Function calling: come un modello usa gli strumenti

Un modello linguistico genera testo. Il function calling è il meccanismo che gli permette di generare, invece del testo, una richiesta strutturata: vorrei chiamare questo strumento, con questi parametri.

Senza
  Tu:  "Che tempo fa a Roma?"
  LLM: "Non ho accesso a dati in tempo reale, però di solito..."

Con
  Tu:  "Che tempo fa a Roma?"
  LLM: { strumento: "meteo", parametri: { città: "Roma" } }
  Sistema: [esegue] → "sole, 22 gradi"
  LLM: "A Roma c'è il sole, 22 gradi."

Il punto che sfugge quasi sempre: il modello non esegue niente. Produce una richiesta. Chi la esegue è il tuo codice, che poi gli restituisce il risultato. Tutta la sicurezza di un agente sta in quello spazio: fra la richiesta e l’esecuzione c’è il tuo programma, ed è lì che si mettono i controlli.

Il ciclo, per intero

1. dichiari gli strumenti disponibili, con le loro descrizioni
2. arriva la domanda dell'utente
3. il modello sceglie: rispondo, o chiedo uno strumento?
      ├── nessuno strumento → risposta diretta
      └── serve uno strumento → produce la richiesta
4. il tuo codice esegue e ottiene un risultato
5. il risultato torna al modello come nuovo messaggio
6. il modello risponde — oppure chiede un altro strumento, e si ricomincia

I passi 3-6 sono esattamente il ciclo dell’agente visto dall’interno. Un agente, tecnicamente, è questo che gira in un while.

Le descrizioni sono il vero programma

Il modello sceglie lo strumento leggendo la descrizione che gli hai dato. Non c’è compilatore, non c’è controllo di tipo: c’è una frase in italiano o in inglese, e una scelta fatta su quella.

Male   "descrizione": "Funzione meteo"
       → il modello non sa quando usarla

Bene   "descrizione": "Restituisce il meteo attuale di una città.
        Usala quando l'utente chiede tempo, temperatura o previsioni."
       → il modello sa quando attivarla, e quando no

Vale anche per i parametri: città va documentato come “nome della città, in italiano, senza provincia” se è quello che ti aspetti. Metà dei fallimenti che sembrano stupidità del modello sono descrizioni scritte da chi già sapeva la risposta.

Una conseguenza operativa: le descrizioni degli strumenti stanno nel contesto, sempre, a ogni richiesta. Trenta strumenti descritti bene sono migliaia di token spesi prima ancora che l’utente parli, e occupano la finestra che servirebbe al lavoro vero.

Quanti strumenti

Pochi. Cinque o dieci ben definiti battono trenta generici, e non per motivi di eleganza: più strumenti ci sono, più aumentano le occasioni di sceglierne uno simile ma sbagliato — e la scelta sbagliata non produce un errore, produce un’azione.

Quando gli strumenti crescono, la strada non è descriverli meglio: è darne al modello solo un sottoinsieme, quello pertinente al compito del momento.

Chiamate in parallelo, e perché contano

I modelli recenti possono chiedere più strumenti in una volta sola:

"Che tempo fa a Roma e a Milano?"
  → [meteo(Roma), meteo(Milano)]     una tornata, due richieste

Non è solo velocità: se le due richieste fossero sequenziali, la seconda partirebbe dopo aver visto il risultato della prima, e il modello potrebbe farsi influenzare da quello. In parallelo restano indipendenti, che è quello che vuoi quando davvero lo sono.

Quando lo strumento fallisce

È il caso che si dimentica di gestire, ed è quello che si presenta di più.

Male   lo strumento va in errore → nessuno lo dice al modello
       → il modello riempie il vuoto: inventa un risultato plausibile

Bene   lo strumento va in errore → l'errore torna al modello come risultato
       → il modello lo dice, oppure prova un'altra strada

Il messaggio di errore va restituito come contenuto, non come eccezione silenziosa: un modello che legge “il file non esiste” cambia strategia, un modello che non riceve niente prosegue come se fosse andato tutto bene.

Una cosa da sapere sui tentativi ripetuti: riprovare la stessa chiamata identica raramente funziona, perché il modello tende a rigenerare la stessa richiesta. Il tentativo utile è quello in cui l’errore è descrittivo: “città sconosciuta: usa il nome in italiano” produce una seconda chiamata diversa, “errore 500” no.

Nativo o standardizzato

Il function calling è il meccanismo di base, e ogni fornitore lo espone con il suo formato: le stesse idee, scritte in modo un po’ diverso. Definire gli strumenti nel proprio codice dà controllo pieno e lega l’applicazione a quel formato.

Sopra questo meccanismo esiste un livello di standardizzazione, che serve a rendere gli strumenti riutilizzabili fra applicazioni diverse invece di riscriverli ogni volta: è il tema della lezione su MCP.

Cosa serve al modello per farlo bene

Non tutti i modelli usano gli strumenti allo stesso modo, e la differenza si vede prima nella forma che nella qualità: i modelli piccoli producono richieste malformate — parametri mancanti, JSON che non chiude, nomi di strumenti inventati. Sotto una certa taglia, in locale, il function calling smette di essere affidabile con più di uno o due strumenti semplici.

È un buon criterio quando si sceglie un modello locale per un agente: non “quanto scrive bene”, ma quanto rispetta un formato sotto pressione. La lezione su come scegliere un modello entra nel merito.

In sintesi

Concetto	In una riga
Function calling	Il modello chiede uno strumento, non lo esegue
Chi esegue	Il tuo codice: è lì che si mettono conferme e limiti
Il ciclo	Dichiara, chiedi, esegui, restituisci, ripeti
Le descrizioni	Sono il programma: il modello sceglie leggendo quelle
Quanti strumenti	Cinque o dieci pertinenti, non trenta generici
Costo nascosto	Le descrizioni occupano contesto a ogni richiesta
Errori	Vanno restituiti al modello, descrittivi: altrimenti inventa
Modelli piccoli	Sbagliano la forma prima del contenuto