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

Ембеддинги в одному абзаці

Модель ембеддингів відображає текст у вектор так, щоб тексти з подібним змістом опинялися поруч. Сучасні моделі ембеддингів — це трансформерні енкодери, навчені з контрастивними цілями на величезних наборах пов'язаних пар текстів: запитань і відповідей, заголовків і текстів, перекладів (Reimers & Gurevych, Sentence-BERT). Під час запиту ви ембеддите запитання користувача й шукаєте найближчі вектори фрагментів у векторній базі.

На практиці важливі два наслідки:

  1. Уявлення моделі про «подібне» походить з її навчальних даних. Доменна мова (юридична, медична, бухгалтерська) і менш представлені мови можуть оброблятися гірше, ніж загальна англійська.
  2. Запитання й відповіді формулюються по-різному. Добрі моделі пошуку навчені на асиметричний пошук (короткий запит → довгий фрагмент), і багато з них очікують префікси на кшталт query: і passage:; читайте картку моделі.

Вибір моделі ембеддингів

Бенчмарк MTEB порівнює моделі ембеддингів на багатьох задачах і мовах. Ключовий висновок оригінальної статті досі актуальний: жодна модель не домінує на всіх задачах (Muennighoff et al., 2022). Використовуйте MTEB для короткого списку, а вирішуйте на власних даних.

Критерії:

Критерій Чому важливо
Оцінки пошуку вашими мовами Українська і змішаний українсько-англійсько-російський текст типові для локальних бізнес-даних
Максимальна довжина входу Визначає максимальний розмір фрагмента (512 чи 8192 токени)
Розмірність і підтримка Matryoshka Пам'ять і швидкість; вектори, які можна обрізати, економлять сховище (Kusupati et al., 2022)
Хостинг API (OpenAI, Cohere, Voyage, Google) чи відкриті ваги для власного хостингу
Вартість і пропускна здатність Переембеддинг великого корпусу трапляється частіше, ніж очікуєте
Ліцензія Ліцензії моделей з відкритими вагами різняться

Серед багатомовних відкритих моделей для української варто протестувати BGE-M3, що підтримує щільний, розріджений і багатовекторний пошук в одній моделі (Chen et al., 2024), і родину multilingual E5 (Wang et al., 2024). Комерційні API великих провайдерів теж добре працюють з українською. Власний хостинг важливий, коли документи не можуть залишати вашу інфраструктуру; див. власний хостинг LLM і приватність LLM-застосунків.

Оцінка на власних даних — це один день роботи

Зберіть невеликий набір для оцінки пошуку:

  1. Зберіть 100–200 реальних запитань (з тікетів підтримки, логів пошуку, від працівників).
  2. Для кожного позначте фрагмент(и), що містять відповідь.
  3. Заембеддьте корпус 2–4 моделями-кандидатами.
  4. Виміряйте recall@k (чи є правильний фрагмент у топ-5/10/20?) і MRR (наскільки високо він стоїть?).
def recall_at_k(results: dict[str, list[str]], gold: dict[str, set[str]], k: int) -> float:
    hits = sum(1 for q, ids in results.items() if gold[q] & set(ids[:k]))
    return hits / len(results)

for model in ["bge-m3", "multilingual-e5-large", "api-model-x"]:
    results = run_retrieval(model, questions, top_k=20)
    print(model, {k: round(recall_at_k(results, gold, k), 3) for k in (5, 10, 20)})

Різниця в 10–20 пунктів recall@10 між моделями на реальних українських бізнес-даних — звична справа, і це значно більше, ніж підказують середні з лідербордів. Цей набір також стає частиною ваших наскрізних evals для LLM.

Чанкінг: тут виграється або програється більша частина якості

Чанкінг визначає, що є «одиницею пошуку». Завеликі фрагменти змішують теми, розмивають ембеддинг і марнують контекст. Замалі — втрачають контекст, потрібний для розуміння («Комісія становить 2%» — яка комісія?).

Стратегії

  • Фіксований розмір з перекриттям. Розрізати кожні N токенів з перекриттям 10–20%. Проста базова лінія; ігнорує структуру.
  • Рекурсивний / з урахуванням структури. Розбивати за заголовками, потім абзацами, потім реченнями, доки фрагменти не вмістяться в ліміт. Найкращий варіант за замовчуванням для більшості бізнес-документів.
  • Під тип документа. Договори — за пунктами, FAQ — за запитаннями, код — за функціями, таблиці — групами рядків із повтором заголовків, листи — за повідомленнями.
  • Семантичний чанкінг. Розрізати там, де подібність ембеддингів сусідніх речень падає. Іноді допомагає для неструктурованої прози; більше обчислень, нестабільний виграш.

Типові стартові розміри — 200–800 токенів. Міряйте, а не припускайте.

Зберігайте контекст у кожному фрагменті

Фрагмент має бути зрозумілим, коли його читають окремо. Дешеві прийоми:

  • Додавайте на початок назву документа й шлях розділу: Політика повернень > Річні плани > Часткові повернення.
  • Зберігайте метадані (тип документа, дата, продукт, мова, рівень доступу) для фільтрації.
  • Не розривайте таблиці або перетворюйте їх на речення «колонка: значення» для кожного рядка.

Contextual retrieval

Техніка contextual retrieval від Anthropic використовує LLM, щоб написати короткий контекст для конкретного фрагмента («Цей фрагмент зі звіту ACME за 2 квартал 2026 року і стосується виручки в сегменті ЄС...»), який додається перед ембеддингом та індексацією BM25. В їхніх експериментах контекстуальні ембеддинги плюс контекстуальний BM25 зменшили кількість невдалих пошуків на 49%, а в поєднанні з переранжуванням — на 67%. Завдяки кешуванню промптів вартість генерації таких контекстів для всього корпусу помірна.

Late chunking і багатовекторні підходи

Альтернативи генерації контексту для кожного фрагмента: late chunking ембеддить увесь документ моделлю з довгим контекстом і усереднює ембеддинги токенів для кожного фрагмента, тож вектор фрагмента «знає» своє оточення (Günther et al., 2024). Багатовекторні моделі на кшталт ColBERT зберігають вектор для кожного токена й порівнюють на дрібному рівні, ціною більшого сховища (Khattab & Zaharia, 2020).

Гібридний пошук і переранжування

Ембеддинги вловлюють зміст, але слабші на точних ідентифікаторах — номерах статей, артикулах, кодах помилок, іменах. Поєднуйте їх із пошуком за ключовими словами (BM25) і зливайте ранжування. Потім застосуйте cross-encoder переранжувальник до топ-30–100 кандидатів: переранжувальники читають запит і фрагмент разом і оцінюють релевантність значно точніше, ніж векторна подібність, але дорожче на кожну пару. Гібрид + переранжування — конфігурація, яку ми розгортаємо за замовчуванням; деталі реалізації — у статті RAG для бізнесу, а для PostgreSQL — у порівнянні векторних баз даних.

Особливості української мови

  • Змішані мови. Бізнес-дані в Україні часто змішують українську, англійську й російську, іноді в одному документі. Використовуйте багатомовні моделі й тестуйте міжмовні запити (запитання українською, відповідь в англійському документі).
  • Морфологія. Українська флексія шкодить наївному пошуку за ключовими словами: «договору», «договором», «договорі». Використовуйте нормальний аналізатор або більше покладайтеся на щільну складову; тестуйте BM25 зі стемінгом і без.
  • Апострофи й транслітерація. Нормалізуйте варіанти апострофа (', ’, ʼ) і враховуйте транслітеровані форми імен і брендів.
  • Скановані документи. Якість OCR для кирилиці різна; поганий OCR руйнує пошук. Див. обробка документів з LLM.

Операційні практики

  • Версіонуйте ембеддинги. Зберігайте назву й версію моделі з кожним вектором. Змішування векторів різних моделей в одному індексі мовчки ламає пошук.
  • Зберігайте сирий текст. Ви будете переембеддити при зміні моделі; плануйте це як фонову міграцію з періодом подвійного читання.
  • Інкрементальні оновлення. Переембеддьте лише змінені документи; зміни визначайте за хешем вмісту.
  • Поважайте контроль доступу під час пошуку. Фільтруйте за правами користувача в запиті, а не лише в промпті; див. безпека AI-агентів.
  • Моніторте пошук у продакшені. Логуйте ідентифікатори й оцінки знайдених фрагментів для кожної відповіді, щоб простежувати погані відповіді до пошуку; див. спостережуваність LLM.

Стартова конфігурація

Для типової української корпоративної бази знань:

  1. Чанкінг з урахуванням структури, 300–600 токенів, з назвою й шляхом розділу на початку.
  2. Багатомовна модель ембеддингів, обрана за recall@10 на 150 реальних запитаннях.
  3. Гібридний пошук: щільний + BM25, злиття через RRF, топ-50 кандидатів.
  4. Cross-encoder переранжування до топ-5–8 фрагментів.
  5. Contextual retrieval, якщо recall@10 досі нижчий за приблизно 85–90%.

Далі ітеруйте з набором для оцінки, змінюючи щоразу одну річ.

FAQ

Більша розмірність ембеддингів — кращі результати? Не обов'язково. Якість моделі важить більше за кількість вимірів; моделі Matryoshka часто зберігають більшу частину якості з удвічі меншою розмірністю.

Чи варто донавчати модель ембеддингів? Розгляньте це після того, як спробували гібридний пошук, переранжування й кращий чанкінг, і лише за наявності тисяч розмічених пар «запит–фрагмент». Див. fine-tuning, RAG чи промпти.

Чи можна просто взяти моделі з довгим контекстом і обійтися без пошуку? Для малих корпусів — іноді. Для більших чи тих, що часто змінюються, пошук лишається дешевшим, швидшим і керованішим; див. контекстна інженерія.

Як часто переембеддити? Коли змінюється вміст (інкрементально) і коли змінюєте модель (повністю). Інакше ембеддинги не «псуються».

Джерела

  1. Muennighoff et al. (2022). MTEB: Massive Text Embedding Benchmark; лідерборд MTEB.
  2. Reimers, N., Gurevych, I. (2019). Sentence-BERT.
  3. Chen et al. (2024). BGE M3-Embedding; Wang et al. (2024). Multilingual E5 Text Embeddings.
  4. Kusupati et al. (2022). Matryoshka Representation Learning.
  5. Anthropic (2024). Introducing Contextual Retrieval.
  6. Günther et al. (2024). Late Chunking; Khattab, O., Zaharia, M. (2020). ColBERT.