1536 vs 3072 embeddings: порівняння для пошуку по документах та RAG

Коли команда будує RAG-пайплайн і retrieval повертає нерелевантні результати — типова перша реакція: «треба взяти більшу embedding-модель». Логіка зрозуміла: більше вимірів → більше інформації → кращий пошук. Але дані кажуть інше.

Ця стаття — технічний розбір для розробників, які проектують RAG під конкретні обмеження по RAM, вартості і якості. Ми дивимось на цифри: MTEB-бенчмарки, вартість storage, latency, і порівнюємо альтернативи — зокрема reranking, який у більшості сценаріїв дає більший приріст retrieval якості за меншу ціну ніж перехід на 3072-вимірну модель.

Якщо ви ще на етапі вибору підходу до парсингу документів перед векторизацією — спочатку читайте попередні статті серії: «Як OCR впливає на якість RAG-систем» і «Vision RAG vs OCR: порівняння підходів». Погані вхідні дані nullify будь-яку перевагу від кращої embedding-моделі.

Що таке embedding-вектор і що означає його розмірність

Embedding-модель перетворює текст у числовий вектор — список чисел фіксованої довжини. Цей вектор є «координатою» тексту у n-вимірному семантичному просторі. Тексти зі схожим значенням мають близькі вектори (висока cosine similarity); тексти з різним значенням — далекі.

Розмірність вектора — це кількість чисел у цьому списку. text-embedding-3-small повертає 1536 чисел на вхідний текст. text-embedding-3-large — 3072.

Що вимірює розмірність

Важливо: розмірність — це властивість архітектури моделі і її тренування, а не просто «більше = краще». Дослідження production RAG-систем показує, що зниження з 1536 до 384 вимірів у деяких сценаріях не дає вимірюваного падіння retrieval accuracy — при цьому скорочуючи latency вдвічі і storage на 75%.

Matryoshka Representation Learning (MRL): використовуй large, зберігай менше

text-embedding-3-large і text-embedding-3-small підтримують MRL — підхід, при якому перші виміри вектора несуть найбільш загальний семантичний сигнал, а кожен наступний додає деталізацію. Це дозволяє «обрізати» вектор після генерації без повного перенавчання моделі.

Практично: генеруєш 3072-вимірний вектор через API, але зберігаєш лише перші 256, 512, 1024 або 1536 вимірів через параметр dimensions. Якість падає не пропорційно — нелінійно:

Скорочення з 3072 до 1536 вимірів дає −50% RAM при втраті лише 1.6% якості. До 1024 — −66% RAM при −2.8% якості. Це найпрактичніший компроміс для більшості сценаріїв.

Важливо: MRL працює тільки з моделями, які явно навчені з цією технікою (text-embedding-3-* від OpenAI, частина моделей Cohere і Nomic). Звичайне «обрізання» вектора довільної моделі дасть деградацію без гарантій.

Як розмірність впливає на якість семантичного пошуку

Теоретична перевага вищої розмірності реалізується не завжди і не рівномірно. Вплив залежить від трьох факторів: характеру документів, типу запитів і наявності інших компонентів пайплайну.

Де розмірність дійсно важлива

Де розмірність майже не важлива

text-embedding-3-small (1536) vs text-embedding-3-large (3072): реальні відмінності

MTEB-бенчмарк: цифри

MTEB (Massive Text Embedding Benchmark) — стандартний бенчмарк для порівняння embedding-моделей. Для RAG найрелевантніша метрика — MTEB Retrieval (nDCG@10).

Джерело: ICLERB Benchmark, MTEB Leaderboard листопад 2024.

8.5% приріст nDCG@10 — це реальна різниця, але важливо розуміти контекст: це бенчмарк на загальному наборі задач. На вашому конкретному корпусі різниця може бути більшою або меншою. І за 6.5× вищу вартість ембедингу плюс 2× вищу вартість storage.

Контекст ринку: OpenAI вже не лідер

text-embedding-3-large не оновлювалась з січня 2024 року. За даними MTEB Leaderboard квітень 2026, ландшафт суттєво змінився:

Qwen3-Embedding-0.6B з 1024 вимірами (70.70 MTEB) перевершує text-embedding-3-large з 3072 вимірами (66.43 MTEB) — при меншій розмірності і повній self-hosted доступності. Це нагадує головний меседж статті: розмірність ≠ якість.

Практична різниця на реальних задачах

Вплив на RAM, дисковий простір і швидкість пошуку

Вартість зберігання векторів — лінійна від розмірності. Кожен float32 займає 4 байти. 1536 вимірів × 4 = 6 144 байт (~6 KB) на вектор. 3072 вимірів — рівно вдвічі більше.

Конкретні числа для типових колекцій

