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

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

Пример запуска: юридический чат-бот самопомощи

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

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

Ставить цели

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

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

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

Цели на разных уровнях

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

Чтобы распутать разные цели, полезно задавать вопросы на разных уровнях и обсуждать, как разные цели соотносятся друг с другом. Мы находим классификацию целей Халтена полезной (и рекомендуем полное обсуждение в главе 4 Создание интеллектуальных систем):

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

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

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

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

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

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

Отношения между целями

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

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

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

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

Кратко об измерении

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

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

Все измеримо

В своей простейшей форме измерение — это просто присвоение чисел атрибутам объектов или событий по некоторому правилу. На практике мы проводим измерения, чтобы узнать что-то об объектах или событиях с намерением принять какое-то решение. Следовательно, Дуглас Хаббард определяет измерение как «количественно выраженное уменьшение неопределенности, основанное на одном или нескольких наблюдениях».

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

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

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

О терминологии. Qопределение обычно представляет собой процесс превращения наблюдений в числа — он лежит в основе всех измерений. Мера и метрика относятся к методу или стандартному формату измерения чего-либо, например, проценту ложноположительных предсказаний классификатора или количеству строк кода, написанных за один раз. неделя. Термины «мера» и «метрика» часто используются взаимозаменяемо, и в этой книге мы будем использовать только термин «мера», хотя авторы делают различия, например, метрики получаются из нескольких мер или метрики являются стандартизированными мерами. Наконец, эксплуатация относится к определению и внедрению метода измерения некоторого фактора, например, выявлению ложноположительных прогнозов из файлов журналов или выявлению измененных и добавленных строк для каждого разработчика из системы контроля версий.

Определение мер

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

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

  • Вместо точность измерения укажите точность измерения с помощью MAPE, которая относится к четко определенному существующему показателю (см. также главу Качество модели: измерение точности прогнозирования).
  • Вместо оценить качество тестирования укажите «измерить охват филиала с помощью Jacoco», который использует четко определенный существующий показатель и даже включает конкретный измерительный инструмент (инструмент), который будет использоваться. для измерения.
  • Вместо "измерить время выполнения" укажите "среднее и 90%-квантильное время отклика для REST-API чат-бота при нормальной нагрузке", которое описывает условия или экспериментальные протоколы при которой собрана мера.
  • Вместо «измерять удовлетворенность клиентов» укажите «сообщать о частоте ответов и среднем рейтинге клиентов по 5-балльной шкале оценок, показанных 10% всех клиентов после взаимодействия с чат-ботом для 10 сообщений (случайно выбранных )», который описывает воспроизводимую процедуру измерения.

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

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

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

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

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

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

Оценка качества меры

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

Точность и аккуратность. Полезным различием для рассуждений о любом процессе измерения является различие между точностью и точностью (не путать с полнотой и точностью в контексте оценки качества модели).

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

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

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

Визуализация разницы между точностью и точностью, показывающая, например, как несколько результатов могут быть очень близкими друг к другу (точными), но далекими от цели (неточными). CC-BY-4.0 от Arbeck.

При измерении нас обычно беспокоят как неточность, так и неточность (шум), и нам нужно решать эти проблемы совсем по-другому:

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

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

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

Ловушка: эффект уличного фонаря

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

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

Ловушка: меры, используемые в качестве стимулов

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

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

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

Краткое содержание

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

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

Дальнейшее чтение

Как и все главы, этот текст выпущен под лицензией Creative Commons 4.0 BY-SA.