эвристики в машинном обучении

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

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

Что? Начинать без машинного обучения?

Об этом говорю не только я.

Догадайтесь, какое правило является первым в 43 правилах машинного обучения Google?

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

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

Множество практиков машинного обучения, с которыми я проводил интервью в рамках проекта Applying ML, в ответ на этот вопрос тоже дают похожие ответы: «Представьте, что вам дали новую незнакомую задачу, которую нужно решить при помощи машинного обучения. Как вы подойдёте к её решению?»

«Для начала я приложу серьёзные усилия к тому, чтобы проверить, можно ли решить её без машинного обучения. Я всегда стремлюсь пробовать менее гламурные, простые вещи, прежде чем переходить к более сложным решениям». — Вики Бойкис, инженер ML в Tumblr

«Я думаю, что сначала важно выполнить задачу без ML. Решить задачу вручную или при помощи эвристик. Это заставит вас глубоко освоить задачу и данные, что является самым важным первым шагом. Более того, стоит получить точку отсчёта без ML, чтобы честно сравнивать показатели». — Хамел Хуссейн, ведущий инженер ML в Github

«Сначала попробуйте решить задачу без машинного обучения. Этот совет дают все, потому что он хорош. Можно написать несколько правил или эвристик if/else, чтобы принимать простые решения и действовать на их основе». — Адам Лаиакано, ведущий инженер платформы ML в Spotify

Тогда с чего начинать?

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

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

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

Точечная диаграмма непостоянной связи между температурой и продажами мороженого (источник)

Я выяснил, что если какая-то из переменных является категорийной, то хорошо подходят диаграммы типа «ящик с усами». Допустим, вы пытаетесь спрогнозировать срок жизни собаки — насколько важен её размер для этого параметра?

Ящик с усами срока жизни разных размеров пород собак (источник)

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

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

«Много лет назад у нас был похожий опыт. После блокирования скаммеры быстро создавали новые веб-сайты и ускальзывали от моделей, но продолжали использовать одни и те же изображения с одинаковыми именами файлов. Попались!». Джек Хэнлон (@JHanlon)

А вот ещё один пример, в котором регулярные выражения оказались лучше глубокого обучения.

«Меня за это так много критиковали. В одном проекте, над которым я работал, выполнялось сравнение строк, но заказчик был разочарован тем, что я не использовал нейросети, и нанял для этого кого-то другого. Угадайте, какой способ оказался точнее и дешевле?», — Митч Хейл (@bwahacker)

Эти эвристики также помогают с бутстреппингом разметки (weak supervision). Если вы начинаете с нуля и у вас нет разметки, weak supervision позволяет быстро и эффективно получить множество меток, хоть и низкого качества. Эти эвристики можно формализовать как функции разметки для генерирования меток. Другими примерами weak supervision являются использование баз знаний и заранее обученных моделей. Подробнее о weak supervision в Google и Apple можно прочитать здесь.

Когда же нужно использовать машинное обучение?

После того, как у вас появится точка отсчёта без ML с достаточно хорошими показателями, и объём усилий по поддержке и совершенствованию этой точки отсчёта перевешивает объём усилий по созданию и развёртыванию системы на основе ML. Сложно конкретно указать, когда это случается, но когда становится невозможно изменять ваши 195 созданных вручную правил без того, чтобы что-то не сломалось, то стоит задуматься о машинном обучении. Вот правило №3 из Правил ML компании Google.

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

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

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

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

Часто для получения «золотого стандарта» набора данных с высококачественными метками требуется разметка вручную. При его наличии обучение и валидация работ по машинному обучению становятся намного проще.

Но что если мне нужно использовать ML ради самого ML?

Хм, тогда вы находитесь в сложном положении. Как обеспечить равновесие между решением задачи (удовлетворением требований заказчика) и тратой кучи времени и усилий просто ради самого ML? У меня нет ответа на этот вопрос, но я процитирую гениальный совет Брэндона Рорера.

«Совет по стратегии работы с ML

Когда у вас есть задача, создайте два решения — байесовский трансформер с глубоким обучением, работающий в многооблачном (multicloud) Kubernetes и SQL-запрос, построенный на основе стека чрезвычайно упрощающих допущений. Одно решение запишите в своё резюме, второе используйте в продакшене. И все будут довольны». — Брэндон Рорер (@_brohrer_)

Источник

Эвристики в машинном обучении

Google’s 43 Rules of Machine Learning

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ML этап II: Feature Engineering

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

About

Перевод руководства Мартина Зинкевича «Правила машинного обучения»

Источник