Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 10
Поизучайте Machine Learning, вы его переизобретаете заново. Переизобретать — это ок, это тренирует мышление, но презентовать ваши достижения в отрыве от мирового знания, как будто этих знаний не существует — весьма наивно (а ещё непродуктивно и неуважительно к читателям, т.к. снижает уровень дискуссии до «мне нравятся/не нравятся ваши разработки». неужели вы просто хотели, чтобы вас похвалили за то, что вы такой умный? ).
Конкретнее скажу, что для сколько-нибудь полезного использования у вашей модели и её предполагаемого применения есть два недостатка:
1) у вас не будет недостаточно данных / экспертов для того, чтобы ваши модели были достаточно точными для практического применения.
2) у людей свои предпочтения, «людям нужны свои личные веса для правил», данные одного эксперта не будут применимы для другого. вы уже изобрели, как с этим работать?
Конкретнее скажу, что для сколько-нибудь полезного использования у вашей модели и её предполагаемого применения есть два недостатка:
1) у вас не будет недостаточно данных / экспертов для того, чтобы ваши модели были достаточно точными для практического применения.
2) у людей свои предпочтения, «людям нужны свои личные веса для правил», данные одного эксперта не будут применимы для другого. вы уже изобрели, как с этим работать?
А, да, касательно недвижимости/машин — есть ещё ключевой недостаток. Все каталоги врут.
Поэтому вам всё равно придётся составлять табличку в excel, после того, как вы прозвоните все выбранные объявления (или даже обойдёте ножками, в случае с машинами или недвижимостью). А там уже можно будет добавить и косвенные фичи, которые нужно пользователю, типа «реальная цена», «сколько уйдёт на ремонт», «скидка», «насколько она мне нравится», «сколько бензина сожрёт за 5 лет», и вот обычно можно достаточно просто эти кастомные фичи сделать аддитивными, добавить им веса и получить линейный классификатор.
Поэтому вам всё равно придётся составлять табличку в excel, после того, как вы прозвоните все выбранные объявления (или даже обойдёте ножками, в случае с машинами или недвижимостью). А там уже можно будет добавить и косвенные фичи, которые нужно пользователю, типа «реальная цена», «сколько уйдёт на ремонт», «скидка», «насколько она мне нравится», «сколько бензина сожрёт за 5 лет», и вот обычно можно достаточно просто эти кастомные фичи сделать аддитивными, добавить им веса и получить линейный классификатор.
Смотрите в чем дело, это направление — скорее альтернатива (может в чем-то «подружка») Machine Learning. Как вы написали в комменте ниже, каталоги врут, поэтому в проекте речь идет о предоставлении максимально прозрачного (стороннего для любого каталога) математически детерминированного механизма выделения интересующих пользователя элементов каталога, а не о том, как на основе его запросов и редиректов предложить «совершенно точно подходящую» продукцию, ну и всего в таком духе. К слову, в пункте 2 вы пишете, что «людям нужны свои личные веса для правил», что верно. Возможно, из-за некоторой недосказанности в проекте, вы решили, что какой-то дядя расставляет веса… Это дело пользователя. Да, пользователь может воспользоваться готовым правилом, если захочет. Но не обязан.
Насчет пункта 1 — не понял, в чем недостаток, поясните.
P.S. никакой подход не может быть без недостатков, разумеется, но здесь они, по всей видимости, носят несколько иной характер. Например, необходимость оценки каждого элемента каталога при сортировке, что не позволяет делать короткие быстрые выборки из БД.
данные одного эксперта не будут применимы для другого. вы уже изобрели, как с этим работать?Если пытаетесь подколоть знанием о групповой обработке экспертных оценок — то засчитано))) Если нет — то надо дополнительно раскрыть суть послания…
Насчет пункта 1 — не понял, в чем недостаток, поясните.
P.S. никакой подход не может быть без недостатков, разумеется, но здесь они, по всей видимости, носят несколько иной характер. Например, необходимость оценки каждого элемента каталога при сортировке, что не позволяет делать короткие быстрые выборки из БД.
В свое время я делал подобные приложения под WinMobile, x86 и Андроид. Нафиг никому не нужно.
Вообще-то ценность того или иного признака/предмета/услуги меняется нелинейным образом. Что было доказано еще в позапрошлом веке и даже преподается в основах экономики. Помнится в учебнике приводился такой пример: выбор между двумя продуктами, допустим один из них вам нравится большей чем другой, например леденец и мороженное которое вам нравится. Во время прогулки имея возможность (вернее «необходимость») купить 4 мороженных или 8 леденцов, вы скорее всего купите 3 мороженных и 1-2 леденца, хотя леденец вам особо и не нравится. Индивидуальная «ценность» следующего мороженного будет падать с каждым съеденным до этого мороженным, и в какой-то момент (в данном случае) появится «ценность» разнообразия, которая превысит «ценность» еще одного мороженного. Хотя фактическая цена мороженного не менялась.
А поскольку такая «ценность» индивидуальна, ее изменение нелинейно и субъективно — то из подобных затей чаще всего ничего не выходит.
Эффект учитывается на макроуровне, на индивидуальном — слишком много времени уходит на выяснение шкалы ценностей у индивида, в итоге слишком маленький выхлоп.
А поскольку такая «ценность» индивидуальна, ее изменение нелинейно и субъективно — то из подобных затей чаще всего ничего не выходит.
Эффект учитывается на макроуровне, на индивидуальном — слишком много времени уходит на выяснение шкалы ценностей у индивида, в итоге слишком маленький выхлоп.
Возможно, я не совсем верно понимаю ход Ваших мыслей, но отмечу, что здесь речь о выдаче наиболее предпочтительных вариантов пользователю. Речь о покупке некоторого количества экземпляров варианта не идет, есть просто вариант «мороженое» и вариант «леденец». Если вдруг речь о том, что пользователь ранее уже что-то покупал и пришел вновь, и его предпочтения изменились… тогда да, надо формировать новое правило выбора. Можно облегчить его судьбу тем хранением старого правила… (Есть еще подсказки, которые СУЩЕСТВЕННО облегчают жизнь, но о них в следующей статье — когда будет возможность показать как это работает).
То есть, вы просто предлагаете пользователю писать decision tree вручную? Тогда я вас неправильно понял. Значит, вы изобрели крайне ограниченный визуальный язык программирования. Ну что ж, попробуйте теперь предложить его программистам (предпочтут «if» в excel или код на любимом ЯП) и непрограммистам (не разберутся, нет нужного стиля мышления). Останется крайне узкая группа людей, которая не сформирована в рынок и не ищет ваш продукт. То есть, вы их просто не найдёте. Но попробовать можете, конечно.
Все это так. Добавлю, что тот самый «визуальный язык» не представлен полностью — только самый простой случай (он же обязательный — простые правила). В следующем билде планируется добавить уже сложные правила, причем их число намного меньше, чем могло быть. Внедрение действительно выглядит трудным, и группа людей, понимающих что это и с чем это можно есть — мала. Поэтому мы и здесь — формировать понимание, что в ряде случаев можно не «тыкать» как обезьяна перебирая тонны объявлений, а просто указать приоритеты. Посмотрим, что выйдет…
P.S. Кстати, как с функционалом? Писали о проблемах на сервере…
P.S. Кстати, как с функционалом? Писали о проблемах на сервере…
Вот как-то так…
gyazo.com/717557c0ba4b6cc089af62b9dd0c80d6
Т.е. вроде даже что-то работает, но каждый раз при обращении к серверу жалуется. И критерии сортировки не применяются, как я понял — всегда всё по 100% + NaN%.
Может, лучше, видео сделаете и соберёте обратную связь в форму от forms.google.com?
gyazo.com/717557c0ba4b6cc089af62b9dd0c80d6
Т.е. вроде даже что-то работает, но каждый раз при обращении к серверу жалуется. И критерии сортировки не применяются, как я понял — всегда всё по 100% + NaN%.
Может, лучше, видео сделаете и соберёте обратную связь в форму от forms.google.com?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MCDM-Project. Часть 1. Концепция