TL;DR
AGO — это процедура принятия решения «выпускать новую версию RAG-бота или нет» (RAG — ответы модели по найденным в вашей базе документам). Вместо одного числа от LLM-судьи у решения четыре исхода: выпустить, на ручную проверку, заблокировать, не оценить. Отсутствие данных и сломанный ответ судьи — это тоже исходы, а не «ноль» и не «пройдено». Перед тем как судья начнёт влиять на решения, его проверяют на эталонном наборе с человеческой разметкой. Для малых выборок вместо «прошло 87%» считают вероятность того, что новая версия стала хуже старой.
Главная находка: дешёвый LLM-судья почти не отличает неподтверждённые ответы от подтверждённых, но снаружи этого не видно. Он возвращает идеальный JSON, ни одной ошибки формата и правдоподобные объяснения. Реальное качество при этом лишь чуть выше подбрасывания монетки. Сильный судья заметно лучше, но по типам документов его надёжность прыгает от «хорошо» до «почти бесполезно». Проверить судью на одном домене и перенести результат на другой нельзя.
Метод сводится к четырём вещам. Первая: судья возвращает строгий JSON, а любой кривой ответ уходит в ручную проверку, а не превращается в оценку. Вторая: решение принимается по доле прошедших кейсов, а не по среднему «баллу». Третья: до запуска судьи на ваших данных его проверяют на 30–100+ кейсах, размеченных людьми. Четвёртая: смена модели судьи означает, что проверку нужно пройти заново.
Схема метода
ШАГ 1: Собрать эталонный набор (30 минимум, 100+ для серьёзных решений),
2 разметчика, оба класса ≥30%, есть пограничные случаи
→ бинарные метки «ответ опирается на источники / нет»
ШАГ 2: Прогнать LLM-судью (температура 0, один JSON-вызов)
→ оценки: релевантность контекста, опора на источники, релевантность ответа
ШАГ 3: Сравнить судью с людьми: согласие, MCC, AUROC, перебор порогов, доверительные интервалы
→ судья допущен / допущен только в режиме «ревью» / отклонён
ШАГ 4: Решение по каждому кейсу
→ нет данных: not evaluable · критическое нарушение: block
· любой другой провал: manual review · иначе promote
ШАГ 5: Решение по прогону (консервативно)
→ один block = block; один review или not evaluable = review
ШАГ 6: Сравнение версий A и B: P(B хуже A более чем на δ)
→ ≥0.8 block · ≥0.5 manual review · иначе promote
Шаги 1–3 — разовая проверка судьи. Шаги 4–6 повторяются при каждом релизе.
Пример применения
Задача: Команда поддержки маркетплейса запустила RAG-бота по базе знаний о возвратах и доставке. Чтобы сэкономить, судьёй поставили самую дешёвую модель. Завтра релиз новой версии бота с другим промптом. Прежде чем доверить дешёвому судье решение «выпускаем», его нужно проверить: у вас есть 100 диалогов, где два сотрудника независимо пометили, опирается ли ответ бота на найденные статьи.
Промпт (для чата с анализом данных, например ChatGPT с Advanced Data Analysis):
Я проверяю LLM-судью для RAG-бота поддержки маркетплейса, прежде чем он
начнёт влиять на решение о релизе.
Во вложении CSV на 100 строк. Колонки:
- case_id
- human_label_1, human_label_2 (1 = ответ опирается на найденные статьи, 0 = нет)
- judge_adherence (оценка судьи от 0 до 1)
Сделай по шагам:
1. Посчитай согласие двух разметчиков (сырое и Cohen's kappa). Это потолок:
судья не может быть надёжнее людей. Итоговую метку возьми как
согласованную; расхождения выведи списком для арбитража.
2. Проверь баланс: доля меньшего класса должна быть не ниже 30%.
Если ниже — скажи об этом до любых расчётов.
3. Для судьи посчитай: AUROC по сырым оценкам, MCC и согласие при пороге 0.8,
перебор порогов от 0.1 до 0.9. Для каждой метрики дай 95% доверительный
интервал (bootstrap, 1000 повторов).
4. Если kappa не определена (в метках один класс) — так и напиши, не подставляй число.
5. Вынеси вердикт: допустить судью в режиме block / только в режиме review /
отклонить. Если нижняя граница интервала AUROC близка к 0.5 — отклонить.
6. Отдельно перечисли строки, где судья уверенно ошибся (оценка ≥0.9 при метке 0).
Результат: Модель сначала сообщит, насколько согласны между собой разметчики, и проверит баланс классов. Затем выдаст таблицу метрик судьи с доверительными интервалами и график или таблицу по порогам. Если дешёвый судья слабый, станет видно, что ни один порог не даёт приличного MCC, то есть дело не в настройке порога. В конце будет вердикт по допуску и список «уверенных промахов» для ручного разбора.
Почему это работает
Слабость. Судья-LLM выглядит надёжно, даже когда он слаб: формат идеальный, объяснения гладкие. Среднее по баллам прячет и слабость судьи, и неопределённость. На 100 кейсах «87% против 84%» может быть чистым шумом. Молча подставленный ноль неотличим от реально измеренного провала. Молча «подправленный» кривой ответ может превратиться в уверенное «прошло».
Сильная сторона. Для сравнения судьи с людьми достаточно небольшого размеченного набора. Бинарные метки, AUROC и доверительные интервалы показывают, различает ли судья классы вообще, причём независимо от выбранного порога. Модель умеет вернуть строгий JSON при температуре 0, а правило «нет данных — не оценивай» можно прописать в инструкции.
Как метод это использует. Он делает неопределённость явной. Нет данных → «не оценено». Судья ответил мусором → ручная проверка. Судья не проверен → работает только в режиме «ревью». Вероятность регрессии честно учитывает размер выборки. Гейт сознательно перестраховывается: лишняя ручная проверка стоит часов сотрудника, пропущенная регрессия — инцидента в проде.
Рычаги управления:
- Размер эталонного набора: 30 кейсов — быстрая проверка «на дым», 100+ — для решений, которые блокируют релиз.
- Режим метрики (observe / review / block): начинайте со всех судейских метрик в review, переводите в block по мере роста набора и после прохождения проверки.
- δ (минимальное ухудшение, которое вам важно, по умолчанию 0,03): для денег и права поставьте меньше, для черновиков — больше.
- Пороги вероятности (0,8 для блока, 0,5 для ревью): снижайте, если инцидент дорогой.
- Критические нарушения (ПДн, секреты, запрещённые фразы, утечка промпта): всегда блок, независимо от настроек метрики.
- Веса категорий: по умолчанию вес категории равен её доле в тесте, но если тест намеренно перегружен критичными случаями, задайте веса по реальному трафику.
Шаблон промпта
В статье рубрика судьи не приведена, есть только её описание: одна JSON-выдача по трём измерениям, температура 0, правила протокола. Шаблон ниже собран по этому описанию.
Блок 1. Судья (один вызов на кейс, температура 0):
Ты — строгий судья ответов RAG-системы {название_системы}.
Ты проверяешь, опирается ли ответ только на найденные фрагменты.
Вопрос: {вопрос}
Найденные фрагменты: {контексты}
Ответ системы: {ответ}
1. Если найденных фрагментов нет или они пусты — верни "status": "not_evaluable".
Не придумывай оценку и не ставь 0.
2. Если реплика не требует поиска (приветствие, благодарность) —
поле adherence не заполняй: верни null.
3. Все оценки — числа от 0 до 1. Любой другой формат — ошибка.
4. Отвечай только JSON, без текста вокруг.
context_relevance: насколько найденные фрагменты относятся к вопросу.
adherence: 1.0 — каждое утверждение ответа подтверждено фрагментами;
0.0 — есть утверждения без опоры или противоречащие фрагментам.
Перечисли неподтверждённые утверждения в unsupported_claims.
answer_relevance: насколько ответ отвечает на вопрос.
{критичные_правила — например: ответ не содержит {запрещённые_фразы}, ПДн}
{"status": "ok", "context_relevance": 0.0, "adherence": 0.0,
"answer_relevance": 0.0, "unsupported_claims": [], "comment": ""}
Блок 2. Правила решения (для прогона и сравнения версий):
Решение по кейсу:
- нет метрик (не удалось оценить) → NOT_EVALUABLE
- провал критической метрики ({критичные_метрики}) → BLOCK
- провал метрики в режиме block → BLOCK
- провал метрики в режиме review → MANUAL_REVIEW
- провал метрики в режиме observe → не влияет, только отчёт
- иначе → PROMOTE
Решение по прогону (консервативно):
- хотя бы один BLOCK → BLOCK
- все кейсы NOT_EVALUABLE → NOT_EVALUABLE
- хотя бы один MANUAL_REVIEW или NOT_EVALUABLE → MANUAL_REVIEW
- иначе → PROMOTE
Недостающие данные — всегда явный пробел с описанием влияния, никогда не значение по умолчанию.
Невалидный ответ судьи не превращай в оценку: кейс уходит на MANUAL_REVIEW.
Версия A (текущая): {прошло_A} из {всего_A} в каждой категории.
Версия B (кандидат): {прошло_B} из {всего_B} в каждой категории.
δ = {дельта}, по умолчанию 0.03.
Для каждой категории возьми апостериорное распределение Beta(1 + k, 1 + n − k).
Сведи категории с весами {веса_категорий}.
Оцени Монте-Карло (10 000 выборок, seed = 42):
ρ = P(доля_B < доля_A − δ).
ρ ≥ 0.8 → BLOCK; ρ ≥ 0.5 → MANUAL_REVIEW; иначе → PROMOTE.
Выведи 95% интервалы по категориям и итоговое ρ.
Что подставлять: {критичные_метрики} — то, что для вас недопустимо в любом случае (утечка ПДн, обещание того, чего нет в политике). {веса_категорий} — доли тем в реальном трафике, а не в тестовом наборе. {дельта} — минимальное ухудшение, которое вам важно.
🚀 Быстрый старт — вставь в чат:
Вот шаблон барьера качества для RAG (судья + правила решения + сравнение версий).
Адаптируй под мою систему: [опиши бота и базу знаний].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие нарушения для вас критические, какие категории вопросов бывают и какова их доля в трафике, а также какое ухудшение качества вы считаете значимым. Это нужно, потому что от них зависят критические метрики, веса и δ. Она возьмёт структуру из шаблона и соберёт рубрику под вашу задачу.
Ограничения
⚠️ Это не сквозная проверка всего гейта: Авторы честно пишут, что бенчмарк проверяет только слой судьи. Сам гейт проверен на симуляции, а не на реальных релизах. Даже с полным набором мер доля небезопасных выпусков при регрессии осталась заметной (порядка пятой-трети случаев), хотя у наивного гейта она выше. Гейт снижает риск, но не убирает его.
⚠️ Эталонные метки тоже сделаны LLM: В RAGBench метки поставили LLM-аннотаторы, откалиброванные по людям. Это не абсолютная истина, и сами авторы называют их «референсными».
⚠️ Две модели, один бенчмарк, по 100 кейсов на домен: Цифры показывают тенденцию, а не точные пределы. Судьи — модели прошлого поколения. Вывод «дешёвый слабый, дорогой сильнее» может сместиться, а вывод «проверяй на своих данных» — нет.
⚠️ Релевантность контекста судья оценил плохо: Корреляции низкие и нестабильные (местами отрицательные). Авторы объясняют это разным определением метрики и считают результат пробным. Доверять этой оценке без своей проверки нельзя.
⚠️ Нужна ручная разметка: 100 кейсов, два разметчика, арбитраж расхождений — это дни работы эксперта. Байесовский расчёт в чате делается через анализ данных, а как постоянный процесс требует скрипта.
⚠️ Любая смена судьи сбрасывает проверку: Размещённые модели меняются без предупреждения. Проверка привязана к точной версии модели, рубрике и порогу.
Как исследовали
Исследователи — консалтинговая команда из Неаполя, которая оценивает RAG-системы для корпоративных клиентов. Данные клиентов закрытые, поэтому судью проверили на открытом бенчмарке RAGBench: 100 тысяч троек «вопрос–документы–ответ» из 12 наборов (юриспруденция, финансы, медицина и др.). Брали по 100 примеров из каждого набора, с балансом классов. Рубрику заморозили до теста и потом не меняли. Двух судей, gpt-4.1-nano и gpt-4o, сначала сравнили на валидационной выборке из трёх наборов, затем один раз прогнали на тесте (1200 примеров на судью, одинаковые для обоих).
Результат: у дешёвого судьи AUROC 0,603, то есть чуть выше случайного, а MCC всего 0,17. Ни один порог в диапазоне 0,1–0,9 не давал MCC выше 0,17, так что проблема не в настройке порога. При этом ни одной ошибки протокола и гладкие объяснения. У gpt-4o AUROC 0,783 (MCC 0,43), но обошёлся он примерно в 24 раза дороже ($9,42 против $0,39 на тесте). По доменам разброс огромный: от 0,62 (юридические контракты) до 0,88 (экспертные вопросы), а MCC от 0,04 (инструкции к устройствам) до 0,62. То есть даже сильная модель на отдельных типах документов почти бесполезна.
Самый показательный эпизод: на пилоте из трёх наборов у того же дешёвого судьи вышло 0,563 с доверительным интервалом, включающим 0,5. Без интервала можно было бы написать «слабоват», а с ним видно: утверждать «лучше случайного» нельзя. Для гейта авторы отдельно проверили три сценария (регрессия, без изменений, улучшение). При регрессии их профиль выпускал плохую версию в 22–35% случаев против 29–42% у наивного. Выигрыш реальный, но скромный. Для практики вывод такой: ваш судья не «в целом хорош», он хорош или плох на ваших данных, и это нужно измерить.
Адаптации и экстраполяции
🔧 Техника: добавить в вывод судьи поле unsupported_claims → разбор ошибок вместо одного числа
"unsupported_claims": ["{цитата из ответа без опоры в источниках}"]
Когда эксперт арбитрирует спорные кейсы, он видит конкретную фразу, а не «0,6». Это быстрее разбирать расхождения судьи и людей и проще найти системные слепые зоны (например, судья пропускает числа и сроки).
Экстраполяция: проверка судьи на других задачах (моё применение, в статье не проверялось)
Логика «эталонный набор → согласие с людьми → интервалы → допуск в режиме ревью» переносится на любого LLM-судью: оценку писем клиентам, качество суммаризации звонков, проверку тональности. Сначала посмотрите, отличает ли судья ваши хорошие тексты от плохих.
Я хочу использовать LLM как судью для {задача: например, оценки ответов менеджеров
в переписке с клиентами}. У меня {число} примеров с оценкой двух сотрудников
(хорошо / плохо). Проверь судью: посчитай AUROC и MCC с доверительными интервалами,
покажи результаты на разных порогах и скажи, можно ли ему доверить блокировку
или только режим «на проверку». Дай список уверенных промахов.
Ресурсы
- AGO AI Quality Gate: Evidence-First Release Decisions for Retrieval-Augmented Generation — Giulio Zeloni, Enrico Lo Conte, Salvatore Rionero, Giuseppe Santoro, Alessandro Rastelli, Fabio Sorrentino; Protom Group S.p.A., Неаполь, Италия.
- RAGBench (Friel et al.) — открытый набор из 100 тысяч трасс RAG с разметкой TRACe. На него опираются все оценки судьи.
- Связанные работы, упомянутые в статье: RAGAs, ARES, TruLens, NeMo Guardrails, исследования смещений LLM-судей (позиционное, по длине).