Прибуток:
- Визначення показників, які окремо вимірюють утримання та якість створення
- Налаштуйте золотий набір питань і запустіть автоматичне оцінювання за допомогою LLM-as-judge
- Підтримка якості за допомогою зворотного зв’язку, моніторингу та регресійного тестування на виробництві
Речення «Я встановив помічника, здається, він працює добре» не є інженерним твердженням. Системи RAG виходять з ладу безшумно: новий тип документа обманює пошук, швидка зміна знижує точність, індекс стає несвіжим. Єдиний спосіб зрозуміти це - виміряти. У цьому розділі ми розповідаємо, як вимірювати якість RAG (окремо отримання та генерування), автоматичне оцінювання (LLM-as-judge) і підтримувати якість у виробництві (моніторинг, регресія). «Те, що не вимірюєш, не можна покращити» — девіз цього підрозділу.
Вимірюйте дві різні речі
RAG має дві ноги, і їх потрібно вимірювати окремо, оскільки проблема може бути в будь-якій з них:
- Якість отримання: чи надійшла правильна частина?
- Якість генерації: чи була правильна відповідь отримана з вхідного фрагмента?
Якщо відповідь погана, потрібно спочатку знати, яка нога погана. Якщо правильна частина ніколи не надходить, навіть найкраща підказка не може зберегти (проблема отримання). Якщо надійшла правильна частина, але модель неправильно її прочитала, покращення пошуку марно (проблема генерації).
Метрики пошуку
Пошук – це проблема сортування/доступу; вимірюється класичними метриками пошуку інформації. Для цього потрібно мати золоте гроно: знати, яка частина є «правильною» для кожного питання.
метрика
Які заходи
Просте визначення
Recall@k
Чи правильна фігура у верхній k?
Правильна швидкість захоплення деталей
точність@k
Скільки з k повернених частин є релевантними?
Прибирання привезеного
MRR (середній взаємний ранг)
У якому порядку правильна частина?
Нагороди за перебування у вищих рангах
Коефіцієнт попадання
Прийшов хоча б один правильний шматок?
Основне мірило успіху
Практичний коментар: якщо Recall@k низький, стратегію фрагментації або пошуку (гібрид, k, переранжування) слід переробити. Якщо точність низька, але запам’ятовування високе, додавання повторного ранжирування є хорошим кроком.
Показники генерації
Коли надходить правильна деталь, ми вимірюємо якість відповіді моделі. Три основні виміри:
- Вірність: чи кожне твердження у відповіді підтверджується контекстом? Є підгонка? Це прямий показник галюцинації.
- Релевантність відповіді: чи відповідає відповідь на запитання чи вона не стосується теми?
- Повнота: Чи була використана вся релевантна інформація в контексті чи її немає?
Вони часто оцінюються на основі оцінки (наприклад, 1-5), а не двійкової, як-от «правда/неправда».
Порада: відстежуйте вірність як окремий показник. Якщо точність зменшується разом із зменшенням точності, проблема полягає в генерації; Якщо точність висока, але відповідь неправильна, проблема полягає в неправильному фрагменті (повернення). Разом ці два показники є компасом, який показує місце несправності.
Створення золотого набору запитань
Для кожного вимірювання потрібен золотий набір/набір оціночних даних: реалістичні запитання + очікувані правильні відповіді + правильні джерела. Почати з 30-50 правильно підібраних питань краще, ніж з 500 випадкових питань. Включіть у набір наступне: поширені реальні запитання, відомі складні запитання, запитання-пастки без відповідей (треба сказати «не знаю»), запитання з суперечливими джерелами.
# Приклад золотого кластера (концептуальний)[ {"question": "Скільки днів щорічної відпустки?", "expected_answer": "14 днів для 1-5 років стажу", "correct_part_id": "two-part-3", "category": "leave"}, {"question": "Де знаходиться офіс компанії Mars?", "expected_answer": "NO_INFORMATION", # trap: я не знаю "correct_part_id": null, "category": "trap"}]
LLM-as-Judge: автоматичне оцінювання
Набирати сотні відповідей вручну втомлює. Модель LLM-as-judge — це коли одна модель оцінює та обґрунтовує відповідь іншої моделі на основі певних критеріїв. Хороша підказка судді чітко визначає критерії, наводить приклади та запитує обґрунтування.
# LLM-as-judge підказка (концептуальна) Ви неупереджений оцінювач. Оцініть наведену нижче ВІДПОВІДЬ відповідно до заданого КОНТЕКСТУ та ОЧІКУВАНОЇ ВІДПОВІДІ. Оцініть (1-5) і обґрунтуйте:- вірність: чи підтверджується кожне твердження у відповіді контекстом?- точність: чи відповідає відповідь очікуваній?- повнота: чи повна відповідна інформація? Зокрема: якщо відповідь містить інформацію, яка не відповідає контексту, укажіть вірність1 і вкажіть, яке твердження є сфабрикованим. КОНТЕКСТ: {контекст}ОЧІКУВАНО: {очікувано}ВІДПОВІДЬ: {відповідь}Вихід: {вірність, точність, повнота, обґрунтування}
Застереження: LLM як суддя не ідеальний; Вони можуть мати власні упередження (довга відповідь, перевага власного стилю). Також перевірте суддю: оцініть деякі відповіді як суддею, так і людиною та виміряйте згоду між ними. Якщо суддя відповідає людським оцінкам, ви можете йому довіряти.
Слабкий/сильний рейтинг
Слабкий («це було добре для мене»):
Я поставив кілька запитань, і відповіді здалися хорошими. У мене це живе.# Проблема: немає вимірювань, регрес непомітний, покращення сліпе.
Потужність (золотий кластер + дискретні показники + автоматичне судження + регресія):
Золоте гроно 40 питань. З кожною зміною, recall@5, вірність і точність вимірюються автоматично. Якщо оцінка падає, зміна скасовується. Під час виробництва відгуки користувачів збираються та додаються до набору.
Моніторинг і регресія у виробництві
Оцінка не проводиться один раз і не закінчується. Три постійні практики:
- Регресійне тестування: автоматично запускати золотий кластер після кожного запиту/вилучення/зміни моделі. Якщо рахунок зменшується, зміна скасовується. Це запобігає «розриву, намагаючись зробити його кращим».
- Моніторинг виробництва: відслідковується показник «не знайшов інформацію» в реальних питаннях, середня затримка, вартість, відгуки користувачів (👍/👎). Раптове збільшення «Я не знаю» часто є першою ознакою несправності індексу або пошуку.
- Цикл зворотного зв’язку: реальні запитання, надані користувачем 👎, переглядаються та додаються до золотої купи; Таким чином, набір з часом стає багатшим, а сліпі зони системи закриваються.
Три міні-чохли
Випадок 1 — Тиха регресія. Команда змінила підказку, щоб «поліпшити» її; Загальна точність підвищилася, але точність знизилася на 30% у питаннях пастки (модель почала більше підходити). Цього б не помітили, якби не питання-пастки в золотому грона; Регресійне тестування скасувало зміни.
Випадок 2 — Випрямлення неправильної ноги. В одного асистента відповіді були погані; Команда працювала над підказкою тижнями. Коли ми вимірювали показники пошуку, recall@5 становив лише 48% — проблема полягала в пошуку, а не в генерації. Коли було додано гібрид + переранжування, запам’ятовування зросло до 89%, а також зросла точність.
Випадок 3 — сповіщення про виробництво. Одного разу показник «Я не міг знайти інформацію» для помічника служби підтримки підскочив з 6% до 34%. Трекпад попередив; Причина полягала в тому, що робота індексування, яка виконується вночі, мовчки провалилася, і нові статті не завантажувалися. Без моніторингу некоректні заяви «не знаю» тривали б днями.
Поширені помилки
- Бути задоволеним «у мене це добре спрацювало»: без вимірювання регрес залишається непоміченим.
- Не розділяючи пошук і генерацію: ви виправите неправильну ногу та втратите час.
- Не ставте запитань-пасток: Схильність вигадувати речі не проявляється в золотому кластері.
- Неперевіряючий суддя: упереджене журі викликає помилкову впевненість.
- Виробництво не відстежується: збій індексу, вибух витрат продовжується тихо.
Підсумовуючи
- У RAG якість пошуку та генерації вимірюється окремо; Спочатку необхідно визначити, яка нога пошкоджена.
- recall@k, precision@k, MRR для пошуку; Для породження використовуються вірність, придатність, повнота.
- Кожне вимірювання потребує золотого кластера; Поставте в нього реальні, складні, пастки та суперечливі запитання.
- LLM-as-judge великі набори автоматичних оцінок; але сам суддя повинен бути виправданий перед людиною.
- Регресійне тестування, моніторинг виробництва та цикл зворотного зв’язку зберігають якість протягом тривалого часу.
Аплікаційне завдання
(1) Створіть золотий набір із принаймні 15 запитань для свого помічника: додайте принаймні 3 пастки (без відповідей), 3 складних, 2 суперечливих запитання. Напишіть очікувану відповідь і правильну частину до кожного запитання. (2) Вручну порівняти дві різні версії підказок із цим набором; Поставте кожній відповіді 1-5 балів за вірність і точність. (3) Адаптуйте підказку LLM-as-judge вище до власних критеріїв. (4) Визначте 3 показники, які ви відстежуватимете у виробництві, і для кожного запитайте «при якому пороговому значенні я можу подати сигнал?» напишіть значення.
контрольний список
- [ ] Я можу виміряти якість утримання та створення за допомогою окремих показників.
- [ ] Я знаю, що означають такі показники, як recall@k, вірність.
- [ ] Я можу побудувати золотий кластер, який включає реальні, складні, пастки та суперечливі запитання.
- [ ] Я можу налаштувати автоматичне оцінювання та перевірити суддю за допомогою LLM-as-judge.
- [ ] Я можу керувати регресійним тестуванням, моніторингом виробництва та циклом зворотного зв’язку.