Home Nieuws Dit boomzoekraamwerk bereikt 98,7% van de documenten waarin het zoeken naar vectoren...

Dit boomzoekraamwerk bereikt 98,7% van de documenten waarin het zoeken naar vectoren mislukt

8
0
Dit boomzoekraamwerk bereikt 98,7% van de documenten waarin het zoeken naar vectoren mislukt

Een nieuw open source-framework genaamd Pagina-index lost een van de oude problemen van Retrieval-Augmented Generation (RAG) op: het omgaan met zeer lange documenten.

De klassieke RAG-workflow (documenten clusteren, insluitingen berekenen, ze opslaan in een vectordatabase en de beste overeenkomsten ophalen op basis van semantische gelijkenis) werkt goed voor basistaken zoals vraag-en-antwoord over kleine documenten.

PageIndex laat de standaard ‘chunk-and-embed’-benadering volledig varen en beschouwt het ophalen van documenten niet als een zoekprobleem, maar als een navigatieprobleem.

Maar terwijl bedrijven RAG proberen om te zetten in intensieve workflows – het controleren van financiële overzichten, het analyseren van juridische contracten, het navigeren door farmaceutische protocollen – stuiten ze op een nauwkeurigheidsbarrière die stukje bij beetje optimalisatie niet kan oplossen.

AlphaGo voor documenten

PageIndex pakt deze beperkingen aan door een concept te lenen van gameplay-AI in plaats van van zoekmachines: zoeken in bomen.

Wanneer mensen specifieke informatie moeten vinden in een compact leerboek of een lang jaarverslag, scannen ze niet elke sectie lineair. Ze raadplegen de inhoudsopgave om het juiste hoofdstuk te identificeren, vervolgens de sectie en ten slotte de specifieke pagina. PageIndex dwingt LLM om dit menselijke gedrag te repliceren.

In plaats van vectoren vooraf te berekenen, bouwt het raamwerk een “algemene index” van de structuur van het document, waardoor een boom ontstaat waarin knooppunten hoofdstukken, secties en subsecties vertegenwoordigen. Wanneer een zoekopdracht binnenkomt, voert LLM een boomzoekopdracht uit die elk knooppunt expliciet classificeert als relevant of irrelevant op basis van de volledige context van het verzoek van de gebruiker.

Hoe PageIndex werkt (zuur: PageIndex GitHub)

“In computerwetenschappelijke termen is een inhoudsopgave een boomgestructureerde weergave van een document, en het navigeren daarin is vergelijkbaar met het zoeken in bomen,” zei Zhang. “PageIndex gebruikt hetzelfde kernidee – zoeken in bomen – voor het ophalen van documenten en kan worden gezien als een AlphaGo-achtig systeem voor het ophalen van documenten in plaats van voor gamen.”

Dit verschuift het architecturale paradigma van passief ophalen, waarbij het systeem eenvoudigweg overeenkomende tekst ophaalt, naar actieve navigatie, waarbij een agentmodel bepaalt waar te kijken.

De grenzen van semantische gelijkenis

Er zit een fundamentele fout in de manier waarop traditionele RAG verwerkt complexe gegevens. Bij het ophalen van vectoren wordt ervan uitgegaan dat de tekst die semantisch het meest lijkt op de zoekopdracht van een gebruiker, ook het meest relevant is. In professionele domeinen gaat deze aanname vaak niet op.

Mingtian Zhang, mede-oprichter van PageIndex, wijst op financiële rapportage als een goed voorbeeld van deze manier van falen. Als een financieel analist een AI vraagt ​​naar ‘EBITDA’ (winst vóór rente, belasting, afschrijvingen en amortisatie), haalt een standaard vectordatabase elk onderdeel op waarin dat acroniem of een soortgelijke term voorkomt.

“Meerdere secties kunnen EBITDA vermelden met vergelijkbare bewoordingen, maar slechts één sectie definieert de precieze berekening, aanpassingen of rapportagereikwijdte die relevant zijn voor de vraag”, vertelde Zhang aan VentureBeat. “Een op gelijkenis gebaseerde retriever heeft moeite om deze gevallen te onderscheiden, omdat de semantische signalen bijna niet van elkaar te onderscheiden zijn.”

Dit is de kloof tussen intentie en inhoud. De gebruiker wil het woord “EBITDA” niet vinden; ze willen de ‘logica’ erachter voor dat specifieke kwartaal begrijpen.

Bovendien verwijderen traditionele insluitingen de query uit zijn context. Omdat insluitingsmodellen strikte limieten voor de invoerlengte hebben, ziet het ophaalsysteem meestal alleen de specifieke vraag die wordt gesteld en negeert het de voorgaande rondes van het gesprek. Dit scheidt de ophaalstap van het redeneerproces van de gebruiker. Het systeem koppelt documenten aan een korte, gedecontextualiseerde zoekopdracht in plaats van aan de hele geschiedenis van het probleem dat de gebruiker probeert op te lossen.

Het multi-hop redeneerprobleem oplossen

De impact van deze structurele aanpak in de echte wereld is het meest zichtbaar bij ‘multi-hop’-query’s waarbij de AI een spoor van broodkruimels door verschillende delen van een document moet volgen.

In een recente benchmarktest, bekend als FinanceBench, werd een systeem gebouwd op PageIndex genaamd “Meer 2.5” behaalde een state-of-the-art nauwkeurigheidsscore van 98,7%. De prestatiekloof tussen deze aanpak en vectorgebaseerde systemen wordt duidelijk wanneer wordt geanalyseerd hoe ze omgaan met interne referenties.

