Het 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 relevante inhoud voor een specifieke zoekopdracht op te halen.
In het AI-tijdperk zijn retrievers gebruikt als onderdeel van de RAG-pijplijn. De aanpak is eenvoudig: neem relevante documenten, voer ze in LLM in en laat het model antwoorden genereren op basis van die context.
Hoewel het ophalen een opgelost probleem lijkt, is het feitelijk onoplosbaar voor moderne AI-workflows voor agenten.
In de onderzoek Deze week gepubliceerd, introduceert Databricks Instructed Retriever, een nieuwe architectuur die volgens het bedrijf tot 70% verbetering oplevert ten opzichte van traditionele RAG bij het beantwoorden van complexe, instructie-zware ondernemingsvragen. 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 menselijk gebruik, niet voor gebruik door agenten”, vertelde Michael Bendersky, onderzoeksdirecteur bij Databricks, aan VentureBeat. “Wat we ontdekten was dat de fouten van de agent in veel gevallen niet te wijten waren aan het feit dat de agent de gegevens niet in overweging kon nemen, maar omdat de agent niet in staat was de juiste gegevens op te halen.”
Wat ontbreekt er aan de traditionele RAG-retriever
Het kernprobleem komt voort uit de manier waarop traditionele RAG omgaat met wat Bendersky ‘specificaties op systeemniveau’ noemt. Dit omvat de volledige context van gebruikersinstructies, een metadataschema en voorbeelden die definiëren hoe succesvol ophalen eruit ziet.
In een typische RAG-pijplijn worden gebruikersquery’s omgezet in inbedding, worden vergelijkbare documenten opgehaald uit een vectordatabase en worden de resultaten in een taalmodel ingevoerd om te worden gegenereerd. Deze systemen kunnen basisfiltering omvatten, maar behandelen elke zoekopdracht in essentie als een geïsoleerde oefening in het matchen van tekst.
Deze aanpak komt niet overeen met daadwerkelijke bedrijfsgegevens. Bedrijfsdocumenten bevatten vaak rijke metagegevens, zoals tijdstempels, auteursinformatie, productbeoordelingen, documenttypen en domeinspecifieke kenmerken. Wanneer gebruikers vragen stellen waarbij rekening moet worden gehouden met deze metadatavelden, hebben traditionele RAG’s het moeilijk.
Neem dit voorbeeld eens: ‘Toon vijfsterrenproductrecensies van de afgelopen zes maanden, maar sluit alles van Merk X uit.’ Traditionele RAG’s kunnen dergelijke natuurlijke taalbeperkingen niet op betrouwbare wijze vertalen in geschikte databasefilters en gestructureerde zoekopdrachten.
“Als je alleen maar een traditioneel RAG-systeem gebruikt, kun je op geen enkele manier profiteren van alle verschillende signalen over de gegevens die in metadata zijn verpakt”, zegt Bendersky. “Ze moeten aan de agenten zelf worden doorgegeven, zodat ze ze goed kunnen innemen.”
Dit probleem wordt urgenter naarmate bedrijven overstappen van eenvoudige documentzoekopdrachten naar agentische workflows. Mensen die zoeksystemen gebruiken, kunnen zoekopdrachten herformuleren en filters handmatig toepassen als de eerste resultaten niet kloppen. AI-agenten die autonoom opereren, vereisen dat het ophaalsysteem zelf complexe, veelzijdige instructies begrijpt en uitvoert.
Hoe de geïnstrueerde retriever werkt
De aanpak van Databricks herontwerpt het ophaalpad fundamenteel. Het systeem implementeert volledige systeemspecificaties tijdens elke opname- en bouwfase. Deze specificatie omvat gebruikersinstructies, gelabelde voorbeelden en een indexschema.
De architectuur voegt drie belangrijke mogelijkheden toe:
Query-ontleding: Het systeem splitst een complexe, uit meerdere delen bestaande zoekopdracht op in een zoekplan met meerdere trefwoordzoekopdrachten en filterinstructies. De zoekopdracht naar “nieuwste FooBrand-producten met uitzondering van lichte modellen” wordt opgesplitst in een gestructureerde zoekopdracht met geschikte metadatafilters. Traditionele systemen zullen een enkele semantische zoekopdracht proberen.
Redenen voor metadata: Instructies in natuurlijke taal worden vertaald in databasefilters. “Van vorig jaar” wordt het datumfilter, “vijfsterrenrecensies” wordt het beoordelingsfilter. Het systeem begrijpt welke metadata beschikbaar zijn en hoe deze kan worden afgestemd op de intentie van de gebruiker.
Contextuele relevantie: In de fase van het opnieuw rangschikken wordt de volledige context van de instructies van de gebruiker gebruikt om documenten te verbeteren die overeenkomen met de intentie, zelfs als trefwoorden zwakkere overeenkomsten hebben. Het systeem kan prioriteit geven aan recentheid of bepaalde soorten documenten op basis van specificaties, en niet alleen op tekstovereenstemming.
“De magie zit in de manier waarop we de vragen formuleren”, zei Bendersky. “We proberen deze tool te gebruiken zoals een agent dat zou doen, niet zoals een mens dat zou doen. Het heeft alle ins en outs van een API en gebruikt deze zo goed als hij kan.”
Contextueel geheugen versus architectuur voor het ophalen van contextueel geheugen
In de tweede helft van 2025 zal er in de sector een verschuiving plaatsvinden van RAG naar agent AI-geheugen, ook wel contextueel geheugen genoemd. Benaderingen omvatten Terugkijkend En A-MEM kwam naar voren en bood de belofte van een RAG-vrije toekomst.
Bendersky voerde aan dat contextueel geheugen en verfijnde retrieval verschillende doelen dienen. Beide zijn nodig voor zakelijke AI-systemen.
“Je kunt onmogelijk alles in je bedrijf in je contextuele geheugen passen”, zegt Bendersky. “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” altijd beschikbaar. Maar het feitelijke gegevenscorpus van het bedrijf ligt buiten dit contextvenster. De meeste bedrijven hebben datavolumes die zelfs grote contextvensters overschrijden.
Instructed Retriever maakt gebruik van contextueel geheugen voor specificaties op systeemniveau, terwijl het ophalen wordt gebruikt om toegang te krijgen tot een breder gegevensdomein. Specificaties in context geven aan hoe de retriever zoekopdrachten construeert en resultaten interpreteert. Het retrievalsysteem haalt vervolgens specifieke documenten uit miljarden kandidaten.
Deze taakverdeling is van belang voor praktische toepassingen. Het in context plaatsen van miljoenen documenten is niet haalbaar en ook niet efficiënt. Metagegevens alleen kunnen belangrijk zijn bij het omgaan met heterogene systemen in een onderneming. Instructed Retriever lost dit probleem op door metadata direct bruikbaar te maken zonder dat alles in context hoeft te staan.
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 een vraag-antwoordsysteem voor hun documenten te bouwen, maken automatisch gebruik van de Instructed Retriever-architectuur zonder een speciale RAG-pijplijn 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 implementaties consistent blijven met de producten van het bedrijf.
Deze technologie is met name veelbelovend voor bedrijven met complexe, zeer gestructureerde gegevens en rijke metadata. Bendersky noemde gebruiksscenario’s in de financiële wereld, e-commerce en gezondheidszorg. In principe kan elk domein waarvan de documenten betekenisvolle attributen hebben die verder gaan dan de ruwe tekst hiervan profiteren.
“Wat we in sommige gevallen zien is het ontsluiten van dingen waar klanten niet zonder zouden kunnen”, zegt Bendersky.
Hij legt uit dat gebruikers zonder Instructed Retriever meer gegevensbeheertaken zouden moeten uitvoeren om inhoud in de juiste structuren en tabellen te krijgen, zodat LLM de juiste informatie correct kan ophalen.
“Hier maak je gewoon een index met de juiste metadata, richt je retriever erop en het werkt gewoon,” zei hij.
Wat dit betekent voor de AI-strategieën van bedrijven
Voor bedrijven die vandaag de dag op RAG gebaseerde systemen bouwen, roept dit onderzoek een belangrijke vraag op: is uw capture pipeline werkelijk in staat om de instructies en metadata-redenering te volgen die vereist zijn voor uw gebruiksscenario?
De door Databricks aangetoonde verbetering van 70% had niet kunnen worden bereikt door aanvullende optimalisatie. Dit vertegenwoordigt architectonische verschillen in de manier waarop systeemspecificaties door de vastleg- en bouwprocessen stromen. Organisaties die hebben geïnvesteerd in het zorgvuldig structureren van hun gegevens met gedetailleerde metadata kunnen tot de conclusie komen dat traditionele RAG een groot deel van de waarde van die structuur achter zich laat.
Voor bedrijven die AI-systemen willen inzetten die op betrouwbare wijze complexe, uit meerdere delen bestaande instructies uit heterogene databronnen kunnen volgen, laat dit onderzoek zien dat ophaalarchitectuur een belangrijke 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 behoeften kan voldoen. De door Databricks aangetoonde prestatieverschillen suggereren dat meer geavanceerde ophaalarchitecturen nu van cruciaal belang zijn voor bedrijven met complexe datadomeinen.
