Runbook для LLM-инцидента: что делать, когда ответы внезапно стали неверными

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

Определите признаки инцидента и ответственного. Неверный ответ на один тест и массовая выдача закрытых данных требуют разной срочности и разных первых действий.

Где возникает ошибка

Данные ниже вымышлены: они показывают способ разбора, а не измерения действующего сервиса.

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

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

Как воспроизвести проблему

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

В журнале фиксируйте время наблюдения, гипотезу, действие и результат проверки. Меняйте по одной значимой зависимости, когда это возможно. После восстановления прогоните критичные сценарии и проверьте остаточные внешние действия. Разбор должен завершаться конкретными улучшениями: новый тест, сигнал, ограничение или исправление процедуры, а не общим «быть внимательнее».

Что учитывать при переносе

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

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

Если хотите связать этот разбор с системной практикой, посмотрите программу LLMOps & Evaluation на Latorn: она охватывает контур оценки, версии промптов, мониторинг и выпуск LLM-приложений. Перед оплатой сопоставьте требования курса со своим опытом и задачей проекта.

Следующий шаг: LLMOps: измерение качества, расходы и выпуск изменений. По смежным вопросам: Манифест релиза LLM-приложения: что версионировать кроме промпта, Метрики LLM и высокая кардинальность: почему user_id не стоит делать label.