Google's 43 Rules of Machine Learning

Перевод отличного руководства Мартина Зинкевича "Принципы машинного обучения", с дополнительными комментариями.

---

Вы можете найти терминологию к этому руководству в файле terminology.md.

Вы можете найти введение к этому руководству в файле overview.md.

Содержание

1. Before Machine Learning
2. ML Phase 1: Your First Pipeline
3. ML Phase 2: Feature Engineering
4. ML Phase 3: Slow Growth, Optimation Refinement, and Complex Models
5. Related Work
6. Acknowledgements & Appendix

Note: Asterisk (*) footnotes are my own. Numbered footnotes are Martin's.

Прежде чем использовать машинное обучение

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

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

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

^{Google Research Blog - The 280-Year-Old Algorithm Inside Google Trips}

Правило #2: Во-первых, спроектируйте и реализуйте метрики

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

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

Команда Google Plus измеряет “открытий на просмотр”, “репостов на просмотр”, плюсование(лайк или +1) на просмотр, отношение комментариев к просмотрам, комментарии на пользователя, репосты на пользователя и другие что можно использовать в расчете добротности сообщения во время обслуживания. Также, обратите внимание на экспериментальный фреймворк, который вы можете сгруппировать пользователей в кластеры и агрегироваться статистику для экспериментов, что важно. Смотрите правило #12 .

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

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

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

Первый пайплайн (Pipeline)

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

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

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

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

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

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

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

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

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

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

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

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

Часто мы создаем пайплайн копируя существующий пайплайн (см. культ карго programming), а старый пайплайн удаляет данные которые нужны для нового пайплайну. Например, пайплайн для Google Plus горяче удалял старые сообщения(потому что пытается ранжировать новые сообщения). Этот пайплайн скопирован и использован в Google Plus Stream, где старые сообщения важны, но пайплайн удалял старые сообщения. Другой распространенный шаблон состоит в том что только логгировать данные которые пользователь смотрят. Таким образом, эти данные бесполезны, если мы хотим моделировать почему конкретное сообщение не было замечено пользователем, потому что все негативные примеры были удалены. Похожий случай произошел в Play. Во время работы над “Play Apps Home”, был создан новый пайплайн, который также содержал примеры двух других лендингов (“Play Games Home” and “Play Home Home”) без какого-то признака позволяющего понять откуда пришел каждый объект.

Правило #7: Включите эвристики в признаки или обработайте их

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

