Почему «похоже» — недостаточно

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

Смысловые векторы хорошо связывают разные формулировки одной потребности. Однако буквенно-цифровые коды, единицы измерения и обозначения модификаций могут быть для них непрозрачны. Лексический поиск по словам возвращает документы с совпадающими терминами. А точный фильтр по полю артикула отвечает на ещё более строгий вопрос: существует ли именно такой код. В документации Qdrant эти задачи разделены: keyword-поля предназначены для точных значений, текстовый поиск — для слов и фраз, гибридный запрос объединяет смысловую и лексическую выдачу. Это описание возможностей инструмента, не гарантия качества конкретного каталога.

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

Три ветки одного поиска

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

Затем маршрут выглядит так:

  • Точное совпадение по индексированному полю `sku` или таблице соответствия кодов. Система возвращает карточку товара, версию каталога и статус доступности. Смысловая модель не вправе заменять найденный код другим.
  • Если точного совпадения нет, лексический поиск ищет маркировку в описаниях и документах, а смысловой — назначение и синонимы. Их результаты объединяют только как список кандидатов, помеченный «требует проверки».
  • Если запрос описательный, без кода, смысловая и лексическая ветки работают вместе с фильтрами по категории и доступу. Затем независимые технические правила проверяют обязательные характеристики и совместимость.

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

Где уместен гибридный слой

В гибридной ветке одна карточка может иметь плотный вектор для смыслового описания и разреженное представление для слов. Запрос делает две предварительные выборки и объединяет позиции кандидатов. Qdrant описывает такой механизм в Query API; среди способов слияния есть reciprocal rank fusion, или RRF. Он использует места документов в двух списках, а не напрямую складывает несопоставимые оценки плотной модели и BM25. Это полезная отправная точка, но итоговый порядок нужно проверять на собственных запросах.

Важно ограничение: если нужный товар отсутствует в обеих предварительных выборках, слияние его не создаст. Если точный артикул уже известен, нет смысла заставлять RRF «угадывать» его среди похожих. Гибридная ветка раскрывает неясный естественный запрос, например «уплотнение для пищевого насоса с высокой температурой», а не отменяет точный поиск и инженерные ограничения. Популярный товар тоже не обязан быть совместимым.

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

Подготовка данных важнее хитрого ранжирования

Сначала стоит договориться о канонической товарной карточке. Минимум: устойчивый внутренний ID, артикулы производителя и поставщика, версия и дата источника, название, категория, измеримые характеристики с единицами, совместимость, статус жизненного цикла и ссылка на первичный документ. Устаревшие цены, остатки и условия продажи лучше подгружать из действующей ERP при показе результата, а не зашивать в редко обновляемый вектор. Разные права доступа дилеров и филиалов должны применяться до выдачи, а не скрываться промптом.

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

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

Пилот, который может опровергнуть идею

Начните с 50–100 обезличенных реальных запросов, если такой объём есть. Разделите их хотя бы на четыре группы: точный код, код с опечаткой, описание без кода и запрос на замену или аналог. Для каждого фиксируйте правильный товар либо честный ответ «нужно уточнение», а также обязательные признаки совместимости. Это не обучающая выборка для обещанного результата, а проверочный набор. Его размечают владелец каталога и технический специалист; спорные случаи разбирают отдельно.

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

Экономику считайте модельно и с вашими допущениями. Формула для одного принятого результата: стоимость подготовки и обновления карточек, инфраструктуры и рабочего времени проверки, делённая на число подтверждённых полезных ответов. Отдельно оцените цену ошибочной отгрузки, возврата и задержки заказа. Мы не приводим универсальных рублей или процентов ускорения: они зависят от номенклатуры, качества мастер-данных и процесса согласования. На пилоте часто выясняется, что очистка кодов приносит больше пользы, чем ещё одна модель.

Следующий шаг без большой закупки

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

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