Home Nieuws Dit boomzoekraamwerk behaalde 98,7% op documenten waarin het zoeken naar vectoren mislukte

Dit boomzoekraamwerk behaalde 98,7% op documenten waarin het zoeken naar vectoren mislukte

5
0
Dit boomzoekraamwerk behaalde 98,7% op documenten waarin het zoeken naar vectoren mislukte

Het nieuwe open source-framework heet Pagina-index lost een van de al lang bestaande problemen van retrieval-augmented generatie (RAG) op: omgaan met zeer lange documenten.

De klassieke RAG-workflow (het document bijsnijden, de insluitingen berekenen, deze opslaan in een vectordatabase en de beste overeenkomsten ophalen op basis van semantische gelijkenis) werkt goed voor basistaken zoals vragen en antwoorden op 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 wanneer bedrijven RAG proberen te verplaatsen naar workflows waar veel op het spel staat – het controleren van financiële rapporten, het analyseren van juridische contracten, het navigeren door farmaceutische protocollen – worden ze geconfronteerd met nauwkeurigheidsbarrières die slice-optimalisatie niet kan oplossen.

AlphaGo voor documenten

PageIndex overwint deze beperking door een concept te lenen van game-AI, en niet van zoekmachines: boomzoeken.

Wanneer mensen specifieke informatie moeten vinden in een compact leerboek of een lang jaarverslag, scannen ze niet elke paragraaf lineair. Ze kijken naar de inhoudsopgave om relevante hoofdstukken te identificeren, vervolgens secties en ten slotte specifieke pagina’s. PageIndex dwingt LLM’s om dit menselijke gedrag te imiteren.

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

Hoe PageIndex werkt (bron: PageIndex GitHub)

“In computerwetenschappelijke termen is een inhoudsopgave een boomachtige gestructureerde weergave van een document, en de navigatie ervan komt overeen met het zoeken in een boomstructuur,” zei Zhang. “PageIndex past hetzelfde kernidee toe – door boombladeren bladeren – om documenten op te halen, en kan worden gezien als een AlphaGo-achtig systeem voor het ophalen, niet voor gamen.”

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

Semantische gelijkenisbeperkingen

Er zit een fundamentele fout in zijn methode Traditionele RAG omgaan met complexe gegevens. Bij het ophalen van vectoren wordt ervan uitgegaan dat de tekst die semantisch het meest lijkt op de zoekopdracht van de gebruiker, ook de meest relevante tekst is. In de professionele wereld faalt deze veronderstelling vaak.

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), zal een standaard vectordatabase elke sectie uitkiezen waar het acroniem of soortgelijke termen voorkomen.

“Sommige secties vermelden EBITDA in soortgelijke bewoordingen, maar slechts één sectie legt de exacte berekening, aanpassing of reikwijdte van de rapportage uit die relevant is voor de vraag”, vertelde Zhang aan VentureBeat. “Een op gelijkenis gebaseerde retriever heeft moeite om onderscheid te maken tussen deze gevallen, omdat de semantische signalen bijna niet van elkaar te onderscheiden zijn.”

Dit is de kloof tussen intentie en inhoud. Gebruikers willen het woord “EBITDA” niet tegenkomen; ze willen de ‘logica’ erachter voor een bepaald kwartaal begrijpen.

Bovendien verwijdert traditionele insluiting de querycontext. Omdat insluitingsmodellen strikte beperkingen op de invoerlengte hebben, kijken ophaalsystemen doorgaans alleen naar de specifieke gestelde vraag, waarbij eerdere gesprekken worden genegeerd. Hierdoor wordt de ophaalstap uit het redeneringsproces van de gebruiker verwijderd. Het systeem koppelt documenten aan korte, gedecontextualiseerde zoekopdrachten, in plaats van aan een volledige geschiedenis van het probleem dat de gebruiker probeert op te lossen.

Multi-hop redeneerproblemen oplossen

De echte impact van deze structurele aanpak 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 de nieuwste benchmarktest, bekend als FinanceBench, heet het systeem dat op PageIndex is gebouwd “Verder 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 het jaarverslag van de Federal Reserve. Het hoofdgedeelte van het rapport beschrijft de ‘verandering’ in waarden, maar bevat geen totalen. De tekst bevat echter een voetnoot: “Zie bijlage G van dit rapport… voor meer gedetailleerde informatie.”

