Фрейминг применительно к информационному поиску (IR) — это особенность статистических паттернов, возникающая из-за разной формулировки запроса и документа, которую алгоритм поиска учитывает при выборе наиболее подходящей информации.
Можно представить его как контекстное облако, в которое завернута информация. Алгоритм ищет не «истину», а наилучшее статистическое попадание запроса в это облако. Если попадание есть — алгоритм выдает результат, даже если содержательно это неправильный фрейм (например, вы искали научную статью, а нашли новостную заметку с теми же ключевыми словами).
Современный семантический поиск работает именно так — он сопоставляет эмбеддинги страниц и запросов через вычисление косинусной близости (или скалярного произведения). Именно здесь кроется главный «конфликт фреймов», который ломает многие поисковые системы.
Как устроено сопоставление (Bi-Encoders vs. Cross-Encoders)
В продвинутых системах (например, Google на базе Transformer’ов или SPLADE) страницы заранее индексируются в виде векторов (эмбеддингов). Ваш запрос тоже превращается в вектор. Поиск — это просто поиск ближайших соседей (ANN) в многомерном пространстве.
Но здесь есть ключевая инженерная деталь: обычно используются би-энкодеры. Это значит, что эмбеддинг страницы считается абсолютно независимо от эмбеддинга запроса. Модель кодирует страницу саму по себе, а запрос — сам по себе, а потом сравнивает готовые векторы.
Проблема фрейминга: Запрос vs. Документ
Это самый важный момент. Ваш вопрос содержит скрытое допущение, что «шаблон страницы» и «запрос» лежат в одной плоскости. В реальности язык запроса и язык документа — это два разных статистических распределения (разные фреймы):
Запрос обычно короткий, вопросительный, содержит глаголы действия: «Как починить кран?», «Купить iPhone 15 дешево».
Документ — это длинный, повествовательный, утвердительный текст: «Для ремонта смесителя потребуется отвертка…», «Интернет-магазин предлагает iPhone 15 со скидкой».
Статистический паттерн, который выучивает Bi-Encoder, заключается в том, чтобы максимально сблизить векторы разных фреймов, если они часто встречались вместе в интернете. Если в тренировочном датасете (например, MS MARCO) запрос «как починить» часто стоял рядом с ответами, содержащими слово «ремонт», модель выучит, что вектор запроса (как починить) должен быть близок к вектору документа (ремонт).
Но если фрейм запроса меняется (например, пользователь пишет сленг: «Кран течет, что делать?»), а в обучающей выборке такого сочетания не было, модель не экстраполирует логику, а просто ищет статистически ближайшие слова. Семантика (смысл) здесь вторична по отношению к частотной сочетаемости токенов в прошлом.
«Проклятие шаблонов» (Shortcut в поиске)
Поскольку поисковик сопоставляет эмбеддинги, он обожает находить дешевые статистические якоря.
Пример: вы ищете «вредные продукты». В датасете страница А пишет: «ВОЗ называет сахар, соль и трансжиры вредными». Страница Б пишет: «Опасные пищевые добавки разрушают печень». Эмбеддинг модели может сильнее притянуть запрос к странице Б, потому что слово «опасные» в обучающих текстах чаще стояло рядом со словом «вред», чем слово «ВОЗ» с «вредом» (хотя фактически страница А — это прямой авторитетный ответ).
Поисковик ранжирует не по истинности ответа на ваш фрейм, а по статистической близости векторов. Это приводит к тому, что страницы, написанные под тот же «фрейм» (сенсационный, кликбейтный), всегда будут выигрывать у страниц с сухим научным фреймом, потому что их векторы статистически чаще пересекаются с эмоциональными запросами.
Проблема интента как часть фрейминга
Самый сложный случай — когда один и тот же запрос имеет разные интенты, а внутри каждого интента — разные фреймы.:
Запрос: «Apple». Вектор страницы может быть про фрукты, про компанию, или про лейбл звукозаписи.
Эмбеддинг усредняет контекст. Если в интернете в 60% случаев слово «Apple» стоит рядом с «iPhone», а в 40% — рядом с «яблоком», вектор запроса «Apple» без контекста будет лежать где-то посередине между этими двумя кластерами. В результате поиск потеряет резкость и выдаст смесь из того и другого. Чтобы победить это, современные системы используют контекстуальный фрейминг на лету: подмешивают к запросу эмбеддинги из истории пользователя или геолокации, искусственно смещая вектор запроса в нужный кластер.
Когда вы пишете контент, вы не можете одновременно закрыть все интенты на одной странице — это приведёт к усреднению и потере релевантности. Поэтому стратегия строится так:
Сначала вы определяете главный интент запроса (смотрите на топ выдачи: если все страницы — магазины, интент коммерческий).
Затем внутри этого интента вы выделяете ключевые фреймы (те уточнения, которые чаще всего встречаются в PAA, подсказках и заголовках конкурентов).
Вы решаете: либо создаёте отдельные страницы под каждый фрейм (если они сильно различаются по смыслу), либо объединяете их на одной странице в виде отдельных блоков/секций (если они дополняют друг друга).
Как поисковики борются с этим фрейминг-разрывом?
Понимая, что сопоставление двух независимых эмбеддингов (страница vs запрос) — это борьба с разными статистическими фреймами, инженеры используют трюки:
Query Expansion (расширение запроса). Перед тем как превратить запрос в вектор, модель переписывает его. Она добавляет слова, типичные для фрейма документа. Вместо «Как чинить» она генерирует внутреннее представление «Инструкция по ремонту, шаги, инструменты». Это искусственно сдвигает вектор запроса ближе к кластеру документа.
Кросс-энкодеры для переранжирования (второй проход). Первый проход (быстрое сопоставление векторов) выдает 1000 кандидатов. Затем в дело вступает тяжелая Cross-Encoder модель. Она склеивает запрос и страницу в одну строку [CLS] Запрос [SEP] Страница [CLS] и смотрит на них вместе. Эта модель видит взаимодействие фреймов и может сказать: «Хотя ваши векторы далеки, в контексте этого конкретного абзаца речь идет именно о том, о чем спрашивают». Это частично исправляет ошибки изолированного эмбеддинга.
Система ищет не «смысл», а статистический перевод с языка запросов на язык документов.
Главная уязвимость здесь — узость запроса. У страницы эмбеддинг богатый (1000 токенов), у запроса — бедный (3-5 токенов). Модель вынуждена угадывать, какой именно «угол» страницы (фрейм) релевантен. Если вы ищете «Статистика смертности от COVID», модель найдет страницу, где эти слова стоят близко. Но если вы ищете «Насколько опасен коронавирус на самом деле», модель может выдать конспирологический сайт, потому что его фрейм (скептицизм) статистически ближе к вашему запросу, чем фрейм сухой официальной статистики, даже если официальная статистика — единственный верный источник.
Гибридный пайплайн
Комбинированная оценка (ключевые слова + эмбеддинги + переранжирование) — это многоуровневый инженерный подход к компенсации разрыва фреймов, позволяющий учесть как лексические (точные), так и семантические (контекстные) статистические паттерны. Однако это не устраняет проблему глобально, а лишь повышает вероятность того, что выбранный документ будет соответствовать статистической близости к запросу, но не обязательно — смысловой истине или новым трендам.
Ключевые слова (TF-IDF / BM25) — лексический якорь
Это грубый, но надежный способ борьбы с перекосом эмбеддингов.
Как борется с фреймингом: эмбеддинги любят «усреднять» смысл. Если вы ищете редкое техническое название «Клевер луговой», эмбеддинг может случайно потянуться к общему смыслу «растений». BM25 жестко требует точного вхождения токенов.
Что дает: гарантирует, что страница, где слово написано именно так, как в запросе, всегда попадет в топ кандидатов, независимо от того, как ее «переосмыслил» семантический вектор.
Сопоставление эмбеддингов (Bi-Encoder / Dense Retrieval) — семантический мост
Это главный борец с лексическим разрывом фреймов (когда мысль одна, а слова разные).
Как борется с фреймингом: вы ищете «Как избавиться от икоты», а в статье написано «Методы купирования диафрагмального спазма». BM25 покажет 0 совпадений. Эмбеддинг же сблизит эти фреймы, потому что в обучающих текстах эти понятия часто стояли рядом.
Что дает: затаскивает в выдачу документы, написанные на экспертном языке, подходящие под ваш пользовательский (бытовой) фрейм.
Переранжирование (Cross-Encoder): судья с полным контекстом
Это самый тяжелый и умный этап. Первые два этапа сравнивают запрос и документ по отдельности (похожесть двух векторов). Кросс-энкодер склеивает их в одну строку и смотрит на взаимодействие.
Как борется с фреймингом: первые два этапа могли выдать 1000 документов, где просто есть похожие слова. Кросс-энкодер читает весь абзац и понимает контекстное отрицание. Например, запрос: «Яблоко не красное». Би-энкодер выдаст кучу страниц про красные яблоки (потому что они статистически близки), а кросс-энкодер, увидев отрицание, резко занизит их рейтинг. Он понимает отношение между частями фрейма.
Что дает: исправляет ошибки первых двух «быстрых» этапов, отсекая ложные статистические корреляции.
Главные ограничения метода
Если представить, что идеальный поиск — это 100%, то эта комбинация добивает вас до ~85-90%. Дальше стена:
Она не устраняет «сдвиг распределения» (Distribution Shift). Модель эмбеддингов обучена на данных 2023 года. Если в 2026 году появился новый сленг (например, «скуф» или «нормис»), все три этапа беспомощны. В эмбеддингах этих слов нет (OOV — Out of Vocabulary), BM25 их не знает, а кросс-энкодер их никогда не видел. Фрейм нового поколения ломает систему.
Она не отличает «авторитетность» от «совпадения». Если запрос имеет конспирологический фрейм («Правда о вакцинах»), эмбеддинги найдут точно такой же конспирологический фрейм в тексте. Cross-encoder увидит, что текст идеально отвечает на запрос, и поднимет фейковую статью в топ, потому что она статистически релевантна. Авторитетность (истина) — это внешний фактор, его нет в векторах.
Она не решает проблему «Многозначности» (Polysemy) без контекста. Запрос «лук». Bi-Encoder найдет смесь из овощей, стрелков и моды. BM25 — тоже. Cross-Encoder — тоже (он не знает, кто вы). Комбинация не угадает ваш фрейм, пока вы не добавите слово «репчатый» или «модный». Это требует внешнего знания (истории пользователя), которого в пайплайне нет.
Ветвление запроса как следующий шаг эволюции
Query Fan-Out (или декомпозиция запроса) — это следующий шаг эволюции в решении проблемы фрейминга и семантического разрыва.
Если комбинация «BM25 + эмбеддинги + реранкер» была эшелонированной обороной, то Query Fan-Out — это стратегия «разведки боем»: вместо того чтобы искать один «идеальный» документ, система запускает несколько параллельных поисковых групп, каждая из которых атакует проблему под своим углом.
Разберем, в чем суть, чем это отличается от классического расширения запроса (Query Expansion), и почему это мощный, но не идеальный инструмент.
Ключевое отличие: Query Expansion vs. Query Fan-Out
Это принципиально разные подходы, и их часто путают.
Query Expansion (классическое расширение) – это «растягивание» одного запроса. Вы берете исходный запрос и добавляете в него синонимы, связанные термины или уточнения. В итоге у вас все равно один поисковый запрос, просто более длинный и размытый. Он отвечает на вопрос: «Какие еще фразы означают то же, что и мой запрос?».
Query Fan-Out (декомпозиция): «размножение» одного запроса на множество независимых. Система не изменяет исходный запрос, а генерирует десятки (иногда сотни) совершенно новых, самостоятельных подзапросов. Каждый из них ищет информацию независимо и параллельно. Он отвечает на вопрос: «Какие еще вопросы нужно задать, чтобы проверить или дополнить ответ на мой запрос?».
Как Query Fan-Out борется с фреймингом?
Проблема фрейминга в том, что один запрос может иметь множество граней (интентов). Классический поиск пытается угадать эту единственную грань и часто ошибается. Fan-Out же обходит эту проблему, рассматривая все возможные грани одновременно.
Пример из реальной жизни: запрос «Лучшая CRM для стартапов». Вместо того чтобы гадать, что для вас важнее (цена, интеграции или безопасность), система Fan-Out запускает параллельный поиск по всем этим подвопросам:
«Недорогая CRM для стартапов»
«CRM с большим количеством интеграций»
«CRM, соответствующая GDPR»
«Отзывы стартапов о выборе CRM»
Затем она собирает все результаты, синтезирует их и выдает вам один емкий ответ, где будут рассмотрены все эти аспекты. Таким образом, проблема выбора «правильного» фрейма снимается за счет того, что система просто проверяет их все.
Типы подзапросов
Fan-Out генерирует не просто синонимы. Согласно патентам Google, он создает валидационные запросы разных типов:
Уточнение (specification): добавляет ограничения для точных данных.
Кларификация (clarification): проверяет разные значения неоднозначных слов (например, «Apple» как компания или фрукт).
Следствие (entailment): ищет факты, которые должны быть правдой, если ответ верен.
Обобщение (generalisation): расширяет контекст, чтобы понять родительскую категорию.
В чем «слабое место» этого подхода?
Несмотря на всю мощь, Query Fan-Out не является панацеей и имеет свои ограничения:
Зависимость от качества синтеза. Самый слабый этап — это сборка (синтез) финального ответа из множества разрозненных кусочков. LLM может отлично найти информацию, но ошибиться в ее агрегации, создав логически противоречивый или поверхностный ответ.
Проблема «глубины против ширины»: система отлично покрывает широту темы (много аспектов), но может потерять глубину по каждому из них. Она скорее выдаст обзор, чем исчерпывающее руководство.
«Галлюцинации» в подзапросах. Если LLM неправильно сгенерирует сами подзапросы (например, придумает несуществующий аспект), вся последующая цепочка поиска будет построена на ложном фундаменте.
Не решает проблему авторитетности. Как и в прошлом примере, если конспирологический сайт лучше отвечает на один из подзапросов, его информация может быть включена в финальный синтез, даже если она недостоверна.
Query Fan-Out (декомпозиция запроса) — это эволюционный шаг вперед по сравнению с классическим расширением запроса. Вместо того чтобы пытаться подогнать один запрос под разные фреймы, он кардинально решает проблему, запуская множество параллельных подзапросов, каждый из которых покрывает свой собственный фрейм или аспект исходного вопроса, а затем синтезирует из полученных частей целостный ответ. Однако он не устраняет проблему полностью, а переносит фокус уязвимости на этап синтеза и генерации самих подзапросов.
Каждому SEO-специалисту хорошо известны текстовые анализаторы, определяющие релевантность по медианным и усреднённым данным по топу выдачи (Just-Magic, SEOlemma и т.п.). SEO-специалист, копирующий структуру, частотность и объём топовых страниц, пытается искусственно воспроизвести статистический паттерн, который алгоритм уже признал «правильным» для данного фрейма. Однако это работает только до тех пор, пока алгоритм не обновится или пока не изменится сам фрейм запроса.
Фрейминг — это то, как информация представлена (язык, акценты, структура). Поисковик, ранжируя страницы, не «понимает» контент, а сопоставляет его вектор с векторами запросов. Но вектор страницы зависит не только от смысла, но и от формы подачи:
Частотность ключевых слов → усиливает определённые координаты в эмбеддинге (модель запоминает, что эти слова важны для данного запроса).
Объём текста → даёт больше «точек» для векторного представления, увеличивает плотность семантического покрытия.
Анкоры ссылок → внешний контекст, который тоже превращается в вектор и добавляет странице статистических «якорей», подтверждающих её принадлежность к определённому фрейму.
Структура (заголовки, списки) → влияет на то, как модель сегментирует текст, выделяя главные темы.
Когда SEO-специалист анализирует топ-10 и «копирует» эти параметры, он фактически подгоняет свою страницу под тот статистический портрет, который алгоритм считает наиболее близким к запросу. Это осознанная или неосознанная работа с фреймингом: вы говорите алгоритму: «Я такой же, как эти страницы, которые ты уже признал релевантными для этого фрейма».
Почему это работает (но не всегда)
Работает, потому что алгоритмы действительно чувствительны к статистическим паттернам на уровне токенов, длины, структуры. Гугл и Яндекс используют тысячи факторов, и многие из них коррелируют с формой подачи. Не всегда, потому что:
Алгоритмы становятся умнее — они уже различают переоптимизацию и могут штрафовать за «точное копирование» (например, одинаковые списки, шаблонные тексты).
Фрейм запроса может меняться: сегодня топ выдачи состоит из длинных гайдов, завтра — из коротких видео-аннотаций (из-за изменения пользовательских предпочтений). Копирование устаревшего фрейма не поможет.
Вы рискуете скопировать фрейм конкурента, но не его интент. Например, все топ-страницы пишут длинные статьи, но пользователи на самом деле ищут быстрый ответ — тогда ваша длинная статья не удовлетворит интент, и поведенческие факторы убьют ранжирование.
Как связать это с более правильной стратегией
Вместо механического копирования статистики, более продвинутый подход — фрейм-ориентированный аудит:
Соберите топ выдачи не только по ключевым словам, но и по типу контента (обзор, сравнение, инструкция, список), по тональности (экспертный, развлекательный, официальный) — это и есть фреймы.
Определите, какой фрейм лидирует для вашего запроса и соответствует ли он вашей ЦА. Если ваш продукт премиум, а топ — дешёвые обзоры, копировать их фрейм — ошибка. Лучше создать свой, но подтвердить его авторитетность и качество.
Статистику (частотность, объём) используйте как ориентир, а не как догму. Добавляйте уникальные смысловые блоки, которые закрывают скрытые подфреймы (например, часто задаваемые вопросы, сравнения, реальные кейсы) — это обогатит ваш эмбеддинг и позволит выигрывать не за счёт копирования, а за счёт полноты покрытия.
Практика копирования топ-статистики — это грубая, но эффективная эмпирика, которая пытается угадать, какие статистические паттерны алгоритм считает признаками «правильного фрейма». Однако она не решает проблему фрейминга, а лишь подстраивается под текущие веса. В долгосрочной перспективе побеждают те, кто изучает реальные интенты пользователей и создаёт контент, который закрывает не один фрейм, а несколько, обеспечивая тем самым устойчивость к обновлениям алгоритмов и изменениям пользовательского поведения.
Смена фокуса: от «ключа» к «фрейму»
Современные поисковые алгоритмы (особенно на базе нейросетей) перестали быть «словарными» — они сопоставляют эмбеддинги (смысловые векторы) страниц и запросов. Этот подход, заложенный ещё в классической модели DSSM (2013), сегодня реализуется через более мощные трансформерные энкодеры: DPR и Sentence-BERT для однокомпонентных векторов, а также ColBERT для более точного попиксельного (потокенового) сравнения. Это значит, что классический SEO-подход «забить текст точными вхождениями» умирает.
Вместо этого ваша задача — покрыть все возможные фреймы (интенты) пользователя на одной странице или в кластере страниц. Например, для запроса «как выбрать велосипед» нужно закрыть не только «советы по выбору», но и подфреймы: «бюджетные модели», «для города/гор», «отзывы», «сравнение брендов». Если вы пишете один текст, включайте в него синонимы, связанные термины и ответы на уточняющие вопросы (FAQ) — это помогает алгоритму «увидеть» вашу страницу как релевантную сразу для нескольких семантических бликов, повышая шанс попасть в топ даже без точного попадания запроса.
Техническая архитектура под декомпозицию
Поисковики и ИИ-системы на поиске всё чаще используют Query Fan-Out — декомпозицию запроса на десятки подвопросов. Чтобы ваш сайт выигрывал в такой системе, стройте внутреннюю перелинковку и структуру разделов не линейно, а звездообразно: создавайте «пилотную» страницу-хаб (обзорную) и множество дочерних материалов, каждый из которых закрывает один узкий подзапрос. Используйте микроразметку (FAQPage, HowTo, QAPage) — она помогает поисковым алгоритмам явно идентифицировать, какой именно фрейм вы закрываете. И главное: анализируйте семантическое ядро не по частотности, а по смысловым кластерам (например, через кластеризацию поисковых сниппетов конкурентов). Если ваша страница статистически ближе к запросу по эмбеддингам, чем страница конкурента, она выйдет вперёд даже при меньшем количестве внешних ссылок.
Перестаньте гнаться за частотными и бесполезными ключевиками. Ваш KPI теперь — глубина и ширина покрытия интентов на целевой странице. Оценивайте контент через призму вопросов целевой аудитории, а не просто списка слов. И помните: даже самая крутая семантика бесполезна, если вы не позаботились о том, чтобы каждый подфрейм был логически связан перелинковкой — именно так алгоритмы «склеивают» разрозненные фрагменты в единый авторитетный ответ.
