🔎 Агент SMITH для поиска: маленькая модель ищет, большая — отвечает

На AI RnD Day Артём Снегирёв рассказал, как команда обучала SMITH — отдельного агента для многошагового поиска.

📌 TLDR
Вместо того чтобы заставлять дорогую LLM читать всю поисковую выдачу, ребята из команды Артема предложили другой подход и поручили поиск небольшой модели. SMITH уточняет запросы, обращается к векторному индексу и возвращает ID нужных документов, а ответ пользователю пишет другая LLM, которую можно выбирать под свои нужды и которая не мешает поиску. Агента обучали сначала на примерах поисковых цепочек, затем добавили щепотку RL. При этом выяснилось: агент часто находит нужный документ, но не включает его в итоговый набор. Ниже представлены технические детали...

⚙️ Что внутри
Архитектура на базе родного GigaChat3-10B-A1.8B, контекст 32K токенов (хотя модель поддерживает 256K). Инструмент search возвращает top-10 документов за вызов. Затем эмбеддер на базе Qwen3-8B строит векторные представления, размер чанка — 512. Цикл выглядит так: определить, чего не хватает → сформировать подзапрос → прочитать выдачу → продолжить поиск или остановиться. Обычно хватает 4–6 итераций.

🧪 Как учили искать
Для SFT использовали 8K траекторий, отфильтрованных по длине контекста и качеству поиска. Траектория — это вся последовательность запросов, найденных документов и финального отбора для выдачи результата.

Многошаговые вопросы собирали подстановками. Вместо вопроса "В каком году Беринг прибыл к Каме?" было усложнение "В каком году руководитель Второй Камчатской экспедиции прибыл к реке, на которой стоит Пермь?". То есть теперь нужно раскрыть две сущности, а затем найти дату. Это сложно 😳

Отдельно попробовали обучать агента на "идеальных" поисковых траекториях: брали готовое разбиение вопроса на подзапросы, каждый превращали в отдельный вызов поиска и гарантировали нужный документ в выдаче. Но результат оказался на 3,3 п. п. ниже, чем при обучении на базовом наборе траекторий. То есть более аккуратная демонстрация не обязательно лучше готовит агента к реальному поиску. Почему так вышло? Возможное объяснение — в таких примерах нет ситуаций, где нужно исправить неудачный запрос или продолжить поиск после неполной выдачи. Отдельно этот момент пока не изучали.

✂️ Что убрали из агента
Все замеры сделаны на бенче HotpotQA (Multi-hop Question Answering). Метрика nDCG@10 оценивает релевантность и порядок первых десяти документов.

Отказ от блока рассуждений сократил контекст на 10%, но снизил метрику на 1,1 пункта. Среднее число поисковых вызовов выросло с 4,4 до 4,9. Зато замена ответа с цитатами на простой список doc_id подняла nDCG@10 с 79,6 до 83,2. Для модели оставили только отбор документов. Снизились ли при этом галлюцинации, отдельно не проверяли.
А удаление повторяющихся документов из контекста не оправдало ожиданий: контекст стал короче на 13%, но метрика упала на 1,9 пункта. В итоге дубликаты заменялись заглушками.

📈 Что добавило обучение с подкреплением
Использовали GRPO: восемь поисковых траекторий на запрос, награда по метрике recall@30, доля эталонных релевантных документов, попавших в первые 30 результатов.

На двухшаговых задачах MuSiQue переход от SFT к SFT → RL поднял nDCG@10 с 83,1 до 87,5 и сократил среднее число вызовов с 4,8 до 3,5.

На трёхшаговых задачах выигрыш скромнее: 75,4 → 77,0. При этом метрика при идеальном отборе уже найденных документов выросла с 86,4 до 92,3. То есть видно, что агент стал приносить больше полезного, но значительную часть терял на финальном отборе.

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

🤗 HF
🖥 Github

🔗 Более подробно — в презентации Артёма (в комментариях файлом) и в записи выступления (тайминг: 2:05:00).

#RAG #agents #search #conference #paperwatch