Databricks heeft een RAG-agent gebouwd die naar eigen zeggen elk type enterprise search aankan

De meeste zakelijke RAG-pijplijnen zijn geoptimaliseerd voor één zoekgedrag. Ze falen stilletjes bij anderen. Modellen die zijn getraind om rapporten over meerdere documenten te synthetiseren, kunnen slecht omgaan met het browsen door entiteiten op basis van beperkingen. Modellen die zijn aangepast voor eenvoudige zoektaken werken niet vanwege redenering in meerdere stappen in plaats van interne records. De meeste teams komen erachter wanneer er iets kapot is.

Databricks probeert dit op te lossen met KARL, een afkorting van Knowledge Agents via Reinforcement Learning. Het bedrijf trainde agenten tegelijkertijd in zes verschillende zoekgedragingen voor bedrijven met behulp van een nieuw versterkend leeralgoritme. Het resultaat, zo beweert het bedrijf, is een model dat Claude Opus 4.6 op maat gemaakte benchmarks matcht met 33% lagere kosten per zoekopdracht en 47% lagere latentie, volledig getraind op door agenten gegenereerde synthetische gegevens zonder de noodzaak van menselijke labels. De vergelijking is gebaseerd op KARLBench, gemaakt door Databricks om het zoekgedrag van ondernemingen te evalueren.

“Veel van de grote overwinningen op het gebied van versterkend leren die we het afgelopen jaar in de gemeenschap hebben gezien, hadden te maken met verifieerbare taken met goede en foute antwoorden”, vertelde Jonathan Frankle, Chief AI Scientist bij Databricks, aan VentureBeat in een exclusief interview. “Het werk dat wij voor KARL doen, en dat is voor de meeste bedrijven normaal, is niet helemaal op dezelfde manier verifieerbaar.”

Deze taken omvatten het synthetiseren van informatie uit de notulen van productmanagers, het reconstrueren van concurrerende dealresultaten uit gefragmenteerde klantrecords, het beantwoorden van vragen over de accountgeschiedenis wanneer geen enkel document een volledig antwoord heeft, en het genereren van gevechtskaarten op basis van ongestructureerde interne gegevens. Geen van de antwoorden heeft één juist antwoord dat automatisch door het systeem kan worden gecontroleerd.

“Versterkingsleren doen in een wereld waar je geen goede en foute antwoorden hebt, en uitzoeken hoe je het proces kunt begeleiden en ervoor kunt zorgen dat er geen beloningshacks plaatsvinden – dat is echt niet triviaal,” zei Frankle. “Heel weinig van wat bedrijven dagelijks doen op het gebied van kennistaken is verifieerbaar.”

De valkuil van generalisatie in bedrijfs-RAG

Standaard RAG breekt dubbelzinnige meerstapsquery’s af en maakt gebruik van gefragmenteerde interne gegevens die nooit zijn ontworpen om te worden bevraagd.

Om KARL te evalueren, heeft Databricks de KARLBench-benchmark gebouwd om de prestaties van zes ondernemingszoekgedragingen te meten: op beperkingen gebaseerde zoekopdrachten naar entiteiten, synthese van rapporten tussen documenten, het doorkruisen van lange documenten met numerieke redenering in tabelvorm, het volledig ophalen van entiteiten, procedureel redeneren over technische documentatie en aggregatie van feiten over interne bedrijfsrecords. Die laatste taak was PMBench, die werd gemaakt op basis van de vergadernotities van Databricks’ eigen productmanagers – zo gefragmenteerd, dubbelzinnig en ongestructureerd dat het frontiermodel er niet goed mee overweg kon.

Trainen op de ene taak en testen op een andere taak levert slechte resultaten op. Het KARL-artikel laat zien dat multi-task RL gegeneraliseerd kan worden op een manier die training met één taak niet kan. Het team trainde KARL met behulp van synthetische gegevens voor twee van de zes taken en ontdekte dat KARL goed presteerde op vier nog nooit eerder vertoonde taken.

Om bijvoorbeeld een concurrentiepositie voor klanten uit de financiële dienstverlening op te bouwen, moeten agenten relevante accounts identificeren, recentheid filteren, eerdere concurrerende transacties reconstrueren en resultaten afleiden – die nergens in de gegevens worden gelabeld.

Frankle noemde wat KARL deed ‘gefundeerd redeneren’: het uitvoeren van een moeilijke reeks redeneringen, waarbij elke stap werd gekoppeld aan de genomen feiten. “Je kunt dit zien als RAG,” zei hij, “maar net als RAG plus plus plus plus plus, tot 200 vectordatabaseoproepen.”

RL-motoren: waarom OAPL ertoe doet

KARL-training wordt ondersteund door OAPL, een afkorting voor Optimal Advantage-based Policy Optimization with Lagged Inference. Het is een nieuwe aanpak, gezamenlijk ontwikkeld door onderzoekers van Cornell, Databricks en Harvard en gepubliceerd in een apart papier een week vóór KARL.

