PageIndex Djupdykning: Vektorlös resonemangsbaserad RAG, låt AI läsa dokument som en mänsklig expert

PageIndex är ett vektorlöst, resonemangsbaserat RAG-ramverk med öppen källkod från Vectify AI-teamet (GitHub 14.8k+ stjärnor). Det omvandlar långa dokument till ett hierarkiskt trädindex och använder LLM för resonemangsbaserad sökning i trädet, vilket uppnår 98,7 % noggrannhet på FinanceBench, ett benchmark för frågesvar på finansiella dokument.

1. Bakgrund: De fem smärtpunkterna med traditionell RAG

RAG har blivit de facto-standard för applikationer med stora modeller. Den vanliga lösningen är att i förbehandlingsfasen dela upp dokument i bitar av fast längd (chunks), omvandla dem till vektorer genom en embedding-modell och lagra dem i en vektor-databas; vid sökning görs samma embedding på användarens fråga, och sedan hämtas Top-K-resultaten genom vektorsimilitudssökning och sammanfogas till LLM:s inmatningskontext.

Detta arbetsflöde är effektivt för korta texter och generella scenarier, men i scenarier med professionella långa dokument (finansiella rapporter, lagar och förordningar, tekniska manualer etc.) avslöjas fem grundläggande problem:

1) Likhet ≠ Relevans. Vektorsökning antar att "den semantiskt mest liknande textbiten = den mest relevanta svarskälla", men i professionella dokument delar många stycken liknande semantik men skiljer sig åt i viktiga detaljer.

2) Hård uppdelning förstör kontextuell integritet. Att dela upp dokument i fasta fönster på 512 eller 1024 tokens kommer att trunkera meningar, stycken eller till och med hela logiska avsnitt, vilket leder till att viktig kontext går förlorad.

3) Felinriktning mellan frågeintention och kunskapsutrymme. Användarens fråga uttrycker en "intention" snarare än "innehåll", och query embedding och document embedding befinner sig i olika semantiska utrymmen.

4) Kan inte hantera hänvisningar i dokumentet. Professionella dokument innehåller ofta hänvisningar som "se bilaga G" eller "se tabell 5.3", och det finns ingen semantisk likhet mellan dessa hänvisningar och det hänvisade innehållet, så vektorsökning kan inte matcha dem.

5) Oberoende frågor, kan inte utnyttja konversationshistorik. Varje sökning behandlar frågan som en oberoende begäran och kan inte kombinera den tidigare konversationskontexten för att göra inkrementell sökning.

2. PageIndex övergripande arkitektur

PageIndex är ett vektorlöst (Vectorless), resonemangsbaserat (Reasoning-based) RAG-ramverk. Dess kärnidé är: I stället för att låta modellen göra ungefärliga matchningar i vektorutrymmet, är det bättre att låta modellen resonera om dokumentets strukturerade representation – att bestämma "vart man ska titta", snarare än bara "vad som ser liknande ut".

PageIndex simulerar hur mänskliga experter läser långa dokument: först bläddra i innehållsförteckningen, bedöma relevanta kapitel baserat på frågan och gå gradvis djupare tills målinnehållet hittas. Denna process uppnås i två steg:

• Bygg ett trädstrukturindex: Konvertera PDF/Markdown-dokument till ett hierarkiskt JSON-träd, liknande en "innehållsförteckning optimerad för LLM"
• Resonemangsbaserad trädsökning: LLM navigerar i trädet baserat på frågan, lokaliserar relevanta noder, extraherar innehåll och genererar svar

3. Nedbrytning av kärnmoduler

3.1 PDF-bearbetningspipeline

PageIndex PDF-bearbetningspipeline arrangeras av funktionen tree_parser(), och kärnprocessen inkluderar: katalogdetektering (tre lägesgrenar), komplettering av förord, konvertering av platt lista till hierarkiskt träd, rekursiv underindelning av stora noder, berikning av noder, JSON-trädstrukturutdata.

Tre bearbetningslägen:

• process_toc_with_page_numbers (har innehållsförteckning + har sidnummer): Använd LLM för att konvertera den ursprungliga innehållsförteckningen till strukturerad JSON, mappa logiska sidnummer till fysiska sidnummer
• process_no_toc (ingen innehållsförteckning): LLM härleder den hierarkiska strukturen direkt från brödtexten
• process_toc_no_page_numbers (har innehållsförteckning men inga sidnummer): Extrahera strukturen och härled sedan och komplettera fysiska sidnummer

3.2 Datamodell för trädstruktur

Varje nod i trädet innehåller fält som: title, node_id, start_index, end_index, summary, prefix_summary, text, nodes (array av undernoder) etc.

3.3 Resonemangsbaserad sökmekanism

Sökningsfasen förlitar sig inte på några vektorberäkningar. LLM tar emot användarfrågan och dokumentträdstrukturen, resonerar baserat på nodtitlar och sammanfattningar och matar ut sin "tankeprocess" och en lista över relevanta node_id:n. Systemet extraherar sedan den fullständiga texten för motsvarande noder från node_map baserat på node_id, sammanfogar dem till kontexten och ger dem till LLM för att generera det slutliga svaret.

4. Viktiga designhöjdpunkter

• Vektorlös arkitektur: Inget behov av embedding-modeller och vektordatabaser, vilket minskar infrastrukturkostnaderna och förenklar driftsättningen
• Bevarar dokumentets naturliga struktur: Organiserar innehåll efter dokumentets inneboende kapitel/avsnitt/underavsnitt, vilket undviker kontextförlust över chunks
• Sökbarhetens förklarbarhet: Varje sökning returnerar en komplett resonemangskedja, vilket har tydliga fördelar i scenarier med höga krav på efterlevnad

5. Utvärderingsresultat

Mafin 2.5 är ett finansiellt dokumentfrågesvarssystem baserat på PageIndex. Dess prestanda på FinanceBench (finansiellt dokument QA-benchmarktest) når 98,7 % noggrannhet, vilket är långt över Perplexity (45 %) och GPT-4o (31 %).

6. Lämpliga scenarier

Lämplig för: Långa dokument med tydlig hierarkisk struktur (finansiella rapporter, lagar och förordningar, läroböcker, manualer), med en längd på tiotals till hundratals sidor

Inte lämplig för: Dokument utan strukturerat innehåll, skanningar utan OCR, dokument som huvudsakligen består av tabeller/diagram, scenarier som kräver realtidsrespons på millisekunder

7. Sammanfattning

PageIndex kärnbidrag ligger i att föreslå ett praktiskt vektorlöst RAG-paradigm: använd dokumentets naturliga struktur för att bygga ett trädindex, använd LLM-resonemang för att ersätta vektorsimilitudssökning. Denna lösning presterar utmärkt i professionella långa dokumentscenarier med tydliga hierarkiska strukturer, och förklarbarheten och revisionsbarheten är också betydligt bättre än traditionella lösningar.