Она позволяет сопоставлять товары поставщиков с базой-эталоном, где содержатся приведенные к единому виду объекты номенклатуры, к которым привязаны данные из внешних источников в результате синдикации. Она обладает высокой пропускной способностью и экономит десятки часов на выполнение задач ручного сопоставления.
В чем была задача
Потребность в создании Golden Record встает перед любой системой обработки данных. Если два и более источника хранят информацию об одной сущности, они гарантированно разойдутся. Точнее уже разошлись. Банки сталкиваются с этим, когда объединяют клиентские профили из разных систем. Маркетплейсы, когда сотни продавцов предлагают один и тот же товар под разными названиями. Медицина, когда история болезни пациента раскидана по нескольким больничным базам. В нашем случае источники данных — каталоги автозапчастей с десятками тысяч объектов номенклатуры.
Данные о номенклатуре поступают из десятков источников — и каждый называет одно и то же по-разному. Один и тот же тормозной диск может называться «диск торм. LADA», «brake disc VAZ» или «тормозной диск 2110».
Раньше менеджеры сопоставляли артикулы вручную через Яндекс Таблицы. При миллионах объектов номенклатуры и десятках поставщиков это не масштабируется — ни по скорости, ни по качеству. Тут и возникает потребность в качественном дата-продукте.
Что мы хотели:
- Создать эталонную базу автозапчастей, которая пополняется в полуавтоматическом режиме.
- Иметь интеллектуальную систему сопоставления с возможностью итеративной доработки и улучшения.
- Исключить попадание в базу-эталон непроверенной информации.
- Обрабатывать до миллиона задач в час.
- Уметь численно оценивать эффективность системы.
Эталонная база автозапчастей, сервис для сопоставления, мониторинг и наблюдаемость. Очертания задачи понятны, дальше дело за конкретикой.
Архитектура:
На схеме изображено два контура — быстрый и медленный. В быстром стриминговый движок сразу находит сопоставление в базе-эталоне и отдает клиенту ID товара. В медленном — задача на сопоставление уходит в очередь к MDM-менеджерам на ручное уточнение. Теперь детальнее.
В сердце системы находится Flink — фреймворк для потоковой обработки данных. Он принимает из очереди сообщений задачи на синдикацию и пытается найти соответствие в базе-эталоне. Перед поиском входные данные претерпевают цепочку детерминированных преобразований к эталонному виду. Эти преобразования — набор наших эвристик, которые были сформулированы при анализе структуры данных.
Примеры:
- Приведение к нижнему регистру и удаление пунктуации.
- Схлопывание пробелов: KING TONY и KINGTONY — одно и то же.
- Устранение гомоглифов: кириллические и латинские буквы, неотличимые визуально, унифицируются по написанию.
- Очистка бренда от юридических форм (ООО, GmbH), географических приставок и шумовых слов.
- Канонизация синонимов: разные написания одного бренда приводятся к единому эталонному виду.
Записи, для которых не найдено соответствие, должны быть каким-то образом обработаны. С этой целью на Kotlin реализован бэкенд для ручной обработки. MDM-менеджеры в UI могут просмотреть такие записи и совершить с ними действия: отклонить, назначить соответствие среди существующей номенклатуры или создать новую.
Все решения, алгоритмические и ручные, сохраняются в SCD2-таблице. Таким образом мы расширяем и дополняем знание системы о домене. Эта таблица служит кэшем для повторной обработки уже решенных задач, а также источником данных для обучения ML-алгоритмов.
Узкое место системы — необходимость human in the loop, человеческого решения касательно записей, которым не удалось найти соответствие в базе-эталоне. При нечетком сопоставлении и использовании ML-алгоритмов мы вынуждены принимать взвешенное и компромиссное решение между скоростью и эффективностью. Что лучше: массово выдать решение для миллиона объектов с вероятностью ошибиться или же прогнать неопознанные 5% через ручной процесс. Ответ зависит от конкретного домена и требований. В нашем случае ставка сделана на детерминированный подход: справочник эталонов обеспечивает воспроизводимость — один и тот же вход всегда дает один и тот же ответ, который можно проверить и объяснить. ML при этом не уходит на второй план: каждое решение менеджера пополняет обучающую выборку, и в перспективе модель возьмет на себя большую часть этой работы. Вывод прост: если мы не уверены на 100%, то зовем на помощь человека.
Конечно, такую систему нужно мониторить и уметь оценивать ее эффективность. Для этого мы используем два инструмента: Grafana и DWH. Первый — стандарт индустрии для Observability, а с помощью второго строятся аналитические дашборды на бизнес-метрики, которые позволяют продактам и стейкхолдерам проекта принимать решения о дальнейшем развитии продукта.
Система позволяет нам обрабатывать большие объемы данных в режиме реального времени, подключая все больше внешних клиентов для создания Golden Record. При этом чем больше данных, тем выше эффективность. Бизнес-правила уточняются, эвристики улучшаются, а принятые решения служат источником данных для обучения новых версий алгоритма. Улучшение работы с ML и внедрение LLM — ближайшие шаги для повышения качества системы.
Результаты
За последние 30 дней пайплайн обработал 6,6 млн событий, из которых 972 тыс. уникальных SKU — остальное приходится на повторные запросы от пользователей. Пропускная способность — 14,9 сообщений в секунду (около 54 тыс. в час). 76% всех SKU сопоставляются автоматически, без участия оператора.
За все время работы система накопила 1,29 млн успешных совпадений (MATCH), 449 тыс. записей без совпадения (NO_MATCH) и 250 тыс. записей без бренда (NO_BRAND). Ручная обработка подключается только там, где алгоритм не уверен: за все время операторы обработали вручную порядка 43 тыс. SKU — создали новые эталонные записи (20 тыс.), сопоставили с существующим эталоном (7,9 тыс.) или отклонили задачи (15 тыс.). В среднем ручное решение занимает пять дней от попадания в очередь до его принятия.
Каждое автоматическое совпадение — это работа, которую не пришлось делать руками. Автоматический матчинг 1,29 млн позиций сэкономил около 3,6 тыс. часов ручной работы операторов, или около 3,6 млн руб. Расчет строился из стоимости часа, равного 1000 руб., и консервативной оценки времени на принятие ручного решения в 10 секунд — при более реалистичном тайминге экономия кратно выше.
От прототипа на двух Jupyter Notebooks до полноценного сервиса с вычислительным движком, бэкендом, фронтендом и большим бэклогом понадобилось полгода. Были пересмотрены все компоненты, и, если бы Тезей принимал этот корабль после всех работ, он бы его не узнал — вопреки расхожему философскому парадоксу.