Некоторое время назад в моей ленте в фейсбуке всплыла ссылка на книгу Эндрю Ына (Andrew Ng) "Machine Learning Yearning", которую можно перевести, как "Страсть к машинному обучению" или "Жажда машинного обучения".

Людям, интересующимся машинным обучением или работающим в этой сфере представлять Эндрю не нужно. Для непосвященных достаточно сказать, что он является звездой мировой величины в области искусственного интеллекта. Ученый, инженер, предприниматель, один из основателей Coursera. Автор отличного курса по введению в машинное обучение и курсов, составляющих специализацию "Глубокое обучение" (Deep Learning).

Я с глубоким уважением отношусь к Эндрю, прошел его курсы, поэтому тут же решил прочитать выпускаемую книгу. Оказалось, что книга еще не написана и публикуется по частям, по мере ее написания автором. И вообще это даже не книга, а черновик будущей книги (будет ли она издана в бумажном виде, неизвестно). Потом пришла идея перевести выпускаемые главы. На настоящий момент перевел 14 глав (это первый выпущенный отрывок книги). Планирую продолжить данную работу и перевести всю книгу. Переводимые главы буду публиковать в своем блоге на Хабре.

На момент написания этих строк автор опубликовал 52 главы из задуманных 56 (уведомление о готовности 52 главы пришло мне на почту 4 июля). Все доступные на настоящий момент главы можно скачать здесь ну или самостоятельно найти в интернете.

Перед тем, как опубликовать свой перевод, поискал другие переводы, нашел вот этот, тоже опубликованный на Хабре. Правда переведены только первые 7 глав. Не могу судить о том, чей перевод лучше. Ни я, ни IliaSafonov (по ощущениям от прочтения) не являемся профессиональными переводчиками. Некоторые части мне больше нравятся у меня, некоторые у Ильи. В предисловии Ильи же можно прочитать интересные подробности о книге, которые я опускаю.

Свой перевод публикую без вычитки, "из печи", к некоторым местам планирую вернуться и поправить (особенно это относится к путанице с train / dev / test датасетами). Буду признателен, если в комментариях будут даны замечания как по стилистике, ошибкам и т.п., так и содержательные, касающиеся текста автора.

Все картинки оригинальные (от Эндрю Ын), без них книга была бы более скучной.

Итак, к книге:

Глава 1. Зачем нужна стратегия по машинному обучению

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

Пример: Создание стартапа по распознаванию кошачьих картинок

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

Вы используете нейронную сеть для построения системы компьютерного зрения для распознавания кошек на фотографиях.

Но к несчастью, качество вашего обучающегося алгоритма еще не достаточно хорошее и на вас с колоссальной силой давит необходимость улучшить кошачий детектор.
Что делать?

У вашей команды много идей, таких как:

• Добыть больше данных: собрать больше фотографий кошек.
• Собрать более разнородный датасет. Например, фотографии, на которых кошки находятся в необычных положениях; фотографии кошек с необычной окраской; снимки с разнообразными настройками фотокамеры;…
• Дольше тренировать алгоритм, увеличив количество итераций градиентного спуска
• Попробовать увеличить нейронную сеть, с большим количеством слоев /скрытых нейронов / параметров.
• Попробовать уменьшить нейронную сеть.
• Попробовать добавить регуляризацию (такую, как L2 регуляризацию)
• Изменить архитектуру нейронной сети (функцию активации, количество скрытых нейронов, т. д.)
• …

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

Эта книга расскажет вам, как.

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

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

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

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

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

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

3. Предпосылки и замечания

Если вы прошли курс по машинному обучению, такие как мой курс машинного обучения MOOC на Coursera, или если у вас есть опыт обучения алгоритмов с учителем, вам будет не сложно понять этот текст.

Я предполагаю, что вы знакомы с «обучением с учителем»: обучение функции, которая связывает х с y, используя размеченные тренировочные примеры (х, у). К алгоритмам обучения с учителем относятся линейная регрессия, логистическая регрессия, нейронные сети и другие. На сегодняшний день существует много форм и подходов к машинному обучению, но большая часть подходов, имеющих практическое значение получены из алгоритмов класса «обучение с учителем».

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

Если вы не знакомы с концепциями, упоминаемыми тут, посмотрите видео первых трех недель из курса Машинного обучения на Coursera http://ml-class.org/

