Когда RAG должен сказать «в документах нет ответа»
База знаний не обязана отвечать на каждый вопрос. Если инструкция не описывает доставку за границу, правдоподобный ответ из общих знаний может навредить больше честного уточнения. Для корпоративного помощника определите границу: когда разрешены внешние знания, когда нужен только корпус и как выглядит полезный отказ.
Порог сходства сам по себе не определяет наличие ответа. Близкая статья может обсуждать ту же тему, но не содержать запрошенного условия.
Сравнение состояний
Данные ниже вымышлены: они показывают способ разбора, а не измерения действующего сервиса.
| Вопрос | Найденный фрагмент | Правильное действие |
|---|---|---|
| Срок доставки по городу | Срок указан прямо | Ответить со ссылкой |
| Доставка за границу | Только условия по городу | Сообщить об отсутствии условия |
| Адрес ближайшего пункта | Несколько городов без выбранного | Уточнить город |
Отсутствие основания и неоднозначность запроса требуют разных ответов. В первом случае полезно объяснить, что именно не найдено. Во втором — задать один вопрос, который позволит выбрать нужный документ. Фраза «не знаю» без следующего шага часто ухудшает пользовательский опыт без повышения надёжности.
Не обучайте проверку только на совершенно посторонних вопросах. Самые опасные примеры тематически близки к корпусу: модель легко достраивает отсутствующее правило по знакомому шаблону.
Практические проверки
Подготовьте три группы вопросов: ответимые, близкие без ответа и неоднозначные. Для каждой заранее определите ожидаемое действие, а не эталонную красивую формулировку. Сравните долю необоснованных ответов и долю лишних отказов.
В логах сохраняйте причины отказа: пустой поиск, недостаточное основание, конфликт версий либо недоступность источника. Если все причины свалить в один показатель, команда будет лечить поиск настройкой промпта. Проверьте, что отказ не раскрывает название закрытого документа и не предлагает пользователю получить чужие полномочия.
Ограничения и риски
В медицинских, финансовых и юридических сценариях границы ответа зависят от риска и процесса проверки. Учебная схема не задаёт универсальную политику. Важные исключения согласуют с владельцем продукта и предметной области.
Поисковая выдача предоставляет кандидатов, а решение о достаточности оснований остаётся отдельным этапом RAG. Официальная документация помогает уточнить технический механизм; предложенный диагностический протокол — наш учебный пример.
Если хотите связать этот разбор с системной практикой, посмотрите программу Vector DB & RAG Developer на Latorn: она охватывает векторный поиск с фильтрами, гибридную выдачу и оценку RAG. Перед оплатой сопоставьте требования курса со своим опытом и задачей проекта.
Следующий шаг: RAG на практике: документы, поиск и качество ответов. По смежным вопросам: Чанки в RAG теряют заголовки: как сохранить смысл раздела, Права доступа в RAG: почему фильтра после поиска недостаточно.
