PageIndex dziļa analīze: RAG bez vektoru izmantošanas, kas ļauj AI lasīt dokumentus kā cilvēkam ekspertam

PageIndex ir Vectify AI komandas atvērtā koda RAG ietvars bez vektoru izmantošanas un ar spriešanas iespējām (GitHub 14.8k+ zvaigznes). Tas pārveido garus dokumentus hierarhiskā koka indeksā, izmantojot LLM, lai veiktu spriešanas meklēšanu kokā, sasniedzot 98,7% precizitāti FinanceBench finanšu dokumentu jautājumu un atbilžu etalonā.

1. Fons: Pieci tradicionālā RAG sāpju punkti

RAG ir kļuvis par de facto standartu lielu modeļu lietojumiem. Galvenais risinājums pirmapstrādes posmā sadala dokumentu fiksēta garuma chunk'os, pārveido tos vektoros, izmantojot embedding modeli, un saglabā vektoru datubāzē; vaicājuma laikā lietotāja jautājumam tiek veikts tāds pats embedding, un pēc tam, izmantojot vektoru līdzības meklēšanu, tiek atgūti Top-K rezultāti, kas tiek apvienoti kā LLM ievades konteksts.

Šis process ir efektīvs īsiem tekstiem un vispārīgiem scenārijiem, bet profesionālu garu dokumentu (finanšu pārskati, likumi un noteikumi, tehniskās rokasgrāmatas utt.) scenārijos tas atklāj piecas fundamentālas problēmas:

1) Līdzība ≠ Saistība. Vektoru meklēšana pieņem, ka "semantiski līdzīgākais teksta bloks = visatbilstošākais atbildes avots", bet profesionālos dokumentos daudzi fragmenti dalās ar aptuvenu semantiku, bet būtiski atšķiras svarīgās detaļās.

2) Cieta sadalīšana blokos izjauc konteksta pilnīgumu. Dokumenta sadalīšana fiksētos 512 vai 1024 tokenu logos pārtrauc teikumus, rindkopas vai pat visu loģisko segmentu, izraisot svarīga konteksta zudumu.

3) Vaicājuma nolūks un zināšanu telpa ir neatbilstoši. Lietotāja vaicājums pauž "nolūku", nevis "saturu", un query embedding un document embedding atrodas dažādās semantiskajās telpās.

4) Nevar apstrādāt atsauces dokumentā. Profesionālos dokumentos ir bieži sastopamas atsauces, piemēram, "sīkāku informāciju skatiet G pielikumā", "skatiet 5.3. tabulu" utt. Starp šīm atsaucēm un atsauces saturu nav semantiskas līdzības, un vektoru meklēšana nevar tos saskaņot.

5) Neatkarīgi vaicājumi, nevar izmantot sarunu vēsturi. Katra meklēšana uzskata vaicājumu par neatkarīgu pieprasījumu, un nevar apvienot iepriekšējo sarunu kontekstu, lai veiktu pakāpenisku meklēšanu.

2. PageIndex vispārējā arhitektūra

PageIndex ir RAG ietvars bez vektoriem (Vectorless) un balstīts uz spriešanu (Reasoning-based). Tā galvenā ideja ir: tā vietā, lai modelis veiktu aptuvenu saskaņošanu vektoru telpā, labāk ļaut modelim spriest par dokumenta strukturētu attēlojumu – izlemt, "kur skatīties", nevis tikai "kas izskatās līdzīgs".

PageIndex simulē, kā cilvēks eksperts lasa garus dokumentus: vispirms pārlūko satura rādītāju, pamatojoties uz jautājumu, nosaka atbilstošās nodaļas un pakāpeniski iedziļinās, līdz atrod mērķa saturu. Šis process tiek panākts divos posmos:

• Koka struktūras indeksa izveide: PDF/Markdown dokumenta pārveidošana hierarhiskā JSON kokā, kas ir līdzīgs "LLM optimizētam satura rādītājam"
• Spriešanas koka meklēšana: LLM, pamatojoties uz jautājumu, veic spriešanas navigāciju kokā, lai atrastu atbilstošos mezglus, iegūtu saturu un ģenerētu atbildes

3. Galveno moduļu sadalīšana

3.1 PDF apstrādes līnija

PageIndex PDF apstrādes līniju organizē funkcija tree_parser(), un galvenais process ietver: satura rādītāja noteikšanu (trīs režīmu atzarošana), priekšvārda papildināšanu, plakanā saraksta pārveidošanu hierarhiskā kokā, lielo mezglu rekursīvu sadalīšanu, mezglu bagātināšanu, JSON koka struktūras izvadi.

Trīs apstrādes režīmi:

• process_toc_with_page_numbers (ir satura rādītājs + ir lappušu numuri): LLM izmanto, lai pārveidotu sākotnējo satura rādītāju strukturētā JSON, kartējot loģiskos lappušu numurus uz fiziskajiem lappušu numuriem
• process_no_toc (nav satura rādītāja): LLM tieši secina hierarhisko struktūru no teksta satura
• process_toc_no_page_numbers (ir satura rādītājs, bet nav lappušu numuru): vispirms tiek iegūta struktūra un pēc tam tiek secināti un papildināti fiziskie lappušu numuri

3.2 Koka struktūras datu modelis

Katrs koka mezgls ietver: title, node_id, start_index, end_index, summary, prefix_summary, text, nodes (apakšmezglu masīvs) utt.

3.3 Spriešanas meklēšanas mehānisms

Meklēšanas posms nepaļaujas uz vektoru aprēķiniem. LLM saņem lietotāja jautājumu un dokumenta koka struktūru, pamatojoties uz mezgla nosaukumu un kopsavilkumu, veic spriešanu, izvada savu "domāšanas procesu" un saistīto node_id sarakstu. Sistēma pēc tam, pamatojoties uz node_id, iegūst atbilstošā mezgla pilnu tekstu no node_map, apvieno to kā kontekstu un nodod LLM, lai ģenerētu galīgo atbildi.

4. Galvenie dizaina akcenti

• Arhitektūra bez vektoriem: nav nepieciešams embedding modelis un vektoru datubāze, samazinot infrastruktūras izmaksas un vienkāršojot izvietošanu
• Saglabā dokumenta dabisko struktūru: organizē saturu atbilstoši dokumenta raksturīgajām nodaļām/apakšnodaļām/apakšnodaļām, izvairoties no konteksta zuduma starp chunk'iem
• Meklēšanas izskaidrojamība: katra meklēšana atgriež pilnu spriešanas ķēdi, kas ir acīmredzama priekšrocība scenārijos ar augstām atbilstības prasībām

5. Vērtēšanas rezultāti

Mafin 2.5 ir finanšu dokumentu jautājumu un atbilžu sistēma, kas balstīta uz PageIndex. Tās veiktspēja FinanceBench (finanšu dokumentu QA etalons) sasniedz 98,7% precizitāti, kas ievērojami pārsniedz Perplexity (45%) un GPT-4o (31%).

6. Piemēroti scenāriji

Piemērots: Gariem dokumentiem ar skaidru hierarhisku struktūru (finanšu pārskati, noteikumi, mācību grāmatas, rokasgrāmatas), kuru apjoms ir no desmitiem līdz simtiem lappušu

Nav piemērots: Dokumentiem bez strukturēta satura, neskenētiem OCR dokumentiem, dokumentiem, kuru pamatā ir tabulas/diagrammas, scenārijiem, kuriem nepieciešama reāllaika reakcija milisekundēs

7. Kopsavilkums

PageIndex galvenais ieguldījums ir praktiskas RAG paradigmas bez vektoriem ierosināšana: koka indeksa izveide, izmantojot dokumenta dabisko struktūru, un LLM spriešanas izmantošana, lai aizstātu vektoru līdzības meklēšanu. Šis risinājums izcili darbojas profesionālu garu dokumentu scenārijos ar skaidru hierarhisku struktūru, un tā izskaidrojamība un auditējamība ir ievērojami labāka nekā tradicionālajiem risinājumiem.