Полезная роль малой модели принятия решений
Модель принятия решений оправдывает своё место, когда она сжимает решение, уже принятое где-то в другом месте. Паттерн узкий, и его стоит сформулировать прямо: шаг классифицируется в небольшой набор исходов, которые уже определены — продолжить, эскалировать, отказать, перепланировать — и классификация происходит локально, внутри бюджета задержки, где круговой запрос к хостируемой модели нежизнеспособен. Тот же паттерн поглощает высокочастотную маршрутизацию с низкими ставками, которая иначе потребляла бы вызов frontier-модели. Шаг выбора инструмента, выбор между retrieval и ответом, ветка retry-или-отказ: всё это дёшево оценивать и дорого отправлять наверх на каждом ходу.
Это реальная оптимизация. Она снижает хвостовую задержку, убирает зависимость от удалённого сервиса на общем пути и сохраняет дорогую модель для случаев, которые в ней действительно нуждаются. Ничего из этого не требует, чтобы модель принятия решений была авторитетной. Это требует, чтобы модель принятия решений была производной.
Различие важно, потому что эти две трактовки порождают разные инженерные артефакты. Если модель производна, политика существует независимо и может быть инспектирована. Если модель авторитетна, политика существует только как веса, и единственный способ узнать, что она говорит, — запустить её.
Где протекает абстракция
Три режима отказа повторяются, и они структурные, а не случайные.
Некомпозируемость вероятностных шлюзов. Шлюз с точностью 99%, применённый один раз, — это шлюз с точностью 99%. Шлюз с точностью 99%, применённый на длинной траектории, — это не траектория с безопасностью 99%. Ошибки накапливаются мультипликативно по независимым шагам, а шлюзы в цикле агента не всегда независимы — ранний неверный маршрут меняет распределение входов для каждого последующего шага. Арифметика беспощадна: цепочка решений, каждое из которых верно с высокой вероятностью, всё равно имеет заметный шанс неверного конечного состояния. Вероятностные выходы не композируются в гарантии, и никакая пошаговая точность не превращает их в таковые.
Непрозрачность при ревью. Политика, существующая только как веса, не может быть отревьюена, продиффена или засвидетельствована людьми, которые за неё отвечают. Ревьюер может прочитать allowlist. Ревьюер не может прочитать чекпоинт. Когда разбор инцидента спрашивает почему агент вызвал этот инструмент с этим scope, ответ классификатор оценил это в 0.87 — это не ответ, который удовлетворяет аудитора, и не ответ, который поддерживает исправление.
Правило слоёв
Сначала детерминированная политика. Scope, egress-allowlist, потолки расходов и контракты инструментов, выраженные как ревьюируемые артефакты — файлы, записи, конфигурация, которую человек может прочитать, а CI-задача — продиффить. Они определяют пространство разрешённых действий. Они скучны, и скучность — это и есть суть: это слой, который можно засвидетельствовать.
Модели принятия решений — вторыми. Они выбирают среди опций, которые детерминированный слой уже разрешает. Они не расширяют пространство. Они не вводят инструмент, scope или назначение, которые слой политик уже не авторизовал.
Проверка — одно предложение: всё, что модель может решить, должно быть выразимо как политика, которую детерминированный слой мог бы решить, просто медленнее. Если решение нельзя записать как правило — даже сложное, даже правило, ссылающееся на состояние, — то это не решение о маршрутизации, это изменение политики, и его место наверху, где его можно отревьюить.
Конкретный механизм делает это операционным. Для каждой точки принятия решения поддерживайте детерминированный fallback, реализующий то же пространство исходов в коде. Fallback не обязан быть столь же хорош; он обязан быть корректным и читаемым. Модель работает на горячем пути. Fallback работает в тени, на тех же входах, записывая, что он сказал бы. Два выхода сравниваются, и расхождение логируется вместе с входом, выбором модели и выбором fallback. Это даёт три вещи сразу: ревьюируемое изложение намерения, живой сигнал, g)ан.
Последствия для оценки
Как только слоистость на месте, оценка меняет форму.
Каждому развёртыванию нужен теневой путь. Детерминированный fallback работает рядом с моделью, а не вместо неё. Его выход записывается. Это не цель для тюнинга — это сигнал мониторинга. Расхождение говорит вам, что модель сместилась относительно заявленной политики. Оно не говорит, что модель неправа, и не говорит, что политика неправа. Оно говорит, что эти двое разошлись, и человек должен решить, что из них должно измениться.
Компромисс честен, и его стоит назвать. Теневые пути стоят вычислений и хранения, и они требуют, чтобы детерминированный fallback поддерживался как первоклассный артефакт, а не как заглушка. Взамен система получает ревьюируемую поверхность политик, сигнал дрейфа и деградированный режим, который не пишется впервые во время инцидента. Команды, которые это пропускают, платят за это позже, обычно в виде инцидента, где никто не может восстановить, какой политика должна была быть.
Что это исключает
Это исключает трактовку, где модель принятия решений и есть политика, обученная end-to-end, а детерминированный слой сведён к тонкой обёртке. Такая трактовка выглядит как меньше движущихся частей. На самом деле это меньше ревьюируемых частей, а это не одно и то же.
Это также исключает противоположную сверхкоррекцию: отказ от малых моделей вообще, потому что им нельзя доверить политику. Им можно доверить маршрутизацию — для этого они и нужны. Отказ не в модели. Отказ в том, что её просят быть местом, где живут правила.
Сжимайте политику, которую вы уже написали. Держите политику там, где человек может её прочитать. Когда эти двое расходятся, относитесь к этому как к информации, а не как к шуму, который нужно оттюнить.