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

Проблемы для AI²:

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

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

AI² Возможности:

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

Применение ML/AI в инфраструктуре данных:

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

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

Горячее/теплое/холодное сегментирование. Чтобы минимизировать затраты на хранение, часто используемые данные хранятся на дисках с малой задержкой и наоборот. Однако критерии для определения горячих, теплых или холодных данных часто основаны на давности данных. Например, можно придумать правило, которое классифицирует и, таким образом, помещает данные за последнюю неделю в «горячее» хранилище, от последней недели до последнего квартала — в «горячее» хранилище, а любые более старые данные — в «холодное» хранилище. Однако не все данные используются одинаково, и приведенное выше общее правило не является оптимальным решением. Используя журналы доступа и SQL-запросы, можно быстро определить шаблоны использования и построить прогнозную модель для определения использования различных продуктов данных с течением времени. Использование такой модели может помочь двумя способами. Во-первых, это может привести к большей экономии за счет уменьшения объема данных, которые необходимо хранить в горячей системе хранения. Во-вторых, это может повысить производительность многих запросов, которые требуют более длинного диапазона данных и, следовательно, должны постоянно извлекать данные из медленных «горячих» или «холодных» систем хранения.

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

Применение ML/AI в инфраструктуре:

Поэтапное развертывание. CI/CD (непрерывная интеграция и непрерывное развертывание) — это новая мантра во многих компаниях. Однако это создает проблему для инженеров по надежности сайта. В идеале вы хотите обнаружить плохое развертывание до того, как оно будет развернуто, и, следовательно, у вас есть тонны модульных/интеграционных тестов. Тем не менее, не все ошибки могут быть обнаружены при модульном/интеграционном тестировании, поэтому у вас есть информационные панели, которые инженеры часто отслеживают, внедряя улучшения. В Uber мы изучили различные показатели, которые инженеры часто используют в качестве раннего индикатора для выявления проблем с развертыванием. После этого мы использовали наш поэтапный механизм развертывания для автоматического обнаружения снижения качества обслуживания. Было интересно, что пример использования t-теста на существующей инфраструктуре теперь экономит инженерам тысячи долларов на инженерной производительности.

Определение типа машины. При выборе машины инженер должен учитывать несколько параметров: ЦП, память, пропускная способность сети, ГП, ОЗУ и т. д. Почему бы не позволить науке о данных принимать решения и оптимизировать их с течением времени? . Инженер может предоставить начальные рекомендации (или, в терминах науки о данных, априорную вероятность), но на основе схемы использования вышеуказанного параметра может быть построена интеллектуальная система для оптимизации выбора правильного типа машины для данной услуги.

Когда начать:

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

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

Есть еще много вещей, которые должны появиться, но это может быть темой для другого раза.

Первоначально опубликовано на http://ragrawal.wordpress.com 1 июня 2020 г.