Учёный предложил ловить тихие сбои ИИ-агентов проверкой действий до выполнения

ИИ-агент работает, выполняя действия: запускает команды шелла, применяет правки к коду. Ошибочное действие не всегда проваливается с понятным сообщением об ошибке, оно может провалиться тихо: дать правдоподобный, но неверный результат, который не поднимает никакой тревоги. Автор работы утверждает, что дешёвая детерминированная проверка, выполняемая до того, как действие вступит в силу, эффективная и малоиспользуемая форма надзора за ИИ-агентами, и исследует эту идею сразу в двух режимах действий агента в рамках одной общей схемы. Смысл, заранее, ещё до запуска исполнителя, зафиксировать правильный эффект действия по самой его конструкции: тогда тихий сбой измеряется напрямую, а верификатор вправе отказаться от вердикта вместо того, чтобы гадать.

Для команд шелла построен статический верификатор, покрывающий 9930 команд и 482 инструмента: он ловит 95,8% некорректных команд при 10,0% ложных срабатываний. Проверки синтаксиса и существования бинарника всегда дают однозначный вердикт, не производят ни одного ложного срабатывания и сами по себе ловят половину всех ошибок. Проверка флагов слабее: её точность ограничена только полнотой справки инструмента, и именно на неё приходятся все ложные срабатывания верификатора.

Для правок кода собран бенчмарк из 640 правок в 224 файлах, изолирующий именно шаг применения правки, и он выявляет резкое различие между форматами. Правки, привязанные к содержимому (в духе search/replace или diff), при ошибке проваливаются явно, с понятным сообщением. Правки, привязанные к местоположению, проваливаются незаметно: правка по номеру строки портит 99,1% файлов уже при сдвиге текста всего на одну строку, а правка по имени функции в 12,7% случаев попадает не в ту функцию.

В обеих постановках задачи политика «отказывайся, если не уверен» переводит тихие сбои в исправимые ошибки, ценой того, что агент реже соглашается действовать. Механизм, названный «выборочной привязкой» (selective grounding), достигает полноты (recall) 0,958 при 7,0% ложных срабатываний. Обработчик правок с проверкой места вставки (anchor-and-verify) допускает лишь одно незаметное неверное применение на 8320 попыток, 0,01%. Оба бенчмарка, верификаторы и защитные механизмы автор обещает выложить в открытый доступ.

Ключевые факты

Идея: проверять действие ИИ-агента, команду шелла или правку кода, ещё до того, как оно вступит в силу, дешёвой детерминированной проверкой, которая вправе отказаться от вердикта, если не уверена, вместо того чтобы гадать.
На наборе из 9930 команд и 482 инструментов статический верификатор ловит 95,8% некорректных команд шелла при 10,0% ложных срабатываний; проверки синтаксиса и бинарника безошибочны и сами ловят половину всех ошибок, а все ложные срабатывания дают более слабые проверки флагов, ограниченные полнотой справки инструмента.
На бенчмарке из 640 правок в 224 файлах правки по содержимому (search/replace, diff) при ошибке проваливаются явно, а правки по местоположению, незаметно: правка по номеру строки портит 99,1% файлов при сдвиге на одну строку, а правка по имени функции в 12,7% случаев попадает не в ту функцию.
Политика «отказывайся, если не уверен» переводит тихие сбои в исправимые: выборочная привязка (selective grounding) достигает полноты 0,958 при 7,0% ложных срабатываний, а обработчик с проверкой места вставки (anchor-and-verify) допускает одно незаметное неверное применение на 8320 попыток (0,01%).
Автор обещает выложить оба бенчмарка, верификаторы и защитные механизмы в открытый доступ, хотя площадка и сроки публикации в тексте не названы.

Почему это важно

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

Кому это важно

Тем, кто строит или использует ИИ-агентов, самостоятельно выполняющих действия без построчного просмотра человеком: агентные среды разработки, которые применяют правки к коду от имени пользователя, и автономных DevOps- и SRE-агентов, которые запускают команды в рабочих окружениях. Отдельно это важно тем, кто уже пользуется правками по номеру строки или по имени функции: бенчмарк показывает, что правка по номеру строки портит 99,1% файлов при сдвиге на одну строку, а правка по имени функции в 12,7% случаев путает функции даже без всякого расхождения, тогда как правки вида search/replace или diff проваливаются заметно и потому безопаснее.

Как это применить

Практический вывод из бенчмарка правок: там, где агент редактирует код, форматы, привязанные к содержимому (search/replace, diff), предпочтительнее правок по номеру строки или по имени функции, оба формата проваливаются незаметно: правка по номеру строки портит 99,1% файлов при сдвиге на одну строку, а правка по имени функции в 12,7% случаев путает функции даже без сдвига. Там, где агент выполняет команды шелла, дешёвый статический верификатор, проверка синтаксиса, существования бинарника и допустимости флагов по справке инструмента, перед запуском ловит подавляющее большинство некорректных команд, а политика «отказывайся, если не уверен» при той же полноте (95,8%) снижает долю ложных срабатываний с 10,0% до 7,0% ценой того, что часть законных действий агент выполнять откажется. Автор обещает открыть оба бенчмарка, верификаторы и защитные механизмы, но где именно они будут выложены, в тексте не указано.

Можно ли доверять

Это препринт на arXiv: в тексте не названы ни организации, ни статус рецензирования, поэтому независимо оценить, кто стоит за работой, нечем. Все приведённые числа, из бенчмарков, которые построил сам автор. При этом сама методика, детерминированные проверки на данных, которые автор обещает выложить в открытый доступ, по конструкции проверяема: результаты можно будет пересчитать на тех же 9930 командах и 640 правках, когда бенчмарки станут доступны.

Риски и подводные камни

У любой рабочей точки верификатора есть цена: 10,0% ложных срабатываний у базового статического верификатора команд шелла и 7,0%, у версии с отказом при сомнении означают, что часть легитимных действий агент не выполнит без надобности. Точность проверки флагов ограничена только полнотой справки инструмента, для утилит с неполной или нестандартной справкой в этой проверке останутся слепые зоны, и именно на неё приходятся все ложные срабатывания верификатора. Отказ при сомнении убирает тихие сбои ценой того, что агент реже соглашается действовать, это осознанный компромисс, а не бесплатное решение. И главный практический риск для тех, кто уже сегодня редактирует код через ИИ-агента: если инструмент правит файлы по номеру строки или по имени функции, а не по содержимому, повреждение файла, не гипотетический, а измеренный на 640 правках сценарий: по номеру строки оно происходит при малейшем сдвиге, по имени функции, возможно и без всякого сдвига.

«Мы утверждаем, что дешёвая детерминированная проверка, выполняемая до того, как действие вступает в силу, это эффективная и малоиспользуемая форма надзора за ИИ-агентами.»

— автор работы