Malalimang Pagsusuri sa PageIndex: Walang-Vector na Pangangatwiran na RAG, Ginagawang Parang Eksperto ang AI sa Pagbasa ng mga Dokumento

Ang PageIndex ay isang open-source na walang-vector, pangangatwiran na RAG framework mula sa Vectify AI team (GitHub 14.8k+ stars). Ginagawa nitong hierarchical tree index ang mahahabang dokumento, gumagamit ng LLM para sa pangangatwiran na paghahanap sa puno, at umaabot sa 98.7% na katumpakan sa FinanceBench financial document question answering benchmark.

1. Background: Limang Problema ng Tradisyunal na RAG

Ang RAG ay naging de facto standard para sa malalaking modelo ng aplikasyon. Hinihiwa ng mga pangunahing solusyon ang dokumento sa mga chunk na may nakatakdang haba sa yugto ng pre-processing, ginagamit ang embedding model para gawing vector, at iniimbak sa vector database; kapag nagtatanong, ginagawa rin ang parehong embedding sa tanong ng user, at pagkatapos ay ginagamit ang vector similarity search para bawiin ang Top-K na mga resulta, at pinagsasama-sama bilang input context ng LLM.

Ang prosesong ito ay epektibo sa maiikling teksto at pangkalahatang mga sitwasyon, ngunit sa mga sitwasyon ng propesyonal na mahahabang dokumento (mga ulat sa pananalapi, mga batas at regulasyon, mga teknikal na manwal, atbp.), nagpapakita ito ng limang pangunahing problema:

1) Pagkakatulad ≠ Kaugnayan. Ipinapalagay ng vector retrieval na ang "pinakakatulad na semantic na bloke ng teksto = pinakakaugnay na pinagmulan ng sagot", ngunit sa mga propesyonal na dokumento, maraming mga talata ang nagbabahagi ng halos parehong semantika ngunit may malaking pagkakaiba sa mga kritikal na detalye.

2) Sinisira ng hard chunking ang integridad ng konteksto. Ang paghiwa-hiwa ng mga dokumento sa mga nakatakdang window ng 512 o 1024 token ay puputulin ang mga pangungusap, talata, at maging ang buong lohikal na seksyon, na magreresulta sa pagkawala ng mahalagang konteksto.

3) Hindi pagkakatugma ng layunin ng pagtatanong at espasyo ng kaalaman. Ang tanong ng user ay nagpapahayag ng "layunin" sa halip na "nilalaman", at ang query embedding at document embedding ay nasa iba't ibang semantic space.

4) Hindi makayanan ang mga sanggunian sa loob ng dokumento. Karaniwan sa mga propesyonal na dokumento ang mga sanggunian tulad ng "tingnan ang Apendise G" at "sumangguni sa Talahanayan 5.3", atbp. Walang semantic na pagkakatulad sa pagitan ng mga sangguniang ito at ng nilalamang tinutukoy, at hindi ito maitutugma ng vector retrieval.

5) Independent na pagtatanong, hindi magamit ang kasaysayan ng pag-uusap. Itinuturing ng bawat paghahanap ang query bilang isang independiyenteng kahilingan, at hindi nito magagamit ang konteksto ng nakaraang pag-uusap para sa progresibong paghahanap.

2. Pangkalahatang Arkitektura ng PageIndex

Ang PageIndex ay isang walang-vector (Vectorless), batay sa pangangatwiran (Reasoning-based) na RAG framework. Ang pangunahing ideya nito ay: sa halip na hayaan ang modelo na gumawa ng tinatayang pagtutugma sa vector space, mas mabuting hayaan ang modelo na mangatwiran sa structured na representasyon ng dokumento—magpasya "kung saan titingin", sa halip na "kung ano ang mukhang magkatulad".

Ginagaya ng PageIndex ang paraan ng pagbabasa ng mahahabang dokumento ng mga eksperto: unang tinitingnan ang talaan ng mga nilalaman, tinutukoy ang mga kaugnay na kabanata batay sa tanong, at sumusuri nang paunti-unti hanggang sa mahanap ang target na nilalaman. Ang prosesong ito ay nakakamit sa pamamagitan ng dalawang hakbang:

• Pagbuo ng istraktura ng puno na index: Ginagawang hierarchical JSON tree ang PDF/Markdown na mga dokumento, katulad ng "talaan ng mga nilalaman na na-optimize para sa LLM"
• Pangangatwiran na paghahanap sa puno: Ang LLM ay nangangatwiran at nagna-navigate sa puno batay sa tanong, tinutukoy ang mga kaugnay na node, kinukuha ang nilalaman at bumubuo ng mga sagot

