come progettiamo l'integrazione
La prima decisione è definire il compito
Dire “Vogliamo usare un LLM” non basta. Prima dello sviluppo trasformiamo l'idea in una funzione chiara e verificabile.
- Quali dati riceve in ingresso?
- Quale risultato deve produrre?
- Chi lo utilizza?
- Cosa succede se il modello sbaglia?
Non tutte le funzioni richiedono lo stesso livello di controllo.
Un riepilogo destinato a un operatore, ad esempio, può essere verificato prima dell'utilizzo. L'estrazione di dati da inserire nel gestionale richiede invece uno schema, validazioni e gestione esplicita dei campi incerti.
L'AI può inoltre prevedere un'azione la cui esecuzione deve rimanere separata e sottoposta alle autorizzazioni previste dal software.
Questa distinzione permette di scegliere il modello in base al compito e alle reali esigenze del progetto.
Consideriamo qualità sull'italiano e sul dominio, latenza (velocità), gestione di testo e immagini, quantità di informazioni da elaborare, disponibilità geografica, politiche sui dati e costo per il volume previsto.
I LIVELLI DI INTEGRAZIONE tra SOFTWARE e LLM
Progettiamo un livello di integrazione che permetta al software di utilizzare l'AI attraverso funzioni chiare e specifiche come, per esempio “classifica richiesta”, “estrai anagrafica” o “genera bozza”.
All'interno di questo livello vengono gestiti:
01 – Selezione del modello: Configurazione mirata sul compito da svolgere.
02 – Costruzione delle istruzioni e del contesto: Definizione delle informazioni e delle indicazioni necessarie per ottenere risultati coerenti ed utili.
03 – Adattamento formati: conversione automatica dei messaggi secondo le specifiche del fornitore/modello.
04 – Validazione output: Verifica che i risultati prodotti rispettino i formati e requisiti previsti.
05 – Gestione degli errori: Definiamo tempi massimi, nuovi tentativi e soluzioni alternative in caso di problemi.
06 – Registrazione di metriche tecniche e di qualità: Raccolta di dati per verificare prestazioni, affidabilità e costi.
L’integrazione deve semplificare l’utilizzo dei modelli senza nasconderne le differenze. Alcune funzionalità possono infatti essere specifiche di un determinato modello e rappresentare un vantaggio importante.
Per questo manteniamo queste dipendenze ben separate e visibili, così il software può sfruttare le caratteristiche migliori di ogni soluzione senza diventare legato in modo rigido a un unico fornitore.
Output strutturato,
non testo da interpretare nuovamente
Se il risultato dell'AI deve alimentare il software, non basta che sia una frase plausibile: deve rispettare criteri precisi.
Per questo il modello restituisce una struttura dati che viene verificata prima dell'utilizzo.
Immaginiamo la classificazione di una richiesta di assistenza. La risposta può contenere categoria, priorità proposta, reparto e motivazione. Il backend controlla che i valori appartengano ai campi previsti, applica eventuali regole deterministiche e decide se salvare il risultato o sottoporlo a una persona.
Per l'estrazione documentale distinguiamo inoltre tra valore/informazione assente e valore/informazione incerto. Forzare sempre una risposta aumenta il rischio di dati inventati.
Quando necessario, è possibile anche conservare il testo o il passaggio da cui è stata ricavata l’informazione, così da renderne più semplice la verifica.
DEFINIZIONE SCHEMA
campi
tipi
valori ammessi
Sicurezza & Affidabilità del Flusso
Una Infrastruttura progettata
per essere affidabile
SOLO I DATI DAVVERO NECESSARI: CONTESTO MINIMO, PERTINENTE E AUTORIZZATO
Inviare al modello tutto ciò che il software conosce è costoso e aumenta l’esposizione di informazioni non realmente necessarie. Per ogni operazione selezioniamo soltanto il contesto utile e le informazioni necessarie: dati dell’utente loggato, stato corrente dell’applicazione e documenti che l’utente è autorizzato a consultare.
Le autorizzazioni vengono sempre controllate dal software prima di inviare i dati al modello tramite chiamata API. Credenziali, informazioni riservate e campi sensibili vengono esclusi, filtrati o anonimizzati preventivamente.
Valutiamo anche le condizioni offerte dal fornitore: trattamento dei dati, conservazione, area geografica di elaborazione e opzioni contrattuali. La decisione finale sul modello dipende dalla natura dei dati e dalle regole dell’organizzazione, non solo dalle prestazioni del modello.
MISURABILITÀ DELLA QUALITÀ
Un test tradizionale può verificare che l’API risponda e che il formato sia valido. Questo però non dimostra che il contenuto sia utile. Per questo prepariamo esempi rappresentativi con un risultato atteso o criteri di valutazione condivisi.
La verifica della qualità combina controlli differenti:
- automatici: schema, campi obbligatori, valori ammessi, presenza di contenuti vietati;
- basati su casi: confronto con classificazioni, estrazioni o risposte di riferimento;
- manuali: utilità, chiarezza e adeguatezza valutate da chi conosce il processo;
- operativi: percentuale di revisioni, correzioni, rifiuti e passaggi a una persona.
Questi test vengono mantenuti nel tempo. Quando si modifica un prompt, un modello o una fonte, possiamo confrontare la nuova configurazione con quella precedente e individuare regressioni prima del rilascio.
FALLBACK: COSA ACCADE QUANDO IL MODELLO NON è DISPONIBILE
L’utilizzo di un secondo fornitore non è automaticamente un buon percorso alternativo. Può interpretare le istruzioni in modo diverso, avere capacità differenti o restituire un altro formato. Per questo anche le alternative devono essere progettate e testate per l’operazione specifica.
A seconda del processo, la risposta corretta può essere riprovare la richiesta, usare un modello alternativo, mettere la richiesta in coda, tornare a una regola tradizionale del software oppure chiedere l’intervento di un operatore.
Per un’attività interattiva in tempo reale il tempo massimo di risposta dovrà essere breve; per un’elaborazione asincrona può essere preferibile attendere senza perdere il lavoro.
Il sistema deve distinguere un errore del fornitore, un limite di utilizzo, un output non valido e un problema in uno strumento interno. Questa diagnosi evita tentativi inutili e rende l’assistenza più rapida.
MONITORARE UTILIZZO, PRESTAZIONI E COSTI
Il costo di una funzione AI dipende da diversi fattori:
- volume (quantità di richieste),
- lunghezza del contesto (quantità di informazioni elaborate),
- modello utilizzato,
- eventuali nuovi tentativi,
- servizi e funzioni collegate
Monitoriamo consumi e tempi di risposta per funzione, cliente o ambiente secondo le esigenze del prodotto. In questo modo è possibile individuare richieste troppo estese, configurazioni inefficienti e utilizzi anomali.
I registri devono essere utili senza diventare una copia indiscriminata di dati e conversazioni. Separiamo metriche, tracciamento tecnico e contenuti, applicando tempi di conservazione e livelli di accesso adeguati. Per ogni esecuzione può essere importante ricostruire versione del prompt, modello, parametri, strumenti chiamati ed esito della validazione.
Dalla prova
alla funzione mantenibile
DEFINIZIONE
Delimitiamo compito, utenti, dati, rischio e criterio di successo
CONFRONTO
Proviamo modelli e strategie su esempi reali, senza decidere in base a una singola demo
ARCHITETTURA
Separiamo integrazione, istruzioni, validazione e logica di dominio
SVILUPPO
Colleghiamo la funzione al software con autenticazione, limiti e gestione degli errori
VALUTAZIONE
Costruiamo test ripetibili e una revisione da parte degli utenti competenti
rilascio
Osserviamo qualità, latenza e consumo prima di ampliare il perimetro
Possiamo intervenire su un prodotto in fase di analisi oppure su codice già esistente. In entrambi i casi, il primo confronto serve a individuare dipendenze dal fornitore, dati coinvolti, requisiti di output e comportamento atteso in caso di errore.