La maggior parte delle pipeline RAG aziendali sono ottimizzate per un comportamento di ricerca. Falliscono silenziosamente sugli altri. Un modello addestrato per sintetizzare report tra documenti gestisce in modo inadeguato la ricerca di entità basata su vincoli. Un modello ottimizzato per semplici attività di ricerca fallisce nel ragionamento in più fasi sulle be aware interne. La maggior parte delle squadre scopre quando qualcosa si rompe.
Databricks ha deciso di risolvere questo problema con KARL, abbreviazione di Data Brokers tramite Reinforcement Studying. L’azienda ha formato un agente su sei distinti comportamenti di ricerca aziendale simultaneamente utilizzando un nuovo algoritmo di apprendimento per rinforzo. Il risultato, afferma l’azienda, è un modello che corrisponde a Claude Opus 4.6 su un benchmark appositamente creato con un costo per question inferiore del 33% e una latenza inferiore del 47%, addestrato interamente su dati sintetici generati dall’agente stesso senza necessità di etichettatura umana. Story confronto si basa su KARLBench, che Databricks ha creato per valutare i comportamenti di ricerca aziendale.
“Molti dei grandi successi dell’apprendimento per rinforzo che abbiamo visto nella comunità nell’ultimo anno riguardavano compiti verificabili in cui esiste una risposta giusta e una sbagliata”, ha detto Jonathan Frankle, capo scienziato dell’intelligenza artificiale presso Databricks, a VentureBeat in un’intervista esclusiva. “I compiti a cui stiamo lavorando per KARL, e che sono normali per la maggior parte delle aziende, non sono rigorosamente verificabili allo stesso modo.”
Tali attività includono la sintesi dell’intelligence attraverso gli appunti delle riunioni del product supervisor, la ricostruzione dei risultati degli accordi competitivi da file frammentati dei clienti, la risposta a domande sulla cronologia dell’account in cui nessun singolo documento ha la risposta completa e la generazione di carte di battaglia da dati interni non strutturati. Nessuno di questi ha un’unica risposta corretta che un sistema possa verificare automaticamente.
“Fare l’apprendimento per rinforzo in un mondo in cui non esiste una risposta rigorosa tra giusto e sbagliato, e capire come guidare il processo e assicurarsi che non avvenga l’hacking della ricompensa: non è davvero banale”, ha detto Frankle. “Molto poco di ciò che le aziende fanno quotidianamente riguardo ai compiti legati alla conoscenza è verificabile.”
La trappola della generalizzazione nei RAG aziendali
Il RAG customary risolve question ambigue e in più passaggi attingendo a dati interni frammentati che non sono mai stati progettati per essere interrogati.
Per valutare KARL, Databricks ha creato il benchmark KARLBench per misurare le prestazioni in sei comportamenti di ricerca aziendale: ricerca di entità basata su vincoli, sintesi di report tra documenti, attraversamento di documenti lunghi con ragionamento numerico tabulare, recupero esaustivo di entità, ragionamento procedurale sulla documentazione tecnica e aggregazione di fatti sulle be aware aziendali interne. Quest’ultimo compito è PMBench, costruito a partire dagli appunti della riunione del product supervisor di Databricks: frammentati, ambigui e non strutturati in modi che i modelli di frontiera gestiscono male.
La formazione su un singolo compito e i take a look at sugli altri producono scarsi risultati. Il documento KARL mostra che il RL multi-task si generalizza in modi in cui l’addestramento a compito singolo non lo fa. Il group ha addestrato KARL sui dati sintetici per due dei sei compiti e ha scoperto che si comportava bene in tutti e quattro, cosa che non aveva mai visto.
Per costruire una carta di battaglia competitiva per un cliente di servizi finanziari, advert esempio, l’agente deve identificare i conti rilevanti, filtrare in base all’attualità, ricostruire accordi competitivi passati e dedurre risultati – nessuno dei quali è etichettato da nessuna parte nei dati.
Frankle chiama ciò che fa KARL “ragionamento fondato”: eseguire una catena di ragionamento difficile ancorando ogni passo ai fatti recuperati. “Puoi pensare a questo come RAG”, ha detto, “ma come RAG plus plus plus plus plus plus, fino a 200 chiamate di database vettoriali.”
Il motore RL: perché l’OAPL è importante
La formazione di KARL è fornita da OAPL, abbreviazione di Optimum Benefit-based Coverage Optimization with Lagged Inference coverage. Si tratta di un nuovo approccio, sviluppato congiuntamente da ricercatori di Cornell, Databricks e Harvard e pubblicato su a carta separata la settimana prima di KARL.
L’apprendimento di rinforzo LLM customary utilizza algoritmi su coverage come GRPO (Group Relative Coverage Optimization), che presuppone che il modello che genera i dati di addestramento e il modello da aggiornare siano sincronizzati. Nella formazione distribuita, non lo sono mai. Gli approcci precedenti hanno corretto questo problema con il campionamento per importanza, introducendo varianza e instabilità. OAPL abbraccia invece la natura fuori coverage della formazione distribuita, utilizzando un obiettivo di regressione che rimane stabile con ritardi delle coverage di oltre 400 passaggi di gradiente, 100 volte più fuori coverage rispetto agli approcci gestiti in precedenza. Negli esperimenti di generazione del codice, corrispondeva a un modello addestrato GRPO utilizzando circa tre volte meno campioni di addestramento.
L’efficienza del campione OAPL è ciò che mantiene accessibile il funds per la formazione. Il riutilizzo delle implementazioni raccolte in precedenza anziché richiedere nuovi dati sulla coverage per ogni aggiornamento ha fatto sì che l’intera esecuzione della formazione KARL rimanesse entro poche migliaia di ore GPU. Questa è la differenza tra un progetto di ricerca e qualcosa che un group aziendale può realisticamente tentare.
Agenti, memoria e stack di contesto
Negli ultimi mesi si è discusso molto nel settore su come la RAG possa essere sostituita con la memoria contestuale, a volte chiamata anche memoria dell’agente.
Per Frankle non si tratta di una discussione “o/o”, piuttosto la vede come una pila a strati. Alla base si trova un database vettoriale con milioni di voci, che è troppo grande per il contesto. La finestra del contesto LLM si trova in alto. Tra di loro stanno emergendo livelli di compressione e memorizzazione nella cache che determinano quanto di ciò che un agente ha già appreso può portare avanti.
Per KARL questo non è astratto. Alcune attività di KARLBench richiedevano 200 question sequenziali sul database vettoriale, con l’agente che perfezionava le ricerche, verificava i dettagli e faceva riferimenti incrociati ai documenti prima di impegnarsi a fornire una risposta, esaurendo più volte la finestra di contesto. Invece di addestrare un modello di riepilogo separato, il group ha lasciato che KARL imparasse la compressione end-to-end tramite RL: quando il contesto diventa troppo grande, l’agente lo comprime e continua, con l’unico segnale di addestramento rappresentato dalla ricompensa alla wonderful dell’attività. La rimozione della compressione appresa ha ridotto la precisione su un benchmark dal 57% al 39%.
“Abbiamo semplicemente lasciato che il modello capisse come comprimere il proprio contesto”, ha detto Frankle. “E questo ha funzionato straordinariamente bene.”
Dove KARL non è all’altezza
Frankle period sincero riguardo alle modalità di fallimento. KARL fatica maggiormente su domande con ambiguità significativa, dove esistono più risposte valide e il modello non è in grado di determinare se la domanda è veramente aperta o semplicemente difficile da rispondere. Quel giudizio è ancora un problema irrisolto.
Il modello mostra anche ciò che Franke descrive come rinunciare presto advert alcune domande: fermarsi prima di produrre una risposta definitiva. Ha respinto l’concept di inquadrarlo come un fallimento, sottolineando che le question più costose sono in genere quelle che il modello sbaglia comunque. Fermarsi è spesso la decisione giusta.
KARL è stato inoltre formato e valutato esclusivamente sulla ricerca vettoriale. Le attività che richiedono question SQL, ricerca di file o calcoli basati su Python non rientrano ancora nell’ambito. Frankle ha affermato che queste capacità sono le prossime sulla tabella di marcia, ma non sono nel sistema attuale.
Cosa significa questo per i group dati aziendali
KARL presenta tre decisioni che vale la pena rivedere per i group che valutano la propria infrastruttura di recupero.
Il primo è l’architettura della pipeline. Se il tuo agente RAG è ottimizzato per un comportamento di ricerca, i risultati KARL suggeriscono che non funziona con gli altri. La formazione multi-task attraverso diversi comportamenti di recupero produce modelli che generalizzano. Le condutture strette no.
Il secondo è il motivo per cui l’RL è importante qui – e non è solo un dettaglio dell’allenamento. Databricks ha testato l’alternativa: distillare da modelli esperti tramite una messa a punto supervisionata. Questo approccio ha migliorato le prestazioni nella distribuzione, ma ha prodotto guadagni trascurabili su compiti che il modello non aveva mai visto. RL ha sviluppato comportamenti di ricerca generali trasferiti. Per i group aziendali che si trovano advert affrontare dati eterogenei e tipi di question imprevedibili, questa distinzione è l’intero gioco. Il terzo è cosa significa effettivamente nella pratica l’efficienza RL. Un modello addestrato per effettuare ricerche migliori completa le attività in meno passaggi, si ferma prima sulle question a cui non può rispondere, diversifica la ricerca anziché ripetere question fallite e comprime il proprio contesto anziché esaurire lo spazio. L’argomento a favore della formazione di agenti di ricerca appositamente creati anziché instradare tutto attraverso API di frontiera generiche non riguarda principalmente i costi. Si tratta di costruire un modello che sappia come svolgere il lavoro.