Standaard LLM-versterkingsleren maakt gebruik van beleidsconforme algoritmen zoals GRPO (Group Relative Policy Optimization), waarbij ervan wordt uitgegaan dat het model dat trainingsgegevens genereert en het bijgewerkte model synchroon zijn. Bij gedistribueerde training bestaan ​​ze nooit. Eerdere benaderingen corrigeren hiervoor door middel van belangrijkheidssteekproeven, wat variantie en instabiliteit introduceert. OAPL omarmt het buiten het beleid vallende karakter van gedistribueerde training, waarbij gebruik wordt gemaakt van een regressiedoelstelling die stabiel blijft met een beleidsvertraging van meer dan 400 gradiëntstappen, 100 maal meer buiten het beleid vallende benaderingen dan eerder aangepakte benaderingen. In het experiment voor het genereren van code kwam dit model overeen met het door GRPO getrainde model, waarbij ongeveer drie keer minder trainingsmonsters werden gebruikt.

OAPL-bemonsteringsefficiëntie maakt trainingsbudgetten toegankelijk. Door eerder verzamelde lanceringen te hergebruiken in plaats van voor elke update nieuwe beleidsgegevens te vereisen, duurt de volledige KARL-training slechts een paar duizend GPU-uren. Dat is het verschil tussen een onderzoeksproject en iets dat een bedrijfsteam realistisch gezien kan doen.

Agent-, geheugen- en contextstapel

Er is de afgelopen maanden veel discussie geweest in de industrie over hoe RAG vervangen zou kunnen worden door contextueel geheugen, ook wel agentgeheugen genoemd.

Voor Frankle is dit geen of/of-discussie, maar hij ziet het eerder als een gelaagde stapel. Onderaan bevindt zich een vectordatabase met miljoenen vermeldingen, die te groot is voor de context. Het LLM-contextvenster bevindt zich bovenaan. Tussen deze twee komen compressie- en cachinglagen naar voren die bepalen hoeveel van wat een agent heeft geleerd, kan worden overgedragen.

Voor KARL is dit geen abstract iets. Sommige KARLBench-taken vereisen 200 sequentiële vectordatabasequery’s, waarbij de agent zoekopdrachten verfijnt, details verifieert en naar documenten verwijst voordat antwoorden worden gegeven, waardoor het contextvenster meerdere keren wordt uitgeput. In plaats van een apart samenvattingsmodel te trainen, liet het team KARL end-to-end-compressie leren via RL: als de context te groot werd, comprimeerde de agent deze en ging verder, met als enige trainingssignaal de beloning aan het einde van de taak. Het verwijderen van de geleerde compressie vermindert de nauwkeurigheid op één benchmark van 57% naar 39%.

“We lieten het model uitzoeken hoe het zijn eigen context kon comprimeren,” zei Frankle. “En het werkt heel goed.”

Waar KARL faalt

Frankle is openhartig over de faalmodus. KARL heeft moeite met het beantwoorden van vragen met aanzienlijke dubbelzinnigheid, omdat er veel geldige antwoorden zijn en het model niet kan bepalen of de vraag echt open of moeilijk te beantwoorden is. Die uitspraak is nog steeds een onopgeloste kwestie.

Het model laat ook zien wat Frankle beschrijft als het vroegtijdig opgeven van sommige vragen: stoppen voordat er een definitief antwoord komt. Hij weigerde dit als een mislukking te beschouwen en stelde dat de duurste zoekopdrachten meestal de zoekopdrachten waren die verkeerd waren in zijn model. Stoppen is vaak de juiste beslissing.

KARL is ook uitsluitend getraind en geëvalueerd op het gebied van vectoronderzoek. Taken waarvoor SQL-query’s, bestandszoekopdrachten of op Python gebaseerde berekeningen nodig zijn, vallen niet onder het bereik. Frankle zei dat deze mogelijkheid als volgende op de routekaart staat, maar niet in het huidige systeem.

Wat dit betekent voor bedrijfsdatateams

KARL heeft drie beslissingen naar voren gebracht die de moeite waard zijn om te herzien voor teams die hun ophaalinfrastructuur evalueren.

De eerste is de pijplijnarchitectuur. Als uw RAG-agent is geoptimaliseerd voor één surfgedrag, laten de KARL-resultaten zien dat hij faalt bij ander gedrag. Multi-task training over verschillende ophaalgedragingen levert een generaliseerbaar model op. Smalle pijpleidingen kunnen dit niet.

De tweede reden waarom RL hier belangrijk is – en het is niet alleen een trainingsdetail. Databricks testte een alternatief: filteren vanuit expertmodellen via begeleide aanpassing. De aanpak verbetert de prestaties in distributies, maar levert slechts kleine winsten op bij taken die het model nog nooit heeft gezien. RL ontwikkelt algemeen zoekgedrag dat overdraagt. Voor bedrijfsteams die te maken hebben met heterogene gegevens en onvoorspelbare soorten zoekopdrachten, betekenen deze verschillen alles. De derde is wat RL-efficiëntie feitelijk in de praktijk betekent. Een model dat is getraind om beter te zoeken, voltooit taken in minder stappen, stopt eerder bij onbeantwoordbare vragen, diversifieert de zoekopdracht in plaats van mislukte zoekopdrachten te herhalen, en comprimeert de eigen context in plaats van te weinig ruimte te hebben. Het argument voor het trainen van een op maat gemaakte zoekagent in plaats van alles via een algemene grens-API te routeren gaat niet alleen over de kosten. Het gaat erom een ​​model te bouwen dat weet hoe het zijn werk moet doen.