Inferenza Il futuro guidato dall’IA dell’osservabilità?

Futuro dell'IA guidato dall'osservabilità?

Negli ultimi nove mesi, i rapidi progressi nell’Intelligenza Artificiale Generativa hanno avuto un impatto su quasi ogni settore. Quali sono le implicazioni per come facciamo la monitoraggio dei nostri sistemi di produzione?

<p+Sostengo che la prossima evoluzione in questo ambito sarà una nuova classe di soluzioni che fanno "Inferenza", cioè individuano direttamente la causa di un errore per uno sviluppatore con una ragionevole precisione.

In questo articolo esamineremo:

• L’Inferenza come prossimo passo naturale per l’osservabilità.
• Lezioni apprese da AIOps – perché non è decollato e le implicazioni per l’inferenza.
• Alcuni principi emergenti per la classe di soluzioni di inferenza.

Dove siamo

Per comprendere la prossima generazione di osservabilità, cominciamo con l’obiettivo sottostante di tutti questi strumenti. È mantenere i sistemi di produzione sani e in funzione come previsto e, se qualcosa va storto, permetterci di capire rapidamente perché e risolvere il problema.

• Ricercatori dell’UCL e di Google propongono AudioSlots un modello generativo centrato sui slot per la separazione delle fonti audio nel dominio cieco.
• VoAGI 30 per 30 Giveaway con O’Reilly
• Dove le rocce e l’IA si scontrano l’intersezione tra mineralogia e visione artificiale a zero-shot

Se partiamo da lì, vediamo che ci sono tre livelli distinti in cui gli strumenti possono supportarci:

• Livello 1: “Avvertimi quando qualcosa non va nel mio sistema” – monitoraggio.
• Livello 2: “Dimmi perché qualcosa non va (e come risolverlo)” – chiamiamolo inferenza.
• Livello 3: “Risolvi il problema da solo e dimmi cosa hai fatto” – autoricomposizione.

Gli strumenti di monitoraggio fanno bene il livello 1 (rilevando problemi). Il passo successivo naturale è il livello 2, in cui un sistema ci dice automaticamente perché qualcosa si sta rompendo. Non abbiamo ancora soluzioni che possano farlo, quindi abbiamo aggiunto una categoria di strumenti chiamata osservabilità tra il livello 1 e il livello 2, il cui obiettivo era “aiutarci a capire perché qualcosa si sta rompendo”. Questo è fondamentalmente diventato “qualsiasi dato che potrebbe potenzialmente aiutarci a capire cosa sta accadendo”.

Osservabilità vs. Inferenza

Il problema con l’osservabilità oggi

Il problema principale con l’osservabilità oggi è che è definita ed eseguita in modo approssimativo. Questo perché non sappiamo quali dati ci servono in anticipo; dipende dal problema. La natura degli errori di produzione è che sono a lunga coda e imprevisti; se avessero potuto essere previsti, sarebbero stati risolti. Quindi raccogliamo una vasta varietà di tipi di dati: metriche, log, tracce distribuite, dati sugli errori delle tracce di stack, eventi K8s e profilazione continua, tutto per garantire di avere una certa visibilità quando le cose vanno storte.

Il modo migliore per comprendere l’osservabilità come viene implementata in pratica è: “Tutto al di fuori delle metriche, più le metriche”.

Osservabilità in pratica

Una piattaforma di osservabilità deve anche fare scelte su quanto dati catturare e conservare. Attualmente questa decisione viene lasciata ai clienti, e i clienti di solito raccolgono il maggior numero possibile di dati che possono permettersi. L’adozione rapida del cloud e i modelli SaaS hanno reso possibile la raccolta e la conservazione di enormi quantità di dati.

Il fattore umano sottostante per la raccolta di più tipi e volumi di dati di osservabilità è: “E se qualcosa si rompe e non ho abbastanza dati per risolvere il problema?” Questo è l’incubo peggiore di ogni team di ingegneria. Come risultato di questo, oggi abbiamo una situazione in cui ci sono:

• I tipi di dati di osservabilità sono in continua espansione.
• I volumi di dati di osservabilità sono in aumento esponenziale.
• Un aumento della proliferazione di strumenti: in media, l’azienda utilizza più di 5 strumenti di osservabilità.

Con tutto ciò, abbiamo iniziato ad avere nuovi problemi. Ora è sempre più difficile per gli sviluppatori navigare manualmente tra decine di dashboard ricche di dati per individuare un errore. L’osservabilità è diventata anche proibitivamente costosa, quindi le aziende devono iniziare a fare trade-off complessi su quali dati conservare, perdendo a volte visibilità. A causa di tutto ciò e del continuo aumento della complessità dei sistemi di produzione, stiamo osservando che il MTTR per gli errori di produzione è effettivamente aumentato nel corso degli anni.

Inferenza – Osservabilità più AI

Sostengo che il passo successivo dopo l’osservabilità sia l’Inferenza, dove una piattaforma può spiegare ragionevolmente perché si è verificato un errore in modo che possiamo risolverlo. Questo diventa possibile ora nel 2023 con l’evoluzione rapida dei modelli di intelligenza artificiale negli ultimi mesi.

Immagina una soluzione che:

• Evidenzi automaticamente solo gli errori che richiedono l’attenzione immediata dello sviluppatore.
• Dice allo sviluppatore esattamente cosa sta causando il problema e dove si trova – questa pod, questo server, questo percorso di codice, questo tipo di richiesta.
• Guida lo sviluppatore su come risolvere il problema.
• Utilizza le azioni effettive dello sviluppatore per migliorare continuamente le sue raccomandazioni.

C’è un po’ di attività in questa area, ma siamo ancora molto all’inizio e possiamo aspettarci che diverse nuove aziende emergano qui nei prossimi anni.

Tuttavia, qualsiasi conversazione sull’AI + osservabilità sarebbe incompleta senza una discussione su AIOPs, che aveva la stessa promessa (usare l’AI per automatizzare le operazioni di produzione) e ha visto un’ondata di investimenti tra il ’15 e il ’20 ma ha avuto un successo limitato e si è affievolita. Per una completa esplorazione del perché AIOPs è fallita, leggi questo – AIOps è morto.

Evitare le insidie di AIOps

La premessa originale di AIOps era che se avessimo spinto i dati dalle cinque o sei diverse fonti di osservabilità in una piattaforma unificante e quindi avessimo applicato l’AI a tutti questi dati (metriche, log, dipendenze, tracce, configurazioni, aggiornamenti, eventi K8s), avremmo ottenuto delle intuizioni su perché qualcosa si è rotto.

L’architettura di una piattaforma AIOP.

Anche se attraente in teoria, questo argomento ha mostrato delle lacune in alcuni modi.

In primo luogo, collegare tutto era impraticabile e un problema molto più difficile di quanto stimato. Diversi strumenti di osservabilità raccoglievano dati diversi su diversi sistemi a intervalli di tempo diversi e esprimevano sottoinsiemi diversi dei dati raccolti a uno strumento di terze parti. Inoltre, ogni cliente aveva le proprie pratiche di raccolta dati. Le aziende, ad esempio, avrebbero avuto diversi strumenti di osservabilità con raccolta dati altamente personalizzata e non standard e l’azienda avrebbe dovuto fornire manualmente contesto su di essi a qualsiasi nuovo strumento AIOP. Tutto ciò ha influenzato la qualità della risposta / dell’individuazione della causa principale a cui i modelli di ML potevano arrivare e il valore che hanno finito per fornire.

In secondo luogo, il modello di AIOP era troppo ampio e non era guidato da casi d’uso specifici. Ad esempio, a quali tipi specifici di errori miravano i modelli? Errori di infrastruttura / errori di codice / errori difficili / errori soft? La maggior parte delle piattaforme AIOP è andata abbastanza ampia qui e ha cercato di assorbire otto diversi tipi di dati nella speranza di trovare pattern e anomalie e aveva troppa dipendenza da quanto dati e di quale qualità il cliente spingeva nella piattaforma, che variava la qualità del loro output.

In terzo luogo, il processo di integrazione in ogni azienda era troppo complesso. Una grande azienda ha una distribuzione frammentata di strumenti di osservabilità, con decine di strumenti gestiti da team diversi. Una piattaforma AIOP doveva essere integrata in tutti quegli strumenti per poter aggiungere valore. Anche nel caso del modulo AIOP di una grande piattaforma di osservabilità come Datadog o DynaTrace, il requisito era che l’intero stack di osservabilità dovesse essere spostato al singolo fornitore (tra infrastruttura e metriche app, log, tracciamento distribuito, monitoraggio degli errori, ecc.) perché il modulo AIOP fosse efficace.

In quarto luogo, i volumi massicci di dati e la potenza di elaborazione necessaria per elaborare i dati hanno reso questi strumenti molto costosi rispetto al loro valore discutibile.

Tutto ciò ha portato a un grado di disillusione tra molti primi utilizzatori di strumenti AIOP e la maggior parte delle aziende è tornata a un meccanismo semplice di “raccogliere dati e visualizzarli su dashboard” per le proprie esigenze.

Diverse cose apprese da qui saranno applicabili e possono essere apprese e applicate mentre tentiamo di Inferencing.

Principi di Inferencing

L’Inferencing dovrebbe essere diverso in alcuni modi per raggiungere in modo più efficiente l’obiettivo finale.

Progettato da Zero con l’AI in Mente

Una soluzione di Inferencing dovrebbe essere progettata da zero per il caso d’uso dell’AI, ovvero la raccolta dati, l’elaborazione, il flusso di lavoro, lo storage e l’interfaccia utente sono tutti progettati da zero per “individuare la causa principale dei problemi usando l’AI”.

Ciò che probabilmente NON sembrerà è l’AI aggiunto in cima a una soluzione di osservabilità esistente o a dati di osservabilità esistenti, semplicemente perché è quello che abbiamo tentato e fallito con AIOPs. Dovrà essere un sistema a stack completo in cui tutto è progettato attorno all’uso dell’AI per l’obiettivo esplicito di eseguire l’analisi delle cause principali.

Come apparirebbe questo in pratica?

Architettura Nativa AI a Stack Completo con Raccolta, Elaborazione, Storage e Visualizzazione dei Dati

Una soluzione di Inferencing dovrebbe essere integrata verticalmente, ovvero dovrebbe raccogliere dati di telemetria, elaborare i dati e possedere il flusso di lavoro dei dati e il livello di interazione con gli utenti.

Questo è importante perché consentirebbe alla soluzione di utilizzare le interazioni dell’utente per imparare e aggiornare i propri meccanismi di elaborazione e raccolta dati.

Sarebbe anche fondamentale per la soluzione di Inferencing essere in grado di raccogliere i dati di cui ha bisogno, nel formato di cui ha bisogno, con il contesto di cui ha bisogno, dagli ambienti dei clienti – per avere il controllo sull’efficacia del root-causing e dell’esperienza utente.

Raccolta dati adattiva

Una soluzione di Inferencing dovrebbe avere intelligenza incorporata nella raccolta dei dati stessi. Ciò significa che l’agente dovrebbe essere in grado di guardare i dati in streaming e decidere al momento se catturarli o eliminarli.

Oggi, tutti gli agenti di strumentazione sono “stupidi” – semplicemente prendono uno snapshot di tutti i dati e li inviano, e l’elaborazione avviene in seguito. Questo ha senso oggi perché utilizziamo principalmente agenti di codice e vogliamo che gli agenti siano il più leggeri possibile e aggiungano un minimo overhead.

Tuttavia, con l’emergere di tecnologie come eBPF che ci consentono di raccogliere dati out-of-band dal kernel con quasi zero overhead, è possibile immaginare un agente di strumentazione intelligente che risolva attivamente la qualità dei dati richiesta dai modelli di inferenza.

Elaborazione dati adattata a casi d’uso specifici

Nell’Inferencing, tutte le tecniche di elaborazione dati dovrebbero essere incentrate su casi d’uso specifici, ad esempio, come posso identificare in modo affidabile l’errore di tipo A? E l’errore di tipo B? E così via.

Tutti i modelli di elaborazione dati seguirebbero il principio di essere in grado di individuare in modo affidabile alcune tipologie di errori e aumentare gradualmente il tipo di errori che identificherebbero man mano che i modelli evolvono. Ciò potrebbe portare a diversi tipi di dati, flussi di dati e prompt per ogni tipo di errore. Potremmo avere alcune piattaforme di inferenza che sono migliori nel root-causing degli errori infrastrutturali, alcune negli errori di sicurezza, alcune negli errori di codice, e così via, con ciascun tipo che raccoglie set di dati leggermente diversi con flussi di dati leggermente diversi e un framework di modelli diverso.

Quello che probabilmente non faranno è “rilevare anomalie generali” e quindi lavorare all’indietro per capire cosa potrebbe aver causato l’anomalia. Ciò è dovuto al fatto che i dati necessari per identificare la causa di un errore sono molto diversi dai dati necessari per “individuare” un errore.

Archiviazione progettata per l’IA

La visione dello storage in un mondo di Inferencing appare già diversa rispetto a quella di un mondo di monitoraggio o osservabilità. Ora abbiamo grandi archivi di dati per tutto ciò che accade, ma nell’inferenza, ciò di cui abbiamo bisogno è solo l’archiviazione dei dati più rilevanti e recenti necessari dai modelli di intelligenza artificiale per individuare in modo affidabile le cause degli errori. Ciò potrebbe comportare diverse pratiche, come archiviare i dati in database vettoriali per facilitare il clustering e il recupero, archiviare solo una piccola parte dei casi di successo e scartare il resto, deduplicare gli errori, e così via.

Come risultato, la quantità di archiviazione richiesta per le soluzioni di Inferencing potrebbe effettivamente essere inferiore a quella di tradizionali soluzioni di monitoraggio e osservabilità.

Interfaccia utente più semplice e interattiva

Un’interfaccia di Inferencing probabilmente assomiglierebbe meno a un insieme di dashboard con dati e più a un’interfaccia conversazionale++ adatta per i team di sviluppo. Potrebbe avere una semplice tabella di errori prioritizzati che richiedono l’attenzione umana: si fa clic su ogni errore e viene fornito un elenco delle cause più probabili con una probabilità di accuratezza. Potrebbe quindi utilizzare RLHF (Reinforcement Learning from Human Feedback) per far sì che gli utenti confermino se una causa radice è stata identificata correttamente, in modo che i modelli possano migliorare le prestazioni nel tempo. Le possibilità sono ampie qui.

Riassunto

In sintesi, è probabile che ci siano cambiamenti radicali nello spazio del monitoraggio e dell’osservabilità con gli sviluppi recenti di Gen. AI.

La prima ondata di soluzioni assomiglierà probabilmente alle piattaforme AIOPs di un tempo, con un sottile involucro di Gen. AI attorno ai dati di osservabilità esistenti. Le aziende già presenti sul mercato sono meglio posizionate per vincere questa ondata. Questo potrebbe essere simile a Github Copilot: si ottiene una buona suggerimento circa il 10% delle volte. Tuttavia, il vero salto in avanti probabilmente avverrà tra un paio di anni, con una nuova classe di soluzioni di Inferencing che possono identificare in modo accurato le cause degli errori nell’80%+ dei casi. Per poter fare ciò, sarebbe necessario essere full-stack e gestire la raccolta dei dati, l’elaborazione, l’archiviazione, i modelli e le interazioni con l’utente. Abbiamo esplorato alcune ipotesi preliminari su come le soluzioni di Inferencing sarebbero diverse dalle pratiche esistenti in ciascuna parte dello stack.