Эмбеддинги простыми словами: как текст превращается в числа

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

Что такое эмбеддинг

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

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

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

Откуда берутся эти числа

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

Практический вывод из этого один, но важный: векторы разных моделей несовместимы между собой. Если вы проиндексировали базу знаний моделью OpenAI, а запрос закодировали моделью Google, сравнивать их бессмысленно — результат будет случайным шумом. Меняете модель — переиндексируйте всё заново.

Как измеряют близость

Самая распространённая мера — косинусная близость (cosine similarity). Она смотрит не на длину векторов, а на угол между ними: значение около 1 означает «направления совпадают, тексты про одно и то же», около 0 — «связи нет», отрицательные значения на практике встречаются редко. У OpenAI векторы нормализованы к длине 1, поэтому косинусная близость там сводится к простому скалярному произведению, а ранжирование по косинусу и по евклидову расстоянию даёт одинаковый порядок результатов.

Абсолютные значения не стоит трактовать буквально. «0,82» само по себе ничего не значит: у разных моделей своя шкала, и на реальной базе нормальные совпадения могут держаться в диапазоне 0,7–0,9, а мусор — около 0,6. Порог отсечения подбирают опытным путём на своих данных, а не берут из статьи.

Где это применяют

• Семантический поиск. Пользователь спрашивает своими словами, система находит документы по смыслу, а не по вхождению слов.
• RAG. Поиск по базе знаний перед ответом модели — самый частый сценарий; подробнее разбирали в статье «Что такое RAG простыми словами».
• Классификация. Сравниваем вектор входящего обращения с векторами типовых категорий — получаем маршрутизацию заявок без обучения отдельной модели (см. «Классификация заявок и обращений с помощью ИИ»).
• Дедупликация и кластеризация. Найти повторяющиеся товары в каталоге, склеить одинаковые по смыслу тикеты, сгруппировать отзывы по темам.
• Рекомендации и «похожие статьи». Берём вектор текущего материала и ищем ближайшие в базе.
• Память агентов. Долговременная память ассистента часто устроена как векторный поиск по прошлым диалогам — об этом была отдельная заметка.

Какие модели брать в 2026 году

Облачные

У OpenAI два актуальных варианта: text-embedding-3-small (1536 чисел по умолчанию, около $0,02 за миллион токенов) и text-embedding-3-large (3072 числа, около $0,13 за миллион). Оба принимают до 8192 токенов на вход. Разница в качестве на бенчмарке MTEB невелика — примерно 62,3 % против 64,6 %, — а цена отличается в 6,5 раза, поэтому для большинства задач разумно начинать с младшей модели. Пакетный API (batch) даёт скидку 50 % и хорошо подходит для первичной индексации большой базы.

У Google в Gemini API сейчас две модели: gemini-embedding-001 (только текст, до 2048 токенов, около $0,15 за миллион) и более новая gemini-embedding-2 — мультимодальная, с окном 8192 токена и ценой около $0,20 за миллион. Полезная особенность Google — параметр task_type: можно явно указать, для чего вектор нужен (поиск по документам, поиск запроса, классификация, кластеризация), и модель сместит представление под задачу. Попробовать без кода можно прямо в браузере — как это делается, описано в заметке «Google AI Studio: что это и как с ним работать». Цены и лимиты провайдеров мы сравнивали в материале «Сравнение API: Gemini, Claude и OpenAI».

Локальные

Эмбеддинги — тот редкий случай, когда локальная модель почти не уступает облачной, а работает мгновенно и бесплатно: модели маленькие, от 20 до 600 миллионов параметров, и спокойно крутятся даже без видеокарты. Через Ollama на своём сервере доступны nomic-embed-text (самый популярный выбор), bge-m3 (хорошо работает с русским и другими языками), embeddinggemma от Google на 300M параметров и лёгкий all-minilm для слабого железа. Если данные нельзя отправлять наружу или объёмы большие, локальный вариант часто оказывается практичнее облачного.

Размерность: почему 3072 числа не всегда лучше 768

Чем длиннее вектор, тем больше памяти он занимает и тем дольше идёт поиск. Миллион документов по 3072 числа в формате float32 — это примерно 12 ГБ только под векторы. Современные модели решают проблему через приём под названием Matryoshka Representation Learning: важная информация сосредоточена в начале вектора, поэтому хвост можно просто отрезать. У OpenAI за это отвечает параметр dimensions, у Google — output_dimensionality (поддерживается диапазон от 128 до 3072, рекомендуемые значения — 768, 1536 и 3072).

Потери качества при этом невелики: укороченный до 256 чисел вектор text-embedding-3-large по бенчмаркам обгоняет полный устаревший ada-002 на 1536 числах. Практическое правило: начните с 768 или 1536, померяйте качество поиска на своих запросах и увеличивайте только если действительно не хватает. Если обрезаете вектор вручную уже после получения, не забудьте заново нормализовать его по L2 — иначе косинусная близость поедет.

Первый запрос

Проще всего попробовать на Python. Ключ получаем по инструкции из заметки «OpenAI API: как получить ключ и сделать первый запрос»:

from openai import OpenAI
client = OpenAI()

r = client.embeddings.create(
    model="text-embedding-3-small",
    input="как оформить возврат товара",
    dimensions=768,
)
vec = r.data[0].embedding
print(len(vec), vec[:5])

Локальный вариант через Ollama выглядит почти так же и не требует ключей:

curl http://localhost:11434/api/embed -d '{
  "model": "nomic-embed-text",
  "input": "как оформить возврат товара"
}'

Дальше остаётся посчитать близость. Для нормализованных векторов это одна строка на NumPy: float(np.dot(a, b)). Возьмите три-четыре свои фразы, посчитайте попарные значения и посмотрите, совпадает ли порядок с вашей интуицией, — это лучший способ почувствовать, как модель видит ваши данные.

Где хранить векторы

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

Типичные ошибки

• Смешивать модели. Индексировали одной, ищете другой — поиск сломан. Версию модели стоит хранить рядом с векторами.
• Кодировать слишком длинные куски. Вектор целой главы — это «средняя температура по больнице»: конкретный факт в нём растворяется. Текст нужно резать на фрагменты по 200–500 слов.
• Хранить эмбеддинги в JSON-файле. Векторы в текстовом виде раздувают файл в разы; для хранения используйте бинарные форматы или базу.
• Забывать про стоимость индексации. Каждое переиндексирование базы — это оплаченные токены; как их считать, разбирали в заметке «Токены и лимиты: как считать и экономить».
• Ждать от эмбеддингов точных совпадений. Артикул, номер заказа, конкретную дату векторный поиск находит плохо — для этого лучше комбинировать его с обычным поиском по словам.

Вывод

Эмбеддинг — это перевод текста в координаты на смысловой карте, и почти вся «магия» современных ИИ-систем поиска сводится к тому, чтобы аккуратно разложить свои данные по этой карте и потом найти ближайшую точку. Технология зрелая, стоит копейки, а в локальном варианте — вообще ничего. Начинать разумно с младшей модели и умеренной размерности, обязательно измерять качество на собственных запросах, а масштаб и точные настройки добавлять уже тогда, когда упрётесь в реальное ограничение.