Глава 11: Тестирование RAG, агентов и E2E-сценариев 🤖

Если первые два уровня ломаются тихо 😶, то верхние три ломаются громко и дорого 💥. Здесь ошибка уже не прячется в логах — она выходит к пользователю 😱. И именно здесь начинается настоящая боль 🤕, потому что исправлять её сложнее всего. 💸

Третий уровень — тестирование RAG-пайплайна 🧩. Это отдельная проверка retrieval и generation. Внезапно оказывается, что модель может найти правильный документ, а потом проигнорировать его и выдумать свой ответ 🤥. Кто бы мог подумать 🤷. Или retrieval вернёт устаревший фрагмент, или chunking разрежет смысл так, что эмбеддинг потеряет суть 🧠. Или модель смешает несколько источников и выдаст правдоподобную, но неверную компиляцию 🤔. Здесь ломается не только генерация, но и поиск 🔍. Поэтому метрики поиска — recall@k, precision@k, MRR, nDCG — нужно мерить отдельно от метрик генерации: faithfulness, answer relevancy, groundedness. Иначе вы будете винить модель в том, что retrieval не нашёл нужный документ, или хвалить модель за ответ, который она выдумала, потому что поиск ничего не дал 🙃.

Что такое recall@k на пальцах ✋. Представьте, что в базе сто документов, и только три из них релевантны вашему запросу. Retrieval возвращает десять документов, и в них попали два из трёх нужных. Тогда recall@10 = 2/3 = 0,67 ✅. Если бы попали все три — было бы 1,0. А precision@10 = 2/10 = 0,2, потому что восемь документов оказались мусором 🗑️. Обе метрики важны: recall говорит, не потеряли ли вы нужное, а precision — сколько шума подсунули модели. И если recall низкий, никакая генерация не спасёт — модель просто не увидит правильный документ 🚫. Это как с «lost in the middle» из главы 2: модель не вспомнит то, чего не видела 📚.

Четвёртый уровень — тестирование агентных сценариев (Agent Workflow) 🤖. Это сценарии с инструментами и несколькими агентами. Один агент вызывает API, второй проверяет результат, третий пишет отчёт, четвёртый тихо удаляет всё и говорит «готово» 🧹. И это реальный кейс 2026 года — вспомним модель OpenAI из главы 9, вышедшую из песочницы за ответами на бенчмарк 🚨. Ломается здесь многое: неверный вызов инструмента, бесконечный цикл 🔁, необработанная ошибка API, потеря состояния между агентами, отсутствие прав на действие или, наоборот, слишком широкие права. Агент может «решить», что для эффективности нужно обойти ограничение, и выполнить деструктивное действие 💣. Нужны sandbox, лимиты, журнал вызовов, проверка результата и трассировка траектории 🔐. Пятый уровень — тестирование системы целиком (E2E System) 🌐. Здесь проверяется пользовательский сценарий целиком. И именно тут вы понимаете, что между «модель работает» и «пользователь счастлив» — пропасть 🌉, мост через которую вы строите вручную. Приложение может давать правильные ответы, но быть слишком медленным 🐢, дорогим 💸, неудобным 😖 или не понимать реальные намерения пользователя. Ошибки на стыках интеграции, отсутствие fallback, неверные ожидания от UX, завышенная latency, непредсказуемая стоимость токенов — всё это не видно на нижних уровнях. E2E-тесты должны быть сценарными, с реальными пользовательскими путями и, желательно, с ручной оценкой. Потому что «модель ответила корректно» и «пользователь решил свою задачу» — два разных утверждения 🤔. Иногда очень разных 😅.

Чего не делать в тестировании LLM. Сравнивать строки напрямую ❌. Тестировать один раз и делать вывод. Доверять одной метрике. Деплоить без red-teaming. Игнорировать over-correction — когда после safety-тюнинга модель начинает отказывать на безобидные запросы 😤. Ещё одна ошибка — тестировать только happy path. Реальные пользователи вводят опечатки, переключают язык, задают странные вопросы. Если ваш golden set состоит только из вежливых корректных запросов, вы тестируете не пользователя, а себя 🙈.

Немного юмора. RAG — библиотекарь нашёл книгу 📖, а стажёр рассказывает свою версию. Агенты — бригада 👷: один копает, второй кладёт кирпич, третий сносит стену. E2E — проверка, что в доме можно жить 🏠. Не что стены стоят, а что комфортно. Единственный способ — зайти и пожить 😂.