De meeste zakelijke RAG-pijplijnen zijn geoptimaliseerd voor één zoekgedrag. Ze laten de anderen stilletjes in de steek. Een model dat is getraind om rapporten uit verschillende documenten te synthetiseren, kan slecht omgaan met op beperkingen gebaseerde entiteitszoekopdrachten. Een model dat is opgezet voor 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 zakelijke zoekgedragingen met behulp van een nieuw versterkend leeralgoritme. Het resultaat, zo beweert het bedrijf, is een model dat overeenkomt met de Claude Opus 4.6 op een speciaal gebouwde benchmark, met 33% lagere kosten per eenheid. query en 47% lagere latentie, volledig getraind op synthetische gegevens die door de agent zelf zijn gegenereerd zonder dat menselijke labels nodig zijn. Deze vergelijking is gebaseerd op KARLBench, dat Databricks heeft gebouwd om het zoekgedrag van ondernemingen te evalueren.
“Veel van de grote verbeteringen 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 wij voor KARL aan werken, die voor de meeste bedrijven gewoon zijn, zijn niet strikt op dezelfde manier 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 hen 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 beloningshacking niet plaatsvindt – dat is echt niet triviaal”, zei Frankle. “Er is maar weinig te verifiëren van wat bedrijven dagelijks met kennistaken doen.”
De generalisatievalkuil in enterprise-RAG
Standaard RAG verdeelt dubbelzinnige query’s in meerdere stappen die gebruikmaken 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 van ondernemingen te meten: op beperkingen gebaseerde zoekacties naar entiteiten, rapportsynthese tussen documenten, beoordeling van lange documenten met numerieke redenering in tabelvorm, uitputtende zoekacties naar entiteiten, procedureel redeneren over technische documentatie en aggregatie van feiten over interne bedrijfsmemo’s. De laatste taak is PMBench, opgebouwd uit de notulen van de productmanagervergaderingen van Databricks – gefragmenteerd, dubbelzinnig en ongestructureerd op manieren die grensmodellen slecht aankunnen.
Trainen op een enkele taak en testen op de andere taken levert slechte resultaten op. Het KARL-artikel laat zien dat multi-task RL generaliseert op een manier die training met één taak 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 een competitieve strijdkaart voor een financiële dienstverlener op te bouwen, moet de agent b.v. identificeer relevante accounts, filter op recent, reconstrueer eerdere concurrerende deals en leid resultaten af - die nergens in de gegevens worden gelabeld.
Frankle noemt wat KARL doet ‘gefundeerd redeneren’: het uitvoeren van een moeilijke reeks redeneringen 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 plus plus, tot 200 vectordatabaseoproepen.”
De RL-engine: waarom OAPL ertoe doet
De training van KARL wordt mogelijk gemaakt door OAPL, een afkorting voor Optimal Advantage-gebaseerde beleidsoptimalisatie met vertraagd gevolgtrekkingsbeleid. Het is een nieuwe aanpak die gezamenlijk is 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), waarbij ervan wordt uitgegaan dat het model dat trainingsgegevens genereert en het model dat wordt bijgewerkt, gesynchroniseerd zijn. Bij gedistribueerde training is dat nooit het geval. Eerdere benaderingen corrigeerden hiervoor met belangrijkheidssteekproeven die variantie en instabiliteit introduceerden. OAPL omarmt in plaats daarvan het buiten het beleid vallende karakter van gedistribueerde training door gebruik te maken van een regressiemaatstaf die stabiel blijft met beleidsvertragingen van meer dan 400 gradiëntstappen, 100 keer meer buiten het beleid vallende benaderingen dan eerder gehanteerde benaderingen. Bij codegeneratie-experimenten kwam het overeen met een GRPO-getraind model, waarbij ongeveer drie keer minder trainingsmonsters werden gebruikt.
De proefefficiëntie van OAPL zorgt ervoor dat het opleidingsbudget beschikbaar blijft. 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 zakelijk team realistisch gezien kan proberen.
Agenten, geheugen en 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. Onderaan bevindt zich een vectordatabase met miljoenen vermeldingen, die te groot is voor de context. Het LLM-contextvenster bevindt zich bovenaan. Daartussen bevinden zich compressie- en cachelagen 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 verfijnte, details verifieerde en naar documenten keek voordat hij een antwoord gaf, waardoor het contextvenster vele malen werd uitgeput. In plaats van een apart samenvattingsmodel te trainen, liet het team KARL end-to-end compressie leren via RL: wanneer de context te groot wordt, comprimeert de agent deze en gaat verder, waarbij het enige trainingssignaal de beloning aan het einde van de taak is. Door de geleerde 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
Franke was eerlijk over de faalwijzen. KARL worstelt het meest met vragen met aanzienlijke ambiguïteit, 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 bepaalde 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 keuze.
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, worden nog niet behandeld. Frankle zei dat deze opties de volgende zijn op de routekaart, maar dat ze niet in het huidige systeem voorkomen.
Wat dit betekent voor bedrijfsdatateams
KARL somt drie beslissingen op 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 mislukt. Multi-task training voor verschillende ophaalgedragingen 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. Deze aanpak verbeterde de prestaties in de distributie, maar leverde verwaarloosbare winsten op bij taken die het model nog nooit had gezien. RL ontwikkelde algemeen zoekgedrag dat wordt overgenomen. Voor bedrijfsteams die te maken hebben met heterogene gegevens en onvoorspelbare soorten zoekopdrachten is dit verschil baanbrekend. 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 zijn zoekopdracht in plaats van mislukte zoekopdrachten te herhalen, en comprimeert zijn eigen context in plaats van te weinig ruimte te hebben. Het argument om speciaal gebouwde zoekagenten te trainen in plaats van alles via grens-API’s voor algemene doeleinden te routeren, gaat niet in de eerste plaats over de kosten. Het gaat erom een model te bouwen dat weet hoe het moet.
