Система, скорее всего, сначала обучается на очень и очень больших массивах данных в течение очень и очень долгого времени с использованием очень и очень большого количества ресурсов, но потом выдаёт ответы почти мнгновенно. Правда, для этого ей, скорее всего, потребуется куча данных, выученных на первом шаге, так что об использовании в оффлайне, скорее всего, речи не идёт.
А так действительно ресайз картинок делается? Тот же Lanczos, насколько я понимаю, зависит от точки. Т.е. свёртка там не с постоянным ядром, а с зависящим от текущей позиции.
А ещё, кажется, полноценная свёртка нам не нужна, т.к. не для каждого пикселя исходного изображения нужно её считать.
Хм, Ваш комментарий был оставлен 30 мая, когда результаты всех лотерей были известны, а оферы сделаны, так что из комментариев неочевидно, как Вы это сделали. Поясните, пожалуйста.
Ну память штука конечная, её всегда может не найтись.
Вот, кстати, интересно посмотреть на какую-нибудь схему с убывающим коэффициентом роста. Допустим, начинать с 2 с шагом в 0.1 после каждой реаллокации и насыщением на, допустим, 1.3
Вы про mjpeg?
Если да, то проверьте FF 34 (а ещё лучше — текущую dev ветку). multipart response довольно заковыристый стандарт, его реализация довольно закрученная (насколько я понимаю, ответ может быть совершенно произвольным, после картинки может придти HTML-страничка), но недавно пофиксили некоторые баги, связанные с ним.
Вообще, несмотря на распространённость данного формата в области стриминга с различных веб-камер, я бы посоветовал использовать что-то более «мейнстримовое», что используется медиаресурсами для онлайн-стриминга видео. Конкретных советов, к сожалению, дать не могу.
Очевидно, что если мы подствим x = φ, то получим 1 < 0, что неверно для любого k. Но если x = φ — ɛ, то первое слагаемое отрицательно, а для достаточно большого k ещё и очень велико по модулю за счёт экспоненциального роста xk-1
Так, для x = 1.5 нужно взять k=5. Подступаться к φ, конечно, не стоит ибо для x=1.61803398 мы получим k=38.
Следует заметить, что Zipfan Academy физически расположена в Сан-Франциско, а обучение у них очное. Вряд ли среди аудитории данного поста много людей, живущих в СФ и, при этом, не знающих о них.
С чего Вы решили, что машина просто усредняет? Более того, даже в случае банального усреднения результат был бы больше похож на классику ибо частота её прослушивания больше, чем частота всего остального.
Ничто не мешает на утренних данным запускать один алгоритм, на дневных другой, на вечерних третий, а в промежутках интерполировать. К времени года тоже можно привязаться аналогично. Ну а ситуация вокруг отражается интересами всех пользователей, на которых машина и обучается.
Не обязательно советовать на уровне исполнителей. Можно рекомендовать альбомы, треки, кусочки треков. Описанная в данной статье модель достаточно общая, чтобы работать в любой из этих ситуаций.
Ваша аналогия с почтовым спамом очень странная. Спам приходит сам по себе, а от использования сервиса можно отказаться.
А что должно быть в статье про рекомендательные системы? «Оптимизация некоего частного случая» является примером конкретного алгоритмы для решения конкретной задачи. Обилие математики обусловлено сложностью задачи.
На мой взгляд статья «Что такое рекомендательные системы» будет исключительно философско-болтологической, а для таких статей теперь существует GeekTimes. Эта же статья вполне подходит тематике Хабра.
«Хабрахабр» исключительно [...] профессиональный, хардкорный ресурс, где айтишники делятся опытом друг с другом и улучшают свои профессиональные навыки.
Вы гонитесь за точностью во всех случаях, что близко к сильному ИИ. Более того, далеко не каждый Ваш друг, я уверен, сможет так точно порекомендовать что-нибудь (даже зная ваши предпочтения), я уверен.
Эффективность математических моделей и машинного обучения в частности, как мне кажется, связана с тем, что многие вещь в мире хоть и сложны и, кажется, почти случайны, всё же имеют некоторую структуру под собой. Как бы изменичивы Ваши предпочтения ни были, это всё же не белый шум. Опять же, машины учатся хорошо работать в среднем, а не во всех случаях. Если раз в году на полнолуние после дождичка в четверг Вы слушаете Бразильские народные песни, а всё остальное время исключительно классику, то алгоритм вряд ли научится советовать Вам бразильскую музыку по тем самым дням. Хотя бы потому что такой сценарий неотличим от случая, когда к Вам приехали в гости родственники и какая-нибудь 12-летняя племянница захотела послушать Ранеток, которых Вы, в рассматриваемой ситуации, слушать не хотите.
Рассматриваемый Вами случай специфичен тем, что он не располагает никаких фидбеком от Вас в момент рекомендации. Ваш друг тоже ничего Вам не посоветует, если Вы будете сидеть с закрытым ртом и ничего ему про своё текущее состояние не скажете. Если же соответстующий фидбек у системы есть (Вы, например, решили что-то послушать, а машина на той же страничке предложила Вам что-то ещё), то у системы есть шанс на успех ибо
1. Ваши предпочтения не белый шум
2. Вы не единственный пользователь системы
Кого будет накручивать радио я не понял. Я ведь ни слова не сказал о том, какую модель, как и на каких данных мы собрались обучать. Более того, я нигде не говорил про то, что рекомендации должны быть детерминированы.
Во-первых, я не говорил, что для нормализации достаточно названия сверить. Посыл мой был в том, что нормализация есть отдельная задача, ортогональная рекомендации.
Можно, например, анализировать аудиопток, отсеивая таким образом дубликаты. Или как-то иначе, суть от этого не изменится: это отдельная задача со своими методами.
К чему здесь Зайцы — непонятно. Надо было бы им строить рекомендации или делать другую аналитику — привели бы свою свалку в порядок. Тут, вроде, не plug-and-play решение предлагается.
Касательно Вашего примера:
Я считаю, что задачей рекомендательных систем является преподнесение чего-то нового, о чём пользователь раньше не знал. Другой вариант трека, конечно, может быть интересен, но в меньшей степени, чем совершенно новый неизвестный ранее трек (возможно, нового исполнителя, у которого есть ещё много «вкусного»).
Опять же, если человек знает исполнителя, что мешает ему пойти и послушать всю его дискографию? На мой взгляд, в рекомендации уже известного исполнителя смысла мало (тут я лукавлю, и это зависит от того, как мы собираемся использовать систему. В случае радио, например, мы хотим составлять плейлист автоматически, не требуя от пользователя даже присутствия. Но в таком случае нет никакой разницы, поставим мы Машину времени или Машину Времени).
Ну а вообще, в случае несколькиз различных треков можно сделать по-разному:
1. Если мы уверены в качестве контента, а различия невелики, то можно все дубли считать за один трек, а проигрывать случайный.
2. Если различия велики (акустическая версия, например), то есть смысл создать отдельную запись под такой трек, отразив это в названии.
Более того, можно усложнить модель, введя таксономию на разных версия одной песни, так что рекомендовать мы их всё-таки будем, но с меньшим «весом».
«Машина времени» и «Машина Времени» — проблема нормализации данных, а не рекомендательного алгоритма. Алгоритм ожидает получить данные на вход в таком виде, что все исполнители различны. Поскольку что «Машина времени», что «Машина Времени» для него всего-лишь 2 набора байт, а распознавать естественный язык для машин пока непросто, приходится придумывать какие-то правила, приводящие данные к некой стандартной форме.
В общем, это обычный баг, по какой-то причине Last.FM не смог / не захотел использовать уже существующего исполнителя, что ввело рекомендательный алгоритм в замешательство. Общему подходу от этого ни жарко, ни холодно — с таким же успехом можно было где-нибудь в алгоритме заменить умножение на сложение, только баг был бы виден лучше.
Не стоит ожидать от математических алгоритмов совершенства, они всегда основаны на некоторых предположениях (далеко не всегда адекватных реальному миру).
Вообще, в подобных задачах обычно полноценный градиентный спуск слишком (вычислительно) сложен, ибо размер обучающего множества может быть очень велик, вычислять такое на каждой итерации дорого. На практике используется только стохастический градиентный спуск, у которого из-за стохастичности имеются шумы, так что сходится он ещё дольше, а на шаг нужно налагать условия Роббинса-Монро.
Судя по всему, оба видеосета сняли одновременно, т.к. одни и те же люди одеты в одинаковую одежду и находятся в тех же обстановках (сравните картинки с этой статьей).
Видел человека, приехавшего по J1 из Португалии и водившего машину в Калифорнии. Мне сказали, что подводный камень здесь в том, что водить так можно только 3-6 месяцев (точно не помню), а потом придётся местные права получать.
А ещё, кажется, полноценная свёртка нам не нужна, т.к. не для каждого пикселя исходного изображения нужно её считать.
Вот, кстати, интересно посмотреть на какую-нибудь схему с убывающим коэффициентом роста. Допустим, начинать с 2 с шагом в 0.1 после каждой реаллокации и насыщением на, допустим, 1.3
Если да, то проверьте FF 34 (а ещё лучше — текущую dev ветку). multipart response довольно заковыристый стандарт, его реализация довольно закрученная (насколько я понимаю, ответ может быть совершенно произвольным, после картинки может придти HTML-страничка), но недавно пофиксили некоторые баги, связанные с ним.
Вообще, несмотря на распространённость данного формата в области стриминга с различных веб-камер, я бы посоветовал использовать что-то более «мейнстримовое», что используется медиаресурсами для онлайн-стриминга видео. Конкретных советов, к сожалению, дать не могу.
Для любого x < φ найдётся такое k, что
xk < xk-2 + … + 1
Это следует из тех соображений, что
xk < xk-2 + … + 1
эквивалентно
xk (x-1) < xk-1 — 1
xk+1 — xk — xk-1 + 1 < 0
xk-1(x2 — x — 1) + 1 < 0
Очевидно, что если мы подствим x = φ, то получим 1 < 0, что неверно для любого k. Но если x = φ — ɛ, то первое слагаемое отрицательно, а для достаточно большого k ещё и очень велико по модулю за счёт экспоненциального роста xk-1
Так, для x = 1.5 нужно взять k=5. Подступаться к φ, конечно, не стоит ибо для x=1.61803398 мы получим k=38.
Ничто не мешает на утренних данным запускать один алгоритм, на дневных другой, на вечерних третий, а в промежутках интерполировать. К времени года тоже можно привязаться аналогично. Ну а ситуация вокруг отражается интересами всех пользователей, на которых машина и обучается.
Не обязательно советовать на уровне исполнителей. Можно рекомендовать альбомы, треки, кусочки треков. Описанная в данной статье модель достаточно общая, чтобы работать в любой из этих ситуаций.
Ваша аналогия с почтовым спамом очень странная. Спам приходит сам по себе, а от использования сервиса можно отказаться.
На мой взгляд статья «Что такое рекомендательные системы» будет исключительно философско-болтологической, а для таких статей теперь существует GeekTimes. Эта же статья вполне подходит тематике Хабра.
Вообще, на хабре уже есть статьи про рекомендательные системы, вводную можно почерпнуть оттуда.
Как писали ТМ в статье о разделении
Эффективность математических моделей и машинного обучения в частности, как мне кажется, связана с тем, что многие вещь в мире хоть и сложны и, кажется, почти случайны, всё же имеют некоторую структуру под собой. Как бы изменичивы Ваши предпочтения ни были, это всё же не белый шум. Опять же, машины учатся хорошо работать в среднем, а не во всех случаях. Если раз в году на полнолуние после дождичка в четверг Вы слушаете Бразильские народные песни, а всё остальное время исключительно классику, то алгоритм вряд ли научится советовать Вам бразильскую музыку по тем самым дням. Хотя бы потому что такой сценарий неотличим от случая, когда к Вам приехали в гости родственники и какая-нибудь 12-летняя племянница захотела послушать Ранеток, которых Вы, в рассматриваемой ситуации, слушать не хотите.
Рассматриваемый Вами случай специфичен тем, что он не располагает никаких фидбеком от Вас в момент рекомендации. Ваш друг тоже ничего Вам не посоветует, если Вы будете сидеть с закрытым ртом и ничего ему про своё текущее состояние не скажете. Если же соответстующий фидбек у системы есть (Вы, например, решили что-то послушать, а машина на той же страничке предложила Вам что-то ещё), то у системы есть шанс на успех ибо
1. Ваши предпочтения не белый шум
2. Вы не единственный пользователь системы
Кого будет накручивать радио я не понял. Я ведь ни слова не сказал о том, какую модель, как и на каких данных мы собрались обучать. Более того, я нигде не говорил про то, что рекомендации должны быть детерминированы.
Можно, например, анализировать аудиопток, отсеивая таким образом дубликаты. Или как-то иначе, суть от этого не изменится: это отдельная задача со своими методами.
К чему здесь Зайцы — непонятно. Надо было бы им строить рекомендации или делать другую аналитику — привели бы свою свалку в порядок. Тут, вроде, не plug-and-play решение предлагается.
Касательно Вашего примера:
Я считаю, что задачей рекомендательных систем является преподнесение чего-то нового, о чём пользователь раньше не знал. Другой вариант трека, конечно, может быть интересен, но в меньшей степени, чем совершенно новый неизвестный ранее трек (возможно, нового исполнителя, у которого есть ещё много «вкусного»).
Опять же, если человек знает исполнителя, что мешает ему пойти и послушать всю его дискографию? На мой взгляд, в рекомендации уже известного исполнителя смысла мало (тут я лукавлю, и это зависит от того, как мы собираемся использовать систему. В случае радио, например, мы хотим составлять плейлист автоматически, не требуя от пользователя даже присутствия. Но в таком случае нет никакой разницы, поставим мы Машину времени или Машину Времени).
Ну а вообще, в случае несколькиз различных треков можно сделать по-разному:
1. Если мы уверены в качестве контента, а различия невелики, то можно все дубли считать за один трек, а проигрывать случайный.
2. Если различия велики (акустическая версия, например), то есть смысл создать отдельную запись под такой трек, отразив это в названии.
Более того, можно усложнить модель, введя таксономию на разных версия одной песни, так что рекомендовать мы их всё-таки будем, но с меньшим «весом».
В общем, это обычный баг, по какой-то причине Last.FM не смог / не захотел использовать уже существующего исполнителя, что ввело рекомендательный алгоритм в замешательство. Общему подходу от этого ни жарко, ни холодно — с таким же успехом можно было где-нибудь в алгоритме заменить умножение на сложение, только баг был бы виден лучше.
Не стоит ожидать от математических алгоритмов совершенства, они всегда основаны на некоторых предположениях (далеко не всегда адекватных реальному миру).
В ALS совсем не то, используется тот факт, что при зафиксированной матрице P или Q имеется аналитическое решение.