Modelo propõe, aplicação executa: uma fronteira para conter erros de agentes

O primeiro artigo de uma série do Stack Overflow Blog propõe confinar o julgamento de um LLM a uma etapa de um fluxo conhecido e testável.[13] O agente entrega uma proposta estruturada; um componente separado é o único autorizado a mudar o estado de negócio após validações e aprovações.[13] A ideia não é tornar o modelo determinístico. É impedir que uma recomendação errada vire uma ação por falta de fronteira.

O que muda para quem desenvolve

No desenho descrito, a aplicação controla coordenação, identidade, locatário, políticas e regras de negócio.[13] Agentes não criam cadeias ocultas de chamadas entre si, e a saída do modelo permanece não confiável até passar por controles independentes.[13]

Minha análise é que isso permite testar o sistema em dois planos. Um verifica se a proposta faz sentido. O outro verifica se qualquer proposta, inclusive uma ruim, consegue ultrapassar permissões e regras. A qualidade do primeiro não pode ser usada como substituta da segurança do segundo.

O artigo recomenda contratos explícitos, como JSON Schema ou chamadas tipadas, com validação e limite de tentativas.[13] Também ressalta que uma saída correta no esquema ainda pode estar errada no mérito.[13] Portanto, JSON válido deve ser requisito de entrada do executor, não selo de aprovação da decisão.

Como aplicar

Imagine uma automação que prepara alterações de cadastro. Proponho dois componentes: um produz a alteração pretendida e sua justificativa; outro verifica identidade, campos permitidos, regras e aprovação antes de gravar. O primeiro não recebe credenciais de escrita.

Defina um objeto de proposta com alvo, operação, campos e evidências. Não aceite que um campo preenchido pelo agente, como aprovado, determine autorização. A aplicação deve calcular esse estado a partir de política e aprovação reais.

Use um modelo simulado nos testes de encadeamento e force propostas malformadas, alvo fora do escopo e mudanças proibidas. O critério de aceitação é que nenhuma alcance a escrita. Depois teste qualidade semântica com um conjunto separado, pois o simulador não mede a qualidade do LLM real.

Para a trilha de decisão, registre versões de modelo e instruções, proposta, verificações e encaminhamento. O artigo sugere registros canônicos imutáveis e uso do hash da entrada para evitar armazenamento indiscriminado de dados sensíveis.[13] Defina ainda como corrigir uma decisão preservando o registro anterior.

Cuidados e limites

A repetibilidade mostrada com um gateway simulado não garante respostas idênticas de um LLM real.[13] Um segundo modelo usado como juiz também não transforma julgamento em prova determinística.[13]

O texto aceita ciclos ReAct como exceção, exigindo teto de passos, ferramentas permitidas, registro de iterações e as mesmas verificações finais.[13] Minha recomendação é começar com propostas sem execução automática e ampliar autoridade apenas com evidência. Trata-se de um desenho de referência, não de um sistema completo certificado para uso regulado.[13] A fronteira precisa existir nas permissões efetivas, não somente nas instruções dadas ao agente.

Fonte

[13] Fonte: Stack Overflow Blog