Function Calling — Come i LLM Imparano a Usare i Tool

Cos'è: Il function calling (o tool use) è la capacità di un LLM di emettere, invece di testo libero, chiamate strutturate a funzioni esterne definite dallo sviluppatore. Introdotto da OpenAI a giugno 2023, è il primitivo che ha trasformato i modelli linguistici da generatori di testo a componenti orchestrabili di sistemi software complessi.

Il Primitivo che Mancava: giugno 2023

Prima del function calling, integrare un LLM con sistemi esterni richiedeva tecniche fragili: prompt ingegnerizzati per produrre JSON, parser che tolleravano output malformati, retry in caso di formato errato. Il modello non aveva garanzie strutturali sull'output — ogni chiamata poteva restituire variazioni di formato imprevedibili.

Con la release del 13 giugno 2023, OpenAI introduce function calling su GPT-3.5-turbo e GPT-4. Il cambiamento fondamentale è che lo sviluppatore descrive le funzioni disponibili tramite JSON Schema, e il modello — quando lo ritiene appropriato — emette un oggetto strutturato che specifica quale funzione chiamare e con quali argomenti. Il formato è garantito essere valido rispetto allo schema fornito.

Questo non è solo un miglioramento di convenienza: è un cambio architetturale. Il modello diventa un componente affidabile in una pipeline software, non solo una sorgente di testo da parsare euristicamente.

Come Funziona: il Ciclo Completo

Il flusso di una singola interazione con function calling si articola in quattro fasi distinte:

1. Definizione delle funzioni. Lo sviluppatore include nella richiesta all'API un array tools, dove ogni elemento descrive una funzione: nome, descrizione in linguaggio naturale, e parametri come JSON Schema. La descrizione è cruciale — il modello la usa per decidere quando e come chiamare la funzione.

2. Decisione del modello. Il modello analizza il messaggio dell'utente e decide se rispondere con testo libero o con una chiamata a funzione. Se sceglie una funzione, la risposta ha finish_reason: "tool_calls" e contiene il nome della funzione e gli argomenti inferiti, serializzati come stringa JSON.

3. Esecuzione lato client. L'applicazione riceve la risposta, deserializza gli argomenti, ed esegue la funzione reale nel proprio codice (chiamata HTTP, query database, calcolo locale). Il modello non esegue nulla direttamente — è sempre il codice applicativo a farlo.

4. Restituzione del risultato. L'applicazione aggiunge al thread conversazionale un messaggio di ruolo tool con il risultato dell'esecuzione. Il modello riceve questo contesto e formula la risposta finale all'utente, integrando l'informazione ottenuta.

Parallel Tool Use: efficienza su task multi-step

Un'evoluzione significativa è il parallel tool use, disponibile su GPT-4 Turbo e modelli successivi. In un singolo turno, il modello può emettere più chiamate a funzioni indipendenti contemporaneamente — l'applicazione le esegue in parallelo, e il modello aspetta tutti i risultati prima di rispondere.

Esempio pratico: un assistente di viaggio che deve rispondere "Che tempo fa a Milano e quanto costa un volo domani?" può emettere simultaneamente una chiamata a get_weather(city="Milano") e search_flights(origin="...", destination="Milano", date="..."). Senza parallel tool use, queste sarebbero due richieste sequenziali con doppia latenza di rete e doppio costo di inferenza.

Il parametro tool_choice permette di forzare il comportamento: "auto" lascia decidere il modello, "none" disabilita le funzioni, {"type": "function", "function": {"name": "..."}} forza una specifica funzione. Quest'ultima opzione è utile per costruire pipeline deterministiche dove il modello è usato come parser strutturato piuttosto che come agente decisore.

Anthropic Tool Use: lo stesso primitivo, filosofia diversa

Anthropic introduce il proprio equivalente — chiamato tool use — con Claude 3 nel marzo 2024. La meccanica è identica nella sostanza: JSON Schema per la definizione, risposta strutturata quando il modello sceglie un tool, ciclo di feedback con il risultato. Le differenze sono nei dettagli del protocollo API e nel comportamento del modello.

Claude tende a essere più esplicito nelle sue ragioni per scegliere un tool — le sue chain-of-thought (quando visibili in extended thinking) mostrano ragionamento più articolato sulla pertinenza della chiamata. OpenAI è generalmente più veloce nell'esecuzione, Claude più prudente nell'evitare chiamate non necessarie. In pratica, la scelta tra i due dipende più dall'ecosistema di modelli già in uso che da differenze funzionali nel primitivo.

LLM + Tool vs Agente: la distinzione che conta

C'è una distinzione fondamentale spesso confusa: un LLM con function calling non è automaticamente un agente. Un agente implica un loop autonomo: il modello agisce, osserva il risultato, decide il passo successivo, agisce di nuovo — senza supervisione umana a ogni step.

Un LLM con tool use in modalità single-turn è uno strumento potente ma deterministico: l'applicazione controlla il loop, decide quando reiniettare i risultati, e può interrompere il flusso in qualsiasi momento. Un agente come AutoGPT o un sistema basato su LangGraph o Agentix usa lo stesso primitivo ma all'interno di un loop autonomo dove il modello stesso decide quante iterazioni fare e quando fermarsi.

Il rischio specifico del function calling in contesti agentici è la prompt injection via tool response: un attore malevolo può inserire istruzioni nel risultato restituito da un tool (ad esempio nel contenuto di una pagina web fetchata) cercando di dirottare il comportamento del modello. I sistemi di produzione devono trattare i risultati dei tool come input non fidati e applicare sanitizzazione appropriata.

Esempi Pratici ad Alta Utilità

I casi d'uso più comuni e ad alto valore in produzione includono: weather API (il classico esempio OpenAI, ma rappresentativo di qualsiasi sorgente dati real-time), database query (il modello genera parametri di ricerca strutturati invece di SQL grezzo — più sicuro contro injection), web search (Bing API, Brave Search, Tavily — il modello decide quando la propria conoscenza è insufficiente o outdated), esecuzione codice (il modello genera codice, un sandbox lo esegue, il risultato rientra nel contesto), e interazioni con CRM/ERP (lettura e scrittura di record aziendali in modo strutturato e auditabile).

Il pattern più robusto in produzione è quello di descrivere le funzioni con documentazione ricca e esempi di input/output nel campo description: il modello usa questa documentazione per capire non solo cosa fa la funzione ma quando è appropriato chiamarla, riducendo significativamente i false positive.

---