RAG Diagnostics — это диагностика RAG-системы, когда команда разбирает не только финальный ответ, а весь путь от вопроса пользователя до ответа модели. Цель простая: понять, где именно сломалось качество. Агент мог не найти нужный документ, найти слишком много шума, неправильно нарезать фрагменты, потерять важный контекст, сослаться не на тот источник или уверенно пересказать устаревший регламент.
Без диагностики RAG часто чинят вслепую. Например, меняют модель, хотя проблема была в плохом chunking. Увеличивают top-k, хотя нужен retrieval filter по типу документа. Переписывают системный промпт, хотя в индекс попали старые версии инструкций. RAG Diagnostics помогает отделить проблемы поиска от проблем генерации и не тратить время на случайные правки.
Хорошая диагностика смотрит на несколько слоев. Сначала проверяют исходный вопрос: что пользователь реально хотел узнать. Потом смотрят retrieval: какие документы попали в выдачу, почему именно они, есть ли среди них правильный источник. Затем оценивают контекст: хватает ли модели данных для ответа, нет ли противоречий и лишнего шума. После этого проверяют сам ответ: соответствует ли он источникам, есть ли цитаты, не добавлены ли неподтвержденные утверждения.
Для бизнеса RAG Diagnostics особенно важна после изменений: обновили базу знаний, поменяли модель, добавили новые документы, включили reranking, изменили права доступа или запустили агента в новом отделе. Диагностика превращает RAG из “черного ящика” в понятную систему, где каждую ошибку можно привязать к конкретному месту и исправить.
Примеры
- Агент поддержки дал неверный ответ по возврату. Диагностика показала, что retriever нашел старую версию регламента.
- Внутренний поиск не отвечает на вопрос сотрудника. В trace видно, что нужный документ есть в базе, но chunking отрезал важный абзац.
- Юридический агент сослался на договор, но цитата не подтверждает вывод. Ошибка находится на уровне генерации, а не поиска.
- После увеличения top-k ответы стали хуже: в контекст попадает больше нерелевантных фрагментов и модель путается.
- BI-агент правильно нашел metric catalog, но ответил без учета фильтра по региону. Диагностика указывает на проблему в metadata filters.
Где используется
- Разобрать, почему RAG-агент дал неправильный или неполный ответ.
- Отделить проблемы retrieval от проблем промпта, модели и финальной генерации.
- Проверить качество chunking, top-k, reranking, фильтров и метаданных.
- Найти устаревшие, дублирующиеся или противоречивые документы в базе знаний.
- Проверить, почему цитаты не подтверждают ответ модели.
- Диагностировать ошибки прав доступа и утечки закрытых источников.
- Сравнить поведение RAG до и после обновления модели или индекса.
- Собрать trace для сложных кейсов поддержки, HR, юристов, продаж и аналитики.
- Подготовить задачи на исправление базы знаний, индексации или retriever.
Связанные термины
Частые вопросы
Чем RAG Diagnostics отличается от RAG Evals?
RAG Evals измеряют качество на наборе тестов, а RAG Diagnostics разбирает конкретную ошибку по шагам: вопрос, поиск, контекст, ответ, цитаты и права доступа.
С чего начинать диагностику RAG?
Сначала нужно сохранить исходный вопрос, найденные документы, фрагменты контекста, финальный ответ и trace. Потом отдельно проверить, был ли найден правильный источник и как модель использовала контекст.
Какие ошибки чаще всего находят при диагностике?
Часто встречаются старые документы, плохой chunking, слабые метаданные, неверные retrieval filters, слишком большой top-k, отсутствие reranking и ответы, которые не подтверждаются цитатами.
Нужны ли специальные инструменты для RAG Diagnostics?
Желательно иметь tracing, логи retrieval, просмотр найденных chunks, ссылки на источники и набор тестовых вопросов. Без этого диагностика превращается в ручное угадывание.
Когда стоит проводить диагностику RAG?
После заметных ошибок пользователей, перед production-запуском, после обновления базы знаний, смены модели, изменения индекса, настройки reranking или прав доступа.
