Ламповый тест на верифицируемость при проектировании агентов

Кратко

Прежде чем тратить больше вычислительных ресурсов на вашего агента, задайте себе этот вопрос: способен ли ваш агент проверить свой собственный результат (т.е. может ли он распознать, когда получил правильный ответ)? Для некоторых задач верифицируемость очевидна: задача предоставляет условия, по которым можно проверить кандидатов и принять решение об остановке. Для других это менее ясно. В этой статье мы обсуждаем, почему именно это свойство — верифицируемость — должно определять, куда вы направите свой бюджет в следующий раз: на верификацию, если результат можно проверить, или на разнообразие и агрегацию, если нет.

Аргументы против стратегии «сначала масштабирование»

Опросите большинство инженеров о том, как улучшить агента, и большинство скажет: масштабируйте его. Больше попыток, более длинный и расширенный контекст, более мощная модель. Это предполагает, что текущая архитектура уже верна, просто ей не хватает мощности. В большинстве случаев масштабирование работает. Но это дорогой путь.

За год исследований по оптимизации агентов мы снова и снова убеждались, почему это предположение (правильная архитектура, недостаточно мощности) ошибочно. Признаком этого является обнаружение неэффективности в архитектуре: применение единого бюджета к разным задачам, генерация сигналов и прогонов только для того, чтобы их отбросить, использование передовой модели, когда открытая модель справилась бы не хуже. Каждый из этих моментов указывает на то, что есть возможности для дальнейшей оптимизации архитектуры агента перед масштабированием.

Существует простая лакмусовая бумажка: можно ли проверить кандидата хоть на что-то? Это свойство задачи, и оно определяет выбор вашей архитектуры. Если да — инвестируйте в верификацию и отбор. Если нет — инвестируйте в разнообразие и агрегацию.

Затем второй вопрос, касающийся вашего конвейера, а не задачи: использует ли он уже доступную ему проверку? На него мы отвечаем с помощью эксперимента с оракулом.

Механизм верификации дает вам одно преимущество: право выбрать одного кандидата и отбросить остальные. Когда вы не можете создать такой механизм, разнообразие и агрегация становятся заменой: запускайте различные попытки, а затем объединяйте их, потому что без проверки вы не можете безопасно выбрать какой-то один вариант.

В этой статье мы используем эту лакмусовую бумажку для анализа конвейеров агентов в четырех областях — агентный поиск, глубокие исследования, индексация RAG и агентное программирование — используя наши ответы для оптимизации существующей архитектуры и повышения производительности в каждой из них.

Задача №1: Агентный поиск

Может ли агент определить, когда у него есть правильный ответ? Да. Ответ представляет собой единую сущность, а условия явны.

Вопрос для многошагового агентного поиска определяет свой ответ через условия, и ответом является одна короткая сущность, например, имя человека. Именно эта форма делает проверку эффективной. Верификация одной сущности на соответствие заданным условиям охватывает гораздо более узкое пространство, чем исходный поиск.

Измените форму, и ответ изменится вместе с ней. Попросите вместо этого найти всех лауреатов Нобелевской премии, чьи матери не закончили среднюю школу, и каждого найденного кандидата все еще можно проверить, но узнать, нашли ли вы их всех, невозможно, потому что подтверждение полноты означает повторный запуск поиска. Точность остается верифицируемой, а полнота — нет. Это же разделение возвращается в задаче №4.

Прежде чем что-либо строить, мы провели эксперимент с оракулом: мы сделали выбор на основе эталонных ответов, создав потолок, который не могла бы преодолеть ни одна система реального времени, поскольку ни одна реальная система на самом деле не видит эти ответы. Это легко сделать, и это быстро отсеивает стратегии. Например, мы увидели, что показатель pass@k значительно выше pass@1, что говорит о том, что правильный ответ регулярно появляется среди множества попыток, однако любая отдельная попытка обычно не является той, которая его находит.

