 |
|
14/01/2008
Цитата:
морфологический анализ
морфологический анализ
Это больше поможет при создании синонимайзера =)
Цитата:
Но вопрос: где взять эталонную базу моделей?
Но вопрос: где взять эталонную базу моделей?
Завести самим, ну, или, "понаграбить" с Яндекс.Маркета
Цитата:
Если интересно - могу описать алгоритм более подробно
Если интересно - могу описать алгоритм более подробно
Да, было бы интересно на него посмотреть.
 |
|
19/01/2008
to altsupport:
Всё просто до безобразия. У нас есть две таблицы товаров, одна "эталонная" - с правильными названиями, описаниями и.т.п. для выгрузки в магазины, а вторая - все прайсы поставщиков с ихними наименованиями. Для первой таблицы триггер при изменении наименования добавляет в подчинённую таблицу слова которые содержит это наименование. Например для "Пылесос GST1120/RT это будут:
При идентификации, искомое наименование тоже разбивается на слова и SQL-запросом выбираются эталонные товары с наибольшим коефициентом совпадения.
Это описание алгоритма вкратце. Замечу, что при количестве товара в эталонной базе около 5000 и суммарному количеству в прайсах поставщиков 40000 на core quad 2400 (на одном ядре!!!) процесс идентификации по всем товарам занимает менее 7-ми минут. А вот процент успешной идентификации зависит от правильности наименований номенклатуры как эталонной так и поставщиков.
Также в ближайшее время планируется усовершенствование этого механизма, например составление списка слов не принимающих участия в идентификации, очень актуально, например, для мобильных телефонов, т.к. в названии часто указывают перечень цветов.
Цитата:
Да, было бы интересно на него посмотреть.
Да, было бы интересно на него посмотреть.
Всё просто до безобразия. У нас есть две таблицы товаров, одна "эталонная" - с правильными названиями, описаниями и.т.п. для выгрузки в магазины, а вторая - все прайсы поставщиков с ихними наименованиями. Для первой таблицы триггер при изменении наименования добавляет в подчинённую таблицу слова которые содержит это наименование. Например для "Пылесос GST1120/RT это будут:
- Пылесос
GST
1120
RT
При идентификации, искомое наименование тоже разбивается на слова и SQL-запросом выбираются эталонные товары с наибольшим коефициентом совпадения.
Это описание алгоритма вкратце. Замечу, что при количестве товара в эталонной базе около 5000 и суммарному количеству в прайсах поставщиков 40000 на core quad 2400 (на одном ядре!!!) процесс идентификации по всем товарам занимает менее 7-ми минут. А вот процент успешной идентификации зависит от правильности наименований номенклатуры как эталонной так и поставщиков.
Также в ближайшее время планируется усовершенствование этого механизма, например составление списка слов не принимающих участия в идентификации, очень актуально, например, для мобильных телефонов, т.к. в названии часто указывают перечень цветов.
|
|
|
20/01/2008
2Svyat
А вы ведете базу знаний? Ведь поставщик в своей базе не так часто меняет названия. Да и при суммарном 40 000, не так часто появляется новый товар?
Т.е. по таблицам (после модерации) получается вот так (немного по-другому будет (см. ниже)):
Название-эталон|Название как у поставщика 1|Название как у поставщика 2
...
Получаете прайс поставщика. Берете название, сверяете с названием его колонки. Если на 100% совпадает, значит это то и есть.
Все что не совпало, то в конце автоматического распихивания выведется на ручное распихивание. При ручном распихивании, также пополняется (запоминается) база знаний (какое наименование какому эталоному).
А чтобы быстрее сверялось, то добавить еще колонку, где будет храниться хэш названия (тем же md5). И тогда - получили названия поставщика, его в md5 (удалив двойные пробелы и в начале и конце) и сверять с колонокой. Полю md5 назначит индекс или уникал. Тогда очень быстро будет чекаться.
...
Весь гиммор это создание эталоной базы (но можно понапарсить) и первичного создания базы знаний. Но все зависит как организуете. Ведь если сделать удобный интерфейс первоначального распихивания (с алгоритмом предугадывания), то для наполнения сиди и тока кликай мыхой выбирая раздел, фирму и т.п. На создание такой базы у одного человека уйдет около месяца (если не свихнется). Поэтому надо сажать всех. Главное чтобы без ошибок распихивали. А чтобы без ошибок, тогда надо дублировать друг-друга. Т.е. если один человек этот товар поместил сюда и второй тоже этот же товар поместил сюда, то так и есть. Если они поместили в разные места, то все вернуть назад, а товар пометить как проблемный.
Тоже грамотно. Главное чтобы эти товары по цене не отличались. А то иногда бывает что из-за цвета один дороже другого.
...
Вообще, уже обсуждали — было бы все едино для всех. Т.е. у каждого товара был бы свой ID (как ISBN у книг) и каждый поставщик вставлял бы его в свои прайсы. Как бы резко в гору пошла коммерция! Так как многих такие сопоставления останавливают. Была бы конкуренция. Цены снизились. Повысилось качество. Потому, что в таком случае продавцы бы обрабатывали большее количество прайсов, соответствено выбирали бы те, где дешевле или где обслуживают быстрее и качественей.
Т.е. на том же государственном уровне ввели бы реестр (обязателен для производителей).
Выпустил товар? Дуй в реестр, вводи название, вводи описание, получай ИД.
А остальные (цепочка от производителя до конечного продавца) этот ИД держат в колонке к товару.
А вы ведете базу знаний? Ведь поставщик в своей базе не так часто меняет названия. Да и при суммарном 40 000, не так часто появляется новый товар?
Т.е. по таблицам (после модерации) получается вот так (немного по-другому будет (см. ниже)):
Название-эталон|Название как у поставщика 1|Название как у поставщика 2
...
Получаете прайс поставщика. Берете название, сверяете с названием его колонки. Если на 100% совпадает, значит это то и есть.
Все что не совпало, то в конце автоматического распихивания выведется на ручное распихивание. При ручном распихивании, также пополняется (запоминается) база знаний (какое наименование какому эталоному).
А чтобы быстрее сверялось, то добавить еще колонку, где будет храниться хэш названия (тем же md5). И тогда - получили названия поставщика, его в md5 (удалив двойные пробелы и в начале и конце) и сверять с колонокой. Полю md5 назначит индекс или уникал. Тогда очень быстро будет чекаться.
...
Весь гиммор это создание эталоной базы (но можно понапарсить) и первичного создания базы знаний. Но все зависит как организуете. Ведь если сделать удобный интерфейс первоначального распихивания (с алгоритмом предугадывания), то для наполнения сиди и тока кликай мыхой выбирая раздел, фирму и т.п. На создание такой базы у одного человека уйдет около месяца (если не свихнется). Поэтому надо сажать всех. Главное чтобы без ошибок распихивали. А чтобы без ошибок, тогда надо дублировать друг-друга. Т.е. если один человек этот товар поместил сюда и второй тоже этот же товар поместил сюда, то так и есть. Если они поместили в разные места, то все вернуть назад, а товар пометить как проблемный.
Цитата:
списка слов не принимающих участия в идентификации
списка слов не принимающих участия в идентификации
Тоже грамотно. Главное чтобы эти товары по цене не отличались. А то иногда бывает что из-за цвета один дороже другого.
...
Вообще, уже обсуждали — было бы все едино для всех. Т.е. у каждого товара был бы свой ID (как ISBN у книг) и каждый поставщик вставлял бы его в свои прайсы. Как бы резко в гору пошла коммерция! Так как многих такие сопоставления останавливают. Была бы конкуренция. Цены снизились. Повысилось качество. Потому, что в таком случае продавцы бы обрабатывали большее количество прайсов, соответствено выбирали бы те, где дешевле или где обслуживают быстрее и качественей.
Т.е. на том же государственном уровне ввели бы реестр (обязателен для производителей).
Выпустил товар? Дуй в реестр, вводи название, вводи описание, получай ИД.
А остальные (цепочка от производителя до конечного продавца) этот ИД держат в колонке к товару.
|
|
|
21/01/2008
to altsupport:
В нашей системе используется СУБД MS MSQL Server, поэтому мы можем себе позволить хранить две таблицы как эталонный катклог так и все ранее импортированные прайсы, и при импорте прайса поставщика мы есесно сверяем номенклатуру с уже имеющейся у нас (или по уникальному коду поставщика или по наименованию) и привязка к эталонам идёт по ID которые являются уникальными ключами записи (md5 сдесь уже никчему). Более того, у нас храниться вся история изменений всех полей, от даты импорта до наименования и цены!!! (Логируется триггерами).
Выше я приводил скриншот этого механизма, вся привязка занимает не более 2-5 секунд если товар есть в эталонной базе. И делается это только один раз и только в случае, если автоматическая идентификация не сработала. Один оператор за день легко может привязать более 3000 прайс-строк.
Это не проблема, перед привязкой можно проверить значение поля и выдать сообщение, а возможность нарушения целостности данных при одновременной работе нескольких операторов - исключается! Они работают под своими транзакциями, можножна только временная блокировка одного - другим.
Да, реестр дело хорошее...
А вообще у меня идей по усовершенствованию алгоритма масса, и по возможности они тестируются на приемлемость использования. Главный параметр, это чтобы идентификация 1-й строчки прайса не занимала много времени. Для интернет-магазинов это не особо критично, т.к. количество прайс-строк в них редко превышает 100 тыс, и добавляется/изменяется в них за менсяц 5-10%. А вот для больших каталогов и прайс обменников это очень критично. Сейчас скорость довольно приемлема но о результатах смогу сообщить после завершения тестов и некоторого времени "промышленной" эксплуатации.
А по поводу единой базы идентификаторов - есть тот же штрих-код, но я кажись видел его в прайсах раза. Да и например китайцы, тот же Orion грешит тем, что тулит один и тот же штрих-код на все котобки. Везде есть свои изъяны.
Цитата:
А вы ведете базу знаний? Ведь поставщик в своей базе не так часто меняет названия. Да и при суммарном 40 000, не так часто появляется новый товар?
А вы ведете базу знаний? Ведь поставщик в своей базе не так часто меняет названия. Да и при суммарном 40 000, не так часто появляется новый товар?
В нашей системе используется СУБД MS MSQL Server, поэтому мы можем себе позволить хранить две таблицы как эталонный катклог так и все ранее импортированные прайсы, и при импорте прайса поставщика мы есесно сверяем номенклатуру с уже имеющейся у нас (или по уникальному коду поставщика или по наименованию) и привязка к эталонам идёт по ID которые являются уникальными ключами записи (md5 сдесь уже никчему). Более того, у нас храниться вся история изменений всех полей, от даты импорта до наименования и цены!!! (Логируется триггерами).
Цитата:
Ведь если сделать удобный интерфейс первоначального распихивания (с алгоритмом предугадывания), то для наполнения сиди и тока кликай мыхой выбирая раздел, фирму и т.п.
Ведь если сделать удобный интерфейс первоначального распихивания (с алгоритмом предугадывания), то для наполнения сиди и тока кликай мыхой выбирая раздел, фирму и т.п.
Выше я приводил скриншот этого механизма, вся привязка занимает не более 2-5 секунд если товар есть в эталонной базе. И делается это только один раз и только в случае, если автоматическая идентификация не сработала. Один оператор за день легко может привязать более 3000 прайс-строк.
Цитата:
Главное чтобы без ошибок распихивали. А чтобы без ошибок, тогда надо дублировать друг-друга. Т.е. если один человек этот товар поместил сюда и второй тоже этот же товар поместил сюда, то так и есть. Если они поместили в разные места, то все вернуть назад, а товар пометить как проблемный
Главное чтобы без ошибок распихивали. А чтобы без ошибок, тогда надо дублировать друг-друга. Т.е. если один человек этот товар поместил сюда и второй тоже этот же товар поместил сюда, то так и есть. Если они поместили в разные места, то все вернуть назад, а товар пометить как проблемный
Это не проблема, перед привязкой можно проверить значение поля и выдать сообщение, а возможность нарушения целостности данных при одновременной работе нескольких операторов - исключается! Они работают под своими транзакциями, можножна только временная блокировка одного - другим.
Да, реестр дело хорошее...
А вообще у меня идей по усовершенствованию алгоритма масса, и по возможности они тестируются на приемлемость использования. Главный параметр, это чтобы идентификация 1-й строчки прайса не занимала много времени. Для интернет-магазинов это не особо критично, т.к. количество прайс-строк в них редко превышает 100 тыс, и добавляется/изменяется в них за менсяц 5-10%. А вот для больших каталогов и прайс обменников это очень критично. Сейчас скорость довольно приемлема но о результатах смогу сообщить после завершения тестов и некоторого времени "промышленной" эксплуатации.
А по поводу единой базы идентификаторов - есть тот же штрих-код, но я кажись видел его в прайсах раза. Да и например китайцы, тот же Orion грешит тем, что тулит один и тот же штрих-код на все котобки. Везде есть свои изъяны.
|
|
|
21/01/2008
Цитата:
md5 сдесь уже никчему
md5 сдесь уже никчему
Не, ИД это ИД (наверное автоинкремент), а мд5 - это хэш от наименования. Хэш с хэшем (считайте тоже строка но меньше) быстрее сравниваются (по нему выбирается). Так не заметно, а при больших количествах (несколько сотен тысяч) разница будет видна.
Тоже самое пораспихивая на кучу маленьких таблиц. Но для вас всё это мало актуально, у вас свой SQL Server.
Вы делитесь усовершенствованиями, что удалось выяснить эксперементальным путем. Так как актуально.
 |
