Как тестировать RAG-системы: методы, инструменты и метрики
В компании появился ИИ‑помощник, чат‑бот или поиск по внутренней базе знаний? Следующий логичный шаг – убедиться, что он работает надёжно.
У RAG-системы может быть высокий показатель качества, низкая задержка и почти нулевой процент технических ошибок – и при этом пользователи будут получать неправильные ответы. А это грозит серьёзными финансовыми и репутационными потерями.
Почему так происходит?
Потому что LLM-систему нельзя тестировать по той же логике, что обычный веб-сервис. В новом лонгриде разбираемся, как выстроить контроль качества, на что обратить внимание в первую очередь, какие метрики отражают реальную картину.
Внутри: 🔘какие особенности LLM ломают привычный подход к тестированию; 🔘на каких 8 этапах RAG-конвейера могут возникать ошибки; 🔘какие метрики использовать для оценки поиска, качества ответов и производительности; 🔘почему средняя задержка может скрывать проблемы пользователей и что такое TTFT, ITL и goodput; 🔘как организовать регресс, нагрузочное тестирование и контроль качества после выхода системы в прод.
Плюс – разборы реальных примеров и полезные инструменты.
#RAG #LLM #тестированиеПО #тестированиеИИ #QA #AIOps #управлениеITпроектами #CTO
· 09.09
Привет, я разрабатываю опенсорс-движок для kb и отчасти статья полезная. Есть два вопроса -
1. Гонять бенчмарки дело недешёвое. Какой бюджет в токенах на тестирование? 2. Мой kb-движок нацелен на получение актуальной информации из чатов,кода,доков и тасок. Я прогонял на DRAGON (100% recall, 80.3% кач) и на синтетических датасетах по законодательству и опенсорс-проектам. Какие ещё бенчмарки можете посоветовать? Я знаю про EnterpriseRAG-Bench, но на моём стенде его прогон займёт год.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 10.09
По бюджету. Считать удобнее через дробление на кейсы, а не прогоны. Сколько именно выйдет – зависит от вашего top-k, размера чанков и числа метрик, так что универсальной цифры нет, надо померить у себя. Что устойчиво независимо от настроек: судья обычно съедает сопоставимую с генерацией долю счёта, потому что контекст скармливается ему повторно, а метрики ретривера стоят ноль токенов и закрывают заметную часть диагностики. Снизить можно, навскидку, через кэш вердиктов по хэшу – но он имеет смысл только при temp=0, иначе нечего кэшировать; пересуждать одно изменившееся, diff по нормализованному ответу; парное сравнение вместо абсолютных оценок, там дисперсия ниже.
По бенчмаркам. 100% recall – возможно, показатель потери: если метрика больше не различает, весь остаток сидит в тех 19,7%. Возможно, стоит сначала разобрать их руками и построить таксономию ошибок, это дешевле любого нового прогона. Плюс DRAGON собран на новостях, чаты и таски устроены иначе, так что перенос по retrieval, видимо, ограниченный. Из того, что ближе к вашим (насколько могу понять контекст): LongMemEval, LoCoMo (длинные диалоги), FreshStack (код и техдоки), CoIR (регресс эмбеддера на коде). RAGTruth – не для оценки продукта, а чтобы понять, врет ли детектор галлюцинаций.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён