Як перевіряти RAG-системи перед запуском у продукті

Якість відповіді починається до генерації

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

Тестовий набір має відображати реальні запити

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

Ранжування потрібно перевіряти після кожної зміни індексу

Результат пошуку залежить не лише від моделі векторів. На нього впливають очищення документа, розмір фрагмента, перекриття між частинами, фільтри метаданих, поєднання звичайного й семантичного пошуку та повторне ранжування. Зміна одного параметра може допомогти коротким довідкам і водночас погіршити роботу з великими політиками або таблицями. Тому конфігурацію слід зберігати як версію, а результати кожного експерименту порівнювати на незмінному наборі запитів. Корисно дивитися не лише на середню оцінку, а й на теми, де новий варіант програв. Якщо команда не може відтворити індекс і пояснити різницю між двома запусками, вона не матиме надійного способу розслідувати погіршення після оновлення. Контрольний набір корисно будувати за тими самими принципами, що й оцінювання локальних моделей на реальних пристроях, а вплив на роботу команди перевіряти через вимірюваний результат ШІ-помічника.

Посилання на джерело ще не доводить правильність

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

Людські оцінки потребують спільної шкали

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

Доступ до документів потрібно перевіряти на кожному кроці

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

Запуск потребує спостереження, а не разової оцінки

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