Как научить ИИ-агентов искать информацию в интернете и проводить исследования

Зачем агенту вообще искать информацию

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

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

Второй по частоте кейс после поддержки — работа с документами. Когда у компании большая стопка PDF, вплоть до сложной строительной документации, и нужно найти, как именно должен быть реализован тот или иной проект, без поиска не обойтись. Та же логика — при автоматизации подготовки писем и отчётов.

Отдельно можно выделить B2C-консультантов — агентов, которые общаются напрямую с клиентами B2B-заказчика. Например, покупатель выбирает пылесос, смотрит и сравнивает модели. Если у ИИ-ассистента есть хороший поиск, он поймёт, какую модель хочет купить человек, сравнит её с другими, найдёт отзывы в интернете и проконсультирует.

Поиск как способ собрать контекст, а не просто ответить

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

Контекст можно собирать из внутренних знаний компании, из интернета, для персонализации из информации о самом пользователе или из внутренних процессов и инструкций. Раньше разработчик вручную решал, какую информацию добавить в промпт. Сейчас задача стала сложнее: построить систему, которая сама умеет собирать нужный контекст под конкретный запрос. Современный поиск как раз даёт доступ к актуальной информации — той, что появилась уже после обучения модели.

File Search: как в Yandex AI Studio готовят данные для RAG

В Yandex AI Studio за этот сценарий отвечает инструмент AI Search — его часть File Search реализует классический прямой RAG-пайплайн. Завести простой RAG «на коленке» несложно, сложность — в качественной предобработке данных. С текстом всё более-менее понятно: режем на кусочки, опираясь на разметку. С остальными форматами сложнее.

File Search умеет работать с таблицами, CSV и Excel, из PDF и PPTX забирает не только текст, но и изображения, и тоже их обрабатывает. С изображениями и скриншотами тоже работает: в простых опенсорсных RAG-решениях этот шаг часто пропускают, и качество падает. Из видео и аудио одновременно достаёт текстовую дорожку и содержимое видеоряда — и то и другое векторизует как часть контекста.

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

GenSearch: генеративный ответ по поиску в интернете

Второе направление — поиск во внешних источниках. GenSearch принимает запрос, анализирует его, ищет по технологиям Яндекса и генерирует ответ с цитатами и ссылками на источники.

Инструмент подходит, если поиск — не ключевая функция чат-бота и хочется быстро собрать MVP, не настраивая поиск вручную. Есть ограничение — повлиять на промпт итоговой генерации нельзя, вы получаете готовый генеративный ответ как есть. Для узкоспециализированных ассистентов это работает хуже, а полноценный глубокий рисёрч на GenSearch построить сложно.

Image Search: поиск по изображению и тексту

Image Search в том же плейграунде ищет изображения по текстовому запросу и по загруженной картинке. Например, по запросу «котики» он найдёт подходящие изображения, покажет настройки параметров поиска и готовый код с этими параметрами.

Поиск по изображению работает так же: если, к примеру, провести поиск по фото комнатного растения, сервис сможет найти сайт, где продают такое же растение.

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

Яндекс Вордстат: частотность запросов через MCP

Яндекс Вордстат — инструмент, который показывает, как часто ищут те или иные фразы в интернете. Это классический инструмент для SEO-оптимизации, но полезен он и для маркетинговых исследований: позволяет анализировать интерес к темам, смотреть похожие запросы, оценивать частотность и статистику поведения.

В Yandex AI Studio доступен шаблон MCP-сервера для Вордстата. Не нужно ничего программировать самостоятельно: достаточно подключить шаблон MCP-сервера в интерфейсе — и можно общаться с ассистентом на естественном языке, а он будет проводить исследования. Вместе с шаблоном MCP для Вордстата нужно подключить ещё и инструмент веб-поиска.

Yandex Search API: классический текстовый поиск с фильтрами

Yandex Search API — классический текстовый поиск на технологиях Яндекса. Можно задать запрос, настроить API через фильтры и получить список ссылок — например, топ-10 с настраиваемой глубиной — и сниппет к каждой: два-три предложения о содержимом страницы, как в обычной выдаче поисковика.

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

Web Search Tool: как добавить агенту поиск в интернете

Теперь — о том, как встроить поиск прямо в агента. Yandex AI Studio поддерживает режим совместимости с OpenAI API, и в нём есть Responses API со встроенным инструментом Web Search Tool. Как и в обычном Search API, в нём можно настраивать регион, конкретные сайты и язык поиска.

Ключевое отличие — режим потребления контекста, который меняет саму логику работы агента.

Три режима Web Search Tool

Low

Режим с коротким ответом. Экономит токены и по сути работает как формат «запрос — ответ». Хорошо подходит для простых вопросов вроде текущей погоды или цены товара, но для глубокого исследования не годится.

Medium

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

High

Самый продвинутый режим. Полноценный агентский рисёрч с многократными вызовами инструментов поиска, сравнением результатов и возможностью не просто искать в интернете, а подробно изучать конкретные части страницы.

Поверх High можно добавить и другие инструменты: MCP к Вордстату, Code Interpreter для графиков и отчётов в PDF, или даже подключить RAG — и получится ассистент, который ищет одновременно в интернете и по внутренним базам знаний компании, готовит развёрнутые исследования в нужном формате и умеет сравнивать варианты.

