Passi il messaggio di un utente all'API GPT e, invece di una risposta in linguaggio naturale, il modello ti restituisce un oggetto JSON strutturato che ti dice esattamente quale funzione chiamare e con quali argomenti. Questa è la chiamata di funzioni — e cambia il tipo di applicazioni che puoi costruire con gli LLM.
La maggior parte degli sviluppatori sente “function calling” e presume che il modello stia eseguendo codice per loro. Non è così.
Quando usi la chiamata di funzioni, l’LLM non esegue la funzione. Invece, identifica la funzione appropriata, raccoglie tutti i parametri necessari e fornisce le informazioni in un formato JSON strutturato.
La tua applicazione è ancora responsabile dell’esecuzione della logica effettiva. Il modello ti sta solo dicendo cosa eseguire e con quali input.
Questa distinzione conta più di quanto sembri, e plasma tutto: da come progetti l’integrazione a come pensi alla sicurezza.
Cosa È Davvero la Chiamata di Funzioni — e Cosa la Gente Continua a Sbagliare
La chiamata di funzioni (nota anche come chiamata di strumenti) offre un modo potente e flessibile per i modelli OpenAI di interfacciarsi con sistemi esterni e accedere a dati al di fuori del loro addestramento.
Il nome è la prima fonte di confusione. Le persone pensano che il modello stia eseguendo qualcosa. Non è così.
Ci sono molti nomi e spiegazioni per la chiamata di funzioni, ma tutto si riduce a un’unica affermazione: “la chiamata di funzioni è un tipo di capacità di output strutturato di un grande modello linguistico.” Gli LLM non chiamano funzioni da soli; suggeriscono quale funzione dovresti chiamare da un insieme predefinito di funzioni che fornisci all’LLM in un prompt.
La seconda confusione riguarda la vecchia superficie dell’API.
I parametri functions e function_call sono stati deprecati con il rilascio della versione 2023-12-01-preview dell’API. Il sostituto di functions è il parametro tools.
Se stai seguendo un tutorial che usa il vecchio parametro functions, stai già lavorando con una sintassi deprecata. Usa invece tools e tool_choice.
Una funzione è un tipo specifico di strumento, definito da uno schema JSON. Una definizione di funzione consente al modello di passare dati alla tua applicazione, dove il tuo codice può accedere ai dati o intraprendere azioni suggerite dal modello.
Quello schema è ciò che conferisce alla chiamata di funzioni il suo vantaggio in termini di affidabilità rispetto al semplice prompting: non stai sperando che il modello formatti correttamente l’output, stai imponendo la struttura a livello di API.
Come Funziona la Chiamata di Funzioni nell’API OpenAI — Passo dopo Passo
La chiamata di strumenti è una conversazione a più passaggi tra la tua applicazione e un modello tramite l’API OpenAI. Il flusso di chiamata degli strumenti ha cinque passaggi di alto livello: inviare una richiesta al modello con gli strumenti che potrebbe chiamare...
Ecco come appaiono in pratica ciascuno di questi passaggi.
Passaggio 1: Definisci gli schemi delle tue funzioni. Descrivi ogni funzione disponibile come un oggetto JSON all’interno del parametro tools. Lo schema include il nome della funzione, una descrizione in linguaggio naturale che il modello usa per decidere quando invocarla e un blocco parameters che segue le convenzioni di JSON Schema.
Più dettagliata è la tua description — in termini di situazioni in cui può e dovrebbe chiamare la funzione — meglio è. Nota, tuttavia, che le descrizioni delle funzioni fanno parte del prompt e quindi consumano token a tutti gli effetti.
Passaggio 2: Invia la richiesta. Chiami la Chat Completions API con il messaggio dell’utente e la tua lista di tools. Il modello vede entrambi.
Passaggio 3: Il modello decide se chiamare una funzione.
Una chiamata di funzione si riferisce a un tipo speciale di risposta che puoi ottenere dal modello se, esaminando un prompt, determina che, per seguire le istruzioni, deve chiamare uno degli strumenti a sua disposizione. Se il modello riceve un prompt come “com’è il meteo a Parigi?”, potrebbe rispondere con una chiamata allo strumento get_weather, con Parigi come argomento della località.
Passaggio 4: Il tuo codice esegue la funzione. Analizzi la risposta del modello, estrai il nome della funzione e gli argomenti ed esegui il codice effettivo nel tuo runtime. L’API ha restituito JSON strutturato — decidi tu cosa farne.
Passaggio 5: Invia il risultato indietro.
Invii quindi tutte le definizioni degli strumenti, il prompt originale, la chiamata allo strumento del modello e l’output della chiamata allo strumento di nuovo al modello per ricevere finalmente una risposta testuale
— qualcosa come “Il meteo a Parigi oggi è 25°C.”
Un dettaglio che la maggior parte dei tutorial salta:
quando imposti strict: true nella definizione della tua funzione, Structured Outputs garantisce che gli argomenti generati dal modello per una chiamata di funzione corrispondano esattamente al JSON Schema che hai fornito.
Impostare strict su true garantirà che le chiamate di funzione aderiscano in modo affidabile allo schema della funzione, invece di essere “best effort”. OpenAI consiglia di attivare sempre la modalità strict.
Sempre. Non c’è un buon motivo per non farlo.
C’è anche la chiamata di funzioni in parallelo di cui essere a conoscenza.
A seconda della richiesta dell’utente, il modello invocherà chiamate di funzione in parallelo se si utilizzano gli ultimi modelli rilasciati il 6 novembre 2023 o dopo.
Questo significa che una singola richiesta come “com’è il meteo a Londra e Tokyo?” può attivare due chiamate agli strumenti simultanee invece di concatenarle in sequenza.
Casi d’Uso Reali della Chiamata di Funzioni
L’esempio del meteo è ovunque perché è pulito. I casi d’uso reali in produzione sono più disordinati e interessanti.
Pipeline di supporto clienti con dati live
La chiamata di funzioni è utile per un gran numero di casi d’uso — per esempio, un assistente AI che deve recuperare i dati cliente più recenti da un sistema interno quando un utente chiede “quali sono i miei ordini recenti?” prima di poter generare una risposta.
Il modello capisce l’intento, estrae l’ID cliente dal contesto e chiama l’API interna del tuo CRM. Niente regex fragili. Niente prompt template talmente delicati da rompersi per una virgola mancante.
Estrazione di dati strutturati su larga scala
Una pipeline di estrazione dati che recupera testo grezzo, lo converte in dati strutturati e lo salva in un database è un altro ottimo esempio. Ottieni schemi coerenti su migliaia di documenti senza mettere a punto manualmente la logica di parsing per ogni tipo di documento.
Dal linguaggio naturale alle API
Soluzioni basate su LLM per estrarre e taggare dati, applicazioni che possono aiutare a convertire il linguaggio naturale in chiamate API o query di database valide, e motori di recupero di conoscenza conversazionali che interagiscono con una knowledge base — tutti beneficiano della garanzia di formattazione dell’output della chiamata di funzioni. Quando hai bisogno che l’output alimenti sistemi a valle, non puoi tollerare variabilità.
Workflow agentici con più strumenti
Per gli sviluppatori, la chiamata di funzioni abilita l’accesso ai dati in tempo reale per superare i cutoff di addestramento recuperando prezzi azionari live, meteo o voci recenti di database. Abilita anche l’esecuzione di azioni — trasformando l’LLM da osservatore passivo a partecipante attivo che modifica lo stato, come inviare email, aggiornare CRM o distribuire codice.
La distinzione chiave rispetto a un semplice chatbot: il modello non sta solo generando testo, sta orchestrando operazioni reali nei tuoi sistemi.
Best Practice per la Chiamata di Funzioni — Cosa gli Sviluppatori Sbagliano di Solito
Questa è la sezione che la maggior parte dei tutorial salta del tutto, motivo per cui i team finiscono a fare debug di strani errori in produzione alle 2 di notte.
Scrivere descrizioni troppo vaghe. Il modello usa la descrizione della tua funzione per decidere quando chiamarla. Se la tua descrizione è generica — qualcosa come “elabora le richieste dell’utente” — il modello non ha un segnale affidabile su quando attivarla. Sii specifico sulla condizione di trigger e sulla forma dell’input attesa. Pensa alla descrizione come a un contratto, non a un’etichetta.
Esporre troppe funzioni in una volta sola
Le descrizioni delle funzioni possono consumare un numero significativo di token nel prompt di input.
Caricare definizioni per oltre 50 strumenti nel system prompt crea due problemi: costo e latenza, poiché le definizioni degli strumenti consumano token in input; e degrado dell’accuratezza, poiché all’aumentare del numero di strumenti disponibili diminuisce la capacità del modello di selezionare quello corretto.
Inizia con il set più piccolo di funzioni di cui il tuo caso d’uso ha effettivamente bisogno.
Supporre che il modello non allucini parametri. Lo farà.
Il modello può allucinare parametri
— soprattutto per i campi opzionali che non sono chiaramente vincolati da un enum. Questo è esattamente il motivo per cui strict: true è importante: rimuove al modello la possibilità di inventare campi al di fuori del tuo schema.
Non gestire il loop multi-turn. Gli sviluppatori spesso costruiscono il happy path — l’utente chiede, il modello chiama la funzione, fine.
I modelli possono generare chiamate di funzione che non corrispondono allo schema che hai definito o provare a chiamare una funzione che non hai incluso. Se il modello sta generando chiamate di funzione inaspettate, prova a includere un’unica frase nel messaggio di sistema che dica “Usa solo le funzioni che ti sono state fornite.”
Progetta per i casi limite.
Saltare il passaggio di conferma prima delle operazioni di scrittura.
Sii consapevole dell’impatto reale delle chiamate di funzione che prevedi di eseguire, specialmente quelle che innescano azioni come eseguire codice, aggiornare database o inviare notifiche. Per le funzioni che compiono azioni, si consiglia vivamente di implementare un passaggio in cui l’utente confermi l’azione prima dell’esecuzione.
Se una chiamata di funzione può eliminare dati, inviare denaro o modificare lo stato esterno, una persona dovrebbe approvarla prima.
Considerazioni su Sicurezza e Affidabilità
La chiamata di funzioni amplia ciò che un LLM può fare. Amplia anche ciò che un attaccante può fargli fare.
La minaccia principale qui è l’iniezione di prompt.
Gli obiettivi finali delle iniezioni di prompt variano ma possono includere l’esfiltrazione di dati privati tramite chiamate a strumenti downstream, l’esecuzione di azioni non allineate o, in generale, la modifica del comportamento del modello in modo non previsto.
Quando le tue chiamate di funzione possono inviare email, interrogare database o attivare webhook, un attacco di injection non è solo un chatbot che esce dallo script — è una potenziale violazione.
Man mano che i sistemi di AI vanno oltre la chat e iniziano a chiamare strumenti e intraprendere azioni, l’iniezione di prompt diventa un problema molto più serio. Un’istruzione malevola nascosta in una pagina web, in un documento o in uno strumento esterno può tentare di sovrascrivere il comportamento del sistema, esporre informazioni sensibili o attivare azioni che il modello non dovrebbe mai compiere.
La strategia di mitigazione ha alcuni livelli concreti.
Progetta workflow in modo che i dati non attendibili non guidino mai direttamente il comportamento degli agenti. Estrai solo campi strutturati specifici — come enum o JSON validati — dagli input esterni per limitare il rischio di injection che fluisce tra i nodi.
Inoltre,
verifica sempre le chiamate di funzione generate dal modello. Questo include controllare i parametri, la funzione chiamata e assicurarsi che la chiamata sia allineata con l’azione prevista.
Una verità scomoda:
“L’iniezione di prompt, proprio come le truffe e l’ingegneria sociale sul web, difficilmente sarà mai completamente ‘risolta’.”
Questa è la valutazione di OpenAI. L’implicazione pratica è che non dovresti progettare sistemi agentici con chiamata di funzioni assumendo che il modello si comporterà sempre come previsto. Difesa in profondità — validazione, permessi con ambito, human-in-the-loop per operazioni distruttive — è l’unica postura sensata.
Chiamata di Funzioni vs. Ingegneria del Prompt — Quando Usare l’Una o l’Altra
Questo confronto emerge continuamente. La risposta breve: risolvono problemi diversi, e confonderli porta a prompt eccessivamente ingegnerizzati dove basterebbe la chiamata di funzioni, o a schemi di funzione fragili quando un buon system prompt sarebbe più semplice.
L’ingegneria del prompt consiste nel creare input testuali per guidare il ragionamento interno dell’LLM — per esempio, chiedendogli di “pensare passo-passo”.
Influenza come il modello ragiona. La chiamata di funzioni, invece, influenza ciò che il modello produce come output e lo instrada direttamente nel tuo sistema.
La chiamata di strumenti è la capacità che consente all’LLM di interagire con sistemi esterni. Mentre usi l’ingegneria del prompt per aiutare il modello a decidere quale strumento usare, la chiamata di strumenti è il meccanismo che esegue effettivamente l’azione. Probabilmente ti servono entrambe, ma hanno scopi diversi.
Un vantaggio tecnico chiave della chiamata di funzioni rispetto all’output strutturato basato su prompt:
la chiamata di strumenti è un concetto integrato direttamente nel modello. Non c’è bisogno di sprecare token ed energie per spiegare al modello che dovrebbe restituire un formato specifico.
Quando crei un prompt che dice “restituisci la tua risposta come JSON con i campi X, Y e Z”, stai spendendo token per istruzioni che il modello potrebbe seguire in modo incoerente. Con la chiamata di funzioni, l’applicazione dello schema avviene a livello di API.
Le API di chiamata di funzioni, ora supportate nativamente in molte piattaforme LLM, forniscono un’interfaccia formale guidata da schemi che consente una rigorosa validazione dei dati e l’integrazione con workflow programmabili.
Questo è il motivo reale per sceglierla rispetto all’ingegneria del prompt per qualsiasi dato che debba fluire in sistemi a valle: l’affidabilità non è opzionale una volta in produzione.
| Dimensione | Ingegneria del Prompt | Chiamata di Funzioni |
|---|---|---|
| Scopo principale | Modellare il ragionamento e il tono del modello | Produrre output strutturati per l’integrazione con i sistemi |
| Formato dell’output | Testo libero (o JSON “a forma di testo”) | Schema JSON imposto |
| Affidabilità dello schema | Best effort; soggetta a drift | Garantita con strict: true |
| Costo in token | Inferiore per output semplici | Superiore (le definizioni delle funzioni aggiungono token) |
| Quando usarla | Compiti di ragionamento, generazione di testo, controllo dello stile | Estrazione di dati strutturati, orchestrazione API, azioni agentiche |
| Esposizione a prompt injection | Inferiore (nessuna esecuzione di strumenti esterni) | Superiore (le chiamate possono attivare azioni nel mondo reale) |
L’euristica pratica: se l’output deve alimentare un sistema a valle — una scrittura su database, una chiamata API, un ramo decisionale nel tuo codice — usa la chiamata di funzioni. Se l’output è destinato alla lettura umana, l’ingegneria del prompt è di solito sufficiente e più economica.
Punti Chiave
| Argomento | Cosa Ricordare |
|---|---|
| Cos’è | Il modello produce JSON strutturato che descrive quale funzione chiamare — non esegue la funzione |
| Superficie API attuale | Usa tools e tool_choice; i parametri functions e function_call sono deprecati |
| Modalità strict | Imposta sempre strict: true nelle definizioni di funzione per imporre la conformità allo schema |
| Chiamate parallele | Supportate nei modelli rilasciati dopo novembre 2023; una richiesta può attivare più chiamate a strumenti |
| Costo in token | Gli schemi delle funzioni consumano token in input; minimizza il numero di funzioni esposte |
| Sicurezza | Valida tutte le chiamate di funzione generate; non consentire mai a contenuti esterni non attendibili di guidare direttamente le chiamate |
| vs. Ingegneria del Prompt | La chiamata di funzioni impone la struttura dell’output a livello di API; l’ingegneria del prompt modella il ragionamento interno |
| Passi di conferma | Qualsiasi funzione con effetti reali (scrivere, inviare, eliminare) dovrebbe richiedere conferma dell’utente prima dell’esecuzione |
Se vuoi sperimentare la chiamata di funzioni su modelli diversi — GPT-5.4, claude opus 4.7, gemini 3.1 pro — senza mantenere credenziali API separate per ciascuno, CometAPI ti dà accesso a tutti tramite un unico endpoint e una singola chiave, rendendo i test cross-model significativamente meno gravosi.
CometAPI risolve l’overhead infrastrutturale:
✅ Sintassi unificata per la chiamata di funzioni su oltre 15 modelli
✅ Un’unica chiave API — nessun account separato per OpenAI/Anthropic/Google
✅ Traduzione automatica dello schema — scrivi una volta, testa ovunque
✅ Monitoraggio dei costi integrato — confronta l’uso di token per modello in tempo reale
Inizia a testare con crediti gratuiti → Ottieni l’accesso