3. Paghiwa-hiwalay ng mga Pangunahing Module

3.1 PDF Processing Pipeline

Ang PDF processing pipeline ng PageIndex ay isinaayos ng function na tree_parser(), at ang pangunahing proseso ay kinabibilangan ng: pagtukoy ng talaan ng mga nilalaman (tatlong mode branch), pagdaragdag ng paunang salita, paggawa ng flat list sa hierarchical tree, recursive na paghahati ng malalaking node, pagpapayaman ng mga node, at pag-output ng JSON tree structure.

Tatlong mode ng pagproseso:

• process_toc_with_page_numbers (may talaan ng mga nilalaman + may mga numero ng pahina): Ginagamit ng LLM ang orihinal na talaan ng mga nilalaman para gawing structured JSON, at imapa ang mga lohikal na numero ng pahina sa mga pisikal na numero ng pahina
• process_no_toc (walang talaan ng mga nilalaman): Direktang kinukuha ng LLM ang hierarchical structure mula sa nilalaman ng katawan
• process_toc_no_page_numbers (may talaan ng mga nilalaman ngunit walang mga numero ng pahina): Kinukuha ang istraktura at pagkatapos ay kinukuha at dinadagdag ang mga pisikal na numero ng pahina

3.2 Data Model ng Istraktura ng Puno

Kasama sa bawat node sa puno ang: title, node_id, start_index, end_index, summary, prefix_summary, text, nodes (array ng mga child node), at iba pang mga field.

3.3 Mekanismo ng Pangangatwiran na Paghahanap

Ang yugto ng paghahanap ay hindi umaasa sa anumang pagkalkula ng vector. Tumatanggap ang LLM ng tanong ng user at istraktura ng puno ng dokumento, nangangatwiran batay sa pamagat at buod ng node, at naglalabas ng "proseso ng pag-iisip" at listahan ng mga kaugnay na node_id. Pagkatapos ay kinukuha ng system ang kumpletong teksto ng kaukulang node mula sa node_map batay sa node_id, pinagsasama-sama ito bilang konteksto at ibinibigay sa LLM upang bumuo ng panghuling sagot.

4. Mga Pangunahing Highlight ng Disenyo

• Walang-Vector na Arkitektura: Hindi na kailangan ng embedding model at vector database, binabawasan ang mga gastos sa imprastraktura at pinapasimple ang pag-deploy
• Pinapanatili ang Likas na Istraktura ng Dokumento: Inaayos ang nilalaman ayon sa likas na mga kabanata/seksyon/subseksyon ng dokumento, iniiwasan ang pagkawala ng konteksto sa mga chunk
• Pagpapaliwanag ng Paghahanap: Nagbabalik ang bawat paghahanap ng kumpletong chain ng pangangatwiran, na may malinaw na kalamangan sa mga sitwasyon na may mataas na kinakailangan sa pagsunod

5. Mga Resulta ng Pagsusuri

Ang Mafin 2.5 ay isang financial document question answering system na batay sa PageIndex. Ang pagganap nito sa FinanceBench (financial document QA benchmark test) ay umabot sa 98.7% na katumpakan, na higit na nakahihigit sa Perplexity (45%) at GPT-4o (31%).

6. Mga Naaangkop na Sitwasyon

Angkop para sa: Mahahabang dokumento na may malinaw na hierarchical structure (mga ulat sa pananalapi, mga regulasyon, mga aklat-aralin, mga manwal), na may haba na dose-dosenang hanggang daan-daang pahina

Hindi angkop para sa: Mga dokumento na walang structured na nilalaman, mga na-scan na dokumento na hindi na-OCR, mga dokumento na pangunahing binubuo ng mga talahanayan/tsart, mga sitwasyon na nangangailangan ng real-time na pagtugon sa millisecond

7. Buod

Ang pangunahing kontribusyon ng PageIndex ay ang pagpapanukala ng isang praktikal na walang-vector na RAG paradigm: gumamit ng likas na istraktura ng dokumento upang bumuo ng index ng puno, at gumamit ng pangangatwiran ng LLM upang palitan ang vector similarity search. Ang solusyong ito ay mahusay sa mga propesyonal na mahahabang dokumento na may malinaw na hierarchical structure, at ang pagpapaliwanag at pagiging audit nito ay makabuluhang mas mahusay kaysa sa mga tradisyunal na solusyon.