Устройство ИИ-поиска

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

Поиск можно запустить по внутренним базам данных, а можно искать по веб-документам, используя собственные поисковые индексы, внешние поисковики вроде Google или другие API. Именно так работают ChatGPT Search, Perplexity, Brave Search, Google AI Overview и до недавнего времени You.com.

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

Проблемы веб-поиска для ИИ

Проблема #1: Низкое качество контента

Веб давно перестал быть библиотекой знаний. SEO-оптимизация, контент-фермы, AI-generated текст, бесполезные в информационном плане мемы и бесконечные ленты видео - всё это превратило интернет в свалку низкокачественной информации. RAG, построенный на таких данных, выдаёт такие же низкокачественные ответы.

Проблема #2: Производное знание вместо первоисточников

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

Пример: Stack Overflow содержит сотни вопросов про создание git-репозитория. Все они так или иначе дублируют содержание одного официального man-файла. Эти документы появились не из-за нехватки информации, а из-за:

• Лени разбираться в документации

• Языкового барьера (не все читают по-английски)

• SEO-оптимизации

• Социальных факторов, например, желания набрать "голосов" на простых вопросах и ответах

• Несовершенства поиска и навигации

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

Почему это критично именно для ИИ:

Современные LLM обладают способностью к логическому выводу (inference). Им не нужны готовые объяснения и "разжеванные" интерпретации - модель сама может сделать простейшие логические заключения из исходных данных.

Давайте вернемся к примеру с git. Человеку на Stack Overflow нужно было готовое решение его конкретной проблемы. Но LLM достаточно дать исходную документацию - она сама выведет ответ на любой конкретный вопрос пользователя. Все остальные сотни документов на тему создания git-репозитория, хранящиеся в поисковом индексе, здесь попросту не нужны.

Проблема #3: Ограниченность и однообразие результатов

Google и другие веб-поисковики возвращают ограниченное количество результатов (обычно 10-20), и эти результаты страдают от отсутствия diversity - разнообразия источников и точек зрения.

Для человека это не критично: мы ищем один быстрый ответ, кликаем на первую ссылку и уходим. Но для RAG-систем это фундаментальная проблема:

• LLM строит ответы на основе синтеза информации из нескольких источников

• Чем разнообразнее входные данные, тем полнее и объективнее итоговый ответ, а однообразные входные данные приводят к узкому контексту и неполным ответам

Веб-поисковики оптимизированы для людей, а не для ИИ. Они возвращают топ-10 самых "популярных" результатов, которые часто дублируют друг друга по содержанию. RAG-система получает не 10 разных точек зрения, а 10 вариаций одного и того же - что сводит на нет преимущества многодокументного контекста.

Проблема #4: Статистика ≠ Достоверность

Эта проблема проистекает из предыдущей. Казалось бы, большое количество документов должно означать большую статистическую достоверность. Но это работает только если источники независимы и качественны.

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

Как я строил Space Frontiers

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

Нюансы построения ИИ-поиска

Выбор векторной базы данных

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

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

Для Space Frontiers с миллиардом документов HNSW не подходил. Существуют альтернативные векторные индексы - DiskANN, ScaNN и другие, более устойчивые к работе с диском. Они ограничивают количество обращений к диску за счет иной структуры индекса и худшей средней производительности, потому они не умирают при нехватке оперативной памяти.

Для векторной части поиска я выбрал AlloyDB со ScaNN индексом. Едва ли какой-то другой векторный поиск способен обслуживать более миллиарда 1024-мерных векторов на единственной машине с 256 ГБ оперативной памяти. А авторство Google давало какие-никакие гарантии развития и поддержки индекса.

Выбор эмбеддингов

Проверьте, что выбранные эмбеддинги хорошо работают с основным языком вашего корпуса и основным доменом ваших документов. No-brainer модели в первой половине 2025 года - Jina, BGE-M3, Qwen3 (если у вас достаточно GPU).

Выбор сервера эмбеддингов

Другое важное решение - где будет происходить инференс эмбеддингов? Варианты с инференсом прямо в Python-коде рядом с вашим процессом индексации или рядом с Search API очень унылы: плохо масштабируются, плохо параллелятся, плохо управляются, имеют низкую производительность в области сериализации и десериализации входных и выходных данных.

В начале пути я честно пытался поддерживать Triton Inference Server на моих железках с GPU и сам собирал модели. Честно - Triton образца 2025 года был ужасен. Конфликты версий, компиляция моделей по витиеватым issues в GitHub, ручное раскладывание файлов. Каждая новая тестируемая модель эмбеддингов заставляла тратить несколько дней на её сборку. Да, производительность была образцовая, но в конце концов я пожертвовал 20% производительности и переехал на vLLM, который позволяет запускать новые модели за часы, а не дни, и легко разворачивается в Kubernetes вместе с легковесной gRPC-оберткой. Последнее немаловажно - перегонка эмбеддингов в JSON и обратно, если вы используете какой-нибудь FastAPI, может откушать немало перформанса.

