Як вибрати embedding-модель для української, коли жоден бенчмарк вам не підходить

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Вибір embedding-моделі для RAG зазвичай виглядає просто: відкриваєш MTEB leaderboard, дивишся на топ, береш першу модель, яка влазить у бюджет. Для англійської це працює. Для української юридичної — ні, і нижче я покажу, чому.

Про проєкт

Юстай — RAG-чатбот для консультацій з українського законодавства: користувач ставить питання українською, система знаходить релевантні фрагменти офіційних документів і передає їх LLM разом із питанням (покликати можна тут — yust.ai). Якість retrieval тут — головне вузьке місце: якщо потрібна стаття закону не потрапила в top-K результатів пошуку, жодна LLM її не «довигадає» (точніше, довигадає — і це буде галюцинація).

Вектори ми зберігаємо в PostgreSQL з pgvector, а не в окремому векторному сервісі (Qdrant, Weaviate, Milvus). Наш корпус — ~308 тисяч чанків з ~1040 документів; для такого масштабу pgvector з HNSW-індексом більш ніж достатній: одиниці мілісекунд на 11 тисячах рядків, десятки — на 308 тисячах. А операційний виграш від однієї бази суттєвий: немає синхронізації між метаданими чанків і векторами, один бекап, одна модель доступу, і гібридний пошук (vector + FTS + trigram) живе в одному engine.

Перший pipeline працював на OpenAI text-embedding-3-small. Питання стояло так: чи залишаємо якість на столі, і скільки коштує це перевірити? Виявилося — менше $0.50 в API-витратах, а результат — +15 процентних пунктів Recall@5. Нижче повна історія, включно з несподіванкою з Matryoshka-розмірностями.

Про дати: бенчмарк ми проводили у квітні 2026-го, всі числа нижче — звідти. Вибрана за його результатами модель з кінця квітня працює в production, тож наприкінці розповім, як це рішення постаріло за 4 місяці.

Що таке embedding-модель

Embedding-модель перетворює текст на вектор — масив із сотень або тисяч чисел, у якому семантично близькі тексти отримують схожі вектори. «Розірвання шлюбу» і «як розлучитися» опиняться поруч у векторному просторі, хоча не мають жодного спільного слова — саме тому векторний пошук знаходить те, що пропустив би пошук за ключовими словами.

У RAG це працює так: кожен фрагмент корпусу один раз перетворюється на вектор і зберігається в базі; запит користувача теж перетворюється тією ж моделлю, і система шукає найближчі до нього вектори (у нас — за косинусною відстанню). Якість embedding-моделі напряму визначає, чи потраплять правильні фрагменти в top-K — тобто це перша ланка, від якої залежить все інше.

Проблема: MTEB не знає про українську юридичну

MTEB (Massive Text Embedding Benchmark) — стандартний спосіб порівнювати моделі embedding. Там сотні моделей, десятки задач, зручні фільтри. Мені потрібні були два фільтри одночасно: мова = українська, домен = legal.

Що я знайшов:

• Український пресет: 203 моделі, ранжовані за українськими завданнями. Але всі задачі — у загальному домені: Вікіпедія, новини, відгуки. Юридичних текстів немає.
• Legal-пресет (MTEB Law, RTEB Legal): юридичний retrieval є — але тільки англійською та німецькою (AILA, GerDaLIR, LegalQuAD...). Української немає взагалі.
• Комбінований фільтр «українська + legal»: 0 задач. Перетин порожній.

Тобто, прочитати готове число з leaderboard неможливо. Але часткові фільтри все одно дали корисний сигнал.

Що показав український general-domain пресет

Retrieval-оцінки для української (MTEB multilingual, відфільтрований по укр. задачах):

Ключовий рядок тут — останній. text-embedding-3-small — сильна універсальна модель для англійської, але для української це середина рейтингу: ~12 пунктів відставання від топових моделей. Тобто запас для покращення, найімовірніше, реальний.

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

Shortlist на власний бенчмарк:

• text-embedding-3-small — діючий чемпіон, якого треба перемогти
• bge-m3 — перевірена мультимовна середня вага
• qwen3-embedding-4b — баланс якість/вартість
• qwen3-embedding-8b — перевірка стелі

Архітектурні рішення перед бенчмарком

Окрема таблиця векторів на кожну модель

Розмірності у моделей різні: 1024 у BGE-M3, 1536 у OpenAI, 2560 у Qwen3-4B, 4096 у Qwen3-8B. Колонки pgvector типізовані за розмірністю, тому «одна таблиця з nullable-колонками під кожну модель» швидко перетворюється на болото.

