Практика современной data-driven SEO едва ли возможна без анализа семантики, основанной на векторных представлениях контента – эмбеддингов. Для специалистов доступно множество моделей, каждая из которых применима для одних задач и может быть неэффективной для других. Рассмотрим, на что обращать внимание при выборе.

Что влияет на выбор #

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

Поставленные SEO-задачи #

Конкретный характер работы определяет требуемый тип эмбеддингов:

• Кластеризация поисковых запросов и группировка ключевых слов требуют моделей, чувствительных к семантической близости (SBERT, RuBERT).
• Поиск семантических дубликатов или рерайтов контента — внимания к структуре и лексическому разнообразию. Здесь идеально отрабатывают модели типа embeddingGemma.
• Ранжирование и рекомендация схожих страниц — баланса между общим смыслом и спецификой домена (например, модель, обученная на википедийных или коммерческих текстах).
• Классификация страниц по тематикам или интентам — устойчивости к длине документов (длинные модели Transformer с адаптацией).

Рабочее программное обеспечение (ПО) #

Экосистема и стек, в которые интегрируется модель.

• Чаще всего для простых задач используется Screaming Frog SEO Spider с подключенной моделью. В этом случае контент векторизуется сразу после сканирования.
• Если используется Python (например, в ETL-пайплайнах или ноутбуках), то подойдут библиотеки sentence-transformers, transformers, fasttext, Gensim.
• При работе с Java/Scala (Spark, Elasticsearch) — модели ONNX, TensorFlow SavedModel или встроенные векторизаторы Elasticsearch (ELSER, E5).
• Для Go, C++ или микросервисной архитектуры — лёгкие модели (например, Universal Sentence Encoder в TensorFlow Lite, или загрузка эмбеддингов через Triton/TorchServe).
• Если ПО предполагает пакетную векторизацию (например, Airflow + ClickHouse), критична совместимость с форматами векторов (Float32, бинарные, квантованные).

Технические ресурсы #

Для извлечения эмбеддингов (векторизации контента) могут потребоваться серьёзные технические ресурсы в зависимости от используемого стека, модели и объёмов контента.

• Вычислительные мощности (CPU/GPU) — для трансформеров требуются GPU (например, 24+ ГБ VRAM для больших моделей) или серверные CPU с AVX-512. Для задач с большими объёмами данных (миллионы документов) — распределённая обработка (Spark, Dask).
• Память и хранилище — количество и размерность эмбеддингов: 768-мерные векторы для 10 млн документов займут ~30 ГБ в виде float32. Нужно предусмотреть сжатие (PCA, Product Quantization, бинарные векторы).
• Время инференса. Для обработки в реальном времени (например, подборка LSI-похожих страниц на лету) требуются модели с малым latency: FastText, BERT tiny, или дистиллированные версии. Для offline-обработки (раз в сутки) допустимы большие “тяжёлые” модели (RuBERT-large, LaBSE).
• Энергопотребление как критерий выбора важно для облачных или edge-решений: модели на CPU экономнее, но медленнее; GPU быстрее, но дороже.

Если вы работаете с одной из проприетарных моделей, подключенных по API к SFSS (например, я долго использовал ada-002 от OpenAI почти для любых задач в этой сфере), вам не потребуется ни GPU, ни значительный расход ресурсов процессора на вашей рабочей машине. При работе через API все вычисления происходят на серверах провайдера. Ваш компьютер выступает только в роли клиента, отправляющего запросы и принимающего ответы. Ни GPU, ни значительная загрузка CPU для этого не нужны — достаточно интернет-соединения и минимальных ресурсов для HTTP-клиента.

Исключение – модели, подключенные с локального сервера (Ollama или LM Studio). Однако и они чаще всего не потребуют много ресурсов вашего компьютера.

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

Модели вложений для базовых задач SEO #

В своей практике для рутинных задач я использую чаще всего две модели:

• EmbeddingGemma
• multilingual-e5-large

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

По сути, выбор между multilingual-e5-large и embeddingGemma — это классический компромисс между «проверенным поколением» и «новым, перспективным классом».

Сравнение двух моделей в деталях

Рассмотрим особенности каждой модели более подробно.

multilingual-e5-large — работаем с семантикой углубленно #

Эта модель лучше всего раскрывает свои возможности при использовании с sentence-transformers в Python. Она стабильно показывает высокие результаты на множестве бенчмарков, особенно в задачах поиска (retrieval) и классификации. Его часто рассматривают как «золотой стандарт» среди моделей сравнимого размера.

• Большая размерность. 1024 измерения против 768 дают модель с большей «вместительностью», что часто означает способность улавливать более тонкие нюансы. Это как сравнивать лист бумаги А4 и А3 — на большем можно уместить больше деталей.
• Проверенная архитектура. Построен на базе хорошо изученной и стабильной архитектуры XLM-RoBERTa, что упрощает отладку, тонкую настройку и понимание его поведения.

Главный недостаток: малое контекстное окно. Иными словами, вам либо придётся «нарезать» свой контент на осмысленные чанки определенного размера, либо модель сама обрежет ваш контент, отбросив его часть. В этом есть и положительный смысл: точно так же работает и Google, и вы можете на практике оценить, как реальная поисковая система видит ваш контент.

EmbeddingGemma — новый класс, оптимизированный для эффективности #

Идеальна для работы в Screaming Frog SEO Spider. Просто подключаете её с собственного локального сервера и запускаете сканирование сайта. По итогам получаете выгрузку векторных вложений по каждому URL, список страниц, определенных как семантические дубли, страницы, определенные как несоответствующие общей тематике. В самом SFSS можно визуализировать семантику сайта (грубо, в общих чертах, чтобы определить возможные проблемные места для дальнейшего анализа точечно).

Её главный козырь — невероятная легкость. В 10 раз меньший размер в памяти в сравнении с multilingual-e5-large делает его идеальным кандидатом для работы на CPU, Edge-устройствах или в средах с ограниченными ресурсами. Эту модель изначально «затачивали» для работы на мобильных устройствах, и запустить её реально даже на смартфоне.

Благодаря большому контекстному окну можно векторизовать даже объёмные документы. 2048 токенов против 512 — это колоссальное преимущество при работе с большими документами, подробными инструкциями или чатами, где важна история диалога.

Однако есть и недостатки. Несмотря на звездные общие показатели EmbeddingGemma, на некоторых задачах он может уступать старшему конкуренту.

• Проблема оценки сложности. Из-за малого количества параметров и оптимизации под скорость, модель может быть более «строгой» в оценке семантической близости. Тесты показывают, что multilingual-e5-large склонен давать более высокие, «сглаженные» оценки схожести, в то время как EmbeddingGemma выставляет более жесткие и контрастные оценки.
• Производительность для конкретных языков. Некоторые исследования для неевропейских языков показывают, что EmbeddingGemma может заметно уступать более тяжелым моделям, таким как multilingual-e5-large. Эта закономерность характерна для многих новых мультиязычных моделей, и ее важно учитывать, хотя для работы с русскоязычным контентом никаких проблем не отмечено.

Качество векторизации #

Сравним две модели не просто по цифрам, а по их «почерку»:

• EmbeddingGemma дает «контрастные» вектора. Это как строгий, но справедливый критик: она хорошо видит четкие границы между понятиями, что часто полезно для задач, требующих однозначного разделения данных. Но она экономит ресурсы (~200MB RAM в квантизованном виде) и поэтому критически важна для интеграции в ваш процесс через Screaming Frog.
• multilingual-e5-large дает «гладкую», более «щедрую» оценку семантической близости. Она склонна показывать мелкие, нюансированные связи там, где Gemma могла бы поставить почти ноль. Это и есть та самая «абсолютная точность», которая делает её лучшей в строгих бенчмарках (набирает ~75.9% против ~71.6% у Gemma на некоторых тестах).

На практике это означает, что для одного и того же запроса поиска модель e5 может вернуть 10 результатов с оценкой релевантности от 0.70 до 0.95, а Gemma — только 5 результатов с оценками от 0.85 до 0.95, посчитав остальные нерелевантными.

Простой пример: извлекаем векторные вложения с сайта с помощью embeddingGemma получаем две чётко выраженные о очень далёкие группы страниц без промежуточного контента. Фактически, структура сайта разваливается на два типа страниц (в данном случае – речь о сервисе eSIM для туристов. Одна группа – выбор страны, другая – тарифы. И ничего между ними).

Векторизация контента с помощью multilingual-e5-large наглядно демонстрирует, что не всё так чётко, выявляя и подгруппы, и связи между ними. С этим уже можно работать более эффективно.

e5-large обнаружила значительно большее количество подгрупп в сравнении с embeddingGemma

Эти особенности и определяют применение двух отличающихся моделей в рабочем процессе.

• Быстрая, лёгкая, но грубая модель embeddingGemma используется в процессе сканирования сайта для первичной фильтрации и сортировки контента на данных.
• Более ресурсоёмкая и точная multilingual-e5-large обрабатывает отобранный список кандидатов – более точно, более эффективно для решения задач по семантике. Например, диаграммы рассеяния через UMAP или t-SNE на векторах от e5-large дадут вам гораздо более содержательную картину семантических кластеров, чем на «контрастных» векторах Gemma. Для задачи «найти дублирующийся контент, который звучит по‑разному, но означает одно и то же» — e5-large незаменим.