Сбои продакшн-ИИ: что ломается после демо

Большинство ИИ-демо ломаются слишком вежливо. Пример входных данных чистый. Данные актуальные. Инструмент работает. Пользователь задаёт нормальный вопрос. Модель даёт хороший ответ. Все кивают.

В продакшне вежливости меньше. Пользователи вставляют неаккуратные входные данные. Исходные документы устаревают. API отдают тайм-ауты. Промпты дрейфуют. Модель следует неправильной инструкции. Клиент задаёт вопрос чуть за пределами корпуса. Вызов инструмента проходит успешно, но обновляет не ту запись. Рабочий процесс выдаёт что-то достаточно гладкое, чтобы никто не заметил ошибку до более позднего момента.

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

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

Режим сбоя 1: правдоподобный ложный вывод

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

Типичные триггеры:

• Конкретные факты без привязки к источникам.
• Юридические, медицинские, финансовые вопросы или вопросы по регламентам.
• Недавние события.
• Некачественное извлечение (retrieval).
• Резюме длинных документов, где релевантное доказательство спрятано глубоко.

Меры контроля:

• Требуйте цитаты или фрагменты источников для фактических утверждений.
• Отказывайтесь отвечать за пределами доступного набора источников.
• Добавьте оценочные примеры (evals) для известных шаблонов ложных ответов.
• Направляйте результаты с высоким влиянием на проверку человеком.
• Логируйте идентификаторы источников, использованные в ответе.

Не контролируйте это фразой вроде «будь точным». Контролируйте источниками, тестами и контрольными точками проверки.

Режим сбоя 2: устаревший контекст

Ответ опирается на источники, но эти источники устарели.

Примеры:

• Старая страница с ценами.
• Замещённая (устаревшая) политика.
• Предыдущая версия договора.
• Устаревшая документация по продукту.
• Закешированный статус клиента.

Меры контроля:

• Храните дату источника, версию, владельца и правило свежести.
• Предпочитайте авторитетные источники кратким пересказам.
• Помечайте устаревшие источники в результатах извлечения.
• Добавьте тесты на свежесть.
• Уведомляйте владельца, когда ключевые источники старше своего окна пересмотра.

RAG-системы могут уверенно отвечать по устаревшим документам. Слой извлечения (retrieval) должен понимать, что значит «актуальный».

Режим сбоя 3: подхалимство и излишнее соглашательство

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

Это важно в стратегии, анализе, планировании и поддержке решений. Пользователь спрашивает: «Этот план запуска выглядит надёжно, верно?» — и получает согласие вместо анализа рисков.

Меры контроля:

• Просите контраргументы и указание на неопределённость.
• Используйте оценочные критерии решений вместо открытого одобрения.
• Требуйте ответа на вопрос «что могло бы сделать это неверным?».
• Разделяйте генерацию идей и проверку.
• При оценке (evals) включайте примеры, где исходная посылка пользователя ошибочна.

Система должна помогать пользователю думать лучше, а не просто полировать его текущую позицию.

Режим сбоя 4: инъекция в промпт

Модель воспринимает недоверенный контент как инструкцию.

Примеры:

• Веб-страница говорит «ignore previous instructions».
• Письмо в поддержку содержит вредоносные инструкции.
• Документ в RAG-корпусе просит ассистента раскрыть скрытые данные.
• Результат инструмента содержит текст, пытающийся изменить рабочий процесс.

Меры контроля:

• Чётко маркируйте недоверенный контент.
• Никогда не наделяйте извлечённый контент тем же уровнем полномочий, что системные инструкции или инструкции разработчика.
• Ограничивайте разрешения инструментов.
• Добавьте белые списки для исходящих действий.
• Проверяйте примеры инъекций при оценке (evals).
• Держите секреты вне контекста промпта.

Инъекция в промпт не решается одним умным системным промптом. Она снижается архитектурой: границами данных, разрешениями инструментов и валидацией вывода.

Режим сбоя 5: небезопасное использование инструментов

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

Примеры:

• Обновляет не тот контакт в CRM.
• Отправляет письмо не тому получателю.
• Создаёт дубликаты записей.
• Бронирует встречу без подтверждения часового пояса.
• Удаляет или перезаписывает данные.

Меры контроля:

• Начинайте с режима только для чтения.
• Используйте узкоспециализированные инструменты с явными схемами.
• Проверяйте аргументы инструментов вне модели.
• Требуйте подтверждения для операций записи.
• Добавьте ключи идемпотентности.
• Логируйте вызовы инструментов и их результаты.
• Добавьте аварийный выключатель.

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

Режим сбоя 6: дрейф схемы и контракта

Формат вывода модели меняется или меняется нижестоящий API — и рабочий процесс тихо ломается.

Меры контроля:

• Используйте структурированный вывод там, где возможно.
• Проверяйте каждый вывод модели перед использованием.
• Считайте некорректный вывод восстановимым сбоем.
• Версионируйте промпты и схемы вместе.
• Добавьте контрактные тесты для нижестоящих API.
• Мониторьте ошибки разбора.

Если нижестоящий узел предполагает корректный JSON, рабочий процесс должен доказать, что JSON корректен.

Режим сбоя 7: слабый запасной сценарий

Система замечает проблему, но не восстанавливается безопасно.

Плохие запасные сценарии:

• Пустой ответ.
• Тихий сбой.
• Шаблонное извинение без действий.
• Зацикленные повторные попытки.
• Эскалация человеку без контекста.

Хорошие запасные сценарии:

• Понятное сообщение пользователю.
• Очередь на обработку человеком с входными данными, источником, ошибкой и предпринятым действием.
• Повтор с задержкой (backoff) только там, где повтор безопасен.
• Ручной путь для срочных случаев.
• Условие остановки при повторяющихся сбоях.

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

Режим сбоя 8: пробел в наблюдаемости

Что-то ломается, и никто не может восстановить почему.

Меры контроля:

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

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

Реестр режимов сбоя для продакшна

Создайте по одной строке на каждый режим сбоя:

Прилагаемый к этой статье реестр даёт шаблон.

Пока не делайте этого

Не запускайте ИИ, обращённый к клиентам, без реестра режимов сбоя.

Не позволяйте инструментам с правом записи обходить валидацию.

Не полагайтесь только на ручные выборочные проверки после запуска.

Не измеряйте только среднее качество. Редкие сбои могут составлять весь риск.

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

Главный вывод

Продакшн-ИИ-системы ломаются повторяющимися способами. Галлюцинации, устаревший контекст, подхалимство, инъекция в промпт, небезопасное использование инструментов, дрейф схемы, слабый запасной сценарий и пробелы в наблюдаемости — это не крайние случаи. Это обычная часть выпуска ИИ.

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