Embeddings: смысл текста как вектор

Зачем

Классический keyword-поиск (BM25, Elasticsearch) ищет совпадения токенов. Пользователь пишет «как вернуть деньги», в документе написано «оформить возврат», — пересечения нет, recall ноль. Это работало в 2010, но в 2026 половина запросов в продуктовом поиске и весь RAG для LLM требуют понимать смысл, а не буквы.

Embedding — это функция text -> float[N], которая отображает строку в точку в N-мерном пространстве так, что семантически близкие тексты лежат рядом, а непохожие — далеко. «Refund» и «money back» оказываются на cosine 0.87. «Refund» и «best pizza» — на 0.08. Это даёт три суперспособности:

1. Semantic search. Запрос превращается в вектор, ищем ближайшие документы по cosine — синонимы и парафразы находятся «бесплатно».
2. RAG retrieval. LLM не знает приватных документов, но мы достаём top-K релевантных embeddings, склеиваем в контекст и подаём в prompt. Это вся суть production-ready ChatGPT-style ассистентов поверх своих данных.
3. Recommendations / clustering / dedup / anomaly detection — всё та же операция: посчитал расстояния, сделал вывод.

Без embeddings ты пишешь правила, синонимы, словари и стеммеры до конца жизни. С embeddings — одна модель решает 80% задач NLP, оставшиеся 20% делает LLM поверх их выдачи.

Mental model одной фразой

Embedding — это координаты смысла в N-мерном пространстве. Cosine между двумя векторами отвечает на вопрос «насколько эти два текста об одном и том же», а не «насколько похожи их буквы».

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

Что на диаграмме

Две группы, отражающие реальный split любого embedding-приложения.

Offline indexing pipeline (батчевый, считается раз в день/час):

• source-docs (S3) — исходные документы, обычно лежат в object storage
• chunker — режет длинные документы на куски ~500 токенов с overlap ~50
• embedder-api — вызов модели (OpenAI / Voyage / self-host)
• vector-db (Qdrant) — хранит {id, vector[1536], metadata} + HNSW индекс

Online query path (низкая латентность, синхронный):

• user — отправляет запрос
• api — продуктовый API, оркестрирует
• embedding cache (Redis) — key = hash(query), TTL дни/недели
• query-embedder — та же модель что и в offline, но на одной строке
• vector-db (read) — ANN search top-K, ~10ms на млн векторов
• llm — собирает ответ из retrieved context (RAG)

Два ADR живут на ноде embedder — это места, где архитектор принимает решения, влияющие на стоимость и качество всего pipeline.

Сценарии

Три сценария разворачивают концепт от «что вообще такое embedding» до «как это работает в проде на 10K документов».

1. Text -> embedding (model call)

Один запрос «how do I get my money back?» проходит весь путь. Видно как API сначала бьёт в Redis cache (промах на холодном запросе), потом вызывает модель. Внутри модели — три шага: tokenize → forward pass через трансформер (~30ms) → L2-нормализация. Возвращается float32[1536]. Этот же вектор пишется в cache, чтобы повторный идентичный запрос ушёл за ~1ms вместо ~50ms + $0.00001.

Главное, что нужно вынести: embedding — это функция. Одинаковый вход даёт одинаковый выход (для той же модели той же версии). Поэтому кешировать можно агрессивно.

2. Cosine similarity: synonyms close, unrelated far

Сценарий-демонстратор интуиции. В индекс кладётся один документ: «request a refund for my order». Затем четыре query сравниваются с ним:

Это и есть то, ради чего вообще берут embeddings: BM25 на этих парах дал бы 0 / partial / 0 / max — синоним был бы потерян. Финальный шаг сценария — красное предупреждение про забытый query/passage prefix на Voyage/BGE: лишишься ~10% recall на ровном месте, потому что модель ожидает специальный токен в начале query, отличающий его от passage.

3. Batch embedding pipeline (offline indexing)

