ЧАСТЬ 2: ТЕХНИЧЕСКАЯ РЕАЛИЗАЦИЯ И РЕЗУЛЬТАТЫ

«Мы не видели пассажиров — только их тени». Часть 2: Как мы создали ИИ-систему для подсчёта пассажиров в индийских автобусах

Автор: Алексей Бобрешов, руководитель отдела ИИ Время чтения: 12–15 минут Это продолжение статьи. Рекомендуется прочитать Часть 1 для понимания контекста.

Введение: От стратегии к реализации

В Части 1 я рассказал о проблеме системного обмана в индийских автобусах, существующих решениях и стратегическом подходе. Теперь — о технической реализации.

Напомню ключевые цифры:

• Пилот: 12 автобусов (сейчас, сбор первичных результатов)

• Следующий этап: 56 автобусов (весь флот компании)

• Гипотетическое масштабирование: 300 автобусов — для расчёта потенциальных потерь (650 млн₽/год)

В этой статье (Часть 2) я расскажу о технической реализации, архитектуре и результатах.

Глава 6. Ветка 3: Технологическая реализация

6.1. Командировка: Цель и результаты

Перед запуском проекта я принял решение лично посетить Индию. Цели:

• Осмотреть автобусы на заводе — понять конструкцию, оценить возможность модернизации

• Снять видео на мобильный телефон с различными углами наклона камеры — чтобы понять, какие могут быть ошибки при входе/выходе пассажиров

• Передать инструкции инженерам — как должны стоять камеры для максимальной точности

• Провести переговоры с поставщиком данных — согласовать технические детали

Результаты командировки (5 дней, бюджет ~250 000₽):

• Собрано ~1 час видео в 4K (пассажиры входят и выходят, разные ракурсы, разное освещение)

• На основе видео сформирован датасет IndiaBus-v1.0 — мало изображений

• Согласован формат передачи данных через API (формат json)

• Подтверждена возможность выгрузки данных по WiFi/GSM на конечных остановках

• Составлен протокол согласованных технических решений

Почему это было важно: Видео с разными углами позволило мне:

1. Выявить потенциальные ошибки детекции (перекрытия, отражения, различная конструкция автобусов)

2. Определить оптимальный угол наклона камеры

3. Передать чёткие инструкции команде в России — без необходимости повторной командировки

6.2. Архитектура системы: Трёхуровневый подход

┌─────────────────────────────────────────────────────────────┐
│                    УРОВЕНЬ 1: БОРТ                          │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐         │
│  │ Камера      │  │ Камера      │  │ GPS/NavIC   │         │
│  │ ВХОД (лицо) │  │ ВЫХОД (лицо)│  │ + Timestamp │         │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘         │
│         └────────────────┴────────────────┘                 │
│                           ↓                                 │
│  ┌─────────────────────────────────────────────────┐       │
│  │  SSD-накопитель: хранение во время рейса        │       │
│  │  Объём: ~15 ГБ за 1 рейс                        │       │
│  └─────────────────────────────────────────────────┘       │
└─────────────────────────────────────────────────────────────┘
                           ↓ WiFi/GSM на конечной остановке
┌─────────────────────────────────────────────────────────────┐
│                    УРОВЕНЬ 2: ВЫГРУЗКА                      │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Скорость передачи: ~400 Мбит/сек                   │   │
│  │  Время выгрузки: ~5-10 минут за рейс                │   │
│  └─────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────────┐
│                    УРОВЕНЬ 3: СЕРВЕР ИИ                     │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐     │
│  │ YOLO        │ →  │ Вырезка     │ →  │ Custom CNN  │     │
│  │ Детекция    │    │ лиц         │    │ Adaptive    │     │
│  │ лиц         │    │             │    │ Face        │     │
│  └─────────────┘    └─────────────┘    │ Extractor   │     │
│                                         │ (512D/1024D)│     │
│                                         └─────────────┘     │
│                                                  ↓            │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  СРАВНЕНИЕ: Embedding_вход ↔ Embedding_выход        │   │
│  │  Порог: в настройке (вопрос в работе)               │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                  ↓            │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Привязка к остановкам через GPS + Timestamp        │   │
│  │  Расчёт: Σ(тариф × количество остановок)            │   │
│  │  Для каждого уникального пассажира                  │   │
│  └─────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

умучался с этой схемой, всё равно кривые поля ))

6.3. Почему Custom CNN, а не готовые решения

