# Стэнфордский курс AA228V: Почему Runtime Monitoring — это «ответ на всё» в безопасности ИИ Источник: https://www.youtube.com/watch?v=uDaHF-rIXb0 Канал: Stanford Online Опубликовано: 07.04.2025 --- В рамках курса Стэнфордского университета AA228V по валидации систем, критически важных для безопасности, финальная лекция была посвящена методам мониторинга во время выполнения (Runtime Monitoring). В то время как офлайн-валидация полагается на модели, которые неизбежно ограничены в своей способности предсказать все нюансы реальности, мониторинг в реальном времени служит последним рубежом защиты, позволяя системе распознавать ситуации, к которым она не была готова. ## 🛠️ Переход к Runtime Monitoring: когда офлайн-методы бессильны [[JUMP:00:05]] До завершающего этапа курса студенты изучали методы, которые можно назвать «офлайн-валидацией»: оценку вероятности отказов, формальные гарантии и объяснимость моделей. Все они базируются на математических моделях мира. Однако, как отмечает лектор, моделирование сложных сред, таких как городские дороги для беспилотных автомобилей, — задача практически невыполнимая до конца [0:57]. В качестве примеров «краевых случаев» (edge cases), которые крайне сложно предусмотреть в модели, были приведены [1:10]: * **Whimo и фонтан:** беспилотник Waymo сталкивается с прорывом гидранта, когда вода бьет столбом прямо посреди дороги. * **Tesla и грузовик со светофорами:** автомобиль Tesla следует за грузовиком, перевозящим светофоры, и пытается реагировать на каждый из них, постоянно меняя режим движения [1:34]. Основная цель мониторинга во время выполнения — зафиксировать опасную или неизвестную ситуацию и активировать механизм отката (fallback mechanism). Это может быть переход в безопасный режим, немедленная остановка или передача управления оператору-человеку [4:21]. По мнению лектора, цитирующего Дугласа Адамса, если «42» — это ответ на вопрос о жизни и вселенной, то «мониторинг во время выполнения» — это ответ на вопрос о безопасном развертывании систем в реальном мире [3:30]. ## 🌐 Мониторинг области операционного проектирования (ODD) [[JUMP:05:14]] Системы проектируются для работы в определенных условиях, называемых Operational Design Domain (ODD). Если система выходит за пределы ODD (например, беспилотник для дневной езды оказывается на дороге ночью), результаты предварительной валидации перестают быть актуальными [6:19]. Существует два основных подхода к определению границ ODD: 1. **Ручной дизайн признаков:** Инженеры сами прописывают условия (например, отсутствие облачности, отсутствие бликов, конкретная рулежная дорожка для самолета) [7:49]. 2. **Подход на основе данных (Data-driven):** Область определяется набором данных, которые использовались при офлайн-валидации. Если текущее состояние системы «похоже» на данные из валидационного набора, считается, что мы находимся внутри ODD [8:28]. ### Метод ближайших соседей и его ограничения Самый простой алгоритм — считать точку принадлежащей к ODD, если её ближайший сосед в обучающей выборке находится в пределах заданного порога расстояния [13:46]. Однако у этого метода есть существенные недостатки [17:41]: * **Потребление памяти:** Необходимо хранить весь огромный набор данных на борту системы. * **Вычислительная сложность:** Поиск ближайшего соседа в многомерном пространстве требует значительных ресурсов. * **Проблема размерности:** В пространствах высокой размерности (например, пиксели изображений) метрики расстояния теряют физический и семантический смысл [18:07]. В качестве альтернативы предлагается использовать кластеризацию и хранить только центры кластеров или строить выпуклые оболочки данных (политопы). С юмором упоминается «Hull Monitor» (каламбур от выражения «Whole monitor»), который проверяет вхождение точки в объединение выпуклых оболочек кластеров данных [21:00]. ## 📉 Проблема «схлопывания признаков» (Feature Collapse) [[JUMP:27:53]] При работе с изображениями (например, 4096 пикселей) напрямую применять ODD-мониторинг нельзя. Обычно используется снижение размерности через автоэнкодеры, чтобы спроецировать картинку в 2D-пространство [30:01]. Однако лектор предупреждает о риске **feature collapse**: ситуации, когда принципиально разные входные данные проецируются в одну и ту же область латентного пространства [32:25]. Например, система может успешно распознать ослепляющий солнечный свет как «вне ODD», но при этом ночные изображения (которые также являются внешними для этой модели) могут ошибочно спроецироваться в ту же область, что и нормальные дневные кадры [32:37]. Это делает мониторинг слепым к определенным типам угроз. ## ❓ Квантификация неопределенности: Алеаторная и Эпистемическая [[JUMP:35:19]] Для мониторинга важно не просто выдавать результат, но и оценивать уверенность в нем. Лектор выделяет два типа неопределенности: 1. **Выходная (алеаторная) неопределенность:** Связана с шумом в данных или случайностью самого мира (шум датчиков, непредсказуемость поведения людей) [43:30]. Мы знаем, что мир случаен, и можем оценить эту случайность. 2. **Модельная (эпистемическая) неопределенность:** Обусловлена недостатком знаний или данных у модели. Пример с изображением «бутылки соуса, дающей показания в суде», сгенерированным нейросетью: у человека нет внутренней модели для такого события, поэтому возникает высокая эпистемическая неопределенность [39:06]. ### Методы оценки Для оценки выходной неопределенности в регрессии модель обучают предсказывать не только значение, но и дисперсию (параметры распределения) [47:12]. Однако современные нейросети часто бывают «плохо откалиброваны» — они склонны выдавать чрезмерно уверенные прогнозы (например, 99% уверенности при реальной точности в 60%) [51:11]. Для исправления этого применяются: * **Температурное масштабирование (Temperature Scaling):** Простой метод настройки «уверенности» классификатора на проверочном наборе данных [52:42]. * **Конформное предсказание (Conformal Prediction):** Популярный метод, позволяющий создавать наборы предсказаний с гарантированным уровнем достоверности даже для некалиброванных моделей [58:10]. ## 🧩 Ансамблирование и мониторинг отказов [[JUMP:1:02:59]] Модельную неопределенность часто оценивают с помощью создания ансамблей моделей. Если несколько моделей, обученных на одних и тех же данных, выдают разные результаты в новой точке пространства, значит, в этой области у системы высокая неопределенность [1:04:02]. Основной риск здесь — **коллапс ансамбля**, когда все модели сходятся в один и тот же локальный минимум и становятся «согласованно неправыми» [1:08:11]. В заключение было отмечено, что даже внутри «безопасной» зоны ODD система может совершать ошибки. Для этого используется **Failure Monitoring**: запуск упрощенных версий офлайн-анализа (например, анализа достижимости) прямо во время работы системы для предсказания вероятности столкновения в ближайшие секунды [1:09:42]. --- Курс завершился призывом использовать «модель швейцарского сыра»: ни один метод валидации не идеален, но наложение их друг на друга позволяет закрыть «дыры» и создать надежный кейс безопасности для любой сложной системы [1:13:44].