Компанія з галузі професійних послуг впровадила RAG на 4 000 договорів та внутрішніх процедур. Перші тести з популярною хмарною моделлю дали recall@5 на рівні 58%. Після заміни на BGE-M3, запущений локально, recall зріс до 79%. Різниця полягала в одній причині: українська відмінюваність. Слово «замовлення» в родовому відмінку та «замовлення» в називному — для простої моделі це два різні токени, для BGE-M3 — дві близькі точки у векторному просторі.
Чому українська мова є викликом для ембедінгів#
Українська має багату відмінюваність: іменники змінюються за 7 відмінками, дієслова — за особами, числами та родами. Одне поняття може з’являтися в документах як «постачальник», «постачальника», «постачальником», «постачальники» (мн.). Моделі, треновані переважно на англійській, сприймають кожну форму як окремий токен і навчаються лише тих форм, які бачили достатньо часто в корпусі.
Додаються діакритики. Користувачі під час пошуку часто вводять «звязок» замість «зв'язок» або «воз» замість «візьми». Хороша модель для української має розміщувати обидві форми близько одна до одної у векторному просторі, а не сприймати їх як різні слова.
Третя проблема — змішана мова документів. Договори, процедури ISO, ділова кореспонденція містять англійські терміни (compliance, vendor, deliverable), скорочення (NDA, SLA, KPI) та українські речення. Монолінгвальна модель для української може не знати цих термінів в англійському контексті. Мультимовна модель справляється краще, бо бачила обидві мови в одному реченні.
Критерії вибору моделі ембедінгів для українського RAG#
Під час вибору моделі перевір п’ять параметрів.
Мультимовність з багатим слов’янським корпусом. Не кожна модель «мультимовна» тренувалася на українській у рівній пропорції. 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 та GDPR. Якщо обробляєш договори, кадрові дані або ділову кореспонденцію, self-hosting — це вибір за замовчуванням. Локальна модель (через Ollama або прямий сервер ONNX) не надсилає фрагменти документів до зовнішніх API. Це не питання переваг, а основа відповідності GDPR ст. 28 (договір доручення обробки).
Швидкість індексації. При 50 000 фрагментів модель, що працює на CPU сервера (наприклад, BGE-M3 через Ollama), займає 40-90 хвилин під час першої індексації. Модель через хмарне API: 5-15 хвилин. Для інкрементального реіндексування різниця менша, але її варто врахувати в архітектурі.
Порівняння моделей: мультимовна vs. спеціалізована#
| Критерій | BGE-M3 (мультим., локальний) | multilingual-e5-large (мультим., локальний) | text-embedding-3-small (мультим., хмара) | Моделі UK-only (sdadas/Ukrainian-RoBERTa) |
|---|---|---|---|---|
| Українська відмінюваність | дуже добра | добра | добра | дуже добра |
| Мішані документи UK/EN | дуже добра | добра | дуже добра | слабка |
| Розмірність вектора | 1024 | 1024 | 1536 | 768 |
| Макс. довжина контексту | 512 (стандартно) / 8192 (ColBERT) | 512 | 8192 | 512 |
| Self-hosting | так (Ollama/ONNX) | так (Ollama/HF) | ні (API OpenAI) | так (HF) |
| GDPR (без виходу даних) | так | так | ні (дані до хмари) | так |
| Операційні витрати | ресурси сервера | ресурси сервера | оплата за токени | ресурси сервера |
| Зрілість для UK | висока | середня | висока | висока, але UK-only |
Практичні висновки: для проектів з GDPR та мішаними документами 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).
Повний огляд семантичного пошуку в компанії знайдеш у статті Семантичний пошук та ембедінги у компанії.
Спробуй наживо#
FAQ#
Чи справді BGE-M3 краще справляється з українською відмінюваністю, ніж англійські моделі?#
BGE-M3 тренувався на мультимовному корпусі, що включає слов’янські мови, зокрема українську. У тестах на українських юридичних та технічних документах досягає recall@5 на 10-20 відсоткових пунктів вище, ніж моделі, що базуються виключно на англійській або старому mBERT. Різниця особливо помітна при запитах у відмінкових формах (родовий, орудний), які користувачі пишуть природно, а документ містить форму називного відмінка.
Коли варто обирати монолінгвальну модель (лише UK) замість мультимовної?#
Коли твій індекс містить виключно українські документи без англійської термінології, а тобі важлива максимальна точність при простих фактографічних запитах. Моделі UK-only (наприклад, sdadas/Ukrainian-RoBERTa-base-finetuned-ukrainian-question-answering) можуть давати трохи кращі результати на чистому українському тексті. При мішаних документах UK/EN або листуванні з англійськими скороченнями перевага швидко зникає.
Скільки триває перша індексація при BGE-M3 локально?#
На типовий сервер з 16 ГБ RAM та CPU (без GPU) індексація 10 000 фрагментів по 400 токенів займає 15-30 хвилин. При 50 000 фрагментів: 60-90 хвилин. Перерахунок ембедінгів відбувається один раз; наступні запити швидкі (кілька мілісекунд). Якщо важлива швидша перша індексація, варто розглянути сервер з GPU або хмарне API (для даних, не охоплених GDPR).
Чи можна використовувати різні моделі ембедінгів для різних колекцій документів?#
Так, але кожна колекція має використовувати одну й ту саму модель під час індексації та запитів. Змішування моделей в одному індексі недопустиме: вектори з різних моделей не є геометрично порівнюваними. Якщо хочеш змінити модель, потрібно переіндексувати всю колекцію. Тому рішення про модель має передувати побудові продуктивного індексу.
Як GDPR впливає на вибір моделі ембедінгів?#
Якщо твої документи містять персональні дані (імена, номери паспортів, адреси в листуванні), їхнє надсилання до зовнішнього API ембедінгів вимагає договору доручення обробки з постачальником (ст. 28 GDPR) та аналізу DPIA при високому ризику. Self-hosting моделі локально усуває цю проблему: фрагменти документів ніколи не залишають твою інфраструктуру. Перед впровадженням перевір також оцінку готовності твоєї організації до впровадження AI.