CAPIRE L’IA · 12 di N
«Come apro una richiesta di assistenza?» e «Apri una richiesta di assistenza per questo problema» sembrano domande vicine. La prima chiede una spiegazione. La seconda chiede una modifica in un sistema esterno.
È qui che il discorso sugli agenti diventa concreto. Un testo corretto non basta più: occorrono identificativi, strumenti, autorizzazioni e prove dell’esito. Il sistema deve collegare ciò che propone a ciò che è realmente accaduto.
Che cosa intendiamo per agente?
Non esiste un unico confine terminologico condiviso. Qui chiamiamo agente basato su LLM un sistema che usa un modello per scegliere passi operativi verso un obiettivo, invoca strumenti e utilizza le osservazioni ottenute per decidere come proseguire.
Il modello è una componente. Intorno ci sono software di orchestrazione, stato, strumenti, credenziali, controlli e criteri di arresto. Dare un nome umano al sistema non aggiunge nessuna di queste capacità.
È utile distinguere un workflow, il cui percorso è in gran parte definito dal codice, da un agente che decide dinamicamente una parte dei passi. Il contributo di Anthropic su come costruire agenti efficaci usa questa distinzione e sottolinea il valore di soluzioni semplici, verificabili e proporzionate al compito.
Un esempio: segnalare una stampante guasta
Immaginiamo un assistente interno e un utente autorizzato: «La stampante PR-204 non stampa. Apri una segnalazione e dammi il numero del ticket». L’identificativo e il caso sono inventati.
Un chatbot senza strumenti può spiegare la procedura o preparare il testo. Un sistema collegato al gestionale può cercare il dispositivo, verificare se esiste già una segnalazione aperta, creare il ticket e leggere l’identificativo restituito.
Se ci sono due dispositivi con nomi simili, deve risolvere l’ambiguità. Se il gestionale non risponde, non può sostituire il risultato con un numero plausibile. L’obiettivo comprende sia l’azione sia una conferma fondata sul suo esito.
La chiamata a uno strumento è un’uscita strutturata
Il modello può produrre una richiesta del tipo: usare lo strumento «crea_ticket» con dispositivo «PR-204», categoria «stampa» e descrizione del problema. È una struttura di dati, spesso codificata in JSON.
Questa richiesta non esegue da sola l’azione. Il software deve controllare nome dello strumento, argomenti, identità dell’utente e permessi; poi può invocare l’API del gestionale. La risposta dello strumento viene riportata al sistema come osservazione.
Si distinguono quindi tre momenti: proposta del modello, esecuzione autorizzata dal software e risultato osservato. Confonderli porta alla frase più pericolosa in questo esempio: «Ticket creato», quando è stato soltanto preparato il comando.
Un ciclo con stato e condizioni di uscita
Il sistema conserva informazioni rilevanti: dispositivo selezionato, dati già raccolti, strumenti chiamati, risultati e passi ancora da completare. Questo stato può vivere nel contesto, in una struttura esterna o in entrambi. Non implica che il modello si riaddestri a ogni passo.
Dopo la ricerca dei ticket esistenti, l’agente può scegliere un ramo. Se trova una segnalazione pertinente, può comunicarne lo stato secondo le regole del servizio. Se non la trova, può proporre la creazione. Se mancano dati necessari, può chiederli.
Un piano iniziale aiuta, ma non è una prova che i passi siano stati eseguiti. Le osservazioni possono costringere a cambiarlo. Servono anche limiti: numero massimo di tentativi, tempo disponibile, budget e condizioni che richiedono il passaggio a un operatore.
Gli errori cambiano natura quando si agisce
Una risposta sbagliata può essere corretta in una conversazione. Un’azione può aver già modificato un archivio, inviato una comunicazione o consumato una risorsa. L’affidabilità deve quindi riguardare l’intera sequenza operativa.
Supponiamo, in un modello puramente didattico, che cinque passi indipendenti abbiano ciascuno probabilità 0,95 di riuscita e che tutti siano necessari. La probabilità di riuscita completa è 0,95⁵ ≈ 0,774. Non è una stima delle prestazioni di un agente reale: i passi possono essere dipendenti e controlli o recuperi cambiano il risultato.
Il conto mostra però perché una buona prestazione locale non basta. Bisogna misurare il completamento del compito, la correttezza delle modifiche e la gestione degli errori, non soltanto la qualità del testo finale.
Un timeout non significa che nulla sia accaduto
Nel nostro esempio il gestionale potrebbe creare il ticket ma perdere la risposta a causa di un’interruzione di rete. Se l’agente ripete subito la creazione, può generare un doppione.
Una soluzione progettuale è usare un identificativo univoco dell’operazione e un’API che supporti l’idempotenza: ripetere la stessa richiesta non deve creare nuove copie dell’effetto. Dove non è disponibile, occorrono controlli specifici dello stato prima di riprovare.
Il risultato finale dovrebbe distinguere «operazione riuscita», «operazione fallita» ed «esito ancora incerto». L’incertezza di esecuzione è una condizione operativa reale, non un difetto da nascondere con una frase rassicurante.
Il controllo umano deve avere un oggetto preciso
Chiedere «Confermi?» a ogni passo può diventare un gesto automatico. È più utile stabilire quali operazioni sono già autorizzate e per quali serve una revisione, mostrando in quel momento il destinatario, i dati e l’effetto previsto.
Nel nostro caso, leggere il dispositivo e verificare ticket aperti può rientrare nell’incarico. Creare la segnalazione può essere già autorizzato dalla richiesta esplicita dell’utente e dalle regole del servizio. Inviare comunicazioni ad altri soggetti o modificare configurazioni richiede una valutazione diversa: non discende automaticamente dall’obiettivo di aprire un ticket.
I controlli devono essere applicati dal software: strumenti disponibili, permessi limitati, validazione degli argomenti e registrazione degli esiti. Una frase nel prompt che invita alla prudenza non sostituisce un vincolo tecnico.
Quando una fonte prova a diventare un comando
L’agente può leggere un documento o un ticket contenente istruzioni ostili, per esempio un testo che gli chiede di ignorare l’obiettivo e inviare informazioni altrove. È il problema della prompt injection: dati provenienti dall’esterno tentano di farsi trattare come istruzioni autorevoli.
Separare i dati dai comandi, limitare strumenti e privilegi e controllare le destinazioni riduce le possibilità di azioni indebite. La questione non riguarda solo la bontà della risposta: riguarda quali effetti il sistema può produrre quando interpreta male ciò che legge.
Come valutare un agente sul serio
Per la stampante fittizia prepariamo casi verificabili: dispositivo valido, identificativo ambiguo, ticket già aperto, permesso insufficiente, timeout dopo creazione e testo ostile in un risultato. Per ciascuno definiamo stato finale atteso e azioni vietate.
Controlliamo se il ticket esiste davvero, se è associato al dispositivo corretto, se ci sono doppioni e se il numero comunicato coincide con quello del gestionale. Osserviamo anche tempo, numero di chiamate, interventi umani e capacità di fermarsi.
Questo rende la valutazione aderente al compito. Una risposta elegante può accompagnare un’azione sbagliata; una risposta breve con un identificativo verificato può rappresentare un risultato migliore.
Tre cose da conservare
- Un agente è un sistema, non soltanto un modello. Collega scelte, strumenti, stato e osservazioni.
- Proporre, eseguire e verificare sono momenti distinti. Un comando generato non dimostra un effetto nel mondo.
- L’autonomia richiede confini concreti. Permessi, controlli, gestione degli errori e intervento umano fanno parte del funzionamento.
La serie è partita da una macchina che impara e arriva a un sistema che agisce. Il filo rimane lo stesso: identificare che cosa cambia, quali calcoli vengono eseguiti e quali prove consentono di fidarsi del risultato. Sono domande utili tanto davanti a una rete piccola quanto davanti a un assistente collegato ai nostri strumenti di lavoro.
← Torna al percorso Capire l’IA
Lascia un commento