Нечеткое сопоставление названий продуктов
Мне нужно автоматически сопоставлять названия продуктов (камеры, ноутбуки, телевизоры и т.д.), которые поступают из разных источников в каноническое имя в базе данных.
Например, "Canon PowerShot a20IS" , "NEW powershot A20 IS от Canon и Цифровая камера Canon PS A20IS
должны соответствовать "Canon PowerShot A20 IS" . Я работал с levenshtein расстоянием с некоторыми добавленными эвристиками (удаление очевидных общих слов, назначение более высоких издержек на количество изменений и т.д.), Что работает в некоторой степени, но недостаточно хорошо.
Основная проблема заключается в том, что даже однобуквенные изменения в релевантных ключевых словах могут иметь огромное значение, но нелегко определить, какие из них являются ключевыми словами. Рассмотрим, например, три названия продуктов:
Lenovo T400
Lenovo R400
Новый Lenovo T-400, Core 2 Duo
Первые два являются смехотворно подобными строками по любому стандарту (ok, soundex может помочь выделить T и R в этом случае, но имена могут также быть 400T и 400R), первая и третья довольно далеко друг от друга, поскольку строки, но являются одним и тем же продуктом.
Очевидно, что алгоритм сопоставления не может быть точным на 100%, моя цель - автоматически сопоставить примерно 80% имен с высокой степенью уверенности.
Любые идеи или ссылки очень ценятся
Ответы
Ответ 1
Я думаю, что это сработает, чтобы отличить ключевые слова, такие как Lenovo от мякины, например Новый.
Я бы запустил некоторый анализ по базе данных имен для определения ключевых слов. Вы можете использовать код, аналогичный тому, который используется для создания облака слов.
Затем я бы вручную редактировал список, чтобы удалить что-либо явно, как, например, New, на самом деле обычное, но не ключевое.
Затем у вас будет список ключевых слов, которые могут использоваться для определения сходства. Вы связывали бы "сырое" имя с его ключевыми словами и использовали бы эти ключевые слова при сравнении двух или более необработанных имен для сходства (в буквальном смысле, доля общих ключевых слов).
Не идеальное решение на любом участке, но я не думаю, что вы его ожидаете?
Ответ 2
Ключевое понимание здесь заключается в том, что у вас есть правильная метрика расстояния. На самом деле это не ваша проблема. Ваша проблема в классификации.
Позвольте мне привести вам пример. Скажем, у вас есть 20 записей для Foo X1 и 20 для Foo Y1. Вы можете смело предположить, что они две группы. С другой стороны, если у вас есть 39 записей для бара X1 и 1 для бара Y1, вы должны рассматривать их как одну группу.
Теперь расстояние X1 ↔ Y1 в обоих примерах одинаковое, так почему же существует разница в классификации? Это потому, что бар Y1 является выбросом, а Foo Y1 - нет.
Самое смешное, что вам действительно не нужно делать много работы, чтобы определить эти группы впереди. Вы просто выполняете рекурсивную классификацию. Вы начинаете с node для каждой группы, а затем добавляете супернод для двух ближайших узлов. На суперноме хранится наилучшее предположение, размер его поддерева и вариации в нем. Поскольку многие из ваших строк будут идентичными, вы скоро получите большие поддеревья с одинаковыми записями. Рекурсия заканчивается супернодом, содержащимся в корне дерева.
Теперь сопоставьте канонические имена с этим деревом. Вы быстро увидите, что каждый будет соответствовать целому поддереву. Теперь используйте расстояния между этими деревьями, чтобы выбрать ограничение расстояния для этой записи. Если у вас есть продукты Foo X1 и Foo Y1 в базе данных, расстояние отсечения должно быть ниже, чтобы отразить это.
Ответ 3
edg отвечает в правильном направлении, я думаю - вам нужно отличить ключевые слова от пуха.
Контекст имеет значение. Чтобы взять ваш пример, Core 2 Duo пушистый, глядя на два экземпляра T400, но не глядя на процессор OEM-пакета.
Если вы можете пометить в своей базе данных, какие части канонической формы названия продукта важнее и должны появляться в той или иной форме для идентификации продукта, вы должны это сделать. Может быть, с помощью какой-то семантической разметки? Можете ли вы позволить себе иметь человеческую оценку базы данных?
Вы можете попытаться определить классы эквивалентности для таких вещей, как "T-400", "T400", "T 400" и т.д. Возможно, набор правил, которые говорят "числа, связываются сильнее, чем буквы, прикрепленные к этим номерам".
Разделение на случаи, основанные на изготовителе, номер модели и т.д., может быть хорошим подходом. Я бы рекомендовал вам взглянуть на методы определения сроков, чтобы попытаться выполнить это: http://www.worldcat.org/isbn/9780262100854
Конструирование всего в гибкой структуре, которая в основном управляется правилами, где правила могут быть изменены в зависимости от ваших потребностей и появления плохих шаблонов (читай: все, что нарушает ваш алгоритм), также будет хорошей идеей. Таким образом, вы сможете улучшить производительность системы на основе реальных данных.
Ответ 4
Для этого вы можете использовать поиск триграмм. Должен признаться, что я никогда не видел, чтобы алгоритм реализовал индекс, но видел, как он работает в фармацевтических приложениях, где он отлично справляется с плохо названными названиями лекарств. Возможно, вы сможете применить такую же логику к этой проблеме.
Ответ 5
Возможно, вы захотите создать логику, которая игнорирует комбинацию букв и цифр номеров моделей (поскольку они почти всегда очень похожи).
Ответ 6
Алгоритмы проверки орфографии приходят на ум.
Хотя я не смог найти хорошую реализацию примера, я считаю, что вы можете изменить базовый алгоритм проверки орфографии, чтобы получить удовлетворительные результаты. то есть работать со словами как единицей, а не с символом.
Биты и куски, оставшиеся в моей памяти:
- Разделите все обычные слова (a, an, the, new). То, что является "общим", зависит от контекста.
- Возьмите первую букву каждого слова и ее длину и сделайте ключ слова.
- Когда появляется подозрительное слово, он ищет слова с тем же или похожим ключом.
Это может не решить ваши проблемы напрямую... но вы говорите, что искали идеи, верно?
: -)
Ответ 7
Не имея опыта работы с этим типом проблем, но я думаю, что очень наивная реализация будет заключаться в том, чтобы обозначить термин поиска и найти совпадения, которые содержат какой-либо токен.
"Canon PowerShot A20 IS", например, символизирует:
который будет соответствовать каждому из других элементов, которые вы хотите отобразить в результатах. Разумеется, эта стратегия, скорее всего, приведет к множеству ложных совпадений.
Другая стратегия - хранить "ключевые слова" для каждого элемента, такого как "камера", "канон", "цифровая камера" и поиск на основе элементов, имеющих соответствующие ключевые слова. Кроме того, если вы сохранили другие атрибуты, такие как "Создатель", "Бренд" и т.д., Вы можете выполнять поиск по каждому из них.
Ответ 8
Это именно та проблема, над которой я работаю в свободное время. Я придумал:
на основе ключевых слов сузить область поиска:
в этом случае вы можете иметь некоторую иерархию:
тип → компания → модель
чтобы вы соответствовали
"Цифровая камера" для типа
"Canon" для компании, и там вы останетесь с гораздо более узкими возможностями для поиска.
Вы могли бы продолжить эту работу, добавив товарные линии и т.д.
Но главное, это, вероятно, нужно делать итеративно.
Ответ 9
Это проблема запись связи. библиотека дедуплирования python обеспечивает полную реализацию, но даже если вы не используете python, документация имеет хороший обзор того, как подойти к этой проблеме.
Вкратце, в рамках стандартной парадигмы эта задача разбивается на три этапа
- Сравните поля, в этом случае просто имя. Вы можете использовать один или несколько компараторов для этого, например, расстояние редактирования, например расстояние Левенштейна, или что-то вроде косинусного расстояния, которое сравнивает количество общих слов.
- Поверните массив значений расстояния в вероятность того, что пара записей действительно будет о том же самом.
- Скопируйте эти парные вероятности на группы записей, которые, вероятно, все относятся к одной и той же вещи.
Ответ 10
Мы можем использовать Служба Datadecision для соответствия товарам.
Это позволит вам автоматически сопоставлять данные вашего продукта с использованием статистических алгоритмов. Эта операция выполняется после определения пороговой оценки доверия.
Все данные, которые не могут быть автоматически сопоставлены, должны быть вручную просмотрены через выделенный пользовательский интерфейс.
В онлайн-службе используются таблицы поиска для хранения синонимов, а также для вашей истории сопоставления вручную. Это позволяет вам улучшить автоматизацию сопоставления данных при следующем вводе новых данных.