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

Но чем ближе мы подходили к реальному рейсу, тем меньше задача была похожа на обычную детекцию. Оказалось, что сначала нужно договориться о времени, остановках, идентификаторах и даже о том, что именно считать событием входа. Модель может правильно увидеть человека — и всё равно выдать неправильный бизнес-результат.

В какой-то момент я понял: главная угроза AI-проекту — не всегда слабый алгоритм. Иногда опаснее слишком ранняя уверенность, что мы уже правильно поняли задачу.

Я веду несколько проектов одновременно и регулярно использую генеративные модели в работе. Они помогают мне разбирать требования, обсуждать архитектуру, проверять гипотезы, готовить постановки задач и смотреть на код с разных сторон. Но со временем моё отношение к ним изменилось.

Раньше естественным казался вопрос: «Предложи хорошее решение». Теперь я гораздо чаще формулирую запрос иначе:

Вот мой вариант. Не улучшай его и не соглашайся со мной. Найди допущения, при которых он перестанет работать. Укажи, что необходимо проверить на данных, в коде и у заказчика.

Генеративная модель стала для меня не источником правильных ответов, а доступным оппонентом. И это, пожалуй, намного полезнее.

Когда компьютерное зрение — только часть задачи

В проекте контроля пассажиропотока нужно было связать несколько миров.

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

Во втором мире находилась телематика: время движения, координаты, скорость и предполагаемые остановки.

В третьем — бизнес-смысл. Нужно было не просто обнаружить человека, а связать событие с конкретным рейсом и участком маршрута. Если эта связь недоказуема, красивое число на дашборде мало что значит.

Первоначальная логика напрашивалась сама собой:

камера
  -> детекция человека
  -> определение входа или выхода
  -> привязка ко времени и остановке
  -> пассажиропоток по рейсу

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

Совпадают ли часы камеры и телематики? Можно ли считать любую стоянку остановкой для посадки? Не потеряется ли человек при перекрытии? Не попадёт ли одно событие в два соседних интервала? Что делать, если модель не уверена? Кто отвечает за связь между видео, рейсом и маршрутом?

Если задать модели общий вопрос «как построить систему подсчёта пассажиров», она охотно нарисует архитектуру. В ней будут детектор, трекер, база данных, API и дашборд. Всё будет выглядеть законченно.

Но законченная схема ещё не означает законченного понимания.

Поэтому я стал использовать модели иначе: просить их перечислить условия истинности цепочки. Не «как реализовать», а «что должно быть доказано, прежде чем мы сможем доверять результату».

В нашем случае одним из таких условий оказалось время.

Один рейс и несколько вариантов времени

Фраза «время события» кажется однозначной, пока не начинаешь работать с реальным видео.

Есть время в имени файла. Есть временная позиция кадра внутри видеопотока. Есть часы, напечатанные поверх изображения. Есть метки телематики. Наконец, есть время, которое ожидает увидеть бизнес-пользователь.

Если эти шкалы расходятся, алгоритм может правильно определить вход пассажира, но привязать его не к той остановке. Для компьютерного зрения событие останется верным. Для системы пассажиропотока — уже нет.

При проверке одного из файлов выяснилось, что часы внутри изображения имеют постоянное смещение относительно временной шкалы, восстановленной из имени файла и позиции кадра. Это обнаружила не языковая модель. Смещение подтвердили контрольными кадрами и сопоставлением с телематикой.

Именно здесь находится важная граница.

Генеративная модель помогла расширить список вопросов: какие источники времени существуют, какой из них считается опорным, как обнаружить рассинхронизацию, что произойдёт с последующими расчётами. Но ответ появился только после проверки исходного видео и данных.

После этого формулировка задачи изменилась. Нам требовалось уже не просто «синхронизировать видео с GPS», а зафиксировать воспроизводимое правило:

опорное время файла
  + временная позиция события внутри видео
  -> абсолютное время события
  -> попадание в подтверждённый интервал
  -> связь с телематикой

Экранные часы при этом могли оставаться полезным контрольным признаком, но не должны были незаметно превратиться в источник истины.

Для меня это характерный пример того, как меняется работа с GenAI. Её ответ не закрывает вопрос. Хороший ответ помогает точнее сформулировать, какое доказательство нам нужно получить.

От возражения — к инженерному артефакту

Разговор с моделью легко создаёт ощущение движения. За полчаса можно получить несколько вариантов архитектуры, таблицу рисков, тест-план и убедительное резюме для встречи.

Но если после разговора в проекте ничего не изменилось, возможно, движения не было.

Я стараюсь заканчивать такую работу одним из конкретных результатов:

• вопросом ответственному участнику;

• схемой границ модулей;

• контрактом входных и выходных данных;

• тестовым сценарием;

• записью об архитектурном решении;

• статусом «не подтверждено»;

• измерением на исходных данных.

В проекте пассажиропотока это привело к разделению ответственности. Один контур проверяет видео, строит временную шкалу, связывает её с телематикой и формирует интервалы-кандидаты. Другой выполняет детекцию, трекинг и определение направления движения.

Между ними нужен не устный договор и не надежда, что разработчики одинаково поняли задачу. Нужен машинно проверяемый контракт: какие поля передаются, что они означают, какая версия данных использована и что делать со спорным событием.

Особенно важным для меня стало последнее.

Система не должна молча выбрасывать всё, что не удалось уверенно сопоставить. Неопределённое событие тоже является результатом. Его нужно сохранить, пометить и при необходимости отправить на ручную проверку.

То же относится к остановкам. Нулевая скорость ещё не доказывает посадку: автобус мог стоять в пробке, на светофоре или по технической причине. Поэтому найденный по телематике интервал сначала получает статус кандидата. Геозона помогает установить место, открытие двери — возможность посадки. Сам факт входа пассажира требует отдельного подтверждения, например по видео. Эти сигналы отвечают на разные вопросы и не должны незаметно подменять друг друга.

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

