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

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

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

Цель этого документа – помочь тем, у кого есть базовые знания в области машинного обучения, воспользоваться преимуществами лучших практик 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 есть много документов по машинному обучению, а также внешне.

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

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 года.