Більша embedding-модель — не завжди краща: наш досвід з корпоративними документами

Що таке embeddings і чому їх розмір впливає на ваш бізнес

Коли AI-система шукає відповідь у ваших документах, вона не читає кожен файл щоразу. Натомість вона заздалегідь перетворює кожен фрагмент тексту на числовий «відбиток» — вектор. Це і є embedding.

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

Розмірність — це кількість чисел у такому векторі. text-embedding-3-small від OpenAI генерує вектори з 1536 значень, text-embedding-3-large — з 3072. Здавалося б: більше чисел — точніший пошук. Але на практиці все складніше.

Чому це важливо для бізнесу? Тому що розмірність напряму впливає на три речі: швидкість пошуку, обсяг пам'яті сервера і вартість обробки документів. І якщо ви обрали розмірність «про запас» — ви платите за неї щодня.

Чому компанії переплачують за розмірність, яка їм не потрібна

Коли ми починаємо працювати з новим клієнтом, одне з перших питань, яке ми обговорюємо — яка розмірність вектора підійде для їхнього архіву. І майже щоразу звучить одна й та сама думка: «Давайте візьмемо 3072 — краще ж більше, правда?»

Це абсолютно зрозуміла логіка. Більше вимірів — ніби більше деталей, точніший пошук. Але на практиці це не завжди так. І ми пояснюємо чому — з цифрами.

За даними дослідження з оптимізації зберігання векторів у RAG-системах (arxiv, 2025), мільйон документів з 1536-вимірними векторами займає ~6,1 ГБ RAM. З 3072-вимірними — вдвічі більше, понад 12 ГБ. У хмарній інфраструктурі RAM — прямий фактор вартості щомісяця.

При цьому приріст якості пошуку мінімальний. Порівняльний аналіз embedding-моделей 2026 року показує: перехід з 1536 до 3072 вимірів дає лише 2–4 пункти nDCG на retrieval-бенчмарках. «Крива якості вирівнюється дуже швидко після 768 вимірів для більшості задач» — при вшестеро більших витратах на зберігання.

Ось як виглядає порівняння у цифрах:

Для SMB-компанії з архівом у 50 000–200 000 документів — типовий масштаб юридичної фірми, медичного центру або дистриб'ютора — різниця у витратах за рік може становити кілька тисяч доларів. Без жодного відчутного покращення в якості відповідей.

Висновок простий: «більше» у випадку з ембедингами — не завжди «краще». Це «дорожче» і «повільніше». А для більшості корпоративних документів якість пошуку з 1536 вимірами цілком достатня.

Що ми отримали з 1536 у реальному продукті

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

Наш стек: Spring Boot, Java 21, PostgreSQL з розширенням pgvector, OpenRouter як шлюз до LLM. Інфраструктура — Railway EU West (Amsterdam), зберігання файлів — Cloudflare R2 в юрисдикції ЄС. Для ембедингів обрали text-embedding-3-small з розмірністю 1536.

Чому саме 1536, а не 3072

На старті ми теж замислювались: можливо, варто взяти більшу модель — про запас? Але коли порахували реальні витрати на масштабі і подивились на бенчмарки для нашого типу документів (юридичні договори, внутрішні регламенти, HR-документи, інструкції), стало зрозуміло: різниця в якості пошуку між 1536 і 3072 для однорідних корпоративних текстів однією мовою — мінімальна. А різниця у витратах — суттєва.

Що змінилось після вибору 1536

Важливий урок: розмірність — не головна змінна

Коли точність пошуку була низькою (17%), проблема була не в тому, що ми взяли 1536 замість 3072. Проблема була в якості OCR-розпізнавання — скановані PDF давали «сміття» на вхід, і жодна розмірність ембедингу це не врятувала б.

Після впровадження Vision OCR (GPT-4o-mini для розпізнавання з автоматичним retry на 90°/180°/270° для перевернутих сканів) — точність пошуку виросла до прийнятного рівня. З тими самими 1536 вимірами.

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

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

Коли 3072 справді виправданий — а коли це зайві витрати

Ми навмисно не кажемо, що 3072 — це завжди погано. Це було б нечесно. Є сценарії, де більша розмірність дійсно виправдана — і ми самі рекомендуємо її клієнтам, коли бачимо відповідні умови. Але таких випадків серед SMB-компаній значно менше, ніж здається на перший погляд.

Коли 3072 має сенс

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

Складна доменна термінологія. Медичні протоколи, наукові статті, патентна документація — тексти, де формулювання принципово важливе і схожі за звучанням терміни означають різні речі. Тут вища розмірність дає кращу «роздільну здатність» між близькими поняттями.

Мільйонні архіви з бізнес-критичним пошуком. Якщо у вас 2–5 млн документів і навіть один пропущений релевантний результат коштує грошей або репутації — різниця в 2–4 пункти nDCG на бенчмарках стає відчутною в реальних сценаріях. На такому масштабі варто тестувати обидва варіанти.

Є інфраструктурний бюджет. Якщо RAM і storage не є обмеженням, а команда готова до вищих операційних витрат — 3072 дає певний запас точності «про всяк випадок».

Коли 1536 цілком достатньо

Однорідні документи однією мовою. Внутрішні регламенти, трудові договори, HR-документи, інструкції для персоналу, прайс-листи — це найпоширеніший тип архіву серед наших клієнтів. Тут 1536 дає якість пошуку, невідрізнювану від 3072 на практиці.

Архів до 500 000 документів. Типовий масштаб юридичної фірми, медичного центру або дистриб'ютора. На такому обсязі різниця між моделями в реальних запитах — статистичний шум, не бізнес-ефект.

Розгортання на обмежених ресурсах. Якщо ви розгортаєте систему на власних серверах або закритому контурі (Hetzner, on-premise) — вдвічі менший RAM footprint від 1536 може означати різницю між одним і двома серверами в стійці.

Важлива швидкість відповіді. Менша розмірність = швидший similarity search при тому самому залізі. Для продуктів, де користувач очікує відповідь у реальному часі, це відчутно.

Цікавий факт, який змінює інтуїцію

Як зазначає офіційна документація OpenAI, text-embedding-3-large, скорочений до 256 вимірів, все одно перевершує text-embedding-ada-002 повного розміру (1536) на MTEB-бенчмарку. Тобто сучасні моделі навчились пакувати інформацію ефективніше — і максимальна розмірність більше не є синонімом максимальної якості.

Це важливо розуміти: ми живемо вже не в епосі «більше вимірів = краще». Ми живемо в епосі ефективного кодування, де правильно навчена модель з 1536 вимірами виграє у застарілої моделі з 3072.

Коротко: матриця вибору

Як обрати розмірність під свій документний архів — чекліст

Це найпрактичніша секція статті. Якщо ви зараз стоїте перед вибором embedding-моделі для вашої AI-системи — дайте відповідь на шість питань нижче. Після кожного питання є конкретні приклади з нашої практики, щоб ви могли впізнати свій сценарій.

Питання 1: Яка мова ваших документів?

Це перше і найважливіше питання. Розмірність ембедингу суттєво впливає на якість пошуку саме в мовному контексті.

• Один архів — одна мова (всі договори українською, всі інструкції німецькою) → 1536 достатньо. Модель добре справляється з однорідним мовним контентом.
• Документи різними мовами, але в окремих файлах (частина архіву українською, частина англійською) → 1536 впорається, якщо пошук ведеться мовою документа.
• Мішанина мов в одному фрагменті (технічна документація, де в одному абзаці є англійські терміни і українські пояснення) → варто тестувати 3072.

Приклад з практики: клієнт — українська юридична фірма, архів із 40 000 договорів українською мовою. Обрали 1536. Пошук за змістом пунктів договору працює коректно, клієнт задоволений результатом.

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

Питання 2: Який обсяг архіву?

Обсяг архіву впливає на два фактори одночасно: вартість індексації (API-виклики) і вартість зберігання векторів у базі даних.

Важливо: вартість індексації — одноразова. Але вартість зберігання векторів у RAM — щомісячна. При 3072 вимірах вона вдвічі вища. Читайте також: як правильно підготувати документи для AI-пошуку — структура файлів впливає на розмір чанків і, відповідно, на кількість векторів у базі.

Питання 3: Які формати документів у вашому архіві?

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

• Цифрові PDF і Word-файли → текст чистий, індексація пряма. 1536 дасть повну якість.
• Скановані PDF (відскановані паперові документи) → головна проблема тут не розмірність, а якість OCR. Поганий OCR дає «сміття» на вхід — і жодна розмірність це не врятує. Спочатку вирішіть питання розпізнавання, і лише потім оцінюйте вектори. Детально про це — у нашому кейсі: як Vision OCR підвищує точність пошуку по сканованих документах.
• Змішаний архів (частина цифрова, частина скановані) → потрібен окремий pipeline для сканованих документів перед індексацією.

Приклад з практики: у нас був кейс, де точність пошуку по сканованому архіві становила 17%. Ми спробували змінити параметри — не допомогло. Проблема була в тому, що OCR давав перекручений текст із символами-замінниками. Після впровадження Vision OCR точність виросла до ~50% — з тими самими 1536 вимірами. Розмірність тут взагалі не була змінною.

Питання 4: Який бюджет на інфраструктуру?

Питання не лише про вартість API, а про повну вартість утримання системи (TCO): RAM сервера, storage у векторній базі, вартість хостингу.

Питання 5: Наскільки критична точність пошуку для вашого бізнесу?

Будьмо чесними: для більшості корпоративних задач різниця між 1536 і 3072 на практиці непомітна. Але є винятки.

• Пошук по внутрішніх регламентах, HR-документах, інструкціях → точність 1536 більш ніж достатня. Співробітник знайде потрібний пункт.
• Юридичний пошук по договорах → 1536 справляється. Критичніше — правильний чанкінг і якість OCR.
• Медичні протоколи з вузькою термінологією → варто протестувати 3072, особливо якщо схожі терміни означають різні процедури.
• Бізнес-критичний пошук, де пропущений результат = фінансовий або юридичний ризик → тестуйте обидва варіанти на реальному архіві перед запуском.

Питання 6: Чи є у вас ресурс на тестування?

Якщо є сумніви — найчесніша відповідь: проведіть A/B тест на вашому реальному архіві. Візьміть 50–100 типових запитів від майбутніх користувачів, проіндексуйте вибірку документів з обома моделями і порівняйте результати. Це займе кілька годин і дасть точніший результат, ніж будь-який бенчмарк.

Якщо ресурсу на тестування немає — орієнтуйтесь на таблицю нижче: