Исследователи проверили, способен ли мультиагентный фреймворк MARCH обоснованно выбирать между двумя программными решениями. По данным препринта, опубликованного на arXiv 28 сентября 2026 года, в 78–95% сравнений система признавала оба варианта одинаково хорошими. В одном из приведённых авторами измерений её точность составила 4,4%, тогда как та же языковая модель при прямом вопросе достигла 43,7%.
Работа не предлагает нового рекордного судью для кода. Её задача уже: определить без размеченных правильных ответов, когда у системы вообще есть основания для выбора. Авторы выделили два показателя, извлекаемых из внутренних журналов MARCH, и использовали один из них как фильтр. После этого судья отвечал только примерно на половину сравнений, зато его точность на оставшейся части выросла с 20,7 до 36,9%.
Основной источник этих данных — карточка препринта arXiv. Размещение работы на arXiv само по себе не означает, что результаты прошли независимое рецензирование.
Почему проверка по доказательствам дала сбой
Обычный LLM-судья получает задачу и два ответа, после чего выбирает лучший. Проблема такого подхода в том, что уверенная формулировка не показывает, действительно ли модель нашла ошибку или лишь построила правдоподобное объяснение уже выбранного вердикта.
Мультиагентная верификация должна снижать этот риск. Вместо одного решения система формирует проверяемые утверждения, собирает для них свидетельства и поручает отдельным компонентам оценить, подтверждаются ли эти утверждения. Такой подход применим, например, к ответам, основанным на найденных документах.
Авторы новой работы утверждают, что доказательная база должна отвечать двум условиям:
— не зависеть от ответа, который проверяет судья;
— различаться для двух сравниваемых кандидатов.
При поиске по документам второй критерий часто выполняется естественным образом: разные утверждения могут вести к разным фрагментам источников. В задаче сравнения программ таким источником становится код самих кандидатов. По версии авторов, в этой конфигурации MARCH часто получает недостаточно различимые свидетельства и не может обоснованно предпочесть одно решение другому.
Это важное уточнение: высокий процент ничьих не означает, что два фрагмента кода действительно эквивалентны. Он показывает, что конкретный проверочный процесс не сформировал доказательную базу, достаточную для их различения.
Что показал эксперимент с MARCH
Исследователи запустили опубликованный фреймворк MARCH без модификаций на двух бенчмарках для оценки кода. В аннотации сообщается о более чем 80 измерениях по разным сочетаниям экспериментальных условий.
В зависимости от условия MARCH присваивал одинаковую оценку обоим решениям в 78–95% сравнений. В худшем из приведённых результатов точность составила 4,4%. Для сопоставления авторы задали той же модели прямой вопрос без мультиагентного разложения и получили 43,7%.
Упрощение задач не устранило проблему. Переход к более крупной модели-судье также не изменил основной результат. Это ставит под сомнение распространённое предположение, что качество подобного оценщика можно исправить одним лишь масштабированием модели или добавлением этапов проверки.
Цифры 4,4% и рост с 20,7 до 36,9% относятся к разным описанным измерениям, поэтому их нельзя объединять в одну последовательность «до и после». Аннотация не раскрывает все условия, знаменатели и правила агрегации. Проверять их следует по полной PDF-версии работы, а не только по краткому описанию.
Два сигнала вместо размеченного набора
Авторы нашли в журналах MARCH два показателя, которые объясняют неспособность системы выбрать кандидата. Для их расчёта не требуется заранее знать, какое решение правильное. Это позволяет контролировать судью до получения дорогостоящей ручной разметки.
В доступной аннотации формулы и официальные названия этих показателей не приведены, поэтому трактовать их как универсальные метрики для всех LLM-судей пока нельзя. Подтверждён более узкий вывод: внутренние следы работы MARCH позволяют оценить, сформировала ли система различимую доказательную базу для конкретного сравнения.
Один из показателей авторы превратили в правило допуска. Если значение указывало, что сравнение не обеспечено достаточными основаниями, система не выдавала вердикт. Такой отказ сократил охват примерно вдвое, зато повысил точность среди принятых сравнений с 20,7 до 36,9%.
Это компромисс между покрытием и надёжностью, а не общее улучшение качества модели. Судья не стал лучше решать все задачи: он перестал отвечать на часть примеров, где его решение, по внутреннему сигналу, было бы слабо обосновано.
Как проверить собственный LLM-судья
Для команд, которые используют модели при проверке сгенерированного кода, практический вывод состоит не в обязательном переходе на MARCH. Полезнее проверить, умеет ли существующая система отделять наличие доказательств от уверенности текста.
Минимальный аудит может включать четыре шага:
Сохранять не только итоговую оценку, но также утверждения, найденные свидетельства и связи между ними.
Измерять долю ничьих и одинаковых оценок отдельно от общей точности. Необычно высокая доля совпадений может скрывать неспособность различить кандидатов.
Сравнивать сложный мультиагентный процесс с прямым запросом к той же модели. Дополнительные агенты полезны лишь тогда, когда дают измеримое преимущество при одинаковом тестовом наборе.
Разрешить системе возвращать статус «недостаточно оснований». Такой ответ следует учитывать отдельно от ошибки и успешного выбора.
Для прикладной проверки потребуется закрытый набор задач, где правильность решений установлена тестами или экспертной проверкой. Показатели без разметки могут определить подозрительные случаи, однако сами по себе не доказывают корректность оставшихся вердиктов.
Что пока нельзя считать доказанным
Исследование охватывает два бенчмарка и один мультиагентный фреймворк. Из аннотации нельзя заключить, что тот же диапазон ошибок сохранится у других архитектур, моделей, языков программирования или наборов задач.
Также остаётся открытым вопрос, изменится ли результат при наличии независимых источников: исполняемых тестов, формальной спецификации, трассировки, документации API или результатов статического анализа. Такая информация отличается от кода проверяемого кандидата и потенциально может дать судье более различимые свидетельства.
Наконец, рост точности до 36,9% всё ещё не делает систему достаточно надёжной для автоматического принятия кода. Главный результат работы — не уровень этой цифры, а возможность обнаружить часть сравнений, в которых судье лучше отказаться от ответа.
Библиографические сведения о препринте также доступны через машиночитаемую запись arXiv. Все три ссылки ведут к представлениям одной и той же первичной работы, а не к независимым подтверждениям. До появления рецензии, кода экспериментов или внешнего воспроизведения заявленные результаты следует рассматривать как выводы авторов препринта.
