Provalo, Parte 2: Logica formale, policy Cedar ed economia della verifica

Il ragionamento automatico aggiunge la verifica agli output di LLM traducendo le politiche aziendali in logica formale e confrontandole con tali regole. Rileva le incongruenze, impone i vincoli di conformità e controlla le azioni degli agenti con una copertura completa a una frazione del costo del controllo qualità manuale.

Nella Parte 1 ("Probabilmente corretto non è sufficiente"), abbiamo spiegato perché le startup che sviluppano applicazioni di intelligenza artificiale necessitano di una verifica deterministica, non solo di misure di sicurezza probabilistiche. In questo post, andiamo a fondo. Se sei un co-fondatore tecnico, un responsabile dell'ingegneria o uno sviluppatore senior in una startup di IA, qui scoprirai come funziona effettivamente il ragionamento automatico, cosa succede quando il tuo LLM genera una risposta e la logica formale la verifica, e perché, dal punto di vista economico, questa soluzione è la scelta migliore rispetto all'assunzione di team di controllo qualità.

In questo post non è presente alcun codice API. Quello verrà trattato nella Parte 3. Qui ci concentriamo sui concetti, sulla logica formale e sulla pipeline di verifica, in modo che tu possa comprendere appieno ciò che stai costruendo.

Stocastico vs. deterministico: la distinzione fondamentale

Prima di addentrarci nei dettagli tecnici, è opportuno chiarire la distinzione fondamentale, poiché essa influenza ogni decisione architetturale che prenderete.

Gli LLM sono stocastici.

Prevedono il token successivo basandosi su distribuzioni di probabilità apprese dai dati di addestramento. I parametri di campionamento Temperature, top-k e top-p introducono una casualità intenzionale. Eseguendo lo stesso prompt due volte, si potrebbero ottenere risposte diverse. Questa è una caratteristica, non un bug: è ciò che rende i modelli linguistici lineari flessibili, creativi e capaci di gestire diversi input in linguaggio naturale. Ma significa anche che ogni singolo output è un campione estratto da una distribuzione di probabilità, non un dato di fatto comprovato.

Il ragionamento automatico (AR) è corretto.

Dati un insieme di regole e un input, il risultato non è una semplice ipotesi. È una dimostrazione. Un'affermazione è dimostrabilmente valida rispetto alle regole, dimostrabilmente non valida oppure il sistema indica con precisione quali informazioni mancano o sono ambigue. Se la risposta è errata, AR non si limita a segnalarla, ma fornisce un controesempio che mostra esattamente perché non funziona. L'output è matematicamente verificabile, non probabilistico. Non ci sono parametri di regolazione. Non c'è campionamento. C'è una dimostrazione che è possibile esaminare.

Non si tratta di stabilire quale approccio sia "migliore" dell'altro. I modelli di logica formale (LLM) sono più abili nel comprendere il linguaggio naturale e nel generare risposte simili a quelle umane. La realtà aumentata (AR) è più efficace nel verificare la correttezza logica di tali risposte. Insieme, formano l'intero sistema: l'LLM gestisce la conversazione, l'AR si occupa della correttezza logica. Questa combinazione di reti neurali e logica formale è ciò che i ricercatori chiamano intelligenza artificiale neurosimbolica.

Per una startup di cinque persone che si appresta a consegnare i suoi primi 100 clienti, questa distinzione ha una conseguenza molto pratica. Non si dispone del personale necessario per un team di controllo qualità e non si ha il margine di manovra per gestire un problema di conformità. La verifica formale diventa un moltiplicatore di forze che permette a un piccolo team di rilasciare prodotti con la sicurezza di un team molto più grande.

Quali sono i due livelli di protezione in Amazon Bedrock?

AWS offre AR su due livelli, che si adattano perfettamente alla curva di maturità della maggior parte delle startup di IA. Quando sei in fase iniziale, il tuo prodotto è probabilmente un chatbot o un assistente: un LLM che risponde alle domande dei clienti, genera raccomandazioni o fornisce indicazioni. In questa fase, il ragionamento automatico in Amazon Bedrock Guardrails verifica il contenuto degli output del modello rispetto alle regole aziendali definite

Man mano che cresci, inizi a costruire flussi di lavoro agentici: la tua IA prenota appuntamenti, elabora rimborsi, interroga database, chiama API esterne. A questo livello, Policy in Amazon Bedrock AgentCore regola quali azioni un agente è autorizzato a intraprendere utilizzando le policy Cedar applicate al gateway prima dell'esecuzione di qualsiasi strumento.

Le policy Cedar regolano le azioni che un agente può compiere. Tuttavia, è anche possibile esporre l'API di verifica di AR come strumento nel set di strumenti dell'agente, consentendogli di convalidare le proprie conclusioni intermedie prima di agire di conseguenza. L'agente richiama ApplyGuardrail sulla policy, analizza i risultati e si autocorregge senza coinvolgere l'utente. Un agente che pianifica un flusso di lavoro a più fasi può verificare se la sequenza proposta viola qualche vincolo, individuare una contraddizione nelle sue ipotesi o confermare che un valore derivato derivi effettivamente dagli input. Questo trasforma AR da un semplice controllo dei limiti a un partner di ragionamento: l'agente non si limita a bloccarsi all'ingresso, ma evita fin dall'inizio di arrivarci.

Ecco come si confrontano:

I controlli AR e Policy in Amazon Bedrock AgentCore proteggono i diversi livelli della tua applicazione.

• I controlli AR convalidano quanto affermato dall'IA, ovvero se la risposta relativa all'ammissibilità al mutuo è corretta in base ai criteri di concessione del credito?
• Policy in Amazon Bedrock AgentCore controlla ciò che fa la tua intelligenza artificiale, ovvero l'agente è autorizzato ad avviare un rimborso o a effettuare verifiche sull'account di un cliente?

 A seconda di cosa stai costruendo oggi, potresti iniziare con uno o entrambi.

• Se il tuo MVP è un chatbot che risponde a domande sulle policy, i controlli AR sono la prima integrazione da effettuare.
• Se stai affidando la spedizione a un agente che si occupa di fissare appuntamenti e movimentare denaro, la politica aziendale non è negoziabile fin dal primo giorno.

La maggior parte delle startup finirà per gestirli entrambi contemporaneamente.

Come funzionano i controlli AR: codificare le regole aziendali come logica formale

L'input per il ragionamento automatico è una policy, e una policy inizia con i documenti che già possiedi.

Se sei una startup fintech, potrebbe trattarsi di un documento sui criteri di concessione del credito. Nel settore sanitario, potrebbero essere protocolli clinici o procedure di gestione HIPAA. Nel settore assicurativo, linee guida di sottoscrizione. Questi documenti definiscono cosa la tua IA dovrebbe e non dovrebbe dire. Sono stati esaminati dai tuo consulenti legali. I tuoi investitori ne hanno chiesto informazioni durante la due diligence. La realtà aumentata trasforma questi artefatti esistenti in regole vincolanti. Non stai costruendo qualcosa di nuovo da zero: stai attivando qualcosa che già possiedi.

Quando carichi un documento di policy (PDF, Markdown o testo semplice) in Amazon Bedrock, il sistema estrae due elementi: variabili e regole.

Le variabili rappresentano i concetti del tuo dominio. Ogni variabile ha un nome, un tipo e una descrizione. Ad esempio, in una policy di ammissibilità ai mutui:

La descrizione delle variabili è il fattore più importante in assoluto per garantire l'accuratezza. Descrizioni vaghe lasciano il sistema di gestione del linguaggio naturale (LLM) incapace di interpretare correttamente il significato di una variabile. Descrizioni dettagliate che spieghino il significato del concetto, come gli utenti lo utilizzano e come appare nei documenti normativi, forniscono al sistema LLM il contesto necessario per mappare il linguaggio naturale alle variabili formali corrette. È qui che la tua esperienza nel settore, in quanto fondatore di una startup, diventa fondamentale.

