Правила машинного обучения:

Лучшие практики для разработки машинного обучения

Мартин Зинкевич

Цель этого документа – помочь тем, у кого есть базовые знания в области машинного обучения, воспользоваться преимуществами лучших практик Google в области машинного обучения. Он представляет стиль машинного обучения, аналогичный Руководству по стилю Google C++ и другим популярным руководствам по практическому программированию. Если вы прошли курс по машинному обучению или создали модель машинного обучения или работали над ней, то у вас есть необходимая подготовка для чтения этого документа.

Мартин Зинкевич представляет 10 своих любимых правил машинного обучения. Читайте дальше, чтобы узнать все 43 правила!

Терминология

Следующие термины будут неоднократно встречаться в нашем обсуждении эффективного машинного обучения:

• Экземпляр : вещь, о которой вы хотите сделать прогноз. Например, экземпляром может быть веб-страница, которую вы хотите классифицировать как «о кошках» или «не о кошках».
• Ярлык : ответ на задачу прогнозирования: либо ответ, полученный системой машинного обучения, либо правильный ответ, предоставленный в обучающих данных. Например, метка веб-страницы может быть «о кошках».
• Функция : свойство экземпляра, используемое в задаче прогнозирования. Например, на веб-странице может быть функция «содержит слово «кошка»».
• Столбец функций : набор связанных функций, например набор всех возможных стран, в которых могут жить пользователи. В примере может присутствовать одна или несколько функций в столбце функций. «Столбец функций» — это терминология, специфичная для Google. Столбец функции называется «пространством имен» в системе VW (в Yahoo/Microsoft) или полем .
• Пример : экземпляр (с его функциями) и метка.
• Модель : статистическое представление задачи прогнозирования. Вы обучаете модель на примерах, а затем используете ее для прогнозирования.
• Метрика : число, которое вас волнует. Может быть оптимизировано напрямую, а может и не быть.
• Цель : показатель, который ваш алгоритм пытается оптимизировать.
• Конвейер : инфраструктура, окружающая алгоритм машинного обучения. Включает сбор данных из внешнего интерфейса, помещение их в файлы данных обучения, обучение одной или нескольких моделей и экспорт моделей в производство.
• Рейтинг кликов Процент посетителей веб-страницы, которые нажимают ссылку в объявлении.

Обзор

Чтобы создавать отличные продукты:

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

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

1. Убедитесь, что ваш конвейер надежен от начала до конца.
2. Начните с разумной цели.
3. Добавляйте привычные функции простым способом.
4. Убедитесь, что ваш трубопровод остается надежным.

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

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

Этот документ оформлен следующим образом:

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

До машинного обучения

Правило №1: Не бойтесь запускать продукт без машинного обучения.

Машинное обучение — это круто, но оно требует данных. Теоретически вы можете взять данные из другой проблемы, а затем настроить модель для нового продукта, но это, скорее всего, будет уступать базовой эвристике . Если вы думаете, что машинное обучение даст вам 100-процентный прирост, то эвристика обеспечит вам 50-процентный успех.

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

Правило №2: Во-первых, спроектируйте и внедрите метрики.

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

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

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

Если вы будете более либеральны в сборе показателей, вы сможете получить более широкое представление о своей системе. Заметили проблему? Добавьте метрику для отслеживания! Вас волнуют некоторые количественные изменения в последней версии? Добавьте метрику для отслеживания!

Правило №3: выбирайте машинное обучение вместо сложной эвристики.

Простая эвристика может вывести ваш продукт на рынок. Сложную эвристику невозможно поддерживать. Когда у вас есть данные и базовое представление о том, чего вы пытаетесь достичь, переходите к машинному обучению. Как и в большинстве задач разработки программного обеспечения, вам потребуется постоянно обновлять свой подход, будь то эвристическая модель или модель машинного обучения, и вы обнаружите, что модель машинного обучения легче обновлять и поддерживать (см. Правило № 16) . ).

Фаза I машинного обучения: ваш первый конвейер

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

Правило № 4. Сохраняйте первую модель простой и создайте правильную инфраструктуру.

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

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

Выбор простых функций упрощает обеспечение того, что:

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

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

Правило №5. Тестируйте инфраструктуру независимо от машинного обучения.

Убедитесь, что инфраструктура тестируема, а обучающие части системы инкапсулированы, чтобы вы могли тестировать все, что ее окружает. Конкретно:

1. Протестируйте ввод данных в алгоритм. Убедитесь, что столбцы объектов, которые должны быть заполнены, заполнены. Если позволяет конфиденциальность, вручную проверьте входные данные для вашего алгоритма обучения. Если возможно, сравните статистику вашего конвейера со статистикой тех же данных, обработанных в другом месте.
2. Протестируйте получение моделей из алгоритма обучения. Убедитесь, что модель в вашей обучающей среде дает тот же балл, что и модель в вашей обслуживающей среде (см. Правило № 37 ).

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

Правило №6: Будьте осторожны с потерянными данными при копировании конвейеров.

Часто мы создаем конвейер, копируя существующий конвейер (т. е. программирование карго-культа ), и старый конвейер удаляет данные, которые нам нужны для нового конвейера. Например, конвейер Google Plus What's Hot удаляет старые публикации (поскольку он пытается ранжировать свежие публикации). Этот конвейер был скопирован для использования в Google Plus Stream, где старые публикации по-прежнему имеют смысл, но конвейер по-прежнему удалял старые сообщения. Другой распространенный шаблон — регистрировать только те данные, которые видел пользователь. Таким образом, эти данные бесполезны, если мы хотим смоделировать, почему конкретный пост не был просмотрен пользователем, поскольку все негативные примеры были удалены. Аналогичная проблема произошла в Play. Во время работы над Play Apps Home был создан новый конвейер, который также содержал примеры с целевой страницы Play Games без каких-либо функций, позволяющих устранить неоднозначность, откуда взят каждый пример.

Правило №7: Превратите эвристику в функции или обрабатывайте их извне.

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

• Предварительная обработка с использованием эвристики. Если эта функция невероятно крутая, то это вариант. Например, если в спам-фильтре отправитель уже занесен в черный список, не пытайтесь заново узнать, что означает «черный список». Заблокируйте сообщение. Этот подход имеет наибольший смысл в задачах двоичной классификации.
• Создайте функцию. Непосредственное создание функции на основе эвристики — это здорово. Например, если вы используете эвристику для вычисления оценки релевантности результата запроса, вы можете включить эту оценку в качестве значения функции. Позже вы можете захотеть использовать методы машинного обучения для обработки значения (например, преобразования значения в одно из конечного набора дискретных значений или объединения его с другими функциями), но начните с использования необработанного значения, полученного в результате эвристики.
• Изучите необработанные входные данные эвристики. Если для приложений существует эвристика, которая объединяет количество установок, количество символов в тексте и день недели, рассмотрите возможность разделения этих частей и отдельного ввода этих входных данных в обучение. Здесь применимы некоторые приемы, применимые к ансамблям (см. Правило №40 ).
• Измените метку. Это вариант, когда вы чувствуете, что эвристика фиксирует информацию, которая в данный момент не содержится в метке. Например, если вы пытаетесь максимизировать количество загрузок, но при этом хотите получить качественный контент, возможно, решением будет умножить ярлык на среднее количество звезд, полученных приложением. Здесь есть большая свобода действий. См . «Ваша первая цель» .

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

Мониторинг

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

Правило № 8: Знайте требования к свежести вашей системы.

Насколько ухудшится производительность, если у вас есть модель, которой исполнился один день? Неделю? Четверть года? Эта информация может помочь вам понять приоритеты вашего мониторинга. Если вы значительно теряете качество продукта, если модель не обновляется в течение дня, имеет смысл, чтобы инженер постоянно следил за ней. В большинстве систем показа рекламы каждый день появляются новые рекламные объявления, и они должны ежедневно обновляться. Например, если модель машинного обучения для поиска Google Play не будет обновлена, это может оказать негативное влияние менее чем за месяц. Некоторые модели для раздела «Что нового в Google Plus» не имеют идентификатора публикации в своей модели, поэтому они могут экспортировать эти модели нечасто. Другие модели, имеющие идентификаторы сообщений, обновляются гораздо чаще. Также обратите внимание, что актуальность может меняться со временем, особенно когда столбцы функций добавляются или удаляются из вашей модели.

Правило №9: выявляйте проблемы перед экспортом моделей.

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

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

Правило № 10: Следите за скрытыми неудачами.

Эта проблема чаще встречается в системах машинного обучения, чем в других типах систем. Предположим, что конкретная объединяемая таблица больше не обновляется. Система машинного обучения приспособится, и поведение останется достаточно хорошим, постепенно ухудшаясь. Иногда вы найдете таблицы, устаревшие на несколько месяцев, и простое обновление повышает производительность больше, чем любой другой запуск в этом квартале! Охват функции может измениться из-за изменений реализации: например, столбец функции может быть заполнен в 90% примеров и внезапно упасть до 60% примеров. Однажды в Play была таблица, которая устарела в течение 6 месяцев, и одно только обновление таблицы дало прирост количества установок на 2%. Если вы отслеживаете статистику данных, а также время от времени проверяете данные вручную, вы можете уменьшить количество подобных сбоев.

