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

Titolo: Ingegneria del Contesto Strutturato per Sistemi Agentici "File-Native"

Sottotitolo: Valutazione dell'accuratezza dello schema, dell'efficacia del formato e della navigazione multi-file su larga scala.

1. Il Problema

Con l'ascesa degli agenti basati su Large Language Models (LLM) capaci di operare su sistemi esterni, sorge una domanda fondamentale: come dovrebbero gli agenti comprendere i sistemi che devono attivare?
A differenza dei semplici compiti di recupero informazioni, i task agenziali richiedono una profonda comprensione degli schemi, delle relazioni, dei vincoli e del significato semantico per generare operazioni corrette (es. query SQL).
Attualmente, i praticanti mancano di linee guida empiriche su come strutturare il contesto che questi agenti consumano. Mentre si sta passando da approcci puramente basati su prompt a strati semantici basati su file (documenti strutturati letti tramite strumenti nativi come grep e read), non è chiaro se questo approccio migliori le prestazioni, quale formato sia ottimale e come si comporti su scale massive (migliaia di tabelle).

2. Metodologia

Lo studio presenta un'analisi sistematica basata su 9.649 esperimenti condotti su:

• 11 Modelli LLM: Divisi in tre livelli di capacità (Frontier, Frontier Lab, Open Source), inclusi Claude Opus/Haiku, GPT-5, Gemini, DeepSeek, Llama, Kimi e Qwen.
• 4 Formati di Rappresentazione:
  • YAML: Struttura gerarchica, amichevole per grep.
  • Markdown: Stile documentale con linguaggio naturale.
  • JSON: Leggibile dalle macchine, ma verboso.
  • TOON (Token-Oriented Object Notation): Un formato compatto personalizzato (~25% più piccolo di YAML).
• 2 Architetture di Contesto:
  1. File Agent: L'agente usa strumenti nativi (grep, read) per recuperare informazioni dallo schema su richiesta.
  2. Prompt Baseline: L'intero schema (circa 6.000 token) è inserito direttamente nel prompt di sistema senza accesso agli strumenti.
• Task: Generazione di SQL (Text-to-SQL) basata sul benchmark TPC-DS, con query di complessità variabile (L1: lookup diretto, L5: ragionamento multi-step).
• Scala: Schemi da 10 a 10.000 tabelle, testando anche strategie di partizionamento per gli scenari enterprise.

3. Contributi Chiave

Il paper offre cinque contributi principali:

1. Studio Sistematico: La più ampia valutazione empirica finora su architetture file-native vs prompt engineering su scala enterprise.
2. Dipendenza dal Modello: Dimostrazione che l'efficacia dell'architettura "file-native" dipende criticamente dalla capacità del modello.
3. Neutralità del Formato (Aggregate): Evidenza che il formato non influenza significativamente l'accuratezza aggregata, ma rivela sensibilità specifiche per modello.
4. Scalabilità: Validazione che la navigazione dello schema può scalare fino a 10.000 tabelle mantenendo alta accuratezza tramite partizionamento per dominio.
5. Il Fenomeno "Grep Tax": Identificazione di un sovraccarico di token (costo) per formati compatti o nuovi, causato dalla densità di output e dalla familiarità del modello con i pattern di ricerca.

4. Risultati Principali

A. Architettura: File-Native vs Prompt Engineering (RQ1)

• Modelli Frontier (es. Claude Opus, GPT-5): L'approccio file-native migliora l'accuratezza del +2,7% rispetto al prompt engineering (p=0.029).
• Modelli Open Source: Mostrano risultati misti o negativi. In aggregato, l'approccio file-native riduce l'accuratezza del -7,7% (p<0.001). Modelli come Qwen e Llama Maverick hanno sofferto significativamente (-21,9% e -13,9%), mentre altri (Kimi, Llama Scout) non hanno mostrato differenze.
• Conclusione: L'architettura non è universale; i modelli avanzati beneficiano della retrieval on-demand, mentre i modelli open source meno capaci tendono a fallire con la navigazione file.

B. Effetto del Formato (RQ2)

• Non esiste una differenza significativa nell'accuratezza aggregata tra YAML, Markdown, JSON e TOON (p=0.484).
• Tuttavia, i modelli individuali mostrano sensibilità specifiche. I modelli open source hanno una variazione di accuratezza tra i formati molto più ampia (9-20%) rispetto ai modelli frontier (1-5%).
• Efficienza dei Token: YAML è il formato più efficiente in termini di token. TOON, nonostante sia più piccolo in file, consuma più token durante l'esecuzione a causa della densità dell'output di grep e della necessità di più chiamate agli strumenti.

C. Capacità del Modello (RQ3)

• La capacità del modello è il fattore dominante. Esiste un divario di 21 punti percentuali di accuratezza tra i modelli Frontier (86%) e Open Source (64,6%).
• Questo divario supera di gran lunga qualsiasi effetto di formato o architettura.
• I modelli Frontier mantengono prestazioni elevate (64%) anche nelle query più complesse (L5), mentre i modelli open source crollano drasticamente (27%).

D. Scalabilità (RQ4)

• La navigazione file-native scala efficacemente fino a 10.000 tabelle se si utilizza un'architettura di partizionamento per dominio (circa 250 tabelle per dominio).
• Questo approccio mantiene il contesto per query entro limiti gestibili, indipendentemente dalla dimensione totale dello schema.

E. Efficienza e "Grep Tax" (RQ5)

• È stato identificato il fenomeno del "Grep Tax": formati compatti o nuovi (come TOON) possono generare un sovraccarico di token durante l'esecuzione.
• Cause:
  1. Densità del Token: Una singola riga di grep in TOON contiene più informazioni rispetto a YAML, aumentando il costo per ogni hit.
  2. Familiarità del Pattern: I modelli faticano a riconoscere i keyword compatti di TOON (es. TABLE, COL) rispetto a pattern standard (DDL, JSON), portando a cicli di tentativi falliti e chiamate ripetute agli strumenti.
• I modelli Frontier gestiscono meglio questo rumore, mentre i modelli open source possono richiedere molte più chiamate agli strumenti.

5. Significato e Raccomandazioni Pratiche

Il paper ribalta l'assunzione comune che esistano "migliori pratiche" universali per l'ingegneria del contesto. Le raccomandazioni per i praticanti sono:

1. Adattare l'architettura al modello:
   • Per modelli Frontier: Utilizzare l'architettura File Agent (retrieval on-demand).
   • Per modelli Open Source: Preferire il Prompt Engineering (schema completo nel prompt) o validare attentamente prima di adottare l'approccio file-native.
2. Scelta del Formato:
   • Non ottimizzare per l'accuratezza (che è simile), ma per l'efficienza operativa.
   • YAML è raccomandato per l'efficienza dei token e la compatibilità con grep.
   • Evitare formati compatti (come TOON) senza fornire istruzioni specifiche nel prompt per guidare il comportamento di grep.
3. Scalabilità Enterprise:
   • Per schemi di grandi dimensioni, implementare il partizionamento per dominio per mantenere il contesto gestibile.
4. Investire nella Capacità del Modello:
   • Il salto di qualità tra modelli di diverse capacità è il fattore più critico per il successo del sistema.

Conclusione

Questa ricerca fornisce linee guida basate sull'evidenza per il deployment di agenti LLM su sistemi strutturati. Dimostra che le decisioni architetturali devono essere tailorate (cucite su misura) in base alla capacità del modello specifico, piuttosto che basarsi su ipotesi generali. L'ingegneria del contesto non è solo una questione di formato, ma di interazione dinamica tra capacità del modello, strategia di retrieval e gestione della densità informativa.