End-to-end индексация 10K документов. Сценарий протаскивает читателя через все экономические и операционные решения, которые часто упускают в туториалах:

• 10K docs × 5KB → chunker → 80K чанков (overlap 50 токенов)
• Batch POST size = 2048 (баланс между rate limit и latency)
• Стоимость на text-embedding-3-small: 40M токенов × $0.02/1M = $0.80 на полную индексацию. Это дёшево.
• Storage: 80K × 1536 × 4 байта = ~470 MB float32. Int8 quantization → 120 MB. Это в 4 раза меньше при потере ~1% recall — почти всегда стоит.
• HNSW build с M=16, efConstruction=200 — нормальный baseline.
• Красный финал: rate limit на чанке 41,200 → нужны exponential backoff и resume cursor, иначе при retry заиндексируешь те же документы дважды.

Trade-offs (ADR)

ADR-001: Embeddings vs keyword (BM25) search

Контекст. BM25 — точный, дешёвый, объяснимый, мгновенный. Но он слеп к синонимам («car» vs «automobile»), к парафразам («how to refund» vs «money back») и к интенту. Embeddings ловят семантику, но требуют GPU/CPU, хранилище для векторов, ANN-индекс и не объяснимы (нельзя сказать пользователю «нашли по слову X»).

Решение. Бери embeddings (или гибрид), когда:

• recall по синонимам и парафразам важен;
• многоязычность;
• RAG для LLM;
• recommendations.

Оставайся на BM25, когда:

• доминирует exact-token match (логи, код, юридические цитаты, error codes);
• латентность < 10ms;
• бюджет тонкий или объём огромный (петабайты логов);
• queries — короткие ключевые слова без интента.

Production sweet spot — гибрид. BM25 + dense retrieval, объединённые через Reciprocal Rank Fusion (RRF) или взвешенную сумму, дают +10–15% NDCG над любым из методов поодиночке. Большинство зрелых поисковых стэков (Elastic, Vespa, Weaviate, Qdrant) поддерживают это нативно.

ADR-002: Размер модели — 1536 vs 3072 vs 256 (Matryoshka)

Контекст. 3072-dim float32 × 100M векторов = 1.2 TB RAM только под вектора, не считая индекс. 1536 — это уже 600 GB, тоже больно. Matryoshka embeddings (Kusupati 2024) — это модели, обученные так, что любой префикс вектора сам по себе валидный embedding. OpenAI 3-large и nomic-embed-v1.5 поддерживают dimensions параметр: можно попросить 512 вместо 3072 — и сохранить ~90% recall@10.

Решение.

• Прототип / <100K векторов: text-embedding-3-small @ 1536 ($0.02/1M tok). Не думай, бери.
• Production / английский: переходи на 3-large @ 3072 только если evals на твоих данных показали >2% улучшения NDCG. Часто разницы нет.
• >10M векторов: Matryoshka truncate до 768 или 512 + int8 quantization, затем re-rank top-100 полноразмерным вектором. Экономия 8–16× по RAM при потере ~1–3% recall.
• Всегда нормализуй вектора в L2-norm 1: тогда cosine = dot product, а dot быстрее на любом hardware.

Реальные системы

• Notion AI / Slack AI / Linear AI — все используют embeddings (плюс hybrid с BM25) для поиска по своим базам. Стэк обычно OpenAI/Voyage + Pinecone/Qdrant + LLM.
• GitHub Copilot Workspace / Cursor / Sourcegraph Cody — embeddings кода (Voyage code-3, jina code) для context retrieval в редакторе. Без них LLM не «понимает» твой репозиторий.
• Spotify Discover Weekly — item2vec embeddings треков, рекомендации считаются как ANN-поиск ближайших векторов в латентном пространстве.
• Pinterest related pins — visual embeddings (CLIP-style) + behavioural embeddings, fused.
• Amazon product search — гибрид BM25 + dense, поверх — learning-to-rank.
• Anthropic Claude / OpenAI ChatGPT «Projects» / «Custom GPTs» — RAG поверх загруженных файлов: chunking → OpenAI embeddings → in-memory ANN.