Zhang geeft een voorbeeld van een vraag over de totale waarde van uitgestelde activa in een jaarverslag van de Federal Reserve. Het hoofdgedeelte van het rapport beschrijft de “verandering” in waarde, maar toont niet het totaal. In de tekst staat echter een voetnoot: “Zie bijlage G bij dit rapport… voor meer gedetailleerde informatie.”

Een vectorgebaseerd systeem faalt hier doorgaans. De tekst in bijlage G lijkt niet op de vraag van de gebruiker over uitgestelde activa; het is waarschijnlijk gewoon een tabel met getallen. Omdat er geen semantische match is, negeert de vectordatabase deze.

De op redenering gebaseerde retriever leest echter de aanwijzing in de hoofdtekst, volgt de structurele link naar bijlage G, lokaliseert de juiste tabel en retourneert het exacte getal.

De afweging tussen latentie en infrastructuurswitching

Voor enterprise-architecten is latentie de directe zorg bij een LLM-gestuurd zoekproces. Het opzoeken van vectoren gebeurt in milliseconden; als een LLM een inhoudsopgave “leest”, impliceert dit een aanzienlijk langzamere gebruikerservaring.

Zhang legt echter uit dat de waargenomen latentie voor de eindgebruiker verwaarloosbaar kan zijn vanwege de manier waarop ophalen is geïntegreerd in het generatieproces. In een klassieke RAG-opstelling is het ophalen een blokkerende stap: het systeem moet de database doorzoeken voordat het een antwoord kan genereren. Met PageIndex vindt het ophalen inline plaats tijdens het redeneerproces van het model.

“Het systeem kan onmiddellijk beginnen met streamen en ophalen terwijl het wordt gegenereerd”, zei Zhang. “Dit betekent dat PageIndex geen extra ‘fetch port’ toevoegt vóór het eerste token, en dat de Time to First Token (TTFT) vergelijkbaar is met een normale LLM-oproep.”

Deze architecturale verschuiving vereenvoudigt ook de data-infrastructuur. Door de afhankelijkheid van inbedding weg te nemen, hoeven bedrijven niet langer een speciale vectordatabase bij te houden. De boomgestructureerde index is licht genoeg om in een traditionele relationele database zoals PostgreSQL te passen.

Dit pakt een groeiend pijnpunt aan in LLM-systemen met ophaalcomponenten: de complexiteit van het synchroon houden van vectoropslag met live documenten. PageIndex scheidt structuurindexering van tekstextractie. Als een contract verandert of een beleid wordt bijgewerkt, kan het systeem kleine wijzigingen verwerken door alleen de betrokken subboom opnieuw te indexeren in plaats van het hele documentcorpus opnieuw te verwerken.

Een beslissingsmatrix voor het bedrijf

Hoewel de nauwkeurigheidsverbetering overtuigend is, is het zoeken naar bomen geen universele vervanging voor het zoeken naar vectoren. De technologie kan het best worden gezien als een gespecialiseerd hulpmiddel voor ‘diepgaand werk’ en niet als een allesomvattend hulpmiddel voor elke ophaaltaak.

Voor korte documenten, zoals e-mails of chatlogboeken, past de hele context vaak in het contextvenster van een moderne LLM, waardoor elk ophaalsysteem overbodig wordt. Omgekeerd blijven vectorinsluitingen voor taken die uitsluitend op semantische ontdekking zijn gebaseerd, zoals het aanbevelen van vergelijkbare producten of het vinden van inhoud met een vergelijkbare ‘sfeer’, de superieure keuze, omdat het doel nabijheid is en niet redeneren.

PageIndex past precies in het midden: lange, zeer gestructureerde documenten waarbij de kosten van fouten hoog zijn. Dit omvat technische handleidingen, FDA-registraties en fusieovereenkomsten. In deze scenario’s is de vereiste controleerbaarheid. Een bedrijfssysteem moet niet alleen het antwoord kunnen uitleggen, maar ook het pad dat het heeft gevolgd om het te vinden (bijvoorbeeld bevestigen dat het paragraaf 4.1 heeft gecontroleerd, de verwijzing naar bijlage B heeft gevolgd en de daar gevonden gegevens heeft gesynthetiseerd).

PageIndex versus RAG

Afbeelding tegoed: VentureBeat met Nano Banana Pro

De toekomst van bureausourcing

De opkomst van raamwerken als PageIndex signaleert een bredere trend in de AI-stack: de beweging richting “Agent RAG.” Naarmate modellen beter in staat zijn te plannen en te redeneren, verschuift de verantwoordelijkheid voor het vinden van gegevens van de databaselaag naar de modellaag.

We zien dit al in de codeerkamer, waar agenten dat graag doen Claude-code en Cursor stapt af van eenvoudige vectorzoekopdrachten ten gunste van actieve codebase-verkenning. Zhang gelooft dat het terugvinden van generieke documenten hetzelfde traject zal volgen.

“Vectordatabases hebben nog steeds geschikte gebruiksscenario’s”, zei Zhang. “Hun historische rol als standaarddatabase voor LLM’s en AI zal in de loop van de tijd echter minder duidelijk worden.”

Nieuwsbron

LAAT EEN REACTIE ACHTER

Vul alstublieft uw commentaar in!
Vul hier uw naam in