الـ RAG متعدد الوسائط للجداول والرسوم البيانية والمسح الضوئي: ثلاث معماريات ومتى يتم التوجيه حسب الصفحة
استخراج النص فقط يحول رسماً بيانياً في الصفحة 47 إلى تعليق توضيحي قبل أن يراه النموذج. تقارن هذه المقالة بين استرجاع صورة الصفحة، والتحليل المدرك للتخطيط، ووضع تعليقات توضيحية للأشكال من حيث التكلفة ونمط الفشل، وتوضح متى يجب توجيه كل صفحة إلى خط معالجة مختلف.
السؤال يدور حول هامش الربع الثالث حسب المنطقة. الرقم موجود في رسم بياني شريطي مكدس في الصفحة 47 من حزمة مجلس الإدارة. قام خط المعالجة (pipeline) الخاص بالاستيعاب بتحويل هذا الرسم البياني إلى سلسلة نصية واحدة: "الشكل 4: إيرادات الربع الثالث". النموذج لم يرَ الأشرطة أبداً. ومع ذلك، أجاب على السؤال، وكانت الإجابة مجرد تخمين.
هذه ليست مشكلة موجّه (prompt). إنها مشكلة معمارية. خط المعالجة الذي يعتمد على النص فقط يقرأ الطبقة النصية للصفحة ويتجاهل التخطيط الذي أعطى النص معناه. إذا كانت مستنداتك تحتوي على جداول، أو رسوم بيانية، أو نماذج، أو مخططات، أو صفحات ممسوحة ضوئياً، فإن هذا الفقدان جزء لا يتجزأ من النظام.
تتعامل ثلاث معماريات استيعاب مع هذه المشكلة. لكل منها تكلفة مختلفة وطريقة مختلفة في الفشل. اختيار المعمارية المناسبة لكل صفحة أهم من اختيار أفضل نموذج.
لماذا يستمر استخراج النص فقط في الفشل
يقوم خط المعالجة القياسي بأربعة أشياء. يكتشف التخطيط، ويستخرج الطبقة النصية أو يشغل التعرف الضوئي على الحروف (OCR)، ويقسم النص إلى مقاطع (chunks)، ويقوم بعمل تضمين (embedding) لكل مقطع. حالات الفشل هنا متوقعة:
- ▸الجداول متعددة الأعمدة تُقرأ عبر الأعمدة، فتختلط الصفوف. في بروتوكول سريري، قد يُقرأ جرعة أطفال كجزء من عمود البالغين.
- ▸الخلايا المدمجة والترويسات المتداخلة تنهار إلى سلاسل نصية غامضة.
- ▸الرسوم البيانية والمخططات يتم تخطيها، أو استبدالها بالتعليق التوضيحي الخاص بها.
- ▸الصفحات الممسوحة ضوئياً ترث أخطاء التعرف الضوئي على الحروف، والتي تتسلسل لتنتج مقاطع سيئة.
- ▸النماذج تفقد الارتباط بين التسمية وقيمتها.
تستجيب الفرق بإضافة محللات (parsers). مستخرج جداول هنا، ونموذج تعليق على الأشكال هناك، وتعبير نمطي (regex) لإصلاح قالب أحد الموردين. كل قالب جديد يعني قاعدة جديدة. وكل قاعدة هي نقطة جديدة يمكن لخط المعالجة أن يرجع فيها إجابة خاطئة دون إثارة أي خطأ.
السؤال المفيد ليس "أي محلل هو الأفضل". بل هو "هل تحتاج هذه الصفحة إلى استخراج نصها، أم يجب استرجاعها كصفحة كاملة؟"
مقارنة بين ثلاث معماريات
لا يوجد RAG متعدد الوسائط واحد يناسب الجميع. هناك ثلاثة أنماط، وعادة ما تجمع أنظمة الإنتاج بينها.
1. استرجاع صورة الصفحة (بأسلوب ColPali)
قم بتصيير كل صفحة كصورة. مررها عبر نموذج تضمين رؤية ينتج العديد من المتجهات الصغيرة لكل صفحة، متجه واحد لكل رقعة (patch) من الصورة. الرقعة هي مربع صغير من الصفحة، لذا فإن أشرطة الرسم البياني وشبكة الجدول يحصل كل منها على متجهات خاصة به. قم بتخزينها جميعاً. في وقت الاستعلام، قم بتضمين السؤال ومقارنته بكل متجه رقعة في كل صفحة. يُسمى هذا بالتفاعل المتأخر (late interaction): يحدث التطابق بين الاستعلام وكل رقعة، وليس بين الاستعلام ومتجه ملخص واحد. أفضل صور الصفحات مطابقة تذهب بعد ذلك إلى نموذج قادر على الرؤية، والذي يجيب من الصورة نفسها.
قدمت ورقة ColPali (arXiv 2407.01449، يوليو 2024) هذا النهج وأظهرت أنه يمكن تخطي خطوة استخراج النص بالكامل.
- ▸نقاط القوة: لا توجد خطوة استخراج قابلة للكسر. الرسوم البيانية، المخططات، النماذج المكتوبة بخط اليد، النصوص العربية، والمسح الضوئي الفوضوي، كلها تُسترجع بناءً على مظهر الصفحة.
- ▸التكلفة: التخزين. فهرس النص أحادي المتجه يخزن متجهاً واحداً لكل مقطع. بينما فهرس صورة الصفحة يخزن متجهاً واحداً لكل رقعة. كمثال توضيحي، الصفحة المقسمة إلى 1,000 رقعة بـ 128 بُعداً تخزن 128,000 رقم، مقابل 1,024 لمتجه مقطع واحد بـ 1,024 بُعداً. هذا يعني مساحة تخزين أكبر بحوالي 125 مرة لكل صفحة قبل الضغط. تجميع الرقع المتجاورة (pooling) والتكميم الثنائي (binary quantization) يقللان من هذا الحجم. تحدد وثائق المتجهات المتعددة في Qdrant سقف المتجهات الفرعية مضروبة في الأبعاد بـ 1,048,576 لكل نقطة وتوصي بتجميع متجهات الرموز قبل تخزينها.
- ▸نقاط الضعف: الاستشهادات تكون على مستوى الصفحة، وليس على مستوى الجملة. لا يمكنك إبراز السطر الذي جاءت منه الإجابة. تسجيل كل رقعة يزيد من زمن الاستجابة، خاصة بدون وحدة معالجة رسوميات (GPU).
- ▸الأفضل لـ: المستندات المرئية التي لا يمكنك التنبؤ بتخطيطها. بوالص الشحن، الأرشيفات القديمة الممسوحة ضوئياً، الأدلة الهندسية المختلطة، والعروض التقديمية.
2. التحليل المدرك للتخطيط (Docling، Unstructured، Marker)
استخدم نموذجاً يفهم بنية المستند لاستخراج النص مع الاحتفاظ بالتخطيط. تبقى الجداول جداول، والترويسات ترويسات، ويصمد ترتيب القراءة، ويتم وضع علامات على الأشكال. قسّم إلى مقاطع حسب الوحدة: قسم، جدول، تعليق توضيحي. قم بتضمين تلك المقاطع باستخدام نموذج تضمين نصي عادي.
- ▸نقاط القوة: رخيص في وقت الاستعلام، استرجاع بمتجه واحد تقوم بتشغيله بالفعل، استشهادات على مستوى الجملة، متوافق مع أي قاعدة بيانات المتجهات.
- ▸التكلفة: المحلل (parser). اكتشاف التخطيط واستعادة الجداول يحتاجان إلى وقت GPU لكل صفحة، وتختلف الجودة حسب نوع المستند. يصف Docling طريقته في تقرير فني. تنشر Unstructured صفحة معايير تسجل المحللات بناءً على دقة النص، والرموز المخترعة، ودقة خلايا الجدول على 1,000 صفحة مؤسسية. تم نشرها من قبل المورد، لذا اقرأ المنهجية قبل الوثوق بالتصنيف. Marker هو الخيار مفتوح المصدر لملفات PDF التي تحتوي على معادلات وأشكال.
- ▸نقاط الضعف: لا تزال الرسوم البيانية تتحول إلى تعليقات توضيحية. النماذج المرسومة باليد أو غير القياسية تتدهور. أنت تثق في أن المحلل سيكون على صواب.
- ▸الأفضل لـ: المستندات جيدة التنظيم التي تحتوي على طبقة نصية حقيقية. الإيداعات التنظيمية، أدلة السياسات، العقود، والتقارير المنشورة.
3. التعليق التوضيحي للأشكال باستخدام نموذج رؤية
احتفظ بخط المعالجة النصي للنثر. لكل شكل أو رسم بياني أو مخطط يتم اكتشافه، استدعِ نموذج لغة رؤية واطلب وصفاً منظماً. تعليق توضيحي كمثال: "رسم بياني خطي؛ المحور السيني الأرباع من الأول إلى الرابع 2025؛ المحور الصادي الإيرادات بملايين الدولارات؛ ثلاث مناطق؛ منطقة أوروبا والشرق الأوسط وأفريقيا (EMEA) تنخفض من 42 إلى 31 بين الربعين الثاني والثالث". قم بتخزين هذا الوصف كمقطع إضافي مرتبط بصفحة الشكل.
- ▸نقاط القوة: يتكامل مع أي حزمة تقنية موجودة. تصبح الرسوم البيانية قابلة للبحث دون تغيير آلية الاسترجاع.
- ▸التكلفة: استدعاء واحد لنموذج الرؤية لكل شكل عند الاستيعاب. ضع ميزانيتها كتكلفة لمرة واحدة لكل مستند، وليس كتكلفة متكررة.
- ▸نقاط الضعف: جودة التعليق التوضيحي تعتمد على جودة النموذج والموجّه. الرسم البياني المضغوط في فقرة يفقد القيم الصغيرة.
- ▸الأفضل لـ: المجموعات النصية الكثيفة التي تحتوي على ذيل طويل من الأشكال المهمة. تقارير الأبحاث، وثائق المنتجات، والعروض التقديمية للمستثمرين.
أيها تختار
| إذا كانت مستنداتك في الغالب... | استخدم |
|---|---|
| ممسوحة ضوئياً، مختلطة التخطيط، غير متجانسة بصرياً | استرجاع صورة الصفحة بأسلوب ColPali |
| نص منظم مع جداول وأقسام حقيقية | التحليل المدرك للتخطيط (Docling / Unstructured) |
| نثر مع رسوم بيانية ومخططات عرضية | خط معالجة نصي + تعليق توضيحي للأشكال بنموذج VLM |
| كل ما سبق في مجموعة مستندات واحدة | توجيه حسب الصفحة (انظر أدناه) |
توجيه الصفحات: النمط الذي يتفوق على خط المعالجة الفردي
مجموعات المستندات الحقيقية ليست من نوع واحد. أرشيف المشتريات يحتوي على عقود مطبوعة، فاكسات ممسوحة ضوئياً، تصديرات جداول بيانات محفوظة كـ PDF، وأوراق بيانات موردين مليئة بالمخططات. دفع كل هذا عبر خط معالجة واحد يعني التعامل مع جزء منه بشكل سيء.
النمط الفعال هو استخدام موجّه (router) في وقت الاستيعاب، يُطبق على كل صفحة:
- ▸قم بتشغيل مصنف رخيص على الصفحة. الفئات هي: يغلب عليها النص، مليئة بالجداول، مليئة بالأشكال، وممسوحة ضوئياً بطبقة نصية رقيقة أو مفقودة.
- ▸وجّه حسب الفئة. الصفحات التي يغلب عليها النص تمر عبر التحليل المدرك للتخطيط. الصفحات المليئة بالأشكال تذهب إلى التعليق التوضيحي أو تضمين صورة الصفحة. الصفحات الممسوحة ضوئياً والمرئية تذهب إلى استرجاع صورة الصفحة.
- ▸قم بتخزين نوع الصفحة مع المقطع، حتى يتمكن الاسترجاع من وزنها أو تصفيتها بناءً عليه. الحقول page_type، رقم الصفحة، و bbox تنتمي إلى مخطط البيانات الوصفية للمقطع، بجوار التواريخ، مجموعات الوصول، والحالة.
هذا عمل بنية تحتية غير براق. ولكنه أيضاً التغيير الأكثر فعالية لمجموعة مستندات مختلطة. النظام الذي يختار الأداة المناسبة لكل صفحة يتفوق على نموذج تضمين ذكي واحد.
كيف يبدو خط معالجة الاستيعاب الفعال
خط معالجة متعدد الوسائط للإنتاج، مجرد إلى أساسياته:
</>View technical implementation · عرض التفاصيل التقنية
PDF → page splitter → page classifier
│
├── text pages → layout-aware parse → text chunks → text embeddings
├── figure pages → VLM caption + text pass → paired chunks → text embeddings
└── visual pages → page render → vision embeddings (multi-vector)
all chunks → vector store (with page_type metadata, document_id, page_number, bbox)
raw page images → object store (S3, R2), referenced by URL
الـ bbox، وهو اختصار للصندوق المحيط (bounding box)، هو المستطيل الموجود على الصفحة والذي جاء منه المقطع: أربعة إحداثيات. إنه ما يتيح للواجهة رسم تمييز (highlight) على الصفحة المصدر.
قاعدتان توفران عليك الكثير من المتاعب:
- ▸لا تقم أبداً بتخزين بايتات الصورة في حمولة قاعدة بيانات المتجهات. قم بتخزين عنوان URL إلى مخزن الكائنات. الفهرس الخفيف يحافظ على سرعة البحث.
- ▸قم دائماً بتخزين رقم الصفحة، والـ bbox عندما يكون متاحاً لديك. الاستشهاد بدون مرجع صفحة ليس استشهاداً. يحتاج المستخدمون والمدققون إلى النقر للوصول إلى المصدر.
التكلفة: استخدم أرقامك الخاصة
الاستيعاب متعدد الوسائط يكلف أكثر لكل صفحة مقارنة بالنص فقط. مقدار الزيادة يعتمد على المعمارية وعلى مدى ثقل صفحاتك. بدلاً من اقتباس مضاعف شخص آخر، احسب الرقم من مجموعة مستنداتك الخاصة.
لنفترض أن P هي الصفحات المستوعبة شهرياً، و V هي نسبة الصفحات الموجهة إلى تضمين الرؤية، و F هي الأشكال لكل صفحة نصية تُرسل للتعليق التوضيحي. تكلفة الاستيعاب الشهرية تقارب حينها:
- ▸التضمين النصي:
P × tokens_per_page × text_embed_price - ▸تضمين الرؤية:
P × V × tokens_per_page_image × vision_embed_price - ▸التعليق التوضيحي للأشكال:
P × (1 − V) × F × (vlm_input_tokens + vlm_output_tokens) × vlm_price - ▸التخزين: يتناسب مع عدد المتجهات مضروباً في الأبعاد. صفحات المتجهات المتعددة تضاعف العدد بمقدار الرقع المحتفظ بها لكل صفحة بعد التجميع (pooling).
خذ الأسعار من صفحة تسعير مزود الخدمة في اليوم الذي تبني فيه الميزانية. الأسعار تتغير. لكن النمط لا يتغير: يُدفع الاستيعاب مرة واحدة لكل مستند، ويُدفع الاسترجاع لكل استعلام. إذا كان حجم الاستعلام مرتفعاً ومجموعة المستندات محدودة، فادفع مقابل استيعاب أفضل مرة واحدة.
المقارنة التي تستحق إجراؤها ليست "النص أرخص من الرؤية". بل هي "ما هي تكلفة الإجابة الخاطئة بالنسبة لنا؟" إذا كانت الإجابة تغذي قرار مشتريات، أو سير عمل سريري، أو إيداعاً رسمياً، فإن إرجاع التعليق التوضيحي بدلاً من الرسم البياني ليس مجرد بند تكلفة في الـ API.
تشغيله على نطاق واسع
الصور أثقل من النص. تضمين صورة الصفحة على نطاق واسع مقيد بوقت الـ GPU، والبرنامج النصي المتسلسل لن ينتهي قبل أن يلاحظ المستخدمون. هناك أمران مهمان:
- ▸قم بالتوازي حسب الصفحة، وليس حسب المستند. محرك بيانات موزع مثل Ray Data أو Daft أو Spark يوزع الصفحات عبر وحدات معالجة الرسوميات (GPUs). انتبه للضغط العكسي (backpressure). هذا ما يحدث عندما لا تتمكن مرحلة بطيئة، مثل استدعاء واحد لنموذج رؤية لكل شكل، من مواكبة المرحلة التي تغذيها. ينمو الطابور بينهما حتى يفشل شيء ما. قم بتغيير حجم المرحلة البطيئة، أو ضع حداً لمدى تقدم المرحلة السريعة.
- ▸افصل الاستيعاب عن التقديم (serving). الاستيعاب هو مهمة مجمعة (batch job) مع إعادات محاولة ونقاط حفظ. التقديم هو مسار بزمن استجابة منخفض. لا يتشاركان في شيء سوى قاعدة بيانات المتجهات ومخزن الكائنات.
الاسترجاع باستخدام تضمينات الصفحة متعددة المتجهات أبطأ من الاسترجاع النصي أحادي المتجه. الإجابة من صورة صفحة أبطأ من الإجابة من سلسلة نصية. مقدار البطء يعتمد على أجهزتك، واختيارك للتجميع (pooling)، ونموذجك. قم بقياس كليهما على حزمتك الخاصة قبل أن تعد بوقت استجابة معين.
أين يتناسب هذا مع الضبط الدقيق
يحل الـ RAG متعدد الوسائط والضبط الدقيق (fine-tuning) مشاكل مختلفة. الاسترجاع يضع الصفحة الصحيحة أمام النموذج. الضبط الدقيق يغير كيفية قراءة النموذج لتلك الصفحة. بالنسبة لمعظم أعمال المستندات، الاسترجاع هو عنق الزجاجة. خط معالجة موجه جيداً مع نموذج رؤية عام يتفوق على نموذج نصي فقط مضبوط بدقة يعمل على استخراجات مكسورة. يغطي إطار عمل RAG مقابل الضبط الدقيق متى تنعكس هذه الآية.
الأسئلة الشائعة
هل نحتاج إلى استبدال قاعدة بيانات المتجهات الخاصة بنا؟ في الغالب لا. تقبل Qdrant و pgvector ومعظم المخازن الناضجة أي بُعد تضمين تستخدمه. الاسترجاع متعدد المتجهات بأسلوب ColPali يحتاج إلى مخزن يدعمه بشكل أصلي، أو مُعيد ترتيب (reranker) في تطبيقك. تدعم Qdrant المتجهات المتعددة مباشرة؛ بينما تحتاج pgvector إلى المزيد من التجهيزات. إذا بقيت على المتجه الأحادي، فقاعدة بياناتك الحالية تفي بالغرض.
هل يمكن تشغيل هذا بالكامل محلياً (on-premise)؟ نعم. تعمل نماذج تضمين الرؤية مفتوحة الأوزان من عائلة ColPali على وحدات معالجة الرسوميات (GPUs) الخاصة بك. وكذلك النماذج القادرة على الرؤية من عائلتي Qwen و Llama، تحت vLLM أو SGLang. خطط لذاكرة GPU أكبر من تقديم النص فقط، ولمعدل إنتاجية (throughput) المعالجة المسبقة للصور، وليس فقط الرموز في الثانية. يغطي دليل سرعة LLM المحلي أدوات التحكم في التقديم.
ما الذي ينكسر أولاً عندما نتوسع من 1,000 إلى 100,000 مستند؟ وقت الاستيعاب وحجم الفهرس. خط المعالجة الذي يتعامل مع 1,000 ملف PDF على كمبيوتر محمول في فترة ما بعد الظهر يمكن أن يستغرق أسابيع لـ 100,000 مستند إذا كان يعمل بخيط واحد (single-threaded). يمكن أيضاً أن يتجاوز الفهرس متعدد المتجهات سعة الذاكرة. قرر بشأن إطار عمل استيعاب موزع، وعمليات التكميم (quantization) والتجميع (pooling)، قبل فهرسة مجموعة المستندات الكاملة. إعادة فهرسة 100,000 مستند هو مشروع لا أحد يرغب في إجرائه مرتين.
هذا الأسبوع، خذ 50 صفحة من مجموعة مستنداتك الحقيقية وصنفها يدوياً إلى نص، جدول، شكل، ومسح ضوئي. احسب كل فئة. ستخبرك النسب بأي خط معالجة تحتاجه كل شريحة من مجموعة مستنداتك، وما إذا كنت بحاجة إلى موجّه (router) من الأساس. ثم اكتب عشرة أسئلة تقع إجاباتها في تلك الجداول والرسوم البيانية. أضفها إلى مجموعة اختبار تتضمن أسئلة تقع إجاباتها في جداول ورسوم بيانية. إذا فشل نظامك الحالي فيها، فقد اكتشفت مشكلة الصفحة 47 قبل أن يكتشفها المستخدم.
→ مخطط البيانات الوصفية (Metadata Schema) لـ Enterprise RAG: التواريخ، التحكم في الوصول، الحالة، والتسلسل → نظام RAG للبروتوكولات السريرية محلياً (On-Prem): البنية التحتية لمستشفيات الخليج → ورقة بناء RAG العربي: قواعد التسوية، ومستخرجات PDF، ونماذج التضمين التي يجب اختبارها أولاً