Почему разные AI видят текст по-разному?

TL;DR

Один и тот же текст три разных LLM могут «прочитать» по разному. Причина в трёх технических слоях: как текст режется на токены, в каком векторном пространстве он потом живёт, и какой фильтр (top-k) отбирает документы до того, как генеративная часть вообще успевает оценить качество. Если писать текст без учёта этой механики, статья может физически не долетать до финальной генерации в одной системе, при этом отлично работать в другой.

Пишу статью, оптимизирую заголовок, вставляю ключевые слова туда, куда учили пять лет назад для классического SEO – и получаю два противоположных результата. Яндекс цитирует материал в первой тройке источников со ссылкой прямо в ответе. Google AI Overview тот же текст демонстративно игнорирует, вытаскивая в ответ статью конкурента, которая написана хуже, короче и без единого практического примера.

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

Дальше – то, что я вынес из десятков таких экспериментов: почему токенизаторы (алгоритмы разбивки слов на кусочки для модели) режут одно и то же слово по-разному, почему embedding-пространства (числовые представления смысла текста) у моделей несовместимы друг с другом, и почему top-k – это буквально сетка, через которую ваш текст либо проходит, либо нет.

Что вообще значит «AI видит текст»

Фраза «AI видит текст» звучит так, будто где-то внутри модели сидит маленький гном, который открывает вашу статью и формирует мнение. На деле все конечно не так.

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

Сначала текст режется на токены – минимальные кусочки, с которыми модель умеет работать напрямую. Потом эти токены превращаются в векторы (наборы чисел, описывающие смысл) в embedding-пространстве, уникальном для каждой модели. И только затем, если речь о поисковых или RAG-системах (генерация ответа с подгрузкой найденных в интернете документов), включается механизм отбора документов – top-k (фильтр, который решает, какие материалы вообще долетят до генеративной части).

Три станции – три точки, где текст может «сломаться» или, наоборот, отлично пройти проверку. И на каждой станции у Yandex, Google, OpenAI и Perplexity стоят разные инженеры с разными решениями. Отсюда и разница в восприятии одного и того же текста.

Разберём каждую станцию по отдельности, начиная с самой первой и самой недооценённой – с токенизации.

Токенизаторы – разные «алфавиты» для одного и того же текста

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

Токенизатор не режет текст на слова. Он режет текст на частые подстроки, найденные статистически в тренировочных данных конкретной LLM. Алгоритмы называются BPE (Byte Pair Encoding, буквально «попарное объединение байтов») и SentencePiece (библиотека с открытым исходным кодом от Google для быстрой токенизации и детoкенизации текста) – это методы, которые находят самые частотные комбинации символов в огромном корпусе текстов и записывают их как отдельные «единицы смысла» для модели.

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

Результат такого разного подхода к обучению словаря – разное количество токенов на одно и то же русское слово. У Yandex частое русское слово может укладываться в один токен. У Gemini то же слово может распадаться на три-четыре субтокена (частей слова, каждая из которых считается отдельным токеном).

Казалось бы, какая разница модели, видит она слово «пылесос» целиком или по кусочкам «пыле» + «сос»? Смысл-то один. Но в этом и подвох: до того, как модель дойдёт до уровня семантики (смысла), она уже работает с этими токенами как с базовыми единицами. Если слово раздроблено на нетипичные кусочки, у модели возникает больше «шума» на входе, и статистическая связь между частями слова и остальным контекстом становится слабее.

Разберём конкретный пример. Пользователь вводит запрос «робот-пылесос для шерсти». Yandex, с его упором на русский словарь, скорее всего разрежет эту фразу на три цельных смысловых блока: «робот-пылесос», «для», «шерсти». Каждый блок – готовая, узнаваемая единица.

Gemini с мультиязычным словарём может пойти другим путём и разбить составное слово на менее очевидные куски: «роб», «от», «пыле», «сос». Смысл слова «пылесос» модель, конечно, восстановит на более глубоких слоях – архитектура трансформеров (тип нейросети, лежащий в основе большинства современных языковых моделей) достаточно устойчива к такому дроблению. Но сам процесс восстановления смысла требует больше вычислительных «усилий» модели, и в граничных случаях – например, при опечатках, сленге или нестандартном написании – вероятность потери связи растёт.

