Шість метрик оцінки RAG, які мають значення у продакшені

Ранні навчальні матеріали з RAG створюють враження простого підходу: розділяти документи, вбудовувати їх, зберігати вектори, обирати невелике значення top_k, запускати модель. У демо-версії такий підхід може здаватися ефективним. Але у реальних умовах все складніше.

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

Під час налаштування механізму пошуку для асистента корпоративного типу ця проблема проявилась яскраво. Відсутність необхідних доказів змусила команду підвищити глибину пошуку. Результати офлайн-пошуку покращилися, а рівень відтворення інформації також зріс. Паперові показники свідчили про „кращу“ продуктивність, але якість генерованих відповідей погіршилася.

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

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

Виправлення проблем у режимі реального часу в системах RAG швидко виділяє кілька аспектів, які в демо-версіях об’єднуються в один показник: наскільки ефективно відбувається пошук інформації, наскільки добре вона сортується, наскільки якою є відповідь, чи ґрунтуються твердження у фактах, скільки часу очікують користувачі та скільки коштує кожен запит. Наступне питання, яке постійно ставлять — як вибрати розмір фрагментів та параметри top-k? — більше не потребує готових чисел.

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

Шість показників є особливо корисними: Recall@K, nDCG, MRR, Faithfulness, Latency та Cost. Кожен з них виявляє різний вид проблеми. Разом вони пояснюють, як прототип перетворюється на систему, якою можна керувати.

Почніть з пошуку інформації

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

1. Recall@K — охоплення необхідних доказів

Recall@K визначає, яка частка справді релевантних елементів знаходиться серед перших K результатів пошуку.

Візьмемо бота ITSM, який стикається з таким запитом: «Служба оплати не працює після переходу на резервну базу даних — які кроки відновлення мені слід виконати?» Припустимо, потрібно п’ять фактів. Серед перших п’яти результатів пошуку є лише чотири з них. Recall@5 становить 0.80.

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

Це також пояснює, чому фіксоване значення top_k = 5 не є абсолютним стандартом. Якщо змінити значення K з 5 на 10, рівень Recall підніметься з 0.80 до 0.94, що свідчить про те, що індекс містить потрібний матеріал, але вибір є занадто поверхневим. Підвищення значення K також може призвести до перевантаження запиту шумом — саме тому далі розглядаються метрики класифікації.

2. nDCG — чи є найкращі результати ближче до верху?

Лише рівень охоплення недостатній. Важлива також позиція.

Дві системи можуть використовувати однаковий набір інструкцій. Одна розміщує їх на першому місці, потім іншу корисну процедуру, а далі менш важливі елементи. Інша ж ховає цей набір інструкцій на восьмому місці серед слабко пов’язаних сторінок. Рівень Recall схожий, але якість результатів значно відрізняється.

Оцінки nDCG (нормалізований дисконтований кумулятивний приріст) визначають релевантність та надають більше значення розміщенню найкращих елементів на початку. Класична робота Järvelin та Kekäläinen з дисконтованим приростом існує саме з цієї причини.

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

Точність перевіряє ефективність пошуку. nDCG перевіряє розумне ранжування.

3. MRR — як швидко з’являється перший корисний результат?

Середнє обернене ранжування зосереджує увагу на першому релевантному результаті:

[
RR = \frac{1}{\text{rank of first relevant result}}
]

Ранг 1 → RR 1,0. Ранг 5 → RR 0,2. У середньому за набір запитів MRR є чітким сигналом тоді, коли перший хороший результат домінує в результатах пошуку.

Інтерактивні асистенти часто зупиняються після першого значущого уривку. Ретривер, який ховає правильний посібник на дев’ятому місці, може виглядати ефективним у тесті Recall@20, але при цьому мати проблеми в інтерфейсі користувача.

Коли «більше контексту» призводить до проблем

