Ембедінги для української мови: як обрати модель для RAG

Компанія з галузі професійних послуг впровадила RAG на 4 000 договорів та внутрішніх процедур. Перші тести з популярною хмарною моделлю дали recall@5 на рівні 58%. Після заміни на BGE-M3, запущений локально, recall зріс до 79%. Різниця полягала в одній причині: українська відмінюваність. Слово «замовлення» в родовому відмінку та «замовлення» в називному — для простої моделі це два різні токени, для BGE-M3 — дві близькі точки у векторному просторі.

Українська має багату відмінюваність: іменники змінюються за 7 відмінками, дієслова — за особами, числами та родами. Одне поняття може з’являтися в документах як «постачальник», «постачальника», «постачальником», «постачальники» (мн.). Моделі, треновані переважно на англійській, сприймають кожну форму як окремий токен і навчаються лише тих форм, які бачили достатньо часто в корпусі.

Додаються діакритики. Користувачі під час пошуку часто вводять «замовлення» замість «замовлення» або «воз» замість «візьми». Хороша модель для української має розміщувати обидві форми близько одна до одної у векторному просторі, а не сприймати їх як різні слова.

Третя проблема — змішана мова документів. Договори, процедури ISO, ділова кореспонденція містять англійські терміни (compliance, vendor, deliverable), скорочення (NDA, SLA, KPI) та українські речення. Монолінгвальна модель для української може не знати цих термінів в англійському контексті. Мультимовна модель справляється краще, бо бачила обидві мови в одному реченні.

Під час вибору моделі перевір п’ять параметрів.

Мультимовність з багатим слов’янським корпусом. Не кожна модель «мультимовна» тренувалася на українській у рівній пропорції. BGE-M3 та multilingual-e5-large мають задокументований європейський корпус. Моделі на базі mBERT або старішої версії LaBSE гірше справлялися з українською відмінюваністю.

Розмірність вектора та пам’ять. Вища розмірність (1536 vs 768) не завжди дає кращі результати, зате завжди вимагає більше оперативної пам’яті в векторній базі. При 100 000 фрагментів по 1024 виміри індекс HNSW займає близько 400-500 МБ. При 1536 вимірах — 600-800 МБ.

Довжина контексту моделі. Ембедінг перетворює весь фрагмент на один вектор. Якщо модель підтримує лише 512 токенів (близько 350 слів), а твої документи містять сторінки договорів, втрачаєш інформацію з дальшої частини фрагмента. BGE-M3 підтримує до 8192 токенів у режимі ColBERT, стандарт — 512. E5-large: 512. Для довгих документів тут важлива стратегія чанкінгу.

Self-hosting та RODO. Якщо обробляєш договори, кадрові дані або ділову кореспонденцію, self-hosting — це вибір за замовчуванням. Локальна модель (через Ollama або прямий сервер ONNX) не надсилає фрагменти документів до зовнішніх API. Це не питання переваг, а основа відповідності RODO ст. 28 (договір доручення обробки).

Швидкість індексації. При 50 000 фрагментів модель, що працює на CPU сервера (наприклад, BGE-M3 через Ollama), займає 40-90 хвилин під час першої індексації. Модель через хмарне API: 5-15 хвилин. Для інкрементального реіндексування різниця менша, але її варто врахувати в архітектурі.

Практичні висновки: для проектів з RODO та мішаними документами BGE-M3 локально — перший вибір. Для проектів без персональних даних і з потребою швидкого старту text-embedding-3-small через API скорочує час впровадження на 2-4 тижні. Моделі UK-only варто розглядати лише для індексів суто українською та без англійської термінології.

Оцінка на публічних бенчмарках (MTEB, BEIR) мало говорить про те, як модель поведеться на твоїх договорах чи процедурах ISO. Тобі потрібен власний golden set.

Створи набір з 50-100 пар: запит, репрезентативний для реальних запитів користувачів, + список з 3-5 документів, які мають з’являтися у результатах. Запити збирай від фактичних користувачів системи, не вигадуй їх за столом.

Далі виміряй дві метрики:

Recall@5 — скільки з очікуваних документів з’являється у топ-5 результатів. Хороший результат для корпоративних документів: 70-80%. Нижче 60% модель не підходить без гібридної підтримки BM25.

MRR (Mean Reciprocal Rank) — наскільки високо у списку результатів з’являється перший релевантний документ. Чим вище, тим менше контексту потрібно передавати до генеративної моделі, що знижує вартість токенів.

Оцінку варто провести на двох-трьох моделях паралельно: проіндексуй той самий набір фрагментів, запитай тим самим набором запитів, порівняй цифри. Інструменти для цього: RAGAS (open source, Python) або власний скрипт, що обчислює recall та MRR у 50 рядках коду.

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

Після вибору моделі пайплайн виглядає так.

Парсинг документів: PDF, DOCX, електронні листи через OCR або нативний парсер. Видалення колонтитулів. Для договорів варто виділяти пронумеровані розділи як окремі фрагменти.

Чанкінг: 300-600 токенів на фрагмент з 10-15% перекриттям. Для довгих пунктів договорів перекриття 20% зменшує ризик втрати контексту на межі фрагмента. Деталі описуємо в статті про підготовку даних під AI.

Ембедінги: передай фрагменти до моделі (локальної або через API), збережи вектори у векторній базі (Qdrant, pgvector).

Пошук: при запиті користувача обчисли ембедінг запиту, виконай пошук ANN, опціонально поєднай з BM25 (гібридний пошук), відфільтруй через reranker.

Генерація відповіді: передай топ-3-5 фрагментів як контекст до LLM. Перевір, чи відповідь ґрунтується на контексті (faithfulness).

Повний огляд семантичного пошуку в компанії знайдеш у статті Семантичний пошук та ембедінги у компанії.

BGE-M3 тренувався на мультимовному корпусі, що включає слов’янські мови, зокрема українську. У тестах на українських юридичних та технічних документах досягає recall@5 на 10-20 відсоткових пунктів вище, ніж моделі, що базуються виключно на англійській або старому mBERT. Різниця особливо помітна при запитах у відмінкових формах (родовий, орудний), які користувачі пишуть природно, а документ містить форму називного відмінка.

Коли твій індекс містить виключно українські документи без англійської термінології, а тобі важлива максимальна точність при простих фактографічних запитах. Моделі UK-only (наприклад, sdadas/Ukrainian-RoBERTa-base-finetuned-ukrainian-question-answering) можуть давати трохи кращі результати на чистому українському тексті. При мішаних документах UK/EN або листуванні з англійськими скороченнями перевага швидко зникає.

На типовий сервер з 16 ГБ RAM та CPU (без GPU) індексація 10 000 фрагментів по 400 токенів займає 15-30 хвилин. При 50 000 фрагментів: 60-90 хвилин. Перерахунок ембедінгів відбувається один раз; наступні запити швидкі (кілька мілісекунд). Якщо важлива швидша перша індексація, варто розглянути сервер з GPU або хмарне API (для даних, не охоплених RODO).

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

Якщо твої документи містять персональні дані (імена, номери паспортів, адреси в листуванні), їхнє надсилання до зовнішнього API ембедінгів вимагає договору доручення обробки з постачальником (ст. 28 RODO) та аналізу DPIA при високому ризику. Self-hosting моделі локально усуває цю проблему: фрагменти документів ніколи не залишають твою інфраструктуру. Перед впровадженням перевір також оцінку готовності твоєї організації до впровадження AI.