Improved Generalized Planning with LLMs through Strategy Refinement and Reflection

1. Il Problema

Il lavoro affronta la sfida della pianificazione generalizzata (Generalized Planning) utilizzando i Grandi Modelli Linguistici (LLM).

• Contesto: A differenza della pianificazione classica che risolve un singolo compito, la pianificazione generalizzata mira a generare un piano unico (spesso un programma) che sia valido per tutti i possibili compiti all'interno di un dominio PDDL specifico, indipendentemente dalla dimensione del problema o dal numero di oggetti.
• Limitazioni dello stato dell'arte: Il lavoro precedente di Silver et al. (2024) ha proposto un approccio in tre fasi: 1) Generazione di un riepilogo del dominio in linguaggio naturale (NL), 2) Generazione di una "strategia" in NL, 3) Implementazione della strategia in codice Python.
• Il collo di bottiglia: L'approccio di Silver et al. fallisce spesso perché la strategia in linguaggio naturale è troppo ambigua o errata. Se la strategia di base è sbagliata, la generazione del codice Python eredita e amplifica questi errori. Inoltre, non esiste un meccanismo per validare o correggere la strategia prima di passare alla generazione del codice, rendendo il processo di debug inefficiente e costoso.

2. Metodologia Proposta

Gli autori introducono un framework migliorato che tratta la generazione della strategia come un sottoproblema autonomo e critico, introducendo tre innovazioni principali (illustrate nella Figura 1 del paper):

A. Generazione e Validazione di Strategie in Pseudocodice

Invece di generare una strategia in linguaggio naturale puro, l'LLM viene istruito a produrre una strategia in pseudocodice.

• Vantaggio: Lo pseudocodice è più strutturato e vicino alla sintassi del codice finale, riducendo l'ambiguità.
• Validazione Automatica (Debug a livello di strategia): Poiché lo pseudocodice non è eseguibile direttamente, gli autori utilizzano un approccio indiretto:
  1. L'LLM riceve lo pseudocodice e un compito di debug (in formato NL) e deve generare un piano PDDL seguendo quella strategia.
  2. Il piano generato viene validato da un validatore simbolico (VAL).
  3. Se il piano è errato, viene generato un feedback.

B. Fase di Riflessione (Reflection)

Prima di correggere direttamente lo pseudocodice o il codice Python, l'LLM viene sottoposto a una fase di riflessione.

• L'LLM analizza il feedback dell'errore e deve identificare:
  1. Quale parte specifica della strategia (o del codice) ha causato l'errore.
  2. Il motivo logico per cui quella parte è inadeguata.
• Solo dopo questa analisi, l'LLM viene invitato a revisionare lo pseudocodice o il codice. Questo passo imita tecniche di "Self-Refine" e migliora significativamente la capacità di debugging.

C. Generazione Multipla di Varianti di Codice

Nella fase di generazione del codice Python finale:

• Invece di generare un singolo programma, l'LLM produce multiple varianti del programma.
• Le varianti sono ottenute modificando casualmente l'ordine degli oggetti e dei fatti negli input del prompt (mantenendo la temperatura a 0 e il decoding greedy per garantire coerenza logica, ma variando il contesto di presentazione).
• Vengono eseguiti debug su tutte le varianti e viene selezionato il programma con le migliori prestazioni sui compiti di debug.

3. Contributi Chiave

1. Separazione e Raffinamento della Strategia: Trasformare la generazione della strategia in un task separato con validazione automatica tramite pseudocodice, permettendo di correggere errori logici prima della codifica.
2. Integrazione della Riflessione: L'introduzione di un passo di riflessione esplicito sia per la strategia che per il codice, che costringe l'LLM a spiegare l'errore prima di correggerlo, aumentando l'accuratezza delle correzioni.
3. Selezione delle Migliori Varianti: L'uso di un approccio "generate-and-select" per il codice Python, che sfrutta la diversità delle varianti generate per trovare soluzioni robuste.
4. Valutazione Estesa: Sperimentazione su 17 domini PDDL (inclusi quelli di Silver et al. e nuovi domini) utilizzando sia modelli LLM "reasoning" (DeepSeek-V3.2, Qwen3-Thinking) che "non-reasoning" (GPT-4o, Llama3.3).

4. Risultati Sperimentali

Gli esperimenti sono stati condotti su 17 domini di benchmark.

• Prestazioni Generali: L'approccio proposto ha mostrato miglioramenti sostanziali rispetto alla baseline di Silver et al. (2024) e a una reimplementazione controllata.
  • La configurazione migliore (F5-3 con DeepSeek) ha raggiunto una copertura media dell'82% sui compiti di valutazione.
  • In 14 domini su 17, l'approccio ha raggiunto il 100% di copertura in almeno una delle tre esecuzioni.
• Confronto con Modelli: I modelli "reasoning" (DeepSeek, Qwen) hanno performato meglio dei modelli non reasoning, ma l'approccio proposto ha migliorato le prestazioni di tutti e quattro i modelli testati.
• Generalizzazione: I programmi generati con copertura del 100% sono stati verificati manualmente e si è dimostrato che generalizzano correttamente a compiti di dimensioni arbitrarie e a varianti "costumate" (dove i nomi degli oggetti/azioni sono cambiati ma la logica rimane la stessa), indicando una vera capacità di ragionamento e non solo memorizzazione.
• Efficienza Temporale: Sebbene la generazione del programma richieda più tempo e token rispetto alle baseline (a causa delle fasi di riflessione e validazione multipla), l'esecuzione del programma generato è estremamente veloce. Rispetto ai pianificatori simbolici (come FF), l'esecuzione del piano Python è significativamente più rapida (fino a 0.36x il tempo di FF) per la maggior parte dei compiti, pur generando piani leggermente più lunghi (in media 1.1x - 1.5x).

5. Significato e Impatto

Questo lavoro dimostra che la pianificazione generalizzata con LLM può essere resa robusta e scalabile superando le limitazioni della generazione diretta di codice.

• Validazione Ibrida: L'idea di validare una strategia astratta (pseudocodice) tramite un pianificatore simbolico (PDDL) prima di passare al codice è un contributo metodologico significativo che riduce il rischio di errori logici.
• Scalabilità: Dimostra che è possibile generare programmi che risolvono domini di dimensioni arbitrarie, superando il problema della scalabilità tipico degli LLM quando generano piani passo-passo per istanze singole.
• Costo-Beneficio: Sebbene il costo computazionale per generare il piano sia più alto (perché avviene una volta per dominio e non per compito), il costo di esecuzione è minimo, rendendo l'approccio economicamente vantaggioso per applicazioni che richiedono la risoluzione di migliaia di istanze nello stesso dominio.

In sintesi, il paper stabilisce un nuovo standard per l'uso degli LLM nella pianificazione simbolica, spostando il focus dalla semplice generazione di codice alla costruzione di un ciclo di feedback rigoroso che include astrazione, validazione simbolica e riflessione.