Покращення відповідей RAG: по одній виміряній зміні за раз

Перший підхід RAG легко створити: завантажте документи, вбудуйте їх, збережіть вектори, отримайте кілька фрагментів та передайте їх моделі LLM. Він працює, проте відповіді часто є неправильними, навіть коли в документі чітко міститься правильна інформація. У більшості таких випадків причиною не є сама модель; крок пошуку так і не надав їй правильного контексту. У цьому посібнику розглядаються основні фактори, які впливають на процес пошуку, а також методи для визначення того, які з них дійсно допомагають вашій системі.

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

Перш ніж змінювати запити чи моделі, перевірте, що було знайдено для неправильної відповіді. Якщо відповідний уривок відсутній у контексті, жодна налаштування запиту не допоможе виправити відповідь.

Діліть на фрагменти за значущими межами

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

Налаштуйте параметр top_k замість того, щоб вгадувати його

Багато систем обробки потоків даних отримують п’ять найбільш схожих фрагментів просто тому, що п’ять — це поширений стандартний значення. Однак правильний уривок може знаходитися на шостій чи сьомій позиції. Підвищення значення top_k може покращити рівень відтворення інформації, але кожен додатковий фрагмент також додає шум та токени до запиту. Розглядайте top_k як параметр, який потрібно тестувати з урахуванням ваших власних запитань, а не як константу, яку слід копіювати. Ще одним варіантом є пороги релевантності, про які йдеться у статті «Виходячи за межі top-k: пороги релевантності, гібридний пошук та переранжування».

Додайте етап переранжування

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

Поєднання семантичного та ключового пошуку

Ембеддинги добре передають сенс, але іноді точні токени мають більше значення, ніж сенс. Запит на кшталт ERROR_CODE_4291 має мінімум семантичного змісту, тому пошук за схожістю може пропустити документ, у якому він згадується. Методи ранжування за ключовими словами, такі як BM25, добре справляються з такими випадками. Тому багато систем використовують одночасно векторний та ключовий пошук та об’єднують їхні результати — цей підхід називається гібридним пошуком.

Зменшіть прогалину у словниковому запасі запитів

Користувачі рідко формулюють запитання так, як написані документи. Хтось може запитати, чому не відбувається оплата, тоді як відповідна сторінка йдеться про невдачу авторизації картки. Переписування запитів, MultiQuery (створення кількох варіантів формулювань та пошук для кожного з них) та HyDE (створення гіпотетичної відповіді та пошук за її ембеддингом) можуть допомогти подолати цю прогалину. Однак вони збільшують кількість викликів LLM та складність, тому вдавайтеся до них лише після використання простіших методів.

Вимірюйте кожну зміну за базовими показниками

Найважливішою звичкою є відмова від припущень. Фраза «Ми додали переранжування, тож пошук став кращим» є гіпотезою, доки її не буде перевірено. Створіть невеликий набір реальних запитань із відомими відповідними уривками, а потім відстежуйте такі показники:

• Recall@K: чи з’являється правильна інформація серед перших K знайдених уривків.

Точність контексту: наскільки зібраний контекст був справді корисним.

Вірність: чи ґрунтується відповідь у зібраному контексті.

Релевантність відповіді: чи відповідає відповідь поставленому запитанню.

Спочатку зафіксуйте базові показники. У ілюстративному прикладі це може виглядати так:

Baseline Recall@5: 68%

Потім вносьте одну зміну за раз, знову запускайте ті самі запитання та фіксуйте кожен результат. Послідовність покращень може виглядати так:

Better chunking: 74%
Hybrid search: 82%
Reranking: 89%

Ці цифри є прикладом, а не критерієм оцінки; ваші власні дані будуть поводитися інакше. Суть у тому, що журнал змін дозволяє зрозуміти, який крок призвів до складності, а який — ні. Для більш детального розгляду способів виявлення проблем дивіться оцінку RAG за стадіями збоїв.

Підсумок

Почніть з найпростішої схеми: від запиту до отримання даних, потім до контексту та нарешті до LLM, поступово вдосконалюючи кожен етап: зробіть зміну, виміряйте її ефективність, оцініть час виконання та витрати, і повторіть процес. Проста система RAG, яку ви розумієте та можете вимірювати, зазвичай цінніша за складну систему, наповнену техніками, які ніхто не може обґрунтувати цифрами.