Натомість: таблиця legal_chunk_vec_<slug> для кожної моделі, з CASCADE FK на спільну таблицю чанків. Можна дропнути або перебудувати вектори однієї моделі, не чіпаючи інші. Бонус: таблиця baseline-моделі сама визначає бенчмарк-вибірку — наступні моделі векторизують рівно ті самі чанки через INNER JOIN з нею.

Чанкування окремо від embedding

Чанки (текст, breadcrumb, метадані) живуть у власній таблиці, незалежній від моделей. Зміна стратегії чанкування → перебудова чанків → усі моделі перевекторизуються. Зміна моделі → перебудовується тільки її таблиця векторів. А production тим часом працює на старому pipeline і нічого не помічає.

Gold set: свій, бо чужого немає

Retrieval-бенчмарк — це пари (запит, релевантні chunk_id). Публічного набору для українського legal немає, тому генеруємо власний.

Процес:

1. Семплюємо випадкові чанки з контентом довжиною ≥ 120 символів.
2. Для кожного відправляємо breadcrumb + контент у Gemini 2.5 Flash.
3. Просимо: сформулюй українською питання, яке поставила б звичайна людина і на яке цей чанк відповідає. Плюс категорія (direct, definition, procedural, temporal, paraphrase) і self-confidence флаг.

Стартовий набір: 203 запити. Зберігаємо їх як чернетки, з окремим ручним затвердженням для чисел, які підуть у публікацію. Але для порівняння моделей використовуємо чернетки як є: ranking моделей стійкий до шуму — відбраковка кількох слабких LLM-згенерованих питань не змінить, хто переможе.

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

Бенчмарк-вибірка: 11.5K чанків замість 308K

Повний корпус на кожну модель — це можливо (~$0.40 за прохід), але повільно для ітерацій. Натомість:

• усі 203 чанки, на які посилаються запити (gold);
• плюс ~10K випадкових чанків як дистрактори;
• разом 11 516 чанків — ~250 дистракторів на кожен gold-чанк.

Цього достатньо, щоб тиснути на якість retrieval, а прохід однієї моделі займає ~6 хвилин. Абсолютні числа трохи оптимістичніші, ніж були б на повному корпусі, але ranking моделей переноситься надійно.

Що саме ми міряємо: словничок метрик

Перш ніж дивитись на таблицю, що означають її рядки? Всі метрики рахуються так: беремо запит («чи звільняє відсутність роботи від сплати аліментів?»), шукаємо по векторах, дивимося, на якій позиції у видачі опинився gold-чанк — той самий, з якого питання було згенероване. І так 203 рази.

• Recall@K — частка запитів, у яких gold-чанк потрапив у перші K результатів. Recall@5 = 93% означає: у 93% випадків правильний фрагмент закону є серед топ-5. Це головна метрика для RAG: у промпт LLM потрапляє саме top-K, тому Recall@K — це буквально «ймовірність, що модель взагалі побачить правильну статтю».
• MRR (Mean Reciprocal Rank) — середнє значення 1/позиція першого правильного результату. Знайшли на 1-му місці — запит дає 1.0, на 2-му — 0.5, на 5-му — 0.2, не знайшли — 0. MRR = 0.92 означає «правильна відповідь майже завжди перша». На відміну від Recall, MRR розрізняє «знайшли першим» і «знайшли п’ятим».
• nDCG@10 (normalized Discounted Cumulative Gain) — схожа ідея, але з логарифмічним дисконтом за позицію: результат на 2-му місці «коштує» трохи менше, ніж на 1-му, на 10-му — суттєво менше. Стандартна метрика в search-літературі; у нас із одним релевантним чанком на запит вона поводиться майже як MRR, наводимо для порівнюваності з іншими бенчмарками.
• Rank-1 hits — найпростіша для інтуїції: як часто правильний чанк стоїть на першому місці видачі.
• Hard misses — протилежний кінець: частка запитів, де gold-чанк не знайшовся навіть у top-50. Це найболючіша категорія: якщо retrieval промахнувся на 50 позицій, ніякий reranker чи збільшення K не врятує — відповідь буде або «не знаю», або галюцинація.

Якщо запам’ятати одне: Recall@5 — скільки запитів взагалі мають шанс на правильну відповідь; hard misses — скільки приречені.

Серце бенчмарку — це два фрагменти коду

Звучить як «фреймворк», але насправді весь харнес — це один SQL-запит і один цикл. Retrieval — звичайний top-K по таблиці векторів моделі (pgvector, HNSW cosine):

SELECT chunk_id, embedding <=> :query_vector AS dist
FROM legal_chunk_vec_qwen3_8b -- таблиця векторів конкретної моделі
ORDER BY dist
LIMIT 50;

А метрики — цикл по gold-запитах (псевдокод; повна версія ще рахує nDCG, гістограму рангів і розбивку по категоріях):

