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

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

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

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

PageIndex verlaat de standaard “chunk-and-embed”-methode volledig en behandelt het ophalen van documenten niet als een zoekprobleem, maar als een navigatieprobleem.

Maar terwijl bedrijven RAG proberen te verplaatsen naar workflows waar veel op het spel staat (het controleren van financiële overzichten, het analyseren van juridische contracten, het navigeren door farmaceutische protocollen) stuiten ze op een nauwkeurigheidsbarrière die deeloptimalisatie niet kan oplossen.

AlphaGo voor documenten

PageIndex pakt deze beperkingen aan door een concept te lenen van game-playing AI in plaats van van zoekmachines: boom zoeken.

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

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

Hoe PageIndex werkt (zie: PageIndex GitHub)

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

Dit verschuift het architecturale paradigma van passief ophalen, waarbij het systeem eenvoudigweg overeenkomende tekst ophaalt, naar actieve navigatie, waarbij een agentisch model beslist 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 mis.

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, belastingen, afschrijvingen en amortisatie), haalt een standaard vectordatabase elk deel op waar 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 ontdoen traditionele inbedding de vraag van zijn context. Omdat insluitingsmodellen strikte limieten voor de invoerlengte hebben, ziet het ophaalsysteem meestal alleen de specifieke vraag die wordt gesteld, waarbij de voorgaande wendingen van het gesprek worden genegeerd. Hierdoor wordt de ophaalstap losgemaakt van het redeneerproces van de gebruiker. Het systeem koppelt documenten aan een korte, gedecontextualiseerde zoekopdracht in plaats van aan de volledige 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 het 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 vermeldt niet het totaal. De tekst bevat echter een voetnoot: “Zie bijlage G van dit rapport … voor meer gedetailleerde informatie.”

Een vectorgebaseerd systeem faalt hier doorgaans. De tekst in bijlage G lijkt in niets 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 nauwkeurige cijfer.

De latentie-trade-off en de verschuiving van de infrastructuur

Voor enterprise-architecten is latentie de directe zorg bij een LLM-gestuurd zoekproces. Vector-lookups vinden plaats 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 het 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 gebeurt het ophalen inline, tijdens het redeneerproces van het model.

“Het systeem kan onmiddellijk beginnen met streamen en ophalen terwijl het wordt gegenereerd”, zei Zhang. “Dat betekent dat PageIndex geen extra ‘ophaalpoort’ toevoegt vóór het eerste token, en dat 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 levende documenten. PageIndex scheidt structuurindexering van tekstextractie. Als een contract wordt gewijzigd 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 de onderneming

Hoewel de nauwkeurigheidswinst overtuigend is, is het zoeken naar bomen geen universele vervanging voor het zoeken naar vectoren. De technologie kan het beste worden gezien als een gespecialiseerd hulpmiddel voor ‘diepgaand werk’, in plaats van als een allesomvattend hulpmiddel voor elke ophaaltaak.

Voor korte documenten, zoals e-mails of chatlogboeken, past de hele context vaak binnen het contextvenster van een moderne LLM, waardoor elk ophaalsysteem overbodig wordt. Omgekeerd blijven vectorinsluitingen voor taken die puur gebaseerd zijn op semantische ontdekking, 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 waar 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 door te 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 agentische retrieval

De opkomst van raamwerken zoals PageIndex signaleert een bredere trend in de AI-stack: de beweging richting ‘Agent RAGNaarmate modellen beter in staat worden 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 codeerruimte, waar agenten van houden Claude Code en Cursor stappen 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. “Maar hun historische rol als standaarddatabase voor LLM’s en AI zal in de loop van de tijd minder duidelijk worden.”

Nieuwsbron

LAAT EEN REACTIE ACHTER

Vul alstublieft uw commentaar in!
Vul hier uw naam in