Почему векторный поиск путает артикулы и номера ошибок
Запрос «ошибка ZX-104» имеет точный идентификатор. Семантическая модель может найти общую статью о сбое запуска и пропустить нужную строку справочника. Это не обязательно проблема качества эмбеддингов: похожесть смысла и точное совпадение кодов отвечают на разные вопросы.
Для каталога, журналов ошибок и внутренних номеров заявок полезно выделять точные признаки запроса. При этом нельзя превращать любой набор цифр в обязательный фильтр: число может обозначать срок или сумму.
Учебная ситуация
Данные ниже вымышлены: они показывают способ разбора, а не измерения действующего сервиса.
| Запрос | Документ | Точное совпадение | Полезность |
|---|---|---|---|
| Ошибка ZX-104 | ZX-104: перегрев | Есть | Нужный код |
| Ошибка ZX-104 | ZX-140: сеть | Нет | Похожий формат |
| Ошибка ZX-104 | Сбои устройства | Нет | Общий контекст |
В примере точный поиск идентификатора должен сохранить правильную статью среди кандидатов. Семантическая ветка может добавить объяснение человеческой формулировки «устройство перегрелось». Смешивание веток оценивают по результатам, а не по убеждению, что один способ всегда лучше.
Нормализация должна учитывать дефисы, регистр и ведущие нули. Если «AB-01» и «AB-1» обозначают разные товары, удаление нулей создаст ошибку ещё до ранжирования.
Проверка перед внедрением
Соберите небольшой набор запросов трёх типов: чистый код, код с описанием, описание без кода. Отдельно добавьте похожие номера, опечатки и несуществующий код. Для каждого определите допустимое поведение: точная статья, уточнение либо явное отсутствие результата.
Сравните лексическую, векторную и комбинированную выдачу при одинаковом количестве переданных фрагментов. Сохраните ранги правильной статьи и причину её отбора. Не разрешайте генератору исправлять неизвестный артикул молча: пользователь должен видеть, что поиск нашёл похожий, а не исходный номер.
Границы применимости
Лексическое совпадение тоже не гарантирует актуальный ответ: старый справочник может содержать точный код. Проверка версии, прав и применимости документа нужна после любого способа поиска.
Многоэтапные запросы Qdrant позволяют объединять разные наборы кандидатов; правило распознавания кодов задаётся отдельно. Официальная документация помогает уточнить технический механизм; предложенный диагностический протокол — наш учебный пример.
Если хотите связать этот разбор с системной практикой, посмотрите программу Vector DB & RAG Developer на Latorn: она охватывает векторный поиск с фильтрами, гибридную выдачу и оценку RAG. Перед оплатой сопоставьте требования курса со своим опытом и задачей проекта.
Следующий шаг: RAG на практике: документы, поиск и качество ответов. По смежным вопросам: RAG путает проект и компанию с одинаковым названием: как различить сущности, Права доступа в RAG: почему фильтра после поиска недостаточно.
