PageIndex من VectifyAI يوفر بحثاً بدون embeddings للمستندات الطويلة

PageIndex هو أحد أكثر المنافسين الجدد بروزاً للعب دور 'RAG بدون قاعدة بيانات متجهة'. بدلاً من الطريقة المألوفة مع embeddings و chunks، ينشئ النظام فهرساً متسلسلاً للمستند مع وصفات موجزة للأقسام، ثم يطلب من نموذج LLM أن يختار منطقياً العقد الذات الصلة والصفحات المرتبطة بها. يبدو النهج جديداً وللملفات PDF الطويلة والمنظمة جيداً يمكن أن يعمل بطريقة أقرب إلى كيفية قراءة الإنسان للمستند.

آلية PageIndex بسيطة نسبياً. يتم أولاً تقسيم المستند حسب الصفحات، وبعدها ينقح النموذج والكود الداعم فهرساً موسعاً - شجرة من الأقسام مع العناوين ونطاقات الصفحات والملخصات لكل عقدة. عندما يصل سؤال، لا يرسل الإشارة الفورية المستند بأكمله أو مجموعة من chunks النص العشوائية، بل هذه الهيكلة نفسها. يختار نموذج LLM الأفرع ذات الصلة من الشجرة، وبعدها يتم استبدال الصفحات المرفقة بها فقط في الاستعلام النهائي.

نتيجة لذلك، يعمل النظام بدون embeddings، بدون تخزين متجه، وبدون chunking اصطناعي، الذي غالباً ما يكسر المعنى على حدود الأجزاء. لهذا السبب يوجد الكثير من الاهتمام حول PageIndex. في التقارير المالية الطويلة والوثائق القانونية والكتيبات التقنية والمواد التعليمية، يبدو مثل هذا النهج طبيعياً: يبدأ البشر عادةً أيضاً بجدول محتويات بدلاً من فحص النص على دفعات.

في مستودع المشروع، يوضع مطورو VectifyAI النظام مباشرة كاسترجاع قائم على التفكير ويؤكدون أنه على FinanceBench حقق دقة 98.7٪. بالنسبة للفرق التي تعمل مع مستند واحد كبير أو مجموعة صغيرة من ملفات PDF المعقدة، يبدو هذا كبديل قوي لخط أنابيب RAG التقليدي، خاصة إذا كنت تريد بحثاً أكثر قابلية للتفسير مع مراجع واضحة للأقسام والصفحات.

لكن السؤال الرئيسي ليس ما إذا كان يمكن استبدال البحث المتجه بـ PageIndex، بل حيث يصل هذا النهج إلى حدوده. الانتقاد هنا عملي تماماً. أولاً، يجب تخزين جدول المحتويات أيضاً في مكان ما، خاصة إذا كان هناك أكثر من مستند واحد، لذا فإن الحديث عن 'بدون فهرس تماماً' مضلل قليلاً.

ثانياً، بالنسبة للمجموعات الكبيرة، لا توجد استراتيجية مقنعة حتى الآن لاختيار الوثائق: البيانات الوصفية والبحث بالكلمات الرئيسية و TF-IDF و BM25 لا تختفي وغالباً ما تبقى كمرشح أولي رخيص. ثالثاً، استرجاع التفكير يكون تقريباً حتماً أكثر تكلفة في الرموز وأبطأ في وقت الاستجابة. إذا كان نظام RAG المتجه الجيد يوفر بالفعل حوالي 90٪ من الجودة، فيمكن أن تكلف نقاط النسبة المئوية الإضافية عدة مرات أكثر - وليس لكل منتج هذا تبادل معقول.

تُظهر الممارسة أيضاً قيوداً. في التحليلات، يُلاحظ أن PageIndex كان له أداء سيئة مع النص الأدبي بدون هيكل صريح: إذا لم يكن لدى المستند أقسام أو عناوين، فلا يوجد ببساطة شيء لبناء 'جدول محتويات ذكي' منه. كانت النتائج أفضل مع النص الأكاديمي لأنه يحتوي على هرمية مناسبة من الأقسام. يمكنك تشغيل النظام محلياً من خلال المستودع المفتوح: قم بتثبيت التبعيات، وقم بتعيين مفتاح API لـ LLM متوافق عبر LiteLLM، وقم بتشغيل ملف PDF أو markdown من خلال run_pageindex.py.

لكن هناك نقاط دقيقة هنا أيضاً: يحذر المؤلف بشكل منفصل من إصدار LiteLLM، لا ينصح بتثبيت حزمة pageindex في السحابة من pip للعمل المحلي، ويصف كيف أنه على نماذج محلية ضعيفة تتدهور جودة الشجرة بشكل ملحوظ، والعملية نفسها يمكن أن تستغرق عشرات الدقائق حتى على مستند صغير نسبياً.

ماذا يعني هذا في الممارسة؟ لا يبدو PageIndex وكأنه قاتل البحث المتجه، لكنه يبدو بمثابة طبقة جديدة مفيدة في معمارية RAG. الطريقة الأكثر منطقية لرؤيته هي ليس كبديل مباشر، بل كأداة متخصصة للمستندات الطويلة والمنظمة حيث تكون القابلية للشرح ودقة التنقل ومعالجة الصفحة تلو الأخرى مهمة. الحالة الأكثر واقعية هي هجينة: أولاً بحث رخيص حسب البيانات الوصفية أو المتجهات، ثم PageIndex لاختيار دقيق للأقسام. هذا التسوية يعكس الواقع بشكل أفضل: لا توجد بعد بديل عام لـ RAG المتجه، لكن النهج الموجهة نحو المستندات مثل PageIndex لديها بالفعل مكانها الخاص المحدد بوضوح.