Le regole sono espressioni logiche formali che catturano le relazioni tra le variabili. Usano un sottoinsieme della sintassi SMT-LIB e la maggior parte segue un formato if-then (implicativo):

Questo è ciò che Bedrock genera dietro le quinte quando carichi il documento della tua polizza ipotecaria. Puoi rivedere queste regole nella console per verificare che il sistema abbia catturato correttamente il tuo intento, ma non stai scrivendo SMT-LIB manualmente. Scrivi la policy in linguaggio naturale e il sistema la traduce in logica formale.

Il processo di verifica in due passaggi

Una volta configurata una policy AR e collegata a un guardrail (come descritto nella Parte 3), ogni risposta LLM inviata dall'applicazione ad ApplyGuardrail viene sottoposta a un processo di verifica in due fasi. Comprendere questa suddivisione è fondamentale perché indica dove concentrare gli sforzi.

Fase 1: Traduzione

Il sistema converte il linguaggio naturale presente sia nella domanda dell'utente che nella risposta dell'LLM in predicati di logica formale, ovvero affermazioni come "guadagno >= 180 e guadagno <= 220", anziché in semplici assegnazioni, utilizzando le variabili dichiarate nella polizza. È qui che entrano in gioco le descrizioni delle variabili.

Ad esempio, se la risposta dice "un cliente con un acconto di 30.000 dollari USA su una casa da 350.000 dollari USA ha diritto a un mutuo convenzionale", la fase di traduzione produce: downPaymentAmount = 30000, purchasePrice = 350000, mortgageType = CONVENTIONAL.

Il fatto che utilizziamo LLM per tradurre il linguaggio naturale di input in logica è il motivo per cui il sistema dichiara un'accuratezza di verifica fino al 99%. Per garantire la correttezza della nostra traduzione, non ci affidiamo a un solo LLM. Al contrario, utilizziamo più LLM a temperature diverse in parallelo per eseguire la stessa traduzione. Solo quando le traduzioni ridondanti sono semanticamente equivalenti possiamo generare un risultato di validazione. In caso di disaccordo tra le traduzioni, restituiamo un risultato AMBIGUOUS che include due possibili interpretazioni dell'input. Il tuo LLM può utilizzare questo feedback per disambiguare la sua risposta o porre all'utente domande di chiarimento. Quando abbiamo confrontato il nostro sistema con il set di dati di QA condizionale della Carnegie Mellon, in oltre il 99% dei casi in cui una risposta è stata contrassegnata come VALID dal nostro sistema, il contrassegno era corretto. Puoi trovare maggiori dettagli sulla metodologia in questo articolo.

Fase 2: Verifica

Un risolutore di Satisfiability Modulo Theories (SMT) valuta se le assegnazioni tradotte soddisfano tutte le tue regole politiche. Questo passaggio è matematicamente valido per definizione. Una volta che la traduzione è corretta, la verifica è dimostrabilmente corretta.

Per l'esempio del mutuo: il risolutore calcola downPaymentPercentage = (30000 / 350000) * 100 = 8,57%, lo confronta con la regola (=> (< downPaymentPercentage 20,0) (non (= mortgageType CONVENTIONAL))), rileva che 8,57 < 20 e conclude che mortgageType = CONVENTIONAL non è logicamente valido. Il sistema restituisce un risultato non valido con una traccia completa che mostra esattamente quale regola è stata violata e perché.

Il consiglio pratico per chi avvia una startup? La qualità della traduzione è qualcosa che tu puoi controllare attraverso descrizioni più accurate delle variabili. Non ci si deve preoccupare della matematica di verifica. Basta investire nella descrizione accurata del proprio dominio e il risolutore si occuperà del resto.

Cosa significano i risultati?

I controlli AR non si limitano a restituire un semplice "superato" o "non superato". Forniscono risultati strutturati che indicano esattamente cosa è successo e cosa fare in seguito. Ogni risultato rientra in una delle seguenti tipologie:

Questo è importante: i controlli AR operano in modalità di rilevamento. Restituiscono risultati e feedback, ma non bloccano la risposta. La tua applicazione esamina i risultati e decide cosa fare: fornire il contenuto, riscriverlo, chiedere chiarimenti o ripiegare su un'opzione predefinita sicura. Questo ti offre il pieno controllo sull'esperienza utente, garantendoti al contempo una verifica matematica per ogni risposta. Per un esempio pratico di questo modello, consulta l'implementazione open source del chatbot di riscrittura, che mostra come acquisire i risultati AR e inviarli al LLM per la correzione automatica.

Policy di AgentCore: limiti deterministici per gli agenti IA

Se la tua startup sta sviluppando applicazioni agentiche, in cui l'IA orchestra flussi di lavoro a più fasi, richiama strumenti e intraprende azioni per conto degli utenti, hai un problema di fiducia diverso. Non si tratta solo di ciò che dice l'IA, ma di ciò che fa.

Per le startup nei settori sanitario, fintech o legale, "l'agente ha fatto qualcosa di inaspettato" non è accettabile dal punto di vista della conformità o della regolamentazione. Sono necessari limiti dimostrabili al comportamento dell'agente, e tali limiti devono rimanere validi anche quando l'agente viene manipolato tramite iniezione di prompt o commette un errore di ragionamento.

Policy in Amazon Bedrock AgentCore risolve questo problema con un livello di autorizzazione applicato a ogni interazione agente-strumento al confine del gateway. Le policy sono scritte in Cedar, il linguaggio di autorizzazione creato da AWS per essere verificate con il ragionamento automatico. Le policy Cedar definiscono chi (principale) può fare cosa (azione) su quale risorsa e in quali condizioni. Nessuna chiamata allo strumento passa attraverso il gateway senza un permesso corrispondente. Puoi scrivere le policy direttamente in Cedar o descrivere le tue regole in linguaggio naturale e lasciare che il sistema generi il codice Cedar per te.

Prima che le tue policy vengano implementate, il ragionamento automatico esegue una convalida semantica per individuare i problemi, tra cui:

• Policy eccessivamente permissive che consentirebbe tutte le richieste per una determinata combinazione principale/azione/risorsa
• Policy eccessivamente restrittive che negherebbero tutto
• Policy inefficaci in cui un permesso non consente nulla o un divieto non vieta nulla

L'applicazione delle norme si basa su due principi particolarmente importanti per le startup che operano in settori regolamentati:

1. Negazione predefinita: se nessuna policy consente esplicitamente un'azione, questa viene bloccata. Il tuo agente non può fare nulla che tu non abbia autorizzato.
2. Il divieto vince sempre sul permesso: è possibile impostare regole di blocco rigide che non possono essere ignorate, indipendentemente da qualsiasi altra policy esistente.

Immaginiamo una startup del settore sanitario che sviluppa un sistema di prenotazione appuntamenti. Con la policy AgentCore è possibile imporre che i pazienti accedano solo alle proprie cartelle cliniche, che le prenotazioni degli appuntamenti siano limitate agli orari di apertura e che gli importi dei rimborsi siano vincolati da una policy. Queste regole rimangono valide indipendentemente da come viene richiesto all'agente, da eventuali bug presenti nel codice o da quanto fantasiose siano le richieste dell'utente. L'applicazione delle regole avviene a livello di gateway, completamente al di fuori dell'agente.

Quanto costa il ragionamento automatico rispetto al controllo qualità manuale?

Per comprendere l'aspetto economico del ragionamento automatico, è utile confrontarlo con il metodo di riferimento attualmente utilizzato dalla maggior parte dei team: la revisione manuale del controllo qualità degli output del modello.

Alla vecchia maniera: il controllo della qualità manuale

Un revisore che verifica gli output dell'IA può gestire circa 50 interazioni all'ora, con un costo di circa 40 dollari all'ora. Per una startup che gestisce 100.000 interazioni con i clienti al mese, la revisione di ogni interazione costa 80.000 dollari al mese. Anche campionando il 10% costa 8.000 dollari al mese, e il restante 90% non è ancora verificato. Considerando un costo annuo per revisore compreso tra 80.000 e 150.000 dollari, un team di 5-10 revisori arriva a costare dai 400.000 a 1,5 milioni di dollari all'anno. Per la maggior parte delle startup, si tratta di una fetta significativa del budget destinata alla verifica della correttezza dell'IA.

Il nuovo metodo: il ragionamento automatico

Il prezzo dei controlli AR viene calcolato in base alla richiesta di convalida. I prezzi esatti devono essere confermati nella pagina dei prezzi di Bedrock poiché le tariffe possono variare. A differenza della revisione manuale, ogni interazione può essere verificata anziché campionata. Amazon Bedrock Guardrails utilizza unità di testo come unità di convalida, dove ogni unità di testo è composta da 1.000 caratteri. Ecco come si presenta una tipica startup:

Preventivi

Calcolo

Utilizzando l'esempio precedente di una startup che gestisce 100.000 interazioni al mese e ipotizzando che l'output di ogni interazione sia di circa 200 token, possiamo facilmente stimare il costo dell'utilizzo dei controlli AR per la convalida. Amazon Bedrock Guardrails misura l'utilizzo in unità di testo, dove un'unità di testo corrisponde a 1000 caratteri. Utilizzando una media di 4 caratteri per token, stimiamo che ogni interazione sia di circa 800 caratteri e quindi 0,8 unità di testo.

La convalida di 100.000 interazioni da 0,8 unità di testo ciascuna ci fornisce un totale di 80.000 unità di testo al mese. Considerando che il costo dei controlli AR è di 0,17 dollari ogni 1.000 unità di testo, il costo mensile totale per una singola policy sarebbe di 13,60 dollari. Con l'applicazione di più policy, i costi aumentano linearmente. Anche con più policy, il costo totale rimane notevolmente inferiore rispetto alla revisione manuale.

I calcoli relativi alla conformità sono ancora più convincenti. Una singola violazione della normativa HIPAA può costare fino a 2.067.813 dollari all'anno, tenendo conto dell'inflazione attuale. Per una startup del settore sanitario, la cui intelligenza artificiale elabora migliaia di interazioni con i pazienti ogni giorno, il rischio normativo derivante da risultati non verificati è di vitale importanza. In questo contesto, il ragionamento automatico funziona meno come una spesa per il software e più come uno strumento di controllo per la gestione del rischio.

Per gli sviluppatori, l'analogia più calzante è il borrow checker di Rust. Rust rileva la corruzione della memoria in fase di compilazione, prima che il codice raggiunga l'ambiente di produzione. AR, invece, rileva le violazioni delle policy in fase di verifica, prima che raggiungano il cliente. Individuare gli errori prima che causino danni è sempre più economico che correggerli in seguito.

C'è un compromesso: la convalida AR aggiunge latenza a ogni risposta e la riscrittura implica che il tuo LLM venga eseguito due volte sugli output segnalati. Per la maggior parte delle applicazioni, tuttavia, questi costi sono irrisori rispetto all'impatto operativo, legale o reputazionale di un output errato.

Lo stesso ragionamento trova riscontro anche tra gli investitori. Poter affermare che i risultati dell'IA vengono sistematicamente verificati rispetto alle politiche aziendali formali non è semplicemente una caratteristica del prodotto. È la prova che il rischio viene gestito in modo proattivo. Questo è il tipo di affermazione concreta e verificabile che rafforza il profilo di rischio di una startup.

E cosa succede dopo?

Nella Parte 3: Playbook di implementazione passo passo, passiamo dai concetti al codice. Imparerai come creare una policy AR a partire dai tuoi documenti esistenti, distribuirla su un guardrail, integrarla con l'API ApplyGuardrail, gestire i risultati a livello programmatico, configurare la policy AgentCore tramite AgentCore Gateway e creare un audit trail. Tutto ciò che ti serve per passare dalla lettura della verifica matematica alla sua implementazione in produzione.