Reasoning Jury: как жюри LLM оценивает длинные цепочки рассуждений

Reasoning Jury — это система, где вместо одного LLM-судьи работает жюри моделей с модератором: они обсуждают дефекты в длинных reasoning traces, пересматривают голоса и выносят консенсус по серьёзности ошибок. Такой подход даёт более точную оценку рассуждений при доле стоимости 8–15% от одиночного frontier-судьи — и это критично для курирования данных, RL-сигналов и runtime-обратной связи.

Я давно смотрю на то, как команды улучшают reasoning LLM: без честной оценки длинных цепочек рассуждений не собрать нормальный датасет, не дать сильный сигнал в reinforcement learning и не понять, где модель реально ломается на бенчмарках. Плюс в рантайме хочется ловить логические сбои и подсказывать модели, пока ответ ещё не ушёл пользователю.

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

У chain-of-thought моделей ответ может выглядеть убедительно, хотя ошибка сидит в середине цепочки. Поверхностная проверка финального вывода не ловит частичные логические разрывы: модель могла «дотянуть» правильный ответ из неверной логики.

Чем длиннее трейс, тем выше шанс, что судья устанет и согласится с правдоподобным текстом. Для data curation это означает загрязнение обучающей выборки: плохие рассуждения попадают в RL как «хорошие».

Даже сильные модели в режиме LLM-as-a-judge систематически недооценивают серьёзность дефектов или одобряют красиво написанные, но фактически битые цепочки. Они хороши на коротких задачах, но на длинных reasoning traces точность падает заметно.

Для продуктовых команд это боль: нельзя строить пайплайн курирования данных только на одном судье и ждать стабильного качества. Нужен механизм перекрёстной проверки — как ревью в инженерной команде.

При онлайн-обучении reasoning-моделей хочется сильный reward signal от умного судьи. Но proprietary frontier API часто запрещает такое использование: terms of use, rate limits, запрет на дистилляцию сигнала. Команды вынуждены искать open-weight альтернативы, которые при одиночной оценке слабее.

Reasoning Jury как раз закрывает этот разрыв: жюри из open-weight моделей (например, gpt-oss-120b) может обогнать одиночный frontier-судью по точности обнаружения дефектов — и при этом остаётся в рамках допустимого использования.

В Reasoning Jury несколько LLM-«присяжных» сначала выносят начальные вердикты по дефектам трейса и их severity. Затем модератор ведёт раунд обсуждения: присяжные критикуют суждения друг друга и могут изменить голос.

Финальный консенсус формируется либо через настоящую дебатную фазу, либо через консолидацию разногласий модератором. На выходе — структурированная карта дефектов, а не один бинарный «ок/не ок».

Для меня это ближе к инженерному code review, чем к классическому LLM-as-a-judge: несколько независимых взглядов плюс процедура согласования.

В экспериментах жюри из open-weight моделей статистически точнее определяет reasoning defects, чем одиночные frontier-судьи уровня opus-4.6, sonnet-4.6 и gemini-3.1-pro. При этом суммарная стоимость всех этапов — начальные вердикты, дебаты, консолидация — составляет примерно 8–15% от прогона одного frontier в классическом judge-setup.

Для продакшн-пайплайнов это меняет экономику: можно чаще и дешевле прогонять глубокую оценку длинных трейсов, не сжигая бюджет на API топовых моделей.

Агрегированные вердикты жюри можно использовать не только как фильтр данных, но и как карту failure modes: где модель систематически срывается на конкретных типах задач, какие классы ошибок повторяются, как severity распределяется по длине трейса.

Это глубже, чем смотреть только accuracy: видно не «сколько правильно», а «где и почему ломается рассуждение».

Чем Reasoning Jury отличается от обычного LLM-as-a-judge? Один судья даёт один вердикт; жюри проходит раунд взаимной критики под модератором и выносит консенсус по дефектам и их серьёзности.

Можно ли использовать только open-weight модели? Да, и в работе показано, что такое жюри может превосходить одиночный frontier по качеству оценки reasoning traces.

Где это применять на практике? Курирование reasoning-датасетов, reward в RL, runtime feedback пользователю и разбор провалов на бенчмарках.

Сколько это стоит относительно frontier-судьи? Ориентир из статьи — 8–15% суммарной стоимости одиночного frontier judge при более высокой точности на дефектах.