C CountVectorizer начинаем ;)
Так и есть, новый state-of-the-art может каждые пару месяцев появляться, всё время нужно следить, учиться, переучиваться, дополнять или выкидывать. Но и «классические» методы из каких-нибудь дремучих 2010-х годов всё ещё активно используются и отлично себя показывают, так что приходится знать и то, и другое, и третье.
Зато не скучно :3
Действительно, если бы я предсказывал для 2 часов ночи — пришлось бы брать утекшие данные для 1 часа (или подставить предсказанные для него значения), но здесь всё зависит от того, для чего нужен прогноз и на какой период.
Если нужно, например, ежечасно отслеживать аномалии и каждый час можно добавлять в модель новые данные — то в долгосрочном прогнозе нет необходимости. Для прогноза на бОльший период придётся сдвигать начальный лаг модели вглубь, например, если мы хотим уметь прогнозировать на 12 часов вперёд, то и последнее доступное значение для модели должно быть смещено во времени на тот же период, чтобы избежать лика.
А можно полюбопытствовать, что значит «входит в число запрещенных» — провайдер блокирует доступ или администратор рабочей сети не даёт мемесы посмотреть? :)
Вчера точно не было, хотя распараллелить тут можно достаточно просто — разбить потоки по батчам страниц, например, штук по 50-100, а потом объединить в финальный датасет.
Честно говоря, до промышленных систем в таких масштабах дело не доходило, но можно посмотреть в сторону вот этих ребят — scrapinghub.com. Они как раз разрабатывают платформу, позволяющую быстро, эффективно и масштабируемо собирать данные.
Ограничения на число запросов в разных конфигурациях конечно же пробовали, к сожалению, не помогло. Тор активно банят, да и переключение между разными выходами — дело медленное, но все-таки выходных узлов достаточно для того, чтобы забаненные IP не повторялись, а в исследовательских целях, когда сам парсер лишь промежуточный инструмент, а не конечный продукт, можно и подождать.
Прокси — замечательный вариант, если действительно хорошо поискать или заплатить надежным поставщикам, но хотелось поэкспериментировать именно с тором и его передресацией запросов. А за ссылку большое спасибо, наверняка не раз в будущем пригодится!
Честно говоря, не пробовали, но в предыдущих проектах это не помогало. К тому же время отправки запросов и так не было распределено со строгими интервалами, некоторые страницы подгружались быстрее, некоторые медленнее, что зависело и от скорости сети, и от количества контента на странице.
Безусловно, ограничение числа запросов было первым опробованным методом, time.sleep() наше всё, однако он совершенно не спасал. Во-первых, 429-я ни разу не всплывала, а во-вторых, даже при увеличении интервала между запросами до одной минуты, бан всё равно приходил. Из чего мы и сделали вывод, что блокировка происходит при любом подозрении на автоматические запросы, и поэтому стали искать новые способы обхода.
Добрый день! Безусловно, вы правы, — цели бизнеса отличаются от целей данного соревнования. Для бизнеса важно понимать процесс взаимодействия клиента с предоставляемыми услугами, отслеживать тенденции, предупреждать возможный отток и т.д. Соответственно необходим ввод различных метрик для учёта паттернов и изменений, а также методов для удержания клиентов, отнесённых к зоне риска.
На хакатоне же необходимо было предсказать вероятность продления клиентом контракта с клубом на конкретный период времени, т.е. некоторого конечного события в текущем процессе. Конечно, поведенческие паттерны необходимы и здесь, и мы постарались в некотором виде учесть их временную структуру при создании финального набора данных (в том числе регулярность посещений, частоту звонков, сезоны наибольшей активности и т.п.). Однако, так как не было необходимости проводить анализ выживаемости, с построением временного распределения вероятности оттока клиента, мы решили отказаться от непосредственного анализа процессов.
В результате, получили некоторую «гибридную» систему, которая искала придуманные нами признаки во временных рядах и отмечала их наличие/отсутствие в конечном наборе данных. К сожалению, точность на тестовых данных организаторами не сообщалась, но на валидации AUC составил порядка 0.98.
Так и есть, новый state-of-the-art может каждые пару месяцев появляться, всё время нужно следить, учиться, переучиваться, дополнять или выкидывать. Но и «классические» методы из каких-нибудь дремучих 2010-х годов всё ещё активно используются и отлично себя показывают, так что приходится знать и то, и другое, и третье.
Зато не скучно :3
Действительно, если бы я предсказывал для 2 часов ночи — пришлось бы брать утекшие данные для 1 часа (или подставить предсказанные для него значения), но здесь всё зависит от того, для чего нужен прогноз и на какой период.
Если нужно, например, ежечасно отслеживать аномалии и каждый час можно добавлять в модель новые данные — то в долгосрочном прогнозе нет необходимости. Для прогноза на бОльший период придётся сдвигать начальный лаг модели вглубь, например, если мы хотим уметь прогнозировать на 12 часов вперёд, то и последнее доступное значение для модели должно быть смещено во времени на тот же период, чтобы избежать лика.
Прокси — замечательный вариант, если действительно хорошо поискать или заплатить надежным поставщикам, но хотелось поэкспериментировать именно с тором и его передресацией запросов. А за ссылку большое спасибо, наверняка не раз в будущем пригодится!
Безусловно, ограничение числа запросов было первым опробованным методом,
time.sleep()наше всё, однако он совершенно не спасал. Во-первых, 429-я ни разу не всплывала, а во-вторых, даже при увеличении интервала между запросами до одной минуты, бан всё равно приходил. Из чего мы и сделали вывод, что блокировка происходит при любом подозрении на автоматические запросы, и поэтому стали искать новые способы обхода.Судя по всему, на тестовых данных именно такое решение показало наибольшую точность
На хакатоне же необходимо было предсказать вероятность продления клиентом контракта с клубом на конкретный период времени, т.е. некоторого конечного события в текущем процессе. Конечно, поведенческие паттерны необходимы и здесь, и мы постарались в некотором виде учесть их временную структуру при создании финального набора данных (в том числе регулярность посещений, частоту звонков, сезоны наибольшей активности и т.п.). Однако, так как не было необходимости проводить анализ выживаемости, с построением временного распределения вероятности оттока клиента, мы решили отказаться от непосредственного анализа процессов.
В результате, получили некоторую «гибридную» систему, которая искала придуманные нами признаки во временных рядах и отмечала их наличие/отсутствие в конечном наборе данных. К сожалению, точность на тестовых данных организаторами не сообщалась, но на валидации AUC составил порядка 0.98.