Production readiness checklist для LLM-системы

Рабочий чек-лист помогает принять решение о запуске конкретного LLM-процесса: можно ли безопасно выпускать текущую версию, что нужно исправить и кто принимает остаточный риск. Это не сертификат и не универсальный порог качества. Скопируйте шаблон Markdown, заполните его ссылками на собственные проверки и сохраните вместе с версией релиза. Для общей работы с промптами смотрите prompt engineering, для интеграций и процесса — AI automation. Локальный контекст команды описан на странице AI-специалист в Армении.

Когда использовать чек-лист

Заполните его до первого ограниченного запуска, после смены модели или промпта, после изменения источников, прав, маршрутизации или инструментов, а также перед расширением аудитории. Фиксируйте один проверяемый сценарий: «ассистент отвечает на вопросы сотрудников по разрешённым документам» точнее, чем «наш AI готов». Для каждого сценария укажите владельца, аудиторию, данные, разрешённые действия, ожидаемый результат и дату проверки. Другой сценарий потребует отдельного решения.

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

Критерии и шкала готовности

Мы предлагаем шесть групп READINESS-6. Scope: определены задача, аудитория, допустимые данные и отказ. Evidence: ответы имеют проверяемые источники или явную границу незнания. Evaluation: есть репрезентативные обычные, сложные и запрещённые кейсы, эталон и ответственный за оценку. Control: права инструментов, подтверждение внешних действий, лимиты и восстановление. Operations: измеряются задержка, стоимость, ошибки, принятые ответы и состояние зависимостей. Change: версии модели, промпта, политики и источников зафиксированы; есть план отката.

Оцените каждый пункт как 0 — нет доказательства, 1 — частичное доказательство с владельцем и сроком, 2 — воспроизводимое доказательство для этой версии, либо N/A с объяснением. Приоритет BLOCKER означает, что 0 или 1 останавливают запуск; среднее арифметическое его не отменяет. Для остальных пунктов допустим ограниченный пилот с зафиксированным планом, если владелец риска его принимает. Итоговая сумма помогает видеть пробелы, но сама по себе не разрешает релиз.

Как заполнить шаблон

Скачайте редактируемый Markdown-файл. На первой странице укажите system_version, model_version, prompt_version, policy_version, source_revision, owner, review_date и аудиторию. Для каждого пункта добавьте балл, ссылку на артефакт, проверяющего, дату и действие при провале. Ссылки на закрытые материалы оставляйте в своей внутренней копии; публичный шаблон не собирает данные.

Начните с реального маршрута запроса: входные данные, retrieval, модель, валидация, возможный вызов инструмента, ответ и журнал решения. Проверьте нормальный запрос, отсутствующий источник, устаревший документ, запрещённый источник, попытку prompt injection, тайм-аут модели и превышение лимита. Для каждого кейса заранее запишите ожидаемое поведение. Смена модели проверяется на том же наборе: подробнее о методике в evaluation suite.

Не подменяйте наблюдение прогнозом. Порог p95 задержки, стоимость на принятый ответ и долю отказов выбирает владелец процесса по собственным данным. Если данных ещё нет, запишите план измерения и лимит пилота. Разбор latency и модель token cost помогают выбрать измерения, но не дают универсальных чисел.

Как интерпретировать результат

GO возможен, когда все blocker-пункты имеют 2, остальные отклонения приняты владельцем, а сценарий и версия совпадают с проверенными. PILOT подходит для ограниченного трафика и аудитории с измерением, ручным маршрутом и заранее назначенной датой повторной оценки. HOLD нужен при незакрытом blocker, неизвестном владельце, неограниченном внешнем действии или неработающем откате. Эти правила — предлагаемый механизм принятия решения, не внешняя сертификация.

Например, система с хорошими ответами, но без теста на доступ к чужому документу получает HOLD: качество не компенсирует риск прав. Если все blocker-пункты пройдены, а данных о p95 пока мало, владелец может выбрать PILOT с ограниченным объёмом и точкой остановки. Укажите конкретную причину, а не «готово на 80%».

Что делать после проверки

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

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