Что это значит для текста

Если в статье написано «робот пылесос» без дефиса, или используется разговорное сокращение типа «пылик», для одного токенизатора это будет цельная, узнаваемая единица, а для другого – набор рассыпанных сабтокенов, которые модели придётся склеивать заново, теряя часть точности на этом склеивании.

Естественные, стандартные словоформы без сленговых сокращений и с правильной пунктуацией (дефисы, кавычки, заглавные буквы там, где положено) проходят через любой токенизатор чище. Это не значит, что нужно писать канцелярским языком – живая речь тоже проходит нормально, если она грамматически корректна. Проблема начинается там, где авторы гонятся за «модным» написанием, слитным написанием сложных слов или транслитом вместо кириллицы.

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

Embedding-пространства – разная геометрия смысла

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

Тут важно понять одну вещь, которая сначала звучит контринтуитивно: у каждой компании – а часто и внутри одной компании – своё отдельное embedding-пространство. Модель, которая ищет документы (ретривер), и модель, которая генерирует финальный текст ответа, у Google, Yandex и большинства других игроков – это часто разные нейросети с разными весами, обученные на разных данных с разными целевыми функциями.

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

Пример с лужей, который объясняет всё

Возьмём слово «лужа» в контексте статьи про робот-пылесос, который иногда наезжает на лужу, оставленную питомцем, и размазывает её по полу.

Модель А обучалась в основном на технических обзорах, инструкциях и спецификациях. В её embedding-пространстве слово «лужа» в этом контексте окажется рядом с векторами «датчик перепада высот» (сенсор, который должен предотвращать наезд на препятствия и жидкости), «виртуальная стена» (программная граница, которую робот не пересекает) и «объём бака для сбора грязи».

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

Обе модели правы каждая в своём пространстве. Обе описывают одну и ту же реальную ситуацию. Но если ваша статья про робот-пылесос закрывает только технический ракурс – характеристики датчиков, мощность всасывания, объём контейнера – она отлично ложится в кластер Модели А и почти не пересекается с кластером Модели Б. И наоборот: чисто эмоциональный отзывный текст без единой цифры прекрасно резонирует с Моделью Б, но выглядит семантически «пустым» для Модели А.

Почему это критично для контента, который должен работать везде

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

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

Если статья закрывает только один из многих кластеров, она рискует быть отнесена одной из моделей к разряду «семантически неполных» – не потому что текст плохой, а потому что в векторном пространстве конкретной модели он просто не долетает до нужной зоны релевантности.

Тексты, где технический блок и пользовательский блок написаны раздельными разделами (не размазаны по одному абзацу, а выделены явно – например, отдельный подраздел с характеристиками и отдельный с реальным опытом использования), проходят через оба типа embedding-пространств заметно ровнее, чем тексты, где всё смешано в общий поток без структуры.

Top-k и реранкинг – грубый фильтр, о котором почти никто не пишет

Вот тут начинается самая практичная часть всей истории, и именно она объясняет, почему одна и та же статья может блистать в Яндекс и полностью пропадать из ответов Google AI Overview.

Есть два принципиально разных подхода к тому, как AI-система формирует ответ на запрос пользователя.

Первый подход – генеративная модель отвечает либо напрямую из данных, на которых её обучили (training data), либо через собственный встроенный retrieval-слой (механизм поиска релевантных документов), который у крупных игроков интегрирован прямо с их поисковым индексом. Так работают Google AI Overview, Gemini и YandexGPT в чистом режиме. Их система поиска – это, по сути, продолжение обычного поискового индекса компании, только с генеративной надстройкой сверху.

Второй подход – классический RAG (Retrieval-Augmented Generation, «генерация с дополнением через поиск»). Здесь top-k это буквально инженерный параметр конкретного программного пайплайна.

Как устроен RAG-пайплайн

В RAG-системе запрос пользователя сначала кодируется в вектор через embedding-модель. Точно так же кодируются в векторы все документы в базе (или в индексе, к которому у системы есть доступ). Дальше ретривер (модуль поиска) считает математическое сходство между вектором запроса и векторами документов и отбирает top-k документов с наивысшей оценкой сходства – это буквально «k штук документов, у которых оценка выше остальных».

После этого грубого отбора вступает реранкер – отдельная модель, чаще всего cross-encoder (тип модели, которая обрабатывает пару «запрос плюс документ» совместно, а не по отдельности, и поэтому даёт точнее оценку релевантности, хоть и работает медленнее и дороже вычислительно). Реранкер переупорядочивает кандидатов, отобранных на первом грубом шаге, и выбирает финальную, гораздо более узкую группу документов, которая реально попадёт в генеративную часть ответа.

У Perplexity, судя по описаниям её архитектуры в открытых источниках (не по официальным техническим спецификациям, которые компания не публикует полностью), пайплайн многоступенчатый. Сначала широкий отбор через комбинацию BM25 (классический алгоритм ранжирования по совпадению слов и их частоте, без учёта смысла) и семантического embedding-поиска – упор именно на recall (полноту охвата), то есть система старается не упустить потенциально релевантные документы, даже если их сотни. Затем идёт cross-encoder реранкинг для точности – уже гораздо более узкий и качественный отбор. И финальный слой – ML-реранкер с дополнительными сигналами вроде авторитетности домена и свежести публикации.

Точные цифры k на каждом слое публично не раскрываются. Реконструкции и разборы энтузиастов дают разные оценки, и доверять этим цифрам как официальным данным не стоит.

Пример, который делает всю эту механику понятной

Представим ситуацию: вы написали обзор «Топ-5 моющих роботов пылесосов 2026 года», где протестировали каждую модель, включая то, как она справляется с лужами от питомцев. Пользователь спрашивает у AI: «Какой пылесос не размазывает собачьи лужи?»

В Perplexity происходит следующее. Ретривер по эмбеддингам и BM25 грубо отбирает top-100 статей, где есть слова про собак, лужи и уборку. Ваша статья попадает в эту широкую сотню – потому что recall на этом этапе высокий, система старается охватить максимум потенциально релевантного контента, не особо фильтруя по качеству. Дальше вступает cross-encoder-реранкер. Он читает вашу статью по абзацам и видит: здесь реально описан тест функции объезда луж, есть конкретика, есть детали именно про эту проблему. Реранкер поднимает вашу статью в top-3. Итог – Perplexity цитирует вас со ссылкой прямо в ответе.

В Google AI Overview или АлисаAI от Яндекс ситуация другая. У них закрытые внутренние retrieval-слои, встроенные в общий поисковый индекс компании. Если ваш сайт не прошёл их первичный фильтр – например, из-за слабого ссылочного профиля, проблем с UX, отсутствия достаточных сигналов E-E-A-T – статья физически не долетает до генеративной части системы. AI просто сгенерирует ответ на основе материалов конкурентов, которые прошли их внутренний top-k отбор, даже если по содержанию ваш текст был бы полезнее для пользователя.

Главный практический вывод из всей этой механики

Top-k – про то, что ваш контент физически может не пройти самый первый, самый грубый математический отбор – отбор по сходству эмбеддингов – ещё до того момента, когда до него доберётся хоть какая-то модель, способная оценить реальное качество написанного.

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

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

Почему одна и та же статья может «выигрывать» у одной системы и «проигрывать» у другой

Если сложить три механики вместе – токенизацию, embedding-пространства и top-k фильтры – становится понятно, почему универсального рецепта «как написать текст, который AI полюбит» не существует в принципе. Каждая система на каждом из трёх уровней принимает свои решения, и совокупный эффект этих решений может как усиливать видимость текста, так и полностью её гасить.

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

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

В Google AI Overview тот же материал появился в выдаче заметно позже, спустя недели – хотя контент не менялся. Возможное объяснение (именно возможное, а не подтверждённый факт) – домену потребовалось время, чтобы накопить достаточные сигналы траста для тематического кластера «HR и рекрутинг», прежде чем внутренний ретривер начал стабильно пропускать материалы этого сайта в top-k своего закрытого индекса.

В YandexGPT материал вообще первое время не фигурировал в развёрнутых ответах, хотя по классическому поиску Яндекса страница неплохо ранжировалась. Здесь сыграл, скорее всего, эффект токенизации и embedding-пространства именно этой модели: часть терминологии в тексте (некоторые HR-термины вроде «оффер», «фидбэк», «riject-письмо») была написана в англо-русском смешанном варианте, что могло давать более рассыпанную токенизацию и, соответственно, более слабую векторную связь с типичными русскоязычными запросами пользователей.

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

Что можно контролировать?

Раз три уровня механики – токенизация, embedding, top-k – работают по-разному в каждой системе, логично спросить: а что тогда вообще имеет смысл делать оптимизатору/автору, если управлять всеми тремя уровнями напрямую невозможно?

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

Для уровня токенизации

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

Заголовки и подзаголовки писать цельными смысловыми фразами, без искусственного разрыва устойчивых словосочетаний. Например, если пишете про «умный дом», не разбивайте эту устойчивую фразу лишними словами между «умный» и «дом» в заголовке – это увеличивает шанс на аномальную токенизацию у моделей, чей словарь плохо знаком с этим конкретным контекстом.

Для уровня embedding-пространств

Закрывать одновременно несколько типов контента в рамках одной статьи, даже если тема кажется чисто технической или чисто эмоциональной на первый взгляд.

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

Для уровня top-k и ретривера

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

• Конкретика и фактура в тексте – реранкеры, особенно у RAG-систем типа Perplexity, судя по наблюдаемому поведению, отдают предпочтение материалам с проверяемыми деталями, а не общими рассуждениями без фактов.
• Структура текста с чёткими смысловыми блоками – облегчает работу и грубому ретриверу на этапе embedding-сравнения, и точному реранкеру на этапе cross-encoder-анализа.
• Сигналы E-E-A-T на уровне всего домена – ссылочный профиль, авторство с реальной экспертизой, история публикаций по теме – это то, что накапливается месяцами и годами, а не правится за один день редактирования текста.
• Свежесть публикации и её регулярное обновление – некоторые ретриверы, судя по наблюдениям, учитывают дату последнего обновления страницы как сигнал релевантности, особенно для тем, где актуальность быстро меняется.

Ни один из этих пунктов не гарантирует прохождение top-k фильтра конкретной системы – слишком много скрытых переменных. Но совокупность этих факторов заметно повышает вероятность попадания в узкий круг документов, которые реально долетают до генерации.

Частые ошибки при попытке «угодить всем AI сразу»

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

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

Второе заблуждение – убеждённость, что если статья хорошо ранжируется в классическом поиске (обычная десятка синих ссылок), то она автоматически хорошо пройдёт через top-k фильтры генеративных AI-систем. Классическое ранжирование и retrieval-слой генеративной системы – это часто разные механизмы даже внутри одной компании, с разными весами и разными сигналами. Хорошая позиция в классическом поиске повышает шансы, но не гарантирует прохождение через отдельный AI-ориентированный ретривер.

Третье заблуждение – игнорирование факта, что embedding-модели меняются со временем. Компании периодически переобучают или заменяют свои модели для поиска и генерации. Текст, который отлично проходил через фильтры полгода назад, может внезапно потерять видимость не из-за изменений в самом тексте, а из-за того, что изменилась модель, через которую этот текст теперь оценивается. Это не повод паниковать при каждом колебании видимости, но повод периодически перепроверять старые материалы, а не считать однажды написанный текст навечно оптимизированным.

Четвёртое заблуждение – попытка написать текст «одинаково нейтрально» для всех кластеров embedding-пространства, избегая как чисто технического языка, так и чисто эмоционального, в надежде попасть куда-то «в середину». По наблюдениям, такой усреднённый подход часто проигрывает обоим полюсам сразу – текст оказывается недостаточно техническим для одного кластера моделей и недостаточно живым для другого. Гораздо эффективнее явно закрывать оба полюса раздельными блоками внутри одной статьи, чем размывать их в единый нейтральный поток.

Что это вообще все значит

Механика, описанная выше, означает среди прочего и то, что специалисту по поисковой оптимизации теперь приходится разбираться не только в ссылочном профиле и плотности вхождений, но и в архитектуре ретриверов, логике токенизации, принципах работы embedding-пространств – в том самом слое, который ещё три года назад казался исключительно внутренней кухней ML-инженеров. Этот слой больше не чужой; он стал рабочим контекстом, и игнорировать его – значит добровольно выключить себя из процесса.

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

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

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