Агентный поиск с дополнением. Как устроен ИИ-поиск в 2026 и как в него попасть
Поиск в 2026 году больше не работает по схеме «запрос — десять ссылок — вы сами разбираетесь». И даже первое поколение ИИ-поиска «запрос — нашли страницы — модель собрала ответ» уже устарело. Между вашим вопросом и финальным ответом стоит цепочка из пяти привратников — планировщик, маршрутизатор, извлечение, попарное сравнение и критик.
Главное
- Между вопросом и ответом ИИ-поиска стоит цепочка: планировщик, маршрутизатор, извлечение, критик и сборщик.
- Один вопрос запускает от 5 до 20 внутренних под-запросов, поэтому одной сильной страницы мало — нужна глубина кластера.
- Фрагменты сравниваются попарно: выживает самодостаточный абзац с сущностью, условием и фактами.
- Российский контур тоже агентный: Алиса AI сравнивает источники попарно.
Оглавление
Я проектирую сайты как семантические коконы, и в этой статье объясню, почему агентный поиск превращает такую архитектуру из «хорошей практики» в обязательное условие. Если ваша работа над видимостью всё ещё рассчитана на одноразовое извлечение, вы оптимизируете систему, которой уже нет.
Что такое агентный поиск и чем он отличается от простого
Классический поиск с дополнением (по-английски RAG, retrieval-augmented generation — генерация ответа на основе найденных документов) был линейным конвейером. Пришёл запрос, система перевела его в векторное представление, достала верхние фрагменты из индекса, отдала их языковой модели, модель написала ответ. Цитирование отслеживалось просто, потому что набор источников совпадал с набором найденных фрагментов.
Агентный поиск устроен иначе. Один вопрос пользователя запускает не одно извлечение, а от пяти до двадцати внутренних под-запросов. Система сама планирует эти под-запросы, выбирает под каждый свой инструмент, читает промежуточные результаты и только потом решает, что доказательной базы достаточно, и собирает ответ.
| Простой поиск с дополнением | Агентный поиск |
|---|---|
| Одно извлечение на запрос | 5–20 под-запросов на запрос |
| Один инструмент (похожие тексты) | Маршрутизатор выбирает инструмент под задачу |
| Нет проверки черновика | Критик оценивает и отправляет искать заново |
| Цитаты = найденные фрагменты | Цитаты = выжившие после пяти стадий |
Простой поиск ломался на четырёх вещах. Он не вытягивал составные вопросы, где нужно пять извлечений вместо одного. Он не умел исправиться после плохого первого результата. Он не выбирал инструмент под задачу — для «какая сегодня ставка по ипотеке» нужен вызов структурированных данных, а не похожие тексты. И он не проверял сам себя перед публикацией. Подробный разбор этой эволюции есть у iPullRank.
Пять привратников, через которых проходит ваш контент
Реверс-инжиниринг невозможен, пока вы не нарисуете систему, которую разбираете. Вот каноническая схема.
Планировщик
Читает вопрос и раскладывает его на план — несколько под-запросов и порядок их выполнения. Это и есть «веер запросов».
Маршрутизатор
Решает, каким инструментом доставать ответ на каждый под-запрос — векторный поиск, поиск по словам, вызов внешнего интерфейса с данными, запуск кода, загрузка живой страницы. Это самый недооценённый узел всей цепочки. Если у вашей темы есть поверхность для вызова инструмента, а вы её не предоставили, маршрутизатор вас просто пропустит.
Извлечение
Каждый инструмент — отдельная подсистема. На вход идёт под-запрос, на выходе — фрагменты-кандидаты.
Критик-редактор
Оценивает черновик ответа на достаточность, противоречия, свежесть и разнообразие источников. Если что-то не так, отправляет агента искать заново. Это привратник, который выбрасывает из финального ответа больше всего контента.
Сборщик
Составляет финальный ответ со ссылками, обычно после финального попарного пересравнения выживших кандидатов.
Сами свойства — планирование, вызов инструментов, многошаговость и саморефлексия — описаны в фундаментальных работах: ReAct, Toolformer, IRCoT и Self-RAG. Корни подхода — в работе Google REALM ещё 2020 года.
Что из этого уже подтверждено патентами
По отраслевому разбору патентного следа, Google подал заявки почти на каждый узел этой цепочки.
- Планирование и веер запросов — патент US11663201B2 о генерации вариантов запроса обученной моделью.
- Маршрутизация по источникам — US20240362093A1 об ответе по пользовательскому корпусу через вызовы внешних интерфейсов.
- Память диалога — US20240289407A1 о поиске с сохранением состояния беседы.
- Рефлексия и ранжирование — US20250124067A1 о попарном ранжировании через подсказки.
- Сборка ответа — US11769017B1 о генеративных сводках поисковой выдачи.
Вывод простой. Агентная цепочка — это не выдумка стартапов, а производственная архитектура, к которой Google шёл в патентах с 2018 года.
Как то же самое работает у Яндекса
Англоязычные авторы почти всегда забывают про российский контур, а для моих проектов он часто важнее. Поэтому разберу его отдельно.
Сервис Нейро Яндекс показал в 2024 году, и его архитектуру подробно описал ML-руководитель направления в блоге Яндекса на Хабре. Логика там такая. Вопрос пользователя сначала переформулируется в один поисковый запрос отдельной небольшой моделью, которая читает последние реплики диалога и держит контекст. Дальше работает обычный Яндекс Поиск, из верхних документов маленькая модель вырезает релевантные фрагменты, а затем предсказатель выбирает ровно пять документов, на которых строится ответ. Финальный ответ пишет специализированная модель, обученная не выдумывать факты и подтверждать каждый кусочек ссылкой. Отдельно у команды есть разметка подтверждённости, которая отличает прямую цитату от вывода и ловит искажения.
К маю 2026 картина изменилась. Осенью 2025 года Яндекс переименовал линейку в «Алиса AI» и добавил агентные навыки — выполнение цепочек действий, а не просто ответы. Седьмого апреля 2026 года вышло крупное обновление поиска с усиленной Алисой AI и инструмент Вебмастера для ИИ-ответов. Новую архитектуру Яндекс описывает как побеждающую в попарном сравнении со счётом 60 на 40 при на четверть более эффективном выводе. Это тот же механизм попарного сравнения, что и в западных системах. Источники для проверки — разборы Ашманов и партнёры и Rozetked.
Что это значит на практике. Российский контур тоже стал агентным и тоже умеет отсекать источники в попарном сравнении. А ещё у Яндекса есть прямой рычаг управления — директива в robots.txt, которой можно запретить или разрешить использование страниц в ИИ-ответах. Этим стоит управлять осознанно.
Шесть сдвигов в работе с контентом
Здесь — то, ради чего вы читаете. Шесть конкретных следствий.
Побеждать нужно в десятках под-запросов, а не в одной выдаче
Одна хорошо ранжируемая страница больше ничего не гарантирует. Система дробит вашу тему на под-запросы и ищет под каждый отдельно. Глубина кластера перестала быть приятным дополнением и стала структурным требованием — ровно то, что даёт семантический кокон.
Атомарные фрагменты бьют монолитные статьи и теперь выживают попарно
Каждый под-запрос достаёт фрагменты, а не страницы целиком. Потом эти фрагменты сравниваются попарно с фрагментами конкурентов. Значит, абзац должен быть самодостаточным — именованная сущность в первом предложении, явное условие применимости, плотность фактов, таблицы и списки, которые модель процитирует без двусмысленности. Всё, что требует «прокрутить вверх за контекстом», проиграет. Как именно писать такие абзацы — в материале про пассаж-инженерию.
Сущности-мосты решают, попадёте ли вы в многошаговый ответ
Когда первое извлечение нашло сущность А, второе ищет её связи. Если ваш контент — канонический мост между А и Б, вас процитируют в ответах, где пользователь даже не упоминал ваш бренд. Как строить такие мосты, я разбираю в материале про инженерию графа знаний.
Цикл рефлексии награждает контр-аргументы
Критик ищет в черновике подтверждения и противоречия. Контент, который честно разбирает исключения, крайние случаи и «когда это не работает», переживает проверку, а односторонний продающий текст критик помечает как предвзятый и выбрасывает.
Контент, который можно вызвать как инструмент
Калькуляторы, структурированные данные, интерфейсы с данными. Если в вашей нише инструмент полезнее статьи, маршрутизатор вызовет инструмент вместо прозы. Поэтому такие активы стоит делать и отдавать структурированно — это отдельный узел кокона. Пример такого актива у меня — чеклист GEO-готовности страницы.
Свежесть — это проверка на стадии критика
Дата изменения в разметке, версии в тексте, явное «по состоянию на такую-то дату». Это не косметика. Устаревший контент критик выбрасывает, даже если он выиграл попарное сравнение. С поведенческой стороны это смыкается с тем, что я разбираю в статье про поведенческие сигналы.
Объединяющая мысль. Классический контент затачивался под один момент оценки — выдачу. Агентный контент должен выиграть на пяти моментах для каждого под-запроса. Это на порядок больше поверхности, и те, кто строит под неё, получают накопительную гравитацию цитирования.
Почему обычные метрики цитируемости врут
Скажу прямо, потому что для всей категории измерений это неудобно. В простом поиске вы хотя бы видели вход и выход — страница либо попала в извлечение, либо нет. В агентном поиске каждый привратник между вопросом и ответом непрозрачен. Вы не знаете, какие под-запросы сгенерировал планировщик, какой инструмент выбрал маршрутизатор, каким конкурентам ваш фрагмент проиграл в попарном сравнении и что пометил критик. Вы видите только, попали вы в финальный ответ или нет.
Поэтому подсчёт цитат показывает выживших после пятиступенчатого фильтра, не наблюдая сам фильтр, и занижает реальный охват в три-десять раз. Честный путь вперёд — дистилляция. По-простому это значит поднять у себя локальную наблюдаемую копию цепочки «планировщик — маршрутизатор — критик», откалибровать её по тем цитатам, что вы реально видите в выдаче, и использовать как диагностический стенд. Локальный агент — не продакшн-система, но он наблюдаемый, а наблюдаемое лучше невидимого. Готовый открытый стенд для такого аудита выложил iPullRank.
Аудит, который можно провести за неделю
Дам два варианта — без инженерии и с лёгкой инженерией.
Часть без кода. Возьмите пять запросов, где цитирование реально двигает бизнес. Прогоните каждый через режимы глубокого исследования в ChatGPT, Gemini и Perplexity — там виден план и под-запросы. Выпишите все под-запросы в таблицу, по строке на каждый. Прогоните каждый под-запрос отдельным поиском и отметьте, попадает ли ваш контент в извлечение. Сравните охват по под-запросам с итоговой долей цитирования на исходных пяти запросах. Разрыв — это ваша проблема рефлексии или попарного проигрыша. Для каждого под-запроса, где вас нет совсем, классифицируйте причину — нет контента, контент слишком общий, плохая нарезка, нет разметки, нет инструментной поверхности, устаревшая дата. Эта классификация и есть вход в ваш контент-план на квартал.
Часть с лёгкой инженерией. Локальный стенд из той же пятиузловой схемы показывает то, что продакшн скрывает — на какой именно стадии выпал ваш контент, какой ваш абзац проиграл и с какой формулировкой. Это инженерная работа на одного человека, и она окупается калибруемой диагностикой.