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

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

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

Приступая к задачам классификации, мы должны договориться о том, что является положительным случаем ичто такоеотрицательным случаем. Это то, что можно легко определить с помощью вопроса «Есть ли X?». Если вы спросите о картинке и захотите узнать «Есть ли чихуахуа?» ваш положительный случай — «Да, чихуахуа есть», а отрицательный — «Нет, чихуахуа нет».

Матрица путаницы

Задачи классификации лучше всего можно описать с помощью матрицы путаницы. Матрица описывает четыре различные категории.

  • Истинно положительный результат: у нас был положительный случай, и мы правильно классифицировали положительный случай.
  • Истинно отрицательный результат: у нас был отрицательный случай, и мы правильно классифицировали его.
  • Ложноположительный — у нас был отрицательный случай, и мы ошибочно классифицировали его как положительный случай.
  • Ложноотрицательный — у нас был положительный случай, но мы ошибочно классифицировали его как отрицательный.

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

Нет правильного или неправильного ответа на вопрос, лучше ли иметь ложноположительные и ложноотрицательные результаты — все зависит от конкретного случая. Давайте посмотрим на некоторые примеры случаев.

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

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

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

Точность и отзыв

От путаницы, матрицы давайте перейдем к точности и отзыву, которые описывают, к какой метрике вы больше склоняетесь. Лучше всего, если модель имеет 100% точность и полноту, но такое случается редко.

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

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

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

Заключение

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