In che modo l’Event Sourcing preserva una traccia di audit per le decisioni degli agenti IA?
Il sourcing degli eventi conserva una traccia di audit degli agenti IA registrando ogni decisione accettata e ogni modifica di stato come un evento ordinato, invece di sovrascrivere un unico stato corrente mutabile.
Su un server domestico, questo rende ricostruibile l'automazione in più passaggi: al termine del flusso di lavoro, un operatore può ripercorrere la proposta, l'approvazione, la chiamata allo strumento, l'errore, il nuovo tentativo, la compensazione e lo stato finale.
Il sourcing degli eventi archivia le modifiche di stato come record principale
Il sourcing degli eventi registra ogni modifica di stato accettata come un evento, invece di considerare l'ultima riga mutabile come unica fonte di verità. Lo stato corrente viene derivato dalla cronologia ordinata.
Martin Fowler definisce il sourcing degli eventi come l'archiviazione di ogni modifica allo stato dell'applicazione sotto forma di sequenza di eventi. La cronologia conserva il modo in cui il sistema è arrivato a un determinato stato. Martin Fowler descrive il sourcing degli eventi basandosi sull'archiviazione delle modifiche di stato come sequenza di eventi, catturando così l'idea del record principale utilizzata nell'articolo di Martin Fowler sul sourcing degli eventi.
Per un agente IA domestico, ProposalCreated, ApprovalGranted, ToolCallStarted, ToolCallFailed e CompensationCompleted possono rimanere fatti distinti, invece di essere compressi in un unico campo di stato.
Ogni decisione dell'agente diventa un fatto ordinato temporalmente
Un evento dovrebbe descrivere qualcosa che è già accaduto e contenere un contesto sufficiente per interpretarlo in seguito: ID del flusso di lavoro, strumento, hash dei parametri, risultato della policy, esito della decisione e timestamp, se appropriato.
Fowler osserva che, con il sourcing degli eventi, l'archivio degli eventi diventa la principale fonte di verità e lo stato può essere ricostruito tramite replay. Questa sequenza ordinata crea un percorso di audit causale. Microsoft Azure descrive un archivio di eventi in sola aggiunta, in cui gli eventi rappresentano le modifiche allo stato dell'applicazione e supportano i fatti decisionali ordinati temporalmente nel modello Azure per il sourcing degli eventi.
L'oggetto di audit utile è l'artefatto decisionale osservabile, non il ragionamento privato nascosto: quale azione è stata proposta, quale policy l'ha valutata, quale risultato è stato restituito e quale effetto collaterale si è verificato concretamente.
Le proiezioni trasformano il registro degli eventi in viste correnti
Riprodurre l'intera cronologia per ogni schermata o richiesta dell'agente sarebbe inefficiente.
I sistemi basati sul sourcing degli eventi creano proiezioni come lo stato corrente del flusso di lavoro, le approvazioni in sospeso o gli errori recenti.
Il sourcing degli eventi può ricostruire lo stato corrente dell'applicazione dagli eventi registrati. Una proiezione può quindi essere ricostruita se cambiano la sua logica o il database. Le indicazioni di AWS descrivono la derivazione dello stato corrente dagli eventi persistiti e illustrano come le proiezioni possano creare viste di lettura senza sostituire la cronologia sottostante nelle indicazioni di AWS sul sourcing degli eventi.
Su un piccolo server, gli snapshot possono ridurre il tempo di replay mentre gli eventi rimangono autorevoli. Lo snapshot è una scorciatoia per le prestazioni; la sequenza degli eventi è la cronologia.
Gli ID di correlazione collegano il lavoro in più passaggi in un'unica cronologia decisionale
Una richiesta può attivare recupero di informazioni, pianificazione, approvazione, diverse chiamate agli strumenti, nuovi tentativi e compensazione.
Un ID di correlazione raggruppa questi eventi in un'unica operazione coerente.
Questo è diverso dal semplice archiviare i log altrove. L'isolamento dei log di audit esterni di ZimaSpace spiega come le prove possano sopravvivere alla compromissione dell'app; il sourcing degli eventi spiega come lo stato stesso del flusso di lavoro diventi una cronologia ordinata. Kurrent sottolinea l'importanza dei flussi di eventi ordinati e degli identificatori, supportando la correlazione dei passaggi correlati in un'unica cronologia decisionale tracciabile nei concetti di Kurrent sul sourcing degli eventi.
Le due pratiche possono essere combinate: i record degli eventi alimentano il replay operativo, mentre copie orientate all'aggiunta vengono esportate verso un confine di logging separato per preservare meglio le prove.
Le correzioni aggiungono nuovi eventi invece di riscrivere la cronologia
Se in seguito si scopre che una decisione dell'agente era errata, un'architettura basata sul sourcing degli eventi registra un evento compensativo o correttivo invece di eliminare l'evento originale.
La discussione di Fowler sulla bitemporalità illustra l'idea più ampia secondo cui la cronologia dei record può rimanere in sola aggiunta anche quando nuove informazioni correggono ipotesi precedenti. Marten conserva gli eventi in una cronologia di sola aggiunta e ricostruisce da essi lo stato dell'aggregato, illustrando perché le correzioni possano essere aggiunte invece di riscrivere silenziosamente i fatti precedenti nella documentazione dell'archivio eventi Marten.
Questo è utile quando cambiano le policy o i prompt. Un operatore può vedere che un'azione è stata accettata con una determinata versione della policy e successivamente annullata, invece di vedere soltanto lo stato finale corretto.
Il sourcing degli eventi non rende automaticamente le prove a prova di manomissione
La fiducia in una cronologia degli eventi dipende dai controlli che regolano la creazione degli eventi, l'archiviazione, gli accessi, gli orologi e l'eliminazione.
Un processo autorizzato a riscrivere l'archivio può comunque distruggere la propria cronologia.
Fowler evidenzia i vantaggi di audit e delle query storiche quando il registro degli eventi rimane l'archivio autorevole delle informazioni. Durabilità e controlli sulle operazioni di aggiunta rimangono aspetti operativi distinti. Ricerche recenti applicano cronologie strutturate di eventi in sola aggiunta alle attività degli agenti autonomi, chiarendo al contempo che la logica applicativa in sola aggiunta non equivale a uno storage a prova di manomissione; si veda il sourcing degli eventi per agenti autonomi.
La progettazione degli agenti con approccio di sola lettura di ZimaSpace riduce le azioni pericolose prima che si verifichino; il sourcing degli eventi conserva le decisioni e le azioni che si sono effettivamente verificate.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Stato di runtime vs stato persistente in Home Assistant: cosa deve sopravvivere al riavvio?
Home Assistant non conserva ogni valore in tempo reale; la configurazione, i registri, gli stati selezionati ripristinati, la cronologia e i dati di distribuzione...
Come autentica Home Assistant le sessioni locali e remote?
Le sessioni Home Assistant locali e remote utilizzano lo stesso modello di identità lato server; l'accesso remoto modifica il percorso e il confine TLS,...
Perché le query della cronologia di Home Assistant possono rallentare man mano che crescono i dati del Recorder?
La crescita del registratore può aumentare il costo delle query della cronologia quando l’intervallo richiesto coinvolge più righe, aumentano i cache miss o le...
