«Мы не видели пассажиров — только их тени». Часть 1: Как я выявил системный обман на ₹650 млн в индийских автобусах
Автор: Алексей Бобрешов, руководитель отдела ИИ
Категория: Искусственный интеллект, управление проектами, бизнес-аналитика, международные проекты
Время чтения: 10–12 минут
Введение: Почему я взялся за этот проект
Я руковожу направлением искусственного интеллекта в одном из крупнейших федеральных холдингов России. В моём портфеле — 6 реализованных проектов за период с ноября 2023 по февраль 2026 в компании «Название не разглашать». Каждое решение выведено из MVP в Version 1,2 и 3 и работают в production.
Ещё 7 проектов я реализовал на этапе MVP в более ранний период до 2023 года (в другой организации).
Но проект Ai Trans-India выделяется особо для меня.
Международный масштаб. Индия — страна с 1.4 миллиарда человек, где общественный транспорт перевозит миллионы пассажиров ежедневно. Войти в этот рынок — значит доказать, что твои решения работают не только в российских условиях.
Финансовый вызов. При гипотетическом масштабировании на 300 автобусов даже ошибка в 12 рублей на пассажира оборачивается потерями в 650 млн рублей в год. Это не техническая задача — это задача защиты дохода компании.
Технологическая сложность. Две камеры (вход + выход), хранение данных на борту во время рейса, выгрузка по WiFi/GSM на конечной остановке, сезонность, культурные особенности, законодательство DPDPA 2023. Стандартные решения не работают.
Моя роль в проекте. Я не просто «внедрял ИИ». Я:
Определил стратегию проекта и выбрал архитектуру
Провёл переговоры с производителем автобусов и поставщиком телематических данных
Принял решение о поэтапном подходе: пилот на 12 автобусах → масштабирование на 56 автобусов
Обеспечил соблюдение индийского законодательства о персональных данных (DPDPA 2023)
Рассчитал ROI и защитил бюджет перед руководством
В этой статье (Часть 1) я расскажу о проблеме, существующих решениях и стратегическом подходе. Во второй части — о технической реализации, архитектуре и результатах.
Глава 1. Задача, которая казалась невозможной
1.1. Контекст: Как работает оплата в индийских автобусах
Междугородние автобусы в Индии — это не просто транспорт. Это сложная экономическая система, где стоимость проезда зависит от количества пройденных остановок.
Пример маршрута из 7 остановок:
Участок | Стоимость (₹) | Примерное время |
|---|---|---|
Остановка 1 → 2 | ₹50 | 15 мин |
Остановка 2 → 3 | ₹70 | 20 мин |
Остановка 3 → 4 | ₹90 | 25 мин |
Остановка 4 → 5 | ₹110 | 30 мин |
Остановка 5 → 6 | ₹130 | 35 мин |
Остановка 6 → 7 | ₹150 | 40 мин |
Формула расчёта выручки рейса:
Выручка = Σ(тариф_i × количество_пассажиров_i)
где тариф_i — стоимость проезда на i-м участке, количество_пассажиров_i — число пассажиров, проехавших этот участок.
1.2. Проблема: Датчик MassTrans ≠ выручка
В автобусах установлен датчик MassTrans — инфракрасный счётчик объёма. Но вот в чём загвоздка:
Кондуктор НЕ видит то, что считает датчик.
Датчик служит индикатором примерного пассажиропотока, а не инструментом контроля выручки.
Почему цифры датчика — это не показатель выручки:
Ситуация | Что видит датчик | Что происходит на самом деле |
|---|---|---|
Продавец с корзиной заходит на остановке | +1 пассажир | Не пассажир — вышел через 2 минуты |
Пассажиры вышли покурить на долгой остановке | −2 пассажира | Те же пассажиры вернулись через 10 минут |
Мать с ребёнком проходят близко | +1 пассажир | Едут 2 человека |
Пассажир с рюкзаком | +2 пассажира | Едет 1 человек + багаж |
Вывод: Цифры датчика — это примерный поток, а не реальные деньги.
1.3. Как кондукторы используют погрешность в свою пользу
Кондуктор знает: датчик врёт на 25–40%. И он использует это как прикрытие.
Сценарий обмана №1: «Скромный обман в пределах 15%»
Кондуктор не ворует много — он ворует в пределах погрешности датчика.
Параметр | Значение |
|---|---|
Фактически пассажиров | 50 человек |
По датчику | 42 человека (−16%) |
В отчёте кондуктора | 40 человек (−20%) |
Разница | 10 человек |
Схема:
Кондуктор берёт оплату за 5 остановок у каждого пассажира (наличными)
В отчёт пишет: 2 остановки (по «данным датчика»)
Разница: 3 остановки × 10 пассажиров × 50₽ = 1 500₽ на рейсе
Оправдание: «Датчик врёт на 20% — я в пределах нормы. Что вы хотите от меня?»
Сценарий обмана №2: «Продавец напитков»
Параметр | Значение |
|---|---|
Что видит датчик | 1 вошёл → 1 вышел |
Фактически | 0 пассажиров (продавец) |
В отчёте | 1 пассажир × 2 остановки = 140₽ |
Украдено | 140₽ на рейсе |
Оправдание: «Зашёл человек, вышел человек — датчик зафиксировал».
Сценарий обмана №3: «Семья на долгой остановке»
Параметр | Значение |
|---|---|
Семья вышла покурить на 15 минут | 4 человека |
Вернулись перед отправлением | Те же 4 человека |
Датчик видит | 4 вышли + 4 зашли = 8 пассажиров |
В отчёте | 8 пассажиров × 3 остановки = 960₽ |
Украдено | 960₽ на рейсе |
Оправдание: «Датчик посчитал — я записал».
1.4. Масштаб проблемы
Текущее состояние:
Пилот: 12 автобусов, маршрут ГородА–ГородБ (сейчас, сбор первичных результатов)
Следующий этап: 56 автобусов (весь флот компании)
Гипотетическое масштабирование: 300 автобусов — для расчёта потенциальных потерь
Почему 300 автобусов — это не план, а предупреждение:
Если бы мы запускали подобный сервис сразу на большом флоте без отладки системы, потери были бы катастрофическими.
При гипотетическом масштабировании на 300 автобусов:
Ежедневные пассажиры = 300 × 4 рейса × 150 человек = 180 000 пассажиров/день
Потери при ошибке 12₽/человек:
В день: 180 000 × 12 = 2 160 000₽
В месяц: 64 800 000₽
В год: 777 600 000₽
💡 Мой вывод как руководителя:
Это не «операционная погрешность». Это системный риск для бизнеса. Решение — не в «усилении контроля», а в автоматизации с минимальным участием человека. Именно поэтому мы начали с пилота на 12 автобусах.
Глава 2. Почему существующие решения не подошли
2.1. MassTrans: Когда объём не равен количеству
Фундаментальное ограничение: датчик считает входящих по объёму, но не отслеживает индивидуальные паттерны личности.
Почему это не работает для финансового учёта:
Ситуация | Как видит MassTrans | Что происходит на самом деле |
|---|---|---|
Двое проходят близко друг к другу | 1 пассажир | 2 пассажира (потеря выручки) |
Пассажир зашёл и вышел на той же остановке | 1 пассажир | 0 пассажиров (ложное срабатывание) |
Продавец напитков заходит с корзиной | 1–2 пассажира | Не пассажир (выходит на следующей остановке) |
Семья выходит на 15 минут на длинной остановке | Новые пассажиры при возвращении | Те же пассажиры (двойной подсчёт) |
Формула ошибки MassTrans:
Ошибка_MassTrans = Σ(ложные_срабатывания + пропущенные_пассажиры + невозможность_отследить_индивидуальность)
В индийских условиях эта формула даёт погрешность 25–40%, что неприемлемо для финансовых расчётов.
Важно: Междугородние перевозки отличаются от городских — здесь редко бывает толкучка на входе. Пассажиры заходят организованно, по одному-два человека. Но это не решает проблему: даже при «чистом» проходе датчик не знает, кто именно зашёл и сколько остановок проехал.
2.2. Потолочные камеры: Ограничение как возможность
По законодательству Индии, в автобусах уже установлены камеры на потолке — для безопасности. Они обязательны.
Расположение камер:
Камера направлена на дверь (контроль входа/выхода)
Дополнительный ракурс — из салона между 1-м и 2-м рядами сидений (контроль прохода)
Что видит потолочная камера:
Верхнюю часть тела (голова, плечи, спина)
Силуэты, но не лица
Отражения от стекла двери
Преимущество междугородних перевозок: в отличие от городских автобусов, здесь редко бывает толкучка на входе. Пассажиры заходят организованно, что упрощает задачу детекции и трекинга.
Точность стандартных моделей (YOLO, OpenCV): ~60%
Это казалось тупиком. Но я увидел здесь возможность: если мы научимся работать с ограниченными данными, мы получим конкурентное преимущество.
Глава 3. Моё стратегическое решение: Поэтапный подход
3.1. Почему я не стал ждать «идеального» решения
Можно было бы:
Требовать установки камер на уровне лица
Ждать одобрения бюджета
Договариваться с регуляторами
Терять миллионы рублей каждый месяц
Моё решение: Запустить пилот на 12 автобусах, собрать первичные результаты за 90 дней, доказать эффективность, затем — аргументированно перейти на 56 автобусов.
🔑 Принцип, который я использую во всех проектах:
«Лучшее — враг хорошего. Покажи результат быстро, затем улучшай. Иначе проект умрёт в переговорах».
3.2. Три ветки работы параллельно
Я разделил проект на три независимые, но взаимосвязанные ветки:
┌─────────────────────────────────────────────────────────────┐ │ ПРОЕКТ Ai Trans-India │ ├─────────────────┬─────────────────┬─────────────────────────┤ │ Ветка 1 │ Ветка 2 │ Ветка 3 │ │ Партнёры │ Заказчик │ Технология │ ├─────────────────┼─────────────────┼────────────��────────────┤ │ Переговоры с │ Образование │ Выбор архитектуры │ │ производителем │ и управление │ и обучение моделей │ │ автобусов │ ожиданиями │ │ │ и поставщиком │ │ │ │ данных │ │ │ └─────────────────┴─────────────────┴─────────────────────────┘
Такой подход позволил:
Минимизировать риски (провал в одной ветке не убивает проект)
Двигаться параллельно
Показывать прогресс на каждом этапе
Глава 4. Ветка 1: Переговоры с партнёрами
4.1. Производитель автобусов
Задача: Получить техническую документацию, согласовать места установки оборудования, гарантии.
Моя позиция: Мы не просим «сделать нам исключение». Мы предлагаем увеличить ценность их продукта — автобус с предустановленной системой подсчёта пассажиров стоит дороже.
Ключевой вопрос: Расположение существующих камер. Имеем:
Потолочные камеры уже установлены (закон обязывает)
Они смотрят на дверь и из салона между 1-м и 2-м рядами сидений
Это даёт два ракурса для отслеживания пассажиров
Результат: Согласованы:
Использование существующих потолочных камер для тестов на MVP
Возможность установки дополнительных камер при масштабировании
Подключение к бортовой сети 24В с фильтрацией помех
Гарантийные обязательства на механическую целостность
4.2. Поставщик телематических данных
Задача: Получить доступ к данным о геопозиции автобуса, времени остановок, синхронизации времени.
Трудность: Поставщик отказался предоставлять прямой доступ к бортовому оборудованию: «Это нарушит архитектуру нашей платформы».
Моё решение: Не ломать стену — найти дверь. Я предложил интеграцию через их публичное API:
Наша система ←── API ←── Телематическая платформа поставщика │ ├── Данные о геопозиции (каждые 15 сек) ├── Синхронизация времени через NTP-сервер └── Выгрузка видео на конечных остановках
🔑 Ключевой урок переговоров:
«В международных проектах важно не требовать изменить систему партнёра, а предложить работать поверх неё. Это сокращает сроки согласования в 3–5 раз».
Глава 5. Ветка 2: Управление ожиданиями заказчика
5.1. Проблема непонимания
Руководство не понимало, зачем нужна «камера для подсчёта людей». Их аргумент: «У нас есть кондукторы — они справляются».
Это типичная ситуация: заказчик не видит проблемы, пока не увидит цифры.
5.2. Мой подход: Показать, а не рассказать
Я провёл образовательную сессию с демонстрацией:
Видео реального рейса с ручным подсчётом (ошибки в 35% случаев)
Прототип на базе YOLOv8 — подсчёт за 7 секунд с точностью 92%
Расчёт потерь: при среднем рейсе 21 000₽ выручки — 7 350₽ теряется из-за ошибок
5.3. Финансовое обоснование
Детальный расчёт ROI (разделённые сценарии):
Сценарий | Пилот (12 автобусов) | Масштабирование (56 автобусов) | Гипотетика (300 автобусов) |
|---|---|---|---|
Оборудование (1 автобус) | 70 000₽ | 70 000₽ | 70 000₽ |
Оборудование (итого) | 840 000₽ | 3.92 млн₽ | 21 млн₽ |
ФОТ команды (3 месяца) | 6 млн₽ | 6 млн₽ | 6 млн₽ |
Инфраструктура (3 месяца) | 1.5 млн₽ | 1.5 млн₽ | 1.5 млн₽ |
Итого затраты | 8.34 млн₽ | 11.42 млн₽ | 28.5 млн₽ |
Защищённый доход (год) | 8 млн₽ | 37 млн₽ | 650 млн₽ |
ROI (первый год) | −4% | 224% | 2180% |
Срок окупаемости | 12–15 месяцев | 4–5 месяцев | 1.5–2 месяца |
Почему разные цифры? Пилот — это доказательство концепции с минимальными затратами, включая отладку алгоритма в первые 90 дней. Масштабирование — это полная защита дохода на всём флоте. Гипотетика — иллюстрация потенциальных потерь при отсутствии системы.
Результат: Бюджет утверждён. Срок — 100 дней.
💡 Мой принцип:
«Внедрение ИИ начинается не с кода, а с образования. Если заказчик не видит проблему — он не купит решение».
Заключение Части 1
Мы выявили проблему, обосновали бюджет и договорились с партнёрами. Но самое интересное — впереди.
В Части 2 я расскажу:
Как мы собрали датасет в Индии (~1 час видео 2.5K)
Почему разработали собственную CNN вместо готовых решений
Как обеспечили соответствие DPDPA 2023
Какие результаты получили на пилоте (12 автобусов)
Почему 96.3% точности — это недостаточно для масштабирования
Продолжение следует: [Часть 2: Техническая реализация и результаты] (ссылка будет)
Автор: Алексей Бобрешов, руководитель отдела ИИ
Лицензия: CC BY-NC 4.0
