У любой большой языковой модели есть граница знаний — дата, до которой она «видела» интернет во время обучения. Спросите её про вчерашнюю новость, про курс валюты на сегодня или про товар, который вышел на прошлой неделе, — и в лучшем случае она честно скажет «не знаю», а в худшем уверенно выдумает ответ, который звучит правдоподобно, но не имеет отношения к реальности. Это фундаментальное ограничение: модель знает мир до даты обучения, и сама по себе она его не обновляет.
Решение — дать модели инструменты, чтобы добирать свежее прямо в момент запроса. Именно так устроен веб-поиск для ИИ в EPIHEN. Когда вы спрашиваете про что-то актуальное, агент не пытается вспомнить — он идёт в интернет, ищет, читает страницы, проверяет и только потом отвечает, ссылаясь на источники. В этой статье разберём, какими инструментами агент пользуется, как из темы рождается хороший поисковый запрос, что такое research-агент и — самое важное — как устроена защита от выдумок, когда источник недоступен.
Почему модель не знает свежего
Языковая модель — это не база данных и не поисковик. Это статистическая система, обученная на гигантском корпусе текстов до определённого момента. После обучения её знания фиксируются: внутри весов нет механизма, который сам подтянул бы вчерашнюю статью или сегодняшнюю цену.
Поэтому любой ответ на вопрос «что нового», «сколько стоит сейчас», «что произошло на этой неделе» без доступа к интернету — это в лучшем случае пересказ устаревшего, в худшем — фантазия. Чтобы нейросеть работала со свежими данными, ей нужен мост наружу. Этот мост — набор инструментов поиска и чтения, которые агент вызывает сам, когда понимает, что собственных знаний не хватает.
Важно понимать: агент не запускает поиск на каждый запрос подряд. Если вы спрашиваете «объясни, как работает HTTP» — это знание стабильно, оно есть в модели, лезть в интернет незачем. Но как только в вопросе появляется привязка ко времени («сегодня», «новый», «последняя версия», «сколько сейчас стоит») или к конкретному источнику, агент понимает, что собственных весов недостаточно, и подключает инструменты. Это решение принимается на лету, и именно оно отделяет полезный ответ от устаревшего.
Инструменты поиска в EPIHEN
В арсенале агента несколько инструментов, и каждый закрывает свой тип задачи. Агент выбирает подходящий сам — вам не нужно указывать, каким именно искать.
- web_search — основной поиск по интернету. Работает через Perplexity Sonar: это не просто список ссылок, а поисковая система, которая сама читает выдачу и возвращает обобщённый ответ с цитированием источников. Подходит для большинства запросов «что происходит», «найди информацию про», «какие сейчас».
- multi_search — несколько поисковых запросов параллельно (от 2 до 5 за один вызов). Когда тема многогранная и одного запроса мало — например, нужно сравнить три продукта или собрать данные с разных углов, — агент запускает запросы одновременно и получает результаты быстрее, чем если бы искал по очереди.
- academic_search — поиск по научным источникам. Когда нужны не блоги и новости, а исследования, публикации, академические данные, агент использует именно этот инструмент, чтобы выдача была качественнее по части достоверности.
- browse_page и deep_read — чтение конкретных страниц. Если в поисковой выдаче нашлась нужная ссылка, агент открывает её и читает содержимое целиком. Эти инструменты понимают не только обычные сайты, но и социальные сети — Telegram, VK, Instagram читаются нативно, а маркетплейсы (Ozon, Wildberries) — через Sonar, который их индексирует.
- fetch_url — вытащить контент по конкретной ссылке, которую вы уже дали. Работает через Jina Reader: берёт страницу по URL и возвращает чистый текст в формате, удобном для чтения моделью. Это не поиск по теме — это «у меня уже есть ссылка, прочитай её». Если у вас есть конкретный адрес статьи, документации, расписания или страницы с ценами, агент использует именно fetch_url.
Чем web_search отличается от browse_page
Разница простая, но важная. web_search отвечает на вопрос «что вообще есть по теме» — это разведка по широкому полю. browse_page и fetch_url отвечают на вопрос «что конкретно написано вот здесь» — это чтение конкретного адреса.
На практике агент часто комбинирует: сначала web_search, чтобы найти релевантные страницы, потом browse_page или deep_read по самым перспективным ссылкам, чтобы вытащить детали. Так работает любой грамотный человек, который ищет информацию: сначала загуглить, потом открыть пару вкладок и прочитать.
Отдельно стоит отметить работу с социальными сетями и маркетплейсами. Telegram, VK и Instagram читаются нативно — агент достаёт из них посты и каналы напрямую. С маркетплейсами сложнее: Wildberries и Ozon агрессивно защищаются от автоматического чтения, поэтому к ним агент идёт через Sonar, который индексирует их выдачу. Это даёт реальные цены и ссылки, хоть и с оговоркой — насколько актуальна индексация на момент запроса. Когда речь о товарах, агент всегда честно опирается на то, что реально вернул инструмент, и не достраивает недостающее по памяти.
Research-агент: когда тему нужно раскопать глубоко
Иногда вопрос не помещается в один поиск. «Сделай обзор рынка электросамокатов в России за 2026 год», «собери всё, что известно про новый фреймворк X», «проанализируй конкурентов по этому продукту» — это не один запрос, а целое исследование, где нужно декомпозировать тему, искать по нескольким направлениям, читать источники и сводить всё в связный результат.
Для этого есть research-агент — он запускается через run_agent с профилем research. В отличие от одиночного веб-поиска, research-агент работает собственным циклом: он сам разбивает тему на подвопросы, запускает поиск по каждому направлению (в том числе параллельно), читает найденные страницы, оценивает, чего ещё не хватает, и продолжает копать, пока не соберёт достаточно материала. Затем сводит всё в единый ответ с источниками.
Это принципиально другой режим. Обычный web_search — один-два прохода. Research-агент — это самостоятельный исследовательский цикл, который ведёт себя как аналитик: формулирует гипотезы, проверяет их, добирает недостающее. Подходит, когда вам нужен не быстрый факт, а проработанная картина.
Декомпозиция — ключевое слово здесь. Большая тема почти никогда не ищется одним запросом: «обзор рынка» распадается на игроков, цены, доли, тренды, регулирование. Research-агент сам разбивает её на такие узлы, по каждому запускает поиск, а потом сшивает результаты, отбрасывая дубли и противоречия. Параллельность даёт скорость: пока один поток собирает данные по ценам, другой работает по конкурентам. В итоге то, на что у человека ушёл бы час открытых вкладок, агент проходит за один проход — и возвращает не сырую выдачу, а структурированную сводку с источниками под каждым тезисом.
Как формулируется хороший поисковый запрос
Качество ответа на 80% определяется качеством запроса к поисковику. И тут есть нюанс, который многие упускают: поисковый запрос — это не разговорная речь.
Когда вы пишете агенту «слушай, а что там вообще сейчас происходит с этими новыми правилами по маркировке товаров, а то я совсем запутался» — это нормальная человеческая фраза, и агент её поймёт. Но в поисковик он отправит не её, а что-то вроде «маркировка товаров 2026 новые правила». Ключевые слова, существительные, год, конкретика — никаких «слушай», «а что там», «вообще».
Хороший запрос:
- состоит из ключевых слов, а не предложений;
- содержит конкретику — даты, названия, модели, цифры, если они известны;
- не тащит разговорный мусор («подскажи пожалуйста», «мне интересно»);
- при многогранной теме разбивается на несколько узких запросов (тут как раз помогает multi_search).
Агент делает эту трансформацию сам: вы пишете естественно, он переводит ваш вопрос в эффективный поисковый запрос. Но понимать механику полезно — если вы видите, что ответ получился размытым, часто помогает дать агенту больше конкретики, чтобы он сузил поиск.
Цитирование источников
Любой ответ, который агент строит на основе веб-поиска, сопровождается ссылками на источники. Это не формальность, а принцип: вы должны иметь возможность проверить, откуда взялась цифра, цитата или факт.
Когда агент говорит «по данным такого-то издания, цена выросла на 12%», рядом будет ссылка на эту публикацию. Это работает в обе стороны: вам это даёт возможность доверять выборочно (открыть и проверить спорный момент), а агенту — дисциплину не выдавать за факт то, под чем нет источника. Если факт не подкреплён ссылкой — это сигнал, что к нему стоит относиться осторожно.
Главное: что происходит, когда источник недоступен
Здесь самое важное отличие правильно построенного поиска от наивного. Интернет — среда враждебная для ботов. Сайты возвращают 403 (доступ запрещён), 429 (слишком много запросов), отдают пустые страницы, прячут контент за антибот-защитой. Маркетплейсы вроде Wildberries и Ozon режут автоматическое чтение почти мгновенно. Это норма, а не сбой.
Вопрос в том, что агент делает в этот момент. Наивная система, столкнувшись с пустым ответом, заполняет пробел тем, что «звучит правильно»: придумывает правдоподобные цены, генерирует несуществующие артикулы, выдумывает ссылки, которые ведут в никуда. Пользователь получает уверенный ответ — и не догадывается, что половина данных вымышлена.
EPIHEN устроен иначе. Если источник недоступен — агент честно об этом сообщает, а не выдумывает данные. При 403, 429 или пустом ответе он скажет «не смог получить доступ к источнику» — и не станет подставлять выдуманные ID товаров, цены или ссылки. Это жёсткое правило, встроенное в логику работы: лучше честное «не получилось», чем правдоподобная ложь.
На уровне платформы это подкреплено отдельным анти-фабрикационным механизмом. Если агент возвращает подозрительно гладкий результат — например, аккуратный список карточек товаров в ситуации, когда все веб-запросы были заблокированы, — это фиксируется как инцидент и разбирается. Система специально учится не доверять самой себе в моменты, когда у неё нет реальных данных под ответом.
Практический смысл для вас: если EPIHEN говорит «не смог получить информацию с этого сайта» — это не баг и не слабость. Это работающая защита. Вы получаете честную картину того, что реально удалось достать, а не красивую выдумку, на которую нельзя опереться при принятии решений.
Особенно остро это видно в задачах, где цена ошибки выражается в деньгах и времени: подбор товара, проверка цен, поиск контактов, сбор контактных данных компании. Выдуманный артикул отправит вас не туда; вымышленная цена сломает расчёт; несуществующая ссылка съест время впустую. Поэтому правило «нет источника — нет факта» здесь не вежливость, а защита от конкретного вреда. Агент скорее вернёт меньше данных, но реальных, чем больше — но наполовину придуманных.
Лимиты веб-поиска по тарифам
Веб-поиск использует платный внешний сервис (Perplexity Sonar), поэтому количество запросов зависит от тарифа:
- Free — 5 запросов web_search в день. Хватает, чтобы попробовать и решить разовую задачу.
- PRO — 30 запросов в день. Комфортно для регулярной работы с актуальной информацией.
- MAX — без лимита. Для тех, кто строит на поиске серьёзный research-процесс.
Чтение конкретной ссылки через fetch_url работает иначе — оно бесплатно для платформы, поэтому доступно на всех тарифах без жёстких ограничений. Если у вас уже есть ссылка, выгоднее дать её агенту напрямую, чем заставлять его искать то, что вы и так знаете.
Как это выглядит на практике
Соберём всё вместе на примере. Вы пишете: «найди, какие сейчас есть беспроводные наушники с шумоподавлением до 8000 рублей, и сравни топ-3».
Агент: понимает, что нужны свежие данные → формулирует поисковые запросы (ключевые слова, ценовой диапазон) → через web_search и marketplace-каналы собирает варианты → читает карточки товаров → если какой-то источник вернул 403, не выдумывает его содержимое, а отмечает «эту страницу прочитать не удалось» → сводит три реальных варианта с ценами, ссылками и характеристиками → даёт ответ с источниками.
Если бы задача была масштабнее — «сделай полный обзор рынка наушников с шумодавом за 2026 год» — в дело вступил бы research-агент со своим циклом декомпозиции и параллельного поиска.
Вывод
Свежесть данных — это не магия, а инструменты. Модель сама по себе застывает на дате обучения; агент оживляет её, давая доступ к интернету через веб-поиск, чтение страниц и исследовательские циклы. В EPIHEN это web_search через Perplexity Sonar, параллельный multi_search, научный academic_search, чтение страниц через browse_page и deep_read (включая соцсети и маркетплейсы), точечный fetch_url по конкретной ссылке и полноценный research-агент для глубоких тем.
Но самое ценное — не количество инструментов, а честность результата. ИИ с актуальной информацией полезен ровно настолько, насколько ему можно доверять. Поэтому ключевой принцип EPIHEN: каждый факт подкреплён источником, а когда источник недоступен — агент говорит об этом прямо, вместо того чтобы заполнить пробел выдумкой. Лучше честное «не нашёл», чем красивая ложь, на которую вы потом обопрётесь.