Comments 35
Думается, можно было приспособить сфинкс или эластик для этого.
Получаем список непригодных товаров-ячеек, потом выбираем из оставшихся ячейку где хранятся товары другой категории, попутно учитывая цвет/размер/тип упаковки.
Да, это самый верный подход, нежели изобретать колесо.
Когда я впервые реализовывал эту тему, то работать приходилось в устаревшем Navision 6.0, где подцепить что-то внешнее можно было только с большими плясками вокруг automation. В тот момент, признаюсь честно, моей квалификации для этого было недостаточно :-) Потом я этот опыт учёл.
Тоже про Lucene подумал. Проблема в том, что стандартный анализатор текста хорош для естественного языка. Для медикаментов скорее всего придется писать свой. Для обслуживается универсального магазина понадобится учитывать больше контекста для построения индекса. Например, хоть медицинской уголь визуально отличается от угля для рисования или гриля, пикер, работающий лишь с наименованием товара, будет промахиваться. Поэтому для исключения человеческого фактора применяют сканер кодов.
я думаю для медикаментов удобнее по действующему веществу или их комбинации и дозировке подбирать а все коммерческие названия запретить
Увы, но это из рубрики "вредные советы", которые и в думу даже пропихнули. Конкретный пример:
препарат "Вальпроевая кислота", стоит очень недорого, уже давно снят с производства в чистом виде
препарат "Депакин" - действующее вещество одно и это тоже вальпроевая кислота, чуть дороже, недавно снят с производства, продавался параллельно следующему
препарат "Депакин Хроно" - то же действующее вещество, ещё дороже, в производстве и в продаже.
Все три предназначены для одного и того же, но действуют с очень разной эффективностью. Разная технология производства. Это как АвтоВАЗ и BMW - и там и там ключевое слово "автомобиль", вроде бы одно и то же, а результат? На память ещё вспоминаю какие-то препараты "Эпитерра" и "Кеппра". Одно действующее вещество (и, через промежуточные лица) один производитель. Первое - дешёвый ширпотреб, эффективность чуть пониже. Второе - дороговатое, эффективность высокая.
я не биолог и не химик но прекрасно понимаю что может быть изменение эффективности препарата от сопутствующих веществ или если препарат высокомолекулярный от его вариаций но иногда бесит что простейший препарат продают под разными названиями и при приличной разнице в цене
Да, маркетинг - беда-бедой! Стандартизировать бы их, как это сделано с молоком (1.5%, 2.5, 3.5 и т. д.) или маслом (82.5, 72.5 и т. д.). Хотя и там дрянь встречается даже в пределах одного производителя. Вот только чиновники за это цепляются и выходит только хуже: "Давайте нам дешёвый вариант, действующее вещество же одно!". У нас так человека уволили, а потом вдруг пациент первый помер (мозгом).
Обычно используют некое "торговое наименование". И препараты с общим названием "Вольтарен" разных дозировок, не кладут в одну ячейку.
А вы сталкивались с таким лайфхаком? Есть товар "Кислородный концентратор XXX YYY", например. Именно так он фигурирует в документах (УПД, прайс-листы и пр.).
На самом же товаре и его упаковке таких слов нет - он импортный и там всё по-английски: "Oxygen Concentrator XXX YYY". Сборщики часто не умеют переводить даже самые примитивные слова, поэтому в их сборочных листах название товара печатается "как есть".
Как вам?
P. S. Есть случаи, когда этот товар официально вообще называется чем-то типа: "Набор для повышения концентрации кислорода".
Предлагаю всем вместе начать исправлять эту ситуацию и приглашаю почитать о том, как на промышленном складе применяли — внезапно! — алгоритм Левенштейна (способ нечёткого сравнения строк).
кликбейт!
Про то как алгоритм собсно на складе применяли - не рассказано.
Ну неправда же. Названа конкретная проблема, которая мешает работе сборщиков? Указано, что WMS теперь сама находит рекомендуемую ячейку для размещения товара, чтобы всем было хорошо?
И, конечно, описан самый сложный момент - почему простой вызов готовой функции не дал нужного эффекта и как для этого был доработан сам алгоритм. Если этого мало, предложите дополнение и я отредактирую статью.
А В вмс о товаре, традиционно ничего не известно кроме названия и массогабарита?
Смотря где. В одной компании, где я работал, было известно много чего (категория, производитель, штрихкоды и куча полезных параметров), в других - да, в основном беда, как вы и описали.
ну и если в одной - то не прощще по параметрам поделить ( или найти их в других конторах?)
Да! Там бы вполне сработала такая схема размещения: в одной ячейке не больше одного товара из одной товарной категории (там это достаточно хороший параметр). Все счастливы.
P. S. Тут, кстати, тоже можно найти минус в алгоритме. Когда поступает новый товар и под него создаётся новая карточка, то заполнить категорию могут уже после размещения. В складах "на потоке" так обычно и есть:
приёмщик заводит карточку товара, указывая лишь те параметры, которые важны ему: название, штрихкод, условия хранения и габариты.
сотрудник отдела закупок заполнит карточку до конца уже позже, занося страну, производителя и прочее.
Я как полный нуб говорю вам огромное спасибо. Намного интереснее изучать алгоритм на конкретных прикладных примерах. Код даже не смотрел, сама идея применения интересна.
Почему нельзя было взять левенштейн, отнесенный к длине строки?
Провёл тест - результат хуже. Если верно понял, то предлагается мерой похожести использовать отношение расстояния Левенштейна к длине одной из строк?
$text_1 = 'Амлодипин-Веро 5мг таб. №30';
$text_2 = 'Амлодипин-Прана 5мг таб. №90';
echo levenshtein_distance($text_1, $text_2) / mb_strlen($text_1)
// Результат: 0.26
$text_1 = 'Амиодарон 50мл/мл конц. д/приг. р-р д/в/в 3мл амп. №10';
$text_2 = 'Амиодарон амп. 50 мл/мл конц. д/приг. р-ра в/в 3 мл №10';
echo levenshtein_distance($text_1, $text_2) / mb_strlen($text_1)
// Результат: 0.31Если перед вызовом функции добавить нормализацию, то результаты ещё более печальные: 0.07 для первой пары и 0.53 для второй, хотя у второй хочется нулевое расстояние.
Браво! От статьи не оторваться)
Дайте людям фотографию примера товара, чтобы они знали что ищут(в статье говорится, что иногда не знают)
Расстояние должно быть смысловым, а не текстовым. Тут можно было ввести теги и т.д., но явно трудоёмко
Спасибо, конечно, но это же непрограммистский подход :-) По факту вы предлагаете переложить на пользователя работу, которую мы автоматизировали (причём без его ведома).
Первый пункт для многих предприятий, кстати, не подойдёт:
Если сборка идёт с помощью ТСД - ваш первый вариант бесспорно отличный! На цветном экране удобно фотки показать. Я так сделал на молочном заводе, где большинство сотрудников цеха не умеют читать по-русски. Они ориентировались по картинкам товаров, хотя я ещё предлагал сделать перевод интерфейса на их родной фарси.
А если сборка идёт по бумажным сборочным листам? Чёрно-белые фотографии разноцветных лаков и красок? Не пойдёт.Для бумажной сборки это очень дорого. В моей фармацевтической компании на листочке А4 бывает по 8-9 позиций: столько фотографий не поместится, а печатать кипу бумаг - ещё неудобно с собой таскать.
Отличная работа. Не пробовали нормализатор названий сделать или найти готовый, примерно как с адресами делают?
Спасибо! На одном складе, где это делалось, к сожалению, больше ничего не предпринималось. На втором месте для товаров был создан мастер создания, который сам делал названия единообразными. Нормализатор - это оно? Если да, то работает, идея отличная. Не знаю, почему я на первом складе сам не додумался сделать.
История повторяется ;)
https://habr.com/ru/post/234723/
Коллега, вы - гений! Ваша работа меня сразила наповал. Мне нечего прокомментировать :-)
тоже N-граммы пришли на ум, пока читал стать. опередили с предложением)
мне в своё время весьма помогло словарь сделать покороче.
но у меня была другая предметная область
https://habr.com/ru/company/dataline/blog/512142/
В WMS алгоритмы работают на основе выделенных аналитик к номенклатуре товаров и раскладка в ячейки происходит на основе заранее установленных соответствий между ячейками, аналитиками товара и правилами раскладки.
Когда вы применили алгоритм на уровне ИИ для оперативного установления этих связей ячейка-аналитики-правила, то вы аналитическую работу по связке, которую делают "до" раскладки перенесли, фактически, в момент самой раскладки.
Мало того, что алгоритм типа ИИ требует постоянной работы по его подправке за пределами этапа разработки и постоянного непрерывного обучения , что далеко не всегда под силу и квалификацию логистикам, т.е. он фактически всегда "сырой" и выдаёт энный процент ошибок, который, правда, уменьшается с течением, длительным течением времени, так ещё встают вопросы производительности расчета алгоритмов на больших массивах данных (больших складах и/или широкой номенклатуре и объёмных аналитиках).
Предложенный выше нормализатор куда лучшее решение, а вариант с анализом текста рискованный для бизнеса. Правильно заметили, что если процессы бизнеса ранее были уже отлажены, то новые попытки его улучшить будут выдавать всё меньший и меньший результат. И при этом при всё больших и больших затратах. Закон Парето во всей его красе, 20/80 и 80/20!
И еще одна попытка изобретения НСИ
Если уж брать веса слов, то надо подключать базы частей речи: у существительных максимальный вес, у глаголов – поменьше, у союзов, предлогов и вводных – самый маленький.
Применение расстояния Левенштейна с целью оптимизации работы склада