Почему векторный поиск путает артикулы и номера ошибок

Запрос «ошибка ZX-104» имеет точный идентификатор. Семантическая модель может найти общую статью о сбое запуска и пропустить нужную строку справочника. Это не обязательно проблема качества эмбеддингов: похожесть смысла и точное совпадение кодов отвечают на разные вопросы.

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

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

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

ЗапросДокументТочное совпадениеПолезность
Ошибка ZX-104ZX-104: перегревЕстьНужный код
Ошибка ZX-104ZX-140: сетьНетПохожий формат
Ошибка ZX-104Сбои устройстваНетОбщий контекст

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

Нормализация должна учитывать дефисы, регистр и ведущие нули. Если «AB-01» и «AB-1» обозначают разные товары, удаление нулей создаст ошибку ещё до ранжирования.

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

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

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

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

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

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

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

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