Structured Context Engineering for File-Native Agentic Systems: Evaluating Schema Accuracy, Format Effectiveness, and Multi-File Navigation at Scale

Título: Engenharia de Contexto Estruturado para Sistemas Agentes Nativos de Arquivos

Subtítulo: Avaliação de Precisão de Esquema, Eficácia de Formato e Navegação Multi-Arquivo em Escala

1. O Problema

Com o surgimento de agentes de Grandes Modelos de Linguagem (LLMs) capazes de operar sistemas externos através de interfaces programáticas, surge uma lacuna crítica: como os praticantes devem estruturar o contexto que esses agentes consomem?

Diferente de tarefas de recuperação de informação ou perguntas e respostas, tarefas agênicas exigem que o LLM compreenda profundamente esquemas, relacionamentos, restrições e significado semântico para gerar operações corretas. A indústria está migrando de abordagens puras de Retrieval-Augmented Generation (RAG) ou injeção direta de contexto no prompt para camadas semânticas baseadas em arquivos. Neste paradigma, os agentes leem documentos estruturados (esquemas de banco de dados, especificações de API) usando ferramentas nativas de arquivo (como grep e read).

O artigo investiga se essa abordagem "nativa de arquivo" é superior à engenharia de prompts tradicional, como o formato do arquivo (YAML, JSON, etc.) afeta a performance e como o sistema escala para milhares de tabelas.

2. Metodologia

O estudo foi sistemático e abrangente, envolvendo 9.649 experimentos com as seguintes configurações:

• Modelos: 11 modelos de LLM divididos em três tiers de capacidade:
  • Frontier: Claude Opus, GPT-5, Gemini Pro.
  • Frontier Lab (Otimizados por Custo): Claude Haiku, GPT-mini, Gemini Flash.
  • Open Source: DeepSeek, Kimi, Llama, Qwen.
• Arquiteturas Comparadas:
  1. Agente de Arquivo: O agente usa ferramentas grep e read para recuperar informações de esquema sob demanda.
  2. Linha de Base (Prompt): O esquema completo (~6.000 tokens) é injetado diretamente no sistema, sem acesso a ferramentas.
• Formatos de Representação de Esquema:
  • YAML: Estrutura hierárquica, amigável ao grep.
  • Markdown: Estilo de documentação com linguagem natural.
  • JSON: Parseável por máquina, mas verboso.
  • TOON (Token-Oriented Object Notation): Um formato compacto personalizado (~25% menor que YAML) com palavras-chave abreviadas.
• Escalas e Complexidade:
  • Esquemas variando de 10 a 10.000 tabelas.
  • Consultas SQL derivadas do benchmark TPC-DS, classificadas em 5 níveis de complexidade (L1: busca direta a L5: raciocínio multi-etapa).
• Métrica de Avaliação: Similaridade de Jaccard entre o conjunto de resultados gerado pelo agente e a verdade fundamental (ground truth), com um limiar de sucesso de $\ge 0.9$.

3. Principais Contribuições

O artigo oferece cinco contribuições principais baseadas em evidências empíricas:

1. Estudo Sistemático: A maior avaliação comparativa de engenharia de contexto para agentes, cobrindo múltiplos modelos, formatos e escalas.
2. Dependência do Modelo na Arquitetura: Demonstração de que a arquitetura de recuperação de arquivo beneficia modelos de ponta, mas pode prejudicar modelos open source.
3. Insignificância Agregada do Formato: Evidência de que, em média, o formato não altera a precisão, embora existam sensibilidades específicas por modelo.
4. Escalabilidade Validada: Confirmação de que agentes nativos de arquivo podem navegar em esquemas de 10.000 tabelas com alta precisão usando particionamento por domínio.
5. Descoberta do "Grep Tax": Identificação de um fenômeno onde formatos compactos ou novos podem gerar overhead de tokens e chamadas de ferramentas devido à densidade de saída do grep e à falta de familiaridade do modelo com padrões de busca.

4. Resultados Chave

R1: Arquitetura vs. Engenharia de Prompt