Правило № 11: Укажите владельцев функциональных столбцов и документацию.

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

Ваша первая цель

У вас есть множество показателей или измерений системы, которая вас волнует, но ваш алгоритм машинного обучения часто требует одной цели — числа, которое ваш алгоритм «пытается» оптимизировать. Здесь я различаю цели и показатели: показатель — это любое число, о котором сообщает ваша система, которое может быть важным, а может и не быть важным. См. также Правило №2 .

Правило № 12: Не задумывайтесь над тем, какую цель вы выберете для прямой оптимизации.

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

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

Правило № 13. Выберите простой, наблюдаемый и атрибутивный показатель для вашей первой цели.

Часто вы не знаете, какова истинная цель. Вы думаете, что да, но затем, глядя на данные и параллельный анализ вашей старой системы и новой системы ML, вы понимаете, что хотите изменить цель. Более того, разные члены команды часто не могут прийти к согласию относительно истинной цели. Цель ОД должна быть чем-то, что легко измерить и является показателем «истинной» цели. На самом деле, «истинной» цели часто не существует (см. Правило №39 ). Так что тренируйтесь на простой цели ML и рассмотрите возможность создания «уровня политики» сверху, который позволит вам добавлять дополнительную логику (надеюсь, очень простую логику) для окончательного ранжирования.

Проще всего смоделировать поведение пользователя, которое можно непосредственно наблюдать и которое можно отнести к действию системы:

• Был ли клик по этой ранжированной ссылке?
• Был ли этот рейтинговый объект загружен?
• Был ли этот ранжированный объект переслан/ответен/отправлен по электронной почте?
• Был ли этому объекту присвоен рейтинг?
• Был ли показанный объект помечен как спам/порнографический/оскорбительный?

Поначалу избегайте моделирования косвенных эффектов:

• Посетил ли пользователь на следующий день?
• Как долго пользователь посещал сайт?
• Каковы были ежедневные активные пользователи?

Косвенные эффекты дают отличные показатели и могут использоваться во время A/B-тестирования и принятия решений о запуске.

Наконец, не пытайтесь заставить машинное обучение выяснить:

• Доволен ли пользователь использованием продукта?
• Доволен ли пользователь своим опытом?
• Улучшает ли продукт общее самочувствие пользователя?
• Как это повлияет на общее состояние компании?

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

Правило № 14. Начиная с интерпретируемой модели, отладку становится проще.

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

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

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

Правило № 15: Отдельная фильтрация спама и ранжирование качества на уровне политики.

Ранжирование качества — это высокое искусство, а фильтрация спама — это война. Сигналы, которые вы используете для определения качественных публикаций, станут очевидными для тех, кто использует вашу систему, и они изменят свои публикации, чтобы они имели эти свойства. Таким образом, ваш качественный рейтинг должен быть сосредоточен на ранжировании контента, который публикуется добросовестно. Не следует сбрасывать со счетов учащегося по качественному ранжированию за высокий рейтинг спама. Аналогичным образом, «пикантный» контент следует рассматривать отдельно от рейтинга качества. Фильтрация спама — это отдельная история. Вы должны ожидать, что функции, которые вам нужно создать, будут постоянно меняться. Часто вы вводите в систему очевидные правила (если сообщение имеет более трех спам-голосов, не извлекайте его и т. д.). Любую изученную модель придется обновлять ежедневно, а то и быстрее. Большую роль будет играть репутация создателя контента.

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

Фаза II машинного обучения: разработка функций

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

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

Правило № 16: Планируйте запуск и повторение.

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

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

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

Правило № 17: Начните с непосредственно наблюдаемых и зарегистрированных функций, а не с изученных функций.

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

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

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

Правило № 18: Исследуйте особенности контента, которые обобщаются в разных контекстах.

Зачастую система машинного обучения является лишь небольшой частью гораздо большей картины. Например, если вы представляете публикацию, которая может быть использована в What's Hot, многие люди поставят плюс один, поделятся ею или прокомментируют публикацию еще до того, как она будет показана в What’s Hot. Если вы предоставите учащемуся эту статистику, он сможет продвигать новые публикации, для которых у него нет данных, в контексте, который он оптимизирует. YouTube Watch Next может использовать количество просмотров или совместных просмотров (подсчет того, сколько раз одно видео было просмотрено после просмотра другого) из поиска YouTube . Вы также можете использовать явные оценки пользователей. Наконец, если у вас есть действие пользователя, которое вы используете в качестве метки, просмотр этого действия над документом в другом контексте может быть отличной функцией. Все эти функции позволяют вам вносить новый контент в контекст. Обратите внимание, что речь идет не о персонализации: сначала выясните, нравится ли кому-то контент в данном контексте, а затем выясните, кому он нравится больше или меньше.

Правило № 19: Используйте очень специфические функции, когда можете.

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

Правило № 20: Объединяйте и модифицируйте существующие функции для создания новых функций, понятными человеку.

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

Дискретизация состоит в том, чтобы взять непрерывный признак и создать из него множество дискретных признаков. Рассмотрим такой непрерывный признак, как возраст. Вы можете создать объект со значением 1, когда возраст меньше 18 лет, другой объект со значением 1, когда возраст составляет от 18 до 35 лет, и так далее. Не зацикливайтесь на границах этих гистограмм: основные квантили дадут вам наибольшее влияние.

Крестики объединяют два или более столбца объектов. Столбец признаков, в терминологии TensorFlow, представляет собой набор однородных признаков (например, {мужской, женский}, {США, Канада, Мексика} и т. д.). Крест – это новый столбец признаков с признаками, например, {мужской, женский} × {США, Канада, Мексика}. Этот новый столбец характеристик будет содержать признак (мужчина, Канада). Если вы используете TensorFlow и указываете TensorFlow создать для вас этот крест, эта функция (мужчина, Канада) будет присутствовать в примерах, представляющих канадцев мужского пола. Обратите внимание, что для изучения моделей с пересечением трех, четырех или более столбцов базовых функций требуются огромные объемы данных.

Крестики, которые создают очень большие столбцы объектов, могут перекрываться. Например, представьте, что вы выполняете какой-то поиск и у вас есть столбец функций со словами в запросе и столбец функций со словами в документе. Вы можете объединить их с крестом, но в итоге вы получите множество функций (см. Правило № 21 ).

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

Правило № 21. Количество весов признаков, которые вы можете изучить в линейной модели, примерно пропорционально объему имеющихся у вас данных.

Существуют интересные результаты теории статистического обучения, касающиеся соответствующего уровня сложности модели, но это правило — это, по сути, все, что вам нужно знать. У меня были разговоры, в которых люди сомневались, что на тысяче примеров можно чему-то научиться или что вам когда-нибудь понадобится более миллиона примеров, потому что они застряли в определенном методе обучения. Ключевым моментом является масштабирование вашего обучения в соответствии с размером ваших данных:

1. Если вы работаете над системой ранжирования поиска, и в документах и ​​запросах есть миллионы разных слов, и у вас есть 1000 помеченных примеров, тогда вам следует использовать скалярное произведение между функциями документа и запроса, TF-IDF и полутора -дюжина других функций, созданных человеком. 1000 примеров, десяток особенностей.
2. Если у вас миллион примеров, пересеките столбцы функций документа и запроса, используя регуляризацию и, возможно, выбор функций. Это даст вам миллионы функций, но с регуляризацией их станет меньше. Десять миллионов примеров, может быть, сто тысяч функций.
3. Если у вас есть миллиарды или сотни миллиардов примеров, вы можете скрестить столбцы функций с токенами документов и запросов, используя выбор функций и регуляризацию. У вас будет миллиард примеров и 10 миллионов функций. Статистическая теория обучения редко дает жесткие границы, но дает отличное начало.

В конце используйте Правило № 28, чтобы решить, какие функции использовать.

Правило № 22: Очистите функции, которые вы больше не используете.

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

Помните о покрытии, когда решаете, какие функции добавить или оставить. Сколько примеров охватывает эта функция? Например, если у вас есть некоторые функции персонализации, но только у 8% ваших пользователей есть какие-либо функции персонализации, это не будет очень эффективно.

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

Человеческий анализ системы

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

Правило № 23: Вы не типичный конечный пользователь.

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

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

Если вы действительно хотите получить отзывы пользователей, используйте методологии пользователя . Создайте персонажи пользователей (одно из описаний приведено в опыте пользователей Билла Бакстона) в начале процесса и проведет тестирование использования (одно описание в «Стиве Круг» не заставляет меня думать ) позже. Персоны пользователя включают в себя создание гипотетического пользователя. Например, если ваша команда-мужская, она может помочь разработать 35-летнюю персональную индивидуума (в комплекте с пользовательскими функциями) и посмотреть на результаты, которые он получает, а не на 10 результатов для 25-40 лет. мужчины. Привлечение реальных людей, чтобы наблюдать за их реакцией на ваш сайт (локально или удаленно) в тестировании удобства использования, также может дать вам новую перспективу.

