Domanda AI 2: Come garantire che un LLM chiami gli strumenti in modo affidabile

Come garantire che un Large Language Model (LLM) lavori in modo affidabile e controllabile durante la chiamata di strumenti, senza affidarsi solo a prompt per "convincere" il modello. È necessario fornire sistematicamente un framework di vincoli a più livelli.

Prendendo l'esempio della richiesta del meteo, il modello presenta tre comuni comportamenti di "invenzione" nella chiamata di strumenti:
1. Non chiamare lo strumento e inventare direttamente la risposta.
2. Passare parametri con formato errato durante la chiamata (ad esempio, lo strumento non supporta "dopodomani", ma passa il parametro date="dopodomani").
3. Convertire arbitrariamente il formato dei parametri (ad esempio, convertire "dopodomani" in una data specifica senza autorizzazione), anche se lo strumento non lo richiede.

La radice del problema è che l'output del modello è essenzialmente probabilistico, e i prompt impongono solo "vincoli morbidi" sulla distribuzione di probabilità, non un meccanismo forzato che garantisca la stretta osservanza del modello. In scenari complessi, questi "vincoli morbidi" possono facilmente fallire.

Per risolvere questo problema, è necessaria una soluzione ingegneristica a più livelli:

1. Primo livello: Ottimizzazione dei prompt (vincoli morbidi)

   • È il punto di partenza del sistema di vincoli, ma non certo il punto finale.
   • I prompt dovrebbero essere visti come un "contratto operativo", chiarendo lo scopo dello strumento, il tipo di ogni parametro, i limiti, e fornendo esempi di valori non validi.
   • Dovrebbero essere inclusi esempi Few-shot, mostrando esempi di "input corretto → chiamata corretta" per ancorare il comportamento del modello tramite apprendimento contestuale.

2. Secondo livello: Introduzione di JSON Schema (vincoli rigidi)

   • Questo è un passo chiave dal "ragionare" al "mettere le barriere".
   • Sostituire la descrizione in linguaggio naturale dei parametri con una definizione strutturata leggibile e verificabile dalla macchina (JSON Schema). Può definire rigorosamente il tipo di campo, l'obbligatorietà, l'intervallo di valori enumerati, e può vietare al modello di emettere campi non definiti impostando additionalProperties: false.
   • Le principali piattaforme API supportano questo tipo di vincolo di output strutturato durante la fase di decodifica del modello, evitando violazioni di formato alla fonte della generazione.

3. Terzo livello: Creazione di un ciclo di convalida-riparazione-riprova (esecuzione di fallback)

   • Anche con lo Schema, è comunque necessario eseguire la convalida sintattica e dello Schema dopo aver ottenuto l'output del modello.
   • In caso di fallimento della convalida, progettare un meccanismo automatico di pulizia e riprova (con limite massimo), restituendo le informazioni sull'errore al modello per correggere l'output. Dopo aver superato il numero massimo di tentativi, prevedere un piano di degradazione o intervento manuale.

4. Livello architetturale: Separazione delle responsabilità

   • Separare decisione ed esecuzione, formando un'architettura a tre livelli:
     • Livello modello: Responsabile solo della decisione (decidere quale strumento chiamare, quali parametri generare).
     • Livello framework: Responsabile dell'esecuzione del framework, inclusa la convalida dello Schema, la chiamata dello strumento, la gestione dei tentativi e l'integrazione dei risultati. Ciò garantisce che gli errori del modello non influenzino direttamente la sicurezza dello strumento e che le modifiche allo strumento non richiedano frequenti aggiustamenti dei prompt.
     • Livello strumento: Implementazione delle capacità aziendali specifiche.
   • Framework come LangChain, LlamaIndex stanno facendo proprio questo lavoro.

Limitazioni dell'attuale soluzione: Gestisce bene i problemi di formato dei parametri, ma la copertura della convalida semantica dei parametri (ad esempio, l'equivalenza tra "Shanghai" e "Hu") è ancora insufficiente. Questa sarà una sfida ingegneristica da affrontare in futuro.

Conclusione chiave: Rendere affidabile la chiamata di strumenti da parte di un LLM è essenzialmente un problema di ingegneria del software, che richiede la creazione di una soluzione ingegneristica sistematica che va dai vincoli morbidi, ai vincoli rigidi, al fallback di esecuzione, fino al design architetturale, non solo l'ottimizzazione dei prompt.