Артикулы и поиск: как находить товар по разным написаниям

Редакция Romanov Lab · Опубликовано 13 октября 2026

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

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

Сначала выясните, чей это артикул

У товара могут быть внутренний SKU магазина, код производителя, артикул поставщика, штрихкод и старое обозначение. Хранить их в одном текстовом поле с запятыми неудобно: невозможно указать владельца кода, период действия или причину замены.

Используйте отдельные записи: тип идентификатора, владелец или бренд, исходное значение, нормализованный ключ, идентификатор товара и происхождение записи. Внутренний ключ базы данных не заменяет пользовательский артикул. Код должен храниться строкой: превращение 0012 в число 12 уничтожит ведущие нули.

Уникальность кода тоже имеет область действия. Если два производителя используют обозначение 1200, запрос без бренда должен показать оба совпадения с ясными подписями. Автоматический переход к первому результату здесь создаёт ошибку покупки.

Нормализация должна быть обратимой на уровне данных

Исходную строку сохраняют неизменной для отображения и сверки с документами. Рядом строят поисковые ключи. Тогда можно изменить правила индексации и пересобрать индекс без восстановления утраченных символов.

Универсального правила «удалить всё, кроме букв и цифр» недостаточно. Дефис у одного производителя декоративный, а у другого отделяет размер или исполнение. Сначала выгрузите реальные коды и найдите пары, которые сольются после предполагаемого преобразования.

MDN описывает формы нормализации Unicode, включая NFKC. Совместимая нормализация может быть полезна для поиска, но способна менять представление символов. Она не переводит кириллицу в латиницу и не подтверждает, что похожие буквы принадлежат одному артикулу.

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

Исходный код: AB-0012
Точный ключ: AB-0012
Дополнительный ключ: AB0012
Область действия: бренд North / коды крепежа
Версия правила: article-key-v2

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

Задайте ступени поиска

1. Точное совпадение исходного кода в разрешённой области.
2. Точное совпадение по безопасно нормализованному ключу.
3. Совпадение с подтверждённым прежним кодом или альтернативным написанием.
4. Предположение об опечатке с явной подписью и возможностью вернуться к исходному запросу.
5. Аналоги и совместимые замены в отдельной группе.

Артикул AB-0012 и артикул AB-0013 отличаются одним символом, но могут обозначать разные детали. Нечёткий поиск помогает предложить вариант, однако не даёт права объявить его точным совпадением. Кнопка покупки должна оставаться связанной с выбранной карточкой, а не с автоматически исправленным запросом.

Старый код и аналог также различаются. Если производитель переименовал тот же товар, можно записать подтверждённый алиас. Если новый продукт заменяет старый с ограничениями, нужна связь замены и пояснение отличий. Вторая ситуация не должна маскироваться поисковым синонимом.

Учебный разбор коллизии

В каталоге есть North AB-0012, North AB0012 и South AB-0012. Первые две позиции оказались разными исполнениями. После удаления дефиса обе получили AB0012; третья совпала по тексту, но относится к другому бренду.

Правильное исправление начинается с отключения опасного правила для North, а не с назначения одной позиции «главной». Исходные коды остаются доступны. Для запроса AB0012 первым идёт точное совпадение North AB0012, затем можно показать похожие коды. Для запроса AB 0012 выдача сообщает о нескольких подходящих обозначениях и предлагает уточнить бренд и исполнение.

Если все три результата отправить в один товар, ошибка выйдет за пределы поиска: импорт начнёт перезаписывать характеристики, остатки попадут не к тому исполнению, а корзина сохранит неверный идентификатор. Поэтому нормализованный поисковый ключ не используют как единственный ключ импорта или заказа.

Подготовьте контрольный набор до изменения индекса

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

Отдельно проверьте пустой запрос, очень длинную строку и вставку с переводом строки. Запрос должен оставаться данными: его безопасно отображают в интерфейсе и передают поисковому движку через предусмотренный API. Не превращайте пользовательский ввод в выражение языка запросов без контроля.

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

Как понять, что задача решена

• Все подтверждённые написания находят нужный товар, а точный артикул не уступает похожему названию.
• Ни одна известная коллизия не приводит к молчаливому выбору чужого исполнения.
• В карточке и заказе виден исходный код производителя.
• Менеджер может объяснить, почему сработал алиас и откуда он взялся.
• После импорта и полного переиндексирования контрольный набор проходит повторно.

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