Правило № 24: Измерьте дельту между моделями.

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

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

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

Правило № 26: Ищите шаблоны в измеренных ошибках и создайте новые функции.

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

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

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

Правило № 27: Попробуйте количественно оценить наблюдаемое нежелательное поведение.

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

Правило № 28: Имейте в виду, что идентичное краткосрочное поведение не подразумевает идентичное долгосрочное поведение.

Представьте, что у вас есть новая система, которая рассматривает каждый DOC_ID и EXOM_QUERY, а затем вычисляет вероятность щелчка для каждого документа для каждого запроса. Вы обнаружите, что его поведение почти идентична вашей текущей системе с обеих сторон по бокам и A/B -тестированию, поэтому, учитывая ее простоту, вы запускаете ее. Тем не менее, вы замечаете, что новых приложений не отображаются. Почему? Что ж, поскольку ваша система показывает только документ, основанный на своей истории с этим запросом, нет никакого способа узнать, что должен быть показан новый DOC.

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

Обучение, проведенному на тренировке

Проседание обучения-это разница между производительностью во время обучения и производительности во время обслуживания. Этот перекос может быть вызван:

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

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

Правило № 29: Лучший способ убедиться, что вы тренируетесь, как вы, - это сохранить набор функций, используемых во время подачи, а затем подвести эти функции в журнал, чтобы использовать их во время обучения.

Даже если вы не можете сделать это для каждого примера, сделайте это для небольшой фракции, так что вы можете проверить последовательность между службой и обучением (см. Правило № 37 ). Команды, которые сделали это измерение в Google, иногда были удивлены результатами. Домашняя страница YouTube переключилась на функции журнала в течение времени обслуживания со значительными улучшениями качества и снижением сложности кода, и многие команды переключают свою инфраструктуру, как мы говорим.

Правило № 30: Выбранные данные о важности, не произвольно бросайте их!

Когда у вас слишком много данных, существует соблазн взять файлы 1-12 и игнорировать файлы 13-99. Это ошибка. Хотя данные, которые никогда не были показаны пользователю, могут быть сброшены, весом важности лучше всего подходит для остальных. Важность взвешивания означает, что если вы решаете, что вы собираетесь образец примера X с вероятностью 30%, то придайте ему вес 10/3. При весте, все калибровочные свойства, обсуждаемые в правиле № 14, все еще сохраняются.

Правило № 31: Остерегайтесь того, что если вы присоединяетесь к данным из таблицы при обучении и времени обслуживания, данные в таблице могут измениться.

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

Правило № 32: Повторно используйте код между вашим тренировочным конвейером и вашим конвейером, когда это возможно.

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

Правило № 33: Если вы создаете модель на основе данных до 5 января, проверьте модель на данных с 6 января и после.

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

Правило № 34: В бинарной классификации для фильтрации (например, обнаружение спама или определение интересных электронных писем) приносите небольшие краткосрочные жертвы в производительности для очень чистых данных.

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

Но этот подход вводит смещение отбора проб. Вы можете собирать более чистые данные, если вместо этого во время обслуживания вашего маркировки 1% всего трафика как «удерживается», и отправить все примеры пользователю. Теперь ваш фильтр блокирует не менее 74% от негативных примеров. Эти примеры могут стать вашими учебными данными.

Обратите внимание, что если ваш фильтр блокирует 95% от отрицательных примеров или более, этот подход становится менее жизнеспособным. Несмотря на это, если вы хотите измерить производительность обслуживания, вы можете сделать еще более крошечный образец (скажем, 0,1% или 0,001%). Десять тысяч примеров достаточно, чтобы оценить производительность довольно точно.

Правило № 35: Остерегайтесь неотъемлемого перекоса в рейтинге.

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

1. Имейте более высокую регуляризацию на функциях, которые охватывают больше вопросов, в отличие от тех функций, которые включены только для одного запроса. Таким образом, модель будет способствовать функциям, специфичным для одного или нескольких запросов по сравнению с функциями, которые обобщаются ко всем запросам. Этот подход может помочь предотвратить проникновение очень популярных результатов в неактуальные запросы. Обратите внимание, что это напротив более обычных советов о том, чтобы иметь больше регуляризации на столбцах функций с более уникальными значениями.
2. Только позволяют функциям иметь положительные веса. Таким образом, любая хорошая функция будет лучше, чем функция, которая «неизвестна».
3. У вас нет функций только для документов. Это экстремальная версия #1. Например, даже если данное приложение является популярной загрузкой независимо от того, что такое запрос, вы не хотите показывать его повсюду. Отсутствие функций только для документов делает это просто. Причина, по которой вы не хотите показывать конкретное популярное приложение повсюду, связана с важности сделать все желаемые приложения. Например, если кто -то ищет «приложение для наблюдения за птицами», он может скачать «Angry Birds», но это, конечно, не было их намерением. Показание такого приложения может улучшить скорость загрузки, но оставить потребности пользователя в конечном итоге неудовлетворенными.

Правило № 36: Избегайте петли обратной связи с позиционными функциями.

Положение контента значительно влияет на то, насколько вероятно, что пользователь будет взаимодействовать с ним. Если вы поместите приложение в первую позицию, оно будет нажимать чаще, и вы будете убеждены, что оно будет с большей вероятностью нажать. Один из способов справиться с этим - добавить позиционные функции, т.е. функции о положении контента на странице. Вы тренируете свою модель с позиционными функциями, и она учится весу, например, функцию «1stposition» в значительной степени. Таким образом, ваша модель дает меньше веса другим факторам для примеров с «1stposition = true». Затем при обслуживании вы не даете никаких экземпляров позиционной функции, или вы даете им одинаковую функцию по умолчанию, потому что вы забиваете кандидатов, прежде чем вы решите заказ для их отображения.

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

Правило № 37: Измерение обучения/аварийного перекоса.

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

• Разница между производительностью учебных данных и данными удержания. В целом, это всегда будет существовать, и это не всегда плохо.
• Разница между производительностью в данных удержания и данными «следующий день». Опять же, это всегда будет существовать. Вы должны настроить свою регуляризацию, чтобы максимизировать производительность на следующий день. Тем не менее, большие падения производительности между данными Holdout и на следующий день могут указывать на то, что некоторые функции чувствительны к во времени и, возможно, ухудшают производительность модели.
• Разница между производительностью в данных «следующий день» и живыми данными. Если вы применяете модель к примеру в учебных данных и в том же примере при обслуживании, она должна дать вам точно такой же результат (см. Правило № 5 ). Таким образом, расхождение здесь, вероятно, указывает на инженерную ошибку.

ML Phase III: замедленный рост, уточнение оптимизации и сложные модели

Будут определенные признаки того, что второй этап достигает закрытия. Прежде всего, ваши ежемесячные выгоды начнут уменьшаться. Вы начнете иметь компромиссы между показателями: вы увидите некоторый рост, а другие попадают в некоторые эксперименты. Вот где это становится интересным. Поскольку выгоды труднее достичь, машинное обучение должно стать более сложным. Предостережение: этот раздел имеет больше правил синего неба, чем в более ранних разделах. Мы видели, как многие команды пережили счастливые времена фазы I и фазы II машинного обучения. Как только этап III достигнут, команды должны найти свой собственный путь.

Правило № 38: Не тратьте время на новые функции, если не выдвинутые цели стали проблемой.

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

Правило № 39: Решения о запуске являются прокси для долгосрочных целей продукта.

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

Правда в том, что реальный мир - это не подземелья и драконы: нет «очков жизни», определяющих здоровье вашего продукта. Команда должна использовать статистику, которую она собирает, чтобы попытаться эффективно предсказать, насколько хорошей будет система в будущем. Им нужно заботиться о вовлеченности, 1 -дневных активных пользователей (DAU), 30 DAU, доходов и доходности рекламодателей. Эти метрики, которые измеряются в A/B -тестах сами по себе, являются лишь прокси для более долгосрочных целей: удовлетворение пользователей, повышение пользователей, удовлетворение партнеров и прибыль, что даже тогда вы можете рассмотреть прокси для получения полезного, высококачественного продукта и Процветающая компания через пять лет.

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

Эксперимент	Ежедневные активные пользователи	Доход/день
А	1 миллион	4 миллиона долларов
Б	2 миллиона	2 миллиона долларов

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

Более того, No Metric не покрывает окончательную озабоченность команды: «Где мой продукт будет через пять лет»?

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

Правило № 40: Держите ансамбли простыми.

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

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

Правило № 41: Когда Performance Plateaus ищите качественно новые источники информации, чтобы добавить, а не уточнить существующие сигналы.

Вы добавили некоторую демографическую информацию о пользователе. Вы добавили некоторую информацию о словах в документе. Вы прошли исследование шаблонов и настроили регуляризацию. Вы не видели запуска с более чем 1% улучшением ваших ключевых метрик за несколько кварталов. И что теперь?

Пришло время начать создавать инфраструктуру для радикально разных функций, таких как история документов, к которым этот пользователь получил доступ в последний день, неделю или год, или данные из другого свойства. Используйте организации Wikidata или что -то внутреннее для вашей компании (например, график знаний Google). Используйте глубокое обучение. Начните скорректировать свои ожидания в отношении того, сколько возврата вы ожидаете от инвестиций, и соответствующим образом расширите свои усилия. Как и в любом инженерном проекте, вы должны взвесить выгоду от добавления новых функций по сравнению с стоимостью увеличения сложности.

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

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

Проблема в том, что обычным, как правило, трудно победить.

Обратите внимание, что если ваша система измеряет клики, время потраченного времени, часы, +1S, Reshares, и так далее, вы измеряете популярность содержания. Команды иногда пытаются выучить личную модель с разнообразием. Чтобы персонализировать, они добавляют функции, которые позволили бы системе персонализировать (некоторые функции, представляющие интерес пользователя) или диверсифицировать (функции, указывающие, есть ли в этом документе какие -либо общие функции с другими возвращенными документами, такими как автор или контент), и обнаруживают, что эти Особенности получают меньший вес (или иногда другой знак), чем они ожидают.

Это не означает, что разнообразие, персонализация или актуальность не являются ценными. Как указывалось в предыдущем правиле, вы можете выполнить постобработку, чтобы увеличить разнообразие или актуальность. Если вы видите более долгосрочные цели увеличиваются, то вы можете заявить, что разнообразие/релевантность является ценным, помимо популярности. Затем вы можете либо продолжать использовать свою пост -обработку, либо напрямую изменять цель на основе разнообразия или актуальности.

Правило № 43: Ваши друзья, как правило, одинаковы для разных продуктов. Ваши интересы, как правило, не являются.

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

Связанная работа

В Google есть много документов по машинному обучению, а также внешне.

• Курс сбоя машинного обучения : введение в прикладное машинное обучение.
• Машинное обучение: вероятностный подход Кевина Мерфи для понимания области машинного обучения.
• Хороший анализ данных : подход науки о данных к размышлению о наборах данных.
• Глубокое обучение Яном Гудфеллоу и др. Для изучения нелинейных моделей.
• Google Paper по техническому долгу , который имеет много общих советов.
• Документация Tensorflow .

Благодарности

Thanks to David Westbrook, Peter Brandt, Samuel Ieong, Chenyu Zhao, Li Wei, Michalis Potamias, Evan Rosen, Barry Rosenberg, Christine Robson, James Pine, Tal Shaked, Tushar Chandra, Mustafa Ispir, Jeremiah Harmsen, Konstantinos Katsiapis, Glen Anderson, Дэн Дакворт, Шишир Бирмивал, Гал Элидан, Су Лин Ву, Джайхуй Лю, Фернандо Перейра и Хришикеш Арадхей для многих исправлений, предложений и полезных примеров для этого документа. Кроме того, благодаря Кристен Лефевр, Суддху Басу и Крису Бергу, которая помогла с более ранней версией. Любые ошибки, упущения или (задыхаться!) Непопулярные мнения - мои собственные.

Приложение

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

Обзор YouTube

YouTube - это потоковая видео служба. Оба команды YouTube смотрят Next, так и команды на домашних страницах YouTube используют модели ML для ранжирования видео рекомендаций. Смотреть Next рекомендует видео для просмотра после того, как в настоящее время играет один, в то время как Home Page рекомендует видео пользователям, просматривая домашнюю страницу.

Google Play Обзор

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

Google Plus Обзор

Google Plus использовал машинное обучение в различных ситуациях: рейтинговые посты в «потоке» постов, которые можно увидеть пользователем, ранжируя посты «What Hot» (посты, которые очень популярны сейчас, оценивают людей, которых вы знаете, и так далее. Google Plus закрыл все личные учетные записи в 2019 году и был заменен Google Currents для бизнес -счетов 6 июля 2020 года.

,

Лучшие практики для ML Engineering

Мартин Зинкевич

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

Мартин Зинкевич представляет 10 своих любимых правил машинного обучения. Читайте дальше, чтобы выучить все 43 правила!

Терминология

Следующие термины будут неоднократно появляться в нашем обсуждении эффективного машинного обучения:

• Пример : вещь, о которой вы хотите сделать предсказание. Например, экземпляр может быть веб -страницей, которую вы хотите классифицировать как «о кошках» или «не о кошках».
• Метка : Ответ на задачу прогнозирования либо ответ, созданный системой машинного обучения, или правильный ответ, предоставленный в учебных данных. Например, этикетка для веб -страницы может быть «о кошках».
• Особенность : свойство экземпляра, используемого в задаче прогнозирования. Например, веб -страница может иметь функцию «содержит слово« кошка »».
• Столбец функции : набор связанных функций, таких как набор всех возможных стран, в которых пользователи могут жить. Пример может иметь одну или несколько функций, присутствующих в столбце функции. «Столбец функции»-это Google-специфическая терминология. Столбец функции называется «пространством имен» в системе VW (в Yahoo/Microsoft) или в поле .
• Пример : экземпляр (с его функциями) и этикетка.
• Модель : статистическое представление задачи прогнозирования. Вы тренируете модель на примерах, затем используете модель для прогнозирования.
• Метрика : число, о котором вы заботитесь. Может или не может быть непосредственно оптимизирован.
• Цель : показатель, который ваш алгоритм пытается оптимизировать.
• Трубопровод : инфраструктура, окружающая алгоритм машинного обучения. Включает сбор данных с передней части, помещение их в файлы обучения данных, обучение одной или нескольких моделей и экспорт моделей в производство.
• Проголовок по проведению процента посетителей на веб-странице, которые щелкнут ссылку в объявлении.

Обзор

Чтобы сделать отличные продукты:

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

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

1. Убедитесь, что ваш трубопровод находится с твердым конец до конца.
2. Начните с разумной цели.
3. Добавьте функции здравого смысла простым способом.
4. Убедитесь, что ваш трубопровод остается твердым.

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

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

Этот документ организован следующим образом:

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

Перед машинным обучением

Правило № 1: Не бойтесь запустить продукт без машинного обучения.

Машинное обучение круто, но это требует данных. Theoretically, you can take data from a different problem and then tweak the model for a new product, but this will likely underperform basic heuristics . If you think that machine learning will give you a 100% boost, then a heuristic will get you 50% of the way there.

For instance, if you are ranking apps in an app marketplace, you could use the install rate or number of installs as heuristics. If you are detecting spam, filter out publishers that have sent spam before. Don't be afraid to use human editing either. If you need to rank contacts, rank the most recently used highest (or even rank alphabetically). If machine learning is not absolutely required for your product, don't use it until you have data.

Rule #2: First, design and implement metrics.

Before formalizing what your machine learning system will do, track as much as possible in your current system. Do this for the following reasons:

1. It is easier to gain permission from the system's users earlier on.
2. If you think that something might be a concern in the future, it is better to get historical data now.
3. If you design your system with metric instrumentation in mind, things will go better for you in the future. Specifically, you don't want to find yourself grepping for strings in logs to instrument your metrics!
4. You will notice what things change and what stays the same. For instance, suppose you want to directly optimize one-day active users. However, during your early manipulations of the system, you may notice that dramatic alterations of the user experience don't noticeably change this metric.

Google Plus team measures expands per read, reshares per read, plusones per read, comments/read, comments per user, reshares per user, etc. which they use in computing the goodness of a post at serving time. Also, note that an experiment framework, in which you can group users into buckets and aggregate statistics by experiment, is important. See Rule #12 .

By being more liberal about gathering metrics, you can gain a broader picture of your system. Notice a problem? Add a metric to track it! Excited about some quantitative change on the last release? Add a metric to track it!

Rule #3: Choose machine learning over a complex heuristic.

A simple heuristic can get your product out the door. A complex heuristic is unmaintainable. Once you have data and a basic idea of what you are trying to accomplish, move on to machine learning. As in most software engineering tasks, you will want to be constantly updating your approach, whether it is a heuristic or a machine-learned model, and you will find that the machine-learned model is easier to update and maintain (see Rule #16 ).

ML Phase I: Your First Pipeline

Focus on your system infrastructure for your first pipeline. While it is fun to think about all the imaginative machine learning you are going to do, it will be hard to figure out what is happening if you don't first trust your pipeline.

Rule #4: Keep the first model simple and get the infrastructure right.

The first model provides the biggest boost to your product, so it doesn't need to be fancy. But you will run into many more infrastructure issues than you expect. Before anyone can use your fancy new machine learning system, you have to determine:

• How to get examples to your learning algorithm.
• A first cut as to what "good" and "bad" mean to your system.
• How to integrate your model into your application. You can either apply the model live, or precompute the model on examples offline and store the results in a table. For example, you might want to preclassify web pages and store the results in a table, but you might want to classify chat messages live.

Choosing simple features makes it easier to ensure that:

• The features reach your learning algorithm correctly.
• The model learns reasonable weights.
• The features reach your model in the server correctly.

Once you have a system that does these three things reliably, you have done most of the work. Your simple model provides you with baseline metrics and a baseline behavior that you can use to test more complex models. Some teams aim for a "neutral" first launch: a first launch that explicitly deprioritizes machine learning gains, to avoid getting distracted.

Rule #5: Test the infrastructure independently from the machine learning.

Make sure that the infrastructure is testable, and that the learning parts of the system are encapsulated so that you can test everything around it. Конкретно:

1. Test getting data into the algorithm. Check that feature columns that should be populated are populated. Where privacy permits, manually inspect the input to your training algorithm. If possible, check statistics in your pipeline in comparison to statistics for the same data processed elsewhere.
2. Test getting models out of the training algorithm. Make sure that the model in your training environment gives the same score as the model in your serving environment (see Rule #37 ).

Machine learning has an element of unpredictability, so make sure that you have tests for the code for creating examples in training and serving, and that you can load and use a fixed model during serving. Also, it is important to understand your data: see Practical Advice for Analysis of Large, Complex Data Sets .

Rule #6: Be careful about dropped data when copying pipelines.

Often we create a pipeline by copying an existing pipeline (ie, cargo cult programming ), and the old pipeline drops data that we need for the new pipeline. For example, the pipeline for Google Plus What's Hot drops older posts (because it is trying to rank fresh posts). This pipeline was copied to use for Google Plus Stream, where older posts are still meaningful, but the pipeline was still dropping old posts. Another common pattern is to only log data that was seen by the user. Thus, this data is useless if we want to model why a particular post was not seen by the user, because all the negative examples have been dropped. A similar issue occurred in Play. While working on Play Apps Home, a new pipeline was created that also contained examples from the landing page for Play Games without any feature to disambiguate where each example came from.

Rule #7: Turn heuristics into features, or handle them externally.

Usually the problems that machine learning is trying to solve are not completely new. There is an existing system for ranking, or classifying, or whatever problem you are trying to solve. This means that there are a bunch of rules and heuristics. These same heuristics can give you a lift when tweaked with machine learning. Your heuristics should be mined for whatever information they have, for two reasons. First, the transition to a machine learned system will be smoother. Second, usually those rules contain a lot of the intuition about the system you don't want to throw away. There are four ways you can use an existing heuristic:

• Preprocess using the heuristic. If the feature is incredibly awesome, then this is an option. For example, if, in a spam filter, the sender has already been blacklisted, don't try to relearn what "blacklisted" means. Block the message. This approach makes the most sense in binary classification tasks.
• Create a feature. Directly creating a feature from the heuristic is great. For example, if you use a heuristic to compute a relevance score for a query result, you can include the score as the value of a feature. Later on you may want to use machine learning techniques to massage the value (for example, converting the value into one of a finite set of discrete values, or combining it with other features) but start by using the raw value produced by the heuristic.
• Mine the raw inputs of the heuristic. If there is a heuristic for apps that combines the number of installs, the number of characters in the text, and the day of the week, then consider pulling these pieces apart, and feeding these inputs into the learning separately. Some techniques that apply to ensembles apply here (see Rule #40 ).
• Modify the label. This is an option when you feel that the heuristic captures information not currently contained in the label. For example, if you are trying to maximize the number of downloads, but you also want quality content, then maybe the solution is to multiply the label by the average number of stars the app received. There is a lot of leeway here. See "Your First Objective" .

Do be mindful of the added complexity when using heuristics in an ML system. Using old heuristics in your new machine learning algorithm can help to create a smooth transition, but think about whether there is a simpler way to accomplish the same effect.

Мониторинг

In general, practice good alerting hygiene, such as making alerts actionable and having a dashboard page.

Rule #8: Know the freshness requirements of your system.

How much does performance degrade if you have a model that is a day old? A week old? A quarter old? This information can help you to understand the priorities of your monitoring. If you lose significant product quality if the model is not updated for a day, it makes sense to have an engineer watching it continuously. Most ad serving systems have new advertisements to handle every day, and must update daily. For instance, if the ML model for Google Play Search is not updated, it can have a negative impact in under a month. Some models for What's Hot in Google Plus have no post identifier in their model so they can export these models infrequently. Other models that have post identifiers are updated much more frequently. Also notice that freshness can change over time, especially when feature columns are added or removed from your model.

Rule #9: Detect problems before exporting models.

Many machine learning systems have a stage where you export the model to serving. If there is an issue with an exported model, it is a user-facing issue.

Do sanity checks right before you export the model. Specifically, make sure that the model's performance is reasonable on held out data. Or, if you have lingering concerns with the data, don't export a model. Many teams continuously deploying models check the area under the ROC curve (or AUC) before exporting. Issues about models that haven't been exported require an email alert, but issues on a user-facing model may require a page. So better to wait and be sure before impacting users.

Rule #10: Watch for silent failures.

This is a problem that occurs more for machine learning systems than for other kinds of systems. Suppose that a particular table that is being joined is no longer being updated. The machine learning system will adjust, and behavior will continue to be reasonably good, decaying gradually. Sometimes you find tables that are months out of date, and a simple refresh improves performance more than any other launch that quarter! The coverage of a feature may change due to implementation changes: for example a feature column could be populated in 90% of the examples, and suddenly drop to 60% of the examples. Play once had a table that was stale for 6 months, and refreshing the table alone gave a boost of 2% in install rate. If you track statistics of the data, as well as manually inspect the data on occasion, you can reduce these kinds of failures.

Rule #11: Give feature columns owners and documentation.

If the system is large, and there are many feature columns, know who created or is maintaining each feature column. If you find that the person who understands a feature column is leaving, make sure that someone has the information. Although many feature columns have descriptive names, it's good to have a more detailed description of what the feature is, where it came from, and how it is expected to help.

Your First Objective

You have many metrics, or measurements about the system that you care about, but your machine learning algorithm will often require a single objective, a number that your algorithm is "trying" to optimize. I distinguish here between objectives and metrics: a metric is any number that your system reports, which may or may not be important. See also Rule #2 .

Rule #12: Don't overthink which objective you choose to directly optimize.

You want to make money, make your users happy, and make the world a better place. There are tons of metrics that you care about, and you should measure them all (see Rule #2 ). However, early in the machine learning process, you will notice them all going up, even those that you do not directly optimize. For instance, suppose you care about number of clicks and time spent on the site. If you optimize for number of clicks, you are likely to see the time spent increase.

So, keep it simple and don't think too hard about balancing different metrics when you can still easily increase all the metrics. Don't take this rule too far though: do not confuse your objective with the ultimate health of the system (see Rule #39 ). And, if you find yourself increasing the directly optimized metric, but deciding not to launch, some objective revision may be required.

Rule #13: Choose a simple, observable and attributable metric for your first objective.

Often you don't know what the true objective is. You think you do but then as you stare at the data and side-by-side analysis of your old system and new ML system, you realize you want to tweak the objective. Further, different team members often can't agree on the true objective. The ML objective should be something that is easy to measure and is a proxy for the "true" objective. In fact, there is often no "true" objective (see Rule#39 ). So train on the simple ML objective, and consider having a "policy layer" on top that allows you to add additional logic (hopefully very simple logic) to do the final ranking.

The easiest thing to model is a user behavior that is directly observed and attributable to an action of the system:

• Was this ranked link clicked?
• Was this ranked object downloaded?
• Was this ranked object forwarded/replied to/emailed?
• Was this ranked object rated?
• Was this shown object marked as spam/pornography/offensive?

Avoid modeling indirect effects at first:

• Did the user visit the next day?
• How long did the user visit the site?
• What were the daily active users?

Indirect effects make great metrics, and can be used during A/B testing and during launch decisions.

Finally, don't try to get the machine learning to figure out:

• Is the user happy using the product?
• Is the user satisfied with the experience?
• Is the product improving the user's overall wellbeing?
• How will this affect the company's overall health?

These are all important, but also incredibly hard to measure. Instead, use proxies: if the user is happy, they will stay on the site longer. If the user is satisfied, they will visit again tomorrow. Insofar as well-being and company health is concerned, human judgement is required to connect any machine learned objective to the nature of the product you are selling and your business plan.

Rule #14: Starting with an interpretable model makes debugging easier.

Linear regression, logistic regression, and Poisson regression are directly motivated by a probabilistic model. Each prediction is interpretable as a probability or an expected value. This makes them easier to debug than models that use objectives (zero-one loss, various hinge losses, and so on) that try to directly optimize classification accuracy or ranking performance. For example, if probabilities in training deviate from probabilities predicted in side-by-sides or by inspecting the production system, this deviation could reveal a problem.

For example, in linear, logistic, or Poisson regression, there are subsets of the data where the average predicted expectation equals the average label (1- moment calibrated, or just calibrated) . This is true assuming that you have no regularization and that your algorithm has converged, and it is approximately true in general. If you have a feature which is either 1 or 0 for each example, then the set of 3 examples where that feature is 1 is calibrated. Also, if you have a feature that is 1 for every example, then the set of all examples is calibrated.

With simple models, it is easier to deal with feedback loops (see Rule #36 ). Often, we use these probabilistic predictions to make a decision: eg rank posts in decreasing expected value (ie probability of click/download/etc.). However, remember when it comes time to choose which model to use, the decision matters more than the likelihood of the data given the model (see Rule #27 ).

Rule #15: Separate Spam Filtering and Quality Ranking in a Policy Layer.

Quality ranking is a fine art, but spam filtering is a war. The signals that you use to determine high quality posts will become obvious to those who use your system, and they will tweak their posts to have these properties. Thus, your quality ranking should focus on ranking content that is posted in good faith. You should not discount the quality ranking learner for ranking spam highly. Similarly, "racy" content should be handled separately from Quality Ranking. Spam filtering is a different story. You have to expect that the features that you need to generate will be constantly changing. Often, there will be obvious rules that you put into the system (if a post has more than three spam votes, don't retrieve it, et cetera). Any learned model will have to be updated daily, if not faster. The reputation of the creator of the content will play a great role.

At some level, the output of these two systems will have to be integrated. Keep in mind, filtering spam in search results should probably be more aggressive than filtering spam in email messages. Also, it is a standard practice to remove spam from the training data for the quality classifier.

ML Phase II: Feature Engineering

In the first phase of the lifecycle of a machine learning system, the important issues are to get the training data into the learning system, get any metrics of interest instrumented, and create a serving infrastructure. After you have a working end to end system with unit and system tests instrumented, Phase II begins.

In the second phase, there is a lot of low-hanging fruit. There are a variety of obvious features that could be pulled into the system. Thus, the second phase of machine learning involves pulling in as many features as possible and combining them in intuitive ways. During this phase, all of the metrics should still be rising. There will be lots of launches, and it is a great time to pull in lots of engineers that can join up all the data that you need to create a truly awesome learning system.

Rule #16: Plan to launch and iterate.

Don't expect that the model you are working on now will be the last one that you will launch, or even that you will ever stop launching models. Thus consider whether the complexity you are adding with this launch will slow down future launches. Many teams have launched a model per quarter or more for years. There are three basic reasons to launch new models:

• You are coming up with new features.
• You are tuning regularization and combining old features in new ways.
• You are tuning the objective.

Regardless, giving a model a bit of love can be good: looking over the data feeding into the example can help find new signals as well as old, broken ones. So, as you build your model, think about how easy it is to add or remove or recombine features. Think about how easy it is to create a fresh copy of the pipeline and verify its correctness. Think about whether it is possible to have two or three copies running in parallel. Finally, don't worry about whether feature 16 of 35 makes it into this version of the pipeline. You'll get it next quarter.

Rule #17: Start with directly observed and reported features as opposed to learned features.

This might be a controversial point, but it avoids a lot of pitfalls. First of all, let's describe what a learned feature is. A learned feature is a feature generated either by an external system (such as an unsupervised clustering system) or by the learner itself (eg via a factored model or deep learning). Both of these can be useful, but they can have a lot of issues, so they should not be in the first model.

If you use an external system to create a feature, remember that the external system has its own objective. The external system's objective may be only weakly correlated with your current objective. If you grab a snapshot of the external system, then it can become out of date. If you update the features from the external system, then the meanings may change. If you use an external system to provide a feature, be aware that this approach requires a great deal of care.

The primary issue with factored models and deep models is that they are nonconvex. Thus, there is no guarantee that an optimal solution can be approximated or found, and the local minima found on each iteration can be different. This variation makes it hard to judge whether the impact of a change to your system is meaningful or random. By creating a model without deep features, you can get an excellent baseline performance. After this baseline is achieved, you can try more esoteric approaches.

Rule #18: Explore with features of content that generalize across contexts.

Often a machine learning system is a small part of a much bigger picture. For example, if you imagine a post that might be used in What's Hot, many people will plus-one, reshare, or comment on a post before it is ever shown in What's Hot. If you provide those statistics to the learner, it can promote new posts that it has no data for in the context it is optimizing. YouTube Watch Next could use number of watches, or co- watches (counts of how many times one video was watched after another was watched) from YouTube search. You can also use explicit user ratings. Finally, if you have a user action that you are using as a label, seeing that action on the document in a different context can be a great feature. All of these features allow you to bring new content into the context. Note that this is not about personalization: figure out if someone likes the content in this context first, then figure out who likes it more or less.

Rule #19: Use very specific features when you can.

With tons of data, it is simpler to learn millions of simple features than a few complex features. Identifiers of documents being retrieved and canonicalized queries do not provide much generalization, but align your ranking with your labels on head queries. Thus, don't be afraid of groups of features where each feature applies to a very small fraction of your data, but overall coverage is above 90%. You can use regularization to eliminate the features that apply to too few examples.

Rule #20: Combine and modify existing features to create new features in human-understandable ways.

There are a variety of ways to combine and modify features. Machine learning systems such as TensorFlow allow you to pre-process your data through transformations . The two most standard approaches are "discretizations" and "crosses".

Discretization consists of taking a continuous feature and creating many discrete features from it. Consider a continuous feature such as age. You can create a feature which is 1 when age is less than 18, another feature which is 1 when age is between 18 and 35, et cetera. Don't overthink the boundaries of these histograms: basic quantiles will give you most of the impact.

Crosses combine two or more feature columns. A feature column, in TensorFlow's terminology, is a set of homogenous features, (eg {male, female}, {US, Canada, Mexico}, et cetera). A cross is a new feature column with features in, for example, {male, female} × {US,Canada, Mexico}. This new feature column will contain the feature (male, Canada). If you are using TensorFlow and you tell TensorFlow to create this cross for you, this (male, Canada) feature will be present in examples representing male Canadians. Note that it takes massive amounts of data to learn models with crosses of three, four, or more base feature columns.

Crosses that produce very large feature columns may overfit. For instance, imagine that you are doing some sort of search, and you have a feature column with words in the query, and you have a feature column with words in the document. You can combine these with a cross, but you will end up with a lot of features (see Rule #21 ).

When working with text there are two alternatives. The most draconian is a dot product. A dot product in its simplest form simply counts the number of words in common between the query and the document. This feature can then be discretized. Another approach is an intersection: thus, we will have a feature which is present if and only if the word "pony" is in both the document and the query, and another feature which is present if and only if the word "the" is in both the document and the query.

Rule #21: The number of feature weights you can learn in a linear model is roughly proportional to the amount of data you have.

There are fascinating statistical learning theory results concerning the appropriate level of complexity for a model, but this rule is basically all you need to know. I have had conversations in which people were doubtful that anything can be learned from one thousand examples, or that you would ever need more than one million examples, because they get stuck in a certain method of learning. The key is to scale your learning to the size of your data:

1. If you are working on a search ranking system, and there are millions of different words in the documents and the query and you have 1000 labeled examples, then you should use a dot product between document and query features, TF-IDF , and a half-dozen other highly human-engineered features. 1000 examples, a dozen features.
2. If you have a million examples, then intersect the document and query feature columns, using regularization and possibly feature selection. This will give you millions of features, but with regularization you will have fewer. Ten million examples, maybe a hundred thousand features.
3. If you have billions or hundreds of billions of examples, you can cross the feature columns with document and query tokens, using feature selection and regularization. You will have a billion examples, and 10 million features. Statistical learning theory rarely gives tight bounds, but gives great guidance for a starting point.

In the end, use Rule #28 to decide what features to use.

Rule #22: Clean up features you are no longer using.

Unused features create technical debt. If you find that you are not using a feature, and that combining it with other features is not working, then drop it out of your infrastructure. You want to keep your infrastructure clean so that the most promising features can be tried as fast as possible. If necessary, someone can always add back your feature.

Keep coverage in mind when considering what features to add or keep. How many examples are covered by the feature? For example, if you have some personalization features, but only 8% of your users have any personalization features, it is not going to be very effective.

At the same time, some features may punch above their weight. For example, if you have a feature which covers only 1% of the data, but 90% of the examples that have the feature are positive, then it will be a great feature to add.

Human Analysis of the System

Before going on to the third phase of machine learning, it is important to focus on something that is not taught in any machine learning class: how to look at an existing model, and improve it. This is more of an art than a science, and yet there are several antipatterns that it helps to avoid.

Rule #23: You are not a typical end user.

This is perhaps the easiest way for a team to get bogged down. While there are a lot of benefits to fishfooding (using a prototype within your team) and dogfooding (using a prototype within your company), employees should look at whether the performance is correct. While a change which is obviously bad should not be used, anything that looks reasonably near production should be tested further, either by paying laypeople to answer questions on a crowdsourcing platform, or through a live experiment on real users.

There are two reasons for this. The first is that you are too close to the code. You may be looking for a particular aspect of the posts, or you are simply too emotionally involved (eg confirmation bias). The second is that your time is too valuable. Consider the cost of nine engineers sitting in a one hour meeting, and think of how many contracted human labels that buys on a crowdsourcing platform.

If you really want to have user feedback, use user experience methodologies . Create user personas (one description is in Bill Buxton's Sketching User Experiences ) early in a process and do usability testing (one description is in Steve Krug's Don't Make Me Think ) later. User personas involve creating a hypothetical user. For instance, if your team is all male, it might help to design a 35-year-old female user persona (complete with user features), and look at the results it generates rather than 10 results for 25-to-40 year old males. Bringing in actual people to watch their reaction to your site (locally or remotely) in usability testing can also get you a fresh perspective.

Rule #24: Measure the delta between models.

One of the easiest and sometimes most useful measurements you can make before any users have looked at your new model is to calculate just how different the new results are from production. For instance, if you have a ranking problem, run both models on a sample of queries through the entire system, and look at the size of the symmetric difference of the results (weighted by ranking position). If the difference is very small, then you can tell without running an experiment that there will be little change. If the difference is very large, then you want to make sure that the change is good. Looking over queries where the symmetric difference is high can help you to understand qualitatively what the change was like. Make sure, however, that the system is stable. Make sure that a model when compared with itself has a low (ideally zero) symmetric difference.

Rule #25: When choosing models, utilitarian performance trumps predictive power.

Your model may try to predict click-through rate. However, in the end, the key question is what you do with that prediction. If you are using it to rank documents, then the quality of the final ranking matters more than the prediction itself. If you predict the probability that a document is spam and then have a cutoff on what is blocked, then the precision of what is allowed through matters more. Most of the time, these two things should be in agreement: when they do not agree, it will likely be on a small gain. Thus, if there is some change that improves log loss but degrades the performance of the system, look for another feature. When this starts happening more often, it is time to revisit the objective of your model.

Rule #26: Look for patterns in the measured errors, and create new features.

Suppose that you see a training example that the model got "wrong". In a classification task, this error could be a false positive or a false negative. In a ranking task, the error could be a pair where a positive was ranked lower than a negative. The most important point is that this is an example that the machine learning system knows it got wrong and would like to fix if given the opportunity. If you give the model a feature that allows it to fix the error, the model will try to use it.

On the other hand, if you try to create a feature based upon examples the system doesn't see as mistakes, the feature will be ignored. For instance, suppose that in Play Apps Search, someone searches for "free games". Suppose one of the top results is a less relevant gag app. So you create a feature for "gag apps". However, if you are maximizing number of installs, and people install a gag app when they search for free games, the "gag apps" feature won't have the effect you want.

Once you have examples that the model got wrong, look for trends that are outside your current feature set. For instance, if the system seems to be demoting longer posts, then add post length. Don't be too specific about the features you add. If you are going to add post length, don't try to guess what long means, just add a dozen features and the let model figure out what to do with them (see Rule #21 ). That is the easiest way to get what you want.

Rule #27: Try to quantify observed undesirable behavior.

Some members of your team will start to be frustrated with properties of the system they don't like which aren't captured by the existing loss function. At this point, they should do whatever it takes to turn their gripes into solid numbers. For example, if they think that too many "gag apps" are being shown in Play Search, they could have human raters identify gag apps. (You can feasibly use humanlabelled data in this case because a relatively small fraction of the queries account for a large fraction of the traffic.) If your issues are measurable, then you can start using them as features, objectives, or metrics. The general rule is " measure first, optimize second ".

Rule #28: Be aware that identical short-term behavior does not imply identical long-term behavior.

Imagine that you have a new system that looks at every doc_id and exact_query, and then calculates the probability of click for every doc for every query. You find that its behavior is nearly identical to your current system in both side by sides and A/B testing, so given its simplicity, you launch it. However, you notice that no new apps are being shown. Почему? Well, since your system only shows a doc based on its own history with that query, there is no way to learn that a new doc should be shown.

The only way to understand how such a system would work long-term is to have it train only on data acquired when the model was live. This is very difficult.

Training-Serving Skew

Training-serving skew is a difference between performance during training and performance during serving. This skew can be caused by:

• A discrepancy between how you handle data in the training and serving pipelines.
• A change in the data between when you train and when you serve.
• A feedback loop between your model and your algorithm.

We have observed production machine learning systems at Google with training- serving skew that negatively impacts performance. The best solution is to explicitly monitor it so that system and data changes don't introduce skew unnoticed.

Rule #29: The best way to make sure that you train like you serve is to save the set of features used at serving time, and then pipe those features to a log to use them at training time.

Even if you can't do this for every example, do it for a small fraction, such that you can verify the consistency between serving and training (see Rule #37 ). Teams that have made this measurement at Google were sometimes surprised by the results. YouTube home page switched to logging features at serving time with significant quality improvements and a reduction in code complexity, and many teams are switching their infrastructure as we speak.

Rule #30: Importance-weight sampled data, don't arbitrarily drop it!

When you have too much data, there is a temptation to take files 1-12, and ignore files 13-99. This is a mistake. Although data that was never shown to the user can be dropped, importance weighting is best for the rest. Importance weighting means that if you decide that you are going to sample example X with a 30% probability, then give it a weight of 10/3. With importance weighting, all of the calibration properties discussed in Rule #14 still hold.

Rule #31: Beware that if you join data from a table at training and serving time, the data in the table may change.

Say you join doc ids with a table containing features for those docs (such as number of comments or clicks). Between training and serving time, features in the table may be changed. Your model's prediction for the same document may then differ between training and serving. The easiest way to avoid this sort of problem is to log features at serving time (see Rule #32 ). If the table is changing only slowly, you can also snapshot the table hourly or daily to get reasonably close data. Note that this still doesn't completely resolve the issue.

Rule #32: Re-use code between your training pipeline and your serving pipeline whenever possible.

Batch processing is different than online processing. In online processing, you must handle each request as it arrives (eg you must do a separate lookup for each query), whereas in batch processing, you can combine tasks (eg making a join). At serving time, you are doing online processing, whereas training is a batch processing task. However, there are some things that you can do to re-use code. For example, you can create an object that is particular to your system where the result of any queries or joins can be stored in a very human readable way, and errors can be tested easily. Then, once you have gathered all the information, during serving or training, you run a common method to bridge between the human-readable object that is specific to your system, and whatever format the machine learning system expects. This eliminates a source of training-serving skew . As a corollary, try not to use two different programming languages between training and serving. That decision will make it nearly impossible for you to share code.

Rule #33: If you produce a model based on the data until January 5th, test the model on the data from January 6th and after.

In general, measure performance of a model on the data gathered after the data you trained the model on, as this better reflects what your system will do in production. If you produce a model based on the data until January 5th, test the model on the data from January 6th. You will expect that the performance will not be as good on the new data, but it shouldn't be radically worse. Since there might be daily effects, you might not predict the average click rate or conversion rate, but the area under the curve, which represents the likelihood of giving the positive example a score higher than a negative example, should be reasonably close.

Rule #34: In binary classification for filtering (such as spam detection or determining interesting emails), make small short-term sacrifices in performance for very clean data.

In a filtering task, examples which are marked as negative are not shown to the user. Suppose you have a filter that blocks 75% of the negative examples at serving. You might be tempted to draw additional training data from the instances shown to users. For example, if a user marks an email as spam that your filter let through, you might want to learn from that.

But this approach introduces sampling bias. You can gather cleaner data if instead during serving you label 1% of all traffic as "held out", and send all held out examples to the user. Now your filter is blocking at least 74% of the negative examples. These held out examples can become your training data.

Note that if your filter is blocking 95% of the negative examples or more, this approach becomes less viable. Even so, if you wish to measure serving performance, you can make an even tinier sample (say 0.1% or 0.001%). Ten thousand examples is enough to estimate performance quite accurately.

Rule #35: Beware of the inherent skew in ranking problems.

When you switch your ranking algorithm radically enough that different results show up, you have effectively changed the data that your algorithm is going to see in the future. This kind of skew will show up, and you should design your model around it. There are multiple different approaches. These approaches are all ways to favor data that your model has already seen.

1. Have higher regularization on features that cover more queries as opposed to those features that are on for only one query. This way, the model will favor features that are specific to one or a few queries over features that generalize to all queries. This approach can help prevent very popular results from leaking into irrelevant queries. Note that this is opposite the more conventional advice of having more regularization on feature columns with more unique values.
2. Only allow features to have positive weights. Thus, any good feature will be better than a feature that is "unknown".
3. Don't have document-only features. This is an extreme version of #1. For example, even if a given app is a popular download regardless of what the query was, you don't want to show it everywhere. Not having document-only features keeps that simple. The reason you don't want to show a specific popular app everywhere has to do with the importance of making all the desired apps reachable. For instance, if someone searches for "bird watching app", they might download "angry birds", but that certainly wasn't their intent. Showing such an app might improve download rate, but leave the user's needs ultimately unsatisfied.

Rule #36: Avoid feedback loops with positional features.

The position of content dramatically affects how likely the user is to interact with it. If you put an app in the first position it will be clicked more often, and you will be convinced it is more likely to be clicked. One way to deal with this is to add positional features, ie features about the position of the content in the page. You train your model with positional features, and it learns to weight, for example, the feature "1stposition" heavily. Your model thus gives less weight to other factors for examples with "1stposition=true". Then at serving you don't give any instances the positional feature, or you give them all the same default feature, because you are scoring candidates before you have decided the order in which to display them.

Note that it is important to keep any positional features somewhat separate from the rest of the model because of this asymmetry between training and testing. Having the model be the sum of a function of the positional features and a function of the rest of the features is ideal. For example, don't cross the positional features with any document feature.

Rule #37: Measure Training/Serving Skew.

There are several things that can cause skew in the most general sense. Moreover, you can divide it into several parts:

• The difference between the performance on the training data and the holdout data. In general, this will always exist, and it is not always bad.
• The difference between the performance on the holdout data and the "nextday" data. Again, this will always exist. You should tune your regularization to maximize the next-day performance. However, large drops in performance between holdout and next-day data may indicate that some features are time-sensitive and possibly degrading model performance.
• The difference between the performance on the "next-day" data and the live data. If you apply a model to an example in the training data and the same example at serving, it should give you exactly the same result (see Rule #5 ). Thus, a discrepancy here probably indicates an engineering error.

ML Phase III: Slowed Growth, Optimization Refinement, and Complex Models

There will be certain indications that the second phase is reaching a close. First of all, your monthly gains will start to diminish. You will start to have tradeoffs between metrics: you will see some rise and others fall in some experiments. This is where it gets interesting. Since the gains are harder to achieve, the machine learning has to get more sophisticated. A caveat: this section has more blue-sky rules than earlier sections. We have seen many teams go through the happy times of Phase I and Phase II machine learning. Once Phase III has been reached, teams have to find their own path.

Rule #38: Don't waste time on new features if unaligned objectives have become the issue.

As your measurements plateau, your team will start to look at issues that are outside the scope of the objectives of your current machine learning system. As stated before, if the product goals are not covered by the existing algorithmic objective, you need to change either your objective or your product goals. For instance, you may optimize clicks, plus-ones, or downloads, but make launch decisions based in part on human raters.

Rule #39: Launch decisions are a proxy for long-term product goals.

Alice has an idea about reducing the logistic loss of predicting installs. She adds a feature. The logistic loss drops. When she does a live experiment, she sees the install rate increase. However, when she goes to a launch review meeting, someone points out that the number of daily active users drops by 5%. The team decides not to launch the model. Alice is disappointed, but now realizes that launch decisions depend on multiple criteria, only some of which can be directly optimized using ML.

The truth is that the real world is not dungeons and dragons: there are no "hit points" identifying the health of your product. The team has to use the statistics it gathers to try to effectively predict how good the system will be in the future. They need to care about engagement, 1 day active users (DAU), 30 DAU, revenue, and advertiser's return on investment. These metrics that are measureable in A/B tests in themselves are only a proxy for more longterm goals: satisfying users, increasing users, satisfying partners, and profit, which even then you could consider proxies for having a useful, high quality product and a thriving company five years from now.

The only easy launch decisions are when all metrics get better (or at least do not get worse). If the team has a choice between a sophisticated machine learning algorithm, and a simple heuristic, if the simple heuristic does a better job on all these metrics, it should choose the heuristic. Moreover, there is no explicit ranking of all possible metric values. Specifically, consider the following two scenarios:

Эксперимент	Daily Active Users	Revenue/Day
А	1 миллион	$4 million
Б	2 миллиона	$2 million

If the current system is A, then the team would be unlikely to switch to B. If the current system is B, then the team would be unlikely to switch to A. This seems in conflict with rational behavior; however, predictions of changing metrics may or may not pan out, and thus there is a large risk involved with either change. Each metric covers some risk with which the team is concerned.

Moreover, no metric covers the team's ultimate concern, "where is my product going to be five years from now"?

Individuals, on the other hand, tend to favor one objective that they can directly optimize. Most machine learning tools favor such an environment. An engineer banging out new features can get a steady stream of launches in such an environment. There is a type of machine learning, multi-objective learning, which starts to address this problem. For instance, one can formulate a constraint satisfaction problem that has lower bounds on each metric, and optimizes some linear combination of metrics. However, even then, not all metrics are easily framed as machine learning objectives: if a document is clicked on or an app is installed, it is because that the content was shown. But it is far harder to figure out why a user visits your site. How to predict the future success of a site as a whole is AI-complete : as hard as computer vision or natural language processing.

Rule #40: Keep ensembles simple.

Unified models that take in raw features and directly rank content are the easiest models to debug and understand. However, an ensemble of models (a "model" which combines the scores of other models) can work better. To keep things simple, each model should either be an ensemble only taking the input of other models, or a base model taking many features, but not both. If you have models on top of other models that are trained separately, then combining them can result in bad behavior.

Use a simple model for ensembling that takes only the output of your "base" models as inputs. You also want to enforce properties on these ensemble models. For example, an increase in the score produced by a base model should not decrease the score of the ensemble. Also, it is best if the incoming models are semantically interpretable (for example, calibrated) so that changes of the underlying models do not confuse the ensemble model. Also, enforce that an increase in the predicted probability of an underlying classifier does not decrease the predicted probability of the ensemble .

Rule #41: When performance plateaus, look for qualitatively new sources of information to add rather than refining existing signals.

You've added some demographic information about the user. You've added some information about the words in the document. You have gone through template exploration, and tuned the regularization. You haven't seen a launch with more than a 1% improvement in your key metrics in a few quarters. И что теперь?

It is time to start building the infrastructure for radically different features, such as the history of documents that this user has accessed in the last day, week, or year, or data from a different property. Use wikidata entities or something internal to your company (such as Google's knowledge graph ). Use deep learning. Start to adjust your expectations on how much return you expect on investment, and expand your efforts accordingly. As in any engineering project, you have to weigh the benefit of adding new features against the cost of increased complexity.

Rule #42: Don't expect diversity, personalization, or relevance to be as correlated with popularity as you think they are.

Diversity in a set of content can mean many things, with the diversity of the source of the content being one of the most common. Personalization implies each user gets their own results. Relevance implies that the results for a particular query are more appropriate for that query than any other. Thus all three of these properties are defined as being different from the ordinary.

The problem is that the ordinary tends to be hard to beat.

Note that if your system is measuring clicks, time spent, watches, +1s, reshares, et cetera, you are measuring the popularity of the content. Teams sometimes try to learn a personal model with diversity. To personalize, they add features that would allow the system to personalize (some features representing the user's interest) or diversify (features indicating if this document has any features in common with other documents returned, such as author or content), and find that those features get less weight (or sometimes a different sign) than they expect.

This doesn't mean that diversity, personalization, or relevance aren't valuable. As pointed out in the previous rule, you can do postprocessing to increase diversity or relevance. If you see longer term objectives increase, then you can declare that diversity/relevance is valuable, aside from popularity. You can then either continue to use your postprocessing, or directly modify the objective based upon diversity or relevance.

Rule #43: Your friends tend to be the same across different products. Your interests tend not to be.

Teams at Google have gotten a lot of traction from taking a model predicting the closeness of a connection in one product, and having it work well on another. Your friends are who they are. On the other hand, I have watched several teams struggle with personalization features across product divides. Yes, it seems like it should work. For now, it doesn't seem like it does. What has sometimes worked is using raw data from one property to predict behavior on another. Also, keep in mind that even knowing that a user has a history on another property can help. For instance, the presence of user activity on two products may be indicative in and of itself.

Related Work

There are many documents on machine learning at Google as well as externally.

• Machine Learning Crash Course : an introduction to applied machine learning.
• Machine Learning: A Probabilistic Approach by Kevin Murphy for an understanding of the field of machine learning.
• Good Data Analysis : a data science approach to thinking about data sets.
• Deep Learning by Ian Goodfellow et al for learning nonlinear models.
• Google paper on technical debt , which has a lot of general advice.
• Tensorflow Documentation .

Благодарности

Thanks to David Westbrook, Peter Brandt, Samuel Ieong, Chenyu Zhao, Li Wei, Michalis Potamias, Evan Rosen, Barry Rosenberg, Christine Robson, James Pine, Tal Shaked, Tushar Chandra, Mustafa Ispir, Jeremiah Harmsen, Konstantinos Katsiapis, Glen Anderson, Dan Duckworth, Shishir Birmiwal, Gal Elidan, Su Lin Wu, Jaihui Liu, Fernando Pereira, and Hrishikesh Aradhye for many corrections, suggestions, and helpful examples for this document. Also, thanks to Kristen Lefevre, Suddha Basu, and Chris Berg who helped with an earlier version. Any errors, omissions, or (gasp!) unpopular opinions are my own.

Приложение

There are a variety of references to Google products in this document. To provide more context, I give a short description of the most common examples below.

YouTube Overview

YouTube is a streaming video service. Both YouTube Watch Next and YouTube Home Page teams use ML models to rank video recommendations. Watch Next recommends videos to watch after the currently playing one, while Home Page recommends videos to users browsing the home page.

Google Play Overview

Google Play has many models solving a variety of problems. Play Search, Play Home Page Personalized Recommendations, and 'Users Also Installed' apps all use machine learning.

Google Plus Overview

Google Plus used machine learning in a variety of situations: ranking posts in the "stream" of posts being seen by the user, ranking "What's Hot" posts (posts that are very popular now), ranking people you know, et cetera. Google Plus closed down all personal accounts in 2019, and was replaced by Google Currents for business accounts on July 6, 2020.