Демо врёт, прод не прощает

Почти каждый AI-проект выглядит блестяще на демо. Ассистент бойко отвечает, агент красиво выполняет цепочку действий, заказчик доволен. А через две недели в проде начинается то, чего на демо не было. Модель уверенно выдаёт неправильный ответ. Агент зацикливается. На редкий, но реальный запрос система отвечает чушью, и эту чушь видит клиент. Причина одна: демо показывают на удобных примерах, а прод это поток живых, кривых, непредсказуемых запросов, которых никто не закладывал. И вот тут вскрывается главное заблуждение. Команды относятся к AI как к обычному коду, который либо работает, либо нет. Но языковая модель не выдаёт «работает» и «не работает». Она всегда выдаёт что-то правдоподобное, даже когда ошибается. Поэтому AI-система, которая не падает, это не та, что не ошибается. Это та, что знает, когда сказать «не уверен», и не даёт ошибке дойти до пользователя.

Почему именно второй месяц

Развал почти никогда не происходит в первую неделю, и это сбивает с толку. Первые дни систему кормят те же люди, что её делали, плюс ранние пользователи, которые ведут себя аккуратно и спрашивают примерно то, что задумано. Это всё ещё демо, просто растянутое во времени. А дальше подключается обычная аудитория, и распределение запросов меняется. Приходят формулировки, которых не было в голове ни у одного разработчика. Пользователь пишет с опечатками, обрывает мысль на половине, задаёт три вопроса в одном сообщении, прикладывает документ не из того набора, на котором всё проверяли. Объём растёт, и редкий сценарий, у которого один шанс из тысячи, теперь случается каждый день. Накапливается история диалогов, контекст пухнет, и поведение, стабильное на коротких сессиях, плывёт на длинных. Второй месяц это не какой-то магический срок, это момент, когда реальный поток наконец дотягивается до всех углов, которые на демо обходили стороной. Система не сломалась внезапно. Она с самого начала держалась только на удобных данных, просто это стало видно не сразу.

Где именно начинает сыпаться

Чтобы не говорить абстрактно, разберём три типичных места, и все три про одно и то же: модель не сообщает, что ей плохо. Первое, уверенная ошибка. На вопрос, ответа на который у системы нет, модель не говорит «не знаю», а сочиняет правдоподобный ответ и подаёт его тем же тоном, что и верный. Для пользователя разницы нет, и в этом вся беда. Второе, зацикленный агент. Цепочка действий, которая на демо проходила за три шага, на нестандартном входе уходит в круг: вызвать инструмент, получить не тот результат, попробовать снова, и так пока не упрётся в лимит или не сожжёт бюджет на вызовах. Третье, тихий сбой на краю. Запрос, который чуть выходит за рамки предусмотренного, не вызывает явной ошибки, а получает молчаливо неправильную обработку. Никто не видит исключения в логах, потому что с точки зрения кода всё прошло успешно, просто результат бессмысленный. Общий знаменатель тот же, что и в любой хрупкой системе. Ошибка есть, но она ничем себя не выдаёт и спокойно доезжает до пользователя.

Почему «допишем промпт» не спасает

Когда такое всплывает, первая реакция команды почти всегда одна: добавить в системный промпт ещё правил. Написать «если не уверен, скажи об этом», «не выдумывай», «не зацикливайся». Это не работает по той же причине, по которой промпт не работает как граница безопасности. Промпт это пожелание, а не контроль. Модель прочитает «если не уверен, скажи об этом», но у неё нет встроенного датчика уверенности, который она могла бы честно опросить. Она и про выдумку искренне считает, что не выдумывает. Сколько инструкций ни добавь, поведение остаётся вероятностным, а значит на редком входе всё равно когда-нибудь свалится не туда. Надёжность нельзя выпросить у модели текстом. Её строят вокруг модели, на уровне системы, которая обрабатывает её вывод. Модель это деталь, которая иногда ошибается. Задача инженера не уговорить деталь не ошибаться, а собрать конструкцию, в которой её ошибка не доходит до пользователя.

Как собирается автоматизация, которая держится

Устойчивая система отличается от хрупкой не качеством модели, а тем, что вокруг неё стоит. Первое, у действия должна быть проверяемая граница. Если агент что-то меняет, отправляет, списывает или удаляет, результат нужно проверять не на доверии к модели, а на уровне кода. Ответ модели это предложение, а не команда к исполнению. Прежде чем оно превратится в реальное действие, его проверяют на формат, на допустимые значения, на здравый смысл, и только прошедшее проверку идёт дальше. Всё, что меняет данные или касается чувствительного, требует явного подтверждения и пишется в лог, чтобы потом можно было разобрать, что и почему произошло. Второе, у системы должен быть честный способ сказать «не уверен». Раз сама модель не умеет надёжно оценивать свою уверенность, оценку выносят наружу. Проверяют, опирается ли ответ на реальные подтянутые данные или висит в воздухе. Сверяют с источником. Ставят порог, ниже которого система не выдаёт ответ пользователю, а уходит в запасной путь: переспрашивает, отдаёт человеку, честно отвечает, что данных нет. Лучше сказать «не могу ответить», чем уверенно соврать, и это решение принимает обвязка, а не модель. Третье, у любого цикла должен быть предел и запасной выход. Агенту ставят жёсткий лимит шагов, бюджета и времени, чтобы зацикливание упиралось в стену, а не в счёт за вызовы. На каждый шаг закладывают, что инструмент может вернуть мусор, и описывают, что делать в этом случае, вместо того чтобы слепо пробовать снова. Четвёртое, и без этого всё предыдущее слепо, нужна видимость. Хрупкая система отличается от надёжной тем, что в надёжной видно, когда ей плохо. Логируют входы, выходы, сработавшие проверки и отказы, следят за долей ответов «не уверен» и за тем, как меняется поток запросов. Тогда сдвиг распределения, тот самый, что обычно убивает проект на втором месяце, виден заранее на графике, а не задним числом по жалобам клиентов.