Ключевое решение: Разработать собственную архитектуру Adaptive Face Extractor вместо использования коммерческих моделей (FaceNet, ArcFace, Face Recognition).

Причины:

Почему мы отказались от готовых решений:

1. Низкая точность на индийских данных — готовые модели обучались на «западных» датасетах и так себе работают с сари, тюрбанами, специфическим освещением.

2. Высокие вычислительные требования — 98 МБ против 4.7 МБ, 280 мс против 42 мс. Для масштабирования на 56+ автобусов это критично.

3. Стоимость лицензий — при 180 000 пассажиров в день (гипотетический сценарий) затраты на коммерческие API составили бы миллионы рублей в месяц.

4. Переменный размер входа — пассажиры разного роста, разное расстояние до камеры. Готовые модели требуют ресайза (потеря деталей), наша работает с нативным размером.

5. Контроль над данными — мы обязаны соблюдать DPDPA и не можем отправлять биометрию на внешние API.

Архитектура Adaptive Face Extractor:

• Вход: RGB изображение переменного размера H×W×3 (80–180 пикселей)

• Начальный блок: 2× Conv2D(64) + BatchNorm + ReLU

• Мультимасштабный блок: 4 параллельные ветви (Conv2D, Dilation=2, Dilation=3, Pooling)

• Пространственная пирамида пулинга: 4 уровня (1×1, 2×2, 4×4, 8×8)

• Механизм внимания: Squeeze-and-Excitation (SE-блок)

• Финальные слои: 2× Conv2D(512) + GlobalAveragePooling + Dense(1024) + Dropout(0.5)

• Выход: Эмбеддинг 512D или 1024D, L2-нормализованный

Формула эмбеддинга: e = AdaptiveFaceExtractor(image) ∈ R^512 где e — вектор эмбеддинга, L2-нормализованный (∥v∥₂ = 1)

Сходство: similarity(e1, e2) = cosine(e1, e2) > threshold → тот же пассажир (порог в настройке, вопрос в работе)

Почему переменный размер входа критичен:

• Пассажиры разного роста (150–190 см) → разный размер лица в кадре

• Разное расстояние от камеры (0.5–2 м) → масштаб меняется в 4 раза

• Обычные модели требуют ресайза → потеря деталей или добавление шума

• Наша архитектура работает с нативным размером без потери качества

Обучение:

• Датасет: IndiaBus-v1.0 (для тестовых проверок)

• Количество идентичностей: 150+ человек

• Функция потерь: ArcFace Loss (Additive Angular Margin)

• Аугментация: RandomRotation(±10%), RandomZoom(±10%), RandomBrightness(±20%)

• Фреймворк: TensorFlow 2.x + Keras

Начало положено так, далее планов громадьё… на более низкий уровень, на Torch…

6.4. Синхронизация GPS + Timestamp

Проблема: Видео с камер входа/выхода должно быть точно привязано к координатам автобуса для расчёта пройденного маршрута.

Решение:

• GPS-приёмник: гибридный чип NavIC L1 + GPS L1/L5 (точность ≤10 м на территории Индии)

• Timestamp: синхронизация через NTP-сервер в Мумбаи (погрешность <100 мс)

• Частота записи координат: каждые 15 секунд

• Привязка: каждый кадр видео маркируется GPS + Timestamp

Формула расчёта стоимости для пассажира:

Стоимость_пассажира = Σ(тариф_i) для всех остановок i между:
  - Timestamp_входа (GPS_входа ≤ GPS_остановки ≤ GPS_выхода)
  - Timestamp_выхода

6.5. Алгоритм сравнения эмбеддингов

Проблема: Когда пассажир входит и выходит, нужно точно определить, что это один и тот же человек.

Решение: Косинусное сходство с порогом (в настройке):

def compare_faces(embedding1, embedding2, threshold):
    # Косинусное сходство (эквивалентно скалярному произведению для L2-норм)
    similarity = np.dot(embedding1, embedding2)
    
    # Чем ближе к 1, тем более похожи лица
    if similarity > threshold:
        return True  # Один человек
    else:
        return False # Разные люди

Экономическое обоснование порога:

• Высокий порог → меньше ложных совпадений, но больше пропусков (пассажиры не распознаются)

• Низкий порог → больше ложных совпадений, но меньше пропусков

• Сейчас занимаемся настройкой оптимального порога для баланса между точностью и полнотой

Глава 7. Соблюдение законодательства: DPDPA 2023