|
23/01/2008
Тема очень интересная, но наша компания реально однаждый связалась с хохлами и очень потом пожалела об этом... Да и весь треп на 4 страницы это ни что иное как реклама!!! Какие мы хорошие, какие мы умные и т.д. Не написать ли проще господа хочу продать свою программу, функционал такой-то, возьмите хоть кто-то. Я например моло разбираюсь в этих тонкостях которые написаны выше, но даже я понимаю насколько непростая задача. Хотелось бы посмотреть продукт и цену на него.
|
|
|
23/01/2008
Цитата:
Не написать ли проще господа хочу продать свою программу,
Не написать ли проще господа хочу продать свою программу,
Я сообщить, что меня из списка вычеркивайте.
Я лично для себя.
|
|
|
19/02/2008
to S:
Успех внедрения зависит не только от исполнителя но и от заказчика, а в данном случае наверное ещё и существенно.
И если писать
то зачем тогда брызгать слюной?
Успех внедрения зависит не только от исполнителя но и от заказчика, а в данном случае наверное ещё и существенно.
И если писать
Цитата:
"Я например моло разбираюсь в этих тонкостях которые написаны выше"
"Я например моло разбираюсь в этих тонкостях которые написаны выше"
то зачем тогда брызгать слюной?
 |
|
03/03/2008
Автоматическое обновление цен и наличия - это не так сложно, как кажется.
В нашем магазине обновление производится ежедневно. На локальном сервере обновление прайс-листов из 5000-10000 позиций товарв занимает 20-30 секунд.
На сервере в инете примерно так же, больше определяется скоростью закачки.
Всем товарам ИМ должны быть назначены артикулы:
1 вариант: артикулы поставщика и будут артикулами ИМ - в случае, если товары не пересекаются у поставщиков.
2 вариант, посложнее: артикулы ИМ формируются свои (можно AABBCCC, где AA - номер раздела, BB - номер подраздела, CCC - порядковый номер товара в подразделе). Но для того, чтобы по артикулам поставщика скриптом узнавались товары в ИМ, нужно составить таблицу соответствий артикулов ИМ и поставщиков. При первоначальном заполнении базы это несложно делать.
Скрипт пишется на PHP/MySQL, файлы прайсов поставщиков только нужно будет пересохранять из xls в формат csv (есть в любом Экселе) - текстовый файл, разделенный запятыми.
В нашем магазине обновление производится ежедневно. На локальном сервере обновление прайс-листов из 5000-10000 позиций товарв занимает 20-30 секунд.
На сервере в инете примерно так же, больше определяется скоростью закачки.
Всем товарам ИМ должны быть назначены артикулы:
1 вариант: артикулы поставщика и будут артикулами ИМ - в случае, если товары не пересекаются у поставщиков.
2 вариант, посложнее: артикулы ИМ формируются свои (можно AABBCCC, где AA - номер раздела, BB - номер подраздела, CCC - порядковый номер товара в подразделе). Но для того, чтобы по артикулам поставщика скриптом узнавались товары в ИМ, нужно составить таблицу соответствий артикулов ИМ и поставщиков. При первоначальном заполнении базы это несложно делать.
Скрипт пишется на PHP/MySQL, файлы прайсов поставщиков только нужно будет пересохранять из xls в формат csv (есть в любом Экселе) - текстовый файл, разделенный запятыми.
 |
