Dati contestuali: Perché l’AI non ha solo bisogno di volumi

Gli ultimi due anni di AI aziendale sono stati una sperimentazione, ed è stato facile rimanere lì. I modelli continuavano a cambiare, così le tempistiche di produzione sono calate e ogni miglioramento ha fatto emergere nuove funzionalità che i team volevano integrare, il che significava più ambito, più test, più ritardi. Un circolo vizioso, con il modello che progredisce come motivo per cui nulla è stato spedito. Questo ciclo sta rompendo e le aziende sono pronte a passare dalla sperimentazione all’AI, che in realtà offre valore al business. Ciò che conta di più in questo cambiamento non è il modello scelto, né la quantità di dati a disposizione, ma se i dati sono in grado di supportare il contesto, un modello deve essere preciso.

La scelta dei modelli è meno importante perché i migliori modelli di peso aperto e frontiera sono convergenti. Kimi K3 e Claude Fable 5 sono già abbastanza vicine che per la maggior parte dei lavori di livello enterprise è difficile distinguerli, il modello aperto costa una frazione e la prossima release ti offrirà solo un guadagno incrementale, non un salto di qualità come negli anni precedenti. Lo sforzo di progettazione è passato all’utilizzo: gli strumenti, la memoria, le valli e i guardrail avvolti nel modello, dove il problema difficile è passato a mantenere i workload degli agenti in esecuzione per ore con una supervisione umana minima. Ora si tratta di creare una flessibilità invisibile all’utente, in cui il flusso di lavoro eseguito ieri viene eseguito allo stesso modo oggi, mentre l’imbracatura passa da un modello all’altro per ottimizzare i costi, le performance o qualsiasi altro KPI importante. Il modello diventa un dettaglio di implementazione.

Questa flessibilità si basa sul livello più importante che le aziende possono sfruttare: i dati sottostanti. Ricorda che l’approccio più antico nel calcolo si applica ancora qui: garbage-in, garbage-out. Il miglior utilizzo al mondo si basa su ciò che fornisci e i dati più importanti che puoi fornire sono tuoi. È sempre stato il fattore di differenziazione aziendale nell’AI e ora che tutti eseguono essenzialmente gli stessi modelli, è l’unico rimasto. Ogni azienda è impegnata in volumi, decenni di tabelle, documenti e ticket, ma il volume da solo peggiora un modello, non migliora. Ciò che rende preciso un modello è sapere quale tabella è canonica, quale documento è attuale e in che modo il cliente in un sistema si relaziona con il cliente in un altro.

La qualità dei dati determina il successo dell’AI

In un sondaggio condotto da IDC tra i leader aziendali, il 94% ha dichiarato che AI la qualità dei dati è decisiva. Le ricerche dei sondaggi raramente si avvicinano all’unanimità. Il report indica anche le cause principali di scarsa qualità ed è il caso di sospettare che i dati siano ridondanti, in silos e obsoleti. Noterò che la funzionalità del modello non è presente in questo elenco, né il modello è incluso. I problemi che oggi compromettono l’AI aziendale sono gli stessi che hanno minato gli analytics negli ultimi 20 anni. Ciò che è cambiato è come appaiono, perché ciascuno di questi tre problemi di dati peggiora le risposte di un modello a modo suo.

I dati obsoleti producono risposte che sembrano allucinazioni, ma non lo sono. La pipeline di recupero serve la politica di reso dello scorso anno, l’agente la cita a un cliente in modo fluente e sicuro e l’azienda è ora pronta per i termini di rimborso che ha ritirato mesi fa. Gli ingegneri che esaminano l’incidente lo registrano come un’allucinazione, ma il modello ha svolto correttamente il proprio lavoro. Sono gli input a sbagliare.

I dati ridondanti introducono casualità. Quando esistono sei copie quasi identiche di una tabella e due di esse non sono d’accordo, ci sono due modi per sbagliare. Se il recupero fa emergere solo una copia, che il modello riceve è casuale, ovvero la qualità della risposta ora contiene una variabile casuale. Se il recupero emerge entrambi, il modello dovrebbe rilevare la contraddizione, ma in un contesto di mare, potrebbe concentrarsi su una copia e ignorare del tutto l’altra. In entrambi i casi, la stessa domanda posta in due giorni diversi può restituire due risposte diverse e né l’utente né l’ingegnere possono spiegarne il motivo senza tracciare il recupero.

