TL;DR
Слепая проверка — это способ оценивать чужие решения с помощью LLM: судье не показывают метку «совпадает / не совпадает», которую поставила проверяемая система. Модель получает только сами данные, решает задачу с нуля, а её вердикт потом сравнивают с решением системы. Работает как рецензирование вслепую.
Главная находка: если судье показать решение системы и попросить оценить, насколько оно оправдано, он не проверяет, а соглашается задним числом. Самое неприятное: качество оценки может стать хуже монетки. Судья ставит высокие баллы неверным решениям и низкие верным. Причём более сильные модели чувствительнее к метке, чем слабые. Подробная пошаговая инструкция («оцени по 8 шагам») эту проблему не лечит.
Суть метода в два шага: убрать метку из промпта, попросить модель самостоятельно решить, совпадают ли объекты, и дать балл уверенности. Расхождения с решением системы считай подозрительными. На датасетах с узнаваемыми названиями качество проверки вернулось почти к потолку, а на узкоспециальных (медицинские термины) тоже заметно выросло.
Схема метода
ШАГ 1 (отдельный запрос, БЕЗ метки системы):
данные пары → LLM решает сама: MATCH / NON_MATCH + балл 0–10 + ключевые различия
ШАГ 2 (вне LLM — таблица, скрипт или вручную):
вердикт LLM vs решение системы → совпало / не совпало
ШАГ 3: расхождения → на ручную проверку человеку
Шаг 1 выполняется в одном запросе. Метка системы в нём не должна появляться вообще: ни в тексте, ни в примерах, ни в названиях полей.
Пример применения
Задача: Вы продаёте на Ozon и Wildberries. Скрипт склеивает карточки: «это один и тот же товар на двух площадках». Скрипт поставил метку MATCH на пару, где названия почти одинаковые. Нужно проверить, не склеил ли он разные модели.
Промпт (слепой):
Ты — эксперт по каталогам товаров маркетплейсов. Тебе даны две карточки.
Реши самостоятельно, это ОДИН И ТОТ ЖЕ товар (одна и та же модель,
объём/память, комплектация) или РАЗНЫЕ товары.
Карточка A (Ozon):
Название: Смартфон Apple iPhone 15 128GB, чёрный
Бренд: Apple
Артикул производителя: MTLH3
Цена: 71 990 ₽
Карточка B (Wildberries):
Название: Apple iPhone 15 Pro 128 ГБ, чёрный титан
Бренд: Apple
Артикул производителя: MTUV3
Цена: 94 500 ₽
Правила:
- Сходство названий само по себе НЕ доказательство. Ищи различия в модели,
объёме, артикуле, комплектации.
- Если данных недостаточно, так и скажи.
Ответь в формате:
1. Ключевые совпадения (списком)
2. Ключевые различия (списком)
3. Вердикт: MATCH или NON_MATCH
4. Уверенность в том, что это один товар, от 0 до 10
Результат: Модель выдаст короткий разбор: что совпало (бренд, цвет, память), что различается (линейка Pro и обычная, артикулы, разница в цене). Затем вердикт и балл уверенности. Этот вердикт вы сравниваете с меткой скрипта. Если скрипт сказал MATCH, а слепой судья — NON_MATCH с низким баллом, пару нужно разобрать вручную.
Почему это работает
Слабость. Когда судья видит решение системы, оно превращается в готовый вывод, который нужно обосновать. Модель генерирует текст, согласованный с контекстом, поэтому ищет доводы в пользу показанной метки. Авторы называют это anchor bias (эффект привязки). Вместо оценки получается эхо. Плюс модели доверяют знакомым названиям: пара «The Fast and the Furious» (фильм 2001 года и вся франшиза) выглядит одинаковой, хотя это разные сущности.
Сильная сторона. Когда модель просто решает задачу («один и тот же объект или нет») без чужого ответа перед глазами, она неплохо взвешивает совпадения и различия. Задача для неё обычная, как в любой классификации.
Как метод это использует. Мы разделяем «решить» и «сравнить с решением системы». Сравнение делает таблица или человек, а модель в нём не участвует. Привязываться ей не к чему.
Рычаги управления: - Балл 0–10 → оставь, если нужно ранжировать сомнительные пары. Убери, если нужен только вердикт. - Блок «ключевые различия» → оставь для разбора спорных случаев и для ручной проверки. Убери для экономии токенов на больших объёмах. - Правило «сходство названий — не доказательство» → моё добавление, в статье его нет. Помогает против ловушки «одно имя, разные сущности»; проверь на своих данных. - Порог расхождения → выбери сам: например, отправлять человеку только пары, где вердикт расходится с системой или балл от 3 до 7.
Шаблон промпта
Ты — {роль_эксперта}. Тебе даны два объекта из разных источников.
Реши самостоятельно, это ОДИН И ТОТ ЖЕ {тип_сущности} или РАЗНЫЕ.
Объект A ({источник_A}):
{данные_A}
Объект B ({источник_B}):
{данные_B}
Правила:
- Сходство названий само по себе не доказательство.
- Ищи различия в: {на_что_смотреть}.
- Если данных недостаточно, так и скажи.
Ответь в формате:
1. Ключевые совпадения
2. Ключевые различия
3. Вердикт: MATCH или NON_MATCH
4. Уверенность от 0 до 10 в том, что это один и тот же {тип_сущности}
Что подставлять: {тип_сущности} — товар, компания, клиент, термин, документ. {на_что_смотреть} — признаки, по которым объекты реально отличаются в вашей области (ИНН и КПП, артикул, версия, дата).
Главное правило: в промпте нет решения системы, нет слов «система считает» и нет примеров с проставленной меткой. Шаблон — моя реконструкция по описанию протокола (в статье он обозначен как Prompt III), не дословная копия.
🚀 Быстрый старт — вставь в чат:
Вот шаблон слепой проверки решений. Адаптируй под мою задачу: {опиши, что
проверяешь: сопоставление товаров, дубли клиентов, классификацию и т.п.}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие объекты сравниваются, из каких источников и по каким признакам они реально отличаются. Это нужно, чтобы промпт не содержал решения системы, но давал модели правильные критерии для самостоятельной оценки.
Ограничения
⚠️ Подробные инструкции не спасают: если метку оставить, но добавить длинную инструкцию «оцени по 8 шагам, опираясь только на данные», привязка к метке остаётся. Авторы подчёркивают, что рассуждение по шагам (Chain-of-Thought) эту проблему не решает. Убрать нужно саму метку.
⚠️ Сильнее модель ≠ надёжнее судья: более мощные модели сильнее реагируют на метку. «Возьму модель получше» не защита.
⚠️ Незнакомые области: в узких доменах (в статье — медицинские онтологии) модель опирается на узнаваемость названий. Когда названия скрыты, у неё массово рушатся оценки. Слепой режим там тоже заметно помогает, но потолка не достигает, и ему нужна человеческая проверка.
⚠️ Ловушка «то же имя»: даже слепая модель может принять фильм и франшизу с одним названием за одно и то же. Явные критерии различий в промпте и контроль человеком на спорных парах обязательны.
⚠️ Это проверка предсказанием: вы измеряете, согласна ли независимая модель с системой, а не «насколько система права». Если модель ошибается сама, расхождения тоже будут шумом. Нужна небольшая выборка, размеченная человеком, чтобы проверить сам слепой судья.
⚠️ Текст статьи обрезан: я видел описание методов и выводы из аннотации и введения, но не весь раздел результатов и приложения. Точные формулировки промптов авторов в этом тексте отсутствуют.
Как исследовали
Авторы взяли три модели-судьи (GPT-4o-mini, GPT-4o и Claude Opus 4.7) и три набора пар сущностей из разных баз знаний. Два набора общие (DBpedia с Wikidata и с YAGO), третий — новый биомедицинский (MeSH и SNOMED CT, 15 тысяч пар). Проверяли четыре системы сопоставления. Всего сделали около 153 тысяч запросов, потратили порядка 577 долларов.
Идея была в три хода. Сначала возмущения: скрывали названия сущностей и смотрели, на что опирается судья. Затем три режима промпта: подробный (8 шагов рассуждения), минимальный и слепой, без метки. Качество считали как вероятность того, что у верного решения балл выше, чем у неверного. Значение ниже 0.5 хуже монетки. Наконец, контрфактуальный тест: те же данные, но метка системы перевёрнута. Если балл следует за меткой, виновата метка. Баллы менялись больше чем на 2 пункта у 53–99% пар.
Результат: с видимой меткой качество упало до 0.12–0.87, то есть местами судья оценивал наоборот. Слепой режим вернул 0.93–1.00 на общих датасетах и 0.93–0.95 на биомедицинском. Удивило, что сильные модели оказались чувствительнее к метке. Для проверки два автора вслепую разметили 102 пары (согласие очень высокое). Для пар «совпадает» корреляция моделей с людьми при видимой метке была слабой (0.23–0.41). Практический вывод: убирай метку, не усложняй инструкцию.
Адаптации и экстраполяции
Это не из статьи, а мои переносы принципа. Проверяйте на своих задачах.
🔧 Техника: убрать метку → слепой ревьюер. Любому LLM-ревьюеру давай только материал, а не вывод автора.
Ты — независимый рецензент. Ниже дан только исходный материал: {материал}.
Сам реши, какой вывод верен, и обоснуй. Вывода автора ты не видишь.
Затем сравни свой вердикт с выводом автора. Расхождение — сигнал для проверки.
🔧 Техника: разделить роли в агентной цепочке. Если у вас агент-исполнитель и агент-ревьюер (например, в Claude Code), в инструкции ревьюера пропишите: «Не читай описание изменений и сообщение коммита автора. Смотри только на дифф и тесты». Это тот же принцип: ревьюеру не показывают метку «всё верно». Статья агентов не тестировала.
🔧 Техника: выборочная ручная проверка. Отправляй человеку только пары, где слепой вердикт расходится с системой или балл уверенности 3–7. Так экономится разметка, но калибровку на небольшой размеченной выборке всё равно сделайте.
Ресурсы
- Статья: Reliability of LLM Judges for Evaluating Entity Alignment
- Авторы: Vaibhava Lakshmi Ravideshik (University of Michigan, Ann Arbor) и Mayank Kejriwal (Information Sciences Institute, University of Southern California)
- Код и данные: https://github.com/vaibhavalakshmiravideshik/llm-as-a-judge-entity-alignment
- Бенчмарк: MeSH × SNOMED CT (15 тысяч пар); доступ к части SNOMED CT требует лицензии UMLS
- Упомянутые связанные работы: GSM-Symbolic (Mirzadeh et al., 2025), O'Leary (2025) об эффекте привязки у ChatGPT, Claude, Gemini