Embeddings простими словами: як AI розуміє сенс, а не просто слова

Ви коли-небудь дивувались, чому ChatGPT знаходить зв'язок між "автомобілем" і "машиною" — хоча це різні слова? Або чому RAG-система знаходить потрібний документ навіть якщо у запиті немає жодного слова з тексту? Спойлер: за цим стоїть одна технологія — embedding. Це спосіб перетворити будь-який текст у набір чисел так, щоб схожі за змістом тексти мали схожі числа.

📚 Зміст статті

• 📌 Розділ 1. Від токенів до чисел: чому AI не може працювати зі словами напряму
• 📌 Розділ 2. Embedding = координати у просторі сенсу
• 📌 Розділ 3. Звідки беруться ці числа? Як модель навчилась кодувати сенс
• 📌 Розділ 4. Розмірність: чому 768 ≠ 1536 і що це означає на практиці
• 📌 Розділ 5. Де embeddings використовуються: 5 реальних застосувань
• 📌 Розділ 6. Обмеження embeddings: коли вони не допоможуть
• 💼 Розділ 7. Моделі 2026: з чого почати
• ❓ Часті питання (FAQ)
• ✅ Висновки

🎯 Від токенів до чисел: чому AI не може працювати зі словами напряму

Токен — це одиниця тексту, яку бачить AI. Embedding — це те, що цей токен означає, записане у вигляді чисел.

Якщо ви читали статтю про токени, то знаєте: AI ділить текст на фрагменти (токени) — це можуть бути цілі слова, частини слів або навіть окремі символи. Але токен — це ще не значення. Це просто одиниця розбиття.

Embedding — наступний крок. Кожен токен отримує свій унікальний числовий "відбиток" — вектор. Цей вектор кодує не написання слова, а його сенс у контексті мови. Саме тому "автомобіль" і "машина" — різні токени, але їх вектори будуть дуже близькими.

Аналогія: словник vs карта міста

Уявіть два способи описати слово. Перший — словник: "кіт — домашня тварина родини котячих". Це корисно для людини, але марно для математики. Другий — карта: у місті понять "кіт" стоїть поряд з "кошеням", "лапою", "муркотінням" — і далеко від "ракети" чи "бухгалтерії". Embedding — це саме карта, де позиція кожного слова визначається його сенсовим оточенням. документації OpenAI Embeddings як перетворення тексту на числовий вектор у просторі високої розмірності.

• ✔️ Токен = одиниця тексту (що написано)
• ✔️ Embedding = числовий вектор (що це означає)
• ✔️ Без перетворення тексту в числа — жодна нейронна мережа не може з ним працювати

Висновок: Embedding — це обов'язковий місток між текстом, який розуміє людина, і числами, з якими працює AI.

Чому різні моделі дають різний результат: порівняльна таблиця

Чому той самий текст дає різний результат у різних моделях

Три головні причини розходження результатів між моделями:

1. Різний training signal. OpenAI навчала модель на синтетичних парах від GPT-4 — це дає хорошу загальну якість, але деталі датасету закриті. BGE-M3 навчалась на відкритих 1.2M парах з явним мультимовним сигналом — тому краще на кирилиці. E5 використовує instruction-tuning: модель очікує prefix "query: " перед запитом і "passage: " перед документом. Якщо prefix не додати — якість падає на 5–15% навіть на англійському контенті.

2. Різне контекстне вікно. E5-large обробляє лише 512 токенів — довгий документ буде обрізаний, і хвостова частина просто зникне з вектора. OpenAI і BGE-M3 обробляють до 8K токенів, що дозволяє ембедити цілі статті без втрати інформації. Якщо ваші документи довші за 400 слів і ви використовуєте E5 — обов'язково потрібен chunking.

3. Різна геометрія простору. Кожна модель будує свій власний векторний простір. Вектор слова "договір" від OpenAI і вектор того ж слова від BGE-M3 — несумісні числа в несумісних просторах. Саме тому не можна змішувати вектори від різних моделей в одній Vector DB і не можна порівнювати їх між собою. Детально про це — у MTEB Leaderboard, де моделі порівнюються на стандартизованих бенчмарках.

