Хороший текст ещё не доказывает качество. Для бизнеса важнее понять путь ответа: вопрос → источник → правило → поведение при нехватке данных → решение человека или отчёт качества.

RAG Quality

Проверочный слой для AI-агентов, которые отвечают по документам

RAG Quality — это проверочный слой, а не агент и не самостоятельный AI-продукт.

Он помогает проверить, находит ли AI правильные источники, не искажает ли смысл и умеет ли останавливаться там, где данных не хватает.

RAG Quality нужен внутри AI Support Agent, AI Knowledge Assistant, RAG Quality Audit и любых решений, где AI отвечает по базе документов.

Если вы только начинаете, проще читать так:

1. сначала откройте Knowledge Pack, чтобы понять, какие знания готовятся для агента;
2. затем вернитесь сюда, чтобы понять, как проверять ответы;
3. после этого посмотрите RAG Quality Report, чтобы понять, как фиксировать ошибки и улучшения.

RAG Quality нужна, если у вас уже есть AI-агент, document Q&A, internal knowledge assistant или RAG-система, которая отвечает по документам компании.

Проблема в том, что хороший текст ещё не доказывает качество. Агент может звучать уверенно, вежливо и логично, но при этом использовать старый документ, пропустить важное исключение или добавить обещание, которого не было в источнике.

RAG Quality в AI-Ready — это слой проверки. Он показывает не только «ответ похож на правильный», а весь путь: вопрос, найденный источник, статус источника, допустимые claims, поведение при нехватке данных и решение человека.

Короткий ответ

RAG Quality показывает, можно ли доверять ответу AI-агента.

Она проверяет:

• нашёл ли агент правильный источник;
• подходит ли источник к вопросу;
• актуален ли документ;
• не исказил ли агент смысл;
• не сделал ли запрещённое обещание;
• увидел ли нехватку информации;
• передал ли спорный случай человеку.

Это не просто метрика и не только eval tool. Это практический контроль качества перед пилотом и после него.

Когда это становится проблемой

Обычно команда замечает проблему после хорошего демо.

Агент отвечает быстро, текст выглядит аккуратно, пользователю приятно. Но потом кто-то спрашивает нестандартный вопрос, и выясняется, что ответ был собран из неподходящего документа, старой политики или общего знания модели.

RAG Quality нужна, если:

• в базе много документов;
• документы конфликтуют;
• часть материалов устарела;
• ответы влияют на клиентов, деньги, сроки или обязательства;
• агент должен знать, когда остановиться;
• команда не понимает, почему один ответ хороший, а другой опасный.

Без проверки качества RAG легко превращается в поиск уверенных формулировок, а не в работу с утверждёнными знаниями.

Как это выглядит на практике

Клиент спрашивает: «Можно ли вернуть товар после вскрытия упаковки?»

Агент отвечает: «Да, возврат возможен в течение 14 дней».

Текст звучит нормально, но RAG Quality задаёт другие вопросы:

• какой документ использован;
• есть ли в нём исключения;
• относится ли он к этой категории товара;
• свежий ли источник;
• можно ли обещать возврат без проверки;
• должен ли агент уточнить данные или сделать handoff.

Если источник не найден, RAG Quality не должна награждать агента за красивый ответ. Она должна показать gap.

Чем RAG Quality не является

RAG Quality — не просто «оценка от 1 до 10». Оценка полезна только тогда, когда понятно, что именно сломалось и кто это исправляет.

RAG Quality — не RAG как технология. RAG помогает искать по документам. RAG Quality проверяет, можно ли доверять найденному ответу.

RAG Quality — не замена владельца источника. Если документы конфликтуют, решение принимает человек или владелец процесса.

RAG Quality — не обещание production readiness. Даже хороший отчёт качества не заменяет privacy, access, security, approval и deployment review.

Минимальный набор проверки

Для первого прохода не нужно строить огромную eval-систему.

Достаточно собрать:

1. 20–50 реальных вопросов;
2. ожидаемые источники для каждого вопроса;
3. эталонные ответы или правила ответа;
4. сложные случаи: missing source, conflict, outdated source, forbidden claim;
5. список запрещённых обещаний;
6. формат RAG Quality Report;
7. владельца исправления;
8. дату повторной проверки.

Хорошая проверка не только говорит «ответ плохой». Она показывает, что исправить: документ, source map, answer policy, prompt, retrieval, handoff или decision log.

Что ломается без RAG Quality

Первая поломка — агент отвечает по источнику, который не должен был использовать.

Вторая — агент находит правильный документ, но искажает смысл.

Третья — агент не замечает, что информации не хватает.

Четвёртая — агент выбирает один из конфликтующих документов сам.

Пятая — команда видит хорошие средние метрики и пропускает опасные отдельные случаи.

RAG Quality нужна именно для таких моментов. Она заставляет смотреть не на красоту ответа, а на доказуемость.

Что можно сделать самостоятельно

Возьмите реальные вопросы из поддержки, продаж, внутренней базы знаний или документации.

Для каждого вопроса укажите:

• какой источник должен использовать агент;
• какой ответ считается допустимым;
• какие обещания запрещены;
• что делать, если источника нет;
• когда нужен человек.

Потом прогоните эти вопросы через текущего агента или прототип. Не ищите только хорошие примеры. Добавьте неудобные: старый документ, конфликт источников, запрос на скидку, гарантию, возврат, срок или действие от имени компании.

Как AI-Ready использует RAG Quality

В AI-Ready RAG Quality связывает Knowledge Pack, Source Map, Answer Policy, Eval Scenarios, RAG Quality Report и Harness.

Это не отдельная «галочка качества». Это способ превратить слабый ответ в работу:

• issue;
• evidence;
• severity;
• owner;
• fix;
• retest;
• decision log.

Так команда понимает не только, что агент ошибся, но и что нужно изменить до следующего пилота.

Куда идти дальше

Если источники ещё не подготовлены, начните с Knowledge Pack.

Если нужно описать источники, откройте Source Map.

Если нужен формат результата проверки, переходите к RAG Quality Report.

Если хотите связать ошибки, решения и повторную проверку, смотрите Harness.

Техническая карта для специалистов

Ниже остаётся более подробная техническая карта: контрольные слои, eval scenarios, report logic, role of Ragas, human review и связи. Она нужна тем, кто хочет использовать страницу как рабочий контекст для проверки RAG-ответов или подготовки LLM-аудита.

AI-ответ может звучать уверенно и всё равно быть неправильным. Для бизнеса опасность не только в самой ошибке, а в том, что команда не видит, откуда ответ взялся, какой источник был использован и где агент должен был остановиться.

Клиент спрашивает про возврат после вскрытия упаковки. В базе есть общее правило возврата, но исключение для категории лежит в другом документе. Агент отвечает быстро. Оператор видит только красивый текст, но не видит: какой документ найден, была ли проверена категория и не пропущено ли исключение.

Уверенный ответ не равен проверенному ответу.

Короткий ответ

RAG Quality — это проверка того, может ли AI-ответ безопасно опираться на вашу базу знаний: нашёл ли агент нужный источник, правильно ли понял правило, не добавил ли обещание от себя и остановился ли там, где данных не хватает.

Практически это вопрос доверия. Можно ли показать, почему агент сказал именно это? Можно ли увидеть, что источник актуален? Можно ли доказать, что спорный случай ушёл человеку, а не превратился в гладкую догадку?

До и после

Почему красивого ответа мало

Хороший текст не доказывает, что источник выбран правильно. Агент может написать аккуратный абзац и при этом использовать похожий фрагмент, устаревший документ или общее правило вместо исключения.

Правильный источник тоже не гарантирует правильное применение. Агент может найти нужный документ, но выбрать не тот пункт, пропустить условие или сказать уверенно там, где нужно уточнить категорию, дату, регион, статус клиента или ограничение продукта.

Высокая метрика не доказывает готовность к запуску. Метрика помогает увидеть, где копать, но не отвечает за бизнес-границы: какие темы рискованные, где нужна проверка владельцем, что нельзя обещать без утверждённого источника и когда вопрос должен уйти человеку.

Поэтому RAG Quality проверяет не только поиск источника и текст ответа. Он проверяет путь от вопроса к источнику и решению: какой источник найден, что разрешено сказать, где данных не хватает и кто отвечает за исправление.

Пример: плохой и хороший ответ

Диагностика качества для такого примера:

• ожидаемый источник: политика возврата с категорией товара, исключениями и датой проверки;
• сбой: агент обещает возврат без проверки категории или источника;
• строка отчёта: тип risky overclaim, серьёзность high, исправление: обновить Answer Policy и добавить тестовый сценарий про вскрытую упаковку;
• владелец: владелец источника или руководитель поддержки;
• повторная проверка: повторить вопрос после обновления Knowledge Pack и тестового сценария.