Авторы: Ади Эльбаз, Эран Гольдштейн, Тамар Леви Лобода, Нив Гранот, Юваль Белфер
Краткий обзор
DeepResearch Bench II (DRB II) — это бенчмарк, оценивающий агентов для глубоких исследований по 9430 критериям, составленным экспертами, в рамках 132 задач. Мы заняли 1-е место с общим баллом 64,38 — это на 3,2 балла выше предыдущего лучшего результата. Система берет результаты работы более слабых агентов (занимающих места с 7 по 13 в таблице лидеров, ни один из которых не набрал выше 45 баллов) и объединяет их.
Рисунок 1: Таблица лидеров DRB II на 24 июня 2026 года, где наша запись (AI21) занимает 1-е место с общим баллом 64,38.
Рост на 20 пунктов за 6 месяцев: что изменилось?
Примерно полгода назад лучший агент для глубоких исследований в DRB II набирал около 45 баллов. С тех пор область развивалась так, как это обычно и бывает: создавались более совершенные агенты. Улучшилась оркестрация, поиск, декомпозиция и базовые модели. Каждый прирост был результатом усиления одного конкретного агента.
Мы решили задать другой вопрос: не «как создать лучшего агента?», а «сколько еще можно извлечь из тех, что уже существуют?»
Этот вопрос стоит задать, учитывая саму суть глубоких исследований. Получив реальную задачу (например, «оценить преимущества и риски инвестирования в инфраструктуру зарядки электромобилей»), агент работает в течение нескольких минут, ищет информацию в сети и составляет длинный отчет. Самое сложное — не написание текста. Это воспроизведение информации: выявление конкретных, проверяемых фактов, от которых зависит ответ, без пропуска важных деталей. И у воспроизведения информации есть свойство, которого нет у процесса написания: два посредственных отчета редко пропускают одни и те же факты. Там, где один оказался недостаточно полным, другой, скорее всего, восполнил пробел. Факты уже существуют, они разбросаны по разным отчетам; никто просто не собрал их воедино.
И мы это сделали. Объединив результаты работы агентов, которых никто не назвал бы передовыми, мы достигли вершины таблицы лидеров, не создав ни одного нового агента.
Краткое примечание по поводу очевидного возражения, что «возглавить таблицу лидеров» звучит как «манипуляция бенчмарком». Здесь все наоборот: это бустинг, общий метод ансамблирования, а DRB II — это просто площадка, где мы его демонстрируем. Метод требует лишь нескольких разнообразных попыток выполнения задачи, которые с таким же успехом могут быть вашими собственными.
Понимание задачи перед началом разработки
Прежде чем писать какой-либо код, мы потратили первые усилия на анализ того, что на самом деле требуется для достижения успеха.
DRB II оценивает исследовательский отчет по трем измерениям, каждое из которых оценивается как доля успешных прохождений по детализированным критериям:
Каждый критерий оценивает одни и те же измерения, поэтому сочетание критериев показывает, какая именно способность в основном отражается в балле (это верно для любой метрики, построенной на основе множества равнозначных проверок, а не только для этой). В данном случае важнее всего было воспроизведение информации.
К счастью, нужные нам отчеты уже были в открытом доступе. Агенты, занявшие места с 7 по 13, опубликовали свои полные результаты на Hugging Face. Мы скачали их, повторно реализовали метрики и подтвердили по таблице лидеров, что воспроизвели точные баллы каждого агента. Мы начали не с чистого листа, а с семи полных отчетов по каждой задаче, ни один из которых не набрал выше 45 баллов в общем зачете, а лучший из них отставал на 16 пунктов от предыдущего лидера с результатом 61.
Эксперименты с оракулом: сколько информации уже есть?
Затем мы провели эксперименты с оракулом: идеализированные процедуры с доступом к эталонным данным, которые измеряют, сколько релевантной информации содержат эти семь слабых отчетов в совокупности, прежде чем тратить вычислительные ресурсы. Мы попробовали два варианта. Селектор-оракул выбирает для каждой задачи лучший из семи отчетов. Объединитель-оракул комбинирует несколько отчетов в один.
Рисунок 3: Вместо выбора лучшего отдельного отчета (0,56), объединитель-оракул комбинирует лучшие вклады на уровне критериев из нескольких отчетов, достигая балла 0,70.
Результаты поразительно ясны: выбор одного победителя для каждой задачи все равно не позволит достичь текущего уровня SOTA.
Но объединение легко превосходит SOTA, демонстрируя, что семь отчетов вместе содержат гораздо больше, чем любой из них по отдельности. И дело не только в более длинном списке фактов: поскольку разные отчеты охватывают разные области, их объединение повышает качество воспроизведения информации, поддерживает более глубокий анализ и даже делает текст более понятным.
Мы также обнаружили, что эти улучшения масштабируются плавно: объединение только 4 лучших отчетов уже превосходит SOTA таблицы лидеров, а качество продолжает расти по мере добавления новых, создавая баланс между стоимостью и качеством.
Есть один нюанс, который делает объединение еще более мощным. Воспроизведение информации ограничено (нельзя выйти за рамки фактов, существующих во всех входных данных), но анализ — нет: объединение отчетов, каждый из которых видел лишь часть картины, может выявить инсайты на основе сопоставления источников, которых не было ни в одном из оригиналов. Даже там, где факты пересекаются, разные отчеты интерпретировали их по-разному, поэтому объединение их перспектив само по себе может сделать анализ более точным. Информация была там все время, просто она была разбросана; именно объединение позволило повысить балл.
Рисунок 4: Качество объединения оракулом растет с увеличением количества объединенных кандидатов (k). Объединение всего 4 лучших из 7 отчетов (0,646) уже превосходит SOTA таблицы лидеров (0,61), при этом отдача снижается по мере приближения к потолку полного оракула в 0,70.
Метод: Агломеративное попарное объединение
Оракул показал, что потенциал для роста реален; вопрос заключался в том, как реализовать его без доступа к эталонным данным. Наш ответ — агломеративное объединение: вместо выбора или переписывания мы многократно объединяем пары отчетов в один, пока не останется единственный отчет, наследующий факты из всех исходных. Мы используем попарное объединение, потому что объединение меньшего количества элементов за раз сохраняет больше фактов, как мы увидим далее.
Метод состоит из двух этапов: генерация отчетов-кандидатов и их объединение. Большинство попыток сосредоточены на оптимизации первого этапа — генерации новых и улучшенных отчетов; но для второго этапа подойдут любые агенты, создающие разнообразные и разумные попытки, поэтому мы смогли использовать общедоступные результаты.
Для каждой задачи мы берем семь отчетов и проводим агломеративное объединение, многократно комбинируя кандидатов в один, пока не останется единственный отчет. Каждое объединение выполняется моделью Gemini 3.1 Pro с намеренно простым промптом: сохранить каждый факт из обоих входных данных и разрешить противоречия. Результатом являются 132 объединенных отчета, по одному на задачу.
Вот почему агрегация лучше, чем усиление одного агента. Один агент делает ставку на одну декомпозицию с самого начала, и все последующие этапы наследуют ее: пропустите одну нить, и вы пропустите ее везде. Объединение результатов работы нескольких независимых агентов резко повышает вероятность того, что какой-то из них охватил каждую часть ответа. Ни один агент не является достаточно хорошим сам по себе, но вместе они покрывают все пространство.
Главный рычаг — это количество кандидатов, которые мы объединяем за один шаг, что является удобным регулятором скорости и качества. Например, объединение по два дает лучшее воспроизведение информации (с двумя отчетами в контексте модель почти ничего не теряет), но это самый медленный путь, требующий шести шагов для получения одного отчета. Вы можете сократить количество шагов, добавляя больше кандидатов (три кандидата требуют четырех шагов; все семь сразу — всего одного), но точность страдает, так как отчеты перегружают контекст. Более крупные шаги улучшают презентацию, но снижают воспроизведение информации и общий балл, а вес презентации слишком мал, чтобы это компенсировать.
Поскольку Information Recall влияет на итоговый балл, а задача не является критичной к задержкам, мы внедрили попарное объединение, однако настройки позволяют гибко менять параметры: развертывание, чувствительное к задержкам, могло бы использовать более крупные шаги, жертвуя лишь парой баллов ради значительно меньшего количества последовательных слияний.
Рисунок 5: Больше кандидатов на каждом шаге слияния означает меньше шагов, но более низкую точность: Information Recall и TotalScore падают, в то время как Presentation растет. Мы выбрали попарное объединение (два на шаг). Приведенные здесь оценки получены в результате абляционного исследования шагов слияния; итоговый результат составляет 64,38.
(Один рычаг, который мы еще не задействовали, но который является перспективным направлением: порядок слияния, использующий простую функцию сходства. Объединение наиболее различающихся отчетов в первую очередь может минимизировать дублирование на каждом шаге.)
Результаты
Наш конвейер получил оценку 64,38: №1 в DRB II, +3,2 по сравнению с предыдущим SOTA — построен на основе агентов, занимавших места с 7-го по 13-е, с объединением отчетов, которые по отдельности имели баллы в диапазоне от 38 до 45.
Что дальше
Создание достойного агента становится все дешевле. С такими инструментами, как Claude Code или Cursor, настройка исследовательского агента, создающего разумный отчет, становится практически обыденностью, и количество таких агентов будет только расти. Узким местом больше не является вопрос «можете ли вы создать одного хорошего агента?», а «что можно получить из множества тех, что у вас уже есть?»
Ответ: гораздо больше, чем может дать любой из них по отдельности. Когда успех означает охват фактов, а факты распределены по независимым попыткам, мы показываем, что объединение агентов эффективнее, чем усиление одного агента — даже без использования собственной передовой модели. Количество попыток, которые вы объединяете, — это регулятор: мы заняли первое место, начав с самых дешевых и старых отчетов, поэтому, если начинать с более сильных агентов, может хватить и пары штук.