Архитектура поиска: гибридный подход

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

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

Но векторный поиск плохо работает с точными формулировками и цитатами, числами и датами, таблицами и структурированными данными. Еще одна критическая проблема - новые слова, которых не было в обучающих данных векторной модели.

Может показаться, что новых слов в языке не так много, но это заблуждение. В английском языке новое слово появляется примерно каждые 98 минут. В научном домене ситуация еще драматичнее: каждую неделю появляются новые названия лекарств, генов, заболеваний, ИИ-моделей и техник. Все это остается за бортом векторной модели, если вы не умеете её дообучать.

Очевидное решение тут - гибридный поиск - комбинация векторного индекса для поиска по семантике и полнотекстового BM25 поиска для точных совпадений, длинного хвоста запросов и редко употребляемых слов.

В моем случае векторный поиск и BM25 работают параллельно, объединенные результаты переранжируются легкой XGBoost моделью и тяжелой моделью на основе эмбедов.

Стоит отметить, что я экспериментировал с ColBERT (Contextualized Late Interaction over BERT) - теоретически красивым подходом, где вместо одного вектора на документ хранится вектор на каждый токен, а затем делается late interaction между токенами запроса и документа. На практике это оказалось нерентабельно: нужно хранить в 10-1000 раз больше векторов, индексация занимает вечность и может завалить движок, запросы работают десятки секунд. ColBERT работает только на малых корпусах (сотни тысяч документов). Для миллионов и миллиардов документов же нужны такие ресурсы, что их цена перевалила мой бюджет на несколько порядков.

Индексация: качество против количества

Когда начинаешь строить поисковый индекс, возникает соблазн следовать максиме поисковых компаний типа Яндекс и Google: "хочешь нарастить качество поиска - увеличивай количество документов в индексе".

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

Но если вы возьмете обычный BM25 из ElasticSearch или векторный движок (Qdrant, Vespa, Milvus - тысячи их) и попытаетесь загрузить туда десяток миллиардов документов, ваш топ окажется забит "нерелом": дубликатами с непонятных доменов, SEO-оптимизированным спамом, низкокачественными переводами и пересказами.

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

Неконтентные фичи ранжирования

Хорошо, допустим вы всё же хотите добавить неконтентные фичи в вашу формулу ранжирования.

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

Вторая группа фичей - графовые метрики, подсчитываемые на основе ссылочной массы. Простейший пример - PageRank. Чем чаще на документ ссылаются, тем более он важен, что находит отражение в значении его PageRank.

Если вы работаете с веб-контентом, то можете попробовать использовать датасет CommonCrawl, содержащий снимок веба и предпосчитанные графовые метрики, способные неплохо улучшить ваше ранжирование. Похожий подход можно использовать при работе с академической литературой - CrossRef свободно распространяет датасет метаданных всех публикаций, имеющих DOI-номер, и в каждой записи указан набор ссылок на другие публикации. По такому графу можно посчитать аналогичный Citation Rank.

Для сообщений из социальных сетей можно использовать их метрики просмотров и цитирований из API.

Третья группа часто используемых фичей - authority. Эти фичи оценивают, насколько можно доверять источнику страницы. Поэтому когда вы видите страницу, для которой не подсчитана графовая метрика (она слишком новая, на нее ещё нет ссылок), то можно использовать authority домена в качестве аппроксимации-прогноза будущего качества страницы.

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

Chunking: искусство разбиения документов

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

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

Что работает:

• Overlap между чанками для сохранения контекста

• Подмешивание метаданных в текст чанка: добавляйте заголовки разделов, авторов, даты публикации

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

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

Дедупликация как необходимость

Даже в хорошей базе полно дубликатов:

• Одна статья в препринте и финальной публикации

• Разные форматы одного документа (PDF, HTML, текст)

• Переводы и локализации

LLM нет необходимости показывать десятки одинаковых текстов, это лишь ухудшит качество ответа. Дедупликация должна стоять в центре вашего процесса индексации документов. Более того, дедупликация нужна не только на этапе индексации, но и на этапе формирования финального набора результатов перед подачей в LLM - это помогает увеличить diversity результатов. Маленькая подсказка - если вы используете векторный поиск, то у вас уже есть эмбеддинги чанков, которые вы можете использовать для нечеткой дедубликации. Просто настройте и запустите кластеризацию эмбеддингов множества релевантных документов и возьмите по вектору от каждого построенного кластера.

