Як було налаштовано тест

Автор створив невелику систему генерації з доповненням пошуком (RAG) на основі двох документів із правилами платежів і провів дві перевірки:

  • Тест на повноту (Recall) – чи з'явилася правильна сторінка серед п'яти найкращих результатів? Результат: 60 %.
  • Тест на правильність відповіді – чи була остаточна відповідь, згенерована моделлю, правильною? Результат: 90 %.

Розрив у 40 % здавався неможливим. Якщо retriever пропускав потрібну сторінку чотири рази з десяти, як модель могла все одно відповідати правильно дев'ять разів із десяти?

Перші спроби «виправити» retriever

Розробник спробував два поширені методи:

  • Гібридний пошук – поєднання лексичних і векторних сигналів. Повнота залишилася незмінною.
  • Reranker (переранжувальник) – зміна порядку п'яти знайдених сторінок. Повнота зросла до 70 %, але все одно значно відставала від 90 % точності відповідей.

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

Проблема була в метриці, а не в моделі

Замість того, щоб оцінювати успіх за міткою сторінки, автор перевірив факти у знайдених фрагментах (chunks). У трьох із чотирьох випадків «пропусків» правильний факт був присутній, але він знаходився на іншій сторінці, ніж очікував тестовий скрипт. Оцінка карала retriever за знаходження правильної відповіді на неочікуваній сторінці.

Коли метрику змінили на «чи містить будь-який знайдений фрагмент необхідний факт?», повнота підскочила до 90 %, зрівнявшись із точністю відповідей. Retriever працював; не працювала система оцінювання.

Чому традиційна повнота може вводити в оману

  • Маркування на рівні сторінок створює фантомні помилки. Один і той самий факт може з'являтися на кількох сторінках. Якщо позначати лише одну сторінку як еталонну (ground truth), усі інші правильні збіги вважатимуться помилками.
  • Малі корпуси підсилюють цей ефект. При невеликій кількості документів одна неправильно маркована сторінка може різко змінити показник повноти, тоді як точність відповідей залишатиметься стабільною.
  • Шум ембедінгів приховує факти. Векторні моделі оцінюють цілі сторінки; навколишній юридичний або технічний текст розмиває сигнал релевантності цільового речення, опускаючи сторінку нижче в рейтингу, навіть якщо факт там є.

Практичні поради для спеціалістів із RAG

  • Розділяйте помилки ранжування та помилки пошуку. Rerankers виправляють лише перше; якщо правильний фрагмент ніколи не потрапляє до набору кандидатів, зміна порядку не допоможе.
  • Маркуйте тестові дані на рівні фактів. Прив'язуйте кожен запит до конкретної інформації, яка йому потрібна, а не до ідентифікатора одного документа.
  • Не покладайтеся на масштабні бенчмарки для крихітних наборів даних. Малі вузькоспеціалізовані корпуси поводяться інакше, і загальні показники повноти можуть бути оманливими.
  • Звертайте увагу на гранулярність ембедінгів. Фрагмент розміром із цілу сторінку містить багато слів, і навколишній юридичний текст може знизити ранг факту, який вас цікавить.

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