RAG не понимает «а для второго тарифа?»: как проверять уточняющие вопросы

Короткий вопрос зависит от предыдущего сообщения. Поиск строки «а для второго?» сам по себе почти бесполезен: в нём нет ни объекта, ни признака. Но передавать всю историю в поиск тоже неудобно: старые темы и лишние названия смешиваются с текущим намерением.

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

Учебная ситуация

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

Правильное восстановление третьего вопроса использует последнее релевантное сравнение. Однако слово «второй» может быть неоднозначным после длинного разговора. В таком случае уточнение безопаснее уверенного выбора. Не оценивайте этот шаг только по грамматике полученного предложения.

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

Проверка перед внедрением

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

В диагностике храните исходную реплику, использованные сообщения истории и восстановленный запрос. Это помогает поймать перенос устаревших ограничений. Добавьте случай, когда пользователь говорит «нет, я про другой продукт»: предыдущий объект должен перестать управлять поиском. Не отправляйте ненужную личную информацию из истории в сервис эмбеддингов.

Границы применимости

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

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

Если хотите связать этот разбор с системной практикой, посмотрите программу Vector DB & RAG Developer на Latorn: она охватывает векторный поиск с фильтрами, гибридную выдачу и оценку RAG. Перед оплатой сопоставьте требования курса со своим опытом и задачей проекта.

Следующий шаг: RAG на практике: документы, поиск и качество ответов. По смежным вопросам: Как готовить таблицы для RAG, чтобы модель не путала столбцы, В RAG есть ссылки, но ответ не подтверждён: как проверять цитаты.