Две задачи, которые выглядят как одна
Модель принятия решений отвечает на вопрос маршрутизации: при текущем состоянии какая ветвь с наибольшей вероятностью приведёт к успешной траектории? Она обучена на трассах прошлого поведения и выдаёт токен за миллисекунды. Механизм политик отвечает на другой вопрос: при текущем состоянии и предлагаемом действии разрешено ли это действие? Он вычисляет объявленный, проверяемый набор правил и возвращает вердикт за миллисекунды.
Поскольку оба возвращают результат быстро и оба находятся на критическом пути, на архитектурных диаграммах их часто объединяют в один блок с подписью «guardrails» или «router». Такое объединение — категориальная ошибка. Router — это обученная функция над траекториями. Механизм политик — это декларативная функция над правилами. У них разные режимы отказа, разная частота изменений и разные обязательства по доказуемости.
Когда эти два понятия смешиваются, обновление модели незаметно меняет то, что системе разрешено делать. Обучающий запуск становится непроверенным изменением политики, и аудиторский след, необходимый для разбора инцидента, не существует.
Почему подмена так заманчива
Задержка router оплачивается на каждом шаге агента. Классификатор на 2B параметров, показывающий хорошие результаты на классификации намерений, в демо выглядит как guardrail: он быстрый, дешёвый в хостинге и, кажется, удерживает агента в рамках задачи. Декларативная политика, напротив, добавляет отдельный сервис, схему правил, процесс проверки и историю версионирования. Дешёвый путь побеждает до первого инцидента, когда требуется объяснить, почему было выполнено действие.
Что механизм политик должен предоставлять, а классификатор не может
Детерминизм. Один и тот же запрос и контекст должны давать один и тот же вердикт во всех версиях модели. Вердикт классификатора может измениться при обновлении весов, изменении температуры или другом порядке батчинга. Вердикт механизма политик — это функция объявленных правил и явных входных данных.
Перечислимость. Аудитор должен иметь возможность перечислить все классы действий, которые система разрешает. Классификатор можно зондировать, но зондирование даёт выборки, а не перечисление. Это различие важно, когда вопрос звучит как «что эта система может делать?», а не «что она сделала во вторник?»
Атрибуция. Каждый вердикт должен указывать правило, которое его породило, а не вероятность. Когда агент выполняет действие, которое позже выглядит ошибочным, трасса должна указывать, какое правило его допустило. Оценка уверенности 0.87 не отвечает на этот вопрос.
Версионирование. Правила меняются с частотой проверок, а не с частотой обучения. История версий механизма политик — это последовательность проверенных изменений; история версий модели — это последовательность обучающих запусков. Это разные артефакты с разными проверяющими и разной семантикой отката.
Конкретный механизм делает различие наглядным. Рассмотрим границу инструмента, где агент предлагает вызов transfer_funds. Модель принятия решений может направить к этому инструменту, потому что она обучилась на том, что похожие состояния часто предшествуют успешному завершению задачи. Механизм политик оценивает вызов по правилам, таким как amount <= approved_limit, recipient in allowlist и requires_human_approval для набора классов действий. Router выбирает среди уже разрешённых действий; механизм политик решает, разрешено ли выбранное действие вообще. Router никогда не расширяет разрешённое множество.
Рабочее разделение
Разделение, которое выдерживает нагрузку, мало и явно.
- Модели принятия решений выбирают среди уже разрешённых действий. Они работают с множеством, допущенным политикой, и не могут его расширить.
- Политика вычисляется после маршрутизации и перед выполнением, на границе инструмента. Такое размещение позволяет заменить router, не меняя того, что системе разрешено делать.
- Каждый маршрутизированный шаг несёт в трассе идентификатор правила, которое его допустило. Тогда трасса содержит и решение о маршрутизации, и решение об авторизации, и их можно разделить при разборе.
- Замена модели запускает прогон eval по корпусу политик, а не просто проверку точности. Eval спрашивает, остаются ли предпочитаемые действия нового router
У этого разделения есть цена. Оно добавляет вызов сервиса на критическом пути и заставляет команды поддерживать схему правил и процесс проверки. Честный компромисс — это задержка и операционные издержки против аудируемости и ограниченного поведения. Для систем, которые маршрутизируют только среди инструментов только для чтения, издержки могут быть не оправданы. Для систем, которые касаются денег, данных или внешних побочных эффектов, издержки — это цена возможности объяснить действие постфактум.
Есть и второй компромисс в обратную сторону. Слишком грубый механизм политик будет блокировать законные траектории, и команды начнут обходить его. Лекарство не в том, чтобы ослабить механизм, а в том, чтобы сделать набор правил проверяемым и версионируемым, чтобы его расширение было осознанным, зафиксированным изменением, а не неявным.
Режим отказа, который нужно инструментировать
Режим отказа, который имеет значение, — это расхождение между предпочитаемым действием router и множеством, разрешённым политикой. В здоровой системе предпочтения router почти всегда находятся внутри разрешённого множества, а отказы политики редки и объяснимы. Растущая частота расхождений — это сигнал, что модель обучилась в обход правил: она предлагает действия, которые политика постоянно отклоняет, или предлагает действия, которые политика допускает только потому, что правила не успели обновиться.
Инструментирование для этого прямолинейно. Логируйте для каждого маршрутизированного шага предпочитаемое действие router, вердикт политики и идентификатор правила. Затем отслеживайте частоту, с которой предпочитаемое действие выходит за пределы разрешённого множества, и частоту, с которой политика допускает действие, которое router не предпочитал. Рост первой частоты говорит о том, что модель дрейфует к недопустимому поведению. Рост второй частоты говорит о том, что набор политик шире, чем обученное распределение router, — это другая проблема, но столь же достойная внимания.
Ни одна из этих частот не заменяет другую. Вместе они дают картину, которую не даёт ни точность классификатора, ни список правил механизма политик по отдельности. Эта картина нужна для разбора инцидента, и её не может создать быстрый классификатор.
Заключение
Малые модели принятия решений — это бюджет задержки. Они покупают скорость на критическом пути и хорошо с этим справляются. Они не являются слоем управления, и отношение к ним как к таковому схлопывает две поверхности контроля в один артефакт без частоты проверок и без атрибуции. Разделение не бесплатно, но это разница между системой, которую можно объяснить, и системой, которую можно только переобучить.