Оцінка RAG: Тестування витягування перед налаштуванням LLM

Оцінка RAG повинна починатися з витягування. Якщо правильні докази ніколи не досягають моделі, налаштування запитів та оновлення моделі лише роблять неправильний контекст більш переконливим. Тестуйте витягування, генерацію та операції як окремі етапи. Зберігайте невелику, версіоновану регресійну вибірку, яка зазнає невдачі, коли будь-який етап погіршується.

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

У цьому посібнику

Оцінка RAG має три окремі поверхні невдач

Застосування RAG є конвеєром. Один бал за фінальну відповідь приховує, який компонент потребує роботи.

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

Поточна документація оцінювачів RAG від Microsoft робить таке ж розділення в термінах реалізації. Вона надає заходи витягування документів для ранжованих доказів, а потім оцінює закріпленість, релевантність та повноту відповіді на рівні відповіді. Оцінювач витягування документів включає вірність, NDCG, XDCG, максимальну релевантність та судження про відсутню релевантність.

_Корисна оцінка RAG зберігає витягування, генерацію та операційні перевірки видимими як окремі шари._

Чому один загальний бал дає слабкі докази налагодження

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

RAGChecker оцінює поведінку витягувальника та генератора окремо. Його автори порівняли вісім систем RAG у десяти доменах. Їхні метрики включають recall заяви та precision контексту для витягування, плюс використання контексту, чутливість до шуму, галюцинацію та вірність для генерації. У мета-оцінці з 280 пар загальний бал RAGChecker мав кореляцію Спірмена 0.609 з людськими вподобаннями. Два людських анотатори досягли 0.689. Автоматизована оцінка була корисною, але не усунула людський розрив.

Ragas запропонував безсистемні заходи для вірності, релевантності відповіді та релевантності контексту. У своїх порівняннях WikiEval угода з людськими вподобаннями становила 0.95 для вірності, 0.78 для релевантності відповіді та 0.70 для релевантності контексту. Автори виявили, що оцінка релевантності контексту є найскладнішою для судження. Ставтеся до цих цифр як до результатів цього дослідження, а не до універсальних показників точності для кожного судді, набору даних або домену.

Нова рамка, RAGe, додає вибір компонентів та телеметрію апаратного забезпечення. Вона оцінює конфігурації конвеєра через розбивку, вбудовування, витягування, зберігання та генерацію, одночасно відсікаючи комбінації, які перевищують обмеження затримки або VRAM. У статті за замовчуванням використовуються Natural Questions, NewsQA та TriviaQA та підтримуються користувацькі набори даних CSV або JSON. Її основний внесок полягає в способі порівняння якості з обмеженнями ресурсів; вона не встановлює одну конфігурацію, яка виграє в усіх доменах.

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

Створіть тестовий набір перед вибором метрик

Почніть з 40 до 60 запитань з домену, який ви обслуговуєте. Цей діапазон є практичною відправною точкою, а не статистичним законом. Він достатньо великий, щоб виявити кілька типів невдач і достатньо малий, щоб людина могла переглянути після кожної суттєвої зміни.

Включіть принаймні п’ять класів запитів:

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

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

{ "query_id": "refund-window-01", "query": "Скільки часу має клієнт, щоб повернути невідкритий товар?", "relevant_document_ids": ["returns-policy-v4"], "required_claims": ["Невідкриті товари можуть бути повернуті протягом 30 днів."], "must_abstain": false, "allowed_roles": ["customer", "support"], "as_of": "2026-07-01" }

Для невідповідного випадку встановіть `relevant_document_ids` на порожній список і `must_abstain` на `true`. Для обмеженого випадку запустіть той же запит під двома ролями. Авторизований користувач повинен отримати документ; неавторизований користувач не повинен дізнатися зміст цього документа.

Команди, які створюють свій власний корпус і прикладний шар, повинні версіонувати контракт контенту разом з тестовим набором. Те саме правило стосується кастомних систем даних, створених за допомогою Next.js та AI: зміна схеми або контенту може змінити витягування, не торкаючись запиту.

Крок 1: оцініть витягування без генерації відповіді

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

Виберіть метрики, які відповідають формі доказів

Використовуйте частоту попадання@k, коли одного правильного документа достатньо. Це запитує, чи з'явилося принаймні одне релевантне джерело в перших `k` результатах.

Використовуйте recall@k, коли відповідь вимагає кількох джерел. Це вимірює, скільки відомих релевантних документів з'явилося в перших `k`.

Використовуйте precision@k, коли нерелевантний контекст є дорогим або відволікаючим. Високий recall з низькою precision може затопити генератор шумом.

Використовуйте MRR, коли перший релевантний результат має найбільше значення. Використовуйте NDCG, коли кілька оцінених результатів повинні з'явитися в корисному порядку. Microsoft документує NDCG та пов'язані заходи ранжованого витягування в своєму оцінювачі, тоді як RAGChecker використовує recall заяви та precision контексту, щоб зв'язати витягнуті докази з вимогами, які потрібні для відповіді.

Не збирайте кожну метрику за замовчуванням. Виберіть одну метрику покриття та одну метрику ранжування або шуму. Додайте метрику лише тоді, коли вона змінює рішення.

Класифікуйте пропуски перед зміною моделі

Невдачі витягування зазвичай потрапляють у невелику групу:

Кожна невдача має різного власника. Повторне вбудовування не може виправити відсутній документ. Більша мовна модель не може виправити фільтр дозволів. Ререйкер може допомогти, коли докази присутні, але погано впорядковані.

Для додатків, пов'язаних з інструментами, зберігайте запит на витягування, фільтри, ідентифікатори результатів та відповідь інструмента в трасі. Це відповідає більш широкому шаблону контролю, описаному в робочих процесах розробників MCP: перевірте контракт, перехід стану та фінальний текст.

Крок 2: оцініть генерацію на основі фіксованих доказів

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

Вимірюйте чотири поведінки:

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

Запустіть другий тест генерації з навмисно неповним контекстом. Надійна система повинна виявити невизначеність, а не заповнити прогалини з пам'яті моделі. Це важливо, коли корпус містить приватні, змінювані або специфічні для домену факти.

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

Додайте випадки безпеки та конфлікту до набору витягування

Звичайні тести на релевантність пропускають суперечливі або конфліктуючі докази.

Стаття за липень 2026 року про поліморфне отруєння sybil у RAG тестувала групи лексично різних фрагментів, які підтримували ту ж відповідь, обрану атакуючим. У примусовій установці статті поліморфні фрагменти виробили 22.8% рівень захоплення порівняно з 4.0% для повторюваних моноформних фрагментів. Фільтрація за перетином токенів виявила всі моноформні кластери та жоден з поліморфних кластерів.

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

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

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

Калібруйте суддів LLM перед тим, як довіряти їхнім балам

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

Використовуйте чотири контролі:

Дослідження Ragas та RAGChecker обидва показують, чому калібрування має значення. Угода варіюється за виміром, а автоматизовані кореляції залишаються нижчими за людську угоду. Числовий бал повинен викликати перевірку, а не закінчувати її.

Поточні випуски з відкритим кодом також показують активну роботу навколо оцінювачів. DeepEval 4.1.3, випущений 12 липня 2026 року, додав детерміністичні перевірки для циклів агентів та дозволів інструментів, виправивши інтеграцію Ragas. TruLens 2.9.0, випущений 23 липня, додав ансамблі суддів, тести критеріїв A/B, аналіз розподілу балів та генерацію золотих наборів. Активність випуску є доказом підтримуваної інженерної роботи, а не доказом того, що будь-яка з бібліотек є правильним вибором для вашого стеку.

Мінімальний регресійний робочий процес RAG

Використовуйте ту ж послідовність для кожної суттєвої зміни конвеєра:

Стиснутий запис результатів може виглядати так:

{ "run_id": "rag-2026-07-26-b", "test_set": "support-v7", "corpus_snapshot": "2026-07-25T22:00:00Z", "retrieval": { "recall_at_5": 0.91, "ndcg_at_5": 0.84, "unauthorized_hits": 0 }, "generation": { "grounded_pass_rate": 0.94, "complete_pass_rate": 0.87, "abstention_pass_rate": 0.90 }, "operations": { "p95_ms": 1380, "cost_per_query_usd": 0.0042 } }

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

Визначте виправлення з невдалого шару

Ця таблиця є точкою оцінки RAG: невдалий бал повинен визначити наступний експеримент. Якщо це не так, метрика занадто далеко від компонента, який потрібно змінити.

Що підтримують докази

Статті вимірювали конкретні системи та набори даних. RAGChecker виявив, що модульні метрики можуть корелювати з людськими вподобаннями та виявляти торги між витягувальником і генератором. Ragas виявив, що угода суддів варіюється за вірністю, релевантністю відповіді та релевантністю контексту. RAGe продемонстрував рамку, яка поєднує метрики якості з обмеженнями затримки та пам'яті. Бенчмарк отруєння показав, що одна обмежена установка атаки виробила чіткі шаблони захоплення, утримання та відхилення.

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

Перевірки вимог

Джерела