Databricks heeft een RAG-agent gebouwd die naar eigen zeggen elke vorm van enterprise search aankan

De meeste zakelijke RAG-pijplijnen zijn geoptimaliseerd voor één zoekgedrag. Ze falen stilletjes bij de anderen. Een model dat is getraind om rapporten over meerdere documenten samen te stellen, kan slecht omgaan met op beperkingen gebaseerde entiteitszoekopdrachten. Een model dat is afgestemd op eenvoudige opzoektaken valt uiteen bij redeneren in meerdere stappen over interne aantekeningen. De meeste teams komen erachter wanneer er iets kapot gaat.

Databricks wilde dit oplossen met KARL, een afkorting van Knowledge Agents via Reinforcement Learning. Het bedrijf trainde een agent 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 matcht op een speciaal gebouwde benchmark met 33% lagere kosten per zoekopdracht en 47% lagere latentie, volledig getraind op synthetische gegevens die de agent zelf heeft gegenereerd zonder dat menselijke labels nodig zijn. Die vergelijking is gebaseerd op KARLBench, dat Databricks heeft gebouwd om het zoekgedrag van ondernemingen te evalueren.

“Veel van de grote overwinningen die we het afgelopen jaar in de gemeenschap hebben gezien, hebben betrekking op verifieerbare taken waarbij er een goed en een fout antwoord is”, vertelde Jonathan Frankle, Chief AI Scientist bij Databricks, aan VentureBeat in een exclusief interview. “De taken waar we voor KARL aan werken, en die voor de meeste bedrijven normaal zijn, zijn niet op dezelfde manier strikt verifieerbaar.”

Deze taken omvatten het synthetiseren van informatie uit de notulen van productmanagervergaderingen, het reconstrueren van concurrerende dealresultaten uit gefragmenteerde klantrecords, het beantwoorden van vragen over de accountgeschiedenis waar geen enkel document het volledige antwoord biedt en het genereren van gevechtskaarten op basis van ongestructureerde interne gegevens. Geen van deze heeft één juist antwoord dat een systeem automatisch kan controleren.

“Versterkingsleren doen in een wereld waar je geen strikt goed en fout antwoord hebt, en uitzoeken hoe je het proces kunt begeleiden en ervoor kunt zorgen dat er geen beloningshacking plaatsvindt – dat is echt niet triviaal”, zei Frankle. “Heel weinig van wat bedrijven dagelijks doen op het gebied van kennistaken is verifieerbaar.”

De generalisatievalkuil in enterprise-RAG

Standaard RAG werkt niet bij dubbelzinnige, uit meerdere stappen bestaande query’s, waarbij gebruik wordt gemaakt 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 zoekgedragingen voor ondernemingen te meten: op beperkingen gebaseerde zoekopdrachten naar entiteiten, synthese van rapporten tussen documenten, doorkruising van lange documenten met numerieke redenering in tabelvorm, volledig ophalen van entiteiten, procedureel redeneren over technische documentatie en aggregatie van feiten over interne bedrijfsnotities. Die laatste taak is PMBench, opgebouwd uit de notities van Databricks’ eigen productmanagervergaderingen – gefragmenteerd, dubbelzinnig en ongestructureerd op manieren die grensmodellen slecht aankunnen.

Trainen op een enkele taak en testen op de andere levert slechte resultaten op. Het KARL-artikel laat zien dat multi-task RL generaliseert op een manier waarop training met één taak dat niet doet. Het team trainde KARL met synthetische gegevens voor twee van de zes taken en ontdekte dat het bij alle vier de taken goed presteerde, wat het nog nooit eerder had gezien.

Om bijvoorbeeld een concurrentiestrijdkaart voor een klant uit de financiële dienstverlening op te bouwen, moet de agent relevante accounts identificeren, filteren op recentheid, eerdere concurrerende deals reconstrueren en resultaten afleiden – die nergens in de gegevens worden gelabeld.

Frankle noemt wat KARL doet ‘gefundeerd redeneren’: het uitvoeren van een moeilijke redeneerketen terwijl elke stap wordt verankerd in de gevonden feiten. “Je kunt dit zien als RAG,” zei hij, “maar net als RAG plus plus plus plus plus plus, tot wel 200 vectordatabaseoproepen.”

De RL-engine: waarom OAPL ertoe doet

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