Я не устраиваю голосование между моделями

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

Однако я не считаю совпадение ответов доказательством.

Разные модели могут обучаться на похожих данных, воспроизводить распространённые шаблоны и одинаково пропустить неверное исходное допущение. Более того, если сформулировать вопрос так, чтобы он подталкивал к желаемому ответу, большинство моделей помогут этот ответ красиво обосновать.

Поэтому я стараюсь разводить роли.

Первая модель может защищать предложенное решение. Вторая получает задачу найти условия его отказа. Третья сравнивает не красоту аргументов, а перечень проверяемых утверждений. После этого я возвращаюсь к первоисточникам, коду и данным.

Чтобы второй разбор не превратился в пересказ первого, полезно сначала дать моделям одну постановку независимо, без чужих ответов. А уже затем сравнить замечания. Это уменьшает взаимное влияние ответов, хотя независимость самих ошибок всё равно не гарантирует.

Пример запроса для такого разбора может выглядеть так:

Ниже приведена гипотеза и известные ограничения проекта.

1. Отдели подтверждённые факты от предположений.
2. Найди скрытые зависимости и неоднозначные термины.
3. Предложи три сценария, в которых решение даст правдоподобный,
   но неверный результат.
4. Для каждого сценария укажи способ независимой проверки.
5. Не объявляй гипотезу подтверждённой и не придумывай отсутствующие данные.

Ценность такого ответа определяется не числом найденных рисков. Она определяется тем, сколько из них удалось превратить в проверяемые действия.

Что мне даёт портфель проектов

Одновременная работа с несколькими проектами обычно описывается как проблема переключения контекста. Это действительно проблема. Но у неё есть и обратная сторона: начинаешь видеть повторяющиеся классы ошибок.

В системе непрерывного мониторинга внешне другая задача. Там важны текстовая база, разные типы документов, существующая инфраструктура, роли и права доступа. Но базовый вопрос оказывается знакомым: когда найденный фрагмент действительно можно использовать в ответе, а когда пользователь не имеет права его видеть или контекст недостаточен?

В проекте осмотра транспортного средства другой интерфейс: фотографии, голосовое описание, распознавание номера, авторизация пользователя и сохранение материалов осмотра. И снова повторяется тот же мотив. Распознать объект недостаточно. Нужно доказуемо связать результат с пользователем, сессией, временем и разрешённым действием.

Технологии различаются, но ошибки удивительно похожи:

• бизнес-событие не совпадает с тем, что измеряет модель;

• идентификаторы связываются на основании догадки;

• ответственность теряется между модулями и командами;

• демонстрационный результат принимают за промышленный;

• уверенность алгоритма путают с достоверностью факта;

• неизвестное значение незаметно заменяют наиболее удобным.

Именно портфельный взгляд помогает переносить между проектами не готовый код, а более ценный актив — способ задавать вопросы.

Где модели действительно помогают, а где заканчивается их компетенция

Есть формулировка, которой я стараюсь избегать: «Продукт надёжен, потому что его проверили несколько нейросетей».

Нейросеть не выдаёт сертификат надёжности. Она не заменяет тестирование, ревью безопасности и тем более пентест. Пентест имеет конкретный объект, область, методику и отчёт. Если модель просмотрела код и не нашла проблему, это означает только то, что модель не нашла проблему.

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

Семь правил, к которым я пришёл

1. Не просить модель подтвердить мою правоту

Полезнее спросить, при каких условиях моя идея окажется неверной. Особенно если первое решение кажется очевидным.

2. Передавать не весь контекст, а разрешённый и достаточный

Рабочие данные, персональная информация, внутренняя инфраструктура и уязвимости не должны попадать во внешнюю модель только потому, что так удобнее. Если задачу можно проверить на обезличенном или синтетическом примере, я выбираю этот путь.

3. Отделять факт от версии

В ответе модели факты, предположения и рекомендации часто звучат одинаково уверенно. В проектной документации у них должны быть разные статусы.

4. Превращать хороший вопрос в артефакт

Если замечание важно, оно должно попасть в тест, контракт, решение, запрос или список открытых рисков. Иначе оно исчезнет вместе с окном диалога.

5. Не считать согласие нескольких моделей независимой проверкой

Совпадение полезно как сигнал, но ничего не доказывает без первоисточника или эксперимента.

6. Сохранять неизвестное

Система должна уметь сказать: «данных недостаточно», «событие спорное», «нужна ручная проверка». Иногда это более зрелый результат, чем уверенная цифра.

7. Оставлять финальную ответственность человеку

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

Вместо заключения

Я начал использовать генеративные модели, потому что хотел быстрее работать с текстом, кодом и документацией. Со временем оказалось, что их главное преимущество для меня находится в другом месте.

Они позволяют быстрее выйти за пределы первой версии решения.

Но между «модель предложила» и «система работает» остаётся вся инженерия: данные, контракты, измерения, тесты, безопасность, договорённости и ответственность.

И здесь у меня возник следующий вопрос.

Когда я перехожу от обсуждения проекта к устройству самой системы, появляется похожая развилка. Достаточно ли ей выбрать один наиболее вероятный путь? Что, если при высокой цене ошибки стоит сохранить несколько альтернатив, сравнить их и иногда решить, что действовать пока рано?

Этой гипотезе я хочу посвятить следующий материал. А затем разобрать небольшой воспроизводимый пример: где интуиция о пользе нескольких моделей даёт сбой и как из этого построить эксперимент.

А какие этапы вашего инженерного цикла вы сознательно не отдаёте генеративной модели — даже если она предлагает убедительный ответ?