Знание того, что ответы уже были в пуле — просто не были выбраны — помогло нам сосредоточиться на верификации. Мы демонстрируем два способа улучшения сигналов верификации, платя только тогда, когда качество того стоит:

Бесплатный сигнал, ожидающий использования. В BrowseComp-Plus собственные показатели уверенности моделей достаточно хорошо отслеживают точность после калибровки, чтобы сделать выбор. В сочетании с ансамблем моделей, которые ошибаются на разных запросах, это позволило достичь точности 95,18% и современного уровня (SOTA).

Сигнал, за который стоит платить. Уверенность — это самооценка, поэтому она не добавляет новых доказательств о мире, а модели вполне способны ошибаться и быть уверенными одновременно. Это допустимо, когда генераторы сильны и хорошо откалиброваны.

Мы увидели это при тестировании ансамблей небольших моделей на FACTS-Search. Оказывается, небольшие модели часто выдают неправильные ответы — проблема, которую мажоритарное голосование не может решить, пока неправильный ответ является популярным. Поэтому вместо этого мы заменили показатели уверенности независимым верификатором, который заново исследует каждого кандидата с нуля и накладывает вето на неправильные.

Обучив наш собственный верификатор на 8 млрд параметров, мы сравнялись по качеству с передовым верификатором на ансамбле из открытых и закрытых моделей — при стоимости в 3,2 раза ниже. Применив тот же верификатор к ансамблю, состоящему только из моделей с открытым исходным кодом, мы повысили точность на 28% по сравнению с обычным мажоритарным голосованием на идентичных кандидатах — это более 80% от того, что получил передовой верификатор на этом же пуле, примерно за 1/100 цены.

Задача №2: Глубокие исследования

Может ли агент определить, когда у него есть правильный ответ? Нет. Невозможно узнать, что должен содержать полный отчет.

Задача глубокого исследования требует от агента изучения открытого вопроса и подготовки отчета. То, что делает отчет хорошим, — это охват: набор релевантных фактов, выводов и оговорок, которые он раскрывает. Никто не может записать этот набор заранее. Сравните с задачей №1, где условия самого вопроса были перечислением; здесь цель — это набор, который никто не может перечислить до завершения работы.

Это разделяет задачу на две части. Любое отдельное утверждение в отчете можно проверить, так же как можно было проверить каждое имя в том нобелевском списке. Является ли отчет полным — нет, потому что подтверждение полноты означает повторное проведение исследования. Точность выживает, охват — нет, а именно по охвату судят об отчете.

DeepResearch Bench II делает это конкретным: он оценивает отчеты по длинному списку критериев, написанных экспертами, с большим весом для конкретных фактов, которые должен содержать ответ. Пункты остаются скрытыми до оценки, но скрытность — не главная проблема. В производстве вы бы с радостью предоставили модели критерии. Суть в том, что список должен был быть составлен экспертами постфактум, потому что не было способа составить его заранее. В производстве списка вообще нет.

Поэтому ни один верификатор не может ранжировать один отчет выше другого по метрике, которая имеет значение. Разнообразие и агрегация должны были стать нашей стратегией здесь, и в этом суть: они не альтернатива верификации, они — запасной вариант.

Поэтому мы провели несколько экспериментов с оракулом, на этот раз с двумя стратегиями:

• Отбор, ход, который сработал в задаче №1, означает сохранение одного лучшего отчета и отбрасывание остальных. Даже с оракулом-селектором потолок оказался ниже современного уровня, что подтверждает наш предыдущий вывод: без проверки выбор одного кандидата проигрывает.
• Объединение означает взятие нескольких отчетов и объединение их фактов в один; с оракулом-объединителем потолок комфортно превзошел SOTA.

Разрыв между двумя показателями — полученным в результате объединения и опубликованным SOTA — указывал на то, что нужные факты уже были в наличии, просто они были разрознены.

