Embedding-моделі для RAG у 2026: як обрати, порівняння провайдерів

Ви побудували RAG-пайплайн, підключили LLM, налаштували vector store — а пошук повертає нерелевантні результати. Проблема майже завжди не в LLM, а в embedding-моделі. Саме вона визначає, наскільки точно система розуміє зміст тексту і знаходить правильні фрагменти. Спойлер: для 90% проєктів OpenAI text-embedding-3-small за $0.02/1M токенів — оптимальний старт. Але є ситуації, де він програє Cohere, Voyage AI або безкоштовним open-source моделям.

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

• 📌 Що таке embedding і навіщо він потрібен для RAG
• 📌 Критерії вибору embedding-моделі
• 📌 Платні API-провайдери: OpenAI, Cohere, Voyage AI, Gemini, Jina
• 📌 OpenRouter: embedding через єдиний API
• 📌 Open-source моделі: BGE-M3, Nomic, Qwen3, E5
• 📌 Таблиця порівняння всіх моделей
• 📌 Кому що підходить — матриця вибору
• 💼 Мій досвід: embedding для мультимовного блогу WebCraft
• ❓ Часті питання (FAQ)
• ✅ Висновки

🎯 Розділ 1. Що таке embedding і навіщо він потрібен для RAG

Якщо LLM — це мозок вашої RAG-системи, то embedding — це очі. Мозок може бути геніальним, але якщо очі бачать розмито — він отримає неправильну інформацію і дасть неправильну відповідь.

Як детально описано у статті RAG з Ollama: від пайплайну до продакшну, RAG-пайплайн складається з двох фаз: індексація (документ → чанки → ембединги → vector store) і пошук (запит → ембединг → similarity search → контекст → відповідь LLM). Embedding-модель задіяна в обох фазах — і саме від неї залежить, які фрагменти потраплять у контекст LLM.

Аналогія: embedding як фотографія тексту

Уявіть що ви зберігаєте фотографії в різних форматах. Фото 100×100 пікселів — займає мало місця, але деталі розмиті. Фото 4000×3000 — чітке, але важке. З embedding та сама логіка: вектор — це «фотографія» тексту в числовому просторі. Розмірність вектора (384, 768, 1024, 1536, 3072) — як роздільна здатність. Більший вектор кодує більше нюансів смислу, але займає більше місця і повільніше генерується.

Чому вибір embedding-моделі критичний

Є принципове правило: якою моделлю індексували — тією ж моделлю потрібно ембедити запит. Різні моделі дають несумісні вектори. Це означає: якщо ви вирішили змінити embedding-модель — потрібно переіндексувати всю базу заново. Тому вибір на старті має бути усвідомленим.

• ✔️ Погана embedding-модель → нерелевантні чанки в контексті → галюцинації LLM
• ✔️ Правильна embedding-модель → точний retrieval → якісні відповіді

Детальніше про те, як embedding вписується в загальну архітектуру RAG і чим RAG відрізняється від «чистого» LLM — у статті LLM vs RAG у 2026: чому це не одне й те саме.

Висновок: embedding — це фундамент якості RAG. Вибір моделі впливає на точність пошуку більше, ніж вибір LLM для генерації.

📌 Розділ 2. Критерії вибору embedding-моделі

Не існує «найкращої» embedding-моделі — є найкраща для вашої конкретної задачі, мови контенту і бюджету.

Ціна за 1M токенів

Діапазон: від $0 (open-source, self-hosted) до $0.18 (Voyage AI). Для блогу з 500 статей різниця між $0.02 і $0.13 — це центи. Для корпусу з мільйонів документів — сотні доларів щомісяця.

Розмірність вектора

384 (MiniLM) → 768 (nomic) → 1024 (mxbai) → 1536 (OpenAI small) → 3072 (OpenAI large). Більша розмірність = точніший пошук, але більше місця у vector store. Для pgvector з кількома тисячами чанків різниця в розмірі мізерна.

Контекстне вікно

Скільки токенів модель може обробити за один запит. 256 (MiniLM) — лише для коротких фрагментів. 8192 (nomic-embed-text) — достатньо для довгих статей. 32K (Jina v5) — для цілих документів без розбиття.

Мультимовна підтримка

Критично для проєктів з контентом на кількох мовах. OpenAI працює добре з англійською, гірше з кирилицею. Cohere embed-v4 підтримує 100+ мов з однаковою якістю. BGE-M3 — найсильніший open-source варіант для мультимовного пошуку.

Якість retrieval (MTEB бенчмарк)

MTEB (Massive Text Embedding Benchmark) — стандарт порівняння embedding-моделей. Але важливо розуміти: бенчмарки не завжди відображають реальну якість на ваших конкретних даних. Тестуйте на своєму контенті.

Швидкість інференсу

Для індексації (batch, нічний шедулер) — не критично. Для пошуку в реальному часі — важливо. API-провайдери зазвичай відповідають за 50–200мс. Self-hosted на CPU — повільніше.

Висновок: визначте мову контенту, бюджет і масштаб — і ці три фактори звузять вибір до 2–3 моделей.

📌 Розділ 3. Платні API-провайдери

OpenAI: text-embedding-3-small і text-embedding-3-large

text-embedding-3-small — 1536 вимірів, $0.02/1M токенів. Хороший баланс ціни і якості для англомовного контенту. text-embedding-3-large — 3072 вимірів, $0.13/1M токенів. Підтримує Matryoshka Representation Learning: можна зменшити розмірність до 256 з мінімальною втратою якості — економія на зберіганні.

Підходить: загальний RAG, англомовний контент, швидкий старт. Не підходить: мультимовний контент з кирилицею, код і техдоки (Voyage точніший).

Cohere: embed-v4

Лідер мультимовних бенчмарків. 100+ мов з якістю на рівні англійської. $0.10/1M токенів. Підтримує бінарну квантизацію — зменшення розміру зберігання на 90% з мінімальною втратою якості. Окремі input types для search і classification — оптимізація без зміни моделі.

Підходить: мультимовні продукти, глобальні застосунки, RAG з контентом на 3+ мовах. Не підходить: якщо весь контент англійською — OpenAI дешевший і SDK-екосистема ширша.

Voyage AI: voyage-3-large

Найвища точність для коду, API-документації та технічного контенту. $0.18/1M токенів — найдорожчий у списку. Окрема модель voyage-code-3 спеціально для code search. Рекомендований Anthropic як preferred embedding provider.

Підходить: developer tools, code search, технічна документація. Не підходить: загальний контент (переплата без виграшу в якості).

Google Gemini Embedding 2

Мультимодальні embedding: текст, зображення, відео і навіть аудіо без транскрипції. $0.15/1M токенів. Лідер MTEB лідерборду (score 68.32). Нативна підтримка Matryoshka Representation Learning.

Підходить: мультимодальний контент (текст + зображення), Google Cloud екосистема. Не підходить: якщо потрібен тільки текстовий embedding — дорожчий за OpenAI.

Jina AI: jina-embeddings-v5

32K контекстне вікно — найдовше серед комерційних моделей. 89 мов. Бінарна квантизація. Task-specific LoRA адаптери для retrieval, matching і classification. Ціна нижча за більшість конкурентів.

Підходить: довгі документи без розбиття на чанки, мультимовний контент за помірну ціну. Не підходить: якщо екосистема туторіалів і інтеграцій критична (менша спільнота ніж у OpenAI).

Висновок: з мого досвіду, для швидкого старту я раджу OpenAI — найпростіший і найстабільніший варіант. Cohere варто обирати, якщо працюєш із мультимовним контентом. Voyage добре підходить для технічних задач і коду. Gemini має сенс, коли потрібна робота із зображеннями та відео. Jina — оптимальний вибір, якщо критичний довгий контекст і низька вартість.

📌 Розділ 4. OpenRouter: embedding через єдиний API

Доступні embedding-моделі на OpenRouter

openai/text-embedding-3-small — $0.02/1M токенів, 1536 вимірів. openai/text-embedding-3-large — $0.13/1M токенів, 3072 вимірів. qwen/qwen3-embedding-8b — $0.01/1M токенів, мультимовна, оптимізована для retrieval і classification. qwen/qwen3-embedding-0.6b — ~$0.004/1M токенів, базова якість, мінімальна ціна.

Коли OpenRouter — правильний вибір

• ✔️ Потрібно швидко порівняти кілька embedding-моделей на одних даних
• ✔️ Проєкт вже використовує OpenRouter для LLM (один API-ключ і білінг)
• ✔️ Потрібен fallback: якщо один провайдер впав — автоматичне переключення

Коли краще напряму до провайдера

• ⚠️ Потрібні специфічні фічі провайдера (Cohere binary quantization, Jina LoRA adapters)
• ⚠️ Enterprise SLA і гарантії доступності

Для локальної розробки з Ollama embedding-моделі запускаються безкоштовно без жодного API. Детальніше — Ollama у 2026: що це таке і чому розробники масово переходять на локальний AI.

Висновок: для мене OpenRouter — зручний агрегатор для порівняння моделей і швидкого старту. Для production зі специфічними вимогами я рекомендую використовувати прямий API провайдера.

📌 Розділ 5. Open-source моделі (self-hosted)

BGE-M3 (BAAI)

Гібридний пошук: dense + sparse вектори в одній моделі. Мультимовний. Ідеальний для RAG де потрібен і семантичний, і keyword пошук одночасно. Як описано у статті RAG з Ollama, fallback з vector search на keyword search — критичний продакшн-патерн, і BGE-M3 вирішує це на рівні моделі.

Nomic Embed Text V2

Mixture-of-Experts архітектура. Добре працює з довгими документами. Мультимовний. Популярний у локальних RAG-стеках з Ollama як альтернатива nomic-embed-text першої версії.

Qwen3-Embedding (0.6B і 8B)

Найновіша серія від Qwen. Гнучкі розміри вектора (від 256 до 2048 вимірів — вибираєте самі). Мультимовна, instruction-aware. 8B версія доступна на OpenRouter за $0.01/1M токенів — дешевше ніж OpenAI small.

E5 і MiniLM

Легкі моделі для швидкого прототипування. MiniLM — 46 МБ, 384 вимірів. Працює навіть на слабкому залізі. E5 — трохи точніший, але обидва поступаються BGE-M3 і Qwen3 на retrieval-задачах.

Плюси і мінуси self-hosted

• ✔️ Безкоштовно — нуль витрат на API
• ✔️ Повний контроль над даними — нічого не йде в хмару
• ✔️ Немає rate limits і залежності від зовнішнього сервісу
• ⚠️ Потрібен GPU для швидкої генерації (на CPU — повільніше)
• ⚠️ Інфраструктура на вас: оновлення, масштабування, моніторинг

Висновок: open-source — правильний вибір для конфіденційних даних, мінімального бюджету або повного контролю. BGE-M3 і Qwen3-Embedding — лідери у 2026.

📌 Розділ 6. Таблиця порівняння всіх моделей

Висновок: таблиця — відправна точка. Фінальний вибір — тільки після тестування на ваших реальних даних.

📌 Розділ 7. Кому що підходить — матриця вибору

Висновок: визначте свою ситуацію в таблиці — і отримаєте конкретну рекомендацію з якої почати.

💼 Розділ 8. Мій досвід: embedding для мультимовного блогу WebCraft

Більшість проблем з embedding я знайшов не в документації — а через реальні запити користувачів, де пошук повертав не те.

Стек

Java 21, Spring Boot, Spring AI, PostgreSQL з pgvector на Railway. Embedding: openai/text-embedding-3-small через OpenRouter. LLM для генерації: meta-llama/llama-3.3-70b-instruct (безкоштовна версія). Індексація: нічний шедулер, batch по 10–20 документів.

Чому обрав text-embedding-3-small

$0.02 за мільйон токенів — для 2500 статей це буквально центи на місяць. 1536 вимірів — достатня «роздільна здатність» для блогового контенту. OpenAI-сумісний API через OpenRouter — мінімум змін у коді при переключенні моделей.

Проблеми які я знайшов