4. Шкала прогресса в машинного обучения

Многие идеи глубокого обучения (нейронных сетей) существовали десятилетия. Почему эти идеи взлетели только сегодня?

Двумя наибольшими драйверами недавнего прогресса стали:

• Доступность данных Сегодня люди проводят много времени с вычислительными приборами (ноутбуки, мобильные устройства). Их цифровая активность генерирует огромные объемы данных, которые мы можем скармливать нашим обучающимся алгоритмам.
• Вычислительные мощности Только несколько лет назад стало возможным тренировать нейронные сети достаточно больших размеров, позволяющих получать преимущества использования огромных датасетов, которые у нас появились.

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

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

Если вы тренируете маленькую нейронную сеть (NN) для той же самой задачи «обучения с учителем», вы можете получить результат немного лучший, чем у «старых алгоритмов».

Здесь под «Малой NN» мы понимаем нейронную сеть с небольшим количеством скрытых нейронов / слоев / параметров. Наконец, если вы начинаете тренировать все большие и большие нейронные сети, вы можете получить все более высокое качество.

Примечание автора: Эта диаграмма показывает, что нейронные сети работают лучше в режиме малых датасетов. Этот эффект менее устойчивый, чем эффект нейронных сетей, хорошо работающих в режиме огромных датасетов. В режиме малых данных, в зависимости от того, как признаки были обработаны (в зависимости от качества ижниниринга признаков), традиционные алгоритмы могут работать как лучше, так и хуже, чем нейронные сети. Например, если вы имеете 20 примеров для обучения, не имеет большого значения, используете вы логистическую регрессию или нейронную сеть; подготовка признаков имеет больший эффект, чем выбор алгоритма. Однако, если вы имеете 1 миллион обучающих примеров, я бы предпочел нейронную сеть

Таким образом, вы получаете лучшее качество работы алгоритма, когда вы (i) тренируете очень большую нейронную сеть, в этом случае вы находитесь на зеленой кривой на картинке вверху; (ii) в вашем распоряжении огромное количество данных.

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

Процесс совместного выполнения условий (i) и (ii) на практике оказывается удивительно сложным. В этой книге будут подробно обсуждены его детали. Мы начнем с общих стратегий, которые одинаково полезны как для традиционных алгоритмов, так и для нейронных сетей, и затем изучим наиболее современные стратегии, используемые при проектировании и разработке систем глубинного обучения.

5. Создание выборок для обучения и тестирования алгоритмов

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

Ваша команда получает большой тренировочный набор, скачивая фотографии кошек (позитивные примеры) и фотографии, на которых кошек нет (негативные примеры) с различных веб-сайтов. Они нарезали разделили датасет на обучающий и тестовый в отношении 70% на 30%. Используя эти данные, они построили алгоритм, находящий кошек, хорошо работающий как на обучающих так и на тестовых данных.

Однако, когда вы внедрили этот классификатор в мобильное приложение, вы обнаружили, что качество его работы очень низкое!

Что случилось?

Вы вдруг выясняете, что фотографии, которые пользователи загружают в ваше мобильное приложение, имеют совершенно другой вид, чем те фотографии с веб-сайтов, из которых состоит ваш обучающий датасет: пользователи загружают фотографии, снятые камерами мобильных телефонов, которые, как правило, имеют более низкое разрешение, менее четкие и сделаны при плохом освещении. После обучения на вашей обучающей/тестовой выборках, собранных из фотографий с веб-сайтов, ваш алгоритм не смог качественно обобщить результаты на реальное распределение данных, актуальных для вашего приложения (на фотографии, сделанные камерами мобильных телефонов).

До наступления современной эры больших данных, общим правилом машинного обучения было разбиение данных на обучающие и тестовые в отношении 70% на 30%. Несмотря на то, что этот подход все еще работает, будет плохой идеей использовать его во все большем и большем количестве приложений, где распределение обучающей выборки (фотографии с веб-сайтов в примере, рассмотренном выше) отличается от распределения данных, которые будут использоваться в боевом режиме вашего приложения (фотографии с камеры мобильных телефонов).

Обычно используются следующие определения:

• Обучающая выборка (Training set) — выборка из данных, которая используется для обучения алгоритма
• Валидационная выборка (Выборка для разработки Dev (development) set) — выборка данных, которая используется для подбора параметров, выбора признаков и принятия других решений, касающихся обучения алгоритма. Ее иногда так же называют удерживаемой выборкой для кросс-валидации (hold-out cross validation set)
• Тестовая выборка — выборка, которая используется для оценки качества работы алгоритма, при этом никак не используется для обучения алгоритма или используемым при этом обучении параметрам.

Замечание переводчика: Андрю Ын использует понятие development set или dev set, в русском языке и русскоязычной терминологии машинного обучения такого термин не встречается. «Выборка для разработки» или «Разработческая выборка» (прямой перевод английских слов) звучит громоздко. Поэтому я буду в дальнейшем использовать словосочетание «валидационная выборка» в качестве перевода dev set.

Замечаение переводчика 2: DArtN предложил перевести dev set, как "отладочная выборка", я считаю, что это очень удачная идея, но я уже на большом объеме текста использовал термин «валидационная выборка» и заменять его теперь трудоемко. Справедливости ради отмечу, что у термина «валидационная выборка» есть одно преимущество — эта выборка используется для оценки качества алгоритма (для оценки качества работы алгоритма, обученного на тренировочной выборке), поэтому в некотором смысле она является «тестовой», термин «валидационная» в себя включает этот аспект. Прилагательное «отладочная» делает упор на тюнинг параметров. Но в целом, это очень хороший термин (особенно с точки зрения русского языка) и если бы он пришел мне в голову раньше, я бы использовал его вместо термина "валидационная выборка".

Выбрать валидационную и тестовую выборки такими, чтобы он(кроме подбора (настройки) параметров) и отражали данные, которые вы ожидаете получать в будущем и хотите, чтобы на них ваш алгоритм работал хорошо.
Другими словами, ваша тестовая выборка должна быть не просто 30% от доступных данных, особенно если вы ожидаете, что данные, которые будут поступать в будущем (фотографии с мобильных телефонов) будут отличаться по своей природе от вашей обучающей выборки (фотографий, полученных с веб сайтов).

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

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

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

6. Валидационная и тестовая выборки должны иметь одинаковое распределение

Допустим данные вашего приложения для кошачьих фотографий сегментированы по четырем регионам, соответствующих вашим наибольшим рынкам: (i) США, (ii) Китай, (iii) Индия, (iv) Прочие.

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

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

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

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

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

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

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

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

7. Насколько велики должны быть валидационные и тестовые выборки?

Валидационная выборка должна быть достаточной для определения различий между алгоритмами, которые вы испытываете. Например, если классификатор А имеет точность 90.0% и классификатор В имеет точность 90.1%, в этом случае, на валидационной выборке, состоящей из 100 примеров, невозможно обнаружить эту разницу в 0.1%.
Замечание автора: В теории можно проверить имеет ли статистическую значимость изменение качества работы алгоритма при изменении размера валидационной выборки. На практике большинство команд об этом не беспокоятся (если речь идет не о публиковании результатов академических исследований), и я обычно не считаю полезным использование тестов на статистическую значимость для оценки промежуточного прогресса при работе над алгоритмом.

Для зрелых и важных приложений — например, рекламных, интернет-поиска, и рекомендательных сервисов, я встречал команды, которые были высоко мотивированы биться даже за 0.01% улучшения, так как это напрямую влияет на прибыль компании. В этом случае, валидационная выборка должна быть много больше чем 10000, для того, чтобы обнаружить еще меньшие улучшения.

Что можно сказать о размере тестовой выборки? Она должна быть достаточно большой для получения высокой уверенности в качестве работы вашей системы. Одной популярной эвристикой является использование 30% доступных для обучения данных для тестовой выборки. Это хорошо работает, если в вашем распоряжении небольшое количество примеров, скажем от 100 до 10000 примеров. Но в сегодняшнюю эпоху больших данных, когда перед машинным обучением стоят задачи, иногда имеющие больше миллиарда примеров, доля данных, используемых для тестовой и валидационной выборок сокращается, даже если растет абсолютное количество примеров в этих выборках. Нет никакой необходимости использовать чрезмерно большие валидационные/тестовые выборки, свыше того, что необходимо для оценки качества работы ваших алгоритмов.

