В рамках курса Стэнфордского университета AA228V по валидации систем, критически важных для безопасности, финальная лекция была посвящена методам мониторинга во время выполнения (Runtime Monitoring). В то время как офлайн-валидация полагается на модели, которые неизбежно ограничены в своей способности предсказать все нюансы реальности, мониторинг в реальном времени служит последним рубежом защиты, позволяя системе распознавать ситуации, к которым она не была готова.
🛠️ Переход к Runtime Monitoring: когда офлайн-методы бессильны 0:05
До завершающего этапа курса студенты изучали методы, которые можно назвать «офлайн-валидацией»: оценку вероятности отказов, формальные гарантии и объяснимость моделей. Все они базируются на математических моделях мира. Однако, как отмечает лектор, моделирование сложных сред, таких как городские дороги для беспилотных автомобилей, — задача практически невыполнимая до конца .
В качестве примеров «краевых случаев» (edge cases), которые крайне сложно предусмотреть в модели, были приведены :
- Whimo и фонтан: беспилотник Waymo сталкивается с прорывом гидранта, когда вода бьет столбом прямо посреди дороги.
- Tesla и грузовик со светофорами: автомобиль Tesla следует за грузовиком, перевозящим светофоры, и пытается реагировать на каждый из них, постоянно меняя режим движения .
Основная цель мониторинга во время выполнения — зафиксировать опасную или неизвестную ситуацию и активировать механизм отката (fallback mechanism). Это может быть переход в безопасный режим, немедленная остановка или передача управления оператору-человеку . По мнению лектора, цитирующего Дугласа Адамса, если «42» — это ответ на вопрос о жизни и вселенной, то «мониторинг во время выполнения» — это ответ на вопрос о безопасном развертывании систем в реальном мире .
🌐 Мониторинг области операционного проектирования (ODD) 5:14
Системы проектируются для работы в определенных условиях, называемых Operational Design Domain (ODD). Если система выходит за пределы ODD (например, беспилотник для дневной езды оказывается на дороге ночью), результаты предварительной валидации перестают быть актуальными .
Существует два основных подхода к определению границ ODD:
- Ручной дизайн признаков: Инженеры сами прописывают условия (например, отсутствие облачности, отсутствие бликов, конкретная рулежная дорожка для самолета) .
- Подход на основе данных (Data-driven): Область определяется набором данных, которые использовались при офлайн-валидации. Если текущее состояние системы «похоже» на данные из валидационного набора, считается, что мы находимся внутри ODD .
Метод ближайших соседей и его ограничения
Самый простой алгоритм — считать точку принадлежащей к ODD, если её ближайший сосед в обучающей выборке находится в пределах заданного порога расстояния . Однако у этого метода есть существенные недостатки :
- Потребление памяти: Необходимо хранить весь огромный набор данных на борту системы.
- Вычислительная сложность: Поиск ближайшего соседа в многомерном пространстве требует значительных ресурсов.
- Проблема размерности: В пространствах высокой размерности (например, пиксели изображений) метрики расстояния теряют физический и семантический смысл .
В качестве альтернативы предлагается использовать кластеризацию и хранить только центры кластеров или строить выпуклые оболочки данных (политопы). С юмором упоминается «Hull Monitor» (каламбур от выражения «Whole monitor»), который проверяет вхождение точки в объединение выпуклых оболочек кластеров данных .
📉 Проблема «схлопывания признаков» (Feature Collapse) 27:53
При работе с изображениями (например, 4096 пикселей) напрямую применять ODD-мониторинг нельзя. Обычно используется снижение размерности через автоэнкодеры, чтобы спроецировать картинку в 2D-пространство .
Однако лектор предупреждает о риске feature collapse: ситуации, когда принципиально разные входные данные проецируются в одну и ту же область латентного пространства . Например, система может успешно распознать ослепляющий солнечный свет как «вне ODD», но при этом ночные изображения (которые также являются внешними для этой модели) могут ошибочно спроецироваться в ту же область, что и нормальные дневные кадры . Это делает мониторинг слепым к определенным типам угроз.
❓ Квантификация неопределенности: Алеаторная и Эпистемическая 35:19
Для мониторинга важно не просто выдавать результат, но и оценивать уверенность в нем. Лектор выделяет два типа неопределенности:
- Выходная (алеаторная) неопределенность: Связана с шумом в данных или случайностью самого мира (шум датчиков, непредсказуемость поведения людей) . Мы знаем, что мир случаен, и можем оценить эту случайность.
- Модельная (эпистемическая) неопределенность: Обусловлена недостатком знаний или данных у модели. Пример с изображением «бутылки соуса, дающей показания в суде», сгенерированным нейросетью: у человека нет внутренней модели для такого события, поэтому возникает высокая эпистемическая неопределенность .
Методы оценки
Для оценки выходной неопределенности в регрессии модель обучают предсказывать не только значение, но и дисперсию (параметры распределения) . Однако современные нейросети часто бывают «плохо откалиброваны» — они склонны выдавать чрезмерно уверенные прогнозы (например, 99% уверенности при реальной точности в 60%) .
Для исправления этого применяются:
- Температурное масштабирование (Temperature Scaling): Простой метод настройки «уверенности» классификатора на проверочном наборе данных .
- Конформное предсказание (Conformal Prediction): Популярный метод, позволяющий создавать наборы предсказаний с гарантированным уровнем достоверности даже для некалиброванных моделей .
🧩 Ансамблирование и мониторинг отказов 1:02:59
Модельную неопределенность часто оценивают с помощью создания ансамблей моделей. Если несколько моделей, обученных на одних и тех же данных, выдают разные результаты в новой точке пространства, значит, в этой области у системы высокая неопределенность .
Основной риск здесь — коллапс ансамбля, когда все модели сходятся в один и тот же локальный минимум и становятся «согласованно неправыми» .
В заключение было отмечено, что даже внутри «безопасной» зоны ODD система может совершать ошибки. Для этого используется Failure Monitoring: запуск упрощенных версий офлайн-анализа (например, анализа достижимости) прямо во время работы системы для предсказания вероятности столкновения в ближайшие секунды .
Курс завершился призывом использовать «модель швейцарского сыра»: ни один метод валидации не идеален, но наложение их друг на друга позволяет закрыть «дыры» и создать надежный кейс безопасности для любой сложной системы .
