Как мы построили систему матчинга товаров с помощью трансформеров и LLM

Привет! Мы — команда ML-разработчиков «Магнит Фудтех», входящей в состав бизнес-группы Магнит OMNI. 

Меня зовут Виктория Костерина, я тимлид команды. В этой статье мы вместе с моим коллегой, ML-инженером Богданом Тонанайским, рассказываем, как создавали систему автоматического сопоставления товаров между ассортиментом конкурентов и товарами «Магнита».

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

Сопоставить несопоставимое

В магазинах товары могут различаться форматами упаковки, объемом, весом и множеством других факторов. В офлайн-формате продукты стоят на полках, и их можно потрогать. В онлайне товары представлены карточками с текстовыми описаниями и картинками. Однако в базах данных разных ритейлеров даже одни и те же товары могут называться по-разному — как в примере ниже:

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

У нас в «Магните» стояла именно эта задача — автоматически сопоставлять товары из наших каталогов и каталогов конкурентов. Сотни тысяч SKU, разные форматы, опечатки, особенности описаний, — такое практически невозможно свести к ручной разметке. Более того, даже у одних и тех же ритейлеров названия могут меняться со временем.

Наивный путь

На первом этапе нам были доступны только текстовые заголовки товарных карточек. Идея была простая: что, если взять строковое расстояние Левенштейна, и просто искать ближайшие названия? В теории красиво, на практике — провал. Даже очень похожие строки могли означать совершенно разные товары. HitRate@10 оказался около 10%, а простые преобразования вроде приведения к нижнему регистру, стемминга и лемматизации хоть и улучшают метрику почти вдвое, но не дают пригодных результатов. Ниже представлено распределение коэффициента схожести текстов (fuzz ratio), где 100 соответствует полному совпадению.

Отсюда вывод: нормализация текстов важна, но не сделает из строковых методов пригодную систему.

Эмбеддинги приходят на помощь

После строковых методов мы обратились к эмбеддингам: векторизовали названия товаров языковыми моделями и брали топ по косинусной близости. Сырые LaBSE и ruBERT на наших данных сразу подтянули качество, HitRate@10 увеличился более чем в 2 раза. Построив распределени�� косинусной близости топового матча для успешных (матч в топ-10 результатов) и неуспешных (матч дальше) мы увидели следующую картину:

Уже на этих распределениях видно, что при определенном пороге отсечения по метрике (например, 0,995) можно увеличить качество сопоставленных пар при достаточно неплохом покрытии. А если «раздвинуть» эти два распределения, то это существенно повысит процент совпадений и устойчивость результатов. 

Картинка иллюстрирует общую идею. У нас появилась надежда, что fine-tuning даст серьёзный прирост.

Не только fine-tuning

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

Что это такое? Взглянув на самые длинные названия, мы увидели, что они содержат повторяющиеся подстроки, удаление которых улучшило картину:

Можно обучать

Мы выбрали компактную модель rubert-tiny2: баланс скорости и качества оказался оптимальным. Чтобы натренировать её на наших данных, применили contrastive learning с hard negatives. То есть мы специально скармливали парные примеры очень похожих, но разных товаров. В итоге модель научилась разносить и не путать такие пары, как, например, «Pepsi 0,5 л» и «Pepsi Max 0,5 л».

Эта дообученная модель дала ещё +25% к HitRate. Особенно сильно улучшилась точность на пограничных случаях.

LLM — фильтр последней надежды

Финальный пайплайн получился таким:

1. Берём названия товаров конкурентов и «Магнита».

2. Считаем эмбеддинги, ищем ближайших соседей, формируем топ из 5-10 кандидатов.

3. Фильтруем по косинусному сходству.

4. Самые спорные пары отправляем в LLM (DeepSeek, Qwen, YandexGPT).

LLM возвращает JSON: матч/частичный/нематч + уверенность + короткое объяснение. Так мы автоматизировали валидацию и разгр��зили аналитиков.

Что мы поняли:

1. Нормализация данных обязательна. Без неё даже простейшие методы работают плохо.

2. Компактные трансформеры могут быть очень мощными, если их правильно дообучить.

3. LLM отлично дополняют пайплайн, выступая последним фильтром.

Куда двигаться дальше

Сейчас мы хотим попробовать использовать LLM не только как фильтр, но и как генератор матчей и авторазметки. А ещё планируем внедрить semi-supervised обучение с обратной связью от аналитиков и интегрировать результаты в систему ценообразования.

История продолжается :)