Чому оцінювання RAG ламається на реальних даних
На демонстраційному наборі з двадцяти питань асистент відповідає без помилок, а через тиждень роботи співробітники перестають ним користуватися.
Причина не в моделі, а в тому, що реальний трафік влаштований інакше: запити короткі та з помилками, формулювання не збігаються з текстом регламентів, частина питань потребує даних із двох документів одразу.
Перший шар, де втрачається якість, — пошук у базі знань.
Потрібний фрагмент або не потрапляє до топу видачі, або надходить разом із шумом: розбиття документа не збігається зі змістовими блоками, метадані не працюють як фільтр, а схожі формулювання з різних редакцій одного документа конкурують між собою.
Тут рахуємо повноту пошуку та точність — яку частку релевантних фрагментів система дістає і скільки зайвого тягне в контекст.
Другий шар — генерація. Навіть за правильного контексту асистент дописує «загальновідоме», склеює два фрагменти в один і підміняє числа або строки.
Відповідь звучить упевнено, але розходиться з базою знань, і на цьому ламається довіра: неперевірювана відповідь гірша за відсутність відповіді.
Звідси третій шар — вірність джерелу: яку частку тверджень у відповіді можна підтвердити процитованим фрагментом. Ми розводимо метрики за шарами — каркас беремо з відкритого RAGAS — і бачимо, де саме просідає якість відповідей асистента. Розбираємо, як це закривається на кожному шарі.
Що змінюється після впровадження регулярних перевірок
Регулярний прогін на замороженому наборі питань переводить якість відповідей з відчуттів у метрику.
Ми фіксуємо еталонні пари «питання → очікувана відповідь і джерело» і після кожної правки промпту, моделі або пошукового індексу рахуємо faithfulness, precision і recall через RAGAS — результати порівнювані між релізами, а не «цього разу начебто відповідає краще». Що змінюється за пунктами:
- Частка відмов падає. Відповіді, у яких faithfulness нижчий за поріг або немає опори на піднятий фрагмент, відсікаються до викату: у прод іде версія, де частка недостовірних відповідей менша в рази, а не «приблизно як раніше».
- Оновлення індексу виходять швидше. Пересборка й перевірка йдуть одним прогоном, тому правка в базі знань займає години замість днів ручного перегляду десятків діалогів.
- Регресії видно на порозі релізу. Порівняння з попереднім прогоном показує, які групи питань просіли після зміни моделі або розбиття документів на фрагменти.
- Спірні відповіді випливають до випуску. Список питань із низьким recall показує діри в базі знань — їх закривають контентом, а не черговою правкою промпту.
- Розбір став предметним. Для будь-якої відповіді є трасування: які фрагменти піднято, що потрапило в контекст, на якому кроці загубився потрібний факт.
Підсумок: контроль якості відповідей перестає бути разовою прийманкою і стає частиною релізного циклу — з порогами, історією метрик і спільним для команди критерієм того, що вважати погіршенням.
Способи перевірки: від ручної розмітки до автотестів
Перевіряти якість RAG-системи можна трьома шляхами, і на практиці їх не обирають «або-або» — вони закривають різні класи помилок.
Ручна розмітка дає еталон: експерт проходить набір тестів із питань із відомими правильними фрагментами й відзначає, чи відповідь спирається на джерело і чи не втрачено потрібний абзац.
Синтетичний набір збирається з корпусу документів і масштабується до сотень кейсів, але відтворює формулювання самих документів, а не живе мовлення користувача.
Автоматичні прогони рахують метрики без людини: частку відповідей, підкріплених джерелом, потрапляння потрібного фрагмента у видачу, повноту щодо еталона.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручна розмітка | Старт проєкту, спірні та рідкісні питання, налаштування порогу якості | Дорого за часом експерта, погано масштабується, суб’єктивна між розмітниками |
| Синтетичний набір тестів | Швидке охоплення сотень питань, перевірка повноти індексації | Успадковує формулювання документів, не ловить розмовні перефразування та помилки |
| Автоматичні прогони метрик | Регулярна перевірка на кожній зміні індексу або підказки | Метрика не розуміє сенс: правильна відповідь з іншим формулюванням вважається промахом |
Робоча схема — комбінована: еталон із ручної розмітки (зазвичай сто-двісті питань, включно з рідкісними сценаріями), синтетика для обсягу й автоматичний прогін на кожній зміні.
Відкриті набори метрик на кшталт RAGAS закривають базові вимірювання, але їхні показники звіряємо з ручними — розходження одразу показує, де метрика бреше, і тоді ваги переглядаються.
Набір тестів живе разом із системою: нові звернення користувачів перетворюються на питання еталона, тому регрес ловиться до випуску, а не після скарг.
Етапи впровадження контуру контролю якості
Контур контролю якості не з’являється разом із першою версією відповідей: його збирають поетапно, залишаючи на кожному кроці артефакт, який переживе зміну моделі та переіндексацію корпусу.
Нижче — порядок робіт від інвентаризації даних до регламенту, за яким прогони запускаються вже без нашої участі.
- Аудит даних — перелік джерел, перевірка актуальності та дублів, розмітка тем: що корпус покриває щільно, а що збирається з кількох фрагментів.
- Еталонні питання — простий факт, зведення за кількома документами, питання без відповіді в корпусі. До кожного — очікувані фрагменти-джерела, а не лише правильне формулювання.
- Метрики та опорний замір — точність пошуку, повнота видачі, вірність відповіді опорним фрагментам. Перший прогін дає точку відліку для всіх наступних правок.
- Пороги приймання — окремо за кожною метрикою: що достатньо для випуску, а що блокує реліз. Плавність формулювань не повинна маскувати провал за повнотою.
- Регресійні прогони — на зміні моделі, схеми розбиття або правці корпусу; розходження з опорним заміром розбираємо до випуску, а не після скарг.
- Розбір помилок — класифікація провалів: фрагмент не знайдено, знайдено застарілий, відповідь зібрано не за джерелами. За часткою груп видно, що правити — пошук чи корпус.
- Передача регламенту — набір питань, пороги та порядок прогонів переходять вашій команді документом, який вона запускає сама.
Регламент описує, що проганяти після кожної правки корпусу і як тлумачити розходження, — якість перестає залежати від того, хто сьогодні чергує на релізі. У міру появи нових сценаріїв набір еталонних питань розширюється.
Що передаємо: набори тестів, пороги, регламенти
Разом із працюючою системою замовник отримує комплект, за яким якість відповідей можна вимірювати й після передачі — без нас і без нашої інфраструктури. Прогін запускається на вашій стороні, на зафіксованому індексі, і дає порівнювані результати від релізу до релізу.
- Набір тестів — питання, зібрані з реальних звернень, розмічені за типами: пошукові, уточнювальні, багатокрокові та явно без відповіді в базі знань.
- Еталонні відповіді — для кожного питання зафіксовано, що вважається правильним, і вказано фрагмент-джерело, яким ця відповідь підтверджується.
- Звіт за метриками — точність і повнота пошуку, частка відповідей, підтверджених джерелом, і частка коректних відмов «даних у базі немає».
- Зрізи за групами — метрики рахуються окремо за темами та типами запитів: середній бал за всією вибіркою приховує провал на вузькому, але важливому сегменті.
- Правила приймання — порогові значення за кожною метрикою й умови, за яких реліз блокується, а не «доопрацьовується потім».
- Конфігурація прогону — розмір фрагментів, схема розбиття документів, параметри пошуку й версія індексу: без цього два звіти не можна зіставити.
- Регламент супроводу — порядок поповнення набору тестів після кожного розбору збою й правило, хто оновлює еталони при зміні бази знань.
Зміна моделі, переіндексація або розширення бази знань проганяються за лічені хвилини й одразу показують, що саме просіло — пошук чи генерація. Ви ухвалюєте рішення про викат за цифрами, а не за відчуттям від кількох ручних перевірок.
Кейс: оцінювання RAG на потоці звернень клієнтів
RAG-асистент на потоці клієнтських звернень відповідав швидко, але якість ніхто не вимірював: правки в промпт і в розбиття документів вносили за відчуттями.
Відповіді виглядали переконливо, а спиралися не на ті фрагменти — розходження помічали за скаргами операторів, і розбір одного випадку займав дні.
Що було
Перевіряли на десятку зручних питань, де система відповідала добре: реальні формулювання з помилками, змішаною термінологією та уточненнями в довгому діалозі у вибірку не потрапляли. Метрик точності не існувало — лише суб’єктивне «стало краще».
Через це правку не можна було ні прийняти обґрунтовано, ні відкотити: незрозуміло, що саме покращилося і чи не зламалося щось на сусідніх сценаріях.
Що стало
Зібрали набір із живих звернень з еталонними фрагментами й відповідями та підключили регулярні прогони на RAGAS: вірність відповіді джерелу, точність потрапляння в контекст, повнота знайдених фрагментів.
Тепер кожна зміна пошуку або промпту проходить прогін до викату, а спірні випадки інженери розбирають вручну.
Точність потрапляння в контекст зросла з 0,61 до 0,87, вірність відповіді — з 0,72 до 0,94, повнота вибірки — з 0,58 до 0,83. Частка відповідей, побудованих на нерелевантному фрагменті, знизилася приблизно втричі — пішли невірні поради та повторні звернення за тією ж темою.
Зміни перестали бути лотереєю: погіршення видно на прогоні до викату, а не у відгуках через тиждень, і розбір якості займає години замість днів.
Чим відрізняється перевірка пошуку від перевірки генерації
Збій у RAG-системі виглядає однаково: користувач отримує впевнену, але неправильну відповідь. Причина при цьому може лежати в двох різних місцях — на етапі пошуку або на етапі генерації, і метрики в цих контурів різні.
Перевірка пошуку відповідає на питання, чи потрапив потрібний фрагмент у контекст узагалі.
Тут рахують повноту контексту — частку питань, для яких релевантний шматок опинився у верхніх результатах видачі, точність видачі — яку частину цього набору займають справді корисні фрагменти, і позицію першого збігу: якщо потрібний абзац лежить сьомим, генератор до нього дотягнеться не завжди.
Перевірка генерації працює з готовою відповіддю та з тим контекстом, який їй передали. Головна метрика — вірність контексту: кожне твердження у відповіді має спиратися на передані фрагменти, а не на пам’ять моделі.
Поруч рахують повноту відповіді щодо питання й частку чесних відмов «у контексті цього немає» — таке «не знаю» краще за правдоподібну вигадку.
Окремі метрики потрібні тому, що ці контури лагодяться по-різному. Низька повнота контексту лікується розбивкою на фрагменти, пошуком за змістом і за словами, переранжуванням, фільтрами за метаданими.
Якщо контекст на місці, а відповідь із ним розходиться — правимо промпт і схему відповіді, вимагаємо посилань на джерела та перевіряємо твердження після генерації.
Загальний бал без розділення не дає інженеру нічого: падіння на десяток відсотків однаково виглядає і при зламаному індексі, і при невдалій правці промпту. Ми рахуємо обидва контури на одному наборі питань із розміченими фрагментами, тому видно, який шар просіл і що з ним робити.
Часті технічні питання та обмеження
Перед стартом фіксуємо межі заміру: метрики на кшталт faithfulness, precision і recall описують поведінку системи на підготовленому наборі питань, а не її якість загалом.
Тому до цифр завжди додаємо розбір помилок — інакше зростання faithfulness маскує відповіді, які формально спираються на контекст, але не розв’язують задачу користувача.
Як боретеся з шумом у розмітці?
Еталонний набір розмічають двоє незалежно, розходження йдуть в арбітраж третім спеціалістом. Частку незгод тримаємо нижче 10%, спірні приклади доводимо до консенсусу: без цього precision і recall коливаються сильніше, ніж ефект від змін у самій системі.
Які обмеження в самих метрик?
Жодна метрика не ловить неповну відповідь: вона може бути правильною, але пропускати важливу частину контексту. Доповнюємо автозамір набором «хворих» питань і ручною перевіркою випадкової вибірки — так деградація видна там, де усереднений бал її приховує.
Як часто проганяти оцінювання і коли оновлювати набір?
Повний прогін — на кожен реліз пошукового індексу або зміну генеративної моделі, швидкий зріз метрик — на кожну зміну формулювань запитів до моделі.
Набір тестів переглядаємо при оновленні корпусу та появі нових сценаріїв: застарілі питання завищують оцінку, бо система відповідає на них за завченим, а не за документами.
Обговоримо задачу і повернемося з планом робіт
Щоб розбір був предметним, а не загальним, надішліть ввідні щодо поточного рішення. За ними видно, де вузьке місце — у якості генерації, в пошуку чи в розмітці еталонів — і що має сенс змінювати першим.
- сценарій: які питання задають користувачі та яка відповідь вважається правильною;
- 20–50 реальних запитів з еталонними відповідями та посиланням на фрагмент-джерело;
- поточна конфігурація пошуку: як документи ріжуться на чанки, яка модель ембедингів, скільки фрагментів подається в контекст;
- корпус документів або його обезличенний зріз — перевірки проганяємо на ваших даних, а не на демонстраційному наборі;
- метрики, якщо вже рахуєте: precision, recall, faithfulness, частка відповідей без опори на контекст;
- помічені збої: вигадані факти, застарілі фрагменти, втрата інформації із середини документа;
- обмеження щодо даних: де можна розгортати контур, які зовнішні сервіси допустимі.
У відповідь повернемося з планом робіт: етапи, набір метрик із пороговими значеннями, схема регресійних прогонів на зафіксованому наборі питань і порядок старту.
Окремо зафіксуємо, які регламенти оцінювання передаємо вашій команді, щоб перевірки залишалися відтворюваними й без нас.
Опишіть задачу — повернемося з оцінкою та планом.
