Серія питань з AI 11: Як налаштувати RAG?

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

一、Налаштування на стороні індексації даних (підвищення якості «бази знань»)

Це найчастіше ігноруване, але найефективніше місце.

Пункт налаштування	Проблемне явище	Конкретний підхід	Показник ефекту
Аналіз документів	Таблиці, блок-схеми в PDF ігноруються, або текст має неправильне кодування, або порядок порушено.	Заміна на кращу бібліотеку аналізу (наприклад, `unstructured`, режим збереження макета `pypdf`); для таблиць використовуйте `pandas` для вилучення та перетворення в Markdown.	Коефіцієнт відклику +5~15%
Розмір фрагмента тексту	Занадто малий chunk втрачає контекст (наприклад, «його зростання доходу цього року» — втрата вказівки «його»); занадто великий chunk призводить до багато шуму в пошуку.	Експериментуйте з різними розмірами chunk (256/512/768 токенів), перекриття overlap 10~20%; для довгих документів розрізайте за семантичними межами (абзаци/заголовки), а не за фіксованою довжиною.	Коефіцієнт влучень / вірність
Додавання метаданих	Знайдено відповідний фрагмент, але неможливо відстежити джерело або час, або потрібна фільтрація за областю.	Додайте метадані до кожного chunk: `source` (ім'я файлу/URL), `timestamp`, `page_num`, `doc_type`. Використовуйте фільтри під час пошуку (наприклад, `doc_type == 'legal'`).	Точність фільтрації
Вибір моделі вбудовування	Універсальні embedding погано працюють у вузьких сферах (медицина, код, право).	Використовуйте модель, донавчену на предметній області (BGE‑large‑zh, GTE‑Qwen2‑7B‑instruct); або донавчіть власну модель embedding (з triplet loss).	MRR@10 пошуку +10~20%

二、Налаштування на стороні пошуку (зробити «перегляд книги» точнішим)

Пошук визначає якість «довідкового матеріалу», який подається LLM.

Пункт налаштування	Проблемне явище	Конкретний підхід	Ефект
Гібридний пошук	Векторний пошук не може відповідати точним термінам (наприклад, модель продукту `ABC-123`), ключовий пошук не розуміє синоніми.	Одночасно використовуйте векторний пошук (семантика) та BM25 (ключові слова), об'єднуйте через зважування (наприклад, 0.7вектор + 0.3BM25) або rerank.	Коефіцієнт відклику +10~25%
Переранжування (Rerank)	Перші кілька результатів векторного пошуку не обов'язково найрелевантніші, десятий може бути кращим.	Використовуйте модель cross‑encoder (наприклад, `BGE‑reranker-v2`, Cohere Rerank) для повторного оцінювання кандидатів (наприклад, перших 20) і візьміть top‑K.	Значне підвищення коефіцієнта влучень (особливо top‑1)
Переписування запиту	Користувацьке питання нечітке або з багатообігового діалогу з нечіткими посиланнями («Яка його ціна?»).	Використовуйте LLM для перетворення оригінального питання у форму, більш придатну для пошуку (наприклад, «Скільки коштує iPhone 15?»); або доповніть історією діалогу.	Коефіцієнт відклику +5~15%
HyDE	Користувацьке питання надто коротке або абстрактне (наприклад, «Розкажи про фотосинтез»), прямий пошук поганий.	Спочатку заставте LLM згенерувати гіпотетичну відповідь, а потім використовуйте цю відповідь для пошуку документів.	Підходить для відкритої області, але не для точних фактичних запитань
Налаштування кількості пошуку Top‑K	Занадто мале K може пропустити ключову інформацію; занадто велике K збільшує витрати токенів та шум.	Експериментуйте з K=3/5/10, спостерігайте за балансом коефіцієнта відклику та точності відповіді.	Компроміс між ефективністю та результатом

三、Налаштування на стороні генерації (щоб LLM добре використовував довідковий матеріал)

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

Пункт налаштування	Проблемне явище	Конкретний підхід	Ефект
Інженерія промптів	LLM ігнорує знайдену інформацію або вигадує.	Чітка інструкція: «Відповідайте виключно на основі наданих довідкових матеріалів. Якщо матеріалу недостатньо або він нерелевантний, відповідайте «Недостатньо інформації».» Додайте few‑shot examples, що показують, як цитувати джерела.	Вірність +20~40%
Стиснення контексту	Знайдений вміст занадто довгий (перевищує контекстне вікно моделі) або містить багато шуму.	Використовуйте `LLMLingua` або `селективне стиснення контексту`, зберігаючи найрелевантніші речення перед подачею LLM.	Зниження ризику втрати інформації
Оновлення моделі LLM	Маленька модель (7B) не здатна до складного міркування або не пам'ятає довгий контекст.	Замініть на потужнішу модель (GPT‑4o, Claude 3.5 Sonnet, Qwen2.5‑72B).	Значне підвищення точності міркувань
Потоковий вивід та цитування	Користувач не може перевірити достовірність відповіді.	При генерації змусьте LLM виводити `[citation:1]`, що відповідає номеру знайденого документа. На стороні бекенду додайте посилання на оригінал.	Довіра користувача + можливість налагодження
Калібрування відмови від відповіді	Модель вигадує, коли не слід відповідати, або каже «не знаю», коли варто відповісти.	Встановіть поріг схожості: якщо косинусна схожість між top‑1 chunk та питанням нижче 0.7, підкажіть LLM «матеріал нерелевантний».	Зниження рівня галюцинацій

四、Оцінка та ітерація (знати, куди налаштовувати)

Без вимірювання неможлива оптимізація.

Пункт налаштування	Підхід	Показник
Створення оціночного набору	Підготуйте 100~300 реальних користувацьких питань + правильні відповіді + правильні ID знайдених документів.	Охоплює різні складності та інтенції.
Автоматична оцінка	Використовуйте RAGAS (Faithfulness, Answer Relevance, Context Recall) або TruLens.	Три основні показники: вірність, релевантність відповіді, відклик контексту.
Ручна оцінка	Щотижня випадково перевіряйте 20 bad case, аналізуйте типи помилок (помилка пошуку / помилка генерації / відсутність у базі знань).	Пріоритезація покращень.
A/B тестування	У виробничому середовищі тестуйте різні стратегії пошуку на різних групах (наприклад, BM25 vs гібридний пошук).	Онлайн-показники: задоволеність користувачів, відсоток відповідей «немає відповіді».

五、Практичний досвід, який можна згадати на співбесіді (бонусні бали)

«У моєму проекті RAG початковий коефіцієнт влучень був лише 67%. Я зробив три речі:
1. Змінив фіксований розмір фрагмента (1024) на динамічне семантичне розрізання (за заголовками + абзацами), коефіцієнт влучень підвищився до 74%;
2. Додав гібридний пошук (векторний + BM25) і невелику модель rerank, коефіцієнт влучень піднявся до 83%;
3. Оптимізував промпт і обов'язково вимагав «[Відповідну інформацію не знайдено]», рівень галюцинацій знизився з 22% до менш ніж 5%.

Крім того, ми створили конвеєр безперервної оцінки: перед кожною зміною запускали оцінку RAGAS для 200 питань, щоб переконатися у відсутності деградації.»

Остаточний підсумок: повна дорожня карта налаштування RAG

Шар даних ─→ очищення документів, оптимізація фрагментації, покращення метаданих, доменне embedding
Шар пошуку ─→ гібридний пошук, rerank, переписування запиту, HyDE, налаштування Top-K
Шар генерації ─→ покращення промпту, вимоги до інструкцій, стиснення, цитування, поріг відмови
Шар оцінки ─→ набір оцінювання, RAGAS, ручний аналіз, A/B експерименти