Resumo Técnico: Compilar, Depois Paginar: Programas SOP Executáveis e um Tempo de Execução com Limitação de Capacidade para Agentes de LLM Procedimentais

1. Declaração do Problema

A implantação de agentes de linguagem em ambientes corporativos (ex: bancos, clínicas) exige a adesão estrita a Procedimentos Operacionais Padrão (SOPs). Esses SOPs são caracterizados por fluxos de trabalho de longo horizonte, ramificações condicionais e regras de recusa críticas para a segurança. As práticas dominantes atuais tratam os SOPs como texto não estruturado ("prosa residente"), que compete pela atenção com o diálogo e remove a estrutura executável. Isso leva a modos específicos de falha: verificação de checagens puladas, ações prematuras e recusas incorretas. No benchmark SOPBench, mesmo as melhores configurações falham em atender aos padrões de conformidade, com taxas de erro inaceitáveis para escritórios de conformidade.

O desafio central é transformar SOPs de texto estático em lógica executável que um LLM possa seguir sem perder a flexibilidade necessária para o diálogo dinâmico, garantindo ao mesmo tempo que as restrições de segurança sejam aplicadas sem bloquear o modelo de forma rígida (o que pode causar erros irrecuperáveis quando os objetivos do usuário mudam).

2. Metodologia

Os autores propõem uma arquitetura de dois estágios que separa a representação do SOP de sua execução em tempo de execução.

2.1 Compilação Offline (SOP-para-Programa)

Em vez de alimentar o SOP como linguagem natural, um compilador determinístico offline (livre de LLM) traduz restrições de dependência legíveis por máquina em um programa de pseudocódigo de duas camadas:

• Funções de Processo: Uma função por objetivo do usuário.
• Sub-rotinas de Regras: Cada restrição é pareada com uma receita de verificação específica e um valor de retorno portador de evidência {mantém, evidência}.
• Transformações Chave:
  • Sub-rotinas de Estado: Restrições de múltiplos turnos persistem através dos turnos.
  • Elevação de Portão (Gate Hoisting): Portões de autenticação necessários para verificação são movidos para antes das verificações guardadas.
  • Disciplina de Evidência: Todo veredito está vinculado a uma evidência de ferramenta específica; nenhum veredito é emitido sem ela.
  • Fatoração de Quadro (Frame Factoring): Grandes grupos são modularizados em funções nomeadas.
• Saída: Um programa estruturado onde um resultado falso requerido desvia para um estado de falha antes que a ação do objetivo seja executada.

2.2 Tempo de Execução Guiado por Programa (PG) Online

O programa compilado é executado por uma máquina virtual baseada em pilha que gerencia a janela de contexto:

• Paginação de Pilha (Stack Paging): O tempo de execução mantém uma pilha de chamadas, um cursor e um depósito de variáveis. Ele pagina apenas o quadro ativo (aprox. 570 caracteres) para o contexto do LLM, em vez do programa completo (aprox. 10.000 caracteres).
• Fluxo de Execução: O LLM atua como o executor semântico. Ele conversa, seleciona argumentos de ferramentas, interpreta evidências e relata vereditos. O tempo de execução simbólico lida com a contabilidade (transições de pilha, movimento de cursor, vinculação de variáveis).
• Aplicação Suave (Soft Enforcement): O tempo de execução gerencia a atenção, não as permissões. Desvios são possíveis, mas observáveis na trilha de auditoria da pilha. Essa flexibilidade permite mudanças de objetivo, mas depende da capacidade do modelo de executar fielmente o quadro local.

2.3 Design Experimental

O estudo utiliza um design de três braços no SOPBench (Domínio Bancário e outros seis) através de seis modelos de capacidades variadas:

1. Offtext: Texto do SOP verbalizado oficial (baseline).
2. Flat: Texto do programa compilado completo residente em cada turno (isola a representação).
3. PG: Programa compilado executado com o tempo de execução de paginação de pilha (isola o tempo de execução).
4. Full-Cursor (Ablação): Primeiro o quadro ativo, mas o programa completo retido abaixo (isola a saliência do quadro ativo vs. visibilidade global).

3. Principais Contribuições

1. Compilador SOP-para-Programa & Tempo de Execução com Paginação de Pilha: Um sistema que torna os procedimentos executáveis e auditáveis, reduzindo a carga de contexto de ~10k para ~570 caracteres por turno enquanto preserva a estrutura lógica.
2. Estudo de Atribuição com Limitação de Capacidade: Uma análise de seis modelos e sete domínos demonstrando que os benefícios desta abordagem são estritamente dependentes de capacidade.
3. Desentrelace de Mecanismos: Separação de contabilidade genérica, saliência do quadro ativo e visibilidade seletiva, juntamente com diagnósticos para reconstrução de estado e densidade de atenção.
4. Regra de Implantação: Uma diretriz prática: "Compile primeiro; habilite a paginação de quadro ativo apenas após um teste de disciplina de nível de modelo."

4. Resultados

4.1 Representação vs. Tempo de Execução

• Compilação (Flat vs. Offtext): A representação compilada nunca prejudica significativamente o desempenho. Ela gera ganhos significativos (+16,0 pontos no Banco) onde a prosa oficial tem desempenho inferior.
• Tempo de Execução (PG vs. Flat): O efeito do tempo de execução é limitado pela capacidade.
  • Modelos Fortes: Dois modelos fortes (DeepSeek-V4-Flash e Qwen3.7-Plus) mostram ganhos independentes e positivos em sete domínios (ex: 58:19 e 75:31 pares discordantes a favor de PG). No domínio Bancário, o DeepSeek-V4-Flash melhorou de 86,4% (Flat) para 92,8% (PG) com 100% de correção de recusa.
  • Modelos Fracos: Modelos fracos (ex: GPT-4o-mini, Qwen2.5-7B) são significativamente prejudicados pelo tempo de execução, perdendo 14–26 pontos no Banco.

4.2 Análise de Mecanismo

• Saliência do Quadro Ativo: Uma ablação (Full-Cursor) que retém o programa completo, mas destaca o quadro ativo, recupera a maior parte do ganho de recusa dos modelos fortes. Isso sugere que o principal benefício é tornar a instrução atual saliente, não esconder o contexto global.
• Disciplina de Estado vs. Reconstrução:
  • Reconstrução: Todos os modelos, incluindo os prejudicados pelo tempo de execução, podem reconstruir o estado quando explicitamente testados (pontuações próximas ao teto).
  • Disciplina: O "portão" é a disciplina de estado espontânea. Modelos fracos falham porque sobre-verificam ou continuam as checagens após o objetivo ser alcançado ( $\Delta R^2$ positivo em chamadas pós-objetivo), enquanto modelos fortes param naturalmente.
  • Atenção: Modelos fortes alocam atenção ao quadro ativo proporcional ao seu tamanho; modelos fracos subalocam atenção ao quadro ativo quando este faz parte de um contexto maior.

4.3 Conteúdo vs. Formato

• Formato: Ressintetizar o texto oficial em formato de código ajuda modelos fortes (+14,4 pontos), mas prejudica modelos fracos (-12,8 pontos).
• Conteúdo: Adicionar receitas de verificação e disciplina de evidência ajuda modelos fortes significativamente, mas não mostra ganho significativo para modelos fracos.
• Conclusão: O formato "código" não é universalmente benéfico; é uma ferramenta para modelos que já possuem a disciplina para seguir instruções estruturadas.

5. Significância e Alegações

O artigo alega que a principal barreira para agentes de seguimento de SOP confiáveis não é a falta de informação, mas a representação e a disciplina espontânea do modelo em executar essa representação.

• Rejeição de "Mais Scaffolding é Melhor": Os resultados mostem que adicionar orientação de tempo de execução complexa (paginação) a modelos fracos degrada o desempenho.
• A Limitação de Capacidade (The Capability Gate): A eficácia do tempo de execução PG é estritamente limitada pela capacidade do modelo de manter a disciplina de estado. O sistema não "conserta" modelos fracos; ele amplifica o desempenho dos modelos fortes enquanto expõe as limitações dos fracos.
• Orientação Prática:
  1. Compile primeiro: Converta SOPs para pseudocódigo executável para melhorar a estrutura e reduzir o ruído de contexto.
  2. Verifique a disciplina: Só habilite a paginação de quadro ativo (orientação de tempo de execução) após verificar se o modelo consegue seguir instruções sem a ajuda estrutural do tempo de execução.
  3. Aplicação Suave: O sistema depende da observabilidade (trilhas de auditoria) em vez de bloqueio rígido, preservando a flexibilidade para interações dinâmicas com o usuário.

Os autores concluem que, embora sua abordagem alcance taxas de aprovação de 92,8% e 100% de correção de recusa no domínio Bancário para modelos fortes, ela não é uma solução universal. Requer um "teste de disciplina de nível de modelo" antes da implantação para evitar prejudicar modelos mais fracos.