PlanCompiler: A Deterministic Compilation Architecture for Structured Multi-Step LLM Pipelines

1. Il Problema: Fragilità dei Flussi di Lavoro Multi-Step

I Large Language Models (LLM) hanno dimostrato capacità notevoli nella generazione di codice per compiti singoli (es. scrivere una query SQL o una funzione di ordinamento). Tuttavia, diventano fragili quando applicati a flussi di lavoro strutturati multi-step che richiedono:

• Ingestione di dati strutturati.
• Applicazione di una serie di trasformazioni sequenziali.
• Persistenza dei risultati in un database (es. SQL).
• Esportazione di un artefatto finale.

In questi scenari, la generazione di codice "libera" (free-form) tende a fallire a causa di un effetto cumulativo degli errori: un errore in un passaggio (es. un'importazione fantasma o un nome di colonna errato) si propaga attraverso i passaggi successivi, causando fallimenti silenziosi o runtime error. Le soluzioni esistenti (come l'orchestrazione di strumenti) spesso gestiscono i fallimenti a runtime, ma non li prevengono strutturalmente prima dell'esecuzione.

2. Metodologia: Architettura di Compilazione Deterministica

PlanCompiler propone un'architettura che separa rigorosamente la pianificazione dall'esecuzione, trasformando il problema da "generazione di codice" a "compilazione di un grafico validato".

Componenti Chiave:

1. Registro di Nodi Tipizzati (Typed Node Registry):

   • Definisce un insieme chiuso di primitivi computazionali (nodi) come modelli Pydantic.
   • Ogni nodo ha un nome, descrizione, tipi di input/output, parametri richiesti e un percorso verso un template Python pre-scritto.
   • L'LLM non può inventare nuove primitive; può solo selezionare nodi esistenti dal registro e fornire i parametri.

2. Pianificatore (LLM Planner):

   • Riceve la descrizione del compito in linguaggio naturale e il registro dei nodi.
   • Emette un piano strutturato in JSON contenente: lista ordinata di nodi, archi (flusso dati), parametri e flag opzionali.
   • L'LLM agisce solo come selettore di nodi, non come generatore di logica di esecuzione.

3. Validatore Statico (Static Validator):

   • Eseguo 7 controlli deterministici prima che venga generato qualsiasi codice:
     1. Esistenza del nodo (tutti i nodi devono essere nel registro).
     2. Validità degli archi (connessioni corrette).
     3. Compatibilità dei tipi (es. DataFrame -> DataFrame).
     4. Assenza di cicli (ordinamento topologico).
     5. Rilevamento di nodi orfani.
     6. Arità di input (supporto per pipeline single-stream).
     7. Presenza dei parametri richiesti.
   • Se un piano fallisce anche un solo controllo, viene scartato immediatamente. Non c'è modalità "avviso" o riprova automatica.