8. Установите своей команде для оптимизации однопараметрическую метрику качества

Точность классификации является примером однопараметрической метрики качества: вы запускаете свой классификатор на валидационной выборке (или на тестовой), и получаете одну цифру, говорящую о том, какое количество примеров классифицированны правильно. Согласно этой метрике, если классификатор А показывает 97% точность, а классификатор В показывает 90%, мы считаем классификатор А более предпочтительным.

Для контраста рассмотрим метрику точности (precision) и полноты (recall), которая не являются однопараметрической. Она дает две цифры для оценки вашего классификатора. Данную многопараметрическую метрику сложнее использовать для сравнения алгоритмов. Предположим ваш алгоритм показывает следующие результаты:

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

Замечание автора: Точность (precision) кошачьего классификатора оценивает долю фотографий в валидационной (тестовой) выборке, на которых действительно изображены коты в классифицированных алгоритмом, как изображение котов. Полнота(recall) показывает процент всех картинок с кошками в валидационной (тестовой) выборке, которые корректно классифицированы, как изображение котов. Часто приходится идти на компромисс, выбирая между высокой точностью и высокой полнотой.

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

Если вам действительно необходимо оценивать качество точностью и полнотой, я рекомендую использовать один из стандартных способов их комбинации, превращая их в одну цифру. Например, можно взять среднюю точности и полноты и в конечном счете работать с одним параметром. В качестве альтернативы можно рассчитывать F1 метрику, которая является более совершенным способом расчета их средневзвешенного и работает лучше, чем просто среднее.
Замечание автора: Если вы хотите узнать больше об F1 метрике, см. ​ https://en.wikipedia.org/wiki/F1_score, Она является «гармоническим средним» между Точностью и Полнотой и рассчитывается, как 2/((1/Precision)+(1/Recall)).

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

В качестве последнего примера, предположим, что вы раздельно отслеживаете точность вашего кошачьего классификатора на ваших ключевых рынках: (i) США, (ii) Китай, (iii) Индия и (iv) Прочие. Таким образом вы имеете четыре метрики. Взяв средневзвешенную этих четырех цифр, в конце концов у вас будет однопараметрическая метрика оценки качества. Использование средневзвешенного является одним из наиболее распространенных путей превращения нескольких метрик в одну.

9. Оптимизируемые и ограничивающие метрики

Здесь мы рассмотрим другой подход к комбинации многопараметрических метрик качества алгоритмов.
Представьте, что вам необходимо оптимизировать точность и скорость работы обучающегося алгоритма. Вам необходимо выбрать один из трех классификаторов из таблицы:

Получение однопараметрической метрики, связыванием скорости и точности через формулу, такую как [Точность] — 0.5*[Скорость], выглядит не естественным.

Вот что вы можете сделать вместо этого: Во-первых, определите, какое время выполнение алгоритма является «приемлемым». Давайте предположим, что исполнение в течение 100 мили секунд является приемлемым. Затем выберем максимальную точность, соответствующую критерию скорости выполнения. Здесь скорость выполнения является ограничивающей (satisficing) метрикой — ваш классификатор должен удовлетворять ограничивающим значениям этой метрики, в том смысле, что его максимальное значение не может превышать 100 мсек. Точность при этом становится оптимизационной метрикой.

Если вы оперируете N различными критериями, такими как размер бинарного файла модели (который важен для мобильных приложений из-за того, что пользователи не хотят загружать большие приложения), время исполнения, и точность, вы можете рассматривать N-1 из этих критериев как ограничивающие метрики. Т. е. Вы просто требуете, чтобы они принимали определенное значение. Затем определите последнюю (N-ую) метрику, как оптимизационную. Например, установите приемлемое пороговое значение для размера бинарного файла и для времени выполнения алгоритма, и попытайтесь оптимизировать точность, выдерживая эти ограничения.

В качестве последнего примера, представьте что вы разрабатываете прибор, использующий микрофон для улавливания определенного «инициирующего слова», произносимого пользователем для включения системы (после произнесения которого, система просыпается). Например, Amazon Echo улавливает «Alexa»; Apple Siri улавливает «Hey Siri»; Android улавливает «Okay, Google»; приложения Baidu улавливают «Hello Baidu». Вашей заботой является оба false-positive соотношения — как частота включения системы, когда никто не произносил ключевого слова, так и false-negative — как часто система не включается при произнесении ключевого слова. Целесообразной целью при разработке такой системы является минимизация false-negative метрики (это будет оптимизационным параметром) при наличие не более чем один случай false positive каждые 24 часа работы (ограничивающая метрика).

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