для кожного запиту q з gold set:
    vector = embed(q.text)            # той самий шлях, що й у чаті
    hits   = top_k(таблиця_моделі, vector, 50)

    rank = позиція q.expected_chunk_id у hits (або "не знайдено")

    для k у [5, 10, 20, 50]:
        recall[k] += 1, якщо rank знайдено і rank <= k
    mrr += 1 / rank, якщо rank знайдено, інакше 0

поділити акумулятори на кількість запитів — таблиця результатів готова

Плюс невелика консольна команда, яка запускає це для вибраної моделі та зберігає результати прогону в таблицю — щоб порівнювати запуски між собою. Онбординг нової моделі — це дві функції (embed батчами + embed одного запиту) і рядок у списку дозволених таблиць.

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

Всі чотири моделі векторизували ідентичні 11 516 чанків, усі 203 запити, вектори в pgvector з HNSW cosine:

По категоріях (Recall@5; вибірки для не-direct категорій маленькі, числа шумні):

Що тут цікавого:

• Qwen3-8B ріже hard misses втричі порівняно з OpenAI (19.2% → 6.4%) і бере 100% на визначеннях. Для юридичного продукту, де «що таке X?» — базовий тип запиту, це саме по собі виправдовує міграцію.
• BGE-M3 не виправдала очікувань: +3 пункти до OpenAI замість +12, які обіцяв general-domain пресет MTEB. Гіпотеза: юридична українська — вузька, специфічна лексика; перевага мультимовного генералізму згладжується, коли домінують доменні терміни. Це головний аргумент, чому міряти треба на своєму корпусі: MTEB-розрив не переноситься на домен один-в-один.
• BGE-M3 при цьому виграла у Qwen3-4B на визначеннях (93.8% vs 81.2%), програвши в усьому іншому. Можливо, спадок sparse+dense тренування, яке краще чіпляється за термінологічні збіги. Маленька вибірка — ставимось скептично.
• 12 запитів не знайшла жодна з 4 моделей. Це не проблема моделей — це або невдало згенеровані питання, або чанки, зміст яких не відповідає патерну питання. Кандидати на кураторську чистку gold set.

Несподіванка: більше Matryoshka-розмірностей ≠ краще

Нативна розмірність Qwen3-8B — 4096. Але HNSW-індекс для halfvec у pgvector обмежений 4000 розмірностями, тому truncation обов’язковий. На щастя, Qwen3 тренована з Matryoshka Representation Learning: перші N компонент вектора — валідний embedding для будь-якого N.

Публічні числа (model card) обіцяють: 3072 розмірності → втрата ~0.3% від повних 4096; 2048 → ~1%. Ми вибрали 2048 для зберігання, але вирішили перевірити: чи матеріалізується той обіцяний виграш від 3072 на нашому домені? Перевектеризували ті ж 11 516 чанків на 3072 і прогнали бенчмарк ще раз:

3072 виявилася гіршою за 2048. Не драматично, але стабільно гірша за всіма показниками.

Наша інтерпретація: Matryoshka-моделі тренуються з явними loss-термами на стандартних breakpoints (1024, 2048, 4096). 3072 — між ними: додаткові 1024 компоненти не оптимізувалися як самостійний префікс, модель «витратила» їхню виразність на те, за що її не винагороджували. Додайте ~1 пп шуму вимірювання на 203 запитах — і 3072 програє.

Урок: перевіряйте Matryoshka-розмірності на своєму домені. Це один вечір і копійки грошей, а економить від неприємного сюрпризу в production.

fp16: чи болить halfvec

halfvec(2048) зберігає 2-байтні half-precision floats замість 4-байтних fp32 — вдвічі менше диску і пам’яті під індекс. Прямий A/B fp32-vs-fp16 на Qwen3-8B ми зробити не могли (4096 fp32 не індексується HNSW через ліміт 2000 розмірностей), але можна тріангулювати: наш Recall@5 93.1% на 2048-halfvec — в межах Matryoshka-похибки від очікуваного, тобто fp16 не додає видимих втрат. Це збігається з документацією pgvector (<0.2%). Залишаємо як default.

Вартість і латентність

Весь бенчмарк — 5 векторизацій + 5 прогонів — коштував менше $0.50 через OpenRouter + OpenAI напряму. Повна перевекторизація корпусу з 308K чанків на Qwen3-8B: ~$0.25 одноразово.

Єдина реальна ціна — латентність запиту:

Qwen3-8B через OpenRouter у ~5 разів повільніша за OpenAI. Для чат-UX це непомітно — LLM-генерація все одно займає секунди.

Прихований дивіденд: хороший embedding прибирає reranker

Є наслідок сильного embedding, який легко недооцінити: зникає потреба в reranker-і.

У часи text-embedding-3-small ми компенсували слабкий retrieval окремою стадією reranking: витягнути ~50 кандидатів вектором, прогнати через reranker (пробували і Cohere Rerank, і LLM-based варіант), повернути top-K. Класична схема «дешевий retrieval + розумний rerank». Вона працює — але має ціну на кожному запиті:

• ще одна API-залежність зі своїми лімітами, ключами і downtime;
• додаткова мережева петля в найгарячішому шляху — між пошуком і генерацією;
• вартість, що не амортизується: embedding корпусу платиться один раз, reranker — за кожен запит користувача.

Подивіться на числа порівняння ще раз: у Qwen3-8B 91.6% запитів мають правильний чанк на першій позиції, Recall@5 — 93.1%. Reranker-у просто нічого виправляти: він переставляє top-50, у якому правильна відповідь і так майже завжди в top-5. У OpenAI-3s з rank-1 у 74.4% reranker мав що робити — саме тому ми його колись і додали.

Після переходу на Qwen3-8B reranker у нас вимкнений у production (код стадії залишився за feature-флагом — стратегія з Null-реалізацією, нуль коштує). Пайплайн став простішим: запит → embedding → HNSW → LLM.

Загальне правило, яке я звідси виніс: перш ніж додавати reranker — перевірте, чи не дешевше підняти якість embedding. Reranker виправляє ranking, коли перша стадія слабка. Якщо перша стадія сильна, reranker — це латентність і залежність, які ви оплачуєте окремо.

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

1. Генерував би запити з урахуванням категорій. Наш LLM-генератор видав ~170 direct, ~16 definition, ~14 procedural і нуль решти категорій. Якщо семплювати чанки під категорію (чанки з визначеннями — для definition-питань тощо) — сигнал по категоріях був би збалансованішим.
2. Multi-relevant розмітку — раніше. Дозволити запиту посилатись на 2-3 сусідні чанки, щоб procedural-питання мірялись чесно.

Висновки

Конкретний вердикт для нас: міграція з text-embedding-3-small на Qwen3-Embedding-8B @ 2048 dims, halfvec + HNSW cosine у pgvector. Це +14.8 пп Recall@5 (кожен сьомий запит, який раніше промахувався, тепер влучає), втричі менше hard misses, 100% на визначеннях — за $0.25 одноразової перевектеризації.

Загальні висновки, якщо ви вибираєте embedding для непопулярної мови чи вузького домену:

1. Не довіряйте leaderboard сліпо, але використовуйте його як prior. MTEB правильно вказав напрямок (Qwen3 топ, OpenAI-small слабка для української), але помилився в масштабі для BGE-M3 (+12 обіцяних пп перетворились на +3 реальні).
2. Власний бенчмарк — це дешево. LLM-генерація gold set + вибірка з ~10K дистракторів + метрики Recall/MRR — кілька днів роботи і менше долара витрат. Це найкраща інвестиція в RAG-якість, яку можна зробити.
3. Ranking переноситься, абсолютні числа — ні. Маленька вибірка з розумною щільністю дистракторів надійно показує, яка модель краща, навіть якщо абсолютний Recall трохи завищений.
4. Перевіряйте нестандартні Matryoshka-розмірності. Між тренувальними breakpoints якість може просідати, а не рости.

P.S. Чотири місяці по тому

Бенчмарк був у квітні; цей текст я пишу в серпні, і за цей час рішення встигло пройти перевірку production:

• Qwen3-8B @ 2048 halfvec — досі наш єдиний retrieval-вектор. Наприкінці квітня ми повністю перейшли на нього і вимкнули старий pipeline. Жодного разу не виникло бажання відкотитися.
• Корпус виріс з ~308 до ~316 тисяч чанків (законодавство живе: редакції, нові акти), а кількість документів після нормалізації ієрархії — ~940. Довектеризація нових чанків іде фоново і коштує копійки — та сама економіка, що й у бенчмарку.
• Латентність через OpenRouter на практиці не болить. Єдиний нюанс: довелося запінити конкретного провайдера через provider.order, бо дефолтний роутинг інколи віддавав запит провайдеру з іншою поведінкою — дрібниця, але для embedding-консистентності критична: вектори з різних inference-стеків можуть ледь помітно відрізнятись.

Якби я переганяв бенчмарк сьогодні, до shortlist додав би свіжіші моделі з верхівки українського пресету MTEB — leaderboard за ці місяці помітно оновився. Але це і є головна перевага власного бенчмарку: він переживає будь-яку конкретну модель. Нова кандидатка — це один запуск векторизації на 11,5K чанків і шість хвилин очікування, а не новий дослідницький проєкт.