4. Compilatore Deterministico:

   • Riceve solo piani validati.
   • Utilizza un ordinamento topologico per determinare l'ordine di esecuzione.
   • Assembla il codice Python finale leggendo i template preesistenti da disco (senza manipolazione di stringhe da parte dell'LLM) e inserendo i parametri forniti dall'LLM tramite repr().
   • Genera un unico file app.py eseguibile.

5. Modello di Esecuzione:

   • Esecuzione in un singolo processo Python.
   • Nessuna chiamata LLM aggiuntiva dopo l'emissione del piano.
   • Nessun ciclo di riparazione (repair loop) o ispezione dell'output durante l'esecuzione. Il successo è misurato al primo passaggio (first-pass).

3. Contributi Chiave

1. Rappresentazione Intermedia Tipizzata: Un'architettura che elimina per costruzione importazioni fantasma e derive di nomi/connessioni, spostando il controllo dalla prompting alla validazione strutturale.
2. Protocollo di Valutazione Focalizzato sull'Affidabilità: Una valutazione rigorosa su 300 task che misura il successo al primo passaggio senza correzioni, evidenziando come l'architettura mantenga alta l'accuratezza anche in scenari complessi.
3. Analisi dei Fallimenti Residui: Identificazione e classificazione di due specifiche famiglie di fallimenti residui, dimostrando che gli errori non sono distribuiti casualmente ma localizzati in confini specifici dell'architettura.

4. Risultati Sperimentali

Il sistema è stato valutato su 300 task divisi in 6 set (A-F), che variano per profondità della pipeline, gestione dello schema e persistenza SQL.

• Accuratezza (First-Pass Success Rate):

  • PlanCompiler: 92.67% di successo complessivo (278/300).
    • Set A e B: 100% di successo.
    • Set C: 88%, Set D: 96%.
  • Baseline (GPT-4.1): 67% di successo.
  • Baseline (Claude Sonnet 4.6): 62% di successo.
  • PlanCompiler supera GPT-4.1 di +25.67 punti percentuali e Claude di +30.33 punti.

• Efficienza dei Costi:

  • Il costo totale per l'intero set di 300 task è di $0.356 per PlanCompiler.
  • Confronto: $2.140 per GPT-4.1 e $18.391 per Claude.
  • PlanCompiler è 8.27 volte più efficiente di GPT-4.1 e 76.75 volte più efficiente di Claude per task di successo, grazie all'uso di un modello più piccolo (GPT-4o-mini) per la pianificazione e alla riduzione drastica dei token di output.

• Latenza:

  • PlanCompiler ha una latenza leggermente superiore rispetto a GPT-4.1 (media 9.4s vs ~5.0s) ma significativamente inferiore a Claude (16.1s). Tuttavia, la latenza di PlanCompiler è correlata alla complessità del task, mentre le baseline falliscono spesso senza un aumento prevedibile della latenza.

5. Analisi dei Fallimenti e Significato

L'analisi dei fallimenti è uno degli aspetti più rilevanti del paper:

• Natura dei Fallimenti di PlanCompiler: I 22 fallimenti su 300 sono concentrati in due categorie interpretabili:

  1. Evasione dei Vincoli (59%): Il pianificatore instrada l'aggregazione di dati attraverso un campo SQL "aperto" (QueryEngine) invece che attraverso il nodo Aggregator vincolato, causando un disallineamento nel nome della colonna di output. Questo è un errore semantico, non strutturale.
  2. Confusione sui Tipi di Persistenza (41%): Errori di tipo tra DBHandle, percorsi di file e tabelle materializzate dopo i round-trip SQLite, rilevati dal validatore prima della compilazione.

• Natura dei Fallimenti delle Baseline: Gli errori delle baseline sono distribuiti in modo ampio e imprevedibile (nomi di colonne errati, deriva dello schema, importazioni inesistenti, API deprecate), rendendo difficile la correzione automatica.

Significato e Implicazioni

Il paper dimostra che per i flussi di lavoro strutturati, l'affidabilità può essere trattata come un problema di compilazione piuttosto che di prompting.

• Garanzie Strutturali: Separando la pianificazione dall'esecuzione e imponendo vincoli statici, si eliminano intere classi di errori (es. importazioni fantasma, cicli infiniti) prima che il codice venga eseguito.
• Localizzazione degli Errori: Gli errori residui diventano "interpretabili" e localizzati a specifici confini architetturali (es. il campo SQL non vincolato), offrendo una roadmap chiara per migliorare ulteriormente il sistema.
• Efficienza Economica: L'uso di un modello LLM più piccolo e meno costoso per la sola pianificazione, combinato con un compilatore deterministico, offre un vantaggio economico sostanziale rispetto alla generazione diretta di codice da parte di modelli grandi e costosi.

In conclusione, PlanCompiler offre una via pratica per rendere i sistemi LLM più affidabili, ispezionabili e prevedibili nei contesti di elaborazione dati strutturata, trasformando l'incertezza della generazione libera in un processo deterministico e controllato.