«Не все долги плохие, но невыплаченные долги складываются».
Это особенно верно в контексте разработки программного обеспечения. Технический долг в контексте разработки программного обеспечения относится к структуре, которая помогает учитывать долгосрочные затраты на быстрое продвижение. В этой статье мы будем изучать технический долг в контексте машинного обучения (ML).
Известно, что машинное обучение обладает особой способностью увеличивать технический долг сверх долга, уже представленного традиционной разработкой программного обеспечения. Мы рассмотрим 3 основных источника технического долга в машинном обучении, каждый из которых объясним возможным решением.
Скрытый цикл обратной связи
Возможности машинного обучения часто являются частью более крупного программного обеспечения. Это означает, что система машинного обучения интегрирована сложным образом, чтобы получить некоторый ввод от основного программного обеспечения, запустить его через модель и вернуть прогноз программному обеспечению.
Например, возьмем рекомендательную систему на популярном сайте электронной коммерции (кхе*кх* Амазон). Вы никогда не задумывались, почему такие сайты рекомендуют вещи, о покупке которых вы даже не думали? Ну, это может быть проблема технического долга. Команда машинного обучения могла бы внедрить современную рекомендательную систему, которая рекомендует товары, тесно связанные с историей покупок, а также новые товары, которые могут заинтересовать клиентов.
Однако из-за «деловые интересы» компании, эффективность рекомендательной системы может быть снижена. Команда внешнего интерфейса может просто заблокировать рекомендуемые элементы, вероятность которых меньше 50%, поскольку эти элементы могут не представлять интереса для клиентов. Постепенно те элементы с вероятностью чуть выше 50% теперь будут рекомендоваться с вероятностью менее 50%. Это знаменует собой начало порочного круга. Система начинает рекомендовать те же товары, которые клиент уже купил, что противоречит цели системы рекомендаций.
Несмотря на то, что компания смогла получить большую прибыль в течение нескольких месяцев с помощью этой настройки внешнего интерфейса, основанной на искаженной активности клиентов, которую эта настройка стимулировала, модель машинного обучения уступила ложным обучающим данным, которые она получала. Это, в свою очередь, может привести к стагнации или даже снижению темпов продаж через несколько месяцев.
Возможный способ обойти эту проблему — установить прочные связи между различными командами разработчиков, работающими над системой рекомендаций. Важно, чтобы каждая команда сосредоточилась не на повышении своих собственных показателей производительности (например, оценка точности тестирования для команды машинного обучения), а на том, как они могут беспрепятственно сотрудничать для улучшения продаж в долгосрочной перспективе, что является конечной целью.
Ухудшение данных
Модели ML могут получать входные данные, которые уже были выведены другими моделями ML. Отсутствие качества данных может привести к нестабильности входных данных для моделей ML и ухудшению поведения данных по мере их продвижения по конвейеру. Например, вложения (например, Word2vec) точек данных могут использоваться в качестве входных данных для системы машинного обучения. Масштабы этой проблемы аналогичны эффекту домино.
Возможным решением является сохранение 2 копий данных после каждого этапа в конвейере данных. Таким образом, мы могли бы использовать избыточность для обеспечения качества данных и анализа стадии, на которой данные ухудшаются в поведении.
Необъявленные потребители в конвейере
И последнее, но не менее важное: для дальнейшего решения проблемы ухудшения данных в конвейере серия конвейеров, созданных разными командами разработчиков на разных уровнях иерархии, может привести к еще большему беспорядку. Конвейер может быть собран вместе, чтобы удовлетворить определенные требования на данный момент, без видения в долгосрочной перспективе. Эти сложные конвейеры могут привести к необъявленным потребителям, которые не имеют контроля доступа к другим связанным частям конвейеров. Необъявленные потребители потребляют выходные данные модели без возможности опроса. Такие потребители могут привести к дополнительным петлям обратной связи, которые могут привести к совершенно бесполезным прогнозам в последующих моделях машинного обучения конвейера.
Предоставление различным группам разработчиков программного обеспечения возможности получить четкое представление обо всем конвейере могло бы в значительной степени решить эту проблему. Важно регулярно проводить работы по укреплению трубопровода и устранению лазеек, чтобы обеспечить его эффективную и экономичную работу.
Подведение итогов
Как вы, возможно, заметили, основной причиной технического долга в машинном обучении является отсутствие общения и понимания. Сбор вещей для предстоящих важных встреч не поможет погасить технический долг. Вот несколько вещей, которые можно сделать для поощрения культуры выплаты долгов в вашей команде разработчиков:
• Согласование набора показателей производительности для системы, которую создает команда, и обеспечение ее соответствия бизнес-целям
• Обеспечение того, чтобы каждый член команды понимал весь конвейер, даже если он/она не работает. на нем напрямую
• Поощрение постоянного общения между различными командами разработчиков посредством регулярных личных встреч.
Я хотел бы закончить цитатой популярного спикера по разработке программного обеспечения Джима Маккарти, которая, я надеюсь, донесет до меня суть:
«У вас не может быть отличного программного обеспечения без отличной команды, а большинство команд разработчиков ведут себя как неблагополучные семьи».
Я хотел бы поблагодарить следующие источники, которые вдохновили меня на написание этой статьи:
- Доклад Д. Скалли Машинное обучение, технический долг и вы на PAPIs.io
https://www.youtube.com/watch?v=V18AsBIHlWs - И его статья: Машинное обучение: высокопроцентная кредитная карта технического долга
https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43146.pdf
Эта статья является кросс-постом моей оригинальной статьи на dev.to.
