Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Формальные ограничения для LLM-агентов научились обновлять по обратной связи, сохраняя воспроизводимые решения о разрешении и запрете действий. В препринте Google Cloud AI Research, Google DeepMind и University of North Carolina at Chapel Hill, который не прошёл рецензирование и где все числа получили сами авторы, VEPA обошла фиксированные LLM и защитные слои с обновляемой текстовой памятью. Для систем с доступом к документам, инструментам и изменяемым данным это предлагает промежуточный вариант между жёсткими правилами и вероятностным контролем через LLM.
LLM предлагает патч, но не принимает решение
VEPA проверяет событие до того, как агент выполнит действие. Событием может быть вызов инструмента, отправка файла или обращение к данным вместе с контекстом: кто действует, что передаёт, кому, с какой целью и с каким уровнем доступа.
Сначала отдельная LLM переводит исходную трассу агента в типизированную запись с полями из заранее заданной схемы. Если исходное событие не позволяет определить значение, разборщик ставит отметку unknown, а не дополняет контекст догадкой.
Политика состоит из исполняемых правил. Например, сочетание конфиденциальных данных и внешнего получателя может привести к запрету. Для одного и того же типизированного события набор правил всегда выдаёт одинаковый результат.
Когда обратная связь показывает ошибку, другая LLM предлагает патч: добавить, удалить, переписать, разделить или объединить правила. Она ищет не единственный лучший вариант, а набор кандидатов с разным балансом между исправлением новых ошибок и сохранением прежних верных решений.
Кандидат проходит детерминированную проверку. Верификатор отклоняет правила с неизвестными полями и неподдерживаемыми операциями, а также ищет пересечения, при которых одно правило разрешает событие, а другое запрещает его. LLM участвует в поиске формулировки, но не получает права самостоятельно менять решение защитного слоя.
Одной структурной проверки недостаточно: корректно записанное правило может плохо обобщаться на следующие события. Поэтому VEPA отделяет проверку от полномочий. Новое правило начинает влиять на работу агента только после того, как накопит достаточно подтверждений, и теряет это право, если последующая обратная связь ему противоречит.
Верификатор дал системе основную прибавку
Качество измеряли метрикой F1, которая объединяет точность и полноту, причём только на событиях, уже покрытых активной формальной политикой. К финальному раунду VEPA получила F1 0,81 на ASSEBench-Safety и 0,76 на ATBench. Отрыв от сильнейшего конкурента составил соответственно 0,02 и 0,09.
Покрытие росло по мере накопления проверенных правил: формальная часть системы принимала решения для всё большей доли потока. События вне её области направлялись резервной LLM, поэтому детерминизм относился не ко всей системе, а только к активным правилам.
Самым важным компонентом оказался верификатор. Когда сгенерированные изменения применяли без него, итоговая F1 на смешанном потоке падала на 0,13. Удаление отбора кандидатов и слоя полномочий тоже ухудшало результат, но слабее.
VEPA сравнивали с фиксированной LLM и адаптивными системами AGrail и LiSA на ASSEBench-Safety, ASSEBench-Security и ATBench. Проверка охватывала отдельные и смешанные потоки, намеренно искажённую обратную связь, более длинное накопление правил и замену моделей Gemini в нейронных компонентах.
Граница результата проходит перед формальной политикой. Исходный текст разбирает LLM, которая может ошибиться, поэтому воспроизводимость начинается только после преобразования события в типизированную запись. Она также действует лишь там, где активное правило покрывает событие.
Архитектуру стоит разделить на предложение, проверку и полномочия
Работа меняет планы команд, которым недостаточно проверять действия агента ещё одним запросом к LLM. Если агент отправляет сообщения, вызывает привилегированные инструменты или меняет записи, решение можно вынести в отдельный исполняемый слой, а модели оставить подготовку обновлений.
Такой подход требует заранее определить схему событий и конечный словарь значений. Именно эта структура позволяет обнаружить пересечение противоположных правил до выполнения действия. Без неё контроль снова сводится к интерпретации текста моделью и теряет воспроизводимость.
Обновление политики также нельзя считать одним шагом генерации. VEPA показывает полезное разделение ответственности: LLM предлагает изменение, верификатор проверяет его форму и конфликты, а слой полномочий ждёт подтверждений из эксплуатации. Каждый этап можно журналировать и разбирать отдельно.
При этом VEPA не устраняет вероятностную часть полностью. Разбор исходного события и резервное решение для непокрытых случаев остаются за LLM. Практический вывод уже уже: формальные гарантии следует привязывать к конкретной границе системы — типизированному событию и активному правилу, — а не распространять на весь агентный процесс.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