10 Наличие валидационной выборки и метрик увеличивают скорость итераций

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

1. Начинаю с некоторой идеи, как построить эту систему
2. Реализую эту идею в коде (программирую идею)
3. Провожу эксперимент который показывает мне, насколько хорошо работает эта идея. (Обычно мои первые несколько идей не работают!) Отталкиваясь от приобретенных знаний, возвращаюсь к генерации новых идей и далее по кругу.

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

Для контраста, представьте, что у вас нет специальной валидационной выборки и метрики. Таким образом каждый раз ваша команда разрабатывает новый кошачий классификатор, вы должны интегрировать этот классификатор в ваше приложение и играть с приложением какое-то количество часов для того, чтобы почувствовать, действительно ли новый классификатор является улучшением. Это может тянуться невероятно медленно! Кроме того, если ваша команда улучшила точность классификатора с 95.0% до 95.1%, вы можете оказаться не способными заметить эти 0.1% улучшения при манипуляциях (игре) с приложением. Но большой прогресс в вашей системе может быть достигнут постепенным накоплением дюжин таких 0.1%-ных улучшений. Наличие валидационной выборки и метрик, позволяют вам очень быстро замечать и оценивать какие идеи являются успешными, дающими вам маленькие (или большие) улучшения, и поэтому дают вам быстрое решение, какие идеи нужно совершенствовать и какие отбросить.

11 Когда нужно изменять валидационные и тестовые (dev/test sets) выборки и метрики

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

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

Если позднее вы решите, что ваши первоначальные dev/test выборки или первоначальная метрика выбраны неудачно, киньте все силы на то, чтобы быстро их поменять. Например, если ваш выборка для разработки + метрика ранжируют классификатор A выше, чем классификатор B, при этом вы и ваша команда думаете, что классификатор В объективно лучше подходит для вашего продукта, то это может быть знаком, что вы нуждаетесь в изменении dev/test датасетов или в изменении метрики оценки качества.

Существует три основные возможные причины, из-за которых валидационная выборка или метрика оценки качества неправильно ранжируют классификатор А выше классификатора В:

1. Реальное распределение, которое нужно улучшать, отличается от dev/test выборок

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

2. Вы переобучаетесь на валидационной выборке (dev set)

Процесс многократной эволюции идей, на валидационной выборке (dev set) заставляет ваш алгоритм постепенно переобучаться на ней. Когда вы завершили разработку, вы оцениваете качество вашей системы на тестовой выборке. Если вы обнаружите, что качество работы вашего алгоритма на валидационной выборке (dev set) много лучше, чем на тестовой (test set), то это говорит о том, что вы переобучились на валидационной выборке. В этом случае нужно получить новую валидационную выборку.

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

3. Метрика оценивает что-то отличное от того, нужно оптимизировать для целей проекта

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

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

Это довольно общие подходы к изменению dev/test выборок или изменению метрики оценки качества в процессе работы над проектом. Наличие первоначальных dev/test выборок и метрики позволяют вам быстро начать итерации работы над проектом. Если вы даже обнаружите, что выбранные dev/test выборки или метрика больше не ориентируют вашу команду в правильном направлении, это не имеет большого значения! Просто смените их и убедитесь, что ваша команда знает о новом направление.

12 Рекомендации: Подготавливаем валидационную (development) и тестовую выборки