Главная ценность заключается в том, что поиск можно кастомизировать под конкретную бизнес-задачу. Нужен быстрый ответ — подойдёт быстрая модель и режим Low. Нужно готовое исследование — стоит обратить внимание на режимы Medium и High.

От простых запросов к многошаговым задачам

Раньше поиск в браузере был устроен просто: короткий вопрос с ключевыми словами, нужно найти факт, поисковик делает один «проход» и выдаёт ответ. Не понравился ответ — нужно переформулировать запрос вручную и спросить снова.

По мере встраивания ИИ в повседневную жизнь доверие к таким системам растёт, и пользователи начинают задавать не короткие вопросы, а целые многошаговые задачи — их называют мультихоп-запросами. Например, вопрос «какая команда победила на чемпионате мира, когда в Москве была гроза» требует нескольких шагов рассуждения и поиска, а не одного «прохода».

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

Подход № 1: планировщик и исполнитель

Первый архитектурный подход строится на связке двух ролей. Агент-планировщик пишет план исследования, при необходимости уточняет детали у пользователя — какой именно контекст нужно найти, — затем разбивает задачу на части и передаёт их агенту-исполнителю.

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

Планировщик и исполнитель могут быть разными моделями: например, более дорогая и «думающая» модель для планирования и более простая, но с хорошим вызовом инструментов — для исполнения, или наоборот, в зависимости от задачи. Экономия токенов здесь не работает — подход просто дробит один большой контекст на несколько поменьше, а не убирает эти токены совсем. Сэкономить получится в основном за счёт выбора моделей.

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

Из ограничений: подход может оказаться дорогим, если нужен качественный план и, соответственно, дорогая модель для планировщика. Качество нестабильно — если планировщик ошибается, ошибка накапливается по ходу всего плана и модель может уйти не туда. А ещё этот подход сложно тестировать и воспроизводить: другая модель может построить другой план, другой исполнитель — иначе исполнить его.

Если нужен универсальный рисёрч-агент под любые вопросы — это хороший вариант, который выдаёт качественные результаты и не требует сверхсложной реализации.

Подход № 2: жёсткий многошаговый пайплайн

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

Пайплайн собирают разработчики вместе со специалистами из предметной области. Он жёстко заточен под конкретную специализацию, обычно делает один «проход» поиска (реже — несколько) и не задаёт уточняющих вопросов, если это не заложено заранее.

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

Из плюсов: у пайплайна высокая предсказуемость: он собран руками разработчиков, каждый этап можно протестировать и валидировать отдельно, проверить вход и выход. Раз пайплайн спроектирован под конкретную задачу, он решает её достаточно хорошо.

Из ограничений: узкая специализация. Если пайплайн, спроектированный для поиска по медицине, получит вопрос про астрономию, результат будет, скорее всего, слабым.

Для сборки такого пайплайна нужны специалисты из предметной области, а любое изменение логики потребует новой разработки. Области применения — фармакология, врачебная практика, юридическая аналитика, финансовые исследования и т. д.

Подход № 3: агентский цикл с инструментами

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

Из плюсов: стоимостью легко управлять, меняя набор инструментов, их описания, саму модель и системный промпт.

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

Подход гибкий и естественный — модель сама собирает пайплайн из доступных инструментов под конкретный запрос, легко расширяется и даёт высокую наблюдаемость — можно проверить вход и выход каждого вызова инструмента. Он хорошо ложится на модели с сильным использованием инструментов и позволяет легко оптимизировать стоимость на простых запросах.

Есть ещё одно ограничение: нужна модель, которая умеет хорошо пошагово рассуждать. Здесь важно балансировать между глубиной рассуждения и временем ответа. Труднее гарантировать полноту исследования — модель останавливается тогда, когда сама решит, что нашла достаточно, хотя её можно попросить продолжить или задавать уточняющие вопросы по ходу. Расход токенов и времени сильно зависит от числа шагов и заданных ограничений — модель может закончить условно за десять обращений к поиску, а может и за 50 — в зависимости от того, насколько чётко она поняла задачу.

Что общего у всех трёх подходов

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

Каждый из трёх подходов можно построить поверх инструментов Yandex AI Studio. Выбор зависит от задачи:

• нужен универсальный ассистент — подойдёт связка планировщика и исполнителя;
• нужна предсказуемость в чувствительной области — жёсткий пайплайн;
• нужна гибкость и наблюдаемость — агентский цикл с инструментами, как в Web Search Tool.

Частые вопросы

Что в итоге

• Поиск для агента — это не отдельная функция, а способ собрать контекст: из внутренних знаний компании, интернета, данных о пользователе или внутренних процессов.
• Локальная база знаний, которой нет в открытом доступе, — повод использовать RAG. В Yandex AI Studio за это отвечает File Search внутри AI Search, он умеет готовить данные из таблиц, PDF, PPTX, изображений, видео и аудио.
• Web Search Tool встраивает поиск прямо в агента через Responses API и работает в трёх режимах — Low, Medium, High, — которые задают, насколько глубоко агент может использовать инструменты поиска.
• У глубокого исследования есть три архитектурных подхода: планировщик с исполнителем, жёсткий многошаговый пайплайн и агентский цикл с инструментами.