Online алгоритм, или Ещё более большие данные

[ofrei]

Тенденция такова, что нам придётся работать на всё больших данных и на динамически пополняемых коллекциях. Все случаи, когда нам дали готовую коллекцию -- это история про научное исследование, пилотный проект или пресейл. В реальных приложениях мы строим первую модель именно так, но потом она начинает пополняться порциями. Это важный мессадж: все реальные коллекции растут... если Ваша коллекция не растёт, значет Вы пока что играете в бирюльки. BigARTM к этому неплохо подготовлен, но по-настоящему мы с этим ещё не сталкивались.

Наиболее естестественным представляется такой подход:

• стартовую версию модели строить оффлайновым алгоритмом по коллекции настолько большой, насколько это возможно,
• динамически поступающие данные тематизировать порциями при фиксированной матрице Фи,
• изредка прогонять несколько итераций по последним поступившим порциям и слегка обновлять Фи,
• ещё реже делать освежающую итерацию по всей коллекции.

Кажется, что такой смешаный онлайн-оффлайн режим можно протестировать и без изменений в ядре.
Кроме этого нужно окончательно разобраться с чистым онлайн алгоритмом, по которому все еще есть много нерешенных проблем.
Эти попытки надо обязательно продолжать, иначе мы сильно упираемся в длительность экспериментов в каждом проекте.

Будет ли смешаный онлайн-оффлайн алгоритм строить модели так же хорошо, как оффлайновый и так же быстро, как онлайновый?

[ofrei]

Было бы здорово иметь коллекцию arXiv для эскпериментов с online алгоритмом (см. тикет #45 ). Но это не обязательно - можно начать с wiki, коллекция habr, или др. большой коллекции.

[ofrei]

Вопрос - на каком железе проводить вычисления?

[AnyaP]

Можно начать со своего ноутбука и небольших коллекций. Задача - выработать рекомендации для параметров создания модели и метода fit_online(), уже реализованного в библиотеке. Следующая задача - перейти к более хитрым схемам, описанным в тикете.

[AnyaP]

В оригинальной статье Хоффмана, из которой взяты текущие дефолты, значения tau=1024, kappa=0.7 подходят для очень маленьких батчей (десятки документов). Т.к. обычно в наших батчах 100-1000 документов, а между обновлениями обрабатываются несколько батчей (update_every > 1), то кажется разумным уменьшать tau (в статье tau=1, kappa=0.5 для 16000 документов).

Другое наблюдение - дефолтные параметры не приводят к параллельной обработке, что может смущать наших пользователей. Дело в update_every=1, которое в таком случае логичнее было бы положить равным num_processors_count.

[AnyaP]

@ofrei, напомни, пожалуйста, происходят ли какие-то перемасштабирования счетчиков перед тем, как к ним применяются decay_weight и apply_weight (которые в свою очередь могут выражаться через rho).

Насколько я помню, в оригинальной статье счетчики по куче старых батчей и по одному новому приводились к одному масштабу (новые счетчики умножались на число документов во всей коллекции и делились на число документов в батче). Как это сделано у нас? Это важно понимать, чтобы задавать интуитивно осмысленные decay_weight и apply_weight.

@indianjoe92 @izorin, разве у вас не возникает таких вопросов? Получилось ли провести первые эксперименты с режимами работы алгоритма?

[ofrei]

@AnyaP в BigARTM коэффициенты apply_weight и decay_weight напрямую применяются к n_wt счетчикам, без машстабирования. Это легко проверить используя API merge_model - а примеры к ней есть тут. Внутри fit_online используется в точности тот же merge_model, с весами decay_weight (к старым счетчикам nwt) и apply_weight (к новым nwt_hat).

[AnyaP]

@sashafrey Саша, спасибо за ответ!
Кажется, это знание нам немного помогло и алгоритм стал дрессироваться лучше.
Но возник вот такой еще более важный вопрос (+ @arti32lehtonen)

Что происходит со счетчиками nwt в начале нового онлайнового прохода по коллекции? Обнуляются ли они (и вместо них используется инициализация по pwt) или переиспользуются (как будто бы никто и не заметил, что документы пошли по второму кругу)?

Есть подозрение что обнуляются, и есть подозрение, что это плохо. Потому что получается, что нашу супер-хорошую Фи, обученную первым проходом, мы поиспользуем только для оценки тем в первом батче и забудем. А дальше будем использовать смесь инициализации и счетчиков по первому батчу, и будем копить наши знания заново.

[ofrei]

@AnyaP Я думаю что nwt счетчики переиспользуются.

Давайте вместе разберемся, что происходит в питон интерфейсе. В ядре на С++ с nwt ничего не делается. Для начала посмотрим, что происходит при первом онлайн-проходе по коллекции:

1. В методе ARTM.initialize() обе матрицы (pwt и nwt) инициализируются одинаковыми случайными числами.
2. В ARTM.fit_online() просто вычисляются коэффициенты apply_weigth и decay_weight. При этом кол-во обработанных батчей записано в _num_online_processed_batches.

При втором вызове ARTM.fit_online параметр _num_online_processed_batches уже не ноль, поэтому коэффициенты apply_weigth и decay_weight должны без резких скачков продолжать значения использованный в прошлом fit_online.

Про инициализацию nwt матрице нигде речи нет... Поэтому я думаю что nwt счетчики переиспользуются.