• Modelos Frontier: A recuperação nativa de arquivos melhorou a precisão em +2,7% (p=0.029) em comparação com prompts completos.
• Modelos Open Source: A recuperação nativa de arquivos resultou em uma queda de precisão de -7,7% (p<0.001) em média. Modelos como Qwen e Llama Maverick sofreram quedas drásticas (-21,9% e -13,9%, respectivamente), enquanto outros (Kimi, Llama Scout) foram neutros.
• Conclusão: A escolha da arquitetura deve ser baseada na capacidade do modelo, não em uma "melhor prática" universal.

R2: Efeito do Formato na Precisão

• Não houve diferença estatisticamente significativa na precisão agregada entre YAML, Markdown, JSON e TOON (p=0.484).
• Sensibilidade Individual: Modelos open source mostraram sensibilidades maiores a formatos (variação de 9,8% a 20,1% entre formatos), enquanto modelos frontier foram mais robustos (variação de 1,6% a 5,4%).
• Preferências: YAML foi o melhor para 5 modelos, Markdown para 4, JSON para 2 e TOON para 0.

R3: A Capacidade do Modelo é o Fator Dominante

• Existe uma lacuna de 21 pontos percentuais na precisão entre modelos Frontier (86,0%) e Open Source (64,6%).
• Essa diferença supera qualquer efeito de formato ou arquitetura.
• À medida que a complexidade da consulta aumenta (L1 para L5), modelos open source degradam-se rapidamente (caindo para 27% no L5), enquanto modelos Frontier mantêm desempenho sólido (64% no L5).

R4: Escalabilidade (10.000 Tabelas)

• Esquemas de arquivo único mantiveram precisão quase perfeita até 1.000 tabelas.
• Para 10.000 tabelas, o uso de particionamento por domínio (agrupando ~250 tabelas por domínio) permitiu manter alta precisão de navegação, mantendo o contexto por consulta limitado independentemente do tamanho total do esquema.

R5: Eficiência e o "Grep Tax"

• Eficiência de Tokens: YAML foi o formato mais eficiente em tokens.
• O Fenômeno "Grep Tax":
  • Markdown: Consome mais tokens porque o grep retorna linhas inteiras com formatação de tabela (separadores, alinhamentos), aumentando a densidade de tokens por linha.
  • TOON: Embora o arquivo seja 25% menor, o TOON consumiu 38% mais tokens que o YAML em média. Isso ocorre porque:
    1. Densidade: Cada linha contém mais conteúdo de esquema.
    2. Familiaridade de Padrão: Modelos menos familiarizados com a sintaxe TOON (palavras-chave abreviadas) tentam padrões de busca incorretos (ex: tentar sintaxe DDL ou JSON) antes de encontrar o padrão correto, gerando chamadas de ferramenta extras e retrabalho.
  • Este efeito é altamente dependente do modelo; modelos mais avançados (Opus) lidam melhor com a densidade, enquanto modelos menores (Haiku) sofrem com o ciclo de tentativas de padrão.

5. Significado e Recomendações Práticas

O estudo desafia a suposição de que a recuperação de contexto baseada em arquivos é sempre superior. As recomendações para praticantes são:

1. Alinhe Arquitetura ao Modelo:
   • Use Agentes de Arquivo para modelos Frontier (Claude Opus, GPT-5, Gemini Pro).
   • Use Engenharia de Prompt (injeção direta) para modelos Open Source, a menos que validado especificamente.
2. Escolha de Formato:
   • Priorize YAML para eficiência de tokens e compatibilidade com grep.
   • Evite formatos compactos personalizados (como TOON) sem fornecer exemplos de padrões de busca (grep) no prompt, pois isso pode gerar custos ocultos de tokens.
   • Use Markdown apenas para legibilidade humana, sabendo que pode aumentar o custo de tokens em agentes baseados em arquivos.
3. Escala Empresarial:
   • Para esquemas massivos (>1.000 tabelas), implemente particionamento por domínio para manter a navegação eficiente.
4. Foco na Capacidade:
   • Investir na capacidade do modelo (escolher um modelo mais inteligente) tem um impacto muito maior na precisão do que otimizar o formato do arquivo.

Conclusão

O artigo estabelece que a engenharia de contexto para agentes não é uma solução única. A eficácia depende criticamente da interação entre a capacidade do modelo, a arquitetura de recuperação e o formato de dados. A descoberta do "Grep Tax" alerta para os riscos ocultos de formatos compactos em sistemas de agentes, sugerindo que a simplicidade do arquivo não se traduz necessariamente em eficiência de execução.