Кирилиця: якість пошуку на українських запитах помітно нижча ніж на англійських. Запит «як зробити сайт» знаходив менш релевантні результати ніж еквівалентний «how to build a website». Для мультимовного блогу це критично.

Короткі запити: запит з 1–2 слів (наприклад «RAG» або «Spring») давав розмиті результати з низьким score. Рішення — fallback на keyword search для коротких запитів, як описано у статті про RAG з Ollama.

Дублікати при переіндексації: без детермінованих ID чанків — база накопичувала дублікати. Рішення: UUID на основі document_id + номер чанка.

Що б зробив інакше

Для мультимовного контенту з кирилицею — розглянув би Cohere embed-v4 або Qwen3-Embedding-8B ($0.01/1M токенів, мультимовна). Різниця в ціні мізерна, але якість на нелатинських мовах може бути значно вищою. Це наступний крок — тестування на реальних запитах.

Реальні цифри

• ✔️ ~500 статей × 4 мови = ~2000 документів
• ✔️ ~10 000 чанків по 512 токенів
• ✔️ Індексація: ~15–20 хвилин через API
• ✔️ Вартість embedding: менше $1 на місяць
• ✔️ Пошук: 100–300мс на запит

Повний розбір RAG-архітектури для production — RAG у 2026: від PoC до production.

Висновок: для мультимовного блогу OpenAI small працює, але не ідеально з кирилицею. Для подібних проєктів варто тестувати Cohere або Qwen3 — різниця в ціні мінімальна, а якість може бути значно вищою.

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

Чи можна змінити embedding-модель без переіндексації?

Ні. Різні моделі дають несумісні вектори. Якщо змінили модель — потрібно переіндексувати всю базу заново. Саме тому вибір embedding-моделі на старті — одне з найважливіших архітектурних рішень у RAG-системі.

Безкоштовні моделі гірші за платні?

Не завжди. BGE-M3 перевершує OpenAI small на мультимовних retrieval-задачах. Qwen3-Embedding-8B на рівні з OpenAI small за якістю, коштуючи вдвічі менше. Але бенчмарки — не гарантія. Тестуйте на своїх даних.

Скільки коштує embedding для малого проєкту?

Для блогу з 500 статей на OpenAI small — менше $1 на місяць. На Qwen3 через OpenRouter — менше $0.50. Self-hosted — $0, але потрібен сервер з GPU для швидкої генерації.

Яку модель обрати для українського контенту?

OpenAI працює, але якість нижча ніж для англійської. Cohere embed-v4 і BGE-M3 значно краще з кирилицею. Якщо бюджет обмежений — Qwen3-Embedding-8B на OpenRouter ($0.01/1M токенів) з мультимовною підтримкою.

Що таке Matryoshka Representation Learning (MRL)?

Техніка яка дозволяє зменшувати розмірність вектора після генерації без перетренування моделі. Наприклад, OpenAI large генерує 3072 вимірів, але ви можете використати тільки перші 256 — з мінімальною втратою якості. Це економить місце у vector store і прискорює пошук.

✅ Висновки

• 🔹 Embedding-модель — фундамент RAG. Погана модель зробить весь пайплайн марним, незалежно від якості LLM
• 🔹 OpenAI text-embedding-3-small ($0.02/1M) — оптимальний старт для англомовного контенту
• 🔹 Для мультимовного контенту з кирилицею — Cohere embed-v4 або BGE-M3 значно точніші
• 🔹 Зміна embedding-моделі = повна переіндексація. Обирайте усвідомлено на старті
• 🔹 Бенчмарки (MTEB) — корисний орієнтир, але фінальне рішення — тільки після тестування на ваших реальних даних і запитах

Головна думка: я раджу не витрачати тижні на вибір «ідеальної» embedding-моделі. Почніть з OpenAI small або Qwen3, логуйте score на реальних запитах, і замініть модель тільки якщо бачите конкретні проблеми з якістю пошуку.

Якщо ви тільки починаєте з RAG — RAG з Ollama: від пайплайну до продакшну дасть повну картину архітектури. Якщо потрібно зрозуміти різницю між LLM і RAG — LLM vs RAG у 2026. А повний гайд з PoC до production — RAG у 2026: від PoC до production.