Джерело: Qdrant documentation; arXiv 2505.00105 — Optimization of embeddings storage for RAG.

Вартість managed vector DB при масштабі

За аналізом Vector DB Costs 2026, одна embedding call до text-embedding-3-large генерує 3072-вимірний вектор — 10M документів дають 120 GB сирих векторних даних до індексування. Управлінські витрати на Pinecone для 10M векторів з 3072 вимірів — ~$70–120+/місяць проти $35–65 для 1536 вимірів.

При self-hosted Qdrant: 1M векторів 1536 вимірів потребують мінімум 4GB RAM tier (~$36/місяць на Qdrant Cloud). 3072 вимірів при тому ж обсязі — 8GB RAM tier, ~$72/місяць.

Швидкість пошуку (ANN latency)

Практична порада: pgvector і 3072 вимірів

Якщо ви використовуєте pgvector — зверніть увагу на важливе обмеження: GCP PostgreSQL не дозволяє створювати HNSW-індекси для векторів >2000 вимірів. text-embedding-3-large з 3072 вимірами на pgvector у GCP означає brute-force пошук без індексу — катастрофічна деградація latency на колекціях 100 000+ чанків. Або скорочуйте до 1536 через dimensions параметр API, або переходьте на Qdrant/Weaviate.

Порівняння на типових RAG-сценаріях: юридичні документи, технічна документація, FAQ

Сценарій 1: юридичні документи

