Як створити надійний RAG: Глибокий аналіз 7 точок відмов та кадрів оцінки

Покращення генерації за допомогою пошукових даних (RAG) є критично важливим для сучасної архітектури штучного інтелекту, служачи основною основою для створення контекстно-чутливих агентів.

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

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

Анатомія розриву RAG – 7 точок відмов (TF)

За даними дослідників Barnett et al., системи генерації за допомогою пошукових даних (RAG) зустрічають сім конкретних точок відмов (TF) на всіх етапах роботи.

Нижче наведена діаграма ілюструє ці стадії:

Фігура А. Процеси індексування та запитів, необхідні для створення системи RAG. Процес індексування відбувається під час розробки, а запити – під час виконання. Точки відмов, визначені в цьому дослідженні, показані червоними квадратами (джерело)

Давайте розглянемо кожну точку відмов, розташовані згідно з послідовністю етапів, слідуючи за прогресом з верхнього лівого до нижнього правого, показаного в Фігурі А.

TF1. Відсутній контент

Відсутній контент відбувається, коли система запитана на питання, на яке не можна відповісти, оскільки відповідна інформація відсутня в доступному векторному сховищі спочатку.

Відмова відбувається, коли великомасштабна мова (LLM) надає правдоподібну, але неправильну відповідь, замість того, щоб сказати, що вона не знає.

TF2. Пропущені найкращі документи

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

В результаті правильна інформація ніколи не досягає LLM.

TF3. Не в контексті (обмеження стратегії консолідації)

Це ситуація, коли правильний документ існує і витягнутий з векторного сховища, але виключений під час процесу консолідації.

Це відбувається, коли повернуто занадто багато документів і система повинна їх відфільтрувати, щоб вмістити контекстну вікно LLM, обмеження токенів або обмеження швидкості.

TF4. Не витягнутий

Це ситуація, коли LLM не може ідентифікувати правильну інформацію в контексті, хоча правильна інформація була у векторному сховищі і успішно витягнута/консолідована.

Це відбувається, коли контекст надто шумовий або містить суперечливу інформацію, яка плутає LLM.

TF5. Неправильний формат

Це ситуація, коли зберігання, пошук, консолідація та інтерпретація LLM обробляються успішно, але LLM не слідує конкретним інструкціям щодо формату, наданим у запиті, таких як таблиця, маркований список або схема JSON.

TF6. Неправильна специфікація

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

Наприклад, LLM генерує прості відповіді на запит користувача з складною професійною метою.

TF7. Неповні відповіді

Це ситуація, коли LLM генерує вихід, який не обов’язково неправильний, але не містить ключових частин інформації, які були доступні в контексті.

Наприклад, коли користувач запитує складне питання, таке як “Які ключові моменти в документах А, Б і В?”, LLM розглядає лише один або два джерела.

Як TF компрометують продуктивність конвеєра RAG

Кожна з цих TF впливає на продуктивність конвеєрів RAG:

Порушення цілісності даних та довіри

Коли відсутня або неправильна інформація присутня, система більше не є надійним джерелом інформації. Основні TF включають:

• TF1 (Відсутній контент): Відповідь не міститься в документі спочатку.
• TF4 (Не витягнутий): LLM вирішує проігнорувати правильну відповідь у документі.
• TF7 (Неповний): LLM надає півправду, пропускаючи важливі частини.

Пошукові та ефективні вузли

Конвеєр RAG може бути неефективним, коли він пропускає ключову інформацію на етапах пошуку та консолідації. Основні TF включають:

• TF2 (Пропущені найкращі документи): Модель вкладення не може вибрати найкращі вкладення.
• TF3 (Обмеження стратегії консолідації): Сценарій для обрізання документів, щоб вони поміщались у вікно контексту LLM, викидає найважливіші частини.

Помилки користувачського досвіду та форматування

Хоча правильний, вихід з поганою читабельністю або у неправильному форматі може компрометувати досвід користувача. Основні TF включають:

