Sintesi Tecnica: HALO – Un approccio supervisionato alla pianificazione end-to-end PDDL con agenti LLM

1. Definizione del Problema

La pianificazione automatizzata richiede la traduzione di obiettivi in linguaggio naturale in specifiche formali PDDL (Planning Domain Definition Language), che i solver classici possono elaborare. Sebbene i Large Language Models (LLM) offrano un ponte tra il linguaggio naturale e le rappresentazioni formali, essi sono inaffidabili se utilizzati isolatamente, spesso allucinando predicati, codificando erroneamente i vincoli o producendo piani non validi.

Recenti framework agentici (ad es., La Malfa et al. [2026]) affrontano questo problema orchestrando un pool di agenti di riparazione specializzati all'interno di un ciclo di raffinamento controllato da un verificatore. In questi sistemi, un LLM "frontiera" (ad es., GPT-5, Gemini-3) funge da orchestratore, ispezionando lo stato corrente (PDDL, log del solver, errori del validatore) e selezionando l'agente di riparazione appropriato ad ogni passaggio. Sebbene efficace, questo approccio crea un collo di bottiglia significativo: l'orchestratore stesso richiede una costosa chiamata API a un LLM frontiera ad ogni passaggio di raffinamento. Questa dipendenza limita l'implementazione a scenari con accesso continuo alle API, rendendo il framework proibitivamente costoso per ambienti di scala di laboratorio, edge o air-gapped.

La sfida centrale affrontata da questo articolo è: È possibile sostituire l'orchestratore LLM frontiera con un modello piccolo, servito localmente, senza sacrificare i tassi di successo della pianificazione?

2. Metodologia: HALO

Gli autori propongono HALO (Hybrid Agent-Learned Orchestrator), un sistema che sostituisce l'orchestratore frontieraia tramite prompt con una policy QLoRA-tuned accoppiata a uno strato di regole predefinite (hardcoded).

2.1 Il Segnale di Addestramento: Traiettorie Guidate dal Verificatore

Un'intuizione chiave del paper è che il verificatore esterno (compilatore e validatore) fornisce già un forte segnale di supervisione. In un framework agentico, una traiettoria di raffinamento è una sequenza di decisioni (stato, agente). Se la traiettoria termina in un piano valido (certificato dal verificatore), ogni decisione all'interno di quella traiettoria è implicitamente "corretta" nel senso che ha contribuito a un esito positivo.

• Raccolta Dati: Gli autori eseguono un insegnante forte tramite prompt (GPT-5-mini) su problemi di addestramento in 11 domini PDDL.
• Filtraggio: Le traiettorie sono filtrate rigorosamente dal verificatore esterno. Solo quelle che terminano in un piano valido vengono mantenute.
• Supervisione: Il set di addestramento consiste in coppie (stato, agente) estratte da queste traiettorie verificate. La policy viene addestrata tramite supervised fine-tuning (SFT) per predire l'ID dell'agente che l'insegnante ha selezionato, condizionato allo stato.

2.2 Spazio delle Azioni Espanso

Il framework espande il pool di agenti dai 13 originali a 21 agenti, categorizzati come:

1. Agenti di Base (13): Routine di riparazione indotte da prompt LLM (ad es., correttore di sintassi, eliminatore di allucinazioni) derivanti dal lavoro precedente.
2. Agenti di Riparazione del Piano Deterministici (5): Routine non-LLM (ad es., scambio di variabili, riordinamento delle azioni, rimozione della ridondanza) che vengono eseguite in millisecondi con costo zero di LLM.
3. Agenti PDDL-Aware (3): Agenti specializzati per errori di modellazione (ad es., correzione della gerarchia dei tipi, generalizzazione dei predicati).

2.3 Policy di Inferenza Ibrida

Al tempo di inferenza, HALO opera con una policy a due strati ($\pi_{hybrid}$):

• Strato 1 (Regole Hardcoded): Tre casi trivialmente decidibili sono risolti da regole senza invocare un modello:
  • Cold start (PDDL vuoto) $\rightarrow$ Seleziona AgentEmergency.
  • Errori di sintassi rilevati $\rightarrow$ Seleziona AgentSyntaxPDDL.
  • Piano valido raggiunto $\rightarrow$ Seleziona NoOpAgent (termina).
• Strato 2 (Policy Appresa): Se nessuna regola si applica, un piccolo LLM, QLoRA-tuned (ad es., Llama-3-8B), predice l'ID dell'agente successivo. Il modello è sottoposto a fine-tuning per emettere un singolo token corrispondente all'ID dell'agente (0–20).

2.4 Dettagli dell'Addestramento