Юридичні тексти — складний випадок для dense retrieval. Там є і точні числові значення (суми, дати, статті), і тонкі семантичні відмінності (відповідальність vs зобов'язання).

Ключовий висновок для юридичних документів: різниця між 1536 і 3072 у dense-компоненті мінімальна порівняно з ефектом від додавання BM25 в hybrid pipeline. Дослідження на фінансових документах T2-RAGBench (2026) показує, що hybrid + reranker дає Recall@5 = 0.816 проти 0.587 для чистого dense retrieval з text-embedding-3-large — приріст +39% без зміни embedding-моделі.

Сценарій 2: технічна документація

Технічна документація (API-довідники, специфікації, RFC) містить вузькоспеціалізовану термінологію. Тут 3072-вимірна модель дає більш помітний ефект — вузькі терміни кодуються точніше у більшому просторі.

Але і тут важливий нюанс: якщо документація містить точні назви (функцій, параметрів, версій), BM25 або hybrid залишається кращим варіантом для точних запитів. Dense-компонент допомагає для «як зробити X» запитів.

Сценарій 3: FAQ і helpdesk

FAQ — найпростіший сценарій для embedding-моделей. Запити і відповіді семантично прямолінійні. Для FAQ і helpdesk систем навіть 384-вимірна модель дає прийнятну якість — різниця між 1536 і 3072 на цих даних мінімальна.

Для FAQ оптимальна стратегія — почати з text-embedding-3-small або навіть BGE-small (384 вимірів), виміряти Recall@5 на тестовому наборі питань, і тільки якщо є вимірюваний дефіцит — переходити до більшої моделі.

Загальна таблиця по сценаріях

Чому якість моделі важливіша за кількість вимірів

Порівняння text-embedding-3-small (1536) і text-embedding-3-large (3072) — це порівняння двох продуктів одного вендора. Але реальна картина ширша: є моделі з меншою розмірністю і вищою якістю.

Вже згадана Qwen3-Embedding-0.6B (1024 вимірів, MTEB 70.70) перевершує text-embedding-3-large (3072 вимірів, MTEB 66.43) за загальним MTEB-бенчмарком при меншій розмірності. Apache 2.0, повний self-hosting.

Фактори, що визначають якість embedding понад розмірність

«FAISS Hybrid Paradox»: коли більша модель гірша

Дослідження «Rethinking Hybrid Retrieval» (2025) виявило контрінтуїтивний результат: MiniLM-v6 (компактна модель) стабільно перевершує BGE-Large при інтеграції з LLM-based reranking у tri-modal hybrid retrieval. Різниця: до 23.1% кращий nDCG@10 і 36.5% кращий nDCG@1 у фінансовому домені — при 93% менших параметрах і 63% менших embeddings.

Причина — «FAISS Hybrid Paradox»: embedding-простір великих моделей може не збігатись з критеріями релевантності LLM-reranker. Більша модель дає більш «розтягнутий» простір, який LLM-reranker переранжовує гірше ніж компактний.

Висновок: якщо у вашому пайплайні є reranker — не факт що більша embedding-модель покращить результат. Тестуйте на своїх даних.

Reranking як альтернатива збільшенню розмірності

Reranker (або cross-encoder) — другий етап retrieval. На першому етапі embedding-модель знаходить top-k кандидатів за cosine similarity (швидко, але неточно). На другому — reranker переранжовує цих кандидатів, оцінюючи кожну пару (запит, документ) разом (повільно, але набагато точніше).

Чому reranker точніший за embedding

Bi-encoder (embedding-модель) кодує запит і документ незалежно. Це дозволяє швидкий ANN-пошук, але означає що модель не «бачить» запит і документ одночасно під час кодування.

Cross-encoder (reranker) кодує пару (запит + документ) разом. Self-attention «бачить» обидва тексти одночасно і може оцінити тонкі семантичні взаємодії. Це набагато дорожче обчислювально — але і набагато точніше.

Реальні числа: що дає reranker

Hybrid + reranker дає Recall@5 = 0.816 проти 0.587 для чистого dense — +39% без зміни embedding-моделі. Для порівняння: перехід з text-embedding-3-small на large дає ~8.5% за MTEB Retrieval.

Популярні reranker-рішення

Коли reranker не достатньо

Reranker переранжовує тільки те, що потрапило у top-k від першого етапу. Якщо релевантний чанк взагалі не потрапив у top-50 кандидатів — reranker не допоможе. У цьому випадку потрібна краща embedding-модель або hybrid retrieval з більшим k.

Також важливо: reranker додає latency (~100–500 мс на 50 кандидатів). Для real-time систем з вимогами <500 мс end-to-end — це може бути обмеженням.

Матрична логіка вибору: розмір колекції × точність × бюджет

Алгоритм прийняття рішення

FAQ: часті питання про розмірність embeddings

Чи варто переходити з 1536 на 3072?

З мого досвіду — в більшості випадків ні, принаймні не як перший крок. Перехід small → large дає ~8.5% приросту MTEB Retrieval, але коштує 6.5× дорожче за API і вдвічі більше за storage. Перш ніж міняти модель, я завжди спочатку перевіряю: чи впроваджений hybrid retrieval (BM25 + dense), чи є reranker. Ці два компоненти разом дають +39% Recall@5 — без зміни розмірності взагалі. Якщо після цього дефіцит якості залишається — тоді так, перехід на 3072 або на кращу модель виправданий.

Наскільки зростає споживання RAM?

Рівно вдвічі — залежність лінійна. 1M чанків на 1536 вимірах займають ~6.1 GB RAM, на 3072 — ~12.2 GB. На 10M чанків це вже різниця між 61 GB і 122 GB — фактично різний tier сервера і різний бюджет на інфраструктуру. Для невеликих колекцій (до 100K чанків) різниця некритична: 600 MB проти 1.2 GB вміщуються в будь-який сучасний інстанс. Але при масштабуванні це стає першим обмеженням.

Чи впливає розмірність на швидкість pgvector?

Впливає, і є важлива практична пастка. По-перше, вищі виміри означають більше операцій при обчисленні cosine similarity — query latency зростає. По-друге, і це критично: GCP PostgreSQL не підтримує створення HNSW-індексів для векторів більше 2000 вимірів. Якщо використовуєш text-embedding-3-large (3072) з pgvector на GCP — отримуєш brute-force пошук без індексу, що на колекціях 100K+ чанків дає катастрофічну деградацію latency. Рішення: або скорочуй до 1536 через параметр dimensions в API, або переходь на Qdrant чи Weaviate.

Чи потрібні 3072 виміри для невеликого RAG?

Ні. При колекції до 50K чанків різниця між 1536 і 3072 практично невідчутна — будь-яка модель знайде правильний чанк у невеликому індексі. Я рекомендую починати з text-embedding-3-small або навіть BGE-small (384 вимірів), виміряти Recall@5 на тестовому наборі питань і лише тоді приймати рішення. Більшість команд, з якими я працював, виявляли що проблема не в розмірності, а в якості вхідного тексту або відсутності reranker.

Що важливіше: модель чи розмірність?

Модель — завжди важливіша. Найкращий приклад: Qwen3-Embedding-0.6B з 1024 вимірами набирає 70.70 MTEB, тоді як text-embedding-3-large з 3072 вимірами — 66.43. Менша розмірність, кращий результат. З мого досвіду, пріоритетний порядок оптимізації RAG виглядає так: спочатку якість вхідного тексту, потім chunking-стратегія, потім hybrid retrieval і reranker — і тільки після цього вибір або зміна embedding-моделі. Розмірність — це остання змінна, яку варто крутити.

Висновки

Вибір між 1536 і 3072 вимірами — не головне рішення при проектуванні RAG-пайплайну. Воно стоїть набагато нижче в пріоритетах ніж якість вхідних даних, chunking-стратегія і наявність hybrid retrieval з reranker.

Ключові висновки