Мне любопытно, какие методы/подходы преодолевают проблема «холодного старта», когда при входе нового пользователя или элемента в систему из-за отсутствия информации об этой новой сущности, рекомендация является проблемой.Как адаптировать мой механизм рекомендаций к холодным пускам?
Я могу придумать некоторые рекомендации, основанные на прогнозировании (например, пол, национальность и т. Д.).
Возможно, есть моменты, когда вы просто не должны давать рекомендации? «Недостаточно данных» следует квалифицировать как один из тех случаев.
Я просто не вижу, как рекомендации по прогнозированию на основе «пола, национальности и т. Д.» Будут более чем стереотипами.
IIRC, такие места, как Amazon, создавали свои базы данных на некоторое время, прежде чем выносить рекомендации. Это не та вещь, которую вы хотите ошибаться; есть много историй о несоответствующих рекомендациях, основанных на недостаточных данных.
Это было задано несколько раз раньше (естественно, я не могу найти эти вопросы сейчас: /, но общий вывод было бы лучше избегать таких рекомендаций. В разных частях мира одни и те же имена принадлежат разным полам, и поэтому на ...
Рекомендации, основанные на «похожих пользователей понравилось ...» явно должны ждать. вы можете выдавать купоны или другие стимулы для опроса респондентов, если вы абсолютно привержен делать предсказания на основе пользовательского сходства.
Есть два других способа холодного запуска двигателя рекомендации.
Много потенциальных ловушек во всех этих случаях, которые слишком распространены.
Как и следовало ожидать, здесь нет бесплатного обеда. Но подумайте об этом так: двигатели рекомендаций не являются бизнес-планом. Они просто улучшают бизнес-план.
Вы можете использовать систему рекомендаций для холодного запуска.
Существует два типа систем рекомендаций; совместная фильтрация и контент-поддержка. Системы на основе контента используют метаданные о том, что вы рекомендуете. Вопрос в том, какие метаданные важны? Второй подход - это совместная фильтрация, которая не заботится о метаданных, она просто использует то, что люди делали или говорили об элементе, чтобы сделать рекомендацию. При совместной фильтрации вам не нужно беспокоиться о том, какие термины в метаданных важны. На самом деле вам не нужны метаданные, чтобы сделать рекомендацию. Проблема совместной фильтрации заключается в том, что вам нужны данные. Прежде чем у вас будет достаточно данных, вы можете использовать рекомендации на основе контента. Вы можете предоставить рекомендации, основанные на обоих методах, и вначале иметь 100% контентную основу, а затем, когда вы получите больше данных, начните смешивать в основе совместной фильтрации. То есть метод, который я использовал в прошлом.
Еще одна распространенная методика заключается в том, чтобы обрабатывать контентную часть как простую проблему поиска. Вы просто помещаете метаданные в текст или тело своего документа, а затем индексируете свои документы. Вы можете сделать это с Lucene & Solr без написания кода.
Если вы хотите знать, как основной фильтрации работы совместной, проверьте главу 2 «Программирование Коллективного разума» от Тоби Сегаран
Работая над этой проблемой самостоятельно, но эта статья от Microsoft на машинах больцмановских выглядит стоит: http://research.microsoft.com/pubs/81783/gunawardana09__unified_approac_build_hybrid_recom_system.pdf
есть три вещи, которые необходимы для решения холодного запуска задачи:
данные должны были профилированной таким образом, что у вас есть много различных функций (с данными об изделии я e термин, используемый для «функции», часто является «классификационным аспектом»). Если вы не должным образом профилируете данные, поскольку они входят в дверь, ваш механизм рекомендаций останется «холодным», так как он не имеет ничего, чтобы классифицировать рекомендации.
НАИБОЛЕЕ ВАЖНО: Вам нужен цикл обратной связи с пользователем, с помощью которого пользователи могут просматривать рекомендации, предлагаемые механизмом персонализации. Например, кнопка «Да/Нет» для «Было ли это предложение полезной?» должен поставить в очередь обзор участников в одном наборе учебных материалов (т. е. набор данных «Рекомендовать») другому набору учебных материалов (т. е. НЕ рекомендовать набор учебных материалов).
Модель, используемая для (Рекомендовать/НЕ рекомендую) предложения, никогда не должна рассматриваться как рекомендация одного размера. В дополнение к классификации продукта или услуги, предлагаемой клиенту, как фирма классифицирует каждый конкретный вопрос клиента. При правильном функционировании следует ожидать, что клиенты с различными функциями получат разные предложения (Рекомендовать/НЕ рекомендовать) в данной ситуации. Это будет «персонализация» части механизмов персонализации.
Это лучший ответ и действительно заслуживает галочку. Я бы добавил, что алгоритмы бандитов могут сыграть определенную роль в обнаружении базовых ставок для новых продуктов или определении компромисса между подходами на основе контента и совместной работы. – SetJmp