PageIndex: Syväluotaus: Vektoriton päättelypohjainen RAG, joka saa tekoälyn lukemaan dokumentteja kuin ihminen

PageIndex on Vectify AI -tiimin avoimen lähdekoodin vektoriton, päättelypohjainen RAG-kehys (GitHub 14.8k+ tähteä). Se muuntaa pitkät dokumentit hierarkkiseksi puuindeksiksi ja käyttää LLM:ää päättelypohjaiseen hakuun puussa, saavuttaen 98,7 % tarkkuuden FinanceBench-rahoitusdokumenttien kysymys-vastausvertailussa.

1. Tausta: Perinteisen RAG:n viisi kipupistettä

RAG on vakiintunut suurten kielimallien sovellusten tosiasialliseksi standardiksi. Pääasiallinen ratkaisu jakaa dokumentit esikäsittelyvaiheessa kiinteän pituisiksi chunk-osiksi, muuntaa ne vektoreiksi embedding-mallin avulla ja tallentaa vektoritietokantaan. Kyselyvaiheessa käyttäjän kysymyksestä tehdään samalla tavalla embedding, ja sen jälkeen haetaan vektorien samankaltaisuuden perusteella Top-K -tulokset, jotka yhdistetään LLM:n syötekontekstiksi.

Tämä prosessi toimii hyvin lyhyissä teksteissä ja yleisissä tilanteissa, mutta ammattimaisissa pitkissä dokumenteissa (talousraportit, lait ja asetukset, tekniset käsikirjat jne.) se paljastaa viisi perustavanlaatuista ongelmaa:

1) Samankaltaisuus ≠ Relevanttius. Vektorihaku olettaa, että "semanttisesti samankaltaisin tekstilohko = relevanttein vastauslähde", mutta ammattimaisissa dokumenteissa monet kappaleet jakavat likimääräisen semantiikan, mutta eroavat merkittävästi keskeisissä yksityiskohdissa.

2) Kova pilkkominen rikkoo kontekstin eheyden. Dokumentin jakaminen kiinteillä 512 tai 1024 tokenin ikkunoilla katkaisee lauseita, kappaleita tai jopa kokonaisia loogisia osioita, mikä johtaa keskeisen kontekstin menetykseen.

3) Kyselyn tarkoitus ja tietotila ovat epäsynkroniassa. Käyttäjien kyselyt ilmaisevat "tarkoituksen" eivätkä "sisältöä", joten query embedding ja document embedding ovat eri semanttisissa tiloissa.

4) Dokumentin sisäisiä viittauksia ei voida käsitellä. Ammattimaisissa dokumenteissa on yleisiä viittauksia, kuten "katso liite G" tai "viittaa taulukkoon 5.3". Näiden viittausten ja viitatun sisällön välillä ei ole semanttista samankaltaisuutta, joten vektorihaku ei voi löytää niitä.

5) Itsenäiset kyselyt, keskusteluhistoriaa ei voida hyödyntää. Jokainen haku käsittelee kyselyn itsenäisenä pyyntönä, eikä se voi yhdistää edellisen keskustelun kontekstia asteittaiseen hakuun.

2. PageIndexin kokonaisarkkitehtuuri

PageIndex on vektoriton (Vectorless), päättelypohjainen (Reasoning-based) RAG-kehys. Sen ydinajatus on: Sen sijaan, että malli tekisi likimääräisen vastaavuuden vektoritilassa, on parempi antaa mallin päätellä dokumentin jäsennellystä esityksestä – päättää "mihin katsoa" sen sijaan, että vain "mikä näyttää samalta".

PageIndex simuloi ihmisasiantuntijan tapaa lukea pitkiä dokumentteja: ensin selaa sisällysluetteloa, päättelee kysymyksen perusteella asiaankuuluvat luvut ja syventyy kerroksittain, kunnes löytää kohdesisällön. Tämä prosessi toteutetaan kahdessa vaiheessa:

• Puurakenteisen indeksin luominen: Muuntaa PDF/Markdown-dokumentit hierarkkiseksi JSON-puuksi, joka on samankaltainen kuin "LLM:lle optimoitu sisällysluettelo"
• Päättelypohjainen puuhaku: LLM navigoi puussa päättelyn avulla kysymyksen perusteella, paikantaa asiaankuuluvat solmut, poimii sisällön ja luo vastauksen

3. Ydinmoduulien purkaminen

3.1 PDF-käsittelyputki

PageIndexin PDF-käsittelyputki on järjestetty tree_parser()-funktiolla, ja sen ydinprosessi sisältää: sisällysluettelon tunnistuksen (kolme tilahaaraa), johdannon täydentämisen, litteän luettelon muuntamisen hierarkkiseksi puuksi, suurten solmujen rekursiivisen pilkkomisen, solmujen rikastamisen ja JSON-puurakenteen tulostuksen.

Kolme käsittelytilaa:

• process_toc_with_page_numbers (sisällysluettelo + sivunumerot): Käyttää LLM:ää muuntamaan alkuperäisen sisällysluettelon jäsennellyksi JSON:iksi ja kartoittamaan loogiset sivunumerot fyysisiin sivunumeroihin
• process_no_toc (ei sisällysluetteloa): LLM päättelee hierarkkisen rakenteen suoraan tekstin sisällöstä
• process_toc_no_page_numbers (sisällysluettelo, mutta ei sivunumeroita): Poimii rakenteen ja päättelee sitten täydentävät fyysiset sivunumerot

3.2 Puurakenteen datamalli

Puurakenteen jokainen solmu sisältää seuraavat kentät: title, node_id, start_index, end_index, summary, prefix_summary, text, nodes (alisolmujen taulukko) jne.

3.3 Päättelypohjainen hakumekanismi

Hakuvaihe ei ole riippuvainen mistään vektorilaskennasta. LLM vastaanottaa käyttäjän kysymyksen ja dokumenttipuurakenteen, päättelee solmujen otsikoiden ja tiivistelmien perusteella ja tulostaa "ajatteluprosessinsa" ja asiaankuuluvien node_id-listan. Järjestelmä poimii sitten node_id:n perusteella vastaavien solmujen täydellisen tekstin node_map:ista, yhdistää sen kontekstiksi ja antaa sen LLM:lle lopullisen vastauksen luomiseksi.

4. Keskeiset suunnittelun kohokohdat

• Vektoriton arkkitehtuuri: Ei vaadi embedding-mallia ja vektoritietokantaa, mikä alentaa infrastruktuurikustannuksia ja yksinkertaistaa käyttöönottoa
• Säilyttää dokumentin luonnollisen rakenteen: Järjestää sisällön dokumentin luontaisten lukujen/osioiden/alalukujen mukaan, mikä välttää kontekstin menetyksen chunk-osien välillä
• Haun selitettävyys: Jokainen haku palauttaa täydellisen päättelyketjun, mikä on merkittävä etu tilanteissa, joissa on korkeat vaatimustenmukaisuusvaatimukset

5. Arviointitulokset

Mafin 2.5 on PageIndexiin perustuva rahoitusdokumenttien kysymys-vastausjärjestelmä. Sen suorituskyky FinanceBenchissä (rahoitusdokumenttien QA-vertailutesti) saavutti 98,7 % tarkkuuden, mikä on huomattavasti enemmän kuin Perplexity (45 %) ja GPT-4o (31 %).

6. Soveltuvat tilanteet

Sopii: Pitkille dokumenteille, joissa on selkeä hierarkkinen rakenne (talousraportit, lait, oppikirjat, käsikirjat), joiden pituus on kymmeniä tai satoja sivuja

Ei sovi: Dokumenteille, joissa ei ole jäsenneltyä sisältöä, OCR:llä käsittelemättömille skannauksille, dokumenteille, jotka koostuvat pääasiassa taulukoista/kaavioista, tilanteisiin, jotka vaativat millisekunnin tarkkuudella reaaliaikaisen vasteen

7. Yhteenveto

PageIndexin keskeinen panos on käytännöllisen vektorittoman RAG-paradigman ehdottaminen: puuindeksin rakentaminen dokumentin luonnollisen rakenteen avulla ja LLM-päättelyn käyttö vektorien samankaltaisuushakujen sijaan. Tämä ratkaisu toimii erinomaisesti ammattimaisissa pitkissä dokumenteissa, joissa on selkeä hierarkkinen rakenne, ja sen selitettävyys ja auditoitavuus ovat myös huomattavasti parempia kuin perinteisillä ratkaisuilla.