ЧАСТЬ 1: БИЗНЕС И СТРАТЕГИЯ

«Мы не видели пассажиров — только их тени». Часть 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 остановок:

Формула расчёта выручки рейса:
Выручка = Σ(тариф_i × количество_пассажиров_i)
где тариф_i — стоимость проезда на i-м участке, количество_пассажиров_i — число пассажиров, проехавших этот участок.

1.2. Проблема: Датчик MassTrans ≠ выручка

В автобусах установлен датчик MassTrans — инфракрасный счётчик объёма. Но вот в чём загвоздка:

Кондуктор НЕ видит то, что считает датчик.

Датчик служит индикатором примерного пассажиропотока, а не инструментом контроля выручки.

Почему цифры датчика — это не показатель выручки:

Вывод: Цифры датчика — это примерный поток, а не реальные деньги.

1.3. Как кондукторы используют погрешность в свою пользу

Кондуктор знает: датчик врёт на 25–40%. И он использует это как прикрытие.

Сценарий обмана №1: «Скромный обман в пределах 15%»

Кондуктор не ворует много — он ворует в пределах погрешности датчика.

Схема:

• Кондуктор берёт оплату за 5 остановок у каждого пассажира (наличными)

• В отчёт пишет: 2 остановки (по «данным датчика»)

• Разница: 3 остановки × 10 пассажиров × 50₽ = 1 500₽ на рейсе

Оправдание: «Датчик врёт на 20% — я в пределах нормы. Что вы хотите от меня?»

Сценарий обмана №2: «Продавец напитков»

Оправдание: «Зашёл человек, вышел человек — датчик зафиксировал».

Сценарий обмана №3: «Семья на долгой остановке»

Оправдание: «Датчик посчитал — я записал».

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:
Ошибка_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 (разделённые сценарии):

Почему разные цифры? Пилот — это доказательство концепции с минимальными затратами, включая отладку алгоритма в первые 90 дней. Масштабирование — это полная защита дохода на всём флоте. Гипотетика — иллюстрация потенциальных потерь при отсутствии системы.

Результат: Бюджет утверждён. Срок — 100 дней.

💡 Мой принцип:

«Внедрение ИИ начинается не с кода, а с образования. Если заказчик не видит проблему — он не купит решение».

Заключение Части 1

Мы выявили проблему, обосновали бюджет и договорились с партнёрами. Но самое интересное — впереди.

В Части 2 я расскажу:

• Как мы собрали датасет в Индии (~1 час видео 2.5K)

• Почему разработали собственную CNN вместо готовых решений

• Как обеспечили соответствие DPDPA 2023

• Какие результаты получили на пилоте (12 автобусов)

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

Продолжение следует: [Часть 2: Техническая реализация и результаты] (ссылка будет)

Автор: Алексей Бобрешов, руководитель отдела ИИ
Лицензия: CC BY-NC 4.0