ИИ‑агент не должен получать больше автономности только потому, что выглядит компетентным. Автономность должна расти тогда, когда система вокруг агента умеет надежно обнаруживать его ошибки.
С какого *неправильного* вопроса все начинают
Команда, которая внедряет ИИ‑агентов, рано или поздно задается вопросом: насколько самостоятельно мы можем позволить агенту работать?
Обычно ответ звучит примерно так: чем умнее становится модель, тем больше свободы ей можно дать. Агент хорошо проходит демо, показывает нужный результат, поэтому можно ослабить контроль.
На мой взгляд, это неверный подход.
Демонстрация показывает, что агент способен выполнить конкретную задачу. Но она почти ничего не говорит о том, что произойдет в следующий раз. И тем более не отвечает на вопрос, заметит ли кто‑нибудь ошибку, если результат окажется неправильным.
Представьте обычный процесс найма. Кандидат отлично прошел собеседование, уверенно отвечает на вопросы и выглядит компетентным. Но это не значит, что в первый день ему дадут корпоративную кредитную карту и полный доступ ко всем системам. Сначала нужно полностью проверить работу кандидата. Следовательно, именно проверка и ограничивает объем делегированной работы.
Поэтому перед тем, как давать агенту больше самостоятельности, я бы задал два вопроса:
Если система ошибется и никто этого не заметит, сколько это будет стоить и можно ли будет исправить последствия?
Получится ли отличить хороший результат от плохого, не полагаясь на утверждение самого агента?
Первый вопрос быстро разделяет простые и критичные сценарии.
Опечатка в черновике письма, которое еще никто не отправил, почти ничего не стоит. Здесь агенту можно дать много свободы. А неправильное число в отчете, на основании которого принимается бизнес‑решение, — уже другая ситуация. Ошибка может привести к финансовым потерям или подорвать доверие к системе.
Именно такие случаи здесь интересны.
Я размышляю об этой проблеме с тех пор, как начал написал о неверном понимании; ответ выглядит правильным и модель уверенно его выдает, но он не соответствует решению, которое на самом деле требовалось принять. Термин я придумал сам. Пока им пользуется один человек, но я не теряю оптимизма.
Мой основной вывод такой: верхний предел автономности агента задает способность системы обнаруживать его ошибки.
Насколько близко к этому пределу можно работать, зависит уже от стоимости необнаруженной ошибки и возможности ее исправить. Поэтому автономность должна меняться вместе с качеством проверки. Я называю это градиентом автономности.
Кто проверяет работу
В тестировании ПО есть полезное понятие oracle. Это любой механизм, который позволяет определить, правильный результат или нет. Здесь особенно важна независимость: студент не должен проверять собственный экзамен.
Для агентных систем я бы выделил четыре типа проверяющих: от максимально механизированных до наиболее близких к человеческой оценке.
Нумерация здесь требует пояснения. O0 — не самый слабый контролер. Это базовый уровень, на который приходится опираться, если более сильной проверки нет.
Уровни описывают только одно: насколько напрямую и воспроизводимо можно проверить результат. При этом у каждого уровня есть ограничения. Автоматическая проверка может подтвердить, что числа сходятся, но не докажет, что используемое компанией определение «активного клиента» действительно соответствует бизнес‑смыслу. В таких вопросах все равно нужен человек.
Есть и еще одна важная деталь: не стоит задавать агенту один глобальный уровень автономности. Один и тот же агент может получить почти полную свободу при исправлении ошибки в пайплайне, ограниченную свободу при изменении документации и вообще не иметь права самостоятельно менять бизнес‑метрику.
Автономность относится к решению, а не к агенту.
В этом подходе нет ничего принципиально нового. Банки давно требуют вторую пару глаз для платежей. Команды разработки проверяют релизы. Системы оценки ИИ используют разные варианты evals.
Проблема в другом: эти механизмы проверки редко напрямую связаны с разрешениями. Evals помогают понять, насколько хорошо агент справляется с задачей. Но они не обязательно отвечают на вопрос, что именно этому агенту разрешено делать сегодня.
Чек‑лист сам по себе ничего не гарантирует
Четыре уровня проверки — это только лестница. По факту важна не сама категория проверяющего, а то, насколько хорошо он работает.
Фраза «Это решение проходит автоматические тесты» сама по себе мало что значит. Тест может покрывать только небольшую часть действительно важных случаев. Он может быть сломан и никто этого не заметит. Он может запускаться раз в квартал, хотя решение принимается каждый день.
Формально тест есть. Практической защиты может не быть. Поэтому силу проверки имеет смысл оценивать как минимум по четырем параметрам:
Охват. Какую часть решения действительно можно проверить. Что остается за пределами контроля.
Надежность. Работает ли сам проверяющий механизм. Актуальны ли данные или эталон, с которым он сравнивает результат.
Устойчивость. Запускается ли проверка регулярно и работает ли она в реальных условиях.
Независимость. Способна ли проверка обнаружить ошибки агента или повторяет те же ошибки.
Последний пункт особенно важен. Если агент знает, как устроена проверка, он может оптимизировать результат под прохождение теста, а не под правильность самого решения.
Получается не четыре фиксированных уровня, а непрерывная шкала.
Две компании могут сказать: «У нас есть тесты» и при этом находиться на совершенно разных уровнях надежности контроля. Эти четыре параметра позволяют оценивать ситуацию предметно, а не на уровне ощущений.
Возникает очевидный вопрос: кто тогда проверяет проверяющего?
На практике этот регресс не бесконечен. Проверка самого механизма обычно проще, чем проверка результата. Например, факт того, что тест действительно запускался вчера, машина может подтвердить автоматически.
В итоге цепочка заканчивается периодическим контролем со стороны человека.
Это хорошо видно в экспериментах с командами агентов, работающими с реальными платформами данных. Когда система начинает давать неправильные результаты, первым часто ломается не сам агент, а контроль вокруг него. Тест перестает выполняться. Эталон не обновляют после изменения определения. Проверка продолжает проходить, хотя фактически больше ничего не проверяет. А агент продолжает работать так, будто все в порядке.
Второй ИИ не решает проблему независимости
Отдельный случай — когда одного ИИ поручают проверять другим.
Это полезный подход, особенно если проверка касается формы или структуры результата. Но у похожих моделей могут быть одинаковые слепые зоны. Если две модели используют близкие представления и обучались на похожих данных, они могут одинаково ошибаться в одном и том же месте. Поэтому второй ИИ можно рассматривать как O1, но его независимость при проверке похожей модели может быть близка к нулю.
Сам подход не бесполезен. Просто его результат нельзя считать единственным подтверждением для важных изменений.
Автономность должна снижаться автоматически
У градиента автономности есть важное свойство: он асимметричен.
Когда проверка становится надежнее, автономность можно увеличивать. Если проверка ослабевает, автономность должна уменьшаться автоматически. Для агента ухудшение проверки может означать разные вещи: критический тест перестал выполняться, эталонные данные устарели, изменилась базовая модель или исчез один из механизмов контроля.
Во всех этих случаях реакция должна быть заранее определена.
Например:
выполнение → предложение → эскалация → остановка.
Это похоже на то, как управляют крупной программной инфраструктурой. Системам задают допустимый бюджет ошибок, и когда он исчерпан, темп изменений снижается автоматически. Для агентов есть смысл учитывать не только сами ошибки, но и пробелы в покрытии. Иначе получается странная ситуация: агент со слабыми проверками получает больше свободы именно потому, что его ошибки никто не видит.
Обратный путь должен быть медленнее.
Появление более надежного проверяющего может дать основание увеличить автономность, но сам проверяющий не должен автоматически наделять себя дополнительными полномочиями. То же касается новых агентов. Хороший инструментарий создает условия для получения автономности, но не является доказательством того, что агент ее заслуживает. Здесь нужен послужной список: как часто проверка обнаруживала ошибки этого конкретного агента, а не сколько положительных отзывов он получил. Для новых агентов подходит режим «только предложение». Агент формирует результат, но не выполняет действие, пока его не подтвердит проверяющий или человек.
Так ошибки проще исправлять.
При этом нужно проверять и сам механизм контроля. То, что проверка существует, еще не означает, что она действительно работает. Это примерно тот же принцип, по которому время от времени тестируют пожарную сигнализацию.
Автоматически вниз. Намеренно вверх.
Такой подход может показаться слишком консервативным. Но альтернатива — требовать участия человека в каждом действии. Если человек просматривает сотни запросов агентов в день, он постепенно превращается в узкое место системы. Человеческое внимание тоже имеет ограниченную пропускную способность и свои ошибки.
По собственному опыту могу сказать: мое внимание — один из наименее надежных компонентов любой системы контроля, в которой я участвую.
Градиент автономности позволяет решить эту проблему иначе. Человек не обязан проверять все действия агента. Он должен иметь возможность вмешаться там, где автоматические проверки недостаточны. Если контроль слабый, вариантов немного: уменьшить автономность, сократить набор доступных действий или снизить скорость изменений.
Не стоит компенсировать слабый контроль постоянным добавлением разрешений.
Данные, как отдельная проблема
В аналитике проверки часто слабее, чем кажется. Неправильное число может выглядеть вполне правдоподобно, а ошибку в данных иногда сложнее заметить, чем ошибку в коде.
Поэтому вопрос автономности агентов в аналитике заслуживает отдельного рассмотрения.
С чего начинать
Перед тем как предоставить агенту автономность, я бы ответил на шесть вопросов:
Какое именно решение может принять агент?
Сколько стоит необнаруженная ошибка и можно ли ее исправить?
Какой независимый механизм может определить, было ли решение правильным?
Какие части решения никто не проверяет?
Актуальна ли система проверки и запускается ли она достаточно часто?
Что происходит автоматически, когда система проверки перестает работать или становится менее надежной?
Если на эти вопросы есть четкие ответы, выбор модели перестает быть главным вопросом. Разные модели могут решать одну и ту же задачу по‑разному, но при этом работать в рамках одинаковых проверок и ограничений.
Я все больше прихожу к тому, что основной единицей управления ИИ должна быть не модель и даже не агент. Это конкретное решение вместе со всем, что позволяет доказать его ошибочность.
Если вы не можете объяснить, как система обнаружит ошибку агента, значит, вы еще не спроектировали автономную систему. Вы спроектировали систему, которой дали доступ к API и надеетесь, что все будет работать.
