LLM в продакшене без ML-отдела: чеклист для ЛПР

Пилот ≠ продакшен

Команде часто кажется: «мы уже используем ИИ» — потому что отдел пробовал ChatGPT, Copilot или телеграм-бота на базе GPT.

Пилот отвечает на вопрос: решает ли модель задачу на наших примерах?

Продакшен отвечает: будет ли это стабильно, безопасно и измеримо через 3–12 месяцев?

Без этого различия проекты застревают между «впечатлило на демо» и «боимся включить для клиентов».

Чеклист до запуска

1. Владелец процесса и граница сценария

• Назначен бизнес-владелец (не только IT): кто принимает качество.
• Сценарий описан в одном абзаце: вход → действие LLM → выход в систему.
• Явно перечислено, что LLM не делает (скидки, юридические обещания, медицина).

2. Источник правды

• Ответы с цифрами и фактами идут из БД, API, индекса — не из «памяти» модели.
• Версия данных в логе каждого ответа (дата прайса, id документа).
• Для RAG — пайплайн переиндексации при обновлении источников (см. материал про RAG).

3. Evals (регрессионные тесты)

• Golden set: 50–100 реальных запросов + эталонный ответ или критерий «допустимо/нет».
• Метрики минимум: доля верных, доля отказов, доля эскалаций.
• Прогон evals перед каждым изменением промпта, модели или индекса.

OpenAI и Anthropic в документации сходятся: без автоматизируемых evals качество деградирует незаметно.

4. Guardrails

• Системный промпт + post-filter: запрещённые темы, PII, утечка инструкций.
• Лимиты длины, таймауты, fallback «передать человеку».
• Для клиентских каналов — disclaimer и кнопка связи с оператором.

5. Интеграция и observability

• Логи: prompt hash, model id, latency, tokens, user/session (без лишних ПДн).
• Алерт на рост ошибок, latency, стоимости.
• Связь с CRM/ERP/тикетами — заявка не теряется в чате.

6. Право и 152-ФЗ (РФ)

• Классификация: есть ли ПДн в запросах и логах.
• Договор с провайдером API / хостингом, политика на сайте.
• Минимизация: не отправлять в модель лишние поля «на всякий случай».
• При необходимости — on-prem или российский провайдер (оценка после пилота на API).

7. Эксплуатация и бюджет

• Ответственный за промпты и базу знаний (0,2–0,5 FTE на средний проект).
• Резерв 20–40% бюджета на итерации после запуска.
• Календарь ревью: раз в месяц — evals + инциденты + стоимость.

Типовые ошибки

• «В prod на следующий день после демо» — нет evals и мониторинга.
• Один mega-prompt на все отделы — некontrolируемые ответы.
• Fine-tune первым шагом — дорого поддерживать; чаще хватает RAG + tools.
• Нет эскалации — пользователь застревает с галлюцинацией.
• Игнор стоимости токенов — при росте трафика бюджет «взрывается».

Минимальная архитектура (без ML-отдела)

Цепочка, которую собирают без ML-отдела:

• Канал — виджет, Telegram, intranet.
• Orchestrator — правила маршрутизации и эскалации.
• LLM API + tools — search, CRM, lookup по данным.
• Guardrails + logging — фильтры, логи, алерты.
• Evals pipeline — регрессионные тесты промптов при каждом изменении.

ML-инженер не обязателен на старте. Нужны: backend/интегратор, владелец процесса, человек, который ведёт golden set.

Когда отложить prod

• Нет владельца процесса и критериев «хорошего ответа».
• Данные хаотичны — аудит качества данных не делали.
• Юридический контур не согласован, а в чат пишут клиенты с ПДн.
• Ожидание «LLM заменит отдел» без метрик — лучше сузить сценарий.

Связанные материалы

• RAG и источник правды — данные под LLM.
• Когда чат-бот не справится — граница сценария vs процесс.