Взгляд с высоты птичьего полета на проблему машинного обучения

Как ответственно реализовать успешный проект машинного обучения

Пятнадцать заповедей для облегчения эффективной и действенной коммуникации в цепочке создания ценности ИИ

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

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

Тем не менее, при подготовке этой статьи не было написано ни одной строчки кода. Уходите, кодеры! Добро пожаловать, мыслители!

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

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

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

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

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

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

Помните, процесс-тема-вопрос (и активность, но об этом в другом рассказе). Вот так.

Постановка проблемы и понимание

Мотивация

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

Проблема

Какую КОНКРЕТНУЮ проблему нам нужно решить? Здесь язык формальной логики предпочтительнее договорного. Лучший разговор о проблеме, как правило, открытый, свободный от любых предубеждений и предположений, и он приводит к краткому, ясному и недвусмысленному изложению проблемы, которую нам нужно решить вместе.

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

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

Каковы индикаторы/показатели/цели успешного решения проблемы? Что делает нашу проблему решенной? Это сэкономленное время, улучшенная точность, какой-то показатель, связанный с качеством продукта? Какие метрики мы можем ввести для измерения выбранного показателя? Например, для точности автоматической классификации это просто процент правильных догадок или, может быть, точность или чувствительность, оценка F1, ROC AUC? Что касается точности прогноза, будем ли мы использовать среднюю абсолютную ошибку, среднеквадратичную ошибку, среднюю процентную абсолютную ошибку?

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

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

Состояние игры

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

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

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

Влияние

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

Например, что вы делаете с прогнозом, согласно которому на следующей неделе вы собираетесь продать 11 велосипедов? Вы их производите или покупаете, где храните; что произойдет, если окажется, что вы продали только 7; или что произойдет, если вы продали 22 (у вас, возможно, нет в наличии)?

Цели наших показателей могут измениться, как только мы это узнаем. Нужно ли нам давать объяснения прогнозам модели (потому что они нужны клиенту)? Да, ИИ тоже может это делать (погуглите XAI).

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

Сбор и обработка данных

Источники данных и качество

Есть ли существующие данные? У клиента уже есть данные? Как клиент получил эти данные?

Каково качество доступных данных? Кто и в каком процессе аннотировал данные (метки/значения выходных признаков) и с какой степенью достоверности? Содержат ли значения выходных признаков абсолютную истину? Как собирались другие данные, можем ли мы предположить, что значения входных признаков содержат ошибки? В случае проблем с классификацией, сколько меток у нас есть для классификации? Если слишком много, можем ли мы как-то уменьшить/обобщить? Насколько несбалансировано распределение меток/функций вывода? Есть ли недостающие области данных; существуют ли значительные выбросы и каковы первоначальные решения по их устранению?

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

Например, модель может хорошо работать для одних демографических групп, но не так хорошо для других.

Эти ожидания должны использоваться в качестве базовых показателей для целевых показателей/показателей.

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

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

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

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

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

Разработка функций

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

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

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

Схема процесса сбора данных

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

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

Повторное использование веб-данных — разбор и добыча

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

Разрешается ли утилизация и при каких условиях? Несмотря на мотивацию Тима Бернерса-Ли к созданию WWW, веб-контент, хотя и доступен, в соответствии с текущей правовой практикой не является открытыми данными, и его нельзя использовать бесплатно по умолчанию, особенно если его собирают боты. Боты могут мешать работе веб-сайтов; повторное использование данных может привести к денежному ущербу для владельца данных. Перед очисткой веб-сайтов следует тщательно изучить этот вопрос. Каковы условия обслуживания сайта? Является ли удаление сайта добросовестным использованием? Что говорит законодательство страны? Можем ли мы получить разрешение владельца веб-сайта на очистку или просто использование данных для наших целей? Используются ли удаленные данные для обучения модели — воспроизведение/повторное использование данных?

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

Интеграция данных

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

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

Конвейер разработки модели

Исследовательский анализ данных

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

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

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

Есть ли недостающие данные и как их вменить? Отсутствующие данные — это правило, а не исключение. Это происходит по ряду различных причин, таких как неисправность датчиков, потеря данных на каком-то переходном этапе внедрения корпоративной информационной системы, интеграция данных из разных источников и т. д. Стратегии вменения новых данных на место отсутствующих различны. и зависят они от причины, региона, в котором отсутствуют данные, конкретной функции, которая их хранит. Отсутствующие данные можно аппроксимировать, их можно предсказать/прогнозировать и, в крайнем случае, их можно удалить.

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

Как выбрать наиболее релевантные данные для тестирования? В какой-то момент нам нужно решить, какие данные использовать для обучения и проверки, а какие для тестирования. Алгоритм обучения не должен «видеть» тестовые данные, если мы не хотим, чтобы наша модель была предвзятой и слишком подходящей. Распределение покрытия тестовых данных (входные и выходные функции, оба) должно быть идентичным или подобным распределению обучающих данных (стратифицированное разделение). Хотя существуют «правила» для разделения поезд-тест (например, «печально известное» соотношение 70:30%), вы не можете применять их, не задумываясь о репрезентативности.

Например, для прогнозирования временных рядов для тестирования должен использоваться как минимум один период сезонных колебаний, а это означает, что если у вас есть данные только за два года, вам ДОЛЖЕН использоваться 50% (один год) данных для тестирования.

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

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

Нормализация данных

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

Эксперимент

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

Где провести эксперимент? Для очень простых (или упрощенных) моделей вполне подойдут персональные компьютеры и ноутбуки. GPU абсолютно необходим, если конвейер машинного обучения включает в себя нейронные сети. Хорошей альтернативой мощному ноутбуку является Google Collab, предлагающий бесплатное использование GPU или TPU (Tensor Processing Unit, так называемый AI-ускоритель). В настоящее время лучшим решением для облачных проектов машинного обучения является AWS Machine Learning. Хорошо спланированный эксперимент по машинному обучению имеет решающее значение для реалистичной оценки затрат, необходимых для эффективной разработки моделей на платформе AWS.

Какие исходные алгоритмы следует включить в эксперимент? Выбор между глубокими и поверхностными методами зависит от самой проблемы. Уже существуют специализированные архитектуры для конкретных групп задач. Проблемы классификации изображений и обнаружения объектов сегодня обычно решаются с помощью глубоких сверточных нейронных сетей (CNN). Долгосрочное прогнозирование временных рядов и другие последовательные проблемы (такие как распознавание активности) следует сначала тестировать с помощью рекуррентных нейронных сетей, таких как LSTM, но иногда (особенно для скользящих прогнозов) гораздо более простых моделей (таких как Prophet или даже ARIMA) все будет хорошо. Для классификации тем в НЛП искусственные нейронные сети являются отличным инструментом, но машина опорных векторов (SVM), превосходно работающая с разреженными векторами, часто встречающимися в НЛП, будет работать исключительно хорошо, а может быть, даже лучше (зависит от многих факторов), чем ИНС. В общем, для задач, не связанных с изображениями, глубокие нейронные сети постоянно совершенствуются по мере добавления новых данных, в то время как неглубокие методы в какой-то момент имеют тенденцию выходить на плато и сходятся к некоторой точности. Для некоторых более простых задач самые простые методы, такие как логистическая регрессия и линейная регрессия (особенно с полиномиальным расширением), удивят вас отличной производительностью.

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

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

Как оптимизировать модель? Оптимизация является неотъемлемой частью конвейера машинного обучения, поскольку ее эффект может меняться в зависимости от выбора алгоритма, стратегий предварительной обработки данных и других шагов. Значительного улучшения обозначенных показателей можно добиться, выбрав правильный набор значений гиперпараметров в конкретных обстоятельствах. Как правило, оптимизация — это самая затратная по времени и ЦП деятельность в конвейере машинного обучения. Тем не менее, ответы на некоторые первоначальные вопросы могут значительно снизить эту стоимость. Какие гиперпараметры с наибольшей вероятностью повлияют на улучшение метрик? В каких областях следует искать оптимальные значения гиперпараметров? Какой метод оптимизации является наиболее эффективным/эффективным?

Развертывание и отчетность

Анализ требований

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

Каковы нефункциональные требования? Каковы требования к производительности/безопасности/конфиденциальности? Каковы требования к UI/UX? Существуют ли какие-либо национальные, отраслевые или корпоративные стандарты, которые необходимо учитывать, и как они влияют на процессы внедрения?

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

Внедрение и тестирование

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

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

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

Составление отчетов

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