- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Занялся самообучением каталога товаров, т.е. автоклассификацией товаров, появились вопросы.
Имеем:
1. В тестовой базе 5600 единиц товаров в Основной базе (ОБ)
2. Для привязки 15000 единиц товаров во Вторичной базе (ВБ)
Требуется сделать самообновляемую систему с полуавтоматической привязкой на основе ассоциаций и дальнейшей автоматической привязкой.
Первоначальное обучение произодится вручную оператором методом привязки товаров из ВБ к товарам ОБ. При этом к каждому товару из ВБ я вытаскиваю как подсказку возможные варианты из ОБ.
Далее столкнулся с рядом вопросов:
По логике вещей надо собирать отдельную таблицу ассоциаций товаров ОБ и на ее основе автоматически проверять все новые товары из ВБ с целью создания в дальнейшем полностью автоматической привязки.
1. Какая структура подобной таблицы оптимальна в mysql?
2. Есть какие либо варианты подобных классификаторов уже созданные и имеющиеся в паблике?
3. Есть какие либо труды на данную тему?
хотелось бы увидеть готовое решение :)
а то для такой классификации пока использую price.ru (по принципу - в каких категориях этого товара больше)
Готовое решение в виде его клиентской части вам никакой особой радости не принесет, а внутреннюю часть пока что показать не готов ))
а внутреннюю часть пока что показать не готов ))
Показывать не нужно, ток расскажите - какими наборами данных оперируете для присваивания категории (или эти наборы ничто иное как ключевые слова в наименование товара? + стоп слова для разных категорий, чтобы модельки игрушек не попадали в промышленное оборудование?), без данной информации сложно порекомендовать какую-либо структуру БД.
Я не работаю с категориями пока что.
Делаю систему на основе карточек товаров, соотв. и привязку делаю к товарам.
Так же параллельно выдираю классификаторы групп товаров - но это пока только в качестве сбора данных, никак не использую и не анализирую качество сбора.
В кратце алгоритм таков:
Имею наименования моделей очищенные от шлака (всякие мелочи) и минус-слов (цвета к примеру)
Поиск в ОБ - обработка функцией чуть сложнее similar_text - выбор автопривязать или нет - если нет - поиск в АБ (ассоциативная база) и еще раз обработка волшебной функцией - и выбор автопривязать или уже отправить контент-манагеру на проверку.
Соответственно в данной схеме чем больше АБ, тем автоматизированнее процесс.
Формат данных таблиц не имеет значения по сути, кроме интересующей меня АБ.
Я сделал АБ в виде:
id|id товара ОБ|id товара ВБ|наименование модели
Буду рад комментам и советам.
id|id товара ОБ|id товара ВБ|наименование модели
При таом количестве переменных и 20 000 товаров смысла ломать голову над структурой БД абсолютно никакого (т.к. размер базы наверное всего 5-10МБ) у меня ситуация иная - порядок около миллиона.
Хотелось бы услышать про вашу волшебную функцию.
удивило
Я не работаю с категориями пока что.
а смысл тогда разбивки?
я на начальном этапе экспериментов использовал статистику всех отдельных слов в наименование товара по всему массиву товаров (когда без категорий делал) и затем на основе этой статистики делал поиск по всем словам в наименование товара, а веса каждого отдельно слова равнялись обратной частотности (такой подход спасал от составления стоп листа).
Теперь эти "кучки" товаров нужно раскидать по категориям.
Решаю пока проблему когда название товара написано с ошибкой, раньше получалась фигня, но чет забыл про симилар текст, буду пробовать.
При таом количестве переменных и 20 000 товаров смысла ломать голову над структурой БД абсолютно никакого (т.к. размер базы наверное всего 5-10МБ) у меня ситуация иная - порядок около миллиона.
смысл есть всегда. Это тестовая база к тому же ;)
Хотелось бы услышать про вашу волшебную функцию.
удивило
Нашел в паблике и доработал, ее итоги на 90% такие же как и у similar_text, но на этапе разработки я пришел к выводу что она получше работает - ничего волшебного.
а смысл тогда разбивки?
Еще раз топик перечитайте :) У меня не стоит цель классифицировать товары по категориям, я хочу классифицировать товары базы ВБ к базе ОБ, а товары в базе ОБ и так раскиданы по категориям. Подход другой у меня.