Скажем, на выходе после кодирования словаря получается 50000 фичей. А что есть редкость признака? По идее редкие признаки, принимающие положительные значения для целевого класса, наоборот могут сильно помогать при классифицировать.
Из-за большого количества фичей время подбора гиперпараметров даже для простой логистической регрессии и бэггинга становится огромным. Как с этим быть? Вообще под high-dimensional sparse данными я подразумевал не только тексты, а любые варианты bag of something. Любые категориальные фичи имеющие большое количество значений.
SMTP запрос только для проверки валидности email-а — это очень дорого.
Экономия будет:
1. на CPU при генерации писем (случай, когда письма под пользователя, а не у всех одинаковое)
2. времени: почтовики будут охотнее принимать письма от вашего MTA, если не пытаться им в поле to всякий шлак отправлять
Если у вас «сравнительно небольшой объем поток посетителей», то этой действительно будет проблемой.
В ином случае, надо считать что будет выгодней: сэкономленные ресурсы + в целом более качественная база против получения аккаунтов директоров неких крупных фирм Н с невалидным email-адресом.
Возможно на сравнительно небольшом потоке пользователей и рассылок такой подход подойдет.
Однако, в случае если доп. проверка отфильтрует 5-10% ошибочных email-адресов, то будет сэкономлено соответствующее количество ресурса затраченного на генерацию писем (как минимум).
На восстановление рабочего состояния после 3 лет непрерывной работы ушло 2,5 месяца в США. Ничего не делал. Просто отыдхал, ел, купался, спал. И голова освежилась, как пелена сошла, и зрение лучше стало.
Да, кстати, такая же ситуация абсолютно. Серфил хромом блоги, словил Winlock. После рестора системы DrWeb CureIt ничего не нашел… Вот уж не знаю, то ли отрестирились файлы, то ли 0-day бага не слишком опасная оказалась.
Кодировку я не реализовывал. Исходники брал прямо самого WinSCP. Исходники могу Вам выслать, если интересно. Вы не поделитесь процедурой кодировки (если на С#)?
Экономия будет:
1. на CPU при генерации писем (случай, когда письма под пользователя, а не у всех одинаковое)
2. времени: почтовики будут охотнее принимать письма от вашего MTA, если не пытаться им в поле to всякий шлак отправлять
Головной боли меньше будет =)
В ином случае, надо считать что будет выгодней: сэкономленные ресурсы + в целом более качественная база против получения аккаунтов директоров неких крупных фирм Н с невалидным email-адресом.
Однако, в случае если доп. проверка отфильтрует 5-10% ошибочных email-адресов, то будет сэкономлено соответствующее количество ресурса затраченного на генерацию писем (как минимум).
Хэппи энд :)
Но возникает вопрос, как систему обучают?