ज़्यादातर RAG पाइपलाइन एक जैसे दिखते हैं: डॉक्यूमेंट को chunk करो, हर chunk का एम्बेडिंग बनाओ, वेक्टर स्टोर करो, फिर क्वेरी टाइम पर सवाल को एम्बेड करो और top-k सबसे cosine-similar chunks निकालो। PageIndex कुछ अलग कर रहा है। वेक्टर के बजाय, यह एक हायरार्किकल ट्री इंडेक्स बनाता है जो डॉक्यूमेंट की टेबल ऑफ कंटेंट्स को मिरर करता है — हर नोड में एक टाइटल, एक सारांश, और पूरे सेक्शन टेक्स्ट का पॉइंटर होता है। रिट्रीवल कोई सिमिलैरिटी सर्च नहीं है। यह LLM है जो ट्री को पढ़ता है और रीज़न करता है कि किन नोड्स में उतरना है, फिर पूरा टेक्स्ट सिर्फ़ मैच हुए नोड्स से लाता है।
आर्किटेक्चरल दांव यह है कि "जैसे ही क्वेरीज़ कॉम्प्लेक्स होती हैं, सिमिलैरिटी रिलेवेंस का कमज़ोर प्रॉक्सी है"। अगर तुम वित्तीय रिपोर्ट से पूछो "लेखकों ने रिकरेंस के बजाय self-attention क्यों चुना, और कॉम्प्लेक्सिटी ट्रेड-ऑफ क्या हैं", वेक्टर सर्च को ऐसे chunks खोजने पड़ते हैं जिनका एम्बेडिंग सवाल जैसा दिखे — और यह क्रॉस-सेक्शन रीज़निंग को पूरी तरह miss कर सकता है। PageIndex का उदाहरण मूल Transformer पेपर पर इस पर चलता है: LLM ट्री देखता है, पहचानता है कि मोटिवेशन सेक्शन और कॉम्प्लेक्सिटी एनालिसिस सेक्शन दोनों रिलेवेंट हैं, दोनों को लाता है, और जवाब को सही जगहों पर ग्राउंड करता है। ऐसी मल्टी-सेक्शन सिंथेसिस वो जगह है जहां वेक्टर RAG चुपचाप फेल होता है और यूज़र को सिर्फ़ कॉन्फिडेंट गलत जवाब मिलता है।
ईमानदार ट्रेड-ऑफ है कॉस्ट और स्ट्रक्चर। हर रिट्रीवल राउंड में LLM को ट्री सारांश पढ़ना और किन नोड्स को खोलना है उस पर रीज़न करना पड़ता है — यह जनरेशन कॉल के ऊपर एक LLM कॉल प्रति क्वेरी है। वेक्टर सर्च इंडेक्स बन जाने के बाद प्रति क्वेरी मूल रूप से मुफ़्त है; PageIndex रिट्रीवल को ही मॉडल इन्वोकेशन में बदल देता है। अगर तुम्हारे डॉक्यूमेंट वेब से स्क्रैप किए फ़्लैट PDF हैं बिना साफ़ पदानुक्रम के, ट्री मदद नहीं करेगा। अगर तुम्हारी क्वेरीज़ सरल लुकअप हैं ("वारंटी पीरियड क्या है"), रीज़निंग ओवरहेड बर्बाद होता है। PageIndex का आर्टिकल FinanceBench पर वेक्टर baselines के खिलाफ बेंचमार्क नंबर नहीं दिखाता, लेटेंसी या इंडेक्स डॉक्यूमेंट अपडेट कैसे handle करता है उस पर बात नहीं करता, और प्रति क्वेरी कॉस्ट तुलना नहीं करता। ये वो सवाल हैं जो किसी भी गंभीर मूल्यांकन को चाहिए।
लंबे संरचित दस्तावेज़ों पर काम कर रहे डेवलपर्स के लिए — वित्तीय फाइलिंग, कानूनी अनुबंध, रिसर्च पेपर्स, तकनीकी मैनुअल — PageIndex तुम्हारे मौजूदा वेक्टर setup के खिलाफ असली टेस्ट के लायक है। अकेली व्याख्यात्मकता ही मूल्यवान है: जब रिट्रीवल फेल होता है, तुम वो रीज़निंग चेन देख सकते हो जिसने गलत नोड्स चुने, अपारदर्शी cosine स्कोर देखने के बजाय। बाकी सब जो chatbot-over-help-docs कर रहे हैं, उनके लिए मौजूदा एम्बेडिंग stack शायद अभी भी सही जवाब है। यहां वास्तव में दिलचस्प सीमा "वेक्टर बनाम रीज़निंग" को धार्मिक युद्ध की तरह लड़ना नहीं है, बल्कि यह जानना है कि कौन-सा दस्तावेज़ आकार और कौन-सा क्वेरी पैटर्न कौन-सी आर्किटेक्चर को न्यायसंगत ठहराता है। PageIndex एक आकार है; वेक्टर दूसरा।