Построение автопилотов для инженерных систем с использованием ИИ

Мотивы и темы исследований

Совместная работа с командой Huawei Paris Noah’s Ark: Мерван Барлье, Игорь Колин, Людовик Дос Сантос, Габриэль Уртадо, Седрик Малерб и Альберт Томас.

К чему мы стремимся?

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

Мы сделаем системы лучше, дешевле, надежнее, безопаснее и энергоэффективнее.

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

Представление управления: системы и агенты

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

Цель обучения с подкреплением — подражать инженеру, что приводит к автопилоту.

Точнее, мы изучаем политику, которая сопоставляет наблюдаемую последовательность и последовательность вознаграждения с оптимизированными управляющими действиями, используя исторические системные журналы (трассировки) и/или взаимодействуя с системой.

Почему автономное/пакетное обучение с подкреплением (RL)?

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

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

Ниже показан цикл оффлайн RL, встроенный в типичный процесс управления проектами.

Процесс повторяет следующие шаги:

1. Системный инженер записывает след кортежа (действие, наблюдаемое, вознаграждение) (помимо выполнения своей работы по управлению системой).
2. Она отправляет набор данных специалисту по данным.
3. Он разрабатывает контроллер на основе собранных данных с целью улучшения системы (среднее вознаграждение).
4. Она применяет политику, снова регистрирует трассировку и отправляет ее специалисту по данным.

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

Почему микроданные RL?

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

RL на основе модели (MBRL), RL без модели (MFRL) и контекстные бандиты (CB)

Целью RL является изучение политики управления. Автономный MFRL делает это за один раз на собранном автономном наборе данных. В MBRL мы сначала изучаем модель среды, по сути, многовариантный предиктор временных рядов, предсказывающий эволюцию системы с учетом ее истории наблюдений и управляющих воздействий. Затем мы можем использовать эту модель, часто в форме симулятора, для изучения политики управления. Для обучения пилотов использовались авиасимуляторы. Идея здесь та же, за исключением того, что у нас нет физической модели, поэтому мы изучаем ее на основе данных.

У нас есть причины исследовать как безмодельные, так и основанные на моделях подходы.

Почему МФЛ?

1. MFRL, по-видимому, обеспечивает лучшие асимптотические характеристики.
2. MFRL лучше изучен, и существующие алгоритмы могут служить надежной основой.
3. Нам нужно планировать на основе модели, изученной в MBRL, а эти планировщики по сути являются алгоритмами MFRL.

Почему МБРЛ?

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

Почему контекстные бандиты?

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

Темы исследований

Модели динамических систем

Эта тема охватывает вопросы, связанные с моделями динамических систем, которые по сути являются многомерными предикторами временных рядов, изученными на трассировках не-iid и нестационарных систем.

1. Какие модели выбрать и на основании каких критериев?
   В этом сообщении в блоге (подводя итог этой статьи) мы сравним генеративные модели в строгой экспериментальной установке привязать агента планирования к случайной стрельбе и сравнить наиболее популярные генеративные модели с использованием двух динамических метрик, четырех метрик, оцениваемых на статических трассах, и семи требований, которые могут оказаться важными для практикующего специалиста по данным. Мы устанавливаем новый уровень сложности выборки в известной системе Acrobot и объявляем глубокие авторегрессионные сети плотности смеси (DARMDN) наиболее предпочтительной моделью для их способность моделировать многомерные и гетероскедастические апостериорные прогнозы, а также их надежность и гибкость для моделирования наблюдаемых гетерогенных систем.
2. В шумных системах рекомендуется разделять эпистемическую и алеаторную неопределенности. Можем ли мы это проверить? Каковы наилучшие подходы для этого и каковы экспериментальные рамки, в которых можно сравнивать различные подходы? Какую среду лучше всего использовать в экспериментах?
3. Гетероскедастичность во время обучения оказалась решающей в этой статье. Почему? Цель состоит в том, чтобы воспроизвести явление на минимально возможной игрушечной системе и изучить его как экспериментально, так и теоретически.
4. В шумных инженерных системах бывает так, что управляющее действие мало влияет на вознаграждение по сравнению с влиянием состояния или контекста. Изучение совместной модели иногда «затеняет» эффект действия, что вредно для изучения хорошего управляющего агента. Обнаружение этой (беспристрастной) чувствительности вознаграждения к действию в явном виде на этапе моделирования системы имеет решающее значение, что приводит к вопросам, аналогичным плану эксперимента, каузальному обучению и изучению эффектов лечения в здравоохранении.
5. В сложных системах построение сводки истории (контекста) может быть нетривиальной задачей. Использование предварительных знаний, полученных от системного инженера, — это одно направление, а использование нейронных архитектур типа внимания — другое.
6. В нашей установке мы должны изучить новые модели для каждого нового отзыва из реальной системы. Вместо того, чтобы делать это с нуля, может быть интересно использовать методы трансферного обучения, чтобы сделать процесс обучения более простым и плавным.
7. Одним из побочных эффектов изучения модели системы является то, что мы можем проверить поведение системы по модели. Если есть несоответствие, мы можем действовать, например, запуская действие по техническому обслуживанию или предупреждая системного инженера. Мы можем разработать как онлайн-проверки, "реакции страха" автопилота, так и автономные проверки данных, вставленные в медленную итерацию автономного RL.