Навіть після покращення показників ретривації якість відповідей все одно погіршилась. Модель потрапляла у велику кількість зайвого та суперечливого тексту. Показники ранжування пояснюють цю проблему: більше значення K без кращого порядку вносить шум у запит. Це призводить до перевірок на наявність фактичних даних.

4. Вірність — твердження, пов’язані з отриманим текстом

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

Треба розділяти поняття вірності та правильності.

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

• Вірність: чи підтверджується тим, що було знайдено?
• Правильність: чи відповідає запланованій політиці?

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

5. Затримка — на що можуть почекати якісні користувачі

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

Порівняймо два варіанти. А досягає 91% точності відповідей при затримці пошуку 120 мс. Б — 93% при затримці 650 мс. Б кращий лише за точністю. Обмеження продукту визначають, чи є Б насправді кращим. Інтерактивні асистенти з обмеженими бюджетами на відповіді можуть відхилити таку затримку, а пошук — це лише частина загального часу.

Запит у реальному часі може включати переписування, отримання даних, переурочення пріоритетів, створення контексту та генерацію результату. Вимірюйте кожну стадію та весь шлях виконання запиту. Віддавайте перевагу дистрибуціям значень перед середніми значеннями. Середнє значення 400 мс з P95 у 1,8 с зовсім не схоже на показники системи, у якій значення P50/P95/P99 залишаються низькими.

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

6. Витрати — що відбувається при мільйонах запитів

Економічні аспекти проявляються вже тоді, коли прототип стає готовим продуктом.

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

Якщо кожен блок містить в середньому 600 токенів, тоді:

Final K = 5

буде введено близько 3 000 отриманих токенів. Перейти до:

Final K = 15

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

Що насправді означає «налаштування розміру блоку та top-k»

У запитанні для інтерв’ю не просять двох „чарівних“ чисел. Там проситься експериментальний підхід.

Складіть приблизно 200 репрезентативних запитів, які охоплюють усунення несправностей, процедури, інциденти/RCA, правила, неоднозначності, багатоетапні операції та крайні випадки. Нехай експерти у галузі оцінять їхню релевантність.

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

Chunk sizes:
256
512
1024
2048

а також перекриття сіток / кандидатів-K наступним чином:

Overlap:
64
128
256Candidate K:
5
10
20

Сітка 4 × 3 × 3 дає приблизно 36 конфігурацій. Оцінюйте кожну за допомогою більш ніж одного показника:

Recall@K
nDCG@K
MRR
Answer correctness
Faithfulness
Latency
Cost

Потім обирайте оптимальний баланс між якістю, затримкою та витратами — а не максимальний рівень відтворення даних чи показник F1 за замовчуванням.

Несподівані результати експерименту

Припустімо, три конфігурації дають такі результати:

• A: Recall@10 0.94, nDCG@10 0.81, точність 0.89, вірність 0.95, P95 510 мс, $0.025
• B: Recall@10 0.91, nDCG@10 0.88, точність 0.94, вірність 0.96, P95 560 мс, $0.027
• C: Recall@10 0.97, nDCG@10 0.79, точність 0.86, вірність 0.76, P95 820 мс, $0.034

Лише показник Recall робить C найкращим. C дає найслабші результати — очевидно, додаткове отримання інформації шкодить процесу генерації. U має нижчий показник Recall, але випереджає за nDCG, точністю та вірністю, маючи лише незначне погіршення у затримці та витратах. Саме ця конфігурація варта детального аналізу, і саме тому правило „найвищий бал отримання інформації — це перемога“ є поганим універсальним принципом. Оптимізуйте під справжню мету продукту.

Невдача → наступне дослідження

• Низький показник Recall@K → часткове оброблення даних, використання ембеддингів, фільтри метаданих, формування запитів, стратегія отримання інформації

Сильне запам’ятовування, слабкий nDCG → ранжування/переранжування

Сильне пошукове функціонування, слабка точність відповідей → формування контексту, сортування, стимули, генерація

Правдоподібні, але не підтверджені відповіді → вірність/обґрунтування

Хороша якість, погана затримка → аналіз кожної стадії

Хороша якість, високі витрати → кількість кандидатів K, кінцеве значення K, розмір частин, стиснення, кешування, вибір моделі, ефективність токенів

Цей перелік перетворює виправлення помилок на процедуру.

Зберігайте цикл у робочому режимі в продакшені

Одноразовий тест-бенчмарк — це не кінцева мета. Вам потрібна постійна оцінка. Реальний трафік відрізняється від підготовлених наборів: змінюється формулювання, документи оновлюються, політики змінюються, з’являються нові сервіси, трапляються крайні випадки. Розширюйте набір для оцінки на основі проблем у продакшені.

Зріла система оцінювання

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

Запитайте перед налаштуванням

Коли хтось вимагає розміру частин та значення top-k, спочатку поставте запитання: що ми оптимізуємо, як виглядає набір даних із мітками та яка вартість невдалого пошуку? З цими відповідями налаштування перетворюються на експериментальні результати.

Одним із можливих результатів може бути:

512 tokens
128 overlap
Candidate K = 20
Final K = 5

Іншим —:

1024 tokens
64 overlap
Candidate K = 10
Final K = 4

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

Не варто довіряти універсальним показникам без вимірювань. Система RAG є „хорошою“ не тому, що вона знаходить більше інформації, швидше її отримує чи звучить переконливо. Вона є хорошою, коли знаходить правильні докази, ефективно їх ранжує, надає моделі належну кількість контексту, генерує відповіді, які є одночасно правильними та обґрунтованими, і залишається в межах встановлених показників затримки та витрат продукту.

Саме ця різниця — між налаштуванням простої технологічної схеми та створенням функціональної системи — є суттю проблеми.

Припиніть здогадуватися щодо параметрів

Не існує міфічної довжини фрагментів, універсального показника top-k чи єдиного метрику, який може підтвердити готовність до впровадження. Навіть кращий показник Recall@K може погіршити якість відповідей. Ефективне пошукове функціонування все ще може дозволяти робити не підтверджені твердження. Висока точність також може бути недостатньою, якщо затримка чи витрати значно зростають при масштабуванні.

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

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

Тоді значення chunk_size=512 або top_k=5 є доказом, а не фольклором.

Розміщення шести показників на одній сторінці

Придатна таблиця оцінок для щотижневого аналізу RAG може виглядати так:

• Recall@K та MRR для оцінки „Чи знайшли ми докази та як швидко?“
• nDCG для оцінки „Чи поставили ми найкращі докази на перше місце?“
• Вірність та правильність відповідей для оцінки „Чи залишалася генерація чесною та точною?“
• Затримка P50/P95 для оцінки „Чи можуть користувачі чекати?“
• Витрати на одну успішну відповідь для оцінки „Чи може фінансування чекати?“

Розгляньте їх разом. Підвищення показника Recall@K при одночасному зниженні рівня точності — це не успіх. Зменшення затримки, яке призводить до падіння значення nDCG, також не є успіхом. Мета використання шести показників полягає у тому, щоб зробити ці компроміси видимими, а не приховувати їх за однією цифрою F1.

Аксіоматична істина — це дефіцитний ресурс

Якість показників залежить виключно від якості міток, які їх супроводжують. Якщо експерти в галузі ніколи не оцінюватимуть, які уривки є релевантними, то Recall@K залишатиметься формальністю. Якщо ніхто не позначатиме рівень релевантності, nDCG перетворюватиметься на шумливий бінарний показник. Якщо оцінювачі точності діятимуть непослідовно, результати оцінювання будуть змінюватися.

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

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

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

Коли хтось запитує про стандартний розмір частин та значення top-k, перетворіть цей запит на план експерименту. Вкажіть мету, набір даних із мітками, ліміт затримок та верхню межу витрат. Потім нехай сітка експериментів підбере відповідні числа. Усе інше — це припущення, прикидані під інженерну роботу.

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