Vectorgebaseerde systemen falen hier meestal. De tekst in bijlage G komt helemaal niet overeen met de vraag van de gebruiker over uitgestelde activa; hoogstwaarschijnlijk is het gewoon een tabel met getallen. Omdat er geen semantische overeenkomst is, negeert de vectordatabase deze.

De op redenering gebaseerde retriever leest echter de aanwijzingen in de hoofdtekst, volgt de structurele links naar bijlage G, vindt de juiste tabel en retourneert nauwkeurige cijfers.

Latentie-trade-offs en infrastructuurverschuivingen

Voor enterprise-architecten is latentie een groot probleem in het op LLM gebaseerde zoekproces. Vector zoeken vindt plaats in milliseconden; als een LLM de inhoudsopgave “leest”, impliceert dit een veel langzamere gebruikerservaring.

Zhang legt echter uit dat de latentie die eindgebruikers ervaren, verwaarloosbaar kan zijn vanwege de manier waarop capture in het productieproces is geïntegreerd. In een klassieke RAG-opstelling is het ophalen een blokkerende stap: het systeem moet de database doorzoeken voordat het antwoorden kan genereren. Met PageIndex gebeurt het ophalen inline, tijdens het redeneerproces van het model.

“Het systeem kan onmiddellijk beginnen met streamen en het ophalen zodra het is gegenereerd”, aldus Zhang. “Dat betekent dat PageIndex geen extra ‘fetch gate’ 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 te elimineren, hoeven bedrijven niet langer speciale vectordatabases bij te houden. Boomgestructureerde indexen zijn licht genoeg om te worden ingezet in traditionele relationele databases zoals PostgreSQL.

Hiermee wordt een groeiend probleem in LLM-systemen met ophaalcomponenten aangepakt: de complexiteit van het synchroon houden van vectoropslag met bestaande documenten. PageIndex scheidt structuurindexering van tekstextractie. Als een contract wordt gewijzigd of een beleid wordt bijgewerkt, kan het systeem kleine wijzigingen verwerken door eenvoudigweg de betrokken subboom opnieuw te indexeren in plaats van het hele documentcorpus opnieuw te verwerken.

Beslismatrix voor bedrijven

Hoewel de grotere nauwkeurigheid aantrekkelijk is, is het zoeken naar boomstructuren geen universele vervanging voor het zoeken naar vectoren. Deze technologie kan het beste worden gezien als een hulpmiddel specifiek voor “diep werk” en niet als een hulpmiddel dat alle ophaaltaken dekt.

Voor korte documenten, zoals e-mails of chatlogboeken, past de hele context vaak in een modern LLM-contextvenster, dus elk ophaalsysteem is niet nodig. Voor taken die puur gebaseerd zijn op semantische ontdekking, zoals het aanbevelen van vergelijkbare producten of het vinden van inhoud met een vergelijkbare ‘sfeer’, blijft vectorinbedding daarentegen de beste keuze, omdat het doel nabijheid is en niet redeneren.

PageIndex zit precies in het midden: lange, zeer gestructureerde documenten met hoge foutenkosten. Dit omvat technische handleidingen, FDA-registraties en fusieovereenkomsten. In dit scenario is de vereiste controleerbaarheid. Bedrijfssystemen moeten niet alleen het antwoord kunnen uitleggen, maar ook het pad dat nodig is om het te vinden (bijvoorbeeld door te bevestigen dat het systeem paragraaf 4.1 heeft gecontroleerd, de verwijzingen naar bijlage B te volgen en de daar gevonden gegevens te synthetiseren).

Pagina-index versus RAG

Afbeelding tegoed: VentureBeat met Nano Banana Pro

De toekomst van het ophalen van agenten

De opkomst van raamwerken als PageIndex signaleert een bredere trend in de AI-stack: een beweging richting ‘RAG-agent.” 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 codeerruimte, waar agenten dol op zijn CodeClaude en De cursor schakelt van eenvoudig zoeken naar vectoren naar actieve verkenning van de codebase. Zhang gelooft dat het verzamelen van openbare documenten hetzelfde pad zal volgen.

“Vectordatabases hebben nog steeds geschikte gebruiksscenario’s”, zei Zhang. “Maar hun historische rol als standaarddatabase voor LLM’s en AI zal naarmate de tijd verstrijkt minder duidelijk worden.”

Nieuwsbron

LAAT EEN REACTIE ACHTER

Vul alstublieft uw commentaar in!
Vul hier uw naam in