13 сентября 2016 в 09:48

Как мы искали компромисс между точностью и полнотой в конкретной задаче ML



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

Мы в HeadHunter используем машинное обучение для создания пользовательских сервисов. ML — это «модно, стильно, молодежно…», но, в конце концов, это лишь один из возможных инструментов решения бизнес-задач, и этим инструментом нужно правильно пользоваться.

Постановка задачи


Если предельно упрощать, то разработка сервиса — это инвестиции денег компании. А разработанный сервис должен приносить прибыль (возможно, косвенно — например, увеличивая лояльность пользователей). Разработчики же моделей машинного обучения, как вы понимаете, оценивают качество своей работы несколько в других терминах (например, accuracy, ROC-AUC и так далее). Соответственно, нужно каким-то образом переводить требования бизнеса, например, в требования к качеству моделей. Это позволяет в том числе не увлекаться улучшением модели там, где «не надо». То есть с точки зрения бухгалтерии — меньше инвестировать, а с точки зрения разработки продукта — делать то, что действительно полезно пользователям. На одной конкретной задаче я расскажу о том, как довольно простым образом мы устанавливали требования к качеству модели.

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

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

График точность vs полнота выглядит традиционным образом

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

Хорошая или плохая модель получилась? Нужно ли ее улучшать? А если не нужно, то какой порог (threshold), то есть какую точку на кривой выбрать: какой компромисс между точностью и полнотой устраивает бизнес? Сначала я отвечал на этот вопрос довольно туманными построениями в духе «хотим 98% точности, а 40% полноты — казалось бы, вполне неплохо». Обоснование для подобных «продуктовых требований», конечно, существовало, но настолько зыбкое, что недостойно помещения в печать. И первая версия модели вышла именно в таком виде.

Эксперимент с асессорами


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

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

Итак, для каждого резюме мы собрали 4 независимых решения модераторов (0 или 1), решение модели (вещественное число от 0 до 1) и исходное решение одного из этих четверых модераторов (опять же 0 или 1). Первое, что можно сделать — посчитать среднюю «самосогласованность» решений модераторов (она получилась около 90%). Дальше можно более точно оценить «качество» резюме (оценку «опубликовать» или «не публиковать»), например, методом мнения большинства (majority vote). Наши предположения следующие: у нас есть «исходная оценка модератора» и «исходная оценка робота» плюс три оценки независимых модераторов. По трем оценкам всегда будет существовать мнение большинства (если бы оценок было четыре, то при голосовании 2:2 можно было бы выбирать решение случайным образом). В результате мы можем оценить точность «среднего модератора» — она опять же оказывается около 90%. Наносим точку на нашу кривую и видим, что модель обеспечит такую же ожидаемую точность при полноте более 80% (в итоге мы стали автоматически обрабатывать в 2 раза больше резюме при минимальных затратах).

Старая и новые точки на кривой

Выводы и спойлер


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

И в заключение хотел бы выразить свою признательность Роману Поборчему p0b0rchy за консультации нашей команды в ходе работы.

Что почитать:


Автор: @lleo
Похожие публикации

Комментарии (10)

  • +1
    Классный кейс.
    Здравая оценка реальных требований, как делать не «абстрактно идеально», а «максимально полезно».
  • 0
    Вы не могли бы подробнее рассказать, как именно считали «среднюю «самосогласованность» решений модераторов»?
    • +1
      1. у нас было i=1,2,3,4 модератора в эксперименте
      2. выборка на стенде состояла из четырех равных подвыборок r_i (i=1...4) длиной N, для каждой из которых мы знали исходные оценки i-го модератора.
      то есть для 0...(N-1) элемента у нас была исходная оценка первого модератора, для N...2*N-1 элемента — исходная оценка второго модератора, и так далее
      3. так как на стенде каждый человек размечал всю выбору целиком, для каждой четверти выборки у нас было две оценки от одного и того же человека — исходная и собранная в ходе эксперимента
      итого, для каждого модератора самосогласованность = доля совпавших оценок по его подвыборке (для каждой. а дальше, так как размеры выборок равны, то нестрашно брать среднее арифметическое. тем более у нас они получились похожи — все попали в диапазон 0.88-0.92.

      ну или более формально, но менее читаемо:
      4. обозначим за x_ij = {0,1} — оценку i-го модератора для j-го элемента выборки (общей длиной 4N), полученную в ходе эксперимента
      5. по каждому модератору мы знали его исходные оценки m_ij = {0,1} на «его же» подвыборке и можно было посчитать самосогласованность s_i=sum[x_ij for j in range(i*N, (i+1)*N)] / sum[m_ij for j in range(0, 4*N)]
      • 0
        сорри, но вот только в формуле в пятом пункте я перемудрил, правильно очевидно так: sum[x_ij == m_ij for j in range(i*N, (i+1)*N)] / N
        • 0
          Да, конечно, так проще. Работает только для бинарной оценки.
      • 0
        Спасибо, понял.
        То есть, считали самосогласованность на разных подвыборках, но не исследовали групповую согласованность всех четверых модераторов на всей выборке (я, как раз, надеялся подглядеть, как непараметрическую статистику умные люди используют, причем именно в случае оценок, а не ранжирования).
        • 0
          мы ее конечно исследовали, но в силу своих скромных способностей.
          оказалось, можно много интересно понять, если внимательно посмотреть табличку (в процентах):
          4 ответа «да»
          4 ответа «нет»
          3 ответа «да» + 1 ответ «нет»
          2 ответа «да» + 2 ответа «нет»
          1 ответ «да» + 3 ответа «нет»

          ну вообще Вас, вероятно, интересует, а как вычислить доверительный интервал для полученной оценки эмпирической точности (это, по сути, и есть «самосогласованность»). Про это стоит написать отдельно, если кто-нибудь из нас возьмется. Но вообще в таких случаях рекомендуется использовать бутстреп, что мы и сделали, а правильно его применить нам как раз и помог Роман Поборчий
  • 0
    Объясните пожалуйста ещё раз, что у вас такое такое «полнота» и «точность». Лучше в терминах вероятностей. Статье не хватает математики.
    Я так понял, что есть два алгоритма. Первый отбирает резюме, с которыми в принципе готов работать, и его эффективность есть «полнота». Второй алгоритм непосредственно обрабатывает и выставляет оценку, его характеризует «точность».
    • 0
      Модель одна, а формулы есть по осям графиков. В качестве первого шага можно почитать википедию, там очень понятная табличка.
    • +3
      Точность — доля настоящих правильных резюме среди всех выделенных машиной. То есть: верно выделенные / (верно-выделенные + ошибочно засчитанные как правильные). Или: precision = TruePositive / (TruePositive + FalsePositive)

      Полнота — доля правильно выделенных резюме среди всех правильных в выборке. То есть: верно выделенные / (верно выделенные + ошибочно отброшенные правильные). Или: recall = TruePositive / (TruePositive + FalseNegative).

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

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

Самое читаемое Разработка