Standaard LLM-versterkingsleren maakt gebruik van beleidsalgoritmen zoals GRPO (Group Relative Policy Optimization), die ervan uitgaan dat het model dat trainingsgegevens genereert en het model dat wordt bijgewerkt, synchroon lopen. Bij gedistribueerde training is dat nooit het geval. Eerdere benaderingen corrigeerden hiervoor met belangrijkheidssteekproeven, waardoor variantie en instabiliteit werden geïntroduceerd. OAPL omarmt in plaats daarvan de off-policy aard van gedistribueerde training, waarbij gebruik wordt gemaakt van een regressiedoelstelling die stabiel blijft met beleidsvertragingen van meer dan 400 gradiëntstappen, 100 keer meer off-policy dan eerdere benaderingen. Bij codegeneratie-experimenten kwam het overeen met een GRPO-getraind model, waarbij grofweg drie keer minder trainingsmonsters werden gebruikt.

De monsterefficiëntie van OAPL houdt het opleidingsbudget toegankelijk. Door eerder verzamelde implementaties te hergebruiken in plaats van voor elke update nieuwe beleidsgegevens te vereisen, bleef de volledige KARL-training binnen een paar duizend GPU-uren. Dat is het verschil tussen een onderzoeksproject en iets dat een ondernemingsteam realistisch gezien kan proberen.

Agenten, geheugen en de contextstapel

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

Voor Frankle is het geen of/of-discussie, hij ziet het eerder als een gelaagde stapel. Aan de basis bevindt zich een vectordatabase met miljoenen vermeldingen, die te groot is voor context. Het LLM-contextvenster bevindt zich bovenaan. Daartussen ontstaan ​​compressie- en cachinglagen die bepalen hoeveel van wat een agent al heeft geleerd, kan worden overgedragen.

Voor KARL is dit niet abstract. Voor sommige KARLBench-taken waren 200 sequentiële vectordatabasequery’s nodig, waarbij de agent zoekopdrachten verfijnde, details verifieerde en naar documenten keek voordat hij tot een antwoord kwam, waardoor het contextvenster vele malen werd uitgeput. In plaats van een apart samenvattingsmodel te trainen, liet het team KARL de compressie end-to-end leren via RL: wanneer de context te groot wordt, comprimeert de agent deze en gaat verder, met als enige trainingssignaal de beloning aan het einde van de taak. Door die aangeleerde compressie te verwijderen, daalde de nauwkeurigheid op één benchmark van 57% naar 39%.

“We lieten het model gewoon uitzoeken hoe het zijn eigen context kon comprimeren”, zei Frankle. “En dit werkte fenomenaal goed.”

Waar KARL tekortschiet

Frankle was openhartig over de faalwijzen. KARL heeft het meeste moeite met vragen met aanzienlijke dubbelzinnigheid, waarbij meerdere geldige antwoorden bestaan ​​en het model niet kan bepalen of de vraag echt een open einde heeft of gewoon moeilijk te beantwoorden is. Dat oordeel is nog steeds een onopgelost probleem.

Het model laat ook zien wat Frankle omschreef als het vroegtijdig opgeven van sommige vragen: stoppen voordat er een definitief antwoord komt. Hij besloot dit niet als een mislukking te bestempelen, waarbij hij opmerkte dat de duurste zoekopdrachten doorgaans de zoekopdrachten zijn waarbij het model toch de fout in gaat. Stoppen is vaak de juiste beslissing.

KARL werd ook uitsluitend getraind en geëvalueerd op het gebied van vectoronderzoek. Taken waarvoor SQL-query’s, het zoeken naar bestanden of op Python gebaseerde berekeningen nodig zijn, vallen nog niet binnen het bereik. Franke zei dat deze mogelijkheden de volgende stap op de routekaart zijn, maar dat ze niet in het huidige systeem voorkomen.

Wat dit betekent voor bedrijfsdatateams

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

De eerste is pijplijnarchitectuur. Als uw RAG-agent is geoptimaliseerd voor één zoekgedrag, suggereren de KARL-resultaten dat deze bij andere zoekgedragingen faalt. Multi-task training over divers retrievalgedrag levert modellen op die generaliseren. Smalle pijpleidingen niet.

De tweede is waarom RL hier van belang is – en het is niet alleen een trainingsdetail. Databricks testte het alternatief: distilleren uit expertmodellen via begeleide verfijning. Die aanpak verbeterde de prestaties binnen de distributie, maar leverde verwaarloosbare winsten op bij taken die het model nog nooit had gezien. RL ontwikkelde algemeen zoekgedrag dat overging. Voor bedrijfsteams die te maken hebben met heterogene gegevens en onvoorspelbare soorten zoekopdrachten, is dat onderscheid het hele spel. 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 vragen die het niet kan beantwoorden, diversifieert de zoekopdracht in plaats van mislukte zoekopdrachten te herhalen, en comprimeert de eigen context in plaats van dat er geen ruimte meer is. Het argument om speciaal gebouwde zoekagenten te trainen in plaats van alles via algemene grens-API’s te routeren, gaat niet in de eerste plaats over de kosten. Het gaat erom een ​​model te bouwen dat weet hoe het zijn werk moet doen.