Как нейросеть находит и выбирает источники

Любая система ИИ-поиска решает три задачи одновременно, и они противоречат друг другу. Ответ нужно найти быстро — пользователь не станет ждать десять секунд. Качество терять нельзя — ответ с ошибкой или не по теме обесценивает сервис. И всё это должно быть дёшево: каждый запрос стоит реальных денег на вычислениях, а запросов миллионы в день. Улучшить любой из трёх параметров легко, если пожертвовать двумя другими; вся инженерная работа в этой области — поиск баланса между ними.

Отсюда главное следствие для бизнеса: система постоянно экономит. Она не может позволить себе внимательно изучить каждую найденную страницу, поэтому на каждом этапе отбрасывает то, что обрабатывать дорого или непонятно, и оставляет то, что даёт максимум смысла при минимуме затрат. Сайт, который легко прочитать и из которого легко извлечь готовый факт, выигрывает не потому, что он «лучше» в человеческом смысле, а потому, что он дешевле в обработке.

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

RAG — почему модель вообще обращается к сайтам

RAG (Retrieval-Augmented Generation — «генерация, дополненная поиском»: retrieval — извлечение, поиск; augmented — дополненная; generation — генерация текста) — схема, по которой работают все современные ИИ-поисковики. Модель не отвечает по памяти: сначала она ищет документы по теме вопроса, затем формулирует ответ на основе найденного.

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

Сущности и триплеты — из чего модель собирает знание о компании

Найденный текст для модели — не цель, а сырьё. Из него она извлекает сущности. Entity (англ. «сущность») — объект реального мира, о котором идёт речь: компания, услуга, товар, человек, город, бренд. Сущность описывается атрибутами, то есть свойствами (у компании — название, адрес, телефон, режим работы; у услуги — цена, сроки, гарантия, география), и связями с другими сущностями.

И атрибуты, и связи модель представляет в виде триплетов (triple — «тройка»): «субъект — предикат — объект», то есть «о ком или о чём — какое отношение — к чему или какое значение». Например: «компания — работает в — Москве и области», «монтаж — занимает — один день», «гарантия — составляет — 10 лет». Из множества таких троек складывается граф знаний (knowledge graph) — база, в которой поисковые системы хранят факты об объектах и связи между ними. Именно на эти факты, а не на общее впечатление от текста, опирается модель, когда формулирует ответ.

Одна и та же сущность встречается во многих источниках: на сайте, в справочниках, на картах, в отзывах, в СМИ. Если из разных источников извлекаются одинаковые триплеты, факт подтверждается многократно и звучит в ответе уверенно. Если тройка «компания — находится по адресу — …» даёт два разных адреса, модель либо выбирает один наугад, либо не упоминает компанию вовсе.

Что это значит для сайта. Факт легче всего извлекается из предложения, которое уже построено как триплет: понятно, о ком речь, что утверждается и какое значение. «Гарантия на монтаж — 10 лет» превращается в факт без потерь, «мы даём долгую гарантию» — ни во что. Тот же принцип в машиночитаемом виде — микроразметка Schema.org (подробнее в блоке 15): каждое её свойство — готовый триплет «сущность — атрибут — значение». Поэтому важны и формулировки в тексте, и разметка, и одинаковые данные во всех карточках компании.

ANN и ScaNN — как ищут среди миллиардов страниц

Поиск по смыслу работает на векторах: текст превращается в набор чисел — координаты в пространстве смыслов, — и близкие по смыслу тексты оказываются рядом. Такой вектор называют эмбеддингом (embedding, англ. «вложение» — текст, «вложенный» в числовое пространство). Вопрос пользователя превращается в такой же вектор, и задача сводится к поиску ближайших к нему документов.

Сравнить запрос с каждым документом в базе — честный способ, но при миллиардах страниц он неприменим: ответа пришлось бы ждать минутами. Поэтому используется ANN (Approximate Nearest Neighbor — «приблизительный поиск ближайших соседей») — класс алгоритмов, которые сознательно жертвуют небольшой долей точности ради ускорения в сотни и тысячи раз. Система заранее делит пространство на области и при запросе просматривает только те из них, где ответ вероятнее всего, а остальное не трогает.

ScaNN (Scalable Nearest Neighbors — «масштабируемый поиск ближайших соседей») — библиотека Google Research (научно-исследовательского подразделения Google) для такого поиска, построенная на анизотропном квантовании векторов^[1]. Квантование — это сжатие: точные числа вектора заменяются приближёнными, чтобы хранить и сравнивать их быстрее. Анизотропное (от греч. «неодинаковый по направлениям») — значит, что ошибка сжатия допустима не везде одинаково: алгоритм сильнее штрафует погрешность там, где близость высокая, то есть в тех самых документах, которые попадут в ответ, и мирится с неточностью на далёких.

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

На открытом бенчмарке glove-100-angular ScaNN обошла одиннадцать других настроенных библиотек — они и были baseline в этом сравнении — и обрабатывала примерно вдвое больше запросов в секунду при той же точности^[2]. Бенчмарк (benchmark — эталонный тест) — общий для всех набор данных и правил замера, на котором сравнивают разные решения. glove-100-angular — около 1,2 млн векторов слов, полученных моделью GloVe (Global Vectors for Word Representation — «глобальные векторы для представления слов»), по 100 чисел в каждом; близость между ними считается по углу между векторами (angular — «угловой»).