• TF5 (Неправильний формат): LLM не слідує конкретному формату виводу, такому як JSON.
• TF6 (Неправильна специфікація): LLM генерує розгорнуту відповідь на просте питання або навпаки (занадто коротку відповідь на складне питання).

Стек оцінки: кадри для мінімізації TF

Метрики оцінки призначені для систематичного мінімізування цих TF.

Ця секція досліджує основні метрики оцінки з практичними прикладами.

Основні метрики оцінки RAG:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – Юніт-тест перед розгортанням

DeepEval обчислює зважений бал за критеріями.

LLM-оценщик (наприклад, GPT-4o) оцінює кожен критерій проти виводу LLM:

DeepEval використовує G-eval, кадр ланцюга думок (CoT), який приймає багатоступінчатий підхід до оцінки виводу:

1. Визначте критерій для вимірювання (наприклад, “співвідношення”, “плинність” або “п Pertinence”).
2. Генеруйте оціночні кроки (за допомогою оцінювальної LLM).
3. Слідуйте оціночному кроку та аналізуйте вхідні дані та вихід LLM.
4. Обчислюйте очікуваний зважений суму балів кожного критерію.

Типова ситуація на практиці

• Ситуація: Технічний помічник документації (бот) для складного програмного продукту здається працюючим кожного разу, коли команда інженерів оновлює кодову базу.
• Проблема: Ні кількісних доказів того, що бот все ще може відповісти на запит користувача (Ви просто “думаєте”, що це працює…).
• Рішення: Інтегруйте функцію PyTest як регресійний набір CI/CD у Github Action, де DeepEval запускає G-Eval та інші метрики над тестовим випадком:

• Очікувані результати: Якщо будь-який бал метрик впадає нижче порогу (0,85), PyTest підвищує AssertionError – негайно припиняючи збірку CI, запобігаючи тихому регресу від досягнення виробництва.

Примітка розробника – Тестовий випадок для DeepEval
Набір об’єктів LLMTestCase визначає тестовий випадок, який запускає DeepEval.

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

Ці дані можна отримати з файлу JSON або CSV.

RAGAS – Оптимізатор у стозі сіна

Оцінка генерації за допомогою пошукових даних (Ragas) спрямована на оцінку RAG без анотованих наборів даних шляхом генерації синтетичних тестових наборів.

Потім вона обчислює флагманські метрики:

Фігура Б. Діаграма оцінки RAGAS, що з’єднує питання, контекст та відповідь через метрики точності, відкликання, вірності та релевантності (Створено Куріко ІВАЙ)

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

• Пошуковий конвеєр (чорна сплощена лінія, Фігура Б): Точність контексту, відкликання контексту.
• Конвеєр генерації (чорна пунктирна лінія, Фігура Б): Вірність, релевантність відповіді.
• Вірність (червона коробка, Фігура Б): Семантична схожість відповіді, правильність відповіді.

Типова ситуація на практиці

• Ситуація: Система RAG для юридичних контрактів не містить ключових пунктів. Ви не впевнені, чи проблема знаходиться в Пошуку (Пошуковому механізмі) або в Читанні (Генераторі).
• Проблема: Ні ідеї про оптимальне топ-k (кількість витягнутих шматків).
• Рішення: Використайте RAGAS, щоб створити синтетичний тестовий набір із 100 пар запитів та доказів. Потім запустіть конвеєр RAG проти тестового набору, щоб обчислити відкликання контексту та точність контексту:
• Очікуваний результат: В залежності від результатів метрик, план дій може бути наступним:

Таблиця 1. План дій діагностики RAGAS – відображення балів на коригування системи.

TruLens – Спеціаліст зворотного зв’язку

TruLens зосереджується на внутрішніх механіках процесу RAG, а не лише на кінцевому виводі, використовуючи функції зворотного зв’язку.

Він також використовує оцінку LLM, яка відображає, наскільки добре відповідь задовольняє намір запиту, використовуючи 4-бальну шкалу Лікерта (0-3), роблячи його надійним для оцінки якості різних результатів пошуку.

Типова ситуація на практиці

• Сітуація: Бот-медичний радник відповідає на запит користувача правильно, але додає корисну пораду, якої немає в перевіреній базі PDF.
• Проблема: Додана порада може бути корисною, але не підкріплена фактами.
• Рішення: Використайте TruLens, щоб реалізувати функцію зворотного зв’язку для підкріплення з порогом, наприклад бал > 0,8.

• Очікувані результати: Коли LLM генерує відповідь, яка містить інформацію, відсутню у витягнутих шматках, TruLens позначає запис у вашій панелі.

Arize Phoenix – Тиха карта відмов

Arize Phoenix – це відкритий інструмент спостереження та оцінки для оцінки виводів LLM, включаючи складні системи RAG.

Розроблений на основі OpenTelemetry компанією Arize AI, він зосереджується на спостереженні,扱уючи оцінку LLM як підмножину MLOps.

У контексті оцінки RAG Phoenix excels у аналізі вкладень, використовуючи Уніфіковану апроксимацію многовиду та проєкцію (UMAP), щоб зменшити високовимірні вкладення до 2D/3D-простору.

Цей аналіз вкладень математично розкриває, чи скупчені невдалі запити семантично, що вказує на пробіл у векторному сховищі.

Типова ситуація на практиці

• Сітуація: Бот підтримки клієнтів працює добре для повернення коштів, але видає безглузді відповіді на питання про гарантії.
• Проблема: Пробіл даних у векторному сховищі (Не можна знайти в журналах).
• Рішення: Використайте Arize Phoenix, щоб створити візуалізацію вкладень UMAP (UEV), 3D-карту для векторного сховища – щоб накласти запити користувачів на шматки документів.
• Очікувані результати: Візуально побачити кластер запитів користувачів, який потрапляє у темну зону, де немає документів, вказуючи на те, що деякі документи забули завантажити у векторне сховище.

Braintrust – Безпековий мережевий проміжник для регресії запиту

Braintrust призначений для високочастотних ітераційних циклів шляхом використання перекрестного порівняння моделей.

Типова ситуація на практиці

• Сітуація: Команда інженерів оновлює запит від “Відповісти на питання” (Випадок А) до більш складного 500-словного системного інструктажу (Випадок Б).
• Проблема: Покращення запиту для Випадку Б може випадково зламати Випадок А.
• Рішення: Використайте Braintrust, щоб створити золотий набір із набором N ідеальних прикладів (наприклад, N = 50). Дайте Braintrust запустити порівняння бок о бок (SxS) кожен раз, коли команда оновлює окреме слово у запиті:

• Очікуваний результат: Звіт про розбіжності, що показує, які випадки покращились/погіршились для кожного з золотого набору (N = 50).

Підсумок

Коли обробляються з правильними кадрами оцінки, RAG може бути конкурентоспроможним інструментом для надання LLM контексту, найбільш релевантного для запиту користувача.

Стратегія реалізації: відображення метрик на точки відмов

Хоча немає універсального рішення, Таблиця 2 показує, які метрики оцінки застосовувати для кожної TF, розглянутої в цій статті:

Таблиця 2. Матриця мінімізації точок відмов – Який інструмент вирішує яку TF?

DeepEval і RAGAS можуть використовувати свої метрики вірності для вимірювання порушень цілісності даних (TF1, TF4, TF7).

TruLens використовує свою точність контексту/відкликання, щоб вимірювати релевантність контексту до виводу – ефективно оцінюючи TF2.

Arize Phoenix надає візуальний слід процесу пошуку, роблячи легко побачити, чи був документ, витягнутий під час консолідації (TF3).

Для помилок користувачського досвіду DeepEval створює спеціальні метрики для оцінки помилок користувачського досвіду, тоді як Braintrust excels у порівнянні вірних наборів даних.