Decadimento del contesto, deriva dell’orchestrazione e aumento dei fallimenti silenziosi nei sistemi di intelligenza artificiale

L’errore IA più costoso che ho riscontrato nelle distribuzioni aziendali non ha prodotto errori. Nessun avviso attivato. Nessun cruscotto è diventato rosso. Il sistema period pienamente operativo, ma period semplicemente costantemente e fiduciosamente sbagliato. Questo è il divario di affidabilità. Ed è il problema che la maggior parte dei programmi di intelligenza artificiale aziendale non è in grado di individuare.

Abbiamo passato gli ultimi due anni a diventare molto bravi nella valutazione dei modelli: benchmark, punteggi di precisione, esercizi con la squadra rossa, take a look at di qualità del recupero. Ma nella produzione, il modello raramente è il punto in cui il sistema si rompe. Interrompe il livello dell’infrastruttura, le pipeline di dati che lo alimentano, la logica di orchestrazione che lo avvolge, i sistemi di recupero che lo radicano, i flussi di lavoro a valle che si fidano del suo output. Questo livello viene ancora monitorato con strumenti progettati per un diverso tipo di software program.

Il divario che nessuno sta misurando

Ecco cosa rende questo problema difficile da individuare: funzionalmente sano e comportamentalmente affidabile non sono la stessa cosa e la maggior parte degli stack di monitoraggio non è in grado di distinguere.

Un sistema può mostrarsi verde in ogni parametro dell’infrastruttura, latenza all’interno dello SLA, throughput normale, tasso di errore piatto, mentre contemporaneamente ragiona su risultati di recupero che sono obsoleti da sei mesi, tornando silenziosamente al contesto memorizzato nella cache dopo che una chiamata allo strumento peggiora o propagando un’interpretazione errata attraverso cinque passaggi di un flusso di lavoro agente. Niente di tutto ciò si vede in Prometeo. Nessuno di questi attiva un avviso Datadog.

Il motivo è semplice: l’osservabilità tradizionale è stata creata per rispondere alla domanda “il servizio è attivo?” L’intelligenza artificiale aziendale richiede la risposta a una domanda più difficile: “Il servizio si comporta correttamente?” Sono strumenti diversi.

Per colmare questo divario è necessario aggiungere un livello di telemetria comportamentale accanto a quello dell’infrastruttura, non sostituendo ciò che esiste, ma estendendolo per catturare ciò che il modello ha effettivamente fatto con il contesto ricevuto, non solo se il servizio ha risposto.

Quattro modelli di guasto che il monitoraggio customary non riesce a rilevare

Nelle implementazioni di intelligenza artificiale aziendale nelle operazioni di rete, nella logistica e nelle piattaforme di osservabilità, vedo quattro modelli di errore ripetersi con sufficiente coerenza per nominarli.

Il primo è il degrado del contesto. Il modello ragiona su dati incompleti o obsoleti in un modo invisibile all’utente finale. La risposta sembra lucida. La messa a terra è scomparsa. Il rilevamento avviene solitamente settimane dopo, attraverso conseguenze a valle anziché tramite avvisi di sistema.

Il secondo è la deriva dell’orchestrazione. Le pipeline agenti raramente falliscono perché un componente si rompe. Falliscono perché la sequenza delle interazioni tra recupero, inferenza, utilizzo dello strumento e azione a valle inizia a divergere sotto il carico del mondo reale. Un sistema che sembrava stabile durante i take a look at si comporta in modo molto diverso quando la latenza si accumula tra i passaggi e i casi limite si accumulano.

Il terzo è un fallimento parziale silenzioso. Un componente ha prestazioni inferiori senza superare una soglia di avviso. Il sistema degrada comportamentalmente prima di degradarsi operativamente. Questi errori si accumulano silenziosamente ed emergono prima come sfiducia degli utenti, non come ticket di incidente. Quando il segnale raggiunge l’autopsia, l’erosione è in corso da settimane.

Il quarto è il raggio dell’esplosione dell’automazione. Nel software program tradizionale, un difetto localizzato rimane locale. Nei flussi di lavoro basati sull’intelligenza artificiale, un’interpretazione errata all’inizio della catena può propagarsi attraverso fasi, sistemi e decisioni aziendali. Il costo non è solo tecnico. Diventa organizzativo ed è molto difficile invertire la rotta.

Le metriche ti dicono cosa è successo. Raramente ti dicono cosa è quasi successo.

Perché la classica ingegneria del caos non è sufficiente e cosa deve cambiare

L’ingegneria del caos tradizionale pone il giusto tipo di domanda: cosa succede quando le cose si rompono? Uccidi un nodo. Elimina una partizione. CPU di punta. Osservare. Questi take a look at sono necessari e le imprese dovrebbero eseguirli.

Ma per i sistemi di intelligenza artificiale, i guasti più pericolosi non sono causati da guasti alle infrastrutture fisiche. Emergono a livello di interazione tra qualità dei dati, assemblaggio del contesto, ragionamento del modello, logica di orchestrazione e azione a valle. Puoi stressare l’infrastruttura tutto il giorno e non far emergere mai la modalità di guasto che ti costa di più.

Ciò di cui ha bisogno il take a look at di affidabilità dell’intelligenza artificiale è un livello basato sugli intenti: definire cosa deve fare il sistema in condizioni degradate, non solo cosa dovrebbe fare quando tutto funziona. Quindi testa le condizioni specifiche che mettono in discussione story intento. Cosa succede se il livello di recupero restituisce contenuti tecnicamente validi ma obsoleti di sei mesi? Cosa succede se un agente di riepilogo perde il 30% della sua finestra di contesto a causa di un’inflazione inaspettata dei token a monte? Cosa succede se la chiamata di uno strumento ha successo sintatticamente ma restituisce dati semanticamente incompleti? Cosa succede se un agente riprova a utilizzare un flusso di lavoro degradato e aggrava il proprio errore a ogni passaggio?

Questi scenari non sono casi limite. Sono ciò che assomiglia alla produzione. Questo è il quadro che ho applicato nella creazione di sistemi di affidabilità per le infrastrutture aziendali: creazione di livelli di caos basati sugli intenti per ambienti informatici distribuiti. L’intuizione chiave: l’intento definisce il take a look at, non solo l’errore.

Ciò di cui ha effettivamente bisogno il livello infrastrutturale

Niente di tutto ciò richiede di reinventare lo stack. Richiede l’estensione di quattro cose.

Aggiungi la telemetria comportamentale insieme alla telemetria dell’infrastruttura. Monitorare se le risposte sono state fondate, se è stato attivato un comportamento di riserva, se la fiducia è scesa al di sotto di una soglia significativa, se l’output period appropriato per il contesto a valle in cui è entrato. Questo è lo strato di osservabilità che rende tutto il resto interpretabile.

Introdurre l’inserimento di errori semantici negli ambienti di pre-produzione. Simula deliberatamente il recupero obsoleto, l’assemblaggio del contesto incompleto, il degrado delle chiamate agli strumenti e la pressione sui limiti dei token. L’obiettivo non è il caos teatrale. L’obiettivo è scoprire come si comporta il sistema quando le condizioni sono leggermente peggiori dell’ambiente di staging, che è sempre ciò che è la produzione.

Definire le condizioni di arresto sicuro prima dell’implementazione, non dopo il primo incidente. I sistemi di intelligenza artificiale necessitano dell’equivalente di interruttori automatici a livello di ragionamento. Se un sistema non è in grado di mantenere il radicamento, convalidare l’integrità del contesto o completare un flusso di lavoro con sufficiente sicurezza per essere considerato affidabile, dovrebbe arrestarsi in modo pulito, etichettare l’errore e affidare il controllo a un essere umano o a un fallback deterministico. Una battuta d’arresto aggraziata è quasi sempre più sicura di un errore fluido. Troppi sistemi sono progettati per andare avanti perché i risultati sicuri creano l’illusione della correttezza.

Assegna la proprietà condivisa per l’affidabilità end-to-end. Il fallimento organizzativo più comune è una netta separazione tra group modello, group piattaforma, group dati e group applicazione. Quando il sistema è operativamente attivo ma comportamentalmente sbagliato, nessuno ne è chiaramente padrone. Il fallimento semantico ha bisogno di un proprietario. Senza uno, si accumula.

La curva delle scadenze si sta spostando

Negli ultimi due anni, l’elemento di differenziazione dell’intelligenza artificiale aziendale è stata l’adozione: chi arriva alla produzione più velocemente. Quella fase sta finendo. Man mano che i modelli si mercificano e le capacità di base convergono, il vantaggio competitivo deriverà da qualcosa di più difficile da copiare: la capacità di gestire l’intelligenza artificiale in modo affidabile su larga scala, in condizioni reali, con conseguenze reali.

L’elemento di differenziazione di ieri è stata l’adozione del modello. Quella di oggi è l’integrazione dei sistemi. Quella di domani sarà l’affidabilità sotto stress produttivo.

Le imprese che arriveranno prima non disporranno dei modelli più avanzati. Avranno intorno a sé le infrastrutture più disciplinate: infrastrutture che sono state testate rispetto alle condizioni che avrebbero effettivamente dovuto affrontare, non alle condizioni che hanno fatto sembrare buono il progetto pilota.

Il modello non rappresenta l’intero rischio. Il sistema non testato attorno advert esso lo è.

Sayali Patil è un’infrastruttura di intelligenza artificiale e chief di prodotto.

Benvenuto nella comunità VentureBeat!

Il nostro programma di visitor posting è il luogo in cui gli esperti tecnici condividono approfondimenti e forniscono approfondimenti neutrali e non conferiti su intelligenza artificiale, infrastruttura dati, sicurezza informatica e altre tecnologie all’avanguardia che plasmano il futuro dell’impresa.

Per saperne di più dal nostro programma di submit per gli ospiti e dai un’occhiata al nostro linee guida se sei interessato a contribuire con un tuo articolo!