Стоп-краны для ИИ: какие предохранители я поставил и зачем они срабатывали

У скорости есть обратная сторона. Человек, который ошибся, ошибается один раз и замечает это. Программа, которая ошиблась, повторит ошибку тысячу раз подряд и будет уверена, что всё идёт по плану.

Поэтому там, где ИИ работает сам, у него стоят стоп-краны. Ни один из них не придуман заранее: каждый появился после того, как что-то уже сломалось.

История первая: сайт, который на минуту исчез

Выкладывал обновление на сайт клиента. Готовый набор файлов лежал во временной папке компьютера, а выкат идёт по правилу «привести сервер в точности к тому, что в пакете»: чего в пакете нет, то на сервере удаляется.

Система тем временем временную папку почистила. Она на то и временная.

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

Спасло то, что скрипт делает бэкап перед каждым выкатом. Вернули за пять минут.

Что из этого выросло. Пакет переехал из временной папки в проект. А в скрипт добавился отказ: если в пакете меньше 25 файлов, выкат просто не начнётся. Пустой пакет это не «обновление», это авария.

История вторая: сутки без публикаций

Очередь, которая ставит первый комментарий под постом, ходила в соцсеть раз в минуту. Каждый раз спрашивала: пост уже вышел?

За три с половиной часа получилось 223 обращения. Соцсеть решила, что это слишком, и закрыла доступ на сутки.

Итог: не встала запланированная публикация, не вышел комментарий, пост пришлось выпускать руками.

Что из этого выросло. Любой цикл, который ходит наружу, обязан ждать всё дольше: не получилось, жди две минуты, потом четыре, потом восемь. Ровно это правило спасло через неделю, когда пост опоздал на полчаса: очередь четырежды не нашла его и спокойно дождалась, вместо того чтобы долбить сервис.

Что стоит сейчас

Стоп-краны есть не только у публикаций.

Реклама. По умолчанию работа идёт в песочнице, а не в живом кабинете. Чтобы попасть в боевой, его надо включить явно. Чтобы что-то в нём изменить, нужно ещё одно отдельное разрешение. Два сознательных действия до первой правки.

Публикация. Пост не уйдёт без двух разных подтверждений. Плюс потолок обращений в сутки.

Выкат сайта. Бэкап перед каждым выкатом и отказ заливать подозрительно маленький пакет.

Агенты. Отдельный сторож ловит не объём работы, а признаки поломки: одну задачу, которая будит агента снова и снова, и шквал запусков за короткое время. Однажды агент писал комментарий к задаче, комментарий будил агента, и он писал снова. Круг замыкался за 13 миллисекунд.

Деньги. Ничего платного без согласования, новый платный сервис сначала проверяется на пяти запросах.

Чужие серверы. Ограничение скорости запросов и остановка, если сервер начал отдавать пустышки вместо данных.

Отдельно: не верить на слово

Самое полезное правило оказалось самым скучным.

Сервис ответил «удалено» не значит, что удалено. Недавно я получил такой ответ дважды подряд, а запись осталась на месте и через шесть минут вышла на стену вторым, лишним постом. Теперь инструмент после удаления проверяет отдельным запросом, что записи действительно нет.

То же с проверками. Чтобы поверить защите, её надо сломать: специально испортить код и посмотреть, покраснеет ли проверка. Если после поломки всё по-прежнему зелено, значит проверка ничего не проверяет. Последнюю защиту я так ломал пять раз подряд, по одной поломке на каждое правило.

Что из этого следует

Предохранители выглядят как недоверие к ИИ, но дело не в доверии.

Дело в цене скорости. Пока работу делают руками, ошибка ограничена скоростью рук: её замечают и останавливают. Когда работу делает программа, ошибка расходится мгновенно и аккуратно, по всем адресам сразу.

Поэтому вопрос не в том, ошибётся ли автоматика. Вопрос в том, что случится в ту минуту, когда она ошибётся, и кто её остановит.