Anti-patterns

1. Перерасчёт embeddings на каждый запрос. Identical query без cache — это +50ms latency и $$/месяц на ровном месте. Redis с key=hash(query) решает проблему за час работы.
2. Cosine на ненормированных векторах. Некоторые модели возвращают unnormalized — cosine посчитается, но будет искажён по магнитуде. Всегда проверяй, что норма ~= 1. Если нет — нормализуй сам.
3. Игнорирование chunk size при сравнении моделей. Модель с 8K context на длинном документе побьёт OpenAI 8191 limit просто потому, что ничего не теряет на хвосте. Сравнивай honest: одинаковая стратегия chunking + один и тот же датасет.
4. Один embedding для query и passage на моделях, где они асимметричны. Voyage, BGE, E5 требуют разные префиксы (query:, passage:). Забудешь — recall падает на 10–20%. Это не баг моделей, это by design.
5. Прямое cosine между старым и новым embedding model. Координатные системы у text-embedding-ada-002 и text-embedding-3-small разные. Нельзя мигрировать «постепенно», нужен полный re-index.
6. Хранение 3072-dim float32 для 100M+ векторов. 1.2 TB RAM. Бюджет улетит до того, как ты что-то задеплоишь. Matryoshka truncate + int8 → 8–16× экономии.
7. Не делать evals. Лидерборд MTEB показывает «лучшую» модель в среднем по 56 датасетам. На твоих данных лучшей может быть совсем другая. Hamel Husain: «не выбирай по лидерборду, выбирай по своим evals». 100 query-doc золотых пар, измерь recall@10, повтори для 3 моделей.

Когда НЕ использовать

• Exact-match задачи. Поиск по логам, error codes, UUID, SKU — BM25 всегда лучше. Embeddings «улучшат» поиск SKU XJ-99201 так, что найдут XJ-99202 и сломают пользователя.
• Latency-critical hot path < 5ms. Embed+ANN — это минимум 20–50ms. Если бюджет жёстче, грей prefix tries / inverted index.
• Маленький корпус (<1000 документов). BM25 + ручные синонимы дешевле и проще. Embeddings оправданы от ~10K документов и/или мульти-языка.
• Регуляторные требования к explainability. «Почему этот документ?» на cosine = 0.83 — не ответ для compliance. BM25 показывает совпавшие токены, embeddings — нет.
• Domain слишком узкий и не покрыт обучением модели. General-purpose embedding на медицинских терминах путает «инфаркт миокарда» и «инфаркт мозга». Либо файнтьюнь, либо бери domain-specific (Voyage law-2, BioBERT).
• Очень короткие тексты (1–3 токена). Embeddings деградируют — нет контекста для смысла. Названия товаров лучше искать гибридом.

Дальше читать

• /concepts/vector-similarity-ann — что происходит после embedding: HNSW, IVF, ScaNN, как искать top-K за O(log N) среди миллиардов векторов.
• /concepts/rag-architecture — полный RAG-стэк: chunking strategies, hybrid retrieval, re-ranking, prompt assembly, hallucination control.
• MTEB leaderboard — https://huggingface.co/spaces/mteb/leaderboard. Стандартный бенчмарк, 56 датасетов. Используй как стартовую точку, не как истину в последней инстанции.
• Matryoshka Representation Learning — Kusupati et al. 2022. Объясняет, почему можно резать вектор до префикса.
• BGE-M3 paper — Chen et al. 2024. Лучшая open-source мультиязычная embedding, dense + sparse + multi-vector в одной модели.
• Nils Reimers blog (sbert.net) — best practices по training и tuning embeddings, от автора Sentence Transformers.
• OpenAI embeddings guide — https://platform.openai.com/docs/guides/embeddings. Канон по API, ценам, dimensions, use cases.
• Voyage AI domain benchmarks — если у тебя код / юр. документы / финансы, у них есть domain-specific модели с замерами против general-purpose.