Т.е., отвечая совсем конкретно на ваш вопрос, если все ручки примерно одинаковые, то большой разницы между m1 и m2 не будет. А если одна ручка заметно лучше других, то m2 будет заметно меньше m1.
Можно, но это зависит от соотношений между ручками. Собственно, теорема Auer et al. заключается в том, что regret получится логарифмический, причём порядок величины там \sum_{неоптимальные ручки} ln(n) / Delta_i, где Delta_i — разница в ожиданиях выигрышей между i-й ручкой и оптимальной. Простыми словами это значит довольно естественную вещь: чем сильнее оптимальная ручка выделяется на фоне остальных, тем меньше будет regret (тем быстрее мы найдём оптимальную), причём зависимость будет буквально обратно пропорциональная.
Так, может, действительно out? Я, честно говоря, не могу с ходу сообразить, какое должно быть потребление – понятно, что минимум число топиков умножить на число документов плюс число слов, но это минимум…
Хабр большой, мы рекомендуем страницы, а не сайты. Например, вот эта статья попала в компанию к этой и этой. А вот эта – к совсемдругим. Но в основном более технические группы, конечно.
Это задумывалось как цикл статей по рекомендательным системам. Эта конкретная запись пообщее вышла, но я надеюсь уже в следующей части вернуться к теме.
Некоторые предложения про наивный байес прямо из моих лекций взяты; про саму теорему я тоже не в первый раз пишу, не исключено, что начинаю повторяться. :)
(1) Конечно, изучали. Это отдельный интересный вопрос: главный урок Netflix Prize — в том, как объединять кучу разных моделей в одну рекомендацию; когда-нибудь и до него дойдём.
(2) Боюсь, секрет. :)
Я пока могу просто ссылку дать: graphlab.org
Там есть прямо примеры кода сильно параллельных рекомендательных систем.
Подробно пока руки не дошли описывать, но когда-нибудь текст о рекомендациях на графлабе обязательно будет.
Да, ну так ведь предыдущий скрипт так и делает: кушает данные в формате
<id пользователя>; <id продукта>; <оценка>
и выдаёт ответ в виде
<id пользователя>; <список факторов>
и
<id продукта>; <список факторов>
Чтобы затем сделать рекомендацию, нужно взять вектор факторов пользователя и умножить его скалярно на вектор факторов продукта (и даже это, кажется, в скрипте тоже было). Обращение к базам данных, каюсь, не вписывал, но это уж совсем не по теме.
Спасибо за отличные вопросы! На них, безусловно, ответы уже существуют. :) Например, особенно интересный вопрос – про «только что пришедших», особенно если его чуть обобщить: пользователь пришёл на сайт, сделал двадцать лайков и хочет, чтобы что-нибудь тут же изменилось, а пересчёт запланирован на завтра. Это так называемые онлайн-рекомендации, алгоритмы есть, постараюсь про них рассказать. Но вообще я планировал переходить к частностям чуть позже, когда разберусь с концептуальными вопросами – уже шесть статей было, а я ещё, чёрт возьми, про теорему Байеса не рассказал. :)
P.S. Кстати, я пока поддерживал оглавление на своей страничке: logic.pdmi.ras.ru/~sergey/index.php?page=popular
хотя это, конечно, тоже трудно назвать хорошей рекламой. :)
Оглавление – это отличная мысль! Вы не знаете, на хабре можно сделать заглавный пост, который будет всегда висеть сверху?
Про практическое применение не очень понял – то есть я вроде бы стараюсь, даже вот работающий код запостил. Понятно, конечно, что я не могу для каких-то неизвестных мне проектов конкретные решения предлагать, а могу только объяснять общую механику происходящего. Но вот код, который был в прошлый раз, действительно лёг в основу одной из стратегий, которые реально работают в surfingbird (там, конечно, в production код слегка посложнее :), но по сути именно такой).
На случай большого количества данных – вообще-то это и есть алгоритмы для большого количества данных. :) Вряд ли у вас база рейтингов больше, чем у Netflix и Amazon. Разложение матриц – алгоритм как раз для того, чтобы от O(M*N) перейти к O(M+N); про скорость сходимости так сразу с ходу не скажу, надо посмотреть, но в любом случае вероятностное разложение матриц хорошо параллелизуется – когда-нибудь обязательно расскажу о параллельной реализации на GraphLab. Так что да, именно эти алгоритмы и работают для больших массивов данных, и именно их и надо реализовывать в первую очередь.
В основном только статьи; статей очень много, они легко гуглятся по «SVD in collaborative filtering». Какого-то единого объемлющего текста пока не видел – может быть, я в итоге напишу какое-то к нему приближение (не здесь, а в виде единого текста).
Хабр большой, мы рекомендуем страницы, а не сайты. Например, вот эта статья попала в компанию к этой и этой. А вот эта – к совсем другим. Но в основном более технические группы, конечно.
(1) Конечно, изучали. Это отдельный интересный вопрос: главный урок Netflix Prize — в том, как объединять кучу разных моделей в одну рекомендацию; когда-нибудь и до него дойдём.
(2) Боюсь, секрет. :)
(2) Боюсь, секрет. :)
Там есть прямо примеры кода сильно параллельных рекомендательных систем.
Подробно пока руки не дошли описывать, но когда-нибудь текст о рекомендациях на графлабе обязательно будет.
И именно поэтому собираюсь писать более общо и концептуально.
<id пользователя>; <id продукта>; <оценка>
и выдаёт ответ в виде
<id пользователя>; <список факторов>
и
<id продукта>; <список факторов>
Чтобы затем сделать рекомендацию, нужно взять вектор факторов пользователя и умножить его скалярно на вектор факторов продукта (и даже это, кажется, в скрипте тоже было). Обращение к базам данных, каюсь, не вписывал, но это уж совсем не по теме.
Спасибо за отличные вопросы! На них, безусловно, ответы уже существуют. :) Например, особенно интересный вопрос – про «только что пришедших», особенно если его чуть обобщить: пользователь пришёл на сайт, сделал двадцать лайков и хочет, чтобы что-нибудь тут же изменилось, а пересчёт запланирован на завтра. Это так называемые онлайн-рекомендации, алгоритмы есть, постараюсь про них рассказать. Но вообще я планировал переходить к частностям чуть позже, когда разберусь с концептуальными вопросами – уже шесть статей было, а я ещё, чёрт возьми, про теорему Байеса не рассказал. :)
logic.pdmi.ras.ru/~sergey/index.php?page=popular
хотя это, конечно, тоже трудно назвать хорошей рекламой. :)
Про практическое применение не очень понял – то есть я вроде бы стараюсь, даже вот работающий код запостил. Понятно, конечно, что я не могу для каких-то неизвестных мне проектов конкретные решения предлагать, а могу только объяснять общую механику происходящего. Но вот код, который был в прошлый раз, действительно лёг в основу одной из стратегий, которые реально работают в surfingbird (там, конечно, в production код слегка посложнее :), но по сути именно такой).
На случай большого количества данных – вообще-то это и есть алгоритмы для большого количества данных. :) Вряд ли у вас база рейтингов больше, чем у Netflix и Amazon. Разложение матриц – алгоритм как раз для того, чтобы от O(M*N) перейти к O(M+N); про скорость сходимости так сразу с ходу не скажу, надо посмотреть, но в любом случае вероятностное разложение матриц хорошо параллелизуется – когда-нибудь обязательно расскажу о параллельной реализации на GraphLab. Так что да, именно эти алгоритмы и работают для больших массивов данных, и именно их и надо реализовывать в первую очередь.
Да, тот самый.