📌 Embedding = координати у просторі сенсу

Якщо звичайний GPS-координат — це дві числа (широта і довгота), то embedding — це GPS у просторі з тисячами вимірів, де кожна "координата" кодує якийсь аспект сенсу.

Давайте уявимо дуже спрощений простір — лише два виміри. Вісь X — наскільки слово пов'язане з живим світом. Вісь Y — наскільки воно пов'язане з рухом. Тоді:

• "юрист" → висока X (людина), низька Y (не про рух) → координата [0.9, 0.1]
• "кур'єр" → висока X, висока Y → [0.9, 0.8]
• "автомобіль" → низька X, висока Y → [0.1, 0.9]
• "ракета" → низька X, дуже висока Y → [0.05, 0.95]

У реальності вимірів не два, а сотні або тисячі — кожен кодує якийсь тонший аспект: емоційне забарвлення, синтаксичну роль, тематичну приналежність тощо. Ми не можемо їх інтерпретувати поодинці, але математика відстаней між точками у цьому просторі — працює бездоганно.

Як вимірюється схожість між векторами: Cosine Similarity

Відстань між двома векторами вимірюється не по прямій (евклідова відстань), а через кут між ними — так звана cosine similarity. Чим менший кут між двома векторами, тим більш семантично схожі слова або речення. "Договір" і "угода" дивляться майже в один бік у просторі сенсу — кут між ними малий, similarity висока. "Договір" і "ракета" — майже перпендикулярні, similarity близька до нуля.

Cosine similarity — стандарт де факто для більшості моделей і vector DB. Але є важливий нюанс, який я бачу в помилках на production: деякі моделі оптимізовані під іншу метрику — Dot Product (скалярний добуток). Наприклад, Gemini Embedding 2 від Google і частина моделей Cohere в певних режимах очікують саме Dot Product, а не Cosine. Якщо виставити невірну метрику у вашій Vector DB — результати пошуку будуть гіршими навіть при правильній моделі. Завжди перевіряйте документацію моделі перед налаштуванням distance у ChromaDB, Qdrant або pgvector.

Лайфхак: нормалізація векторів пришвидшує пошук

Є практичний трюк, який варто знати. Якщо нормалізувати вектори до одиничної довжини (unit length) — тобто привести кожен вектор до норми рівної 1 — то Cosine Similarity стає математично еквівалентна Dot Product. А Dot Product обчислюється швидше: це просто сума добутків елементів, без додаткового ділення на норми. Багато vector DB (Qdrant, pgvector з vector_cosine_ops) роблять це автоматично — але якщо ви використовуєте власний пошук або FAISS, нормалізуйте вектори перед збереженням і отримаєте приріст швидкості без жодної втрати якості.

Детально про те, як cosine similarity і Dot Product використовуються у пошуку на практиці — у статті Vector Search для початківців.

• ✔️ Embedding — список чисел від 384 до 3072 значень
• ✔️ Схожість вимірюється кутом між векторами (Cosine Similarity) — але перевіряйте документацію моделі: деякі оптимізовані під Dot Product
• ✔️ Нормалізовані вектори: Cosine = Dot Product → швидший пошук без втрати якості

Висновок: Embedding перетворює абстрактний "сенс" на конкретну геометрію — і саме це дозволяє AI порівнювати значення текстів математично. Але правильний вибір метрики схожості — не менш важливий ніж сама модель.

📌 Розділ 3. Звідки беруться ці числа? Як модель навчилась кодувати сенс

Модель не читає словник і не знає граматики. Вона читає мільярди речень — і вчиться, які слова і фрази живуть поруч, а які ніколи не зустрічаються разом.

За цим стоїть ідея дистрибутивної семантики, сформульована лінгвістом Джоном Ферсом ще у 1957 році: "Слово визначається компанією, в якій воно зустрічається." Якщо два слова постійно з'являються в схожих контекстах — вони, скоріш за все, мають схожий сенс. Саме цей принцип став основою для Word2Vec (Google, 2013) — першої масштабної моделі, що перетворила слова на вектори через статистику контекстів, а не через ручну розмітку. Оригінальна стаття Mikolov et al., 2013 — arXiv:1301.3781 .

Від Word2Vec до сучасного контрастного навчання

Word2Vec навчався просто: для кожного слова — передбачити сусідні слова у вікні з 5–10 токенів. Якщо "юрист" і "адвокат" часто зустрічаються в схожих реченнях — їхні вектори зближуються. Це вже працювало. Але у Word2Vec кожне слово мало один вектор незалежно від контексту: слово "ключ" отримувало однаковий вектор у реченні "ключ від замка" і "ключ до успіху" — хоча сенси різні.

Сучасні моделі (BERT від Google, 2018) вирішили цю проблему: вектор тепер залежить від усього речення, а не від статичного словника. Слово "ключ" отримує різний вектор залежно від того, що стоїть поруч. Це стало можливим завдяки архітектурі трансформерів і механізму self-attention. BERT: Pre-training of Deep Bidirectional Transformers — arXiv:1810.04805 .

Як виглядає контрастне навчання на практиці

Сучасний стандарт навчання embedding-моделей — контрастне навчання (contrastive learning), зокрема підхід SimCSE і його похідні. Модель отримує три речення одночасно:

• Anchor (якір): "Як скасувати підписку на сервіс?"
• Positive (позитивний приклад): "Інструкція з відмови від тарифного плану" — має бути близько до anchor
• Negative (негативний приклад): "Рецепт традиційного борщу" — має бути далеко від anchor

Функція втрат (contrastive loss або InfoNCE loss) штрафує модель якщо вектор positive далекий від anchor — або якщо вектор negative занадто близький. Через мільярди таких трійок модель навчається будувати простір, де семантична близькість відображається геометричною близькістю. SimCSE: Simple Contrastive Learning of Sentence Embeddings — arXiv:2104.08821 .

Де беруть пари для навчання? Переважно з трьох джерел: природні пари питання–відповідь (NLI-датасети, Stack Overflow, Reddit), паралельні переклади (для мультимовних моделей) і синтетичні пари згенеровані LLM. Наприклад, для навчання text-embedding-3-small OpenAI використовував синтетичні дані, згенеровані GPT-4, як описано у блозі OpenAI про нові embedding-моделі .

Що модель реально кодує у векторі

Дослідники з'ясували, що різні виміри вектора кодують різні аспекти сенсу — але не так прямолінійно як хотілось би. Один вимір може відповідати за "юридичний контекст", інший — за "емоційний тон", третій — за "синтаксичну роль у реченні". Але виміри не ізольовані: сенс кодується розподілено по всіх числах одночасно. Це означає що жодне окреме число у векторі не має людськи-інтерпретованого значення — тільки вся комбінація разом.

Відомий приклад з Word2Vec, який зберігся і в сучасних моделях: вектор("король") − вектор("чоловік") + вектор("жінка") ≈ вектор("королева"). Арифметика сенсів працює у просторі векторів — це одне з найяскравіших підтверджень того що модель справді вловила структуру мови, а не просто запам'ятала слова.

Чому мультимовні моделі розуміють "договір" і "contract" як одне

Мультимовні embedding-моделі (Cohere embed-v4, BGE-M3, multilingual-e5) навчались одночасно на текстах десятками мовами і на паралельних корпусах перекладів. Через це "договір" (українська) і "contract" (англійська) опиняються у суміжних точках одного простору — бо вони зустрічались у схожих контекстах і були зв'язані через переклади.