• Выбирайте dev и test выборки из распределения, которое отражает те данные, которые вы ожидаете получить в будущем и на которых вы хотите, чтобы ваш алгоритм хорошо работал. Эти выборки могут могут не совпадать с распределением вашего обучающего дата сета.
• Выбирайте выборки для разработки и тестирования (dev test sets) из одного и того же распределения, если это возможно
• Выбирайте для своей команды однопараметрическую метрику оценки качества алгоритмов для оптимизации. Если у вас несколько целей, которых нужно достигнуть одновременно, рассмотрите возможность объединить их в одну формулу (такую как метрика усредненной многопараметрической ошибки) или определите ограничивающие и оптимизационную метрики.
• Машинное обучение является в высшей степени итеративным процессом: вы можете пробовать множество идей прежде чем найдете ту, которая вас удовлетворит.
• Наличие dev/test выборок и однопараметрической метрики оценки качества помогут вам быстро оценивать алгоритмы, и таким образом, проходить итерации быстрее.
• Когда стартует разработка нового приложения, попытайтесь быстро установить dev/test выборки и метрику оценки качества, скажем, потратьте на это не больше недели. Для зрелых приложений нормально, если этот процесс занимает существенно больше времени.
• Старая добрая эвристика разбиения тренировочной и тестовой выборки как 70% на 30% не применима к проблемам, в которых имеется большое количество данных; dev / test выборки могут быть существенно меньше, чем 30% от всех имеющихся данных.
• Если ваша выборка для разработки и метрика больше не указывает вашей команде правильное направление движения, быстро поменяйте их: (i) если ваш алгоритм переобучается на валидационной выборке (dev set), добавьте в нее (в ваш dev set) больше данных. (ii) Если распределение реальных данных, качество работы алгоритма на котором вам необходимо улучшать, отличается от распределения данных в валидационной и (или) тестовой выборках (dev / test sets), сформируйте новые выборки для тестирования и разработки (dev / test sets), используя другие данные. (iii) Если ваша метрика для оценки качества больше не измеряет то, что наиболее важно для вашего проекта, смените эту метрику.

13 Постройте вашу первую систему быстро, а затем итерационно улучшайте

Вы хотите построить построить новую систему антиспама для электронной почты. У вашей команды есть несколько идей:

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

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

Поэтому не пытайтесь с самого начала построить идеальную систему. Вместо этого постройте и обучите простую систему максимально быстро, возможно, за несколько дней.
Замечание автора: Этот совет предназначается скорее для читателей, желающих разрабатывать AI приложения, чем для тех, чьей целью является публикация академических статей. Позднее я вернусь к теме исследований.
Даже если простая система далека от «идеальной» системы, которую вы можете построить, будет полезным изучить, как функционирует эта простая система: вы быстро найдете подсказки, которые покажут вам наиболее перспективные направления, в которые вы должны инвестировать ваше время. Следующие несколько глав покажут вам, как читать эти подсказки.

14 Анализ ошибок: Смотрите на примеры из валидационной выборки (dev set examples) для оценки идей

Когда вы игрались с вашим кошачьим приложением, вы заметили несколько примеров в которых приложение ошибочно принимало собак за кошек. Некоторые собаки выглядят, как кошки!

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

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

Конкретно, что можно сделать в этом случае:

1. Соберите выборку в 100 примеров из валидационной выборки (dev set), которые ваша система неправильно классифицировала. Т. е. примеров, на которых ваша система совершила ошибку.
2. Изучите эти примеры и посчитайте, какую долю от них составляют изображения собак.

Процесс изучения примеров на которых классификатор ошибся, называется «анализ ошибок». В приведенном примере, предположим, вы найдете, что только 5% от неправильно классифицированных изображений являются собаками, тогда не важно, насколько сильно вы улучшите работу вашего алгоритма на собачьих изображениях, вы не сможете получить улучшения качества выше, чем 5% от доли ваших ошибок. Другими словами, 5% это «потолок» (подразумевает максимально возможное число) насколько предполагаемое улучшение может помочь. Таким образом, если ваша общая система в настоящий момент имеет точность 90% (10% ошибок), это улучшение возможно, в лучшем случае улучшит результат до 90.5% точности (или доля ошибок будет составлять 9.5%, что на 5% меньше, чем первоначальные 10% ошибок)

Напротив, если вы обнаружите, что 50% ошибок являются собаками, тогда вы можете быть более уверенными, что предполагаемый проект по улучшению системы будет иметь большой эффект. Он мог бы увеличить точность с 90% до 95% (50% относительное уменьшение ошибки с 10% до 5%)

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

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

Ручная проверка 100 примеров из выборки, это не долго. Даже если вы потратите одну минуту на изображение, вся проверка займет менее 2х часов. Эти два часа могут сохранить вам месяц растраченных впустую усилий.

продолжение