Метаданные и фильтрация

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

Дело в том, что уже на этапе работы с запросом LLM может понять, что пользователю нужна информация только из определенного подмножества документов. Если пользователь просит "pubmed depression research 2025", то не надо искать везде - вы уже понимаете, что нужен только pubmed и только 2025 год. Таким образом вы можете заранее выфильтровать нерелевантные документы по атрибутам.

Ранжирование и обработка запросов

Diversity важнее релевантности

Удивительный факт: LLM + поиск среднего качества может давать результат лучший, чем LLM + поиск хорошего качества. Дело в определении "хорошести" поиска. За десятилетия пользование Google мы начали считать, что хорош тот поиск, что вернет нам кучу релевантных результатов. Релевантность тем выше, чем выше шанс, что пользователь кликнет на результат и останется на веб-странице.

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

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

Важная ремарка: обычная метрика recall@n работает не совсем так как надо, если вы строите AI-поиск. LLM умеет агрегировать разные документы в единый ответ, поэтому группа разнообразных документов может хорошо ответить на вопрос пользователя, несмотря на то, что по отдельности они могут казаться неподходящими под запрос. Представьте: пользователь ищет "короткую биографию Линкольна", а у вас в базе три отдельных документа про его рождение, политическую карьеру и смерть. Они все вместе релевантны, но могут быть пропущены из-за недостаточной релевантности каждого отдельного документа более общему запросу. Поэтому далее под recall имеется в виду diversity-recall - теоретическая метрика, отражающая полноту охвата в контексте всех представленных LLM документов.

Обработка запросов для улучшения recall

1. Query reformulation

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

2. Related queries generation

Генерируем несколько вариаций запроса через LLM и ищем по всем:

Пример:

Query: "как работает трансформер"
Generate related queries: "архитектура transformer модели", "self-attention mechanism", "BERT GPT attention layers"

Таким образом, вы достанете больше разнообразного контента, вероятно содержащего части ответа на исходный вопрос.

3. HyDE (Hypothetical Document Embeddings)

Просим LLM сгенерировать гипотетический ответ на вопрос, затем ищем по эмбеддингу этого ответа (или его чанков) вместо исходного вопроса.

Плюсы HyDE: Даёт небольшой, но стабильный прирост на корпусах со смешанным содержанием (короткие заметки + длинные монографии).

Минусы HyDE: Дополнительная latency и стоимость LLM-вызова для генерации гипотетического ответа.

4. Извлечение интента

При возможности, из запроса извлекаются аспекты, которые затем преобразуются в дополнительные фильтры поискового запроса. Например, запрос "recent news" означает, что мы можем брать только те документы о новостях, которые не старше 7 дней (конкретная длина выбирается под каждый источник отдельно). Для запроса "latest posts from @channel_name" можно вообще не запускать текстовый поиск, а выполнить запрос вида 

SELECT * FROM posts WHERE channel_name = '...' ORDER BY date DESC LIMIT 10

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

Тренировка формулы переранжирования

После изначальной выборки N результатов из поискового индекса их можно переранжировать более дорогими способами. Один из самых простых вариантов - использовать reranker-модели. Более трудозатратный способ - самостоятельно натренировать деревянные модели типа XGBoost. Такие модели можно запускать на объемах 100-1000 документов без серьезного ущерба для latency.

Своя модель поможет вам интегрировать все доступные атрибуты в ранжирование, если они у вас есть. Графовые фичи, authority, freshness, контентные фичи - всё интегрируется в общее ранжирование именно на этом этапе.

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

И да, вам никто не мешает комбинировать все способы переранжирования по нарастанию вычислительной сложности. Достаньте 1000 документов из вашей базы обычным векторным поиском, отберите топ-200, используя XGBoost-модель, отберите 100 документов, используя тяжелый reranker, в конце попросите LLM выбрать 20 наиболее релевантных. Некоторые известные поисковые системы так и работают.

Поиск для агентов

Почему поиск через API критичен

В августе 2025 года Microsoft объявила о закрытии Bing Search API - одного из немногих публичных API для веб-поиска. Это событие стало важным моментом для экосистемы AI-агентов: тысячи разработчиков остались без доступа к программному интерфейсу поиска.

Perplexity отреагировала быстро, запустив свой Perplexity Search API в сентябре 2025. С учетом позиционирования как "search api for ai ecosystem", получается, что это не просто замена Bing - это признание фундаментального сдвига: поиск для агентов работает иначе, чем поиск для людей.

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

И почему такого API до сих пор нет?

