Авторы этой статьи выражают надежду, что эта статья предоставит некоторые практические советы разработчикам и специалистам по сопровождению систем машинного обучения в производственных средах. Авторы предупреждают, что, хотя создание системы машинного обучения с нуля довольно просто, последующие улучшения могут оказаться неожиданно сложными. При чтении этой статьи читатели ясно почувствуют, что опыт получен из с трудом нажитого автором накопления во время его пребывания в Google.
AI Frontier заставит вас перечитать эту классическую статью.Некоторый опыт в статье подчеркивает, что «имеющий отношение к машинному обучению не означает, что от хороших методов разработки программного обеспечения можно полностью отказаться», а часть содержания относится к распространенным ловушкам, характерным для машинное обучение. Учитывая потенциальные проблемы, с которыми сталкиваются все стартапы, стремящиеся построить бизнес «X+AI», представленные здесь рекомендации заслуживают серьезного рассмотрения.
Для получения дополнительных галантерейных товаров, пожалуйста, обратите внимание на публичный аккаунт WeChat «AI Frontline» (ID: ai-front)
К основным категориям технического долга, вызванного системами машинного обучения, упомянутыми в этой статье, относятся: сокрытие информации и проблемы сдерживания изменений, связующий код и конфигурация, а также меняющийся внешний мир и непонимание этого мира выводами аналитической модели.
Одним из наиболее важных выводов в этой статье является то, что технический долг должен вызывать беспокойство у инженеров и исследователей. Поиск решений за счет значительного увеличения сложности системы явно не является разумным подходом. Даже добавление всего одной или двух, казалось бы, безобидных зависимостей данных может замедлить дальнейшую разработку. Хотя сокращение технического долга не так увлекательно, как доказательство новых теорем, оно по-прежнему является важной движущей силой сильных инноваций. На самом деле разработка комплексных и элегантных решений для сложных систем машинного обучения — очень практическая задача.
... модель машинного обучения — это машина, которая создает сложные запутанные состояния, и невозможно эффективно разделить распределение ее улучшений. В качестве доказательства предположим, что E использует функции x1,...Xn в наборе моделей, тогда, если мы изменим входное распределение значений в x1, его важность, вес или оставшиеся функции могут измениться независимо от того, является ли модель пакетной. верно ли это полная переподготовка в виде полной переподготовки, или постепенная адаптация в онлайн моде. Добавление нового признака xn+1 или удаление любого признака xj также может привести к аналогичным изменениям. Ни один вход не является действительно независимым. Шеперд называет это принципом CACE: любое изменение меняет все.
Если мы понимаем важность априорных оценок, то нет необходимости в повторных доказательствах с машинным обучением! Таким образом, модель немного похожа на гигантскую взбивающую машину, в которую мы вбрасываем много информации и получаем результаты, но с непредсказуемой чувствительностью к различным изменениям на входе и малой изоляцией воздействия. Столкнувшись с такой проблемой, что нам делать? Хотя универсального решения не существует, авторы предлагают три стратегии, которые могут помочь.
Вы можете изолировать модель и вместо этого предоставить общие выводы. Однако проблема запутанности все еще существует в каждой модели. Кроме того, «в масштабе эту стратегию может быть трудно поддерживать в долгосрочной перспективе».
Разработайте методы, позволяющие получить представление о поведении, предсказанном моделью. Вам нужно вложить средства в то, чтобы сделать модель менее неуловимой, как черный ящик, например, снабдив ее дополнительными инструментами визуализации. Кроме того, я разговаривал с рядом компаний, некоторые из которых заявили, что их способность интерпретировать решения, принимаемые моделями машинного обучения — даже нормативные требования — является важной частью их бизнес-моделей. Поэтому, пожалуйста, серьезно обдумайте потребности и подходы к реализации в этом отношении.
Используйте более сложные методы регуляризации, чтобы целевая функция, используемая в обучении, отражала любые признаки роста затрат на прогнозирование производительности. «Этот подход может сработать, но это только возможно. Кроме того, он может увеличить сложность системы и привести к увеличению долга, что противоречит цели уменьшения запутанности».
Еще один способ найти случайную связь — создать скрытые петли обратной связи, особенно среди необъявленных потребителей. Не объявляя потребителя, система просто потребляет выходные данные моделирования, и мы едва ли осознаем существование этих процессов. Если он предпримет какое-либо действие на основе информации о входных параметрах, которая влияет на модель, эта скрытая петля обратной связи может легко привести к следующим проблемам:
Представьте себе, что в нашей системе прогнозирования CTR заголовков новостей компонент системы отвечает за «интеллектуальное» определение размера шрифта для заголовков. Если этот модуль размера шрифта начинает использовать рейтинг кликов в качестве входного сигнала, а размер шрифта действительно влияет на склонность пользователя к кликам, тогда размер шрифта будет содержать новую скрытую петлю обратной связи, добавленную рейтингом кликов. Вполне возможно, что такая система будет постепенно и бесконечно увеличивать все ситуации с размерами заголовков.
...Хотя зависимости кода могут быть относительно легко идентифицированы с помощью статического анализа, графиков связей и т. д., инструменты анализа с возможностями обработки зависимостей данных встречаются редко. Поэтому нам сложно создать решение, способное решать большие цепочки зависимостей данных.
Например, определенные входные сигналы могут со временем изменить поведение. Следуя принципам CACE, трудно предсказать последствия, даже если эти изменения воспринимаются как направления для улучшения. Еще одна зависимость от данных — это набор функций в модели, некоторые из которых обеспечивают очень ограниченное увеличение точности. Мы можем эксплуатировать недоиспользуемые зависимости несколькими способами, включая некоторые ранние устаревшие функции, которые устарели, несколько комбинаций функций, добавленных одновременно (вместо того, чтобы просто выбирать те, которые действительно работают), или функции, которые добавляются для достижения цели. точности и не могут продемонстрировать свое влияние на сложность. Будет очень важно очищать функции на регулярной основе.
Например, предположим, что после слияния команды был цикл преобразования со старого номера продукта на новый для простоты, тогда в системе будут представлены оба сценария. Среди них новые продукты могут получить только один новый номер, а старые продукты могут иметь два номера одновременно. Алгоритмы машинного обучения, конечно, также будут включать старые числа в зависимости. Год спустя некоторые менеджеры подчистили код базы данных, в котором были старые номера. Это изменение не будет обнаружено регрессионными тестами, поскольку после очистки старые числа больше не используются. Очевидно, это плохая новость для тех, кто занимается сопровождением систем машинного обучения...
Инструменты, способные понимать зависимости данных, помогут нам сгладить очистку функций. Команда Google создала автоматизированный инструмент управления функциями:
С момента своего внедрения программа помогла командам Google безопасно удалять тысячи строк кода, связанного с функциями, каждый квартал, автоматически проверяя версии и другие проблемы в них. Система также эффективно предотвращает случайное использование устаревших или неработающих функций в новых моделях.
Последний подход к управлению зависимостями данных заключается в создании механизмов «исправления» для повторного использования существующих моделей. Таким образом, вы сможете быстро получить первоначальные результаты, с другой стороны, вы столкнетесь с более высокими затратами на будущий анализ и улучшение модели.
Удивительно, но академические круги осознают, что в большинстве систем машинного обучения лишь небольшая часть кода на самом деле занимается «машинным обучением». На самом деле, в зрелой системе может оказаться не более 5% кода, отвечающего за машинное обучение, а оставшиеся 95% или более просто служат связующим звеном для улучшения громоздкого API путем повторной реализации (а не повторного использования). .
Проблема, которую необходимо решить здесь, заключается в том, что многие библиотеки машинного обучения упакованы в виде отдельных артефактов, что, несомненно, вводит много связующего кода (например, преобразование из Java в R или Matlab). Если вы не можете найти вариант ресурса, который подходит вам в более широкой системной архитектуре, то повторная реализация алгоритма (5% кода) может иметь больше смысла и эффективно сократить объем связующего кода.
Связанная с этим проблема — джунгли конвейеров — чрезмерно сложные конвейеры подготовки данных.
Проблемы джунглей конвейера можно избежать, только внимательно изучив сбор данных и извлечение признаков. Расчистка джунглей конвейера и разработка метода очистки с нуля действительно являются крупными инвестициями на инженерном уровне, но они также могут значительно сократить текущие расходы и ускорить дальнейшую инновационную деятельность.
Как только система станет жесткой из-за связующего кода и проблем с сантехническими джунглями, у многих друзей возникнет искушение скорректировать пути экспериментального кода в производственном коде для проведения дополнительных экспериментов. Это, конечно, удобнее, но как только частота будет слишком высокой, это вызовет только большую путаницу.
Как типичный пример, недавняя очистка Google из важной системы обучения машины обнаружила десятки тысяч неиспользуемых экспериментальных линий кода. Переписать, чтобы воспользоваться более жестким API, эта часть «наследия» может значительно снизить рабочую нагрузку, производственный риск и сложность системы управления, прокладки способа для экспериментов с новыми алгоритмами.
В конце этого раздела: «Конфигурация часто является средством, с помощью которого реальный хаос мешает прекрасным алгоритмам».
Рассмотрим следующий пример. В период с 14 сентября по 17 сентября в компоненте A произошла ошибка регистрации. Функция B официально не будет запущена до 7 октября. Из-за изменения формата записи код, используемый для расчета признака C, должен был внести изменения в данные до и после 1 ноября. Функция D не используется в производственной среде, поэтому при выполнении запросов к модели при настройке в реальном времени необходимо использовать альтернативы D' и D". Если используется функция Z, то все задачи, связанные с обучением, должны получить дополнительную квоту памяти, в противном случае эффективность обучения будет значительно сокращается. Наконец, из-за ограничений по задержке функция Q исключает функцию R. Все эти хаотические условия затрудняют правильное изменение конфигурации и трудность ее обоснования. Кроме того, ошибки конфигурации также могут привести к высоким вычислительные ресурсы или производственные проблемы.
Изменения конфигурации следует обрабатывать с такой же тщательностью и рецензированием, что и изменения кода.
Опыт показывает, что внешний мир редко бывает стабильным. На самом деле меняющаяся природа реального мира является значительным источником технического долга в машинном обучении.
Вместо ручной установки порогов принятия решений (например, показывать или не показывать рекламу) рассмотрите возможность оценки существующих данных проверки, чтобы обнаружить пороги. Кроме того, связанные функции с неизвестной причиной и следствием могут вызвать проблемы:
Это не кажется серьезной проблемой: если два признака всегда коррелированы, но только один из них принадлежит к истинной причинно-следственной связи, все же представляется возможным приписать обеим заслугам и сделать выводы, рассматривая их общее явление. Однако если бы симбиоз этих двух черт во внешнем мире вдруг исчез, то прогнозируемое поведение могло резко измениться. Комплексные стратегии машинного обучения для различения корреляционных эффектов также выходят за рамки нашего обсуждения; [Bottou 2013] дает несколько отличных советов и ссылок на этот счет. В сочетании с фокусом этой статьи мы отмечаем, что акаузальность является еще одним источником скрытого долга.
Наконец, крайне важна система мониторинга в реальном времени. В документе предлагается измерять погрешность прогноза и выдавать оповещения, когда количество действий, предпринятых системой, превышает определенный порог.
В системе, которая работает по назначению, распространение предсказанных меток обычно должно быть эквивалентно публикации наблюдаемых меток. Это не нужно полностью тестировать, так как это может быть удовлетворено одной нулевой моделью, то есть прямым прогнозированием среднего значения появления меток независимо от входных функций. Однако этот простой подход дает на удивление хорошие результаты, а изменения таких показателей часто отражают ключевые проблемы, требующие внимания…
Оригинальная ссылка:
https://blog.acolyer.org/2016/02/29/machine-learning-the-high-interest-credit-card-of-technical-debt/
Ссылка на бумагу:
https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43146.pdf