1. Предобработка с использованием эвристики. Если признак невероятно хорош, то это вариант. Например, в спам фильтре, если отправитель уже находится в черном списке, то не нужно переучивать и менять значение “черный список”. Заблокируйте сообщение. Этот подход имеет наибольший смысл в задачах бинарной классификации.
2. Создавайте новые признаки. Создание признаков из эвристик это превосходно. К пример, если вы используете эвристику чтобы рассчитать оценку релевантности результатов запроса, вы можете включать оценку значения этого признака. Позже вы можете использовать техники машинного обучения для получения правильного значения(к примеру, преобразование значения в один из конечных наборов дискретных значений или объединение с другими признаками), но начинайте с исходных значений произведенными на основе эвристик.
3. Добавляйте сырые данные из эвристик. Если существует эвристика для приложений, которая объединяет количество установок, количество символов в тексте и день недели, то подумайте о том, чтобы разделить эти части друг от друга и передать в обучение отдельно. Здесь применяются некоторые методы, применимые к ансамблям (см. Правило #40)
4. Изменяйте метку. Этот вариант применяется , если вы чувствуете, что эвристика содержит информацию не отраженную в метке. К примеру, если вы пытаетесь максимизировать количество загрузок, но также вы нуждаетесь в качественном контенте, то возможно решение заключается в умножении метки на средний рейтиг приложения. Здесь много пространства для маневра. Смотрите раздел “Ваша первая цель”. Обратите внимание, что вы добавляете сложности, когда используете эвристики в ML-системе. Использование старых эвристик в новом ML-алгоритме позволяет осуществить плавный переход, но подумайте о том, что может есть просто путь достигнуть того же эффекта.

Мониторинг

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

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

Насколько ухудшается производительность, если ваша модель устареет на 1 день? А на неделю? А на квартал? Это информация поможет вам понять приоритеты вашего мониторинга. Если вы потеряете 10% своего дохода из-за того что модель не обновляется в течении дня, имеет смысл постоянно следить за её работой. В большинстве рекламных систем новые объявления обрабатываются каждый день и ежедневно обновляются. Например, если ML-модель в Google Play Search не будет обновлена, это может повлиять на месячный доход. Некоторые модели для What’s Hot in Google Plus не имеют идентификаторов сообщений в своей модели, поэтому они могут экспортировать этим модели нечасто. Другие модели, у которых есть идентификаторы сообщения, обновляются гораздо чаще. Также обратите внимание, что актуальность может меняться со временем, особенно когда признаки добавляются или удаляются из вашей модели.

Правило #9: Обнаружьте проблемы до экспорта модели.

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

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

Правило #10: Следите за тихими неудачами

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

• ^{A Framework for Analysis of Data Freshness - Bouzeghoub & Peralta}

Правило #11: Назначьте владельцев наборам признаков и документации.

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

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

У вас есть много показателей или измерений относительно системы, о которой вы беспокоитесь, но для МЛ-алгоритма часто требуется одна цель - это число, которое ваш алгоритм “пытается” оптимизировать. Здесь я различаю цели и показатели: метрика - это любое число, которая сообщает ваша система, и она может быть важной, а может быть нет. Смотрите правило #2.

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

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

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

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

Часто вы не знаете, какова истинная цель. Вы думаете, что делаете, а затем, когда вы смотрите на данные и анализируете бок-о-бок вашу старую систему и новую систему МЛ, вы понимаете, что хотите её настроить. Кроме того разные члены команды часто не могут договориться об истинной цели. Цель МЛ должна быть легкой для измерения и прозрачной для “настоящей” цели. Поэтому обучайтесь простой МЛ-цели и подумайте о том, что на самом деле есть “слой политики”, который позволяет вам добавить дополнительную логику (надеюсь, очень простую логику), чтобы сделать окончательный рейтинг.

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

1. Была ли нажата эта ранжированная ссылка?
2. Был ли загружен этот ранжированный объект?
3. Был ли этот ранжированный объект перенаправлен/был ли ответ на него или он отправлен по email?
4. Был ли оценен этот ранжированный объект?
5. Был ли показанный объект отмечен как спам/порнография/оскорбления?

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

1. Вернулся ли посетитель на следующий день?
2. Как долго пользователь был на сайте?
3. Сколько пользователей ежедневно активны?

Косвенные эффекты хорошо улучшают показатели и могут быть использованы в А/Б тестировании и запуске решений. В заключении, не пытайтесь получить от МЛ ответ:

1. Счастлив ли пользователь использующий ваш продукт?
2. Доволен ли пользователь взаимодействием?
3. Улучшает ли продукт общее благополучие пользователя?
4. Как это влияет на общее состояние компании?

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

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

Линейная регрессия, логистическая регрессия, и Пуассоновская регрессия напрямую определяются как вероятностная модель. Каждое предсказание интерпретируется как вероятность или ожидаемое значение. Это облегчает их отладку, чем модели, которые используют цели (zero­one loss, various hinge losses, et cetera), которые пытаются напрямую оптимизировать точность классификации или эффективность ранжирования. К примеру, если вероятности при обучении отклоняются от вероятностей, предсказанных бок-о-бок или путем проверки рабочей системы, это отклонение может выявить проблему.

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

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

^{(3) Это верно, если у вас нет регуляризации и ваш алгоритм сходится. В целом это примерно так.}

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

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

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

^{Google Research Blog - Lessons learned while protecting Gmail}

ML этап II: Feature Engineering

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

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

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

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

1. Вы придумываете новые признаки,
2. Вы настраиваете регуляризацию и комбинируете старые признаки по-новому
3. И/или вы корректируете цель.

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

Правило 17 - Начните с непосредственно наблюдаемых и задокументированных признаков вместо "обученных" признаков.

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

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

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

Правило 18 - Исследуйте особенности контента, которые обобщают контексты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Правило 22 - Убирайте признаки, которые вы больше не используете.

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

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

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

Правило 23 - Вы не являетесь типичным конечным пользователем. *

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

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

Если вы действительно хотите иметь обратную связь с пользователем, используйте методики пользовательского опыта. Создайте пользовательские персонажи (в описании Билла Бакстона Designing Sketching User Experiences) в начале процесса и тестируйте на удобство использования (описание находится в статье Стива Края Don’t Make Me Think) позже. Пользовательские истории включают создание гипотетического пользователя. Например, если ваша команда полностью мужская, это может помочь разработать 35-летнюю женщину-пользователя (в комплекте с пользовательскими признаками(фичами))) и посмотреть результаты, которые она генерирует, а не 10 результатов для мужчин в возрасте 25-40 лет. Привлекайте реальных людей и наблюдайте за их реакцией на вашем сайте (локально или удаленно) при тестировании юзабилити. Это также даст вам свежий взгляд.

^{Google Research Blog - How to measure translation quality in your user interfaces}

Правило 24 - Измеряйте дельту между моделями

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

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

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

Правило 26 - Ищите закономерности в ошибках и создавайте новые признаки.

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

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

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