Что это значит для сайта. Поиск приблизительный по своей природе. Гарантии, что подходящая страница будет найдена, не существует в принципе: она может оказаться в области, которую система в этот раз не просматривала. Отсюда две практические вещи. Во-первых, это одна из причин, по которым ответы нейросетей недетерминированы и один и тот же вопрос даёт разные результаты, — поэтому мы замеряем долю упоминаний, а не единичное попадание. До начала работ фиксируем baseline — исходную долю упоминаний компании по согласованному набору запросов — и каждый следующий замер сравниваем с ним: доля выросла — работы дают эффект, снизилась — ищем причину. Во-вторых, страница с размытой темой даёт вектор на периферии своей области и выпадает из просмотра чаще, чем страница, однозначно посвящённая одному вопросу.

MUVERA — как отбираются кандидаты

Один вектор на документ — это дёшево, но грубо: длинный текст сжимается до усреднённого смысла. Начиная с работы ColBERT (Contextualized Late Interaction over BERT — «отложенное контекстное сопоставление на основе BERT»; BERT — языковая модель Google 2018 года)^[3] в поиске используют многовекторные модели: документ описывается не одним вектором, а набором — по вектору на фрагмент. Качество поиска заметно выше, но сравнивать наборы векторов между собой для миллиардов страниц слишком дорого, и обычные алгоритмы ANN к такому сравнению напрямую неприменимы.

MUVERA (MUlti-VEctor Retrieval Algorithm — «алгоритм многовекторного поиска») — подход Google Research, который снимает это ограничение^[4][5]. Множество векторов документа сжимается в один вектор фиксированной длины — FDE (Fixed Dimensional Encoding, «кодирование фиксированной размерности»). Скалярное произведение двух таких FDE приближает ту же величину, которую дало бы полное сравнение всех векторов, причём с доказанной оценкой погрешности. Благодаря этому многовекторный поиск сводится к обычному ANN-поиску по одному вектору — к готовым решениям вроде ScaNN, которые уже работают в промышленной эксплуатации, — а точное сравнение всех векторов выполняется потом и только для отобранных кандидатов. Дорогая операция применяется там, где она уже окупается.

Результаты проверяли на наборе BEIR (Benchmarking Information Retrieval — эталонный набор для оценки поиска из полутора десятков разнородных коллекций: вопросы-ответы, научные статьи, новости, проверка фактов)^[6]. В качестве baseline взяли PLAID — прежнее лучшее решение для многовекторного поиска на основе ColBERT^[7]. По сравнению с ним MUVERA даёт в среднем примерно на 10% выше полноту выдачи (recall — доля нужных документов, которые система вообще нашла) при примерно на 90% меньшей задержке (latency — время от запроса до результата), а той же полноты достигает, отбирая в 2–5 раз меньше кандидатов^[4].

Что это значит для сайта. Отбор идёт на уровне фрагментов, а не страниц целиком. Длинная статья «обо всём сразу» даёт размытый сжатый вектор и проигрывает отбор. Страница, где каждый раздел посвящён одному вопросу и отвечает на него явно, формирует чёткие фрагменты и попадает в кандидаты чаще. Это техническое обоснование того, почему в GEO (Generative Engine Optimization — оптимизация под генеративный ИИ-поиск) структура текста важнее объёма.

ReFrag — почему в ответ попадает не весь найденный текст

Найденные документы надо передать модели, но длинный контекст (объём текста, который модель получает на вход вместе с вопросом) замедляет генерацию. ReFrag (REFRAG: Rethinking RAG based Decoding — «переосмысление генерации ответа в RAG»; разработка Meta Superintelligence Labs — исследовательского подразделения компании Meta, сентябрь 2025)^[8] решает это так: найденный текст режется на короткие фрагменты, каждый сжимается лёгкой вспомогательной моделью в одно числовое представление, и в основную модель передаются уже эти представления, а не полный текст. Отдельная политика отбора решает, какие фрагменты нельзя сжимать, и оставляет их в исходном виде.

Результат — ускорение выдачи первого токена до 30 раз и возможность обработать примерно в 16 раз больше контекста без потери качества^[8]. Токен (token) — минимальная единица текста для модели: слово, часть слова или знак препинания; модель пишет ответ токен за токеном, и время до первого из них — это время, через которое пользователь видит начало ответа. Baseline здесь — обычная схема, при которой модель получает весь найденный текст целиком.

Что это значит для сайта. В развёрнутом виде до модели доходят не все найденные фрагменты, а наиболее информативные. Абзац, который несёт конкретику — цифру, срок, условие, цену, — имеет шанс попасть в ответ дословно. Абзац из общих формулировок сжимается в представление и в итоговом тексте не проявляется никак. Это и есть механическая причина, по которой «мы предлагаем индивидуальный подход и гибкие условия» не попадает в ответы нейросетей, а «замер бесплатный, монтаж за один день, гарантия 10 лет» — попадает.

Вывод

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

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

Как мы применяем это на практике — на странице услуги GEO-продвижение.