TL;DR
CAP — способ проверить LLM, которую вы поставили «судьёй» (она выбирает лучший из двух ответов или оценивает качество). Вместо одного процента точности судью проверяют по восьми условиям. Четыре из них — типы ошибок: выдуманный факт, сломанная логика, преувеличение («гарантируем всегда»), пропуск важной оговорки. Ещё три — устойчивость к оформлению: красивый стиль, раздутая длина, порядок ответов (A/B и B/A). Восьмое — качество объяснения вердикта.
Главная находка: общая точность судьи скрывает узкие слабости. Модель, которая лучше всех ловит выдуманные факты, может хуже всех замечать пропущенную оговорку. Два судьи с одинаковой общей точностью проваливаются в разных местах. Самый сильный по общему счёту судья ловил пропуски хуже слабых моделей. Рейтинг по пропускам почти обратен рейтингу по фактам. Ещё одна боль: судья часто меняет вердикт, если поменять ответы местами. Если требовать правильный вердикт в обоих порядках, цифры падают сильно.
Суть метода: взять пары «хороший ответ / ответ с одной подложенной ошибкой». Прогнать судью в обоих порядках, на разных видах ошибок и на «приукрашенных» и «раздутых» версиях. Результат читать как профиль по условиям, а не как одно число. Профиль показывает, для какой именно задачи судья подходит.
Схема метода
ШАГ 1: Собрать пары (правильный ответ A* + такой же ответ с ОДНОЙ подложенной ошибкой)
→ типы ошибок: факт / логика / преувеличение / пропуск оговорки
ШАГ 2: Сделать варианты оформления (одним промптом к LLM)
→ «причёсанный» стиль · «раздутый» ответ с ошибкой (~2× длины)
ШАГ 3: Прогнать судью на каждой паре в двух порядках (A/B и B/A)
→ вердикт + краткое объяснение
ШАГ 4: Посчитать долю верных вердиктов отдельно по каждому условию
→ устойчивость = верно в ОБОИХ вариантах (порядок, стиль, длина)
ШАГ 5: Проверить объяснения только у верных вердиктов (другая LLM)
→ «поддерживает ли объяснение вердикт»
ИТОГ: профиль из 8 чисел на судью → выбор судьи под свою задачу
Шаги 1–2 и 5 делаются обычными запросами к LLM. Шаг 3 — серия запросов в чате или в простой автоматизации.
Пример применения
Задача: Команда маркетплейса вроде Ozon или Wildberries запускает бота поддержки. Ответы бота нужно автоматически проверять. Выбирают между дешёвой и дорогой моделью в роли судьи. Критичные ошибки бота: выдуманный срок возврата, обещание «вернём деньги всегда» и потерянная оговорка вроде «если товар не был в использовании».
Промпт 1 — делаем тестовые пары (один раз, в чате):
Вот правильный ответ службы поддержки маркетплейса:
«Вы можете вернуть товар в течение 14 дней с момента получения, если он не был в использовании и сохранён товарный вид. Деньги вернём на карту в течение 10 дней после проверки возврата.»
Сделай 4 испорченных версии. В каждой — ровно ОДНА ошибка, остальное слово в слово как в оригинале:
1. ФАКТ: подставь выдуманный срок или сумму.
2. ЛОГИКА: поменяй причинно-следственную связь или условие на обратное.
3. ПРЕУВЕЛИЧЕНИЕ: добавь обещание, которого в оригинале нет («всегда», «без исключений»).
4. ПРОПУСК: убери важную оговорку, остальное оставь.
Ошибка должна быть тонкой, чтобы не бросаться в глаза. К каждой версии напиши одной строкой, что именно испорчено.
Промпт 2 — судья (запускать на каждой паре дважды: ответы в порядке A/B, потом B/A):
Ты проверяешь ответы службы поддержки. Вопрос клиента: «Можно ли вернуть куртку, если я её примерял дома, а бирка на месте?»
Ответ A: {текст_A}
Ответ B: {текст_B}
Выбери ответ, который точнее и безопаснее для компании. Верни:
ВЕРДИКТ: A или B
ОБЪЯСНЕНИЕ: 2–3 предложения — что именно не так в проигравшем ответе.
Результат: Для каждой модели-судьи получится небольшая таблица. По строкам — типы ошибок (факт, логика, преувеличение, пропуск). Отдельно — доля пар, где вердикт верный в обоих порядках. Скорее всего, будет видно, что модель уверенно ловит выдуманные цифры, но хуже замечает пропавшую оговорку. Или что часть вердиктов «переворачивается» при смене порядка. Если ваш главный риск — потерянные оговорки, выбирайте судью по этой колонке, а не по общей точности.
Почему это работает
Слабость: Одна цифра точности смешивает разные навыки. Судья может хорошо ловить выдуманные факты и при этом плохо замечать, что в ответе чего-то не хватает. Ошибку-пропуск искать сложнее: нет неверного утверждения, на которое можно указать. Ещё судья подвержен позиции (склонен выбирать первый или второй ответ), длине (длинный кажется лучше) и «красивому» стилю.
Сильная сторона: Если подложить ровно одну известную ошибку в пару, правильный ответ известен заранее. Тогда проверка сводится к простому подсчёту. LLM сама хорошо генерирует такие испорченные версии. Объяснения вердиктов она тоже проверяет достаточно надёжно: в исследовании её оценка совпала с человеческой примерно в 92% случаев.
Как метод это использует: Он разделяет навыки, которые обычно слиты в одно число. Требование «верно в обоих вариантах» отсеивает случайные попадания: судья, который угадал только в одном порядке, не считается надёжным. Проверка объяснений только на верных вердиктах отделяет «угадал» от «понял».
Рычаги управления: - Типы ошибок — добавьте свои (например, «неверный тон», «утечка внутренней информации») под ваш риск. - Размер выборки — на 10–15 пар на условие уже видны грубые провалы. Тонкие различия между моделями требуют десятков пар. - Сложность пар — на лёгких парах все судьи набирают 90%+, различий не видно. Делайте ошибки тоньше. - Строгость — «верно в обоих порядках» строже, чем «верно в среднем». Для критичных задач берите строгий вариант.
Шаблон промпта
Генератор тестовых пар (шаг 1):
Вот правильный ответ в моей области ({область}):
«{эталонный_ответ}»
Сделай 4 испорченных версии. В каждой — ровно ОДНА ошибка, остальной текст не менять:
1. FACTUAL_FABRICATION — выдуманный факт, число, срок или имя.
2. LOGICAL_REVERSAL — логика или условие развёрнуты наоборот.
3. SCOPE_OVERCLAIM — добавлено утверждение шире, чем позволяют данные («всегда», «все», «гарантированно»).
4. SCOPE_OMISSION — убрана важная оговорка или условие; всё остальное осталось.
Требования: ошибка тонкая (оцени сам по шкале 1–5, нужно ≥4; если ниже — перепиши). К каждой версии добавь строку «Что испорчено: …».
Вариант оформления (шаг 2):
Перепиши ОБА текста (правильный и испорченный) в формальном, «отполированном» стиле. Смысл и ошибка не меняются, длина ±20%.
Затем сделай третью версию: испорченный ответ раздуй примерно вдвое нейтральными фразами, которые не содержат новых фактов и не противоречат тексту. Правильный ответ не трогай.
Судья (шаг 3, запускать в двух порядках):
Задача: выбрать лучший ответ на запрос.
Запрос: {запрос}
Ответ A: {ответ_A}
Ответ B: {ответ_B}
Верни:
ВЕРДИКТ: A или B
ОБЪЯСНЕНИЕ: кратко, какая конкретная ошибка или сравнительный критерий определил выбор.
Подставляйте: {область} — вашу тематику; {эталонный_ответ} — проверенный правильный ответ; {запрос} — исходный вопрос. Считайте для каждой модели долю пар, где вердикт верный в обоих порядках, раздельно по четырём типам ошибок.
🚀 Быстрый старт — вставь в чат:
Вот шаблон диагностики LLM-судьи по методу CAP. Адаптируй под мою задачу: [твоя задача, что судья должен проверять].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что именно судья будет проверять, какие ошибки для вас самые дорогие и есть ли эталонные ответы. Это нужно, чтобы подобрать типы ошибок и сделать их тонкими, иначе тест окажется слишком лёгким. Она возьмёт паттерн из шаблона и соберёт готовые промпты под вашу область.
Ограничения
⚠️ Потолок на лёгких данных: если пары простые, почти все судьи набирают больше 90% по большинству условий, и различия исчезают. Профиль различает судей только на достаточно трудных парах.
⚠️ Результаты привязаны к задаче: лидер на тесте с подложенными ошибками (Claude Sonnet 4.5) уступил лидерство Gemini 2.5 Pro на тесте с математикой и кодом. Профиль нужно строить на вашем типе контента.
⚠️ Хрупкий результат про пропуски: конкретный разрыв между двумя Claude по пропускам оговорок не подтвердился на независимом наборе, а выборка мала. Подтвердилась только общая картина: точность по пропускам не растёт вместе с общей точностью.
⚠️ Тестовые данные сгенерированы одной моделью: ошибки подложил GPT-4o. Авторы проверили второй генератор: абсолютные цифры меняются, а ранжирование судей в основном сохраняется. Но это не снимает вопрос полностью.
⚠️ Оценка объяснений зависит от проверяющей модели: её ошибки односторонни (она скорее занижает качество), так что цифры — это нижняя граница. На малом числе верных вердиктов доверительные интервалы очень широкие.
⚠️ Полная версия требует кода: точные доверительные интервалы и сравнение по нескольким бенчмаркам нужны исследователям. Практик может обойтись мини-версией на 10–30 пар, но тогда статистическая надёжность ниже. Статья в приведённом фрагменте обрывается: разбор «адверсариальных» атак и сравнения моделей одного семейства виден только в аннотации.
Как исследовали
Авторы взяли семь судей: GPT-4o и mini, Claude Sonnet 4.5 и Haiku 4.5, Gemini 2.5 Pro и Flash, Llama-3.3-70B. Идея была простой: если одна цифра точности скрывает слабости, то нужно разложить её на условия. Для этого они сами построили тестовый набор из 2 092 базовых пар. Правильные ответы брали из вопросников по медицине, праву, математике, физике, логике и TruthfulQA. Затем GPT-4o «портил» ответ одной из четырёх ошибок, а отдельная оценка тонкости отсеивала слишком очевидные подделки. Каждую пару расширили тремя вариантами оформления и двумя порядками — всего 6 276 пар. Чтобы найти различия, выделили «трудные» подмножества, где модели ошибаются: на полном наборе все упирались в потолок.
Результаты получились неожиданными. Claude Sonnet 4.5 был лучшим по общей точности на трудном подмножестве (89,7% против 80,5% у Haiku), но на пропусках оговорок набрал лишь 59,2%, на 11 пунктов хуже Haiku. Gemini Flash и Pro близки по общей силе, но качество объяснений у них различается почти вдвое (44% против 83%). У GPT-4o-mini «условная» оценка объяснений выглядела хорошо (75%). Но если считать от всех пар, а не только от верных вердиктов, получалось лишь около 20%.
Самое показательное — порядок ответов. При строгом критерии «верно в обоих порядках» GPT-4o дал лишь 25% на трудном подмножестве, а Sonnet — 86%. Рейтинг судей по устойчивости к порядку хорошо переносится между бенчмарками (средняя корреляция рангов 0,87). Для практика вывод такой: проверка порядка — самый переносимый и надёжный тест, тогда как рейтинг по содержательным ошибкам зависит от набора данных. Кроме того, судьи, лучшие по пропускам, оказываются худшими по фактам (корреляция рангов −0,86): это разные навыки, и общая цифра их смешивает.
Адаптации и экстраполяции
🔧 Техника: добавить подсчёт «вердикт + объяснение верны» → отсечь «угадавших»
Не оценивайте объяснения только по верным вердиктам. Считайте долю всех пар, где верны и вердикт, и объяснение. В работе именно этот показатель сильнее разделил судей: «красивое» среднее по объяснениям скрывало, что модель редко попадает в верный вердикт. В промпте проверяющей модели:
Вот ошибка, которую мы подложили: {что_испорчено}.
Вот объяснение судьи: «{объяснение}».
Назвало ли объяснение именно эту ошибку или верный критерий сравнения, а не просто пересказало вердикт? Ответь: ДА / НЕТ и одной фразой почему.
Экстраполяция: двойной прогон в рабочем процессе агента. Этот шаг в статье не проверялся, это идея по мотивам. Если агент или промпт-проверяющий выбирает лучший вариант из двух (например, два черновика письма клиенту), просите его сравнить в двух порядках и принимайте решение, только если оба вердикта совпали. Если не совпали — отправляйте на ручную проверку:
Сравни два черновика. Сначала в порядке «Черновик 1 / Черновик 2», затем в обратном порядке. Если выбор в двух проходах разный — напиши «НЕУСТОЙЧИВО: нужен человек» и укажи, в чём спор.
Ресурсы
- Conditional Accuracy Profiles: Diagnosing LLM Judges across Deployment Conditions — Wenqi Li, Bin Liu, Mindi Ruan, Chuanbo Hu, Minglei Yin, Xin Li. University at Albany, SUNY; West Virginia University.
- Новый тестовый набор авторов: JUDGEREVA-STANDARD.
- Использованные бенчмарки: JudgeBench, JudgeBench-Pro (из BiasScope), RewardBench, MT-Bench, LLMBar. Связанные работы: RM-Bench, FBI, JRH.