La maggior parte delle pipeline RAG aziendali sono ottimizzate per un singolo comportamento di ricerca. Altre volte falliscono silenziosamente. 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 fallirebbe a causa del ragionamento in più fasi sulle annotazioni interne. La maggior parte delle squadre capisce quando qualcosa è rotto.
Databricks ha deciso di risolvere questo problema con KARL, che sta per Knowledge Brokers Through Reinforcement Learning. Utilizzando un nuovo algoritmo di apprendimento per rinforzo, l’azienda ha formato un agente su sei diversi comportamenti di ricerca aziendale contemporaneamente. L’azienda afferma che il risultato è un modello addestrato interamente su dati sintetici generati dall’agente stesso, senza alcuna etichettatura umana richiesta, corrispondente a Claude Opus 4.6 in un benchmark appositamente creato con un costo per query inferiore del 33% e una latenza inferiore del 47%. Questo confronto si basa su KARLBench, creato da Databricks per valutare il comportamento di ricerca aziendale.
"La maggior parte dei grandi miglioramenti nell’apprendimento per rinforzo che abbiamo visto nella comunità nell’ultimo anno si sono verificati su compiti verificabili in cui ci sono risposte giuste e sbagliate." Jonathan Frankle, capo scienziato dell’intelligenza artificiale presso Databricks, ha detto a VentureBeat in un’intervista esclusiva. "I compiti che svolgiamo per KARL, che sono normali per la maggior parte delle organizzazioni, non possono essere verificati con la stessa precisione."
Queste attività includono la sintesi dell’intelligence dagli appunti delle riunioni del product manager, la ricostruzione dei risultati degli accordi competitivi da record frammentati dei clienti, la risposta a domande sulla cronologia dell’account in cui nessun singolo documento ha la risposta completa e la creazione di carte di battaglia da dati interni non strutturati. Non esiste un’unica risposta corretta a nessuna di queste che il sistema possa verificare automaticamente.
"Fare apprendimento per rinforzo in un mondo in cui non si ha una risposta definitiva tra giusto e sbagliato, e capire come navigare nel processo e assicurarsi che non avvenga l’hacking della ricompensa – non è davvero banale," Ha detto Frank. "Molto poco di ciò che le aziende fanno ogni giorno nelle missioni informative può essere verificato."
La trappola della generalizzazione nei RAG aziendali
Il RAG standard si suddivide in query imprecise in più passaggi che sfruttano 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 asset basata su vincoli, sintesi di report tra documenti, attraversamento di documenti lunghi con ragionamento numerico tabulare, recupero completo di asset, ragionamento procedurale su documenti tecnici e raccolta di fatti su note interne. Quest’ultima attività è PMBench, creata dagli appunti della riunione del product manager di Databricks; frammentato, vago e non strutturato in un modo che i modelli preliminari mal catturavano.
La formazione su qualsiasi compito e il test su altri producono scarsi risultati. Il documento KARL mostra che il RL multitasking si generalizza in un modo diverso dall’addestramento a compito singolo. Il team ha addestrato KARL sui dati sintetici per due dei sei compiti e ha scoperto che si comportava bene in tutti e quattro i compiti come non aveva mai visto prima.
Ad esempio, per creare una carta di battaglia competitiva per un cliente di servizi finanziari, l’agente deve identificare i conti rilevanti, filtrare l’attualità, ricostruire gli impegni competitivi passati e trarre conclusioni; nessuno di questi è taggato da nessuna parte nei dati.
Frankle dice che è stato KARL "ragionamento basato": Condurre una difficile catena di ragionamento ancorando ogni passaggio ai fatti ottenuti. "Puoi pensarlo come RAG," ha detto, "ma come RAG plus plus plus plus plus plus, fino a 200 chiamate al database vettoriale."
Motore RL: perché l’OAPL è importante?
La formazione di KARL è supportata da OAPL, che sta per Optimum Advantage-Based Policy Optimization with Delayed Inference policy. Si tratta di un nuovo approccio sviluppato congiuntamente da ricercatori di Cornell, Databricks e Harvard e pubblicato su una rivista. carta separata La settimana prima di KARL.
L’apprendimento di rinforzo LLM standard utilizza algoritmi in-policy come GRPO (Group Relative Policy Optimization) che presuppone che il modello che genera i dati di addestramento e il modello da aggiornare siano sincronizzati. Non accadono mai nell’apprendimento distribuito. Gli approcci precedenti hanno risolto questo problema introducendo il campionamento per importanza, la varianza e l’instabilità. L’OAPL abbraccia invece la natura non politica della formazione distribuita utilizzando un obiettivo di regressione che rimane costante con ritardi politici di oltre 400 passaggi incrementali; Ciò è 100 volte più fuori dalla politica rispetto agli approcci precedenti. Negli esperimenti di generazione del codice, corrispondeva a un modello addestrato al GRPO utilizzando circa tre volte meno esempi di addestramento.
L’efficienza esemplare dell’OAPL è ciò che rende accessibile il budget per la formazione. Il riutilizzo delle rappresentazioni raccolte in precedenza, invece di richiedere nuovi dati conformi alle policy per ogni aggiornamento, ha fatto sì che l’intero ciclo di formazione KARL avvenisse in poche migliaia di ore GPU. Questa è la differenza tra un progetto di ricerca e qualcosa che un team aziendale potrebbe realisticamente provare.
Agenti, memoria e stack di contesto
Negli ultimi mesi si è discusso molto nel settore su come sostituire il RAG con la memoria contestuale, a volte chiamata memoria dell’agente.
Per Frankle, questo non è un dibattito aut-aut, ma piuttosto lo vede come uno stack a strati. Alla base si trova un database vettoriale contenente milioni di voci, troppo grande per il contesto. La finestra del contesto LLM si trova in alto. Nel mezzo emergono 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 è qualcosa di astratto. Alcune attività di KARLBench richiedevano 200 query sequenziali sul database vettoriale, con l’agente che perfezionava le ricerche, convalidava i dettagli, faceva riferimenti incrociati ai documenti e utilizzava ripetutamente la finestra di contesto prima di fornire una risposta. Invece di addestrare un modello di riepilogo separato, il team ha lasciato che KARL imparasse la compressione end-to-end tramite RL: quando il contesto diventa troppo grande, l’agente lo comprime e va avanti; L’unico segnale di allenamento è la ricompensa alla fine del compito. La rimozione della compressione appresa ha ridotto la precisione dal 57% al 39% in un benchmark.
"Lasciamo che sia il modello a capire come comprimere il proprio contesto," Ha detto Frank. "E ha funzionato straordinariamente bene."
Dove KARL non è all’altezza
Frankle era sincero riguardo alle modalità di fallimento. KARL fatica maggiormente sulle domande con significativa incertezza, dove esiste più di una risposta valida e il modello non può determinare se la domanda è veramente aperta o è difficile rispondere. Questo giudizio è ancora una questione irrisolta.
Il modello illustra anche ciò che Franke descrive come rinuncia prematura ad alcune domande: fermarsi prima di produrre una risposta definitiva. Si è fermato prima di considerare questo come un fallimento, sottolineando che le query più costose sono spesso quelle che il modello ha comunque sbagliato. Fermarsi è spesso la decisione giusta.
KARL è stato inoltre addestrato e valutato esclusivamente sulla ricerca vettoriale. Le attività che richiedono query SQL, ricerche di file o calcoli basati su Python non sono ancora coperte. Frankle ha affermato che queste capacità sono le prossime sulla tabella di marcia, ma non sono nel sistema attuale.
Cosa significa questo per i team dati aziendali?
KARL porta alla luce tre decisioni che vale la pena riconsiderare per i team che valutano le infrastrutture di ripristino.
Il primo è l’architettura della pipeline. Se il tuo strumento RAG è ottimizzato per un comportamento di ricerca, i risultati KARL mostrano che fallisce gli altri. L’addestramento multitasking su una varietà di comportamenti di raggiungimento produce modelli che generalizzano. Le condutture strette non lo fanno.
Il secondo è perché qui il RL è importante, e non è solo un dettaglio formativo. Databricks ha testato l’alternativa: separazione dai modelli esperti attraverso la messa a punto supervisionata. Questo approccio ha migliorato le prestazioni di distribuzione ma ha prodotto vantaggi trascurabili su attività che il modello non aveva mai visto prima. RL ha migliorato il comportamento di ricerca complessivo trasmesso. Per i team aziendali che devono far fronte a dati eterogenei e tipi di query imprevedibili, questa distinzione è fondamentale. Il terzo è cosa significa effettivamente nella pratica l’efficienza RL. Un modello addestrato per effettuare ricerche migliori completerà le attività in meno passaggi, si fermerà prima sulle query a cui non può rispondere, diversificherà la ricerca invece di ripetere query fallite e comprimerà il contesto invece di esaurire lo spazio. L’argomento a favore della formazione di agenti di ricerca appositamente creati anziché instradare tutto attraverso API edge generiche non riguarda principalmente i costi. Si tratta di costruire un modello che sappia come portare a termine il lavoro.
