Позвольте мне описать сценарий, который уже реализуется в производственных средах. Команда развертывает ИИ-агент для управления рутинным масштабированием инфраструктуры. Несколько недель агент работает безупречно. Он оптимизирует затраты, реагирует на изменения трафика быстрее, чем это мог бы сделать любой человек, и команда начинает доверять ему безоговорочно.
Затем в один четверг в 3 часа ночи агент сталкивается с ранее невиданной ситуацией — каскадной частичной неисправностью в сочетании с задержкой распространения DNS — и уверенно принимает абсолютно неправильное решение. Он уменьшает масштаб исправных экземпляров, поскольку неверно интерпретировал ответы проверки работоспособности.
Это не гипотетическая ситуация. Вариации этой истории уже циркулируют в отчетах по итогам инцидентов в компаниях, использующих инфраструктуру на основе агентов. Основная проблема не в том, что агент дал сбой. Все дает сбой. Проблема в том, что агент дал сбой уверенно, не подавая сигналов неопределенности, а окружающие его люди постепенно перестали следить за ситуацией.
У нас есть десятилетия исследований по самоуспокоенности в отношении автоматизации в авиации и промышленных системах управления. Паттерн хорошо задокументирован: по мере того, как автоматизированные системы становятся более надежными, операторы-люди становятся менее бдительными, и когда система наконец выходит из строя по-новому, люди оказываются менее подготовленными, чем когда-либо. Сейчас мы воспроизводим именно этот режим отказа в эксплуатации программного обеспечения, за исключением того, что наш «автопилот» — это языковая модель, которая не может отличить высокую уверенность от правильной уверенности.
Решение заключается не в том, чтобы избегать ИИ-агентов. Этот поезд уже ушел, и рост производительности реальный. Решение заключается в разработке с учетом калиброванного доверия. Это означает, что агенты должны раскрывать свою неопределенность, а не только свои решения. Это означает, что панели управления должны показывать не только то, что сделал агент, но и какие альтернативы он рассматривал и отверг. Это означает, что дежурные инженеры нуждаются в обучении не тому, как управлять системами вручную, что является старой моделью, а тому, как оценивать и отменять решения агента в условиях давления.
Самое главное, это означает включение «снижения доверия» в вашу операционную модель. Если агент не сталкивался с новым сценарием в течение 30 дней, готовность вашей команды к вмешательству снизилась. Планируйте синтетические события неопределенности. Заставляйте агента эскалировать решения, с которыми он мог бы справиться самостоятельно. Держите людей в курсе не потому, что агент нуждается в них сегодня, а потому, что он будет нуждаться в них в тот день, который он не может предсказать.
Подписывайтесь на наш канал в Телеграм
⚡ Подписаться