Некоторые члены вашей команды начнут разочаровыватся в свойствах системы, которые им не нравятся, которые не захватываются существующей функцией потерь. В этот момент они должны делать все возможное, чтобы превратить их "боль" в цифры. Например, если они думают, что слишком много «приложений для gag» отображаются в Play Search, они могут заставить людей оценивать приложения gag. (В этом случае вы можете использовать данные, размеченные человеком, потому что относительно небольшая часть запросов учитывает значительную часть трафика.) Если ваши проблемы измеримы, вы можете начать использовать их в качестве признаков, целей или показателей. Общее правило: “сначала измеряйте, потом оптимизируйте”.

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

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

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

Тренировочное-Рабочее отклонение(смещение)

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

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

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

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

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

Правило 30 - Не удаляйте "вес значимости" представленных данных!

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

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

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

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

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

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

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

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

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

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

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

^* Про Bias можно прочитать здесь

Правило 35 - Остерегайтесь перекоса(отклонения) свойственного задачам ранжирования.

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

1. Делайте сильную регуляризацию признаков, которые охватывают большое количество запросов, в отличие от тех признаков, которые работают только для одиночных запросов. Таким образом, модель будет поддерживать признаки, характерные для одного или нескольких запросов вместо признаков, которые затрагиваются все запросы. Такой подход может помочь предотвратить попадание очень популярных результатов в нерелевантные запросы. Обратите внимание, что это противоречит более традиционным советам относительно сильной регуляризации столбцов-признаков с более уникальными значениями.
2. Используйте признаки только с положительными весами. Таким образом, любой хороший признак будет лучше, чем "неизвестный" признак.
3. Не используйт только признаки на основе характеристик документов. Это крайний случай №1. Например, даже если данное приложение является часто скачиваемым независимо от запросов, вы же не будете показывать его везде ^{4</ sup>. Не имея только признаков на основе характеристик приложения(документа), это просто.}

^{4 - Причина, по которой вы не хотите показывать конкретное популярное приложение во всем мире, связана с важностью достижения всех желаемых приложений. Например, если кто-то ищет «приложение для наблюдения за птицами», они могут загружать «Angry Birds», но это, конечно же, не было их намерением. Отображение такого приложения может повысить скорость загрузки, но в конечном итоге не удовлетворяет потребности пользователя.}

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

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

Правило 37 - Измеряйте перекос между обучением/эксплуатацией.

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

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

Медленный рост, оптимизация, сложные модели.

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

Правило 38 - Не тратьте время на новые признаки, если проблемы с невыполнением обязательств стали проблемой.

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

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

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

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

Эксперимент	Ежедневно активных пользователей(DAU)	Доход в день
A	1 million	$4 million
B	2 million	$2 million

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

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

Правило 40 - Сохраняйте ансамбли простыми.

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

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

Правило 41 - Когда качество модели достигло некоторого уровня и выше не подымается, ищите качественно новые источники информации, а не улучшайте текущие признаки

Вы добавили демографическую информацию о пользователе. Вы добавили информацию о словах в документе. Вы провели исследование и настроили регуляризацию. Вы не видели запусков модели с более чем 1%-улучшением ваших показателей за несколько кварталов. Что теперь? Настало время начать создание инфраструктуры для радикально других признаков, таких как история докумнетов к которым пользователь обращался за последний день, неделю, год или данных с другими свойствами. Используйте wikidata сущности или другие, принятое в вашей компании (такой как Google’s knowledge graph). Используйте глубокое обучение. Начните корректировать свои ожидания относительно прибыли от инвестией и увеличте свои усилия. Как и в любом инженерном проекте, вы должны взвесить преимущества от добавляемых признаков против стоимости от увеличения сложности.

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

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

Обратите внимание: если ваша система измеряет клики, время, часы, + 1s, reshares и т. Д., Вы измеряете популярность контента. Команды иногда пытаются выучить личную модель с разнообразием. Чтобы персонализировать, они добавляют функции, которые позволят системе персонализировать (некоторые функции, представляющие интерес пользователя) или диверсифицировать (функции, указывающие, имеет ли этот документ какие-либо общие черты с другими возвращенными документами, такими как автор или контент) и обнаруживают, что эти функции получают меньше веса (или иногда другой знак), чем они ожидают. Это не означает, что разнообразие, персонализация или релевантность не являются ценными.* Как указано в предыдущем правиле, вы можете выполнять пост-обработку для увеличения разнообразия или релевантности. Если вы видите увеличение долгосрочных целей, вы можете заявить, что разнообразие / релевантность ценны, кроме популярности. Затем вы можете либо продолжать использовать свою пост-обработку, либо напрямую изменять цель, основанную на разнообразии или релевантности.

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

^{Google Research Blog - App Discovery With Google Play}

Правило 43 - Ваша аудитория, как правило, одинакова для разных продуктов.

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