|
03/03/2008
А как быть, если поставщик выдает файл с остатками, в котором к ячейках с артикулами произвольное количество пробелов после артикулов? Поиск то уже пойдет не по строгому соответствию... и тогда некоторые артикулы могут стать для экселя тождественными.. 001 и 0001 например
|
|
|
03/03/2008
Цитата:
А как быть, если поставщик выдает файл с остатками, в котором к ячейках с артикулами произвольное количество пробелов после артикулов?
А как быть, если поставщик выдает файл с остатками, в котором к ячейках с артикулами произвольное количество пробелов после артикулов?
Так все-равно для каждого поставщика пишеться свой обработчик.
Тут проблема больше в человеческом факторе. Не туда тыкнули, не то ввели, раз в неделю будут оформление прайса менять. Поэтому и самое лучшее, но почти не реальное (уже писали) - на государсвенном уровне ввести какой-нить единый реестр товаров. И там четко прописать (ГОСТ?) как должен выглядеть прайс (какие поля) и каждому товару присваивается свой уникальный артикул. И когда все будут по этому реестру - вот тогда не жизнь, а сказка. Причем - всем. Хотя человеческий фактор и ошибки все-равно остануться.
|
|
|
03/03/2008
Ну пробелы между остатком и артикулом - это далеко не самое страшное, для этого можно написать дополнительный скрипт обработки который при необходимости будет разделять остаток от артикула а лишние пробелы удалять. Да и артикул не лучшая привязка, лучше всего это уникальный код из базы данных поставщика. У многих он в прайсе есть, этим они хорошо упрощают жизнь не только себе но и другим.
 |