• Architettura: Fine-tuning QLoRA (quantizzazione a 4 bit, rank LoRA 16) su modelli base come Llama-3-8B, Qwen-2.5-7B e Gemma-2-9B.
• Funzione di Perdita: Cross-entropy a singolo token sull'ID dell'agente, con i token del prompt mascherati.
• Volume di Dati: Circa 12.000–15.000 coppie (stato, agente) derivate da circa 2.000 traiettorie di alta qualità accettate dal verificatore.

3. Contributi Chiave

1. HALO (Hybrid Agent-Learned Orchestrator): Un orchestratore addestrato che sostituisce la chiamata API dell'LLM frontiera con l'inferenza di un modello piccolo e servito localmente. Esso eguaglia o supera le prestazioni dei baseline GPT-5-mini e Gemini-3-Flash, riducendo i costi di orchestrazione di oltre un ordine di grandezza.
2. Supervisione di Traiettoria Guidata dal Verificatore: Gli autori formulano l'addestramento dell'orchestratore come apprendimento per imitazione su traiettorie certificate da un compilatore/validatore esterno. Il verificatore agisce come un filtro di accettazione dei dati piuttosto che come una funzione di perdita, fornendo un segnale di supervisione forte e privo di rumore che generalizza attraverso i domini.
3. Spazio delle Azioni Espanso con Policy Ibrida: L'introduzione di 21 agenti (inclusi i processi di riparazione deterministici) e di una policy ibrida che delega le decisioni triviali a regole hardcoded. Ciò consente alla policy appresa di concentrare la propria capacità su decisioni realmente ambigue, migliorando l'efficienza e riducendo l'onere dell'addestramento.

4. Risultati Sperimentali

Il sistema è stato valutato su 11 domini PDDL che spaziano tra i benchmark PlanBench, Google Natural Plan e Classical Planning.

• Tasso di Successo:
  • HALO eguaglia o supera il baseline a prompt GPT-5-mini in tutte le famiglie (ad es., +3.3% su PlanBench, +37.3% su Natural Plan).
  • HALO si colloca entro 3 punti percentuali dal più forte baseline Gemini-3-Flash su PlanBench e Natural Plan, ed eccelle nella pianificazione classica (95.8% vs 93.0%).
• Efficienza e Costo:
  • Chiamate LLM: HALO riduce le chiamate LLM totali per episodio del 40–50% rispetto ai baseline, principalmente grazie allo strato di regole ibrido che risolve circa il 35% delle decisioni senza una chiamata al modello.
  • Costo: Il costo di orchestrazione scende da ~$0.18–$0.22 per task (GPT-5-mini) e ~$0.06–$0.08 (Gemini-3-Flash) a $0.004 per task per HALO. Ciò rappresenta una riduzione di 45× rispetto a GPT-5-mini e di 15× rispetto a Gemini-3-Flash.
• Generalizzazione: Il modello generalizza a domini non inclusi nell'addestramento con un calo delle prestazioni di soli ~5–8 punti percentuali, suggerando che il segnale appreso cattura pattern di orchestrazione generali al dominio piuttosto che memorizzare scorciatoie specifiche.

5. Significato e Rivendicazioni

Il paper sostiene che i framework agentici costruiti attorno a verificatori formali ammettono una semplificazione strutturale: l'orchestratore non ha bisogno di un LLM frontiera generalista. Al contrario, può essere un modello piccolo, servito localmente e addestrabile, a patto che il verificatore fornisca segnali di accettazione per traiettoria.

Questa scoperta ha implicazioni significative per l'implementazione:

• Disaccoppiamento dalle API: Rimuove la dipendenza dall'accesso continuo alle costose API degli LLM frontiera.
• Accessibilità: Rende la pianificazione end-to-end in linguaggio naturale fattibile per contesti di scala di laboratorio, edge e air-gapped dove l'accesso alle API è impraticabile o proibito.
• Efficienza dei Costi: Dimostra che una pianificazione di alta qualità può essere ottenuta a una frazione del costo (circa 45 volte meno costosa) sfruttando la supervisione "gratuita" inerente al ciclo di verifica.

Gli autori segnalano limitazioni, tra cui la dipendenza dal comportamento dell'insegnante (limitata dalle traiettorie filtrate dal verificatore) e l'incapacità di gestire estensioni PDDL al di fuori dell'ambito dei 21 agenti (ad es., fluenti numerici). Tuttavia, pongono l'accento sul fatto che questo approccio supervisionato serve come un solido baseline, con lavori futuri che potrebbero esplorare il Reinforcement Learning from Verifiable Rewards (RLVR) per superare il "limite dell'insegnante" (teacher ceiling).