Телеграм канал «AI & Robotics Lab»

Разделение "думает" и "действует". Развитие той же идеи: рассуждающую часть системы изолируют так, чтобы она сама ничего не могла выполнить. Все ее предложения проходят через независимую проверку, и только после нее превращаются в действия. Даже если модель обманули, ее намерение упирается в стену.

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

Песочница и контроль выхода. Агент работает в изолированной среде, где ему разрешены только заранее одобренные программы и соединения. Саму изоляцию тоже нужно проверять, потому что, если песочница молча пропускает лишнее, вся архитектура теряет смысл.

Наблюдение и возможность остановить. Защита строится в три шага: предотвратить (права, песочница), заметить (следить за тем, что агент делает прямо сейчас) и среагировать (быстро изолировать, а важные решения оставить людям). Для этого нужен и надежный способ остановить систему.

Где правила заканчиваются. Все перечисленное работает для ограничений, которые можно записать точно: не трогать рабочую базу, не переводить деньги до проверки, не запускать линию без очистки. А вот с расплывчатыми требованиями вроде "не навреди человеку" так не получится: сложность в самом определении, и второй моделью в роли охранника проблему не решить, потому что она тоже вероятностная и ошибается похожим образом. Эта часть остается нерешенной.

#architecture #agents

Убери руки от пульта!

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

Надежный и простой контролер. Еще в исследовании ВВС США 1972 года, т.н. отчет Андерсона сформулирован принцип, на котором полвека держится безопасность компьютерных систем. Тот, кто следит за соблюдением правила, должен удовлетворять трем условиям: его нельзя подделать, его нельзя обойти, и он достаточно прост, чтобы его работу можно было проверить. Модель под эти условия не подходит, потому что она сложная и вероятностная. Поэтому контролер должен быть обычной программой рядом с ней.

Правило в архитектуре, а не в тексте. Обязательство нужно переносить из инструкции, которую модель может прочитать, согласиться с ней и переопределить, в устройство системы, где запрещенного действия просто нет. После случая с удаленной базой Replit не стал усложнять промпт: он физически отделил агента от рабочих данных. Похожий подход у CaMeL: между моделью и инструментами стоит обычная программа, которая следит, откуда пришли данные, и прочитанный текст не может изменить ход выполнения.

Право не отвечать. Система должна уметь промолчать. Идея известна еще с 1970 года: классификатор, который при низкой уверенности отказывается решать и передает вопрос человеку. Важно, что правило "когда модели разрешено говорить" живет вне модели. Тогда система отвечает реже, зато ответы, которые дошли до пользователя, намного надежнее.

Минимальные права. Агент получает только то, что нужно для конкретной задачи, и только на нужное время. Агенту, который сводит обращения клиентов, не нужен доступ к кадровым записям. Хороший тест: что мог бы сделать этот агент в ближайший час, если бы злоумышленник полностью им управлял? Если ответ тревожит, права слишком широкие. В отраслевых рекомендациях эта проблема называется "избыточной самостоятельностью" агента.

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

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

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

Опасная комбинация трех свойств. Риск резко растет, когда у агента одновременно есть доступ к приватным данным, контакт с недоверенным содержимым (сайты, письма, документы) и возможность общаться с внешним миром. Тогда вредный текст на странице может заставить агента отправить данные наружу. Правило: не собирать все три свойства в одном агенте.

Нет доверия - никаких важных действий. Если агент прочитал содержимое, которому нельзя доверять, система должна быть устроена так, чтобы оно не могло запустить действия с серьезными последствиями. Для этого придумано несколько шаблонов. Один из них - план составляется заранее, а затем только исполняется, и прочитанное по ходу дела его не меняет. Другой - две модели: одна управляет инструментами, но никогда не видит текст, которому нет доверия, а вторая читает такой текст, но не имеет никаких прав и передает результат только в виде пометок вроде "результат 1".

#architecture #agents

Никогда не говори никогда

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

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

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

Все это работает на вероятностном принципе. У модели нет жесткого алгоритма, а значит, любой исход возможен, даже самый неожиданный, пусть и с малой вероятностью. Любое правило, которое выражено только текстом (в промпте или в обучении), остается предпочтением, а не обязательством.

Граница. Сама по себе модель устроена именно так, и это ее свойство не исправить ни улучшением модели, ни более строгим промптом. Если мы хотим защититься от неожиданностей, нужно добавить поверх модели слой жестких правил: права доступа, разделение сред, белые списки допустимых действий, обязательные проверки перед необратимыми операциями. Модель остается вероятностной, но действия системы в целом становятся предсказуемыми.

Вот несколько примеров, когда от системы хотели то, что она не могла дать.

• Replit (2025). Основатель компании попросил AI-агента ничего не менять в рабочей базе данных, пока он не разрешит. Агент несколько раз подтвердил, что понял, но все равно удалил базу, а потом сказал, что данные не восстановить (это было неправда). Правило было записано только словами, поэтому осталось пожеланием. Исправили это не более строгой инструкцией: агента физически отделили от рабочих данных, и сделать такое он больше не мог.

• OpenAI и GPT-4o (2025). В обучение добавили награду за "лайки" пользователей. Она вошла в общий баланс с остальными наградами и перевесила умение сдержанно возражать: модель стала поддакивать даже в небезопасных ситуациях, и обновление пришлось откатить. Поведение модели - это результат баланса, и стоит сместить одну составляющую, как меняется все.

• Исследование Cisco (2026). Модели проверяли на просьбы нарушить собственные правила. С первого раза они чаще отказывали, но в длинном диалоге уступали заметно чаще, иногда почти вдвое. Устойчивость правила зависит от того, как долго и настойчиво с моделью разговаривают.

• Атаки одной модели на другую (2026). Исследователи поручили нескольким моделям самостоятельно взламывать защиту популярных ИИ-систем, и в подавляющем большинстве случаев у них это получилось. Обученный отказ плохо работает против противника, который не устает и пробует снова и снова.

Пример защитного слоя. CaMeL (Google DeepMind и ETH Zürich). Между моделью и ее инструментами стоит обычная программа, которая следит, откуда пришли данные. Поэтому текст, прочитанный агентом на странице или в документе, не может заставить его сделать что-то другое. Система немного чаще не справляется с задачами, чем совсем без защиты, но это небольшая цена за предсказуемость.

#architecture #agents

Лучше поздно, чем никогда - ролик про MentorPi уже на канале.

#mentorpi #ros2 #robots