Когда генеративная модель отвечает клиенту, готовит выжимку из договора или формирует комментарий к сделке в CRM, вопрос «правильно ли она это сделала» перестаёт быть риторическим. Выборочное ревью не масштабируется: на тысяче диалогов в сутки человек физически просматривает 1–2%, и выборка смещена в сторону случайных, а не рискованных кейсов. Агентный контроль качества — это когда проверку выполняет вторая LLM по формализованной рубрике, а человек подключается только на спорных и пограничных случаях.

Почему одной модели недостаточно

Самопроверка «той же» моделью работает плохо: она воспроизводит собственные ошибки и склонна подтверждать свой же вывод. Поэтому в контуре появляются разные роли — генератор, критик, верификатор фактов, арбитр. Критик получает не только ответ, но и исходный контекст: фрагменты базы знаний, выдержки из регламента, историю диалога. Без контекста судья оценивает стиль, а не корректность, и пропускает галлюцинации.

Как устроен контур проверки

Типовая схема выглядит так. Агент-генератор формирует черновик. Агент-критик разбирает его по пунктам рубрики и возвращает структурированный JSON: вердикт, список дефектов, цитату-обоснование, уверенность. Агент-верификатор отдельно проверяет факты и числа по источникам, а также формальные требования — наличие обязательных полей, корректность сумм, отсутствие персональных данных. Если уверенность ниже порога или критик и верификатор расходятся, кейс уходит человеку в очередь разбора.

Ключевое требование — структурированный вывод и детерминизм на уровне настройки: temperature 0, фиксированный seed, жёсткая JSON-схема. Иначе метрики качества «плывут» между запусками, и вы не поймёте, стало лучше или просто изменилась случайность.

Рубрика важнее модели-судьи

Практика показывает: прирост качества даёт не переход на более крупную модель, а декомпозиция критериев. Вместо «оцени ответ по шкале 1–10» — набор бинарных вопросов: есть ли ссылка на источник, нет ли обещаний, которых нет в регламенте, соблюдён ли тон, не раскрыты ли данные третьих лиц, корректен ли итоговый документ. Бинарные критерии дают воспроизводимость и понятную аналитику: видно, какой именно дефект доминирует.

Ловушки: самоподтверждение, дрейф, стоимость

Три типовые проблемы. Первая — bias к длинным и «уверенным» ответам: судья путает многословие с полнотой, лечится pairwise-сравнением с эталоном и штрафом за лишние утверждения. Вторая — дрейф: обновилась модель генератора или промпт, и старые пороги перестали работать, нужен регулярный пересчёт согласия с человеческой разметкой. Третья — экономика: проверка каждого ответа двумя агентами удваивает расход токенов, поэтому вводят каскад — дешёвый фильтр по правилам, затем LLM-судья, и только потом человек.

Российская практика

В российских внедрениях контур чаще всего строится на локальных моделях — Qwen, Llama-совместимых весах или отечественных API, развёрнутых в контуре компании. Это требование 152-ФЗ и внутренней ИБ: обращения клиентов, медицинские записи и кадровые документы не должны уходить во внешние сервисы. Типовые сценарии — контроль качества поддержки в контакт-центре, проверка корректности выгрузок и комментариев в 1С, аудит ответов по тендерной и нормативной документации, валидация извлечённых OCR-полей.

Практические шаги внедрения

1. Соберите 100–300 эталонных кейсов и разметьте их силами ваших экспертов — это ваш ground truth. 2. Опишите рубрику бинарными критериями, согласуйте формулировки с бизнесом. 3. Реализуйте судью со structured output и логированием обоснований. 4. Замерьте согласие с людьми: цель — не 100%, а стабильные 80–90% и низкая доля ложных пропусков. 5. Встройте прогон в CI/CD и регрессионные наборы, чтобы ловить деградацию после каждого изменения промпта или модели. 6. Настройте мониторинг дрейфа и очередь ручного разбора.

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

Мы проектируем и внедряем агентные контуры контроля качества: подбираем локальные модели под ваш контур безопасности, описываем рубрики, собираем разметку, настраиваем каскад «правила → LLM-судья → человек» и выводим метрики в дашборд. Работаем с интеграциями 1С, CRM и внутренними базами знаний, включая RAG и OCR-пайплайны. Обсудить проект — покажем, как это будет выглядеть на ваших данных.