Een fundamenteel element van elke gegevenshersteloperatie is het gebruik van een component die bekend staat als een retriever. Het is zijn taak om inhoud op te halen die relevant is voor een bepaalde zoekopdracht.
In het tijdperk van kunstmatige intelligentie worden retrievers gebruikt als onderdeel van RAG-pijpleidingen. De aanpak is eenvoudig: haal de relevante documenten op, plaats ze in een LLM en laat het model op basis van die context een antwoord genereren.
Hoewel herstel een opgelost probleem lijkt, is dit in werkelijkheid niet opgelost voor moderne AI-workflows met agenten.
In onderzoek Deze week uitgebracht, introduceert Databricks Instructed Retriever, een nieuwe architectuur die volgens het bedrijf tot 70% verbetering biedt ten opzichte van traditionele RAG op het gebied van complexe, instructierijke zakelijke taken voor het beantwoorden van vragen. Het verschil ligt in de manier waarop het systeem metadata begrijpt en gebruikt.
“Veel van de systemen die vóór het tijdperk van grote taalmodellen zijn gebouwd om op te halen, zijn feitelijk gebouwd voor gebruik door mensen, en niet door agenten”, vertelde Michael Bendersky, onderzoeksdirecteur bij Databricks, aan VentureBeat. “Wat we hebben ontdekt is dat de fouten die van de agent komen in veel gevallen niet komen doordat de agent niet over de gegevens kan redeneren. Het komt doordat de agent niet in staat is de juiste gegevens op te halen.”
Wat ontbreekt er bij traditionele RAG Retrievers
Het grootste probleem 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 een succesvol herstel 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 in een taalmodel ingevoerd om te worden gegenereerd. Het systeem kan basisfiltering bevatten, maar het behandelt elke zoekopdracht feitelijk als een geïsoleerde oefening in het matchen van tekst.
Deze aanpak werkt niet met echte bedrijfsgegevens. Zakelijke documenten 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 in de juiste databasefilters en gestructureerde zoekopdrachten.
“Als je alleen maar een traditioneel RAG-systeem gebruikt, is er geen manier om al deze verschillende signalen te gebruiken op de gegevens die zijn ingekapseld in de metadata”, aldus Bendersky. “Ze moeten worden doorgegeven aan de agent zelf, zodat hij tijdens het herstel de juiste taak kan uitvoeren.”
Het probleem wordt urgenter naarmate bedrijven verder gaan dan het eenvoudig zoeken naar documenten naar op agenten gebaseerde workflows. Een mens die een zoeksysteem gebruikt, kan zoekopdrachten herformuleren en handmatig filters toepassen wanneer de eerste resultaten niet aan het doel voldoen. Een AI-agent die autonoom opereert, heeft het ophaalsysteem zelf nodig om complexe en veelzijdige instructies te begrijpen en uit te voeren.
Hoe de opgeleide Retriever werkt
De aanpak van Databricks herontwerpt de herstelpijplijn fundamenteel. Het systeem verspreidt de specificaties van het volledige systeem tijdens elke fase van zowel herstel als opwekking. Deze specificaties omvatten gebruikersinstructies, gelabelde voorbeelden en indexschema’s.
De architectuur voegt drie belangrijke mogelijkheden toe:
Uitsplitsing van de zoekopdracht– Het systeem splitst complexe, uit meerdere delen bestaande verzoeken op 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.
Redeneren over metadata: Verklaringen in natuurlijke taal worden vertaald in databasefilters. “Sinds vorig jaar” wordt een datumfilter, “vijfsterrenrecensies” wordt een beoordelingsfilter. Het systeem begrijpt welke metadata beschikbaar zijn en hoe deze kan worden afgestemd op de bedoelingen van de gebruiker.
Contextuele relevantie: De herclassificatiefase gebruikt de volledige context van de gebruikersinstructies om documenten die overeenkomen met de intentie een boost te geven, zelfs als trefwoorden een zwakkere overeenkomst hebben. Het systeem kan prioriteit geven aan actuele zaken of specifieke documenttypen op basis van specificaties in plaats van eenvoudige tekstovereenkomst.
“De magie zit in de manier waarop we de zoekopdrachten construeren”, zegt Bendersky. “We proberen de tool te gebruiken zoals een agent dat zou doen, en niet zoals een mens dat zou doen. Het heeft alle complexiteiten van de API en gebruikt deze zo goed als hij kan.”
Contextueel geheugen en ophaalarchitectuur
In de tweede helft van 2025 heeft er in de sector een verschuiving plaatsgevonden van RAG naar agentisch AI-geheugen, ook wel contextueel geheugen genoemd. Benaderingen inbegrepen Achteraf gezien EN A-MEM kwam naar voren en bood de belofte van een toekomst zonder RAG.
Bendersky stelt dat contextueel geheugen en verfijnde retrieval verschillende doelen dienen. Beide zijn nodig voor zakelijke AI-systemen.
“Je kunt niet alles over je bedrijf in je contextuele geheugen passen”, 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 verspreid.”
Contextueel geheugen blinkt uit in het bijhouden van taakspecificaties, gebruikersvoorkeuren en metadataschema’s binnen een sessie. Houdt de “spelregels” direct beschikbaar. Maar de echte hoeveelheid bedrijfsgegevens bestaat buiten dit contextvenster. De meeste bedrijven beschikken over 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 een grotere schat aan gegevens. Specificaties in context geven aan hoe de retriever zoekopdrachten construeert en resultaten interpreteert. Het retrievalsysteem haalt vervolgens specifieke documenten uit potentieel miljarden kandidaten.
Deze taakverdeling is van belang voor de praktische uitvoering. Het laden van miljoenen documenten in context is niet haalbaar en ook niet efficiënt. Alleen al metagegevens kunnen substantieel zijn als het gaat om heterogene systemen binnen een onderneming. Instructed Retriever lost dit probleem op door metadata direct bruikbaar te maken, zonder dat alles in de context hoeft te passen.
Beschikbaarheid en praktische overwegingen
Instructed Retriever is nu beschikbaar als onderdeel van Databricks Agent-stenen; is geïntegreerd in het Knowledge Assistant-product. Bedrijven die Knowledge Assistant gebruiken om vraag-antwoordsystemen voor 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 eigen implementaties van de bedrijfsproducten behouden blijven.
De technologie is bijzonder 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 gebied waar documenten betekenisvolle attributen hebben die verder gaan dan ruwe tekst hiervan profiteren.
“Wat we in sommige gevallen hebben gezien, ontsluit dingen waar de klant niet zonder kan”, aldus Bendersky.
Hij legde uit dat gebruikers zonder Instructed Retriever meerdere gegevensbeheertaken moeten uitvoeren om inhoud in de juiste structuur en tabellen te plaatsen, zodat een LLM met succes de juiste informatie kan ophalen.
“Hier kun je gewoon een index maken met de juiste metadata, je retriever daarnaar verwijzen en het werkt meteen”, zei hij.
Wat dit betekent voor de AI-strategie van uw bedrijf
Voor bedrijven die tegenwoordig op RAG gebaseerde systemen bouwen, roept het onderzoek een belangrijke vraag op: is de herstelpijplijn daadwerkelijk in staat om instructies te volgen en te redeneren over de metadata die vereist is voor de use case?
De door Databricks aangetoonde verbetering van 70% is niet haalbaar via incrementele optimalisatie. Het vertegenwoordigt een architectonisch verschil in de manier waarop systeemspecificaties het ophaal- en generatieproces doorlopen. 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 inzetten die op betrouwbare wijze complexe, uit meerdere delen bestaande instructies uit heterogene databronnen kunnen volgen, wijst onderzoek uit dat de ophaalarchitectuur de kritische onderscheidende factor kan zijn.
Degenen die nog steeds vertrouwen op basis-RAG voor productiegebruiksscenario’s waarbij geavanceerde metadata betrokken zijn, moeten evalueren of hun huidige aanpak substantieel aan hun behoeften kan voldoen. De door Databricks aangetoonde prestatiekloof suggereert dat een meer geavanceerde herstelarchitectuur nu van groot belang is voor bedrijven met complexe data-assets.
