«Мы не видели пассажиров — только их тени». Часть 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 на конечных остановках
Составлен протокол согласованных технических решений
Почему это было важно: Видео с разными углами позволило мне:
Выявить потенциальные ошибки детекции (перекрытия, отражения, различная конструкция автобусов)
Определить оптимальный угол наклона камеры
Передать чёткие инструкции команде в России — без необходимости повторной командировки
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).
Причины:
Аспект | Готовые модели (FaceNet, ArcFace) | Custom CNN (Adaptive Face Extractor) |
|---|---|---|
Размер входа | Фиксированный (160×160) | Переменный (80×80 – 180×160) |
Точность Re-ID на индийских данных | ~90.0% | 96.3% |
Точность Re-ID на эталонных датасетах | 97.2% | 95.1% |
Размер модели | 98 МБ | 4.7 МБ |
Время инференса | 280 мс | 42 мс на CPU |
Адаптация под Индию | Нет | Да (сари, тюрбаны, освещение) |
Стоимость лицензии | 5–10₽ за запрос | Бесплатно (собственная разработка) |
Почему мы отказались от готовых решений:
Низкая точность на индийских данных — готовые модели обучались на «западных» датасетах и так себе работают с сари, тюрбанами, специфическим освещением.
Высокие вычислительные требования — 98 МБ против 4.7 МБ, 280 мс против 42 мс. Для масштабирования на 56+ автобусов это критично.
Стоимость лицензий — при 180 000 пассажиров в день (гипотетический сценарий) затраты на коммерческие API составили бы миллионы рублей в месяц.
Переменный размер входа — пассажиры разного роста, разное расстояние до камеры. Готовые модели требуют ресайза (потеря деталей), наша работает с нативным размером.
Контроль над данными — мы обязаны соблюдать 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)
Все данные — только на серверах в Индии (регион: Мумбаи)
Изображения лиц хранятся 90 дней для отладки, затем автоматически удаляются
Эмбеддинги могут храниться дольше (не позволяют восстановить изображение)
Информационные таблички в салоне (маратхи, хинди, английский) — информированное согласие
Шифрование: TLS 1.3 + AES-256-GCM
Ежеквартальный аудит третьей стороной
«Право на забвение» — удаление по запросу за 72 часа
Хранение видео на борту:
Потолочные камеры: хранятся по законодательству Индии
Камеры для ИИ: перезаписываются циклично после выгрузки данных
Юридическое обоснование:
DPDPA Section 5 (Legitimate Uses): обработка данных допустима для исполнения договора (перевозка пассажиров)
DPDPA Section 8: данные удаляются после достижения цели (90 дней для отладки)
MeitY разъяснение (2024): эмбеддинги без возможности восстановления изображения не считаются биометрией
Как мы обеспечили соответствие:
Сервер ИИ расположен в Мумбаи, в аккредитованном дата-центре
Автоматическое удаление изображений через 90 дней
Логирование всех операций удаления для аудита
Информационные таблички в каждом автобусе (3 языка)
Глава 8. Результаты: Что изменилось после внедрения
8.1. Метрики эффективности
Показатель | До внедрения | После внедрения | Изменение |
|---|---|---|---|
Точность подсчёта | 65% | 96.3% | +48% |
Рейсов с расхождениями >10% | Неизвестно | 22% выявлено | — |
Время проверки отчёта | 14 часов/рейс | 0 (автоматически) | −100% |
Прибыльность флота | Базовая | +18.7% | — |
Конфликты с пассажирами | Частые | −41% | — |
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 (в предыдущей компании).
Этот проект особенный, потому что демонстрирует три ключевых принципа моей работы:
Стратегия важнее технологии. Я выбрал поэтапный подход, а не «идеальное решение сразу» — и это спасло проект.
Финансовое мышление. Каждый технический риск я переводил на язык потерь и ROI. Это позволило защищать бюджеты и масштабировать решения.
Международный масштаб. Можем, успешно внедрять проекты за рубежом, соблюдая и местное законодательство и работая с локальными партнёрами.
Ещё много работы и следующие шаги
Сбор первичных результатов: 90 дней для отладки алгоритма (текущий этап)
Масштабирование: Переход с 12 на 56 автобусов к апрелю 2026 года
Специализированные камеры: Установка оборудования для повышения точности до 99.5%+
Интеграция с электробусами: Переговоры с компанией-поставщиком систем для расширения покрытия
Другие регионы: Адаптация решения для других штатов Индии и соседних стран
Читать Часть 1: «Мы не видели пассажиров — только их тени». Часть 1: Как я выявил системный обман на ₹650 млн в индийских автобусах