7.1. Почему это важно для бизнеса

Индийский закон Digital Personal Data Protection Act (DPDPA) 2023 — новый регуляторный, который строже предыдущих индийских норм. Но, в тему сказать, но уступает по охвату и требованиям GDPR (ЕС), CCPA (Калифорния) или PIPL (Китай).

Ключевые отличия:

• Меньше акцентов на трансграничной передаче данных

• Нет требования DPIA (Data Protection Impact Assessment)

• Нет механизма коллективных исков

Штрафы:

• Максимальный штраф: 250 крор рупий (~2.7 млрд₽ / ~$30 млн)

• Но это не за любое нарушение, а за конкретные серьёзные проступки:

  • Отсутствие разумных мер безопасности

  • Утечка персональных данных

  • Повторные нарушения после предписаний

Запрет на обработку данных:

• Возможен, но не является автоматической мерой

• Вводится решением Data Protection Board (DPB) в случае тяжких или повторных нарушений

• Чаще применяются: штрафы, предписания, исправительные меры

Моя позиция: Соответствие законодательству — это не ограничение, а конкурентное преимущество. Мы можем работать там, где другие не могут.

7.2. Как мы обеспечили соответствие

Критическое изменение: Первые 90 дней данные хранятся для отладки алгоритма, затем изображения лиц даже не будем хранить, сразу после обработки удаляются, храним эмбеддинги.

DPDPA 2023: 7 обязательных требований (OTR)

1. Все данные — только на серверах в Индии (регион: Мумбаи)

2. Изображения лиц хранятся 90 дней для отладки, затем автоматически удаляются

3. Эмбеддинги могут храниться дольше (не позволяют восстановить изображение)

4. Информационные таблички в салоне (маратхи, хинди, английский) — информированное согласие

5. Шифрование: TLS 1.3 + AES-256-GCM

6. Ежеквартальный аудит третьей стороной

7. «Право на забвение» — удаление по запросу за 72 часа

Хранение видео на борту:

• Потолочные камеры: хранятся по законодательству Индии

• Камеры для ИИ: перезаписываются циклично после выгрузки данных

Юридическое обоснование:

• DPDPA Section 5 (Legitimate Uses): обработка данных допустима для исполнения договора (перевозка пассажиров)

• DPDPA Section 8: данные удаляются после достижения цели (90 дней для отладки)

• MeitY разъяснение (2024): эмбеддинги без возможности восстановления изображения не считаются биометрией

Как мы обеспечили соответствие:

• Сервер ИИ расположен в Мумбаи, в аккредитованном дата-центре

• Автоматическое удаление изображений через 90 дней

• Логирование всех операций удаления для аудита

• Информационные таблички в каждом автобусе (3 языка)

Глава 8. Результаты: Что изменилось после внедрения

8.1. Метрики эффективности

8.2. Финансовый эффект (на 12 автобусов)

Дополнительная выручка = Выявленные расхождения × Количество рейсов

При 22% рейсов с расхождениями >10% и средней выручке 21 000₽/рейс: Дополнительная выручка = 12 × 4 × 30 × 0.22 × 2 100 = 665 280₽/месяц

Годовой эффект: 8 млн₽ на 12 автобусах

8.3. Текущее состояние

• Пилот: 12 автобусов, маршрут ГородА–ГородБ (сейчас, сбор первичных результатов)

• Система работает: обработка в реальном времени, отчёты автоматически

• Персонал обучен: контролёры получают уведомления о расхождениях

• Данные хранятся: 90 дней для отладки → изображения удаляются, эмбеддинги могут храниться дольше

Глава 9. Почему 96.3% — это недостаточно для масштабирования

9.1. Математика масштабирования

Реальный план:

• Пилот: 12 автобусов (сейчас, сбор первичных результатов)

• Следующий этап: 56 автобусов (весь флот компании)

• Гипотетический сценарий: 300 автобусов — для иллюстрации потенциальных потерь

Расчёт для 56 автобусов (реальный): Ежедневные пассажиры: 56 × 4 × 150 = 33 600

Ошибка 3.7% (100% − 96.3%):

• Неверно посчитанные пассажиры: 33 600 × 0.037 = 1 243 человека/день

• При средней потере 12₽/человек: 14 916₽/день

• В год: 5.4 млн₽

Расчёт для 300 автобусов (гипотетический): Ежедневные пассажиры: 300 × 4 × 150 = 180 000

Ошибка 3.7%:

• Неверно посчитанные пассажиры: 180 000 × 0.037 = 6 660 человек/день

• При средней потере 12₽/человек: 79 920₽/день

• В год: 29.2 млн₽

Но реальная ошибка выше из-за:

• Перекрытий в час пик

• Плохого освещения вечером

• Традиционной одежды (сари скрывают силуэт)

Реалистичная оценка потерь:

• Для 56 автобусов: 12–20 млн₽/год

• Для 300 автобусов (гипотетически): 70–120 млн₽/год

9.2. Решение: Переход к специализированным камерам

Техническое решение: Установка камер на уровне лица с углом обзора 120°, обеспечивающих:

• Видимость лиц при входе/выходе

• Точность до 99.5%+

• Сохранение соответствия DPDPA (90 дней хранения для отладки, затем удаление изображений)

Экономическое обоснование (для 56 автобусов):

• Стоимость установки: 23.7 млн₽

• Дополнительная защита: 12–20 млн₽/год

• ROI: 51–84% годовых

• Срок окупаемости: 14–23 месяца

Но главное: защита от системных рисков (штрафы, репутация, мошенничество)

Статус: Веду переговоры по интеграции с компанией, которая предоставляет доступ к системам электробусов. Это позволит нам расширить покрытие и снизить затраты на установку.

Глава 10. Уроки для руководителей ИИ-проектов

10.1. Ограничения — это драйвер инноваций

Необходимость работы с переменным размером лиц заставила нас:

• Разработать собственную архитектуру Adaptive Face Extractor

• Использовать мультимасштабные свертки и пространственную пирамиду пулинга

• Создать механизм внимания (Squeeze-and-Excitation)

Вывод: Если бы у нас были идеальные камеры с первого дня, мы бы не создали это решение. И теперь оно становится нашим конкурентным преимуществом.

10.2. ИИ должен решать бизнес-проблему, а не техническую

Нам не нужно было «распознать лицо с точностью 99.99%». Нам нужно было «посчитать деньги и выявить обман».

Формула успеха: Успех_ИИ = Бизнес_цель × Техническая_реализуемость / Сложность_внедрения Мы максимизировали первую переменную, а не вторую.

10.3. Работа из России возможна — если есть стратегия

Я не переезжал в Индию. Но:

• Провёл одну командировку для сбора данных

• Договорился с локальными партнёрами

• Обеспечил соблюдение законодательства

• Построил систему, которая работает автономно

Ключевой принцип: «Управляй стратегически, делегируй операционно».

10.4. Иногда ИИ нужен не для оптимизации, а для честности

Мы не хотели «ускорить подсчёт» — мы хотели узнать правду. ИИ стал инструментом прозрачности, который показал:

• 22% рейсов имели критические расхождения

• Системный обман был не случайностью, а паттерном

• Защита дохода важнее, чем техническое совершенство

Заключение: Метафора проекта

🚜 «ИИ забирает у человека мотыгу и даёт ему пульт от дистанционно управляемого трактора».

Но в этом проекте пульт показал кое-что ещё: трактор ехал не туда, куда говорил водитель.

Этот проект — один из шести в моём портфеле за период с ноября 2023 по февраль 2026 в компании. Все проекты выведены из MVP, некоторые до Version 3 и работают в production.

Ещё 7 проектов я реализовал на этапе MVP в период до 2023 (в предыдущей компании).

Этот проект особенный, потому что демонстрирует три ключевых принципа моей работы:

1. Стратегия важнее технологии. Я выбрал поэтапный подход, а не «идеальное решение сразу» — и это спасло проект.

2. Финансовое мышление. Каждый технический риск я переводил на язык потерь и ROI. Это позволило защищать бюджеты и масштабировать решения.

3. Международный масштаб. Можем, успешно внедрять проекты за рубежом, соблюдая и местное законодательство и работая с локальными партнёрами.

Ещё много работы и следующие шаги

• Сбор первичных результатов: 90 дней для отладки алгоритма (текущий этап)

• Масштабирование: Переход с 12 на 56 автобусов к апрелю 2026 года

• Специализированные камеры: Установка оборудования для повышения точности до 99.5%+

• Интеграция с электробусами: Переговоры с компанией-поставщиком систем для расширения покрытия

• Другие регионы: Адаптация решения для других штатов Индии и соседних стран

Читать Часть 1: «Мы не видели пассажиров — только их тени». Часть 1: Как я выявил системный обман на ₹650 млн в индийских автобусах