Een kernelement van elke bewerking voor het ophalen van gegevens is het gebruik van een component die bekend staat als een retriever. Het is zijn taak om de relevante inhoud voor een bepaalde zoekopdracht op te halen.
In het AI-tijdperk zijn retrievers gebruikt als onderdeel van RAG-pijpleidingen. De aanpak is eenvoudig: haal relevante documenten op, stuur ze naar een LLM en laat het model op basis van die context een antwoord genereren.
Hoewel het ophalen misschien een opgelost probleem leek, was het in werkelijkheid niet opgelost voor moderne agentische AI-workflows.
In onderzoek Deze week gepubliceerd heeft Databricks Instructed Retriever geïntroduceerd, een nieuwe architectuur die volgens het bedrijf tot 70% verbetering oplevert ten opzichte van traditionele RAG bij complexe, instructie-intensieve ondernemingsvraag-antwoordtaken. Het verschil komt neer op de manier waarop het systeem metadata begrijpt en gebruikt.
“Veel van de systemen die vóór het tijdperk van grote taalmodellen werden gebouwd om op te halen, waren eigenlijk gebouwd voor mensen om te gebruiken, niet voor agenten”, vertelde Michael Bendersky, onderzoeksdirecteur bij Databricks, aan VentureBeat. “Wat we ontdekten is dat de fouten die van de agent komen in veel gevallen niet zijn omdat de agent niet in staat is om over de gegevens te redeneren. Het komt omdat de agent überhaupt niet in staat is om de juiste gegevens op te halen.”
Wat ontbreekt er bij traditionele RAG-retrievers
Het kernprobleem komt voort uit de manier waarop traditionele RAG omgaat met wat Bendersky ‘specificaties op systeemniveau’ noemt. Deze omvatten de volledige context van gebruikersinstructies, metadataschema’s en voorbeelden die definiëren hoe succesvol ophalen eruit zou moeten zien.
In een typische RAG-pijplijn wordt een gebruikersquery omgezet in een inbedding, soortgelijke documenten worden opgehaald uit een vectordatabase en die resultaten worden ingevoerd in een taalmodel dat kan worden gegenereerd. Het systeem kan basisfiltering bevatten, maar het behandelt elke zoekopdracht fundamenteel als een geïsoleerde oefening in het matchen van tekst.
Deze aanpak mislukt met echte bedrijfsgegevens. Bedrijfsdocumenten bevatten vaak rijke metagegevens, zoals tijdstempels, auteursinformatie, productbeoordelingen, documenttypen en domeinspecifieke kenmerken. Wanneer een gebruiker een vraag stelt die redenering over deze metadatavelden vereist, heeft de traditionele RAG het moeilijk.
Neem dit voorbeeld eens: ‘Laat mij vijfsterrenproductrecensies van de afgelopen zes maanden zien, maar sluit alles van Merk X uit.’ Traditionele RAG kan deze natuurlijke taalbeperking niet op betrouwbare wijze vertalen naar de juiste databasefilters en gestructureerde zoekopdrachten.
“Als je alleen maar een traditioneel RAG-systeem gebruikt, is er geen manier om gebruik te maken van al deze verschillende signalen over de gegevens die zijn ingekapseld in metadata”, zei Bendersky. “Ze moeten worden doorgegeven aan de agent zelf om het juiste werk te doen bij het ophalen.”
Het probleem wordt urgenter naarmate bedrijven verder gaan dan het eenvoudig zoeken naar documenten naar agentische workflows. Een mens die een zoeksysteem gebruikt, kan zoekopdrachten herformuleren en filters handmatig toepassen wanneer de eerste resultaten niet kloppen. Een AI-agent die autonoom opereert, heeft het ophaalsysteem zelf nodig om complexe, veelzijdige instructies te begrijpen en uit te voeren.
Hoe de Instructed Retriever werkt
De aanpak van Databricks herontwerpt de ophaalpijplijn fundamenteel. Het systeem geeft volledige systeemspecificaties door tijdens elke fase van zowel het ophalen als genereren. Deze specificaties omvatten gebruikersinstructies, gelabelde voorbeelden en indexschema’s.
De architectuur voegt drie belangrijke mogelijkheden toe:
Query-ontleding: Het systeem verdeelt complexe, uit meerdere delen bestaande verzoeken in een zoekplan met meerdere trefwoordzoekopdrachten en filterinstructies. Een verzoek om “recente FooBrand-producten met uitzondering van Lite-modellen” wordt opgesplitst in gestructureerde zoekopdrachten met de juiste metadatafilters. Traditionele systemen zouden een enkele semantische zoekopdracht proberen.
Metadata-redenering: Instructies in natuurlijke taal worden vertaald in databasefilters. ‘Van vorig jaar’ wordt een datumfilter, ‘vijfsterrenrecensies’ worden een beoordelingsfilter. Het systeem begrijpt welke metadata beschikbaar zijn en hoe deze kan worden afgestemd op de intentie van de gebruiker.
Contextuele relevantie: tijdens de herschikkingsfase wordt de volledige context van gebruikersinstructies gebruikt om documenten die overeenkomen met de intentie een boost te geven, zelfs als trefwoorden zwakker overeenkomen. Het systeem kan prioriteit geven aan recentheid of specifieke documenttypen op basis van specificaties in plaats van alleen tekstovereenkomst.
“De magie zit in de manier waarop we de vragen construeren”, zei Bendersky. “We proberen de tool te gebruiken zoals een agent dat zou doen, niet zoals een mens dat zou doen. Het beschikt over alle fijne kneepjes van de API en gebruikt deze zo goed mogelijk.”
Contextueel geheugen versus ophaalarchitectuur
In de tweede helft van 2025 vond er in de sector een verschuiving plaats van RAG naar agentisch AI-geheugen, ook wel contextueel geheugen genoemd. Benaderingen inclusief Achteraf gezien En A-MEM kwam naar voren en bood de belofte van een RAG-vrije toekomst.
Bendersky stelt dat contextueel geheugen en verfijnde retrieval verschillende doelen dienen. Beide zijn nodig voor zakelijke AI-systemen.
“Je kunt onmogelijk alles in je onderneming in je contextuele geheugen opslaan”, merkte Bendersky op. “Je hebt beide nodig. Je hebt contextueel geheugen nodig om specificaties te leveren, om schema’s te leveren, maar je hebt nog steeds toegang nodig tot de gegevens, die over meerdere tabellen en documenten kunnen worden verdeeld.”
Contextueel geheugen blinkt uit in het bijhouden van taakspecificaties, gebruikersvoorkeuren en metadataschema’s binnen een sessie. Het houdt de “spelregels” direct beschikbaar. Maar het feitelijke bedrijfsdatacorpus bestaat buiten dit contextvenster. De meeste ondernemingen hebben datavolumes die zelfs de royale contextvensters met ordes van grootte overschrijden.
Instructed Retriever maakt gebruik van contextueel geheugen voor specificaties op systeemniveau, terwijl het ophalen wordt gebruikt om toegang te krijgen tot het bredere gegevensdomein. De specificaties in de context geven aan hoe de retriever zoekopdrachten construeert en resultaten interpreteert. Het retrievalsysteem haalt vervolgens specifieke documenten op van potentieel miljarden kandidaten.
Deze taakverdeling is van belang voor de praktische inzet. Het in context plaatsen van miljoenen documenten is niet haalbaar en ook niet efficiënt. Alleen al de metagegevens kunnen substantieel zijn als het gaat om heterogene systemen binnen een onderneming. Instructed Retriever lost dit op door metadata direct bruikbaar te maken, zonder dat deze allemaal in de context moeten passen.
Beschikbaarheid en praktische overwegingen
Instructed Retriever is nu beschikbaar als onderdeel van Databricks Agent-stenen; het is ingebouwd in het Knowledge Assistant-product. Bedrijven die Knowledge Assistant gebruiken om vraag-antwoordsystemen over hun documenten te bouwen, maken automatisch gebruik van de Instructed Retriever-architectuur zonder aangepaste RAG-pijplijnen te bouwen.
Het systeem is niet beschikbaar als open source, hoewel Bendersky aangaf dat Databricks een bredere beschikbaarheid overweegt. Voorlopig is de strategie van het bedrijf om benchmarks zoals StaRK-Instruct vrij te geven aan de onderzoeksgemeenschap, terwijl de implementatie eigen blijft aan de bedrijfsproducten.
De technologie is met name veelbelovend voor bedrijven met complexe, zeer gestructureerde gegevens die rijke metadata bevatten. Bendersky noemde gebruiksscenario’s in de financiële wereld, e-commerce en gezondheidszorg. In wezen kan elk domein waar documenten betekenisvolle attributen hebben die verder gaan dan ruwe tekst hiervan profiteren.
“Wat we in sommige gevallen hebben gezien, ontsluit dingen die de klant niet zonder kan”, zegt Bendersky.
Hij legde uit dat gebruikers zonder Instructed Retriever meer gegevensbeheertaken moeten uitvoeren om inhoud in de juiste structuur en tabellen te plaatsen, zodat een LLM de juiste informatie op de juiste manier kan ophalen.
“Hier kun je gewoon een index maken met de juiste metadata, je retriever daarop wijzen, en het werkt gewoon out-of-the-box”, zei hij.
Wat dit betekent voor de AI-strategie van ondernemingen
Voor bedrijven die tegenwoordig op RAG gebaseerde systemen bouwen, komt uit het onderzoek een cruciale vraag naar voren: is uw ophaalpijplijn daadwerkelijk in staat om de instructies te volgen en metagegevens te redeneren die uw gebruiksscenario vereist?
De verbetering van 70% die Databricks aantoont, is niet haalbaar via incrementele optimalisatie. Het vertegenwoordigt een architectonisch verschil in de manier waarop systeemspecificaties door het ophaal- en generatieproces stromen. Organisaties die hebben geïnvesteerd in het zorgvuldig structureren van hun data met gedetailleerde metadata kunnen tot de conclusie komen dat traditionele RAG een groot deel van de waarde van die structuur op tafel laat liggen.
Voor bedrijven die AI-systemen willen implementeren die op betrouwbare wijze complexe, uit meerdere delen bestaande instructies over heterogene gegevensbronnen kunnen volgen, geeft het onderzoek aan dat de ophaalarchitectuur de kritische onderscheidende factor kan zijn.
Degenen die nog steeds vertrouwen op basis-RAG voor productiegebruiksscenario’s met rijke metadata moeten evalueren of hun huidige aanpak fundamenteel aan hun vereisten kan voldoen. De prestatiekloof die Databricks laat zien, suggereert dat een meer geavanceerde ophaalarchitectuur nu van cruciaal belang is voor ondernemingen met complexe datadomeinen.
