Ответы LLM нестабильны по своей природе: одна и та же модель на том же промпте выдаёт разные формулировки, а иногда и разные факты. Проверять вручную тысячи диалогов в день невозможно — ни по времени, ни по стоимости. Значит, нужна система: письменные критерии качества, автоматические метрики, LLM-судья и выборочный ручной контроль поверх всего этого.

Сначала зафиксируйте, что считаете хорошим ответом

Без письменной рубрики любая автоматическая оценка превращается в гадание. Опишите 5–8 критериев: фактическая корректность, полнота, отсутствие галлюцинаций, соблюдение формата, тон, безопасность, наличие ссылок на источники. К каждому критерию приложите по два примера — «плохо» и «хорошо». Это займёт час, но именно на эту рубрику будут опираться и судья-модель, и разметчики.

Метрики, которые считаются без человека

Для задач с эталонным ответом автоматика закрывает 80–90% контроля. Что считать:

• точное или нормализованное совпадение — извлечение полей, OCR, классификация;
• precision/recall/F1 по сущностям и тегам;
• валидность формата: JSON-схема, обязательные поля, длина;
• groundedness — доля утверждений, подтверждённых переданным контекстом (ключевая метрика для RAG);
• retrieval-метрики: recall@k, MRR, hit rate по чанкам;
• операционные: латентность, стоимость токенов, доля отказов и таймаутов.

Эти числа не требуют чтения текста и считаются на каждом запросе.

LLM-as-a-judge: работает, если настроить

Судья-модель оценивает ответ по вашей рубрике и делает это дешевле человека в десятки раз. Но есть правила, без которых оценки бесполезны. Задавайте бинарные вопросы вместо шкалы 1–10, разбивайте критерии на отдельные запросы, ставьте temperature 0, требуйте сначала обоснование, потом вердикт. Судья не должен быть той же моделью, что генератор, иначе она систематически себя хвалит. Обязательна калибровка: 100–200 примеров, размеченных человеком, и замер согласия (Cohen's kappa). В закрытом контуре судью разворачивают локально — на Qwen или Llama через vLLM, чтобы данные не покидали периметр.

Выборка вместо тотальной проверки

Полный ручной просмотр не нужен. При 1000 диалогов в день и целевой точности ±5% достаточно 250–350 случайных — этого хватает для статистически значимых выводов. Выборку делайте стратифицированной: по типам запросов, длине, источникам, новым темам. Отдельно ведите «красную зону» — жалобы, эскалации на оператора, отказы, ответы без источников. Эти кейсы разбираются всегда, независимо от объёма.

Эталонный набор и регрессия

Соберите 200–500 реальных запросов с проверенными ответами. Прогоняйте этот набор при каждом изменении: промпт, модель, чанкинг, параметры индекса, обновление базы знаний. Это единственный надёжный способ увидеть, что новая версия не сломала то, что работало. Версии промптов, конфигов и результатов храните в MLflow или Langfuse — иначе через месяц вы не восстановите, что и почему изменилось.

Мониторинг в проде

Логируйте запрос, переданный контекст, ответ, модель, версию промпта, латентность и стоимость. На этих данных автоматически считаются: доля ответов с низким groundedness, доля отказов, доля эскалаций, оценки пользователей. Настройте алерты на падение метрик за сутки — деградация после обновления базы знаний обычно видна именно так. В российских внедрениях удобная связка: трейсы в ClickHouse, дашборды в Grafana, выгрузка проблемных кейсов в очередь разметки.

Практический порядок внедрения

1. Рубрика качества на одну страницу с примерами.
2. Автометрики для всех детерминированных задач.
3. Эталонный набор из 200+ реальных запросов.
4. Судья-модель с калибровкой на человеческой разметке.
5. Выборочная ручная проверка 5–10% трафика.
6. Дашборд и регрессионный прогон в CI.

Рабочий контур обычно собирается за 2–4 недели, после чего контроль качества перестаёт быть рутиной и становится инженерной задачей.

Как мы можем помочь

Мы в АПС проектируем и внедряем системы оценки качества LLM: пишем рубрики, собираем эталонные наборы, настраиваем судей-моделей в закрытом контуре, строим дашборды и регрессионные прогоны в CI, связываем всё это с 1С и CRM. Обсудить проект