Спершу набір для оцінки, потім налаштування RAG

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

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

Що таке набір для оцінки

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

• Запитання дослівно, як його поставив би користувач
• Ключові факти, які має містити правильна відповідь, — короткий чекліст, а не еталонний текст
• Документи або розділи, де ці факти є
• Позначка, коли чесна відповідь — «у документах про це нічого немає»

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

Наскільки великим він має бути

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

Міряйте пошук і генерацію окремо

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

• Влучність пошуку: як часто очікуване джерело є серед знайдених
• Повнота відповіді: скільки обов'язкових фактів вона містить
• Обґрунтованість: чи кожне твердження підкріплене знайденим фрагментом
• Точність відмов: чи система каже «не знаю», коли корпус мовчить

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

Автоматизуйте оцінку, але лишіть людину

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

Ставтеся до набору як до коду

Зберігайте набір у системі контролю версій поруч із конфігурацією. Запускайте його в CI, коли змінюється промпт, чанкування чи модель, і записуйте результати разом із комітом. Тоді обговорення зміни звучить як «пошук виріс на чотири пункти, повнота впала на один», а не «здається, стало краще».

Доповнюйте набір щоразу, коли продакшен видає погану відповідь. Кожна скарга користувача — безкоштовний тест-кейс, а набір, що росте з реальних помилок, — найближче до гарантії, що та сама помилка не потрапить у реліз двічі.

З чого почати в понеділок

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