Це відкриває cross-lingual search: запит українською знаходить документи англійською без жодного перекладу. На практиці — якщо ваша база знань наповнена переважно англійськими документами, а користувачі пишуть українською, якісна мультимовна модель закриє цей розрив. У нашому кейсі з WebsCraft це була реальна проблема: частина контенту існує тільки однією мовою, а запити приходять іншою. BGE-M3 справляється з цим значно краще за OpenAI small, де якість на кирилиці помітно нижча ніж на латиниці — що підтверджують і результати MTEB Multilingual Leaderboard .

• ✔️ Дистрибутивна семантика: сенс = контекст співіснування
• ✔️ Контрастне навчання: позитивні пари зближуються, негативні — розходяться
• ✔️ Сучасні моделі (BERT і далі): вектор залежить від контексту, а не статичний
• ✔️ Мультимовні моделі: переклади в одному просторі → cross-lingual пошук без перекладача

Висновок: Числа у векторі — не довільні і не запрограмовані вручну. Вони є результатом навчання на мільярдах прикладів і відображають реальну статистичну структуру мови — саме тому вони так добре вловлюють сенс.

📌 Розмірність: чому 768 ≠ 1536 і що це означає на практиці

Розмірність вектора — як роздільна здатність фотографії: 100×100 пікселів достатньо для піктограми, 4000×3000 — для плаката. Що потрібно вам — залежить від задачі.

Більше вимірів = більше "каналів" для кодування сенсу. Маленький вектор (384 виміри, як у all-MiniLM) може розрізнити "кіт" і "ракету", але може сплутати тонкі нюанси: наприклад, не відрізнить "дострокове розірвання договору" від "закінчення терміну дії контракту". Великий вектор (3072 виміри, як у text-embedding-3-large) вловить і цю різницю — але коштуватиме більше і займе більше місця у базі даних.

Trade-off на практиці: швидкість, якість, вартість

Matryoshka embeddings: велика розмірність без переплати

У 2024–2025 роках набула популярності техніка Matryoshka Representation Learning (MRL). Ідея проста: модель навчається так, що перші N вимірів вектора вже несуть більшу частину корисної інформації. Це означає, що ви можете згенерувати вектор 3072 виміри, але зберігати і шукати тільки по перших 256 — з мінімальною втратою якості. Такий підхід підтримують OpenAI text-embedding-3-large і Gemini Embedding 2: генеруєте один раз, а розмірність обираєте під задачу.

• ✔️ Більша розмірність = більше нюансів, але дорожче і повільніше
• ✔️ Для більшості проєктів 768–1536 вимірів — оптимум
• ✔️ Matryoshka (MRL): можна обрізати вектор без перегенерації

Висновок розділу: Розмірність — це компроміс між якістю і ресурсами; починайте з 768–1536 і збільшуйте тільки якщо є конкретна проблема з якістю пошуку.

📌 Де embeddings використовуються: 5 реальних застосувань

Якщо keyword-пошук — це пошук за адресою, то embedding-пошук — це пошук за тим, що в будинку знаходиться.

1. Семантичний пошук

Класичний пошук шукає точний збіг слів. Семантичний пошук знаходить документи за змістом: запит "як скасувати підписку" знаходить статтю "інструкція з відмови від тарифу" — навіть якщо жодного спільного слова немає. Саме так влаштовані внутрішні пошуки в Notion, Confluence та корпоративних базах знань.

2. RAG (Retrieval-Augmented Generation)

У RAG-системах embedding використовується двічі: при індексації (документ → вектор → збереження у vector DB) і при пошуку (запит → вектор → пошук схожих документів → відповідь LLM). Без якісного embedding — RAG повертає нерелевантні фрагменти, і навіть найкращий LLM галюцинуватиме. Детально — у статті LLM vs RAG у 2026 та повному гайді з RAG.

3. Рекомендаційні системи

"Вам може сподобатись..." — це часто embedding у дії. Стаття, яку ви читаєте, перетворюється на вектор. Система знаходить інші статті з близькими векторами і пропонує їх. Те саме у стримінгових сервісах: фільм, який ви дивились, → вектор → пошук схожих за настроєм і темою, а не тільки за жанром.

