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

Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

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

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

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

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

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

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

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

Обзор

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

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

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

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

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

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

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

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

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

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

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

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

Правило № 2: сначала разработайте и внедрите метрики.

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

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

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

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

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

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

ML Phase I: ваш первый пайплайн

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

Правило № 4: Старайтесь, чтобы первая модель была простой, а инфраструктура — правильной.

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

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

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

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

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

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

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

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

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

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

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

Правило № 7: Превратите эвристики в функции или управляйте ими извне.

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

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

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

Мониторинг

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ML Phase 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: Очистите функции, которые вы больше не используете.

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

Помните о покрытии, когда решаете, какие функции добавить или оставить. Сколько примеров охватывает функция? 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. Why? 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:

Experiment Daily Active Users Revenue/Day
A 1 million $4 million
B 2 million $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. Now what?

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.

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

Acknowledgements

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.

Appendix

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.