germiningeld

Грубо говоря, Data Science занимается тем, чтобы находить в данных закономерности, проверять их и использовать для решения таких задач. Но когда смотришь на эту область со стороны, всё кажется несколько проще, чем оказывается на практике.

Кажется, что достаточно загрузить данные в модель

До того как я начал обучение, моё представление об этой работе было примерно таким:

данные + модель = предсказание.

В каком-то смысле так оно и есть. Допустим, у нас есть данные о десятках тысяч подержанных автомобилей: марка, модель, год выпуска, пробег, мощность двигателя, комплектация, регион продажи и другие характеристики.

С этими данными можно решать совершенно разные задачи.

Например, можно попытаться определить справедливую рыночную цену автомобиля. Мы показываем модели множество машин с уже известными ценами, а затем передаём характеристики нового объявления. На выходе получаем ориентировочную стоимость: условно, такая машина при таких параметрах должна стоить около 2,5 миллиона рублей.

Именно что-то подобное мы уже видим на площадках по продаже автомобилей. Вы выставляете машину за 2,3 миллиона, а сервис показывает, что цена ниже средней по рынку и предложение выглядит выгодным. Или наоборот — что автомобиль заметно дороже похожих вариантов. За простой надписью вроде «хорошая цена» уже стоит работа с большим количеством накопленных данных.

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

Получается, данные могут быть почти теми же, а вопрос к ним — совершенно другим. В одном случае мы хотим получить число, в другом — определить категорию или вероятность события.

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

Что вообще называется моделью

Слово «модель» звучит сложнее, чем сама базовая идея. В самом простом представлении модель — это математическая зависимость, которая получает набор значений и на их основе выдаёт результат.

Допустим, мы хотим оценить стоимость квартиры. У неё есть площадь, количество комнат, этаж, расстояние до центра, возраст дома и множество других характеристик.

Очень упрощённо это можно представить так:

цена = базовое значение + площадь × коэффициент + комнаты × коэффициент + ...

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

Конечно, реальные модели могут быть намного сложнее такой формулы. Но основная идея сохраняется: мы передаём модели некоторый набор данных, а она по определённому математическому правилу рассчитывает результат.

При этом коэффициенты внутри модели нам необязательно придумывать самим. Можно взять тысячи квартир, для которых цена уже известна, и подобрать такие коэффициенты, при которых расчёт модели будет как можно ближе к реальным ценам.

Это и есть обучение модели.

Мы не говорим ей заранее, сколько именно должна добавлять к цене дополнительная комната или один квадратный метр. Мы показываем множество примеров и подбираем параметры так, чтобы модель как можно меньше ошибалась.

И вот здесь возникает более важный вопрос: какие именно данные мы передали модели и насколько им вообще можно доверять?

Хорошая модель начинается не с модели

Представим, что мы хотим определять стоимость квартиры. Можно собрать таблицу из нескольких десятков тысяч объявлений и сразу начать обучение, но сначала придётся ответить на гораздо менее эффектные вопросы.

Откуда взялись эти данные? Есть ли в них ошибки? Что делать с пропущенными значениями? Почему одна квартира стоит 200 тысяч, а другая — 200 миллионов? Является ли такая цена реальной или это ошибка в объявлении?

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

• какие характеристики квартиры действительно имеют значение;

• как представить район;

• что делать с текстовым описанием;

• нужно ли учитывать дату публикации;

• какие данные будут доступны в тот момент, когда модель начнут использовать в реальной работе.

Если подготовить данные плохо, модель совершенно честно научится на плохо подготовленных данных. Она не знает, что мы ошиблись.

Здесь хорошо вспоминается выражение про «ложь, наглую ложь и статистику». Проблема не в том, что статистика врёт. Компьютер как раз очень добросовестно посчитает то, что мы ему поручили.

Проблема в другом: правильный ли вопрос мы задали и правильные ли данные использовали для ответа на него.

Модель может показать отличный результат и при этом оказаться бесполезной

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

И здесь снова возникает ловушка: получить красивое число довольно легко. Гораздо важнее понять, что именно оно означает.

Представим, что банк анализирует операции по картам. Из каждой тысячи операций только десять являются мошенническими. Можно сделать простейшую систему, которая всегда отвечает: «Любая операция нормальная».

В 990 случаях из 1000 она окажется права. Получается 99% правильных ответов.

