Вкратце
В агентном поиске небольшие модели обычно дают правильный ответ, но не могут его выбрать. Мажоритарное голосование не может это исправить, потому что оно не может отменить популярный неправильный ответ. Добавление независимого проверяющего, который повторно исследует каждого кандидата и отклоняет неправильные ответы, превосходит опубликованный SOTA на FACTS-Search, и как только вы обучите своего собственного 8B проверяющего, это почти ничего не стоит, работает с любой пулом генераторов и обобщается на новый эталон и инструмент поиска.
Стандартный способ повысить точность агентной системы — купить лучший генератор, то есть модель-фронтир. Это работает, но это самый дорогой доступный вариант.
В этом посте приводится другой аргумент: то, как вы запускаете свои модели, важнее, чем какая модель вы запускаете. Система ниже добавляет важный компонент к любой архитектуре ИИ: проверяющего. Этот компонент повышает производительность любой архитектуры, будь то ансамбль моделей-фронтиров или эффективных моделей с открытым исходным кодом.
Почему агентному поиску нужен проверяющий
Ваш эффективный агент, вероятно, уже нашел правильный ответ. Проблема в том, что он не выбрал его.
Запуски моделей не являются детерминированными. Один и тот же агент, один и тот же вопрос, не удается в одной попытке и удается в следующей. Во всех генераторах, которые мы протестировали, pass@k значительно выше точности в один выстрел (pass@1): правильные ответы регулярно присутствуют в пуле и просто не выбираются. Таким образом, ограничивающим фактором для агентного поиска является выбор, а не генерация.
Выбор поддается решению, потому что проверка проще, чем генерация (по крайней мере для агентного поиска QA). Ответить на вопрос «Какая группа сыграла ‘Johnny Come Lately’ на альбоме Стива Эрла, который включает ‘Little Sister’?” требует цепочки поисков, тупиковых ситуаций и синтеза. Проверка предложенного ответа гораздо уже: исследуйте одно утверждение и примите решение по нему.
Так почему бы просто не использовать мажоритарное голосование при использовании ансамбля? Потому что голосование не может отменить популярный неправильный ответ. Когда половина пула уверенно повторяет одно и то же неправильное утверждение, голосование не фильтрует ошибку, а сертифицирует ее. Эффективные пулы чаще всего терпят неудачу таким образом, потому что правильные ответы менее часты.
Проверка работает
Во-первых, проигнорируйте стоимость и запустите лучший доступный проверяющий.
Мы работаем над FACTS-Search, эталоном Google DeepMind для сложных многопрыжковых фактических вопросов, которые требуют веб-поиска для ответа. Каждая модель в этом посте, генератор или проверяющий, использует один и тот же API Brave Search, поэтому измеряемые различия — это навыки модели, а не инструментарий.
Ансамбль генераторов из моделей с закрытым и открытым исходным кодом (Claude Haiku, Sonnet, Opus, Qwen3-Coder-30B-A3B при k=4) набрал 83,3 по простому мажоритарному голосованию и 93,4 с проверяющим Claude Opus сверху, что превосходит опубликованный уровень передовых технологий 89,4 (GPT-5.6 Sol), как видно на Рисунке 1.
Запас больше в малом конце
Фронтир-на-фронтире доказывает механизм. Режим, который имеет значение на практике, — это небольшие генераторы, и там запас растет, а не уменьшается: более шумный пул все равно выводит правильные ответы, они просто outnumber, что именно тогда, когда их идентификация окупается.
Наш полностью открытый пул (Qwen3-14B и Qwen3-Coder-30B-A3B при k=4) голосует за 60,1. Добавьте проверяющего Claude Opus к тем же кандидатам, и он наберет 80,4 при стоимости 1,76 доллара за вопрос. Двадцать очков уже находятся в пуле, ждут проверяющего, достаточно хорошего, чтобы претендовать на них.
Проверяющий — это дорогая часть, поэтому мы обучили своего собственного
Фронтир-проверяющий выполняет полный цикл веб-исследований для каждого кандидата: k выборок умножить на количество генераторов, шестнадцать циклов на вопрос в нашей лучшей конфигурации. Это стоит дороже, чем генерировать все, что он проверяет: результат 93,4 стоит 4,26 доллара за вопрос, большая часть из которых — проверяющий.
Очевидное решение — небольшой открытый проверяющий, и оно не работает. Стандартный проверяющий Qwen3-8B повышает эффективность пула с 60,1 до 62,5. Плюс 2,4 очка против Opus’s plus 20,3 на тех же кандидатах. Этот 18-очковый разрыв — проблема обучения: навык проверки не приходит бесплатно с параметрами.
Обучение
Учитывая вопрос и кандидатский ответ, проверяющий запускает свой собственный цикл Brave-search ReAct и выдает одно решение. Награда — это бинарное точное совпадение с эталонной меткой, поэтому она полностью проверяема, без модели награды. Обучающие данные — это около 6K (вопрос, ответ, VALID/NOT_VALID) троек из генеративных роллов, дедуплицированных, сбалансированных по классам и разделенных на уровне вопросов.
Рецепт — SFT, затем RL, по той же причине, что и у DeepSeek-R1: RL с холодного старта не имеет компетентной политики для исследования. Два режима сбоя здесь специфичны для проверки. RL в одиночку reward-хакит классовый дисбаланс, при этом скорость использования инструментов падает с 94% до 0% за девять шагов. Сбалансировка данных закрывает этот шорткат, но не основную проблему: политика закрепляется в одном узком поведении поиска и не может выйти из него, поэтому качество поиска стабилизируется там, где холодный старт случайно приземляется. SFT в одиночку учит навык поиска и размывает решение, потому что имитация распределяет свою потерю по каждому токену длинного траектория, в то время как сигнал проверки живет в одном токене. В композиции использование инструментов остается высоким и становится адаптивным, а решение становится более резким, не приводя к коллапсу политики.
Измерение чего-либо из этого требует двух вещей. Повторный запуск полного цикла для каждой контрольной точки слишком медленный, поэтому варианты проверяющего оцениваются офлайн против фиксированного пула предварительно сгенерированных роллов: кандидаты никогда не меняются, меняется только судья. И метрики должны вычисляться на уровне вопроса, а затем усредняться, потому что метрики решения на уровне ролла (точность, точность, полнота, F1) регулярно улучшались, в то время как система становилась хуже. Мы отслеживаем четыре величины (Рисунок 4): pass@1 и pass@k, один случайный выбор и потолок оракула без проверяющего, и pass@1(v) и pass@k(v), те же две величины только для проверенных кандидатов. Три пробела распределяют вину — два на проверяющего, один на агрегатор:
- Повысивание проверки := pass@1(v) − pass@1 — это точность проверяющего: максимизируйте ее.
- Запас агрегатора := pass@k(v) − pass@1(v) — это то, что более умный агрегатор все еще может восстановить из проверенных кандидатов — отдельная тема, которой мы здесь не занимаемся.
- Предел полноты := pass@k − pass@k(v) — это доля решаемых вопросов, где проверяющий отклонил каждый правильный ответ: минимизируйте ее.
Результаты
100-вопросный публичный тестовый выбор, официальная оценка. Расходы предполагают цены распространенных платформ обслуживания.
Замените один компонент в конфигурации SOTA. Замена проверяющего Claude Opus на нашего обученного 8B проверяющего удерживает 92,9 при стоимости 1,34 доллара: полочка качества за 3,2 раза меньшую стоимость, все еще значительно выше опубликованного SOTA. Самым дорогим компонентом в системе стал один из самых дешевых.
Удалите проприетарные модели полностью. Qwen3-14B и Qwen3-Coder-30B-A3B при k=4 с нашим обученным проверяющим сверху набрали 77,0 при стоимости 0,017 доллара за вопрос против 60,1 мажоритарного голосования на том же пуле и 80,4 для проверяющего Opus на нем. Генераторы почти бесплатны, поэтому проверяющий — это система. Это превосходит один вызов Claude Haiku (76,3 при стоимости 0,043 доллара) при 2,5 раза меньшей стоимости и находится в пределах 4,2 очков от одного вызова Claude Sonnet (81,2 при стоимости 0,1 доллара) при 6 раза меньшей стоимости.
Это обобщает
Мы намеренно обучались на одном эталоне и одном инструменте, потому что в реальной жизни клиент приходит со своей собственной конфигурацией. Эталон BrowseComp-Plus меняется одновременно в обоих аспектах: та же форма задачи, но агент извлекает информацию из фиксированного корпуса вместо поиска в открытом вебе.
Верификатор работает сразу и повышает эффективность последующего голосования с 39% до 51%. Однако он теряет в отзыве: в 27% решаемых вопросов он отвергает всех кандидатов и проигрывает вопрос. Конечное небольшое SFT на примерно 85 вопросах из удерживаемого домена, примерно 15 шагов оптимизатора, сокращает этот разрыв с 27% до 4% и повышает эффективность последующего голосования до 69%.
Проверка добавляет не более 5% к стоимости системы при каждом бюджете развертывания. Мы не утверждаем здесь SOTA, поскольку генератор — это одна открытая модель. Наше утверждение касается рецепта: точность обобщается бесплатно, и разрыв в отзыве легко устраняется.
Резюме
- В агентском поиске правильные ответы обычно уже находятся в пуле. Мажоритарное голосование не может их выявить, потому что не может отменить популярный неправильный ответ. Проблема заключается в отборе.
- Независимый исследовательско-верификационный верификатор с правом вето повысил пул с 83,3 до 93,4 на FACTS-Search, превысив опубликованный SOTA. Это также было основной статьей затрат этой системы.
- Стандартный 8B не восстанавливает почти ничего из этого роста. Обученный, тот же 8B удерживает 92,9 при стоимости 1,34 доллара, что на полбалла меньше, чем у верификатора Claude Opus при стоимости в 3,2 раза ниже, и обеспечивает 77,0 при стоимости 0,017 доллара без использования проприетарной модели в стеке.
- Он обобщает результаты как на эталоне, так и на инструменте: точность передается бесплатно, а небольшая адаптация устраняет разрыв в отзыве и одновременно повышает точность еще больше.
Ограничения: оба эталона оцениваются на выборке из 100 вопросов, метки обучения наследуют шум автоматического оценщика, оба этапа SFT извлекаются из закрытых моделей, а проверка добавляет раунд задержки. Последнее ограничено: траектории верификации коротки по сравнению с развертыванием генерации, которое пропускает извлеченные документы через контекст, и циклы не имеют общего состояния, поэтому шестнадцать проверок стоят времени стенда в один раз.