4. Класифікація без розмітки (zero-shot)

Традиційна класифікація потребує тисячі розмічених прикладів для кожного класу. З embeddings можна класифікувати тексти без жодного прикладу: вираховуємо вектор тексту і порівнюємо з векторами назв класів. "Чи це скарга або похвала?" — обчислюємо cosine similarity з векторами слів "скарга" і "похвала" і дивимось, який ближче.

5. Виявлення дублікатів і cross-lingual пошук

Embeddings знаходять майже однакові тексти навіть якщо вони перефразовані або написані різними мовами. Це корисно для дедуплікації бази знань, виявлення плагіату або — що особливо важливо для українського контенту — пошуку коли запит приходить однією мовою, а документи існують іншою. Мультимовна embedding-модель розміщує "договір оренди" (українська) і "rental agreement" (англійська) в суміжних точках простору.

• ✔️ Семантичний пошук: за змістом, а не за словами
• ✔️ RAG: фундамент якості retrieval
• ✔️ Рекомендації, класифікація, дедуплікація, cross-lingual пошук

Висновок: Embeddings — це не окрема технологія, а горизонтальний інструмент: вони з'являються всюди де AI потрібно розуміти або порівнювати сенс текстів.

📌 Обмеження embeddings: коли вони не допоможуть

Embedding відповідає на питання "про що цей текст?", але не на питання "яке точне значення в рядку 7?"

Проблема 1: точні числа, дати, ID

Запит "договір №4521" і "договір №4522" — для embedding-моделі це майже одне і те саме: обидва "про договір з номером". Різниця в одній цифрі не відображається у векторі так, як вона важлива для людини. Те саме з датами: "що сталось 15 лютого 2023?" — embedding не "знає" що це специфічна дата, а не просто "лютий".

Проблема 2: власні імена і терміни

Рідкісні власні імена, абревіатури, назви продуктів або технічні терміни часто погано представлені у просторі embedding. Якщо ім'я зустрічалось рідко у навчальних даних — його вектор буде "розмитим" і ненадійним.

Проблема 3: короткі запити

Запит "RAG" або "Spring" — занадто мало контексту для якісного вектора. Модель не знає, що саме вас цікавить: RAG як технологія, RAG як назва фільму чи Spring як пора року. Вектор буде усередненим і нечітким. Рішення — fallback на keyword-пошук для коротких запитів, як описано у статті Vector Search для початківців.

Що робити: hybrid search

Для production-систем правильна відповідь — комбінувати семантичний пошук з класичним keyword-пошуком (BM25). Hybrid search дає +15–40% якості порівняно з чистим vector search і вирішує всі три проблеми вище. Детально — у повному гайді з RAG.

• ✔️ Точні числа, ID, дати → keyword-пошук або metadata-фільтри
• ✔️ Короткі запити → fallback на BM25
• ✔️ Production → hybrid search (BM25 + vector)

Висновок: Embeddings — потужний інструмент для семантичних задач, але не замінюють точний пошук; знайте їхні межі і комбінуйте підходи.

Типові помилки з embeddings і як їх уникнути

💼 Моделі 2026: з чого почати

Не витрачайте тижні на вибір "ідеальної" моделі. Почніть, логуйте реальні результати — і замінюйте тільки якщо бачите конкретні проблеми.

Цей розділ — навігаційний. Повне порівняння 10+ моделей з цінами, бенчмарками і матрицею вибору — у якорній статті Embedding-моделі для RAG у 2026. Тут — три сценарії для швидкого старту.

Сценарій 1: локальна розробка без витрат

nomic-embed-text через Ollama — безкоштовно, 768 вимірів, 8K контекстне вікно. Запускається однією командою: ollama pull nomic-embed-text. Підходить для прототипів і навчання, дані не покидають ваш комп'ютер.

Сценарій 2: API-старт із мінімальними витратами

