Ваш RAG-конвеєр успішно проходить стандартне навантажувальне тестування. p95 затримка виглядає здоровою. Рівень помилок близький до нуля. Проте користувачі повідомляють про відповіді, які уникають питання, посилаються на неіснуючі документи або витягують нерелевантні абзаци з white paper, завантаженого шість місяців тому. Дашборд каже, що все гаразд. Досвід користувача свідчить про те, що все зламано.
Цей розрив існує тому, що традиційне тестування продуктивності було розроблене для систем типу «запит-відповідь», а не для систем, які мислять. Коли ви надсилаєте тисячу паралельних запитів на REST-ендпоінт, ви дізнаєтеся, чи витримують ваші сервери навантаження. Ви нічого не дізнаєтеся про те, чи витягує ваш рівень пошуку (retrieval layer) правильні фрагменти (chunks), чи зберігає ваш шаблон промпту контекст, або чи не вигадує модель джерела, коли векторне сховище виявляється порожнім. Стандартне навантажувальне тестування вимірює швидкість. RAG-додатки вимагають, щоб ви вимірювали розуміння.
Поза межами статус-коду 200
Типове навантажувальне тестування API перевіряє три речі: доступність, затримку та пропускну здатність. Воно визначає, чи відповів сервер, скільки це зайняло часу та скільки одночасних користувачів він витримав. Для RAG-додатка ці показники є передумовами, а не підсумками. Швидка неправильна відповідь — це все одно неправильна відповідь, а неправильні відповіді у масштабі коштують дорожче, ніж повільні.
RAG додає два окремі етапи до кожного запиту. По-перше, система перетворює запитання користувача на ембедінг (embedding), робить запит до векторного сховища та отримує набір контекстних фрагментів. По-друге, вона вставляє ці фрагменти в промпт, надсилає все це мовній моделі та повертає потік завершеної відповіді (completion). Традиційні тести часто об'єднують ці етапи в одну метрику «час відповіді». Вони розглядають механізм пошуку та генератор як один «чорний ящик».
Вам потрібно розкрити цей ящик. Якщо ваша векторна база даних сповільнюється під навантаженням, затримка пошуку зростає. LLM все ще може відповідати швидко, але вона відповідатиме на основі сміттєвого контексту, отриманого поспіхом. З іншого боку, векторний пошук може залишатися швидким, тоді як черга LLM накопичується, збільшуючи час до першого токена (time-to-first-token), поки користувачі не залишаться дивитися на мигаючий курсор. Один таймер end-to-end приховує обидва типи збоїв.
Тестуйте пошук, а не лише базу даних
Більшість команд проводять швидкий бенчмарк векторного пошуку і вважають рівень пошуку протестованим. Цей бенчмарк зазвичай вимірює, наскільки швидко база даних повертає найближчих сусідів (nearest neighbors) для підібраного запиту. Він рідко вимірює, чи містять ці сусіди факти