Transcription
Добрый день. Очень рада всех видеть. А меня зовут Мадина Баймуханова, и сегодня я с темой, а как мы аа на шумных чековых айтем собирали товарные категории. Как это у нас получилось? Это был очень тяжёлый проект. Хотелось бы сегодня поделиться с вами.
А обо мне. У меня 15 лет опыта в аналитике. Я была, а, просто аналитиком, потом инженером данных. И сейчас я Head of Data в компании Солудаataта. А, работала с категоризацией данных, с банковским скорингом, с геоаналитикой, также ещё в аналитике соцсетей тоже поработала.
Аа так. А, и тут у меня вопрос к аудитории. Хотелось бы увидеть, если кто-то уже работал с данными, которые генерирует, э, торговля. Возможно, кто-то в интернет-магазинах работает, аа в маркетплейсах может кто-то работает, кто-то сталкивался. Нет. Прикольно. Спасибо.
А так сегодня адженда такая, что я расскажу о нашей проблеме. А почему она так возникла, а-а, о нашей новой архитектуре, то есть что мы выбрали, какие у нас были технические развилки, в итоге, что у нас получилось, что мы автоматизировали, а где осталась ручная работа.
Так и предметная область такова, что мы работаем с сырыми чековыми данными. Это огромный массив данных. Ежедневно мы получаем порядка 20 гигов а строковых данных. А это миллионы, десятки миллионов строк. И наша задача- их обрабатывать и монетизировать. Да, естественно. А при монетизации клиенты хотят данные получать в чистом, а, структурированном виде. И наша проблема как раз-таки и в том, да, что данные, а, сами чековые строки, они не структурированы. Это шумные данные, где присутствует много языков, русский, казахский, английский. А где-то есть транслитерации, опечатки, пробелы, в общем, всякие варианты аа шума, да. И самая большая проблема в том, что одна товарная позиция может иметь десятки вариантов написания. То есть один и тот же товар может быть написан десятью вариантами. То есть 10 - это как бы не предел, там может быть и сотни, и 200. Вот так.
А и вот это я привожу примеры, да, вариантов написаний и как бы какая это ошибка. То есть могут быть просто ошибки в перестановке слов, это могут быть сокращения слов, казахский язык, английский язык, где-то просто транслитерация, пробелы. То есть это всё связано с тем, что аа чековые строки вводятся в сам кассовый аппарат зачастую вручную. А таких кассовых аппаратов у нас в Казахстане, ну, практически миллион, да? И то есть миллион кассовых аппаратов каждый вводится вручную, поэтому мы получаем вот такое качество данных.
И формулировка задачи такая, что а клиент, когда приходит к нам, чтобы купить данные, а они говорят: "Мы хотим отчёты видеть в виде структурированных строк, да, но у нас на вход вот вот такая строка, а на выходе мы должны выдать каноническую строку". То есть как это у них в справочнике, они хотят отчёты получать в том виде, как у них в справочнике эта строка записана. И а в прошлом году, да, у нас появился именно клиент с таким запросом. И на тот момент мы работали на регулярках, которые были вручную, то есть аналитик вручную сидел, погружался в категорию и собирал эти справочники регулярок для того, чтобы эту категорию собрать. Ну такая вот итерация, да, на этих ручных справочниках, она у нас не сработала. не сработало, потому что это огромные просто справочники. Там может быть 500 плюс брендов, а там может быть 1тыся линеек. И одному аналитику, да, даже какой-то команде аналитиков это очень сложно поддерживать. А потому что а категории, да, в одновременной работе может быть десятки, и как бы это всё очень трудоёмко и держать это всё в фокусе.
Итак, а вопрос, да, к аудитории такой, что вот вы примерно уже поняли, да, задачу, что у нас есть вот такие шумные чековые данные. И ваш вариант, да, чтобы вы выбрали. То есть это регулярки словарей. Второе - это идти в МЛ для решения задачи, либо применять lm. Поднимите, пожалуйста, руки, кто за первый вариант. Так, за первый вариант. Никто не хочет. Хорошо. А кто бы решал эту задачу через МЛ? Спасибо. Классно. И кто применил бы LЛM? Спасибо.
Так, и тут, да, то есть, что мы сделали? Мы решили всё-таки пойти поизучать, кто у нас в Казахстане, к сожалению, очень мало компаний, которые монетизируют чековые данные. Поэтому мы всё-таки пошли, да, вот в мир посмотреть, что делают в других странах. И мы нашли похожие задачи. Они есть у маркетплейсов, а они есть у них при объединении каталогов разных поставщиков. То есть задача такая, да, что у нас есть некое некие сущности, которые на самом деле являются одной сущностью. Вот. И получается наша задача на стыке трёх областей - это reip processing, producting и entity resolution. Из processing мы взяли понимание структуры чека, как его чистить, что это вообще такое, как к нему подходить. И в продакт маching - это как раз-таки, а, сама вот эта область понятие, да, такое, как разные написания товаров или разные отображения товаров, как для них находить каноническую сущность. Но в нашем случае задача гораздо жёстче, потому что у нас нет картинки, у нас нет каталога, у нас есть просто чековая строка, да, там, допустим, fз чай 05. И мы из этого должны понять, что это такое.
А, и в общем-то вот задача, да, ещё раз, чтобы было очень сильно понятно. То есть вот у нас есть разные варианты. Тут может быть сотни вариантов написания одного и того же товара в разных вариантах. Казахский, русский, английский. Плюс с ошибками, пробелами. И нам нужно найти каноническую линейку. И при этом у нас таких сотни тысяч вот таких вот строк.
А вот, в общем, после того, как мы поняли, да, что у нас вот такая задача, мы начали строить пайплайн, а мы пошли в маркетплейсы, как бы благодаря, да, нашему прекрасному рынку Казахстана, что у нас есть несколько маркетплейсов, у нас есть интернет-магазины, где мы смогли спарсить справочники. И а плюс вот именно маркетплейсов в том, что можно спарсить не просто, да, линейку, а можно спарсить ещё элементы справочника. Мы можем спарсить бренд, а, объём, вкусы, а, в общем, любые атрибуты, которые присутствуют в каталоге, можем их спарсить и обогатить наши данные.
Так, после этого мы изучили структуру, а, продуктовой линейки, что она из себя представляет. Получается, да, что в основном это у нас бренд, цвет, возможно, вкус, а где-то там ещё какие-то атрибуты присутствуют, объём. И есть шумовые слова. То есть шумовые слова для нас не имеют смысла именно при поиске линейки. Так.
И дальше мы пересмотрели логику атрибутов. Мы разделили их на жёсткие, мягкие. Жёсткие атрибуты - это те, которые нам необходимы для матчинга с линейкой. Это бренд ксайз и часть форм факторов, допустим, а в категории средств для мойки посуды, да, есть жидкости, есть таблетки, есть порошки, есть там, возможно, какие-то жидкие капсулы. То есть вот такой форумфактор, он жёстко, а, нам указывает, что это какая-то конкретная линейка. А после, а, мягкие атрибуты - это вот вкус, цвет, запах. То есть они мягко влияют и у них, а, вес при матчинге гораздо ниже. Так, и это пример, да, определения атрибутов. То есть вот бренд ксайз такой-то, вкус и цветы такие-то. И вот, да, получается, жёсткие атрибуты влияют сильно на матчинг, то есть у них вес выше и мягкое влияние у мягких атрибутов.
А после этого мы написали блок кода. которые из спарсиных справочников, формирует уже на нашей стороне справочник брендов, а, мягких атрибутов и шумовых слов. И также вот этот блок кода обогащает уже из нашей базы чековых данных вот эти вот справочники. И эта работа производится итеративно при работе с категорией, при помощи ручной работы ассесора, справочников. То есть, а, мы, получается, спарсили аа вот это вот всё, создали справочники, прогнали код и обогатили вот эти справочники. Ассессор это провалидировал. И вот этот процесс мы делаем несколько раз достижения а качества. А у клиентов обычно каче требования качества очень высокие. Они хотят видеть, а, 95% строк, чтобы имели каноническую линейку.
И тут у нас пример, а, справочников, допустим, бренда. То есть мы спарсили из маркетплейсов вот эти канонические названия и из нашей базы обогатили, что вот такие вот варианты ещё существуют в нашей базе. То же самое с мягкими атрибутами, тоже получается каноническое написание и плюс варианты из нашей базы.
И вот такой процесс получается. Мы идём с двух сторон, со стороны айтем и со стороны канонической линейки. А понимаем, да, что в item есть категория. И после этого мы можем идти в а матчинг с линейкой. А если вemм есть бренд, то, в общем, мы идём дальше, а, определяем на основе наших же справочников, а, атрибуты. И происходит, в общем-то, матчинг, да, с использованием. Дополнительно мы используем каса similarity. А это как бы дополнительные такие метрики для нас, потому что есть а вот эти вот лишние пробелы, между слов, чтобы их учитывать при матчинге, мы их используем. И в общем-то вот здесь пример этого матчинга, как это произошло. То есть вот у нас есть бренд, а у нас есть категория, у нас есть бренд, у нас есть вкусы, у нас есть объём. И вот нашли мы каноническую линейку.
Так, итоговый пайплайн, который у нас получился, то есть мы начинаем от сырой, а чековой строки. Для неё а определяется категория через ML-модель, которая как бы это другая тема, но тем не менее этот процесс есть. А дальше у нас, а, частично автоматизирован процесс вот этих мягких и жёстких атрибутов. Мы добавляем сюда линейки из маркетплейсов, делаем матчинг и дальше ассер вручную валидирует. То есть у нас автоматизированы процессы категоризации, а, парсинга линеек из маркетплейсов в составления справочников. А сам матчинг автоматизирован. А вот эти вот процесс а составления справочников аа из маркетплейсов и обогащения нашими данными, он частично автоматизирован. И дальше вот у нас ручная валидация.
Так, и в общем-то сравнение, да? А наш самый первый подход изначальный, он был м очень сильно зависел от ручной работы аналитика. То есть, чем больше человек потратил времени на категорию, тем категория была лучше. А, ну, конечно, во-первых, а, работа аналитика, да, то есть аналитиков не так много, а-а, поэтому мы не можем, да, вот столько времени уделять одной категории. Нам надо брать в работу десятки категорий, поэтому этот подход нам не подошёл. Мы попробовалим, а, но поняли, что на локальных категориях, там, где присутствуют плюс казахские слова, там, где есть очень большие сокращения, очень большие ошибки, а в этом случае а качество сопоставления с линейкой очень нестабильное. И мы поняли, да, что при нестабильном качестве где-то, допустим, если мы получаем 60% канонических линеек, где-то мы получаем там 80, где-то 90, то этот процесс надо всё-таки дальше дополнять. Но дополнение - это тоже, да, дополнительная работа. Мы не стали опять же останавливаться на ЛМ, поэтому сделали свой подход, который я вам показала, и мы получили стабильное качество, да, это 90-95% а чековых позиций имеют канонические линейки и автоматизировали большую часть работы. А, то есть у нас время работы над категории сократилось с двух недель до одной недели. Это произошло за счёт вот этой автоматической автоматического парсинга справочников. А доля ручной работы аналитика, да, если в начале он полностью должен был погружаться в категорию, то сейчас а нам достаточно ассор не целого, да, полноценного аналитика, а тут достаточен ассор и а 100% топовых айта мы покрыли каноническими линейками.
Так, и у меня всё. Тут ссылки на мои соцсети. И вот в QR-коде есть, я пишу статьи о кейсах, как использовать чековые данные. Можете тут почитать. Спасибо. Я думаю, очень интересный доклад. Я, как сам аналитик, это дало мне очень много идей. А, и давайте перейдём к нашим вопросам. Итак, первый вопрос от Александры. А, не забанили ли ваши парры, которые вы получали от маркетплейсов? Ничто >> не запретили или не Как сказать? >> А где прочитать? А, ну, на самом деле, маркетплейсы постоянно меняют, да, свои защиты, и мы тоже постоянно под них подстраиваемся. Ну, как бы реальность жизни такова. >> И >> хорошо. Вот следующий вопрос тоже от Александры. >> Как фиксировали набор жёстких атрибутов вручную или разметкой? ручной раз >> как фиксировали, >> да, как фиксировали наборских атрибутов ручной разметку. >> Я не совсем поняла, что значит фиксировали, >> то есть как определяли, как категоризировали вот это всё именно. >> А как мы выбирали жёсткие атрибуты? Ну, жёсткие атрибуты очень жёстко влияют на выбор линейки. То есть, если у нас нет категорий, если у нас нет бренда, если у нас нет объёма, то мы, в принципе, не можем определить линейку. То есть такой айтем без этих атрибутов мы никуда не относим, поэтому они жёсткие. >> Спасибо большое. И у нас следующий вопрос от Рахата. Как вы боролись с появлением новых брендов и грязных айтемов? А, ну, работа у нас постоянно, да, итеративная, то есть раз в месяц мы обновляем наши справочники из маркетплейсов. То есть парсинг происходит каждый месяц. И как бы результаты парсинга мы тоже у себя ра как бы расшиваем, да, какие новые айтемы появились, какие новые бренды. И это вот это дополнение происходит тоже постоянно. >> Угу. И продолжение этого вопроса это происходит автоматически или ручное? Это больше >> автоматически, да. Ну, полуавтоматически, поскольку там есть работа ассосра правочника, он вручную, а, делает одобрение, да? То есть код ему выдаёт: "Вот это я тебе предлагаю обновить". И он говорит: "Да или нет". >> Отлично. >> Хорошо. Так, следующий вопрос. Что происходит с данными, которые удалось по итогу сопоставить со справочными данными? А, >> не удалось сопоставить. >> А, не удалось. >> Аа, ну, мы их не используем. Ну, это, знаете, такие случаи, допустим, аа вот средства для мытья посуды, наверное, все знают, да, фейри. Вот там, а, бывает просто строчка фейри, четыре буквы. То есть вот такую строчку, да, мы, конечно, скорее всего это фейри, да, но мы не можем стопроцентно говорить, что это именно средство для мытья посуды, и мы их не используем, они как бы не применяются, но тем не менее присутствуют в базе. >> Всё, спасибо. И следующий вопрос. Ручной ассор не может ли быть заменён с помощью ML и векторных векторных безданных для справочников и через рак отдавать каноничную каноническую строку, чтобы избежать ручной валидации. А мы всё-таки сознательно оставили ручную валидацию, потому что нас очень сильно а-а как бы требования клиенты таковы, что мы должны чуть ли не 100%, они хотят стопроцентнуе, а частоту данных. А, естественно, стопроцентную частоту данных не может дать ни, ним. Они на это не способны, к сожалению. Вот, собственно, у меня тут лозунг на футболке, да, что не подходят для всех задач. Вот. >> Да, давайте похлопаем. Прямо такой дефис. И следующий вопрос. >> Так, следующий вопрос. Расскажите, какие инструменты ML и LLM использую? >> Как? Как ещё? Ну, вы сказали, что вы не используете. Правильно. >> Аll мы не используем. В данном кейсе он не используется совсем. >> Угу. >> Всё хорошо. Да. А как вы выбирали трешхолд для косинусной близости? >> А так что значит >> вот получается, как вы считали близость товаров к друг другу для категори? >> Ну, на самом деле, это дополнительная метрика с очень, э, небольшим весом, да. Он используется для хвостовых айтем, где вот эти вот присутствуют лишние пробелы или какие-то опечатки. Таких айтем, на самом деле, не так много. Да, они есть, конечно, но их не так много. Поэтому эти метрики у нас есть. И там вес, да, 0,7. Вот 0,7 мы уже их как бы считаем значимым. Вот так. >> Угу. >> Да. Ещё один вопрос от Александра. Александра, где вы не были? Вообще молодцы. Столько классных вопросов. Как работаете со сложными кейсами, тем самыми 5% против и 95% успеха? Ориентируетесь на какую-то степень уверенности? >> Ну вот в этих 5% как раз-таки случаи, да, где вот одно слово там фери фери 450, а либо там вот просто название бренда, где которые мы не можем никуда использовать. Вот в 5% - это вот такие случаи. Хорошо. Так, следующий вопрос от Дианы. Можете рассказать, как вы справляетесь с теми товарами, значениями, с которыми всё-таки сопоставление не удалось? Происходит это вручную или есть алгоритмы? >> Да, это вот в том же блоке, да, который мм дообогащает, получается, линейки, которые мы спарсили, он дообогащает их из чековых данных. А вот в этом случае у нас есть там, да, там отдельный, как результат он выдаёт справочник, строки, которые не удалось никуда смачить, а их аналитик, да, вручную просматривает и дальше решает, да, что с этим делать. То есть это уже такой ручной, полуручной процесс. >> Угу. Всё, спасибо, Мадина. >> Спасибо. Ah.