Недавно я закончил читать книгу Чипа Хьюена Designing Machine Learning Systems, поэтому я хотел бы поделиться некоторыми знаниями, которые я получил, прочитав эту книгу.

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

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

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

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

Глава 3. Основы инженерии данных

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

  • Передача данных через постоянное хранилище — все хранится в постоянном хранилище, каждый из различных контейнеров/компонентов просто читает и записывает данные из базы данных.
  • Передача данных через службу — используйте инфраструктуру RESTful или RPC для создания интерфейсов API, позволяющих взаимодействовать различным контейнерам/компонентам.
  • Передача данных через транспорт в реальном времени. Используйте систему очередей сообщений или систему pub-sub, чтобы выступать в качестве посредника, который координирует передачу данных между различными контейнерами/компонентами. Промежуточное звено может быть либо основано на постоянном хранилище, либо частично основано на постоянном хранилище, либо вообще не связано с постоянным хранилищем.

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

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

Глава 6. Разработка модели и оценка в автономном режиме

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

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

Глава 7. Служба развертывания и прогнозирования моделей

В зависимости от потоков данных, а также типа данных, которые необходимо прогнозировать, могут быть:

  • Пакетное прогнозирование
  • Онлайн-прогнозирование, использующее только пакетную функцию
  • Онлайн-прогнозирование, в котором может использоваться функция потоковой передачи (также называемая прогнозированием потоковой передачи)

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

Унификация конвейера данных может быть нетривиальной задачей — об этом подробнее в главе 10.

Глава 8 — Сдвиг и мониторинг распределения данных

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

  • Отслеживайте метрики, связанные с точностью, если обратная связь с пользователем может быть немедленной. Это распространено в рекомендательных системах и сценариях активного обучения.
  • Отслеживайте распределение самого прогноза и проверяйте, есть ли сдвиг распределения прогнозируемых меток по сравнению с тестовыми метками.
  • Следите за распространением каждой из функций. Это может быть более общим, но хорошей отправной точкой будет минимальная/максимальная/медианная/гистограмма.
  • Контролируйте необработанный ввод. В книге утверждается, что это может выходить за рамки науки о данных или команды машинного обучения, но я думаю, что это больше зависит от того, как на самом деле сформулирована структура команды. В моей области обработки текста здесь также могут появиться интересные метрики: длина текста / язык распределения текста / токена в тексте могут быть метрикой для мониторинга. Они также могут использоваться в качестве функций и, таким образом, могут относиться к форме «функции мониторинга», но бывают ситуации, когда эти функции могут не сильно способствовать обучению модели нейронной сети на тексте, особенно в эту эпоху ChatGPT, но они могут по-прежнему будет полезно для группы мониторинга, чтобы определить, были ли данные сдвинуты, чтобы определить, может ли потребоваться тонкая настройка типа LoRA.

Глава 10. Инфраструктура и инструменты для MLOps

(Это моя любимая глава в книге. На самом деле, эта часть больше связана с Backend Software Engineer ^_^)

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

Рабочие процессы машинного обучения, которые по своей природе являются итеративными, могут управляться с помощью инструментов управления рабочими процессами, что значительно упростит запуск рабочего процесса и мониторинг его хода. Они также способствуют упрощению совместного использования контейнеров/компонентов, что полезно для унифицированного конвейера данных. В книге приведены примеры Apache Airflow, Argo и Metaflow. Я также недавно играл с некоторыми другими инструментами управления рабочим процессом, такими как Prefect и Temporal. Все они имеют свои плюсы и минусы. Лично я больше предпочитаю Temporal, так как он лучше масштабируется и справляется с сбоями, а также имеет больше возможностей для поддержки нескольких языков.

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

Книга также охватывала Featuer Store. Это новая концепция, которая фокусируется либо на управлении функциями, либо на вычислении функций, либо на поддержании согласованности функций при обучении и прогнозировании, либо на всех сразу. Это также тесно связано с предложением из главы 7 о построении унифицированного конвейера данных. Feast / Tecton — вот некоторые из примеров, которые были приведены в качестве инструмента хранилища функций, который можно изучить.

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

Глава 11. Человеческая сторона машинного обучения

Для MLOps требовались знания в области ML и Ops (сокращение от «Operation», обычно относящееся к знаниям внутренней или внутренней стороны). Компании либо имеют две команды для них, либо просят одну команду, чтобы она хорошо справлялась с обеими задачами. У обоих есть своя проблема: если отдельные команды имеют массу накладных расходов, у вас будет много накладных расходов, когда у вас будет более одной команды, и требование, чтобы одна команда обладала знаниями с обеих сторон, делает непрактичным требование, требующее, чтобы специалисты по данным понимали низкоуровневую инфраструктуру. Автор утверждает, что наилучший подход, вероятно, находится где-то посередине: хороший инструмент, созданный теми, кто имеет опыт эксплуатации, который абстрагирует концепцию эксплуатации от специалистов по данным, и с помощью этого инструмента специалисты по данным могут полностью владеть своей частью работы без особой необходимости. для связи с оперативной частью команды. Это, конечно, не устраняет всей сложности коммуникации, но, безусловно, если уровень абстракции сделан достаточно хорошо, это сделает совместную работу между командами намного более эффективной.

Как бывший выпускник UBC NLP Lab, который думал о том, чтобы стать Data Scientist, но каким-то образом в конце концов оказался старшим бэкенд-программистом, я чувствую, что в этом отношении я уникален. Но я согласен, что такие случаи, как мой, редки, и я чувствую, что мои действия с обеих сторон иногда приводят к тому, что я не совершенен ни в Infra, ни в ML. В любом случае, система машинного обучения сложна и, естественно, требует совместной работы. И, как предлагает автор, больше думать об упаковке и абстракции — лучший способ наладить сотрудничество между командами. Что же касается меня, живущего посередине, то это прекрасная возможность поразмыслить над тем, какой именно должна быть эта абстракция.