“Smetti di chiedere al modello di fare aritmetica a mente. Dagli una calcolatrice e lascia che prema i tasti.”
Cosa significa davvero il "function calling"
Descrivi al modello un insieme di funzioni (i loro nomi, cosa fanno e i loro parametri). Quando il modello decide di averne bisogno, invece di rispondere emette una richiesta strutturata: "chiama get_order_status con order_id=4471". Il tuo codice esegue la funzione reale, restituisce il risultato, e il modello continua con quel risultato in mano.
Il modello non esegue mai nulla da solo. Si limita a proporre una chiamata in forma strutturata; il tuo codice decide se e come eseguirla. Quel confine è tutta la storia della sicurezza, e ci appoggiamo molto nel corso sulla sicurezza.
Perché i tool correggono le peggiori debolezze del modello
Ricorda le cose in cui i modelli sono scarsi: l'aritmetica, i fatti recenti, e qualsiasi cosa abbia una risposta giusta deterministica. I tool risolvono tutte e tre affidando il lavoro a sistemi che ci eccellono.
- Calcolatrice / interprete di codice: il modello smette di inventare numeri e li calcola.
- Query a database / API: il modello smette di allucinare dati e li recupera.
- Ricerca: il modello smette di affidarsi a conoscenza di addestramento obsoleta e va a cercare.
- Validatori (type checker, linter, schema): il modello può verificare il proprio output contro la verità.
Progettare buoni tool
Il modello usa un tool come un nuovo assunto usa una API sconosciuta: dal solo nome e dalla descrizione. La progettazione di tool è quindi progettazione di API per un lettore che non leggerà il codice sorgente. I nomi devono essere privi di ambiguità, le descrizioni devono dire quando usare il tool (non solo cosa fa), e i parametri devono essere difficili da usare male.
Restituisci errori su cui il modello può agire. "Errore 400" è inutile; "order_id deve avere 6 cifre; hai passato 4471 (4 cifre)" permette al modello di correggersi e riprovare. Tratta il modello come il consumatore dei tuoi messaggi di errore, e scrivili per quel lettore.
I tool di lettura e i tool di scrittura sono animali diversi
Un tool che legge (consultare un ordine, cercare nei documenti) è a basso rischio: il caso peggiore è una risposta sbagliata. Un tool che scrive (inviare una email, addebitare una carta, eliminare un record) può causare danni reali che il modello non può annullare. Questi meritano un trattamento completamente diverso.
Rendi i tool di scrittura idempotenti dove puoi, così che un retry sia sicuro. Metti un passo di approvazione umana davanti alle azioni ad alto rischio. Dai al modello una modalità dry-run così che possa testare prima di confermare. E logga ogni chiamata. Il modello prima o poi chiamerà un tool di scrittura con argomenti sbagliati; progetta perché sia sopravvivibile, non catastrofico.
Una riga per ciascuno
- Function calling: il modello propone una chiamata strutturata; il tuo codice esegue il tool reale e restituisce il risultato.
- I tool correggono le peggiori debolezze del modello (matematica, fatti recenti, effetti collaterali) delegando a sistemi che ci eccellono.
- La progettazione di tool è progettazione di API per un lettore che non leggerà il sorgente: nomi chiari, errori istruttivi, output compatto.
- I tool di lettura sono a basso rischio; i tool di scrittura hanno bisogno di idempotenza, dry-run, limiti, porte di approvazione e logging.
Dove andare ora