AI-агенты, давайте сами. Как научить AI-агента искать информацию по базе, не задействуя датасеты

Что, если я скажу, что для обучения AI-агентов вообще не нужны датасеты? Не надо их собирать, валидировать, размечать. Достаточно развернуть двух агентов на компактной модели Qwen2.5-3B или 7B, запустить их где-нибудь у себя или в облаке, дать им базу знаний и наблюдать за циклом «AI учит сам себя», попивая кофеек :)

В середине января 2026 года на Hugging Face опубликовали исследование по фреймворку Dr. Zero (DeepResearch-Zero) для самообучения агентов (ссылка на GitHub там тоже имеется). Фишка: в этом подходе агенты самообучаются с нуля без участия человека и показывают результаты, сопоставимые с полностью контролируемыми поисковыми агентами.

Для вашего удобства я написал обзор исследования и дополнил его пояснениями. Приглашаю почитать обо всем под катом.

Всем привет! Я Павел Мохляков, Data Science-инженер в Cloud.ru. Я регулярно мониторю, как можно эффективнее обучать AI-агентов (все-таки это моя работа), и постоянно нужно искать способы, как все оптимизировать.

Обычно обучалки для агентов строятся на базе мощного датасета или с использованием подхода LLM‑as‑a-judge, когда ответы агента проверяет LLM, но нередко качество оценки требует вмешательства человека. В исследовании Dr. Zero: Self-Evolving Search Agents without Training Data авторы предложили новый подход. Его суть в том, что на базе одной и той же LLM инициализируют стартовое состояние двух агентов (Solver и Proposer — скоро расскажу, что они собой представляют), а далее их веса меняются в процессе самообучения. В итоге получаем два разных агента, один из которых учит другого искать по базе информацию для ответа на вопросы.

Самообучение AI-агентов: в чем проблемы существующих подходов

Обучение AI-агентов без данных, созданных или отобранных человеком, — идея не новая, но существующие подходы к такому обучению требуют заранее придуманных вопросов (human-curated questions). Причем не системных промптов, которые один раз загрузил и забыл, а отдельных на каждый запрос.

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

Один из алгоритмов, который задействован в самообучении агентов, — Group Relative Policy Optimization (GRPO). Модель получает на вход промпт и генерирует несколько вариантов ответа. Для каждого вычисляется advantage (преимущество) — показатель того, насколько ответ лучше или хуже среднего по группе. Дальше модель развивается так, чтобы генерировать больше ответов, которые по advantage лучше среднего.

На базе этого алгоритма сделана Hop-Grouped Relative Policy Optimization (HRPO) — модификация, в которой вместо многих ответов на один вопрос используется множество запросов. Они группируются по hop count — числу шагов в рассуждении модели, которые нужны для ответа. Модель вычисляет «лучше среднего» для каждой такой группы. Эта модификация дешевле, так как требует меньше генераций ответов, и поэтому именно ее применяли авторы исследования по самообучению AI-агентов. Дальше расскажу, как именно, но сначала хочу подробнее разобрать, какие агенты есть в этом исследовании и как они друг с дружкой общаются.

Схема взаимодействия AI-агентов при самообучении

Авторы исследования используют двух поисковых AI-агентов: Proposer и Solver. Роли простые: Proposer генерирует вопросы, Solver на них отвечает. Это два отдельных агента, которые собраны на одной и той же базовой модели, например Qwen2.5-7B-Instruct.

Агенты обучают друг друга в замкнутом цикле обратной связи:

1. Proposer генерирует вопросы, используя поиск, и создает сложные, но решаемые задачи с известным ответом.

2. Solver учится на этих задачах, за ответами тоже ходит в поиск.

3. Агенты развиваются последовательно: Proposer учится синтезировать разнообразные и сложные вопросы, в то время как Solver учится рассуждать, обучаясь на этих вопросах. Умнеющий на глазах Solver стимулирует Proposer генерировать все более сложные запросы, и получается непрерывно развивающаяся учебная программа.

В развитии Proposer есть два узких места:

1. Сгенерированные вопросы слишком похожи друг на друга. Из-за этого AI-агент обучается на однотипных задачах и начинает давать шаблонные ответы. А от поискового агента хочется увидеть ответы, которые раскрывают тему ровно настолько, насколько нужно.

2. Сложность вопросов не меняется по мере того, как растут возможности Solver. Из-за этого качество ответов заметно растет только на простых и одношаговых задачах, а сложные и многошаговые запросы AI-агент решает хуже.

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

Дополнительно есть стимул вознаграждения, который управляет уровнем трудности вопросов. Стимул мотивирует Proposer ходить в поиск и формировать сложные, но проверяемые вопросы для Solver. А с помощью HRPO вопросы группируются не в случайном порядке, а по сложности, то есть по числу итераций, которые нужно предпринять Solver для ответа на каждый вопрос. Этот алгоритм гарантирует эффективное обучение, устраняя необходимость дорогих вложенных процедур отбора образцов в процессе самообучения.

Авторы исследования утверждают, что поисковые агенты, обученные без размеченных датасетов, достигают или превосходят полностью контролируемые базовые модели на 14,1% на сложных эталонных тестах по вопросам и ответам. Это позволяет сделать вывод, что человеческий контроль для обучения AI-агентов — вовсе не обязательный компонент.

Как устроена самоэволюция в Dr. Zero

Самоэволюция в Dr. Zero — строго настроенный итеративный процесс оптимизации с двумя отдельными политиками для Proposer и Solver, которые обучают друг друга. По сути, это разновидность самообучения, но авторы используют именно термин «самоэволюция», чтобы подчеркнуть постепенное усложнение задач. Пройдусь по тому, из каких этапов состоит цикл самоэволюции:

Этап 1. Proposer генерирует вопрос и ответ через поиск. Proposer получает начальный документ и строгое техническое задание. Так как Proposer — поисковый агент, в него зашивается системный промпт.

System
Ты Qwen, созданный Alibaba Cloud. Ты полезный ассистент.

# Tools

Ты можешь вызывать одну или несколько функций, чтобы помочь пользователю с запросом.
Тебе предоставлены сигнатуры функций внутри XML-тегов <tools></tools>:

<tools>
{"type": "function", "function": {"name": "search", "description": "Searches the web for relevant information based on the given query.", "parameters": {"type": "object", "properties": {"query_list": {"type": "array", "description": "A list of fully-formed semantic queries. The tool will return search results for each query.", "enum": null}}, "required": ["query_list"]}, "strict": false}}
</tools>

Для каждого вызова функции возвращай JSON-объект с именем функции и аргументами внутри XML-тегов <tool_call></tool_call>:

<tool_call>
{"name": <имя-функции>, "arguments": <аргументы-json-объект>}
</tool_call>

User/Tool

Ты эксперт в генерации вопросов. Создай один сложный детерминированный вопрос и его единственный недвусмысленный ответ на основе предоставленного исходного документа. Логический путь должен начинаться с документа и требовать ровно n шагов (то есть n-1 запросов в поиск) для получения конечного ответа.

### Определения

1.	Hop — узел в цепочке рассуждений. Hop 1 — это исходная информация, найденная в документе. Hop n — окончательный ответ.

### Входные данные

1.	n — точное количество шагов в цепочке рассуждений (требуется n−1 запросов в поиск).
2.	Исходный документ: полный исходный текст.

### Процесс и инструменты

1. Проанализируй документ и выбери отправную точку:

●	Прочитай и проанализируй исходный документ.
●	Выбери конкретную сущность, событие или деталь, явно упомянутую в тексте. Эта информация станет Hop 1.

2. Спроектируй цепочку ответа:

●	От Hop 1 к Hop 2. Определи факт, который относится к Hop 1 и которого НЕТ в тексте, но который можно найти с помощью поиска. Результат — это Шаг 2.
●	Итерация. Продолжай соединять текущий Hop i со следующим Hop i + 1, используя детерминированное и проверяемое отношение, которое найдешь через поиск.
●	Остановись на Hop n. Продолжай этот процесс, пока у тебя не будет ровно n Hops. Hop n должен быть единственным и окончательным ответом.

3. Протоколы рассуждений и поиска:

●	Всегда рассуждай внутри тегов <think> ... </think>, когда выстраиваешь связи в ответе или получаешь новую информацию.
●	Для каждого перехода между Hops, который требует информации из поиска, выполни поисковый запрос, используя <tool_call> ... </tool_call>.
●	Результаты поиска будут предоставлены системой между <tool_response> ... </tool_response>.

4. Формат вывода:

●	Выводи нумерованную последовательность ровно n-1 поисковых шагов. Для каждого поиска i (от 1 до n-1) выводи:

<think> Рассуждение, Hop i. Определи Hop i в документе / результатах поиска, сформулируй запрос для достижения Hop i + 1 </think>
<tool_call> Запрос для поиска Шага i + 1 </tool_call>
[Ожидай результатов поиска в <tool_response> от системы]

●	После завершения всех поисков и достижения Hop n выведи вопрос и окончательный ответ:

<think> Финальный шаг рассуждений. Подтверди, что цепочка завершена с Hop n, и сформулируй вопрос </think>
<question> Сложный вопрос, который представляет собой Hop 1 и запрашивает окончательный ответ (Hop n) </question>
<answer> Единственный и краткий окончательный ответ (Hop n) </answer>

### Примеры

1. Пример шаблона для n = 1 (то есть без похода в поиск):

<think> [Объясни, как Hop 1 выбран из исходного документа и как сформулирован вопрос] </think>
<question> [Вопрос, основанный исключительно на сущности Hop 1 из текста] </question>
<answer> [Ответ (Hop 1)] </answer>

2. Пример шаблона для n = 3 (то есть два запроса в поиск):

<think> [Рассуждение, Hop 1. Найди Hop 1 в исходном документе, сформулируй запрос для достижения Hop 2] </think>
<tool_call> [Поисковый запрос для нахождения Hop 2 на основе Hop 1] </tool_call>
[Ожидай результатов поиска в <tool_response> от системы]
<think> [Рассуждение, Hop 2. На основе результатов поиска определи Hop 2 и составь следующий запрос для нахождения Hop 3] </think>
<tool_call> [Поисковый запрос для нахождения Hop 3 на основе Hop 2] </tool_call>
[Ожидай результатов поиска в <tool_response> от системы]
<think> Финальный шаг рассуждений. Подтверди Hop 3 в результатах поиска и сформулируй вопрос, начиная с Hop 1 </think>
<question> [Вопрос, начинающийся с Hop 1 и требующий от Solver найти Hop 2, чтобы в итоге получить Ответ (Hop 3)] </question>
<answer> [Ответ (Hop 3)] </answer>

### Критические правила

1.	Начинай с исходного документа. Hop 1 должен быть явно присутствующей сущностью в исходном тексте. Каждый последующий шаг должен быть подтвержден соответствующими результатами поиска.
2.	Поиск обязателен для n > 1. Каждая связь между hops после Hop 1 должна использовать поисковую систему.
3.	Точное количество поисков. Выводи ровно (n-1) записей <tool_call>, ни больше ни меньше.
4.	Никаких спойлеров. Вопрос должен упоминать только Hop 1; не включай и не намекай на промежуточные hops.
5.	Ясность. Вопрос должен быть самодостаточным, ответ — кратким и прямым, без дополнительных комментариев, форматирования или объяснений.
6.	Целостность цепочки. Каждый Hop должен строго зависеть от предыдущего. Ни один Hop не должен быть пропущен или выведен без своего непосредственного предшественника.

Теперь сгенерируй вопрос и ответ с n = {hop} шагов. Для этого используй информацию из следующего исходного документа: {document}

Если вкратце, то промпт задает правило, по которому AI-агент будет находить в тексте информацию, нужную для ответа, и ходить в поиск в случае, если это понадобится. Proposer анализирует документ, выбирает отправную точку (Hop 1) и строит цепочку рассуждений, используя тег <think>. Для перехода к следующему Hop агент формирует поисковый запрос через <tool_call>. Получив результаты, он продолжает, пока не построит всю цепочку и не сформулирует итоговый вопрос и точный ответ.

Этап 2. Solver получает вопрос и ищет на него ответ. Solver — второй поисковый агент, инициализированный той же базовой моделью (например, Qwen2.5-7B). Его системный промпт инструктирует его рассуждать внутри <think> и активно использовать поиск.

System

Ты Qwen, созданный Alibaba Cloud. Ты полезный ассистент.

# Tools

Ты можешь вызывать одну или несколько функций для помощи с пользовательским запросом.
Тебе предоставлены сигнатуры функций внутри XML-тегов <tools></tools>:

<tools>
{"type": "function", "function": {"name": "search", "description": "Searches the web for relevant information based on the given query.", "parameters": {"type": "object", "properties": {"query_list": {"type": "array", "description": "A list of fully-formed semantic queries. The tool will return search results for each query.", "enum": null}}, "required": ["query_list"]}, "strict": false}}
</tools>

Для каждого вызова функции возвращай JSON-объект с именем функции и аргументами внутри XML-тегов <tool_call></tool_call>:

<tool_call>
{"name": <имя-функции>, "arguments": <аргументы-json-объект>}
</tool_call>

User/Tool

Ответь на заданный вопрос. Ты должен:

1.	Всегда проводить рассуждения внутри <think> и </think>, когда получаешь новую информацию.
2.	После рассуждений, если тебе не хватает знаний, вызывай поисковую систему через <tool_call> запрос </tool_call>.
3.	Система вернет лучшие результаты поиска между <tool_response> и </tool_response>.
4.	Ты можешь выполнять поиск столько раз, сколько потребуется.
5.	Если дальнейшая внешняя информация не нужна, предоставь ответ напрямую внутри <answer> и </answer>, без подробных иллюстраций. Например: <answer> Пекин </answer>.

Вопрос: {question}

Получив сгенерированный вопрос, Solver сам разбивает его на подзадачи, выполняет поисковые запросы и анализирует результаты, стремясь прийти к финальному ответу, который он заключает в тег <answer>.

Например, для вопроса «Какой фильм снял режиссер, который умер раньше: Gold For The Caesars или Heinz In The Moon?» Solver последовательно ищет режиссеров каждого фильма, затем даты их смерти, сравнивает их и дает обоснованный ответ: Gold for the Caesars.

Этап 3. Вычисление награды для Proposer. Proposer получает высший балл не за любые вопросы, а только за те, что находятся в «зоне ближайшего развития» Solver. Не буду сильно тормошить матанализ, лишь приведу формулу, по которой рассчитывается награда:

Сфокусируюсь тут на двух переменных: n — количество вариантов ответа, которые дает Solver, и k — число верных ответов на все вопросы, которых n штук.

Если упростить, то все работает так: Solver дает несколько вариантов ответа (n вариантов) на один сгенерированный вопрос. Награда максимальна (1.0), когда Solver дает верный ответ только в одной из попыток (k = 1). Размер награды линейно убывает с ростом k. Награда падает до нуля, если Solver всегда ошибается (k = 0, вопрос слишком сложен) или всегда прав (k = n, скучно, слишком просто, нет смысла обучать на вопросе, для которого Solver всегда знает ответ).

Кроме того, есть вознаграждение за формат r^f — это защита от деградации, чтобы Proposer четко следовал алгоритму из системного промпта. При генерации вопросов Proposer должен чередовать размышление (тег <think>), поход в поиск (тег <tool_call>), составление вопроса (<question>) и запись ответа (<answer>). Если последовательность соблюдена — еще плюс к награде.

Этап 4. Обновление агентов. Оба агента совершенствуются с помощью обучения с подкреплением, но с разными алгоритмами, которые настроены под их роли.

Proposer учится с помощью HRPO: вместо группировки нескольких вариантов ответа на один вопрос, как в GRPO, вопросы группируются по сложности, и модель генерирует по одному ответу на каждый из них. Сложность измеряется количеством итераций (hops), которые нужны для ответа. Затем внутри каждой группы вычисляются относительные преимущества → веса модели обновляются, чтобы поощрять генерацию вопросов с высоким advantage. Затраты на вычисления по алгоритму HRPO снижаются примерно в четыре раза по сравнению с использованием GRPO. Это происходит за счет того, что на каждый вопрос генерируется по одному ответу вместо четырех семплов.

Solver обучается с помощью GRPO. Используя сгенерированные пары «вопрос — ответ» как эталон, Solver оптимизируется, чтобы рассуждать в верном направлении. Гиперпараметры процесса детально описаны в этой таблице:

Практические рекомендации: где подход сработает, а где нет

Фреймворк Dr. Zero подойдет, если вам нужен поисковый агент для закрытой базы знаний, например для поиска по технической документации, научным архивам, внутренней Wiki. Связка из двух поисковых агентов хорошо сработает для работы по базе, по которой нет готовых данных для обучения, но есть четкий поисковый индекс. Идеально для фактологических вопросов, где нужно собирать ответ из нескольких частей (multi-hop QA).

Примеры, для каких вопросов подход подойдет:

• «Какой химический элемент открыл ученый, в честь которого назван университет в [городе X]?» (надо найти ученого → узнать университет → узнать элемент).

• «Будут ли совместимы технологии из патентов компании A и компании B?» (требует найти и сравнить описания двух патентов).

Сложность этих вопросов для модели — в логической цепочке и объединении данных из нескольких источников. Именно на таких бенчмарках (HotpotQA, 2WikiMQA) фреймворк Dr. Zero показал хорошие результаты, особенно если агенты были развернуты на Qwen2.5-7B:

Для творческих задач или задач с неоднозначным ответом фреймворк не особо подойдет. Алгоритм обучения во фреймворке Dr. Zero завязан на проверку точного совпадения ответа (Exact Match) с эталоном. Сложно объективно оценить качество стихотворения или глубину анализа так же, как ложность или правдивость факта.

Итоги

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

Расскажите, как бы вы применили Dr. Zero? Или предпочли бы другие фреймворки или вообще не стали обучать AI-агентов ради поиска по базе?