text-embedding-3-small від OpenAI — $0.02 за мільйон токенів, 1536 вимірів. Для блогу з 500 статей це менше $1 на місяць. Найширша екосистема інтеграцій, найпростіший старт через API. Мінус: якість на українській нижча ніж на англійській.

Сценарій 3: мультимовний контент з кирилицею

BGE-M3 (open-source, self-hosted) або Cohere embed-v4 ($0.10/1M токенів) — обидві підтримують 100+ мов з однаковою якістю для латиниці і кирилиці. BGE-M3 також підтримує hybrid search "з коробки": dense + sparse вектори в одній моделі.

• ✔️ Починайте з простого — nomic або OpenAI small
• ✔️ Мультимовний контент → BGE-M3 або Cohere
• ✔️ Деталі і бенчмарки → якорна стаття

Я раджу: вибір моделі — менш критичне рішення, ніж якість ваших даних і стратегія чанкінгу; стартуйте швидко й оптимізуйте на реальних запитах.

❓ Часті питання (FAQ)

Чим embedding відрізняється від токена?

Токен — це одиниця тексту (слово або його частина), яку AI виділяє при розбитті. Embedding — це числовий вектор, що кодує сенс цього токена або цілого речення. Токени — рівень синтаксису, embeddings — рівень семантики. Детально про токени — у статті про токени.

Чи потрібно переіндексувати базу при зміні embedding-моделі?

Так, обов'язково. Різні моделі генерують вектори в несумісних просторах: вектор від OpenAI і вектор від BGE-M3 не можна порівнювати між собою. Якщо ви змінили модель — потрібно перегенерувати всі вектори заново. Саме тому вибір моделі на старті — важливе архітектурне рішення.

Чи можна використовувати один embedding для пошуку і для класифікації?

Технічно — так, але якість буде нижчою. Деякі моделі (наприклад, Cohere embed-v4 або Jina v5) підтримують "task-specific" режими: ви вказуєте тип задачі (retrieval, classification, matching) і модель оптимізує вектор під неї. Якщо задач кілька — розгляньте такі моделі.

Як перевірити якість embedding для мого контенту?

Найпростіший спосіб: візьміть 10–20 реальних запитів, зробіть пошук і подивіться на топ-3 результати з cosine similarity score. Якщо релевантні результати мають score нижче 0.6 або нерелевантні вище 0.7 — модель не підходить для вашого контенту. Бенчмарки (MTEB) — корисний орієнтир, але тестування на реальних даних завжди пріоритетніше. Для системного підходу до оцінки дивіться гайд по метриках і evaluation pipeline для RAG.

Чи можна зробити embedding для зображень?

Так. Мультимодальні моделі (наприклад, Google Gemini Embedding 2) генерують вектори і для тексту, і для зображень в одному просторі. Це дозволяє шукати зображення за текстовим описом або навпаки — і знаходити зображення, схожі за змістом, а не за пікселями.

✅ Висновки

• 🔹 Embedding — це перетворення тексту на числовий вектор, де близькість чисел відображає близькість сенсу
• 🔹 Модель навчається через контрастне навчання на мільярдах текстових пар — без ручної розмітки
• 🔹 Розмірність (384–3072) — компроміс між якістю і ресурсами; для більшості задач достатньо 768–1536
• 🔹 Embeddings лежать в основі RAG, семантичного пошуку, рекомендацій і класифікації
• 🔹 Вони не вміють точно працювати з числами, ID і короткими запитами — для цього потрібен hybrid search
• 🔹 Для старту: nomic-embed-text локально або text-embedding-3-small через API; для кирилиці — BGE-M3 або Cohere

Головна думка: Embedding — це мова, якою AI описує сенс. Розуміючи як вона влаштована, ви зможете будувати системи що знаходять правильну інформацію — а не просто правильні слова.

Якщо хочете зрозуміти як embeddings використовуються у пошуку на рівні математики — Vector Search для початківців. Якщо готові обирати конкретну модель — Embedding-моделі для RAG у 2026.