Поисковые API возвращают небольшой фрагмент исходного документа, который, по их мнению, наиболее релевантен запросу. Подразумевается, что потребитель дальше самостоятельно загрузит веб-документ и скормит его LLM. Тут возникает сразу несколько проблем:

• Нужно самостоятельно загружать десятки веб-страниц - это дополнительная инфраструктура, обработка ошибок, таймауты

• В случае научных статей или книг объем одного документа может быть большим - может возникнуть необходимость отбирать наиболее релевантные части внутри большого документа, и эта работа ложится на клиента

Гораздо удобнее, когда поиск умеет отдавать неограниченно большие релевантные сниппеты потребителю. Почему же так не происходит в мире больших поисковиков?

Проблема авторского права

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

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

MCP: как правильно проектировать тулы для агентов?

MCP (Model Context Protocol) - это новый стандарт для взаимодействия LLM с внешними инструментами. При проектировании MCP важно помнить, что для его дизайна верны все те же принципы, что люди наработали при написании промптов. Поэтому не надо пытаться перенести всё ваше REST API как есть в MCP!

Принцип 1: Каждый инструмент - одна чёткая функция

В противном случае модель может запутаться и дернуть не тот инструмент.

❌ Плохо: Один эндпоинт /search с 20 параметрами

{
  "query": "quantum computing",
  "filters": {
    "date": {"from": "2024-01-01", "to": "2025-01-01"},
    "sources": ["arxiv", "pubmed"],
    "authors": ["John Doe"],
    "min_citations": 5,
    "document_type": "article",
    "language": "en",
    ...
  }
}

✅ Хорошо: Отдельные, логически изолированные инструменты

- search_scientific_papers(query, date_from, date_to, limit=50)
- search_by_author(author_name, topic, limit=50)
- filter_by_citations(results, min_citations)
- search_standards(standard_name, version)
- search_books(query, publisher, limit=50)

Принцип 2: Параметры должны быть простыми и не вложенными

Та же проблема, что и в прошлом пункте, дополняется тем, что модели приходится рисовать сложно-вложенные JSON. Не надо.

❌ Плохо:

{
  "search_config": {
    "query": {
      "text": "quantum computing",
      "operators": {
        "and": ["quantum", "computing"],
        "not": ["classical"]
      }
    },
    "filters": {
      "metadata": {
        "publication": {
          "date": {"range": {"gte": "2024"}}
        }
      }
    }
  }
}

✅ Хорошо:

{
  "query": "quantum computing",
  "exclude_terms": ["classical"],
  "date_from": "2024-01-01",
  "limit": 50
}

Принцип 3: Общее количество инструментов - не больше 10-15

LLM плохо справляются с большим количеством доступных инструментов. Если у вас 50 эндпоинтов - агент запутается в выборе.

Принцип 4: Хорошее описание инструмента критично

LLM выбирает инструмент на основе его описания. Если описание плохое - агент будет использовать не тот инструмент.

❌ Плохо:

def search(query: str) -> List[Document]:
    """Search for documents"""

✅ Хорошо:

def search_scientific_papers(
    query: str,
    date_from: Optional[str] = None,
    min_citations: int = 0,
    limit: int = 50
) -> List[ScientificPaper]:
    """
    Search for peer-reviewed scientific papers in our curated database.
    Returns up to 'limit' results (default 50, max 200).
    
    Use this tool when you need:
    - Academic research papers
    - Peer-reviewed publications
    - Citations and bibliographic data
    
    Do NOT use this for:
    - Books (use search_books instead)
    - Standards/specifications (use search_standards)
    - Social media content (use search_social)
    
    Args:
        query: Search query (e.g. "quantum computing algorithms")
        date_from: Filter papers published after this date (ISO format: YYYY-MM-DD)
        min_citations: Minimum number of citations (default: 0)
        limit: Maximum number of results to return (default: 50, max: 200)
    
    Returns:
        List of scientific papers with metadata (title, authors, abstract, citations)
        Results are sorted by relevance, then by citation count
    """

Выбор LLM-модели

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

Планирование запроса стоит выполнять reasoning-моделями - они лучше справляются с поиском неявных намерений в поисковом запросе.

Начиная с лета 2025 года практически все модели, как open source, так и проприетарные, достаточно качественно следуют инструкциям, и я перестал видеть ошибки, связанные с тем, что модели генерируют невалидный JSON. Да, качество ответов отличается, и более свежие модели генерируют более качественные ответы и лучше проходят needle-in-haystack бенчмарк, поэтому при возможности выбирайте последние из доступных моделей.

Заключение

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

• Качество источников важнее их количества

• Diversity результатов важнее точной релевантности

• Возможность фильтрации и планирования важнее универсальных эвристик

• API и инструментарий должны быть спроектированы с учетом особенностей работы LLM