Прикладная наука о данных и машинное обучение  — «Почему мы в световых годах от сингулярности»

Я помню свое раздражение после часовой беседы с специалистом по данным, который продолжал настаивать на том, что «нейронные сети» не могут быть эффективно обучены, если данные не будут тщательно очищены, реструктурированы и аннотированы. «Затем, — сказал он, — требуется опыт, чтобы выбрать тип модели обучения и настроить ее гиперпараметры».

Искусственный интеллект в 2019 году — не такой уж он и умный

В то время как некоторые заняты размышлениями о сингулярности (момент, когда ИИ заменяет человеческий интеллект), я потратил последние две недели на обучение моделей только для того, чтобы заметить, что результаты были мусором из-за моего отсутствия усердия с точки зрения очистки входных данных. «Глупые вещи», такие как «https», «http» и полные URL-адреса, искажающие облака слов и диаграммы, были лишь верхушкой очень большого айсберга, но уже показали количество времени и циклов ЦП / ОЗУ, которые можно потратить впустую, если не проводить постоянное тестирование. промежуточные результаты.

Даже автоматическое машинное обучение не дает автоматически полезных результатов

Четыре интересные части автоматического машинного обучения — это автоматическая очистка данных, автоматический выбор модели, автоматическая гиперпараметризация и сравнение нескольких моделей друг с другом, чтобы иметь возможность выбрать ту, которая имеет наименьшую частоту ошибок. Хотя все это фантастично, без понимания ваших источников данных со всеми их зависимостями, конкретными характеристиками столбцов и ненужными точками данных, которые продлевают процесс построения модели на часы или дни, автоматическое машинное обучение по-прежнему не является готовым процессом. но предоставляет барьеры, которые помогают опытным пользователям, которым не обязательно быть специалистами по данным, достичь хорошего уровня успеха.

Пример. В приведенном ниже наборе данных показан процент проектов, в которых специалисты по данным используют модели машинного обучения. Однако проблема с базовым набором данных заключалась в определении «ученого данных», «инженера данных», «разработчика, разбирающегося в данных» и кого-то, кто только предполагает, что он специалист по данным, но не имеет квалификации. Короче говоря, чтобы получить приведенную ниже диаграмму, нам нужно было пройти ряд дополнительных шагов, чтобы исключить около 40% строк из набора данных, поскольку они включали информацию от нерелевантных респондентов. И, как позже выяснилось, снизило «внедрение машинного обучения» почти на 20%.

Вот в чем дело: вы можете это сделать, но сколько времени это займет?

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

Пример: Требуется перевод. На приведенной ниже диаграмме показано количество вопросов в службу поддержки для основных платформ управления контейнерами. Но почему Docker так низко показывает? Тег docker-ee в StackOverflow, безусловно, правильный, но оказывается, что люди не очень хорошо используют этот тег из-за несколько неуклюжего названия продукта: Docker Enterprise Edition. Но мы также не можем просто использовать тег «docker», так как большинство людей используют этот тег для всего, что связано с контейнерами, но в большинстве случаев не имеет ничего общего с коммерческой версией Docker Enterprise Edition. Это означает, что мы должны выяснить, как поместить эту информацию в нашу таблицу данных, чтобы мы могли создать более реалистичный график рынка. Это включает в себя поиск и анализ строк, которые относятся к Docker EE, но не применяют тег. Излишне говорить, что это трудоемкая процедура, с которой будут бороться специалисты по обработке данных, поскольку они могут не знать достаточно о предмете, чтобы разработать правила для автоматической маркировки записей как «docker-ee».

Сначала извлечение, затем очистка, затем анализ — модель машинного обучения/ИИ на последнем месте

Я много раз писал о том, что 90% релевантных данных недоступны для людей, которые могли бы с их помощью строить офигенные прогностические модели. Но постоянные записи об этом заставили меня почти забыть о настоящей боли, связанной с извлечением данных в удобном для использования формате. Я задокументирую свой процесс в другом посте, но только сейчас: знать, как получить доступ к источнику данных, — это не то же самое, что уметь извлекать соответствующие части этих данных в удобном для использования формате. А затем подключите его к остальным источникам данных таким образом, чтобы не включать неявные предположения, которые, если они неверны, могут исказить и сделать недействительным весь проект.

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