Алгоритм регуляризации, описанный в «Вариационное авторегуляризованное выравнивание для Sim-to-Real Control»:

  1. Имитация входных данных
  2. Обучите декодер VAE на смоделированных входных данных
  3. Обучите кодер VAE с предварительно обученным декодером на реальных входных данных
  4. Возьмите обновленные параметры симуляции из энкодера и повторите с шага 1.

Этот алгоритм аналогичен процессу инженерного проектирования с упором на простоту:

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

В Дизайн API-интерфейса бампера Джошуа Блох также указал на эти шаги:

При разработке API сначала соберите требования — со здоровой долей скептицизма.

Структурные требования как варианты использования.

Держите API свободными от деталей реализации.

Учитывайте последствия решений по проектированию API для производительности, но не искажайте API для повышения производительности.

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

Эта аналогия пришла мне в голову, когда я подумал о Принципе вычислительной эквивалентности.

Этот пост изначально был опубликован на Substack.