На первый взгляд — почти идеальный результат. Только система не обнаружила ни одной мошеннической операции.

Поэтому в Data Science нет одного универсального числа, которое всегда позволяет сказать: эта модель хорошая, а эта плохая.

Даже хороший показатель качества не говорит всего

Есть метрики, которые оценивают модель сложнее, чем простой подсчёт правильных ответов. Например, AUC.

Само название сейчас не так важно. Важнее понять смысл.

Во многих задачах модель сначала не говорит жёстко «да» или «нет». Она выдаёт некоторую оценку. Например, для банковской операции это может выглядеть как вероятность:

• почти точно нормальная — 0,03;

• уже выглядит подозрительнее — 0,42;

• очень похожа на мошенничество — 0,91.

После этого мы сами решаем, начиная с какого значения считать операцию подозрительной.

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

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

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

Поэтому мало получить хорошую цифру. Нужно понимать, что именно она показывает и соответствует ли это реальной задаче.

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

Одна и та же модель может хорошо выглядеть по одному показателю и плохо — по другому.

Модель нужно ещё и правильно проверить

Есть ещё одна проблема. Представим школьника, которому дали десять задач, а потом по этим же десяти задачам провели экзамен.

Он может просто запомнить ответы. Результат будет великолепным, но мы так и не узнаем, научился ли он решать новые задачи.

С моделями происходит примерно то же самое. Если проверять качество на тех же данных, на которых модель обучалась, можно получить красивый результат, который ничего не скажет о её способности работать с новыми данными.

Поэтому данные разделяют. Одну часть используют для обучения, другую — для проверки, а часть стараются вообще не трогать до самого конца.

Но даже простого разделения иногда недостаточно. Если мы пытаемся прогнозировать будущее, нельзя обучить модель на октябрьских данных, а потом проверять её на августовских. Если данные относятся к одним и тем же людям, компаниям или устройствам, может быть важно не допустить ситуацию, когда информация об одном объекте попала сразу и в обучение, и в проверку.

Иначе модель получит подсказку, которой у неё не будет в реальной работе.

Получается ещё одна большая часть работы специалиста по данным: не просто построить модель, а придумать способ честно проверить, действительно ли она чему-то научилась.

После первой модели работа только начинается

Допустим, данные подготовлены, модель обучена и первая проверка проведена. Работа всё равно не закончена.

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

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

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

Это не обязательно означает, что кто-то всё сделал неправильно. Это и есть нормальная работа с данными: выдвинуть предположение, проверить его, посмотреть на результат и попытаться понять, почему получилось именно так.

Обучение модели — только часть работы

Наверное, именно это сильнее всего изменилось в моём представлении о Data Science после первых учебных проектов.

Со стороны кажется, что основная работа заключается в самой модели: выбрать правильный алгоритм, запустить обучение и получить результат. Но непосредственно обучение зачастую оказывается одной из самых коротких частей процесса.

Полная цепочка выглядит скорее так:

1. получить данные

2. понять их

3. очистить

4. подготовить

5. выбрать нужные характеристики

6. правильно разделить данные

7. обучить модель

8. выбрать способ оценки

9. проверить

10. разобраться в ошибках

11. изменить подход

12. проверить снова.

И только где-то посередине находится непосредственно обучение.

Можно условно сказать, что большая часть работы специалиста по данным остаётся за кадром. Пользователь YouTube видит рекомендацию следующего ролика, клиент банка — решение по кредиту, водитель такси — рассчитанное время поездки, покупатель интернет-магазина — список рекомендуемых товаров.

Но они не видят все решения, которые были приняты до того, как система смогла показать этот результат.

Так что же такое Data Science?Пока для себя я формулирую это так: Data Science — это не столько умение получить от модели какой-то ответ, сколько умение сделать так, чтобы этому ответу были основания доверять.

Модель — только один из инструментов. До неё находятся данные, постановка задачи и подготовка. После неё — проверка, оценка качества и интерпретация результата.

И именно здесь возникает большая часть интересных вопросов:

• почему модель прекрасно работает на обучающих данных, но ошибается на новых;

• почему 99% правильных ответов иногда означают совершенно бесполезную систему;

• почему более сложная модель может работать хуже простой;

• как модель может случайно получить информацию, которой у неё не должно быть;

• что происходит, когда она запоминает данные вместо того, чтобы находить закономерность.

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