Chat completion: la primitiva del client

Un client di chat costruito con l’SDK di Foundry si regge su un’unica operazione fondamentale: la chat completion. L’idea concettuale è semplice: invii al modello una lista ordinata di messaggi, ognuno con un ruolo (tipicamente system, user e assistant), e ricevi in risposta il messaggio successivo generato dal modello. Il messaggio con ruolo system definisce il comportamento e il “carattere” dell’assistente; i messaggi user contengono le richieste dell’utente; i messaggi assistant rappresentano le risposte precedenti del modello.

L’SDK ti evita di comporre a mano le chiamate HTTP verso l’endpoint: configuri una volta il client (endpoint, credenziali e il deployment del modello scelto in Foundry) e poi lavori con oggetti e metodi ad alto livello. A livello d’esame conta capire che il modello non “ricorda” nulla di suo: ogni chat completion è un evento isolato che produce testo a partire soltanto dai messaggi che gli passi in quella singola chiamata.

Gestire lo stato conversazionale

Poiché l’operazione di chat completion è stateless, mantenere una conversazione coerente è responsabilità del client, non del servizio. In pratica il client accumula una lista di messaggi e, a ogni nuovo turno, rinvia l’intera storia più il nuovo messaggio dell’utente. È questo che dà l’illusione della memoria: il modello vede tutti gli scambi precedenti e risponde in modo contestuale.

L’approccio ha un costo che cresce a ogni turno. Ogni messaggio in più consuma token, e ogni modello ha un limite massimo di context window. Conversazioni lunghe possono quindi superare il limite o diventare costose. Le strategie concettuali per gestire il problema sono: troncare i messaggi più vecchi, riassumere periodicamente la storia in un messaggio compatto, oppure conservare solo i turni rilevanti. Il messaggio system va di norma preservato sempre, perché definisce le regole di comportamento.

Streaming delle risposte

Per default una chat completion restituisce la risposta completa in un colpo solo: l’utente attende finché tutto il testo non è pronto. Con lo streaming, invece, il modello invia la risposta in modo incrementale, pezzo dopo pezzo, man mano che viene generata. Il client riceve una sequenza di frammenti e li mostra progressivamente, esattamente come l’effetto “che digita” delle interfacce di chat moderne.

Lo streaming non rende il modello più veloce, ma riduce la latenza percepita: l’utente vede le prime parole quasi subito. Il trade-off è che la logica lato client diventa più complessa. I frammenti vanno accumulati per ricostruire la risposta finale, la gestione degli errori a metà stream è più delicata, e alcune operazioni di post-elaborazione (validazione, parsing di output strutturato) sono più difficili finché il testo non è completo. Per risposte brevi o per elaborazioni batch automatiche, la modalità non-streaming è spesso più semplice.

Cosa ti dà l’SDK

Rispetto a chiamare direttamente l’endpoint REST, l’SDK di Foundry gestisce per te l’autenticazione (tipicamente con Microsoft Entra ID o con chiavi), la serializzazione dei messaggi, la selezione del deployment e spesso politiche di retry. Offre inoltre un modello di codice più portabile fra i diversi modelli del catalogo. Per i dettagli operativi esatti — nomi dei metodi, parametri, opzioni di configurazione — fai sempre riferimento alla documentazione ufficiale, perché Foundry è un prodotto recente e in evoluzione.

Trappole tipiche d’esame

  • “Il modello non ricorda i turni precedenti” → invia tutta la storia: l’operazione è stateless; è il client a dover accumulare e rinviare i messaggi, non il servizio a memorizzarli.
  • Conversazione lunga che degrada o dà errore → context window/token: superato il limite di token del modello serve troncare o riassumere la storia, non semplicemente “aumentare la memoria”.
  • Serve mostrare la risposta subito all’utente → streaming: lo streaming riduce la latenza percepita mostrando i frammenti progressivamente, ma non aumenta la velocità reale del modello.
  • Output da validare o parsare a livello di programma → non-streaming: per elaborare la risposta completa (es. JSON strutturato) la modalità non-streaming semplifica la logica; con lo streaming devi prima riassemblare i frammenti.
  • Cambiare comportamento dell’assistente → messaggio system: tono e regole si impostano nel messaggio con ruolo system, non ripetendo istruzioni in ogni messaggio user.
  • Domanda su come autenticarsi → Entra ID / SDK: l’SDK gestisce autenticazione e retry; evita di ricostruire a mano le chiamate REST se punti a portabilità e sicurezza.