Фильтр по массиву в RAG: почему условия могут совпасть у разных элементов

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

Такая ошибка встречается и в базе знаний: регион и тип лицензии могут относиться к разным пунктам одного документа. Перед написанием фильтра сформулируйте, к какой единице относится сочетание условий.

Разбор на примере

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

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

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

Порядок диагностики

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

При проектировании схемы храните связанные признаки рядом. Если данные развёрнуты в отдельные точки, сохраняйте общий идентификатор варианта, а не только товара. Сравнивайте фактический запрос к хранилищу с человеческим описанием условия. Это простой способ поймать ошибки логики, скрытые за длинным JSON.

Что этот способ не гарантирует

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

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

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

Следующий шаг: RAG на практике: документы, поиск и качество ответов. По смежным вопросам: Права доступа в RAG: почему фильтра после поиска недостаточно, Чанки в RAG теряют заголовки: как сохранить смысл раздела.