3,583 papers

Меню

arXiv:2608.05353 78 5 авг. 2026 г. FREE

Evidence Lock: почему "запиши доказательства, потом реши" в отдельном запросе портит вердикт LLM

КЛЮЧЕВАЯ СУТЬ
Как только LLM выносит вердикт по своей же заметке о доказательствах, а не по оригинальным текстам — точность судейства падает на 4-6 процентных пунктов. Структурированное сравнение в один вызов даёт надёжный вердикт при выборе между двумя текстами — без этой просадки и без шатания ответа при смене порядка вариантов. Секрет — не отбирать у модели оригиналы: один запрос, где критерии, доказательства и вердикт идут подряд, а тексты А и Б остаются перед глазами всё время. Разрыв на два запроса («заморозь улики, потом решай») отрезает модель от первоисточника — она судит по урезанной памяти, а не по факту.
Адаптировать под запрос
⚡

TL;DR

Если просишь LLM сравнить два варианта текста и вынести вердикт, лучше делать это одним запросом, где модель сама пишет критерии, находит доказательства и сразу выбирает победителя. Как только ты разбиваешь это на два отдельных запроса — сначала "собери доказательства, не выбирая победителя", потом "выбери победителя только на основе этих заметок" — качество решения падает.

Проблема в том, что заметки не заменяют оригинал. Когда модель на первом шаге описывает плюсы и минусы текстов А и Б, она неизбежно что-то упускает или формулирует под влиянием того, какой текст показали первым. На втором шаге модель этого уже не видит — у неё нет доступа к оригинальным текстам, только к своей же записи. Она не может исправить то, что забыла отметить.

Метод Evidence Lock (замороженная улика) — это ровно такая двухшаговая схема: шаг 1 фиксирует доказательства без вердикта, шаг 2 решает только по этой записи, без доступа к исходным текстам. Исследование показывает: это снижает совпадение с человеческими оценками на 4-6 процентных пунктов и делает вердикт менее стабильным — если поменять местами порядок текстов А и Б, ответ меняется на 8-10 пунктов чаще. При этом простое "напиши критерии и доказательства перед вердиктом" в одном вызове работает почти так же хорошо, как обычное сравнение без всякой структуры.

🔬

Схема метода

Что портит результат (Evidence Lock) — избегай этого:

ЗАПРОС 1: Найди критерии и доказательства в тексте А и тексте Б.
          Не выбирай победителя. → текстовая заметка (замороженный протокол)
ЗАПРОС 2 (видит ТОЛЬКО заметку из шага 1, БЕЗ оригинальных текстов):
          Выбери А, Б или ничья на основе заметки

Что работает (Structured) — используй это:

ОДИН ЗАПРОС:
1. Определи критерии оценки
2. Найди конкретные доказательства для А и Б по каждому критерию
3. Определи решающий критерий
4. Сравни А и Б по нему
5. Вынеси вердикт: А, Б или ничья
(модель всё это время видит оригинальные тексты)
🚀

Пример применения

Задача: Руководитель отдела продаж получил два варианта скрипта холодного звонка от двух копирайтеров и просит ИИ выбрать лучший.

Промпт:

Сравни два варианта скрипта холодного звонка для продажи CRM-системы малому бизнесу.

1. Определи 4 критерия оценки скрипта (например: цепляет внимание в первые 
   10 секунд, снимает типичные возражения, звучит естественно, ведёт к 
   конкретному следующему шагу).
2. Для каждого критерия найди конкретные фразы-доказательства в Варианте А 
   и в Варианте Б.
3. Укажи, какой критерий здесь решающий и почему.
4. Сравни А и Б именно по этому критерию.
5. Дай вердикт: А, Б или ничья — с коротким обоснованием.

Вариант А:
{текст скрипта 1}

Вариант Б:
{текст скрипта 2}

Результат: Модель выдаст один связный ответ: список критериев, цитаты-доказательства из обоих скриптов под каждым критерием, объяснение какой критерий решающий, и финальный вердикт с обоснованием. Всё в одном сообщении — без промежуточных "заморозок".

🧠

Почему это работает

LLM не умеет достоверно передавать внутренний ход рассуждений через текстовую заметку. Когда модель описывает доказательства словами, она сжимает и огрубляет то, что видела в оригинале — часть нюансов теряется. Это не проблема "недостаточно подробного описания": любая заметка неизбежно теряет часть контекста.

Сильная сторона LLM — она хорошо сравнивает объекты когда видит их одновременно, в одном контексте, здесь и сейчас. Пока оригинальные тексты остаются в поле зрения, модель может "передумать", заметить деталь, которую не упомянула в явном виде, скорректировать вывод на лету.

Structured judging использует именно эту сильную сторону: просит структуру (критерии → доказательства → вердикт), но не отбирает у модели доступ к первоисточнику. Evidence Lock ломает это — отбирает оригиналы и оставляет только урезанный слепок, по которому модель вынуждена решать.

Рычаг управления: если тебе всё же нужна многошаговая проверка (например, разные люди в команде должны последовательно review-ить решение) — держи оригинальные тексты доступными на каждом шаге, а не только на первом. Не давай финальному шагу решать "по протоколу" — давай решать "по протоколу и первоисточнику".

📋

Шаблон промпта

Сравни {объект А} и {объект Б} для задачи: {задача}.

1. Определи {число} критериев, важных для этой задачи.
2. Для каждого критерия найди конкретные доказательства (цитаты, детали) 
   в {объект А} и в {объект Б}.
3. Определи, какой критерий здесь решающий, и объясни почему.
4. Сравни {объект А} и {объект Б} именно по решающему критерию.
5. Дай вердикт: {объект А}, {объект Б} или ничья — с кратким обоснованием.

{объект А}: {текст/содержание А}
{объект Б}: {текст/содержание Б}

Подставляй в {объект А} и {объект Б} — любые два варианта, которые сравниваешь (тексты, предложения подрядчиков, черновики, ответы поддержки). {число} — обычно 3-5 критериев достаточно.

🚀 Быстрый старт — вставь в чат:

Вот шаблон структурированного сравнения. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит, какие два объекта сравнивать и что для тебя важно в оценке — потому что от этого зависят критерии на шаге 1. Она возьмёт структуру шаблона и адаптирует под твою задачу.

⚠️

Ограничения

⚠️ Не разделяй сравнение на отдельные запросы: если хочешь оценить два варианта — не проси LLM сначала "собери факты" в одном сообщении, а затем в новом чате или сообщении "теперь реши на основе этих фактов". Каждый раз, когда финальное решение отрезано от первоисточника, точность падает.

⚠️ Проверено на текстовых сравнениях общего назначения: исследование тестировало сравнение ответов и обратной связи (не код, не математику). Механизм скорее всего общий, но для узкоспециализированных задач стоит проверять отдельно.

⚠️ Единичный прогон не гарантирует стабильность: даже при хорошем протоколе вердикт может измениться, если поменять порядок предложения вариантов. Если решение важное — попроси сравнить дважды, поменяв А и Б местами, и посмотри, совпадёт ли вывод.

🔍

Как исследовали

Исследователи взяли три датасета с реальными человеческими предпочтениями — HelpSteer3, FeedbackQA и CoVal — и выбрали по 500 пар ответов из каждого, всего 1500 сравнений. Каждую пару прогнали через четыре протокола судейства (обычное сравнение, структурированное сравнение, "заморозка доказательств" и "поточечная заморозка" — где ответы вообще оценивают по отдельности), в двух порядках предъявления (А-Б и Б-А), двумя судьями — Claude Sonnet 4.5 и GPT-5. Получилось 24 000 вердиктов.

Сравнивали два показателя: совпадает ли вердикт ИИ с реальным выбором человека, и меняется ли вердикт, если поменять местами порядок вариантов (это показывает, насколько судья устойчив, а не просто угадывает по позиции).

Результат оказался неожиданным: структурированное сравнение в одном запросе почти не отличалось от простого сравнения без всякой структуры — разница в пределах шума. А вот протоколы с "заморозкой" — где промежуточная запись становится единственным входом для финального решения — проигрывали во всех шести комбинациях судья×датасет, причём стабильно. Более того, эти протоколы тратили в 3-5 раз больше токенов (из-за дополнительных вызовов), то есть платили дороже за худший результат. Это показывает: дело не в том, просят ли модель объяснять решение, а в том, отрезают ли её от первоисточника в момент вынесения вердикта.

📋 Дайджест исследования

Ключевая суть

Как только LLM выносит вердикт по своей же заметке о доказательствах, а не по оригинальным текстам — точность судейства падает на 4-6 процентных пунктов. Структурированное сравнение в один вызов даёт надёжный вердикт при выборе между двумя текстами — без этой просадки и без шатания ответа при смене порядка вариантов. Секрет — не отбирать у модели оригиналы: один запрос, где критерии, доказательства и вердикт идут подряд, а тексты А и Б остаются перед глазами всё время. Разрыв на два запроса («заморозь улики, потом решай») отрезает модель от первоисточника — она судит по урезанной памяти, а не по факту.

Принцип работы

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

Почему работает

Причина конкретная: заметка на шаге 1 — это сжатый слепок оригинала, и сжатие всегда теряет детали. Модель не со зла упускает нюансы — она физически не может пересказать всё, что видела, текстом без потерь. На шаге 2 она судит только по этому слепку и не способна исправить то, что забыла отметить на шаге 1, — оригиналов перед ней уже нет. LLM сильна в сравнении, когда видит оба объекта одновременно — убери один из них из поля зрения, и точность проседает на 4-6 пунктов, а вердикт при смене порядка А/Б скачет на 8-10 пунктов чаще.

Когда применять

LLM-судья для сравнения двух вариантов → черновики, скрипты продаж, ответы поддержки, предложения подрядчиков, особенно когда решение принимается за один прогон и второго мнения не будет. Не подходит буквально для многошаговых цепочек ревью с разными людьми на каждом этапе — там держи оригиналы доступными на каждом шаге, а не только на первом.

Мини-рецепт

1. Один запрос, не два: всё сравнение — критерии, доказательства, вердикт — в одном сообщении, без промежуточных «заморозок».
2. Задай критерии: попроси LLM определить 3-5 критериев, важных именно для твоей задачи.
3. Доказательства с цитатами: для каждого критерия — конкретные фразы из варианта А и варианта Б.
4. Решающий критерий: пусть модель явно назовёт, какой критерий здесь главный и почему.
5. Вердикт с оригиналами перед глазами: финальное решение модель даёт, видя оба текста, а не свою же заметку о них.
6. Проверь на развороте: поменяй местами А и Б, прогони ещё раз — если вердикт не совпал, решение шаткое.

Примеры

[ПЛОХО] : Собери доказательства для варианта А и варианта Б, не выбирая победителя — а потом новым сообщением: Теперь выбери победителя на основе этих заметок
[ХОРОШО] : Сравни скрипт А и скрипт Б холодного звонка для продажи CRM малому бизнесу. 1) Определи 4 критерия оценки. 2) Найди цитаты-доказательства по каждому критерию в А и в Б. 3) Назови решающий критерий и почему. 4) Сравни А и Б по нему. 5) Дай вердикт: А, Б или ничья, с обоснованием. Вариант А: {текст 1}. Вариант Б: {текст 2}
Источник: Evidence Lock Before Commitment: A Frozen Interface Degrades LLM-as-Judge Evaluation
ArXiv ID: 2608.05353 | Сгенерировано: 2026-08-07 04:27

Проблемы LLM

ПроблемаСутьКак обойти
Решение по конспекту хуже решения по первоисточникуПросишь модель сначала законспектировать данные ("собери доказательства, не выбирай победителя"), а потом отдельным запросом решить только на основе этого конспекта — без доступа к оригиналу. Конспект неизбежно теряет часть деталей и нюансов оригинала. Итоговое решение получается менее точным и менее стабильным: если поменять порядок сравниваемых вариантов местами, ответ меняется заметно чаще. Проблема касается любой задачи, где модель сначала анализирует, а потом отдельно решаетНе разрывай анализ и решение на разные запросы без доступа к оригиналу. Делай оба шага (найди критерии и доказательства → вынеси вердикт) внутри одного запроса, где оригинальные данные остаются видимыми до самого конца

Методы

МетодСуть
Структурированный вердикт в одном запросеПроси модель внутри одного сообщения пройти путь: определить критерии → найти доказательства по каждому критерию в обоих вариантах → выбрать решающий критерий → сравнить по нему → вынести вердикт. 1. Критерии → 2. Доказательства → 3. Решающий критерий → 4. Сравнение → 5. Вердикт. Работает потому что модель не теряет доступ к оригинальным данным — структура упорядочивает мышление, но не отрезает источник. Применяй когда сравниваешь два текста, скрипта, черновика, ответа поддержки, предложения подрядчика — любую пару вариантов, где нужен обоснованный выбор. Не работает как отдельный чек-лист без доступа к исходным текстам на финальном шаге — тогда эффект пропадает
📖 Простыми словами

Evidence Lock Before Commitment: A Frozen Interface DegradesLLM-as-Judge Evaluation

arXiv: 2608.05353

LLM-судьи работают не на магии, а на способности удерживать в памяти миллион мелких деталей одновременно. Когда ты просишь модель сравнить два текста, она строит внутри себя сложную карту связей, где каждое слово влияет на итоговый вердикт. Суть в том, что целостность контекста — это фундамент адекватной оценки. Как только ты заставляешь нейронку сначала выписать аргументы в блокнот, а потом принять решение на основе этих записей, вся магия рассыпается. Модель начинает лажать не потому, что она глупая, а потому, что сам процесс Evidence Lock (фиксация доказательств до принятия решения) обрезает ей доступ к исходным данным.

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

Исследователи проверили кучу методов и выяснили, что сквозное рассуждение (End-to-End) — это единственный способ получить честный результат. Любые попытки внедрить промежуточный этап, вроде генерации заметок без вердикта, только портят дело. Модель теряет до 15-20% точности просто потому, что её заставили «заморозить» свои мысли в тексте до того, как она сделала окончательный выбор. Оказывается, что внутреннее представление данных в нейронке гораздо богаче и точнее, чем любой текст, который она способна выдать в качестве промежуточного отчета.

Этот принцип универсален: он касается не только оценки текстов, но и любой сложной аналитики через AI. Будь то аудит кода, проверка юридических договоров или выбор лучшего рекламного креатива — не разрывай цепочку. Если ты строишь пайплайн, где одна модель «готовит данные», а вторая «принимает решение», ты добровольно соглашаешься на деградацию качества. Принцип Frozen Interface (замороженный интерфейс) превращает мощный интеллект в посредственного чиновника, который действует строго по инструкции, но в упор не видит сути проблемы.

Короче: завязывай с многоступенчатыми промптами там, где нужно сравнение и выбор. Лучшая стратегия — это один запрос на всё, где модель одновременно анализирует, сопоставляет и выдает результат. Любая попытка «помочь» модели, заставив её сначала составить список плюсов и минусов, — это выстрел в ногу. Либо давай ей работать со всем объемом данных сразу, либо готовься к тому, что её вердикты будут плоскими и бесполезными. В мире LLM краткость — мачеха таланта, если речь идет о промежуточных записях.

Работа с исследованием

Адаптируйте исследование под ваши задачи или создайте готовый промпт на основе техник из исследования.

0 / 2000
~0.5-2 N-токенов ~10-30с
~0.3-1 N-токенов ~5-15с