I dati in silos trasformano le conoscenze condivise in conoscenze locali. Un silos è raramente una restrizione intenzionale. Più spesso, il modo in cui un sistema è stato implementato significa che i dati dovrebbero essere visibili solo da tutti e solo per pochi team. Di conseguenza, una domanda generale sulle conoscenze aziendali restituisce risposte diverse a seconda della sezione di dati che il modello può visualizzare. Due dipendenti possono porre la stessa domanda, ricevere due risposte diverse, ma entrambe sono fedeli ai dati parziali sottostanti. Il problema si aggrava man mano che un maggior numero di strumenti di AI si basa sui dati aziendali. Uno strumento che un team costruisce sulla sua fetta raggiungerà risposte diverse, e infine decisioni diverse, rispetto agli strumenti che altri team costruiscono sulla loro, e ciò che inizia quando due dipendenti ricevono risposte incoerenti finisce come sistemi automatizzati che agiscono su informazioni contrastanti, con l’azienda che sostiene il costo di tale conflitto.

Questa combinazione determina una diagnosi errata prevedibile. Quando un modello capace viene eseguito su dati inadeguati, gli ingegneri vedono risposte sbagliate e concludono che il modello è in errore, i team rispondono valutando una sostituzione e il ciclo di sperimentazione ricomincia da capo. La sostituzione del modello non cambia nulla, perché i dati sottostanti rimangono gli stessi.

I dati non sono contestuali

Se i dati errati peggiorano le risposte di un modello, allora è necessario saperlo che cosa offre un modello capace. La risposta è il contesto e posso spiegare la differenza tra dati e contesto con un’analogia con la vita di tutti i giorni. Supponiamo che un amico ti invii una foto della sua vacanza: È in barca, su un lago e il sole è tramonto. Ora hai i dati e puoi descrivere la scena in modo preciso a chiunque: una persona, una barca, un lago, circa mezzogiorno.

Poi lo chiami e ottieni il contesto. Quel giorno il vento sferrava 20 nodi, abbastanza forte da rendere difficile l’intero attraversamento. Il motore è morto a metà strada e la famiglia si è spostata per un’ora. I suoi figli hanno deciso che la deriva era la parte migliore dell’intero viaggio ed è la storia che racconteranno al Ringraziamento per il prossimo decennio. È la stessa scena, ma ora sai cose molto diverse. La foto ti dice cosa è visibile, mentre l’amico ti dice cosa è successo, perché è importante e a cosa si collega.

La mappatura all’azienda è diretta: I tuoi dati sono la foto e i tuoi dipendenti sono gli amici. Da qualche parte dell’organizzazione, un analista sa che, tra due tabelle delle entrate che sembrano intercambiabili, solo una riporta i numeri corretti del Q3. Qualcuno nel settore finanziario sa che “cliente” nel sistema di fatturazione indica l’entità legale, mentre “cliente” nel sistema di prodotto indica l’utente finale, e che una volta la confessione dei due ha prodotto un numero di abbandono sufficientemente sbagliato da dover essere corretto di fronte al CEO. È qui che provengono le conoscenze aziendali: persone in grado di spiegare perché questo dataset è quello giusto per l’analisi e non l’altro dataset che acquisisce le stesse informazioni in modo superficiale. Il modello non vede nulla di tutto questo, ma solo la foto.

I dati contestuali consentono di trasformare l’account dell’amico in una forma utilizzabile da un computer. Ha due componenti principali. I grafici delle conoscenze codificano le relazioni e la provenienza: questa tabella sostituisce quella, questa metrica deriva da queste tre origini; questo account nel sistema di vendita è la stessa entità di tale account nella fatturazione. I livelli semantici prendono le definizioni che i tuoi dipendenti utilizzano in modo informale e le rendono esplicite e governate: cosa significano i “ricavi”, quale campo clienti è canonico e quale pipeline è effettivamente affidabile per il team finanziario.

Anche i dati contestuali sono alla base del cambiamento del vocabolario del settore, dall’ingegneria rapida all’ingegneria del contesto. L’ingegneria tempestiva era quella di formulare bene la domanda. L’ingegneria del contesto consiste nel decidere cosa può vedere il modello al momento in cui risponde, e questo è un problema di architettura e non una competenza di scrittura.

Figura: stack a due livelli. Livello superiore: Modelli intercambiabili, scambiati liberamente. Livello inferiore: Il livello di contesto durevole (grafico delle conoscenze + livello semantico) che fornisce a ogni modello le stesse conoscenze istituzionali. 

Il modello successivo non risolverà i dati errati

A questo punto, i lettori che lavorano vicino al livello del modello sollevano la stessa obiezione. Se le finestre contestuali sono cresciute oltre un milione di token e il ragionamento migliora a ogni release, perché alla fine la scalabilità non compensa i dati disordinati? È una domanda equa e la scalabilità è utile. Una finestra più lunga significa meno tagli arbitrari a ciò che il modello è in grado di vedere e un ragionamento migliore rileva più contraddizioni rispetto a un tempo. Ciò che la scalabilità non può fare è riparare gli input errati.

Un documento obsoleto in una finestra da un milione di token è ancora obsoleto, paghi solo di più per elaborarlo. Un migliore ragionamento applicato alle tabelle contraddittorie non risolve la contraddizione, ma produce una difesa più articolata di qualsiasi copia scelta dal modello. L’adage menzionato in precedenza in questo articolo è sopravvissuto a 60 anni di crescita esponenziale del calcolo, e anche questo sopravvivrà a questo.

La qualità dell’AI è un problema di data intelligence

Quando la qualità della risposta delude, l’istinto di un leader dell’AI tecnicamente profondo è quello di lavorare a livello di modello (perfezionare il corpo dell’azienda, distillare, valutare più duramente) o a livello di cablaggio (aggiungere nuovi tentativi, stringere i guardrail). Nemmeno funziona, perché non tocca i dati. La messa a punto dei dati ridondanti e obsoleti sposta il problema nelle ponderazioni del modello, dove non viene più visualizzato in alcun registro di recupero che un tecnico può controllare. Un cablaggio più resistente non lo risolve perché rende l’agente più grazioso.

Il livello di contesto è invece quello che dovrebbe fare. I modelli vengono sostituiti e le imbracature vengono ricostruite, ma il livello di contesto rimane e tutto ciò che si aggiunge si basa su ciò che è già presente. Ogni relazione codificata, ogni definizione resa esplicita e ogni elemento di conoscenza istituzionale che si sposta dalla testa di un analista a un grafico migliora ogni modello che viene eseguito su di esso, quello che si implementa oggi e quello che si scambia nel prossimo trimestre. 

Un modello inizia a perdere valore il giorno in cui viene spedito perché è già in arrivo un modello migliore. Mentre lo scrivo, tre punti separano il modello di frontiera leader dal suo challenger open source nell’Artificial Analysis Intelligence Index e l’ordine cambierà tra poche settimane. Il livello di contesto si sposta nella direzione opposta. Genera valore con tutto ciò che si aggiunge e ogni modello eseguito eredita quel valore.

Costruire questo livello è un problema di data intelligence, non un problema di modello. Catalogazione, lignaggio, risoluzione delle entità e semantica governata sono i macchinari che catturano ciò che le persone conoscono e lo collocano dove il modello può usarlo. Non farò finta che questo sia risolto, codificare la tacita conoscenza umana su scala enterprise è davvero difficile. Ma è il problema difficile su cui vale la pena lavorare, perché è l’unica parte dello stack che non è standardizzata.

I modelli continueranno a scambiare posizioni in cima, e questo va bene, perché un’imbracatura flessibile ti consente di sostituirle in un pomeriggio. Ciò che non puoi scambiare è ciò che la tua organizzazione conosce. Qualsiasi modello può guardare la foto, ma solo il tuo livello di contesto sa cosa è successo quel giorno sul lago.