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

Что такое текстовые встраивания?

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

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

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

Например, два клиента отправляют следующие сообщения:

«С моей подписки списали деньги дважды»: [0.21, -0.47, 0.83, ...]
«В моем аккаунте обнаружен дублирующийся платеж»: [0.19, -0.45, 0.80, ...]

Это упрощенные, иллюстративные векторы.

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

Варианты использования текстовых встраиваний в бизнесе

Текстовые встраивания используются в различных задачах обработки естественного языка (NLP), в том числе:

Семантический поиск: поиск релевантной информации на основе смысла. Delivery Hero использует встраивания продуктов и поисковых запросов наряду с текстовым поиском, чтобы помочь покупателям продуктов питания находить нужные товары. Например, поиск по запросу «обезжиренный йогурт» может выдать греческий йогурт или йогурт с жирностью 0.5%, даже если формулировка не совпадает точь-в-точь.
Классификация текста: категоризация текста, например, выявление спам-писем или сортировка документов по темам. MindCraft.ai разработала систему классификации документов, которая использует текстовые встраивания на базе трансформеров и машинное обучение для категоризации корпоративных документов и выявления конфиденциальной информации в целях соблюдения GDPR.
Кластеризация: группировка похожих документов или фрагментов текста для выявления закономерностей. Doczy.ai преобразует текст контрактов в эмбеддинги и группирует семантически связанные положения и концепции, даже если в разных контрактах схожие обязательства выражены с помощью разных формулировок.
Генерация с дополненным извлечением (RAG): извлечение релевантной информации, которую LLM может использовать для создания более точных и контекстно-зависимых ответов. Ring использует текстовые встраивания Amazon Titan в многоязычном RAG-чат-боте для извлечения актуальной документации поддержки перед генерацией ответов на вопросы клиентов на международных рынках.
Рекомендательные системы: предложение связанных статей, продуктов или другого контента на основе текстового сходства. Система JUDE от LinkedIn использует сгенерированные LLM текстовые встраивания описаний вакансий и профилей участников для улучшения рекомендаций по работе, фиксируя связи между бэкграундом кандидатов и доступными позициями.
Распознавание именованных сущностей (NER): помощь в выявлении и классификации имен людей, организаций и мест в тексте. Amazon Health Services использует NER для определения медицинских концепций в запросах клиентов, таких как заболевания, симптомы, лекарства и методы лечения. Она объединяет это понимание с поиском по сходству на основе эмбеддингов для соединения запросов с релевантными медицинскими товарами и услугами.
Машинный перевод: поддержка моделей, переводящих текст между языками. Transglot использует текстовые встраивания в памяти семантического перевода для поиска ранее переведенных отрывков с похожим смыслом, помогая процессам локализации повторно использовать существующие переводы.

Как работают текстовые встраивания?

Итак, как модель встраивания решает, какие числовые значения присвоить фрагменту текста, и почему мы должны ей доверять?

Все начинается с обучения. Модели встраивания учатся на больших массивах текста, ища закономерности в том, как слова используются вместе. Например, традиционные модели, такие как Word2Vec, учатся, предсказывая слово по его окружению, или наоборот. Современные модели, ориентированные на поиск, часто используют контрастивное обучение. Они обучены присваивать более высокие оценки сходства релевантным парам «запрос-документ», чем нерелевантным.

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

Токенизация. Сначала модель разбивает текст на более мелкие части, называемые токенами. Это могут быть целые слова, части слов или знаки препинания. Каждый токен получает числовой идентификатор из словаря модели, который сам по себе не несет никакого смысла.
Кодирование и пулинг. Модель обрабатывает эти токены, используя паттерны, изученные в ходе обучения, и создает вектор. Каждое число в векторе является координатой или компонентом, а измерение — это ось, вдоль которой это число определяет положение вектора. Каждое значение вносит свой вклад в положение текста в математическом пространстве, известном как пространство встраивания.
Расчет сходства. Чтобы найти связанный текст, поисковая система сравнивает эмбеддинг запроса с эмбеддингами документов, используя мерила сходства, такие как косинусное сходство или скалярное произведение.

Именно так интернет-магазины, например, возвращают товары, соответствующие поисковому запросу пользователя.

В чем разница между встраиванием слов, предложений и документов?

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

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

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

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

Насколько размер чанка влияет на качество эмбеддингов?

Достаточно сильно. По словам Рахула Кумара (Rahul Kumar), вице-президента по инженерному ИИ в Xenoss, задача заключается в том, чтобы подобрать размер чанка, который захватывает одну целостную идею без потери важного контекста. Он объясняет возникающий компромисс:

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

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

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

Текстовые эмбеддинги против поиска по ключевым словам

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

Но семантическое сходство не всегда означает релевантность. Шоу Талеби (Shaw Talebi), основатель AI Builder Academy, демонстрирует это ограничение на примере системы поиска по резюме. В случае Талеби при поиске «дата-инженера с опытом работы с Apache Airflow» только один из пяти лучших результатов упоминал Apache Airflow, и он занял третье место — несмотря на то, что в наборе данных этот навык указали еще три резюме.

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

Чтобы решить эту проблему, Рахул Кумар рекомендует выбирать подход к извлечению на основе того, в чем именно поисковая система терпит неудачу:

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

Кумар также рассказал, как его команда применила эти подходы на практике. В одном из проектов они запустили поиск по ключевым словам BM25 и векторный поиск параллельно, объединили результаты с помощью слияния взаимных рангов (RRF) и использовали LLM для повторного ранжирования первых 124 результатов до 6.

«Переход к графово-ориентированному извлечению, когда векторный поиск находит похожие латентные пространства, а затем выполняется двухшаговый обход графа, повысил качество ранжирования (nDCG) с 0,58 до 0,67 и сократил время извлечения p90 с 19 с до менее чем 3 с», — добавляет Кумар.

Типы моделей текстовых эмбеддингов

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

Модели статических текстовых эмбеддингов

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

Два известных метода:

: Разработанная Google в 2013 году, эта модель изучает представления на основе соседних слов с использованием двух архитектур: непрерывного мешка слов (CBOW), который предсказывает слово по его соседям, и skip-gram, которая предсказывает соседние слова по заданному слову.
GloVe (Global Vectors for Word Representation): Разработанная в Стэнфорде в 2014 году, она использует статистику совместной встречаемости слов для изучения взаимосвязей между ними.

Контекстуализированные языковые модели

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

BERT (2018, Google): Использует двунаправленное самовнимание для учета слов по обе стороны от токена. Например, модель генерирует разные представления для слова «банк» в предложениях «Я положил деньги в банк» и «Я сидел на берегу реки» (прим. в англ. языке используется омоним «bank»).
GPT (2018, OpenAI): Использует представления на основе трансформеров, которые учитывают предшествующий текст при предсказании следующего токена. Модели GPT в первую очередь предназначены для генерации текста.

Модели эмбеддингов предложений и документов

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

Doc2Vec: Расширяет обучение в стиле Word2Vec на предложения, абзацы и документы. Это может помочь группировать связанные статьи или классифицировать документы по темам.
Universal Sentence Encoder (USE): Разработан Google в 2018 году для создания представлений фиксированной длины для предложений и коротких абзацев с целью определения семантического сходства и классификации текста.
Sentence-BERT (SBERT, 2019): Разработан Нильсом Реймерсом (Nils Reimers) и Ириной Гуревич (Iryna Gurevych) в Техническом университете Дармштадта, он создан на базе модели BERT от Google и обычно используется для семантического поиска, обнаружения парафраз и кластеризации.
pplx-embed-v1 (2026, Perplexity): Передовая модель текстовых эмбеддингов, созданная для реального масштабного веб-поиска. Это семейство использует предварительное обучение на основе диффузии, чтобы превратить причинную языковую модель в двунаправленный энкодер. Она генерирует плотные эмбеддинги для независимо закодированных запросов и документов, используя обучение с учетом квантования для снижения затрат на хранение. Наша модель 4B INT8 достигла 69,66 nDCG@10 на многоязычном бенчмарке извлечения MTEB по сравнению с gemini-embedding-001 от Google с результатом 67,71.
pplx-embed-context-v1 (2026, Perplexity): Решает распространенную проблему разбиения документов на фрагменты: отрывки могут терять свой смысл, если их оторвать от окружающего текста. Используя позднее разбиение (late chunking), модель обрабатывает документ перед объединением контекстуализированных представлений токенов в отдельные эмбеддинги фрагментов. Наша модель 4B достигла 81,96 nDCG@10 на ConTEB по сравнению с 79,45 для voyage-context-3.
pplx-embed-v2-context (2026, Perplexity): Развивает концепцию контекстного извлечения дальше. Вместо того чтобы обучаться только поиску отрывка, содержащего ответ, модель учится определять вспомогательные отрывки, которые помогают объяснить или подтвердить этот ответ. Модель использует сигналы релевантности, извлеченные из модели сжатия контекста во время обучения, без необходимости наличия этой учительской модели при выводе. Наша превью-модель 9B достигла 45,5% полноты ответов (answer recall) и 40,6% полноты доказательств (evidence recall) по 10 результатам на бенчмарке context-bench.

Модели Perplexity также позволяют хранить эмбеддинги в больших масштабах. Модели создают эмбеддинги INT8 и бинарные эмбеддинги, снижая требования к хранению в 4 и 32 раза соответственно по сравнению с FP32.

Модель

Размерность

Контекст

MRL

Квантование

Инструкция

Пулинг

pplx-embed-v1-0.6B

1024

32K

Да

INT8/BINARY

Среднее (Mean)

pplx-embed-v1-4B

2560

32K

Да

INT8/BINARY

Среднее (Mean)

pplx-embed-context-v1-0.6B

1024

32K

Да

INT8/BINARY

Среднее (Mean)

pplx-embed-context-v1-4B

2560

32K

Да

INT8/BINARY

Среднее (Mean)

Размерности, длина контекста, квантование и конфигурация пулинга модели pplx-embed

Плотные, разреженные и многовекторные эмбеддинги

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

Плотные вложения (Dense embeddings): представление текста с помощью компактных векторов, в которых большинство значений ненулевые.
Разреженные вложения (Sparse embeddings): использование преимущественно нулевых векторов с обученными весами, связанными с важными терминами. Такие модели, как SPLADE (2021), определяют, какие термины важны для поиска релевантных документов.
Многовекторные вложения (Multi-vector embeddings): сохранение нескольких векторов для фрагмента текста, что позволяет выполнять более детальное сравнение между запросами и документами. Такие модели, как ColBERT (2020), используют эти представления для более подробного сравнения запросов и документов.
Модели, сочетающие несколько подходов: BGE-M3 (2024), разработанная BAAI, поддерживает плотный, разреженный и многовекторный поиск в рамках одной модели.

Как выбрать и оценить модель текстовых вложений

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

Вот практический рабочий процесс оценки:

Создайте тестовый набор данных. Соберите 50–100 репрезентативных поисковых запросов в качестве первоначального набора для оценки (вам может потребоваться больше), включая сложные случаи, такие как перефразирования, техническая терминология и точные коды ошибок. Для каждого запроса определите, какие документы или фрагменты содержат релевантные ответы. Эти метки релевантности станут вашим эталоном (ground truth).
Измерьте качество поиска. Протестируйте каждую модель на одном и том же наборе данных для оценки, сохраняя сопоставимые условия подготовки документов и поиска, соблюдая при этом специфичные для модели требования к форматированию запросов, нормализации и оценке сходства. Затем вычислите следующие метрики с помощью InformationRetrievalEvaluator библиотеки Sentence Transformers: Recall@k: дает долю релевантных фрагментов, которые появляются в топ-k результатов. MRR: измеряет, насколько высоко в рейтинге появляется первый релевантный результат. nDCG@k: измеряет, насколько хорошо топ-k результатов ранжируются на основе их релевантности.
Recall@k: дает долю релевантных фрагментов, которые появляются в топ-k результатов.
MRR: измеряет, насколько высоко в рейтинге появляется первый релевантный результат.
nDCG@k: измеряет, насколько хорошо топ-k результатов ранжируются на основе их релевантности.
Оцените задержку (latency) и пропускную способность (throughput). Измерьте, сколько времени требуется каждой модели для создания вложения запроса, в идеале фиксируя медианную задержку (p50) и 95-й перцентиль (p95) при реалистичной нагрузке.
Рассчитайте затраты на хранение и эксплуатацию. Хранение векторов зависит от количества вложений, их размерности и числовой точности. Например, один миллион 768-мерных вложений FP32 требует примерно 3,1 ГБ сырого пространства для хранения векторов, без учета накладных расходов на индексирование. Чтобы уменьшить требования к хранению, вы можете quantize векторы до более низкой числовой точности. Переход с FP32 на INT8, например, сокращает объем хранения сырых векторов примерно в 4 раза. Тем не менее, сжатие может повлиять на качество поиска, поэтому повторите оценку, чтобы проверить баланс.

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

Когда следует использовать вложения вместо LLM?

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

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

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

Что разработчики делают не так при работе с текстовыми вложениями

Чтобы узнать, что разработчики склонны упускать из виду, я поговорил с Рахулом Кумаром (Rahul Kumar) и Сибейцзя Гуанем (Xibeijia Guan), специалистами по работе с данными в Ahrefs. Они выделили шесть ошибок, на которые стоит обратить внимание:

Пропуск предварительной обработки текста. Если входные данные содержат HTML, меню навигации, рекламу или другой нерелевантный контент, этапы предварительной обработки, такие как удаление шаблонного текста (boilerplate), могут помочь улучшить качество вложений за счет удаления лишней информации.
Игнорирование максимальной длины ввода модели. Различные модели имеют разные лимиты токенов и поведение при усечении. Текст, превышающий лимит, может быть усечен, что приведет к потере важной информации.
Несоблюдение специфичных для модели требований. Некоторые модели вложений требуют наличия определенных префиксов, таких как query: и passage:, или различных инструкций для разных задач. Несоблюдение этих требований может ухудшить качество поиска.
Использование несовместимой меры сходства. Косинусное сходство и скалярное произведение не всегда взаимозаменяемы. Проверьте, нормализованы ли вложения, и используйте метод оценки, рекомендованный для модели и векторного индекса.
Смешение тематического сходства с релевантностью. В узкоспециализированных коллекциях документов многие из них могут быть семантически похожими, не отвечая при этом на один и тот же вопрос. Изучайте неудачные запросы и распределения ранжирования. Тестируйте лексический или гибридный поиск, переранжирование (reranking) и фильтры по метаданным, когда пользователям нужна точная информация.
Игнорирование нормализации вложений. Различные модели вложений могут выводить нормализованные или ненормализованные векторы. Проверьте, нормализованы ли вложения и требуется ли дополнительная нормализация в зависимости от используемой метрики сходства.

Часто задаваемые вопросы о текстовых вложениях

1. Как генерировать текстовые вложения?

Самый простой подход — использовать предобученную модель вложений. Например, с помощью библиотеки Sentence Transformers для Python вы можете загрузить такую модель, как all-MiniLM-L6-v2, передать текст в метод model.encode() и получить числовой вектор. Кроме того, вы можете генерировать вложения через API.

Для семантического поиска или RAG вы обычно разбиваете документы на фрагменты (chunks), генерируете вложение для каждого из них и сохраняете векторы в индекс с возможностью поиска.

2. Какие модели вложений являются лучшими для текста?

Стоит рассмотреть несколько моделей в зависимости от того, что вы создаете:

pplx-embed-v1 от Perplexity: создана для крупномасштабного плотного поиска, поддерживает INT8 и бинарные вложения, которые снижают требования к хранению векторов.
pplx-embed-context-v1 от Perplexity: полезна для извлечения фрагментов из длинных документов, где отдельные части теряют смысл без окружающего их контекста.
all-MiniLM-L6-v2: отлично подходит для легкого локального семантического поиска, кластеризации и задач определения сходства предложений. Создает компактные 384-мерные векторы, но усекает входные данные длиннее 256 текстовых фрагментов (word pieces).
BGE-M3: полезна для многоязычного RAG и гибридного поиска. Поддерживает более 100 языков и сочетает в себе плотные, разреженные и многовекторные представления.
Qwen3-Embedding: сильный претендент для многоязычного поиска, извлечения кода и эмбеддингов для конкретных задач. Предлагает модели с открытыми весами объемом 0.6B, 4B и 8B с поддержкой инструкций.
OpenAI’s text-embedding-3-large: вариант на базе API для семантического поиска и извлечения документов, когда вы не хотите размещать модель самостоятельно. Поддерживает до 3072 измерений, которые можно уменьшить для экономии места.
Google’s Gemini Embedding models: полезны для управляемых приложений извлечения. Gemini Embedding 2 также поддерживает поиск по тексту, изображениям, аудио, видео и PDF в общем пространстве эмбеддингов.

3. Могу ли я использовать LLM в качестве модели эмбеддингов?

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

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