В системах, которые работают с переводом денежных средств, здравоохранением или инфраструктурой, недостаточно, чтобы агент искусственного интеллекта успешно работал в большинстве случаев. Центральная идея первого уровня шестиступенчатой модели эксплуатации систем на основе языковых моделей в производственной среде заключается в том, чтобы заключить модель в один узел, оставив окружающую его часть обычным кодом, который можно тестировать, проверять и подвергать аудиту.
В материале этот подход описывается как «слой детерминизма»: система сохраняет способность модели выносить суждения по сложным входным данным, но не позволяет ей напрямую распоряжаться состоянием бизнеса или выполнять чувствительные действия.
Агент предлагает, но не выполняет
Агент работает как чистая функция, преобразующая контекст в предлагаемое решение. Он выдает идентификатор решения, требуемую возможность, предлагаемое изменение, оценку уверенности, маршрут направления, причины и доказательства, но не изменяет состояние бизнеса. Затем результат передается отдельному компоненту, который в материале называется substrate, и тот применяет его только после получения необходимого одобрения.
Такое разделение наделяет систему тремя практическими свойствами: возможностью тестировать агента без симуляции внешнего мира, снижением последствий ошибочных выходных данных до уровня предложения, которое можно отклонить, и предотвращением скрытых цепочек побочных эффектов между агентами. Благодаря этому проверяемый вопрос формулируется так: что предложила модель, кто это одобрил и что было фактически применено?
Фиксированная схема вместо свободного цикла
Вместо того чтобы позволять модели ReAct каждый раз определять следующий шаг, материал предлагает фиксированную схему для каждой возможности. Согласно приведенному примеру, запрос проходит через узлы ввода решения, проверки входных данных и загрузки контекста, затем через один узел языкового вывода, после чего следуют барьеры выходных данных и проверка, необязательное вынесение решения, агрегирование уверенности, направление, подготовка предложения, запись в память и журнал решения.
Такая структура делает путь выполнения заранее известным, ограничивает время и стоимость выполнения и позволяет тестировать каждый узел отдельно. Единственным недетерминированным узлом является llm_decision: он получает структурированный ввод и выдает структурированный вывод, тогда как специализированный код проверяет допустимые значения, соответствие схеме и бизнес-правила.
Структурированные выходные данные не означают правильность решения
Материал предостерегает от использования свободного текста с последующим извлечением из него решения. Альтернатива — использовать JSON-схему, вызов инструментов или генерацию, ограниченную грамматическими правилами, а затем проверять результат и повторять попытку при несоответствии, устанавливая ограниченное число попыток и переходя к безопасному отказу вместо передачи догадки на следующие этапы.
Однако эта процедура регулирует форму выхода, а не правильность суждения. Объект JSON может быть синтаксически корректным, но содержать ошибочное решение. Поэтому проверка бизнес-правил, оценивание и независимые сигналы уверенности должны оставаться на последующих уровнях.
Уверенность, эскалация и неизменяемый журнал
Уверенность формируется из сигнала модели, результатов проверки и проверки второй моделью при выборочном контроле чувствительных решений. Затем система направляет решение на автоматическое выполнение, рекомендует проверку человеком, делает ее обязательной или отклоняет решение. В материале подчеркивается, что оценка уверенности не должна быть полем, которое агент определяет самостоятельно; она должна вычисляться на основе независимых сигналов, причем пороговые значения следует изначально устанавливать консервативно и снижать только после того, как данные подтвердят безопасность такого шага.
Кроме того, каждое решение следует записывать в дополнительный неизменяемый журнал, содержащий версию модели и промпта, краткое резюме входных данных решения, решение, уверенность и маршрут направления. Исправления не изменяют предыдущие записи; вместо этого они добавляются как новые записи со ссылкой на решение, которое они заменяют. Материал рекомендует хранить хеш чувствительных входных данных вместо необработанных данных и не допускать пропуска записи даже под нагрузкой, поскольку журнал является основным источником истины, а не просто данными мониторинга.
Когда разрешать итеративный цикл?
Методология не отвергает циклы ReAct полностью, но ограничивает их случаями, когда количество и порядок шагов зависят от того, что модель обнаруживает в ходе поиска. Даже при их использовании необходимо устанавливать явный предел числа итераций, список инструментов, разрешенных для каждой возможности, и регистрировать каждый шаг, а также вновь направлять результат через те же барьеры, проверку, оценку уверенности и маршрутизацию. Если предел достигнут до получения результата, дальнейший путь должен вести к проверке человеком, а не к бесконечному циклу.
Редакционный комментарий: настоящее изменение здесь заключается не в выборе лучшей модели, а в переносе центра доверия с «автономности агента» на проектирование границ вокруг него. Такая архитектура не решает автоматически проблему правильности суждений или калибровки уверенности, но делает сбой изолируемым, воспроизводимым и поддающимся проверке. Поэтому она подходит как основополагающий принцип для систем с высокими последствиями, но не как замена постоянному оцениванию или специализированной проверке каждой возможности.