Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
LLM стала лучше проверять собственные отчёты, таблицы и другие результаты длинных задач, хотя более сильной модели и готовых ответов у неё не было. В работе Google Cloud AI Research и University of Cambridge, которая не прошла рецензирование и приводит замеры самих авторов, VeriHarness лучше всех сравниваемых методов выбирал удачный результат на каждом тестовом наборе. Для продуктовой команды это сдвигает вопрос с «какую модель поставить судьёй» на «какие доказательства и процедуры проверки дать текущей модели».
Общее мнение прогонов тоже приходится проверять
Обычное масштабирование во время выполнения запускает задачу несколько раз, а затем выбирает самый частый или самый убедительный ответ. Для длинных задач этого мало: разные прогоны могут независимо повторить одну ошибку, а редкий вариант — оказаться верным.
На APEX-Agents неверными оказались 34% утверждений, с которыми согласились все прогоны. Среди спорных утверждений правильный вариант встречался в 74% случаев, но самый частый ответ был верен лишь в 47%. Значит, голосование отбрасывает часть полезных альтернатив, а единодушие скрывает систематические ошибки.
VeriHarness поэтому делит проверку на две разные работы. Первая разбирает расхождения: находит конкурирующие значения, прослеживает их до исходных файлов или вычислений и выбирает проверку, которая лучше всего различит варианты. Если доказательство опровергает все ответы, система либо выводит исправленное значение из источника, либо помечает вопрос как нерешённый.
Вторая работа намеренно спорит с общим мнением. Она заново считает показатели, сверяет подписи с метаданными, проверяет трактовку требований и ищет пункты, которые пропустили все кандидаты. Это принципиальное отличие от модели-оценщика, которая только читает готовые результаты и выставляет им баллы.
Как модель собирает доказательства и пересобирает результат
VeriHarness не меняет веса модели. Он добавляет вокруг неё рабочее пространство, инструменты для получения доказательств, протокол проверки и библиотеку навыков. В рабочем пространстве лежат итоговые файлы каждого прогона, состояние среды, история действий, исходные данные и требования задачи.
Инструменты позволяют открыть источник, проверить версию документа, пересчитать формулу, выполнить код или изучить свойства файла. Навык описывает не само действие, а типичную причину ошибки и способ её обнаружить. Например, он может потребовать сверить период в названии показателя с годами, которые использует формула.
Разбор расхождений и проверка единодушных утверждений идут в отдельных контекстах. Благодаря этому спорные детали не вытесняют поиск общей ошибки. Затем новый контекст получает оба журнала доказательств, выбирает наиболее пригодный исходный результат и составляет план исправлений.
Этот последний этап важен: система не ограничивается выбором одного готового ответа. Она может взять лучший кандидат за основу, заменить опровергнутые значения, добавить пропущенное требование и вернуть пересобранный файл. Каждое изменение связывается с утверждением, выполненной проверкой, найденным доказательством и итоговым решением; неразрешённые вопросы остаются явно отмеченными.
Библиотека навыков может расти без дополнительного обучения модели. На задачах для разработки система сопоставляет собственный журнал с обратной связью внешнего проверяющего, превращает повторяющиеся промахи в новые процедуры и допускает их в библиотеку после проверки. Так контур запоминает не ответы на конкретные задания, а способы искать ошибки в документах, таблицах и вычислениях.
Когда стоит менять архитектуру продукта
Метод проверяли на пяти наборах длинных рабочих задач и двух моделях — Gemini 3.5 Flash и Claude Opus 4.8. Они создавали и проверяли документы, таблицы, код и наборы связанных файлов. Все сравниваемые методы получали один и тот же заранее собранный пул из десяти прогонов, а эталонные ответы и правила внешней оценки во время проверки были скрыты.
После выбора и исправления результата средняя прибавка относительно одиночного прогона составила 6,2 балла для Gemini 3.5 Flash и 6,4 балла для Claude Opus 4.8. Это показывает эффект на заданных тестах, но не гарантирует такую же прибавку в производственном процессе с другими файлами, инструментами и требованиями.
Работа меняет планы команд, у которых уже есть сильная базовая модель, но нет более сильной модели-судьи. Вместо немедленной замены LLM можно сначала добавить несколько независимых прогонов, сохранить доступ к исходной среде и разделить проверку на поиск расхождений и атаку на общее мнение. Особенно естественно это выглядит для результатов, которые можно подтвердить файлами, формулами, метаданными или выполнением кода.
Цена такого подхода — дополнительные вызовы модели и многошаговая проверка. Он рассчитан скорее на отчёты, рабочие книги, патчи и другие результаты, где качество важнее минимальной задержки, чем на интерактивные ответы. Для первого прототипа полезнее ограничить набор проверок самыми дорогими ошибками продукта, чем сразу воспроизводить весь исследовательский контур.
Источники
Иллюстрация: рисунок из статьи «VeriHarness: Scaling Agentic Verification for Long-Horizon Tasks», Caiqi Zhang, Rujun Han, Zifeng Wang и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