|
13/03/2008
А еще лучше когда все услуги по согласованию прайсов и справочника клиента берет на себя организация предоставляющая услугу сводного прайса))) Ведь мало того что нужно закачать прайсы в систему - нужно же еще и наименования к единому коду привести. Или как в нашем случае мы приводим к единому эталонному наименованию в нашем справочнике. Так что получается и прайсы поставщиков и справочник клиента привязан к единому коду. Нужно только количество для заказа проставить да и то можно автоматом дефектуру загрузить и заявки автоматом по поставщикам разойдутся. 
А в результате поставщик получает заявки со своим кодом и наименованием(может получить и в нужном ему формате) а наш клиент получает накладную в своем формате и со своими наименованиями и кодами.
А в результате поставщик получает заявки со своим кодом и наименованием(может получить и в нужном ему формате) а наш клиент получает накладную в своем формате и со своими наименованиями и кодами.
 |
|
28/03/2008
Всем здравствуйте.
Вопрос к Автор: Lev Alin
Подскажите плз. а чем Вас сейчас Ваша версия продукта не устраивает? Что именно хотите доработать?
По описанию вроде бы у Вас сейчас есть все, о чем шла речь в этом топике
http://www.b2b-soft.ru/content/view/13/31/#b1
Или же Ваше описание не соответствует реальным возможностям программы? (надеюсь, что все соответствует)
Тогда в чем же дело?
С уважением
Сергей
Lev Alin:
Почитал я Ваши дискусии и засел за новый продукт, который думаю будет отвечать многим требованиям продиктованным рынком. Постараюсь в новой конфигурации к 1С совместить и "Анализ прайс-листов" и "Выгрузку в ИМ из 1С", которые уже зарекомендовали себя. Правда скоро не ждите месяца через 3-6 будет.
Почитал я Ваши дискусии и засел за новый продукт, который думаю будет отвечать многим требованиям продиктованным рынком. Постараюсь в новой конфигурации к 1С совместить и "Анализ прайс-листов" и "Выгрузку в ИМ из 1С", которые уже зарекомендовали себя. Правда скоро не ждите месяца через 3-6 будет.
Вопрос к Автор: Lev Alin
Подскажите плз. а чем Вас сейчас Ваша версия продукта не устраивает? Что именно хотите доработать?
По описанию вроде бы у Вас сейчас есть все, о чем шла речь в этом топике
http://www.b2b-soft.ru/content/view/13/31/#b1
Или же Ваше описание не соответствует реальным возможностям программы? (надеюсь, что все соответствует)
Тогда в чем же дело?
С уважением
Сергей
|
|
|
28/03/2008
Автор: Lev Alin
Спасибо Вам за ответ.
У меня на этот счет другое мнение...
Ничего там в конфигурации "затачивать" не нужно..... тем более для мелких предприятий....
Автор: Lev Alin
К Вам еще вопрос:
Со стандартной конфигурацией 1С 8.0 Управление торговлей 10.2 Ваша обработка
http://www.b2b-soft.ru/content/view/13/31/#b1
сейчас нормально работает?
Все заявленные функции в описании обработки выполняются?
У меня есть желание приобрести эту обработку НО!
1. Т.к. у данной обработки нет демо-версии (есть только описание)
2. Есть не совсем гладкая история общения с разработчиком....
3. Кто и как будет осущствлять/уже осуществляет саппорт по данной обработке
4. Меня не интересуют какие-либо "затачивания" или "доработки".... Интересует только ГОТОВЫЙ ПРОДУКТ с конкретно описанным функционалом и под СТАНДАРТНЫЕ конфигурации.
Подскажите плз. кто-нибудь уже использует обработку Автор: Lev Alin ?
Какие впечатления? отзывы?
А то платить 12000 только за описание на сайте как-то для меня пока не очень....
Ко всем с уважением
Сергей
Спасибо Вам за ответ.
Lev Alin:
1С Управление торговлей очень хорошая конфигурация, но она слишком перегружена поэтому ее постоянно приходится затачивать под потребности заказчика.
1С Управление торговлей очень хорошая конфигурация, но она слишком перегружена поэтому ее постоянно приходится затачивать под потребности заказчика.
У меня на этот счет другое мнение...
Ничего там в конфигурации "затачивать" не нужно..... тем более для мелких предприятий....
Автор: Lev Alin
К Вам еще вопрос:
Со стандартной конфигурацией 1С 8.0 Управление торговлей 10.2 Ваша обработка
http://www.b2b-soft.ru/content/view/13/31/#b1
сейчас нормально работает?
Все заявленные функции в описании обработки выполняются?
У меня есть желание приобрести эту обработку НО!
1. Т.к. у данной обработки нет демо-версии (есть только описание)
2. Есть не совсем гладкая история общения с разработчиком....
3. Кто и как будет осущствлять/уже осуществляет саппорт по данной обработке
4. Меня не интересуют какие-либо "затачивания" или "доработки".... Интересует только ГОТОВЫЙ ПРОДУКТ с конкретно описанным функционалом и под СТАНДАРТНЫЕ конфигурации.
Подскажите плз. кто-нибудь уже использует обработку Автор: Lev Alin ?
Какие впечатления? отзывы?
А то платить 12000 только за описание на сайте как-то для меня пока не очень....
Ко всем с уважением
Сергей
Ответить