Поэтому мы создали конвейер, который собирал их все в одном месте. Используя разработанный нами алгоритм, мы объединили отчеты семи агентов с низким рейтингом из таблицы лидеров, так что один отчет унаследовал факты от всех них. Этот объединенный отчет занял первое место, обойдя каждого агента, который его создал, и превзойдя предыдущий уровень развития технологий (SOTA).

Задача №3: Индексация RAG

Может ли агент определить, когда у него есть правильный ответ? Нет, и он еще не знает, о чем его спросят.

Индексация представляет собой, пожалуй, одну из самых больших проблем для верифицируемости, потому что решение — какой размер чанка выбрать? — должно быть принято заранее, до того, как будет задан какой-либо вопрос. Руководство по политике должно отвечать как на вопрос «каков точный срок уведомления в разделе 4.2», так и на вопрос «могу ли я включить в расходы ужин с клиентом». На первый вопрос отвечает одна строка. На второй можно ответить, только объединив несколько правил из другого конца документа, ни одно из которых само по себе не является ответом. Фиксация на одном размере чанка оставляет 20-40% полноты поиска (recall) неиспользованными.

Это тот случай, когда нам нужно разнообразие. Да, индексация с разным разрешением требует больше места для хранения и большего количества запросов (fan-out), но это правильный компромисс (можете ли вы представить себе службу поддержки, которая отказывается от получения правильного ответа ради экономии?). Невозможность верификации не всегда означает необходимость тратить меньше.

Задача №4: Агентное программирование

Может ли агент определить, когда у него есть правильный ответ? В конце — да, в процессе — нет.

Верификация для задачи программирования сложна, поэтому это одновременно и самый полезный кейс, и наиболее часто неправильно понимаемый.

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

Поэтому, хотя конечные условия бинарны, промежуточный процесс ограничен покрытием — из-за чего агенты программирования во многом напоминают проблемы полноты поиска (или глубокого исследовательского отчета). Мы видели это в наших экспериментах: подача потенциальных патчей в контекстный поиск, а не только описания проблемы, сделала конвейер гораздо более эффективным в поиске каждого релевантного файла. Когда мы это сделали, доля проблем, где агент пропускал все релевантные файлы, упала с 9,3% до 2,7%, что дало прирост в 3,2 пункта к коэффициенту решения. Большой прирост полноты поиска при лишь скромном приросте точности — это признак того, что неверифицируемый шаг рассматривается как верифицируемый.

Чтобы сопоставить каждый шаг с его потенциалом верифицируемости, мы распределили задачи по-разному. Младшие модели (open-source MiniMax-M3) параллельно сканируют репозиторий, охватывая то, что никто не может подтвердить как покрытое. Старшая модель (GPT-5.2) дистиллирует их попытки в то, от чего зависит исправление. Только после этого основная модель (frontier model) пишет патч один раз, в тот самый момент, когда существует подлинная проверка: 80,8% коэффициент решения на SWE-Bench Pro, уровень SOTA, при стоимости $5,99 за задачу против $18,28 для автономного агента frontier, который показывает более низкие результаты.

Резюме

Каждый из этих пунктов начинался с дешевого измерения, а не с более крупной модели: сравнение pass@k с pass@1, оценка стоимости верификатора против генератора, подсчет рубрик, проведение эксперимента с оракулом. Модели будут продолжать совершенствоваться, но это не изменит главного: способность агента распознавать собственный успех — это свойство задачи, а не модели, которая ее выполняет. Спросите об этом в первую очередь. А затем решите, нужно ли вам масштабирование.

Благодарности

Этот блог основан на исследованиях Ади Эльбаза, Эрана Голдштейна, Тамар Леви Лободы, Нива Гранота, Ассафа Гернера, Эли Лепкифкера, Одеда Авраама, Гая Рефаэли, Гая Фройнда, Алана Арази, Идо Вайсса и Рои Хенделя. Огромное спасибо Джоанне Крамер за редактирование.