Этот список проходят по конкретной версии behavior manifest перед запуском. Галочка без ссылки на тест, dashboard, policy или владельца ничего не доказывает.
Перед запуском LLM-фичи в production проверьте:
Use case
- Задача действительно требует языковой интерпретации или генерации.
- Есть бизнес-метрика успеха.
- Известна стоимость ошибки.
- Известно, где нужен человек.
Data and context
- Источники истины определены.
- Контекст минимален и релевантен.
- Права доступа учитываются до retrieval, а не после генерации.
- PII и секреты не уходят без необходимости.
Prompt and output
- Prompt версионирован.
- Output schema описана и валидируется.
- Есть repair/fallback strategy.
- Ошибки формата покрыты тестами.
Backend integration
- Timeouts настроены.
- Retries ограничены.
- Rate limits обработаны.
- Circuit breaker предусмотрен для провайдера.
- Логи не содержат лишних персональных данных.
Quality
- Есть golden dataset.
- Есть regression evals.
- Есть негативные и adversarial примеры.
- Изменение модели или prompt-а не выкатывается вслепую.
Agents and tools
- Tools имеют минимальные права.
- Опасные действия требуют подтверждения.
- Все действия пишутся в audit log.
- Есть лимит шагов, времени и стоимости.
Cost
- Посчитана стоимость одного события.
- Посчитан месячный бюджет.
- Есть лимиты и деградация сервиса.
- Кэширование и model routing рассмотрены до запуска.
Operations
- Есть метрики latency, error rate, token usage, cost.
- Есть alerting по аномалиям.
- Есть dashboard для владельца фичи.
- Есть процедура rollback.
People
- Назначен владелец фичи, который смотрит на метрики после запуска.
- Операторы/пользователи знают, как сообщить о плохом ответе, и этот сигнал куда-то попадает.
- Команда понимает, что делать при инциденте провайдера: деградация, fallback, коммуникация.
Как пользоваться этим чеклистом
Чеклист нужен не для бюрократии перед релизом, а для проектирования. Первый раз пройдитесь по нему до разработки: половину пунктов дешевле закрыть на этапе дизайна. Второй раз — перед запуском. Третий — через месяц после запуска, когда уже видно, срабатывает ли alerting в реальности.
Незакрытый пункт нельзя прятать под «потом доделаем». Это осознанно принятый риск. Запишите: что может случиться, насколько вероятно, кто решил жить с этим.
Практикум
Задача 58.1: аудит боевой фичи. ⭑⭑
Возьмите свою рабочую LLM-фичу (или результат задач 24.1–24.2, доведённый до «почти прода»). Пройдите весь чеклист честно, без «ну почти есть».
Критерии приёмки:
- По каждому пункту: закрыт / не закрыт / неприменим: с одним предложением обоснования.
- Для каждого незакрытого пункта записан риск: сценарий, вероятность, ущерб.
- Составлен план: три пункта, которые закрываются на этой неделе, и почему именно они.
- Чеклист скопирован в репозиторий проекта и стал частью definition of done для AI-фич.
Подсказки:
- Самые частые провалы аудита: «Quality» (golden dataset есть у единиц) и «Cost» (лимиты «где-то в биллинге провайдера»). Начните с них.