Resumo Técnico: TraceCompiler

Definição do Problema

Agentes de modelos de linguagem com uso de ferramentas (LLM) frequentemente redescobrem procedimentos que já executaram, incorrendo em custos significativos de uso de tokens e latência. Uma única intenção recorrente (ex: solicitar um pagamento ou listar ingressos) frequentemente dispara um traço contendo uma mistura de estrutura reutilizável (ferramentas necessárias, dependências de dados reais, configuração estável) e histórico de execução acidental (tentativas de reexecução, buscas de descoberta de esquema, ordenação estilística e resolução repetida de fatos).

Abordagens atuais, como resumir traços como orientação textual, ainda exigem que o LLM reinterprete o procedimento em tempo de execução. A descoberta de processos convencional é insuficiente porque a ordem observada de eventos não implica dependência; chamadas consecutivas podem resultar de operações independentes, tentativas falhas ou fluxo de dados. Além disso, os logs implantados frequentemente sofrem de observabilidade parcial, registrando argumentos mas não os outputs das ferramentas, tornando impossível verificar dependências ao cruzar os outputs dos produtores com os inputs dos consumidores.

O desafio central é compilar traços de agentes ruidosos e parcialmente observáveis em fluxos de trabalho executáveis e majoritariamente determinísticos, onde decisões apoiadas por evidências são removidas da responsabilidade de tempo de execução do modelo, deixando apenas escolhas genuinamente abertas para o LLM.

Metodologia

O TraceCompiler é um sistema guiado por habilidades que minera clusters de traços ruidosos e os compila em fluxos de trabalho tipados. O pipeline consiste nas seguintes etapas:

1. Descoberta de Intenção e Agrupamento (Clustering)

As conversas são incorporadas como documentos combinando a requisição inicial e o raciocínio intercalado com chamadas de ferramentas. A aglomeração por limiar (distância de cosseno, ligação média) agrupa os traços em clusters de intenção. O sistema prioriza a sub-aglomeração conservadora para evitar a contaminação de intenções distintas. Passagens prévias idempotentes detectam e separam conversas que misturam intenções não relacionadas.

2. Normalização e Denoising Comportamental

Os traços brutos são normalizados para um vocabulário canônico app.action. As ações são rotuladas como:

• Essencial: Necessária para a tarefa.
• Recuperação/Exploratória/Redundante: Mantida para análise, mas potencialmente removível.
• Saída Morta (Dead Output): Ações cujos outputs nunca são consumidos downstream (ex: buscas de esquema).
• Tentativa vs. Variação: O sistema distingue entre ruído (ajustes de argumentos convergindo para um sucesso) e fan-out genuíno (argumentos sistematicamente distintos, ex: buscas por música específica). Loops de paginação são detectados via contadores literais.

3. Verificação de Dependência ao Nível de Argumento

Esta é a inovação central. Uma aresta $a \to b$ é admitida como uma dependência rígida apenas se:

1. Um valor no argumento de $b$ é rastreável ao output de $a$.
2. Exclusão: Toda alternativa de origem para esse valor é excluída (enunciados do usuário, contexto estático, padrões de ferramentas e outputs de todas as outras chamadas precedentes).

Se uma origem alternativa plausível existe (ex: dois produtores do mesmo tipo), a aresta é rebaixada para suspeita e não impõe restrição de ordenação. Isso evita que o compilador infira falsas dependências baseadas apenas em adjacência.

4. Classificação de Proveniência e Contexto Estático

Os vínculos são classificados em:

• Constante: Estável entre traços (resolvido em tempo de compilação).
• Input do Usuário: Resolvido em tempo de execução.
• Aresta de Cópia (Copy Edge): Um valor provado ter origem em um produtor específico.
• Transformação: Transformações determinísticas.
• LLM/Dinâmico: Vínculos semânticos genuínos que exigem resolução do modelo em tempo de execução.

O compilador é especificado para realizar a injeção de contexto estático limitada ao escopo, resolvendo valores estáveis no build e proibindo as ferramentas de descoberta para esses valores em tempo de execução. No entanto, esta funcionalidade não foi exercitada nos resultados relatados; nenhum estudo de caso reportou um valor injetado, e o elemento de design permanece aguardando evidências. Se um efeito colateral irreversível for subdeterminado (ex: a direção de uma mutação é ambígua), o compilador abstrai-se e não emite um grafo executável, escalando a requisição em vez disso.

5. Compilação e Tempo de Execução

A análise é compilada em uma definição executável (DAG) com nós tipados (TOOL, TRANSFORM, DECISION, LLM, HUMAN). O roteador de runtime despacha requisições para fluxos de trabalho compilados se eles coincidirem com um limiar de similaridade conservador; requisições não correspondentes retornam ao agente geral.

O motor do compilador (v1) é implementado como uma habilidade de LLM versionada — um pacote de instruções carregado por um agente — em vez de um modelo treinado. Isso permite auditoria adversarial e revisão rápida sem retreinamento.

Principais Contribuições

1. Formulação: Enquadrar o reuso recorrente de traços de agentes como um problema de compilação sobre estrutura de workflow, proveniência de parâmetros e decisões residuais de LLM sob observabilidade parcial.
2. Pipeline: Um pipeline não supervisionado completo para descoberta de intenção, denoising comportamental, verificação de dependência, classificação de proveniência e geração de workflow executável.
3. Regra de Dependência: Uma regra formalizada e conservadora de dependência ao nível de argumento que admite arestas apenas via exclusão de origens alternativas. Introduz tuplas de evidência explícitas e uma relação de "suspeita" para casos ambíguos.
4. Avaliação: Avaliação contra duas verdades fundamentais (T1 e AppWorld) que não compartilham mecanismos, comparando contra baselines baseados em ordem e recorrência.
5. Estudos de Caso: Demonstração de compilação bem-sucedida (pedido de dinheiro no Venmo) e recusa de compilação (Spotify/Todoist) quando efeitos colaterais irreversíveis estão subdeterminados.

Resultados

Precisão de Dependência

• Corpus T1 (Divisão de Treino): A regra mecanizada alcançou 0.928 de precisão e 0.943 de recall em 15.775 arestas de def–use. Isso supera significativamente os baselines baseados em adjacência (0.711 F1) e medidas de segue-diretamente baseadas em frequência (0.712 F1).
  • Ressalva: Estudos de ablação revelam que, neste corpus específico, o teste de exclusão é quase nulo porque cada relação tem pelo menos um candidato produtor. Consequentemente, a precisão reportada depende fortemente da recência (selecionando o sobrevivente mais recente) entre os candidatos sobreviventes, em vez do teste de exclusão completo. A disciplina de exclusão é exercida pela habilidade de LLM, não pela regra mecanizada, devido às limitações do corpus.
• Execução de Skill Cega: Em um subconjunto de 250 arestas do T1, a habilidade de LLM alcançou 0.992 de precisão/recall em uma única execução.
• AppWorld: Contra uma referência de replay (que recupera valores mascarados), a regra alcançou 0.993 de precisão em 563 arestas de tokens. Isso serve como uma verificação de autoconsistência em vez de uma validação independente, pois a construção da referência compartilha a mesma premissa (preferir tokens da mesma aplicação) que a regra sendo testada. Além disso, este braço limita a atribuição apenas a tokens de sessão e não valida a recuperação de fluxos de identificadores não-token.

Compilação e Execução de Workflow

• Intenção Venmo: Compilou 34 chamadas de API observadas (incluindo retentativas e buscas de esquema) em 11 chamadas de runtime. O workflow passou em 15 de 21 testes de estado em instâncias retidas. As 6 falhas ocorreram porque o ramo específico necessário para a instância retida nunca foi observado no conjunto de treinamento, fazendo com que o sistema escalasse em vez de agir.
• Intenção Spotify/Todoist: O compilador recusou corretamente a compilação desta intenção porque a direção da mutação (adicionar vs. remover) estava subdeterminada pelos traços, representando um efeito colateral irreversível.
• Redução de Chamadas: Em 56 cenários do AppWorld, a fração mediana de chamadas removíveis (descoberta de esquema e repetições idênticas de bytes) foi de 51.4%.

Descoberta de Intenção

No T1, o agrupamento alcançou 0.930 de pureza sobre os diálogos cobertos, mas um baixo Índice de Rand Ajustado (0.235) contra os rótulos de referência. Isso indica que o sistema descobre uma partição mais fina que os rótulos de referência (subdividindo domínios em tarefas de nível de template) em vez de classificar incorretamente.

Significância e Alegações

O artigo afirma que a adjacência observada não implica dependência. Ao aplicar uma disciplina de evidência que exige a exclusão de origens alternativas, o TraceCompiler pode compilar traços ruidosos em fluxos de trabalho determinísticos que reduzem chamadas de ferramentas e invocações de LLM em tempo de execução.

• Segurança: O sistema prioriza a segurança sobre a completude. Ele abstém-se de compilar workflows onde ações irreversíveis estão subdeterminadas, prevenindo a execução de procedimentos especulativos inseguros.
• Eficiência: Embora o artigo meça a redução de chamadas (ex: 34 $\to$ 11 chamadas), ele explicitamente não alega eficiência líquida porque os custos de compilação offline não foram medidos. A premissa econômica é que um modelo capaz pode amortizar o custo de análise ao longo de execuções repetidas.
• Limitações: Os autores reconhecem que a avaliação atual depende de dados sintéticos ou gerados por simuladores. A disciplina de "exclusão" é exercida pela habilidade de LLM, mas não totalmente pela regra mecanizada devido às limitações do corpus (falta de tokens de isca). O sistema atualmente carece de mecanismos de versionamento de workflow e invalidação para deriva de API.

O trabalho estabelece que traços observacionais delimitam reivindicações de necessidade tão estritamente quanto delimitam reivindicações de dependência, e que os instrumentos usados para testar os workflows compilados (harnesses de execução) são, eles próprios, procedimentos de inferência que requerem validação.