Виправте RAG, знайшовши першу стадію, яка зазнала невдачі

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

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

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

Створюйте приклади з доказами, а не лише відповідями

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

Приклад ілюстративного випадку може виглядати так:

{
  "question": "When should this deployment be rolled back?",
  "required_evidence": ["handbook-v3:section-8"],
  "must_include": ["the failed health-check condition"],
  "must_not_claim": ["every warning requires rollback"],
  "answerable": true
}

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

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

Спочатку перевірте найранішу помилку

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

Далі перевірте процес пошуку. Чи потрапили відповідні докази до списку кандидатів? Якщо так, чи вони пережили фільтрацію, переурочування та формування контексту? Це окремі точки перевірки. Уривок, знайдений під час пошуку, але видалений до генерації, не може підтримати кінцеву відповідь.

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

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

Використовуйте метрики, які виявляють різні помилки

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

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

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

Зберігайте якість роботи в одному експерименті

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

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

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

Оцінюйте те, що потрапляє до користувача

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

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