أفضل نماذج OCR مفتوحة المصدر وأدوات تحليل المستندات لأنظمة RAG في 2026
OCR مفتوح المصدر لأنظمة RAG: مقارنة 2026
ثمانون بالمئة من بيانات المؤسسات تعيش في صيغ لم تُصمَّم أصلاً لتقرأها الآلات: ملفات PDF حكومية ممسوحة ضوئياً، وعقود مشتريات بلغات مختلطة، وجداول مالية مطبوعة وتتنقل عبر البريد الإلكتروني بين الأقسام والجهات. كثير من فرق الذكاء الاصطناعي تفترض أن هذه المشكلة محلولة. هي ليست كذلك.
مرحلة OCR (التعرف الضوئي على الحروف) وتحليل المستندات هي حيث تفشل أنظمة RAG (التوليد المعزز بالاسترجاع) أولاً، وتفشل في صمت. جدول يُقرأ بشكل خاطئ يتحول إلى رقم هلوسة. ترتيب قراءة معكوس ينتج مقطعاً بلا تماسك دلالي. عمود بلا رأس يعني أن نموذج التضمين يُشفّر بيانات بلا سياق، ويسترجع النظام بثقة المقطع الخطأ. بحلول الوقت الذي يلاحظ فيه المهندس المشكلة، تكون قد وصلت إلى بيئة الإنتاج.
يقارن هذا الدليل الأدوات التي تهم فعلاً في 2026 للفرق الهندسية التي تبني أنظمة ذكاء اصطناعي للمستندات على نطاق واسع: Tesseract 5 وPaddleOCR v3 وDocling وSurya وTrOCR. يغطي المفاضلات المعمارية، ومتطلبات OCR متعدد اللغات، والتعرف على النصوص العربية RTL، وتجربة نشر حقيقية من العمل الهندسي لشركة Seven Labs مع عميل في دول الخليج العربي.
لماذا تحدد جودة تحليل المستندات دقة الاسترجاع في RAG؟
دقة التعرف الضوئي على الحروف (OCR accuracy) تحظى باهتمام أكبر من حجمها الحقيقي، لكن دقة الحرف الواحد ليست سوى بُعد واحد من المشكلة. تحليل تخطيط الصفحة - اكتشاف الأعمدة والجداول والأشكال وترتيب القراءة وحدود الأقسام - له تأثير لا يقل عن دقة التعرف على الأحرف في جودة المقاطع النصية المُستخرجة.
ملف PDF ممسوح ضوئياً بدقة 98% على مستوى الأحرف لكن باكتشاف خاطئ للأعمدة سينتج نصاً متداخلاً من عمودين منفصلين مدمجين في مقطع واحد. هذا المقطع سيُضمَّن كوحدة دلالية كثيفة ومشوشة. سيسترجعه النظام رداً على استفسارات من أي من العمودين، وسيُنتج النموذج اللغوي تركيباً وهمياً من محتوى لم يكن مقصوداً أن يكون متجاوراً.
واقع الأنابيب تتابعي ومتراكم: OCR يُغذي تحليل التخطيط، وتحليل التخطيط يُغذي تقسيم المستندات، والتقسيم يُغذي التضمين، والتضمين يُغذي الاسترجاع. الأخطاء في أي مرحلة أولى تتضاعف في كل مرحلة لاحقة. الاستثمار في نموذج تضمين مكلف مع محلل مستندات ضعيف خطأ شائع ومكلف.
كيف تقارن أبرز أدوات OCR مفتوحة المصدر في 2026؟
الأدوات التالية تمثل الخيارات الواقعية للنشر الذاتي في سير عمل المستندات المؤسسية في بيئة الإنتاج. لكل منها نمط قوة مميز؛ ولا توجد إجابة شاملة واحدة.
| الأداة | اللغات | تحليل التخطيط | استخراج الجداول | دعم RTL | الأنسب لـ |
|---|---|---|---|---|---|
| Tesseract 5 | 100+ | أساسي | ضعيف | جزئي | المستندات اللاتينية البسيطة عالية الحجم |
| PaddleOCR v3 | 80+ شاملاً العربية | قوي | جيد | نعم | متعدد اللغات، العربية/CJK، التخطيطات المختلطة |
| Docling (IBM) | 40+ | ممتاز | ممتاز | محدود | ملفات PDF المؤسسية المهيكلة، تكامل LLM |
| Surya | 90+ | ممتاز | جيد | نعم | التخطيط أولاً، معالجة GPU |
| TrOCR | 10+ | لا يوجد | لا يوجد | محدود | الخطوط اليدوية والمسوحات التاريخية المتدهورة |
Tesseract 5: خط البداية وليس السقف
Tesseract 5 هو الخيار الناضج والمُختبر الذي تبدأ به كل فرقة. محرك التعرف القائم على LSTM موثوق للمستندات اللاتينية النظيفة المكتوبة، ونظام البيئة البرمجية من المكتبات المساعدة مثل pytesseract وtesserocr يجعل التكامل مباشراً. لأنابيب المعالجة الدفعية عالية الحجم على مستندات إنجليزية بسيطة، يبقى خياراً مقبولاً.
الحد الأعلى للإنتاج يظهر سريعاً. تحليل تخطيط الصفحة في Tesseract ضعيف - صُمم للتعرف على الأحرف لا لفهم بنية الصفحة. التخطيطات متعددة الأعمدة والجداول ذات الخلايا المدمجة والصفحات المتعددة الاتجاهات تنتج مخرجات رديئة دون معالجة مسبقة مكثفة. دعم OCR العربي موجود عبر حزمة اللغة ara، لكن معالجة التشكيل وتقسيم الوصل متقطعة وغير متسقة، وترتيب القراءة من اليمين إلى اليسار كثيراً ما يكون خاطئاً في المستندات ثنائية اللغة.
لأي سير عمل مؤسسي يتضمن نصوصاً غير لاتينية أو جداول معقدة أو تخطيطات كثيفة، Tesseract 5 نقطة انطلاق للتقييم لا توصية للإنتاج.
PaddleOCR v3: الخيار الأقوى متعدد اللغات
PaddleOCR v3، الذي طوّرته فرقة PaddlePaddle في Baidu، هو أكثر محركات OCR مفتوحة المصدر كفاءة للفرق التي تحتاج إلى دعم حقيقي لـ OCR متعدد اللغات في بيئة الإنتاج. يغطي 80+ لغة شاملاً العربية والهندية واليابانية والكورية والصينية، بنماذج تعرف مخصصة مدربة على توزيعات مستندات حقيقية لا على بيانات اصطناعية فحسب.
أنبوب التخطيط هو المُميِّز الفعلي. يفصل PaddleOCR بين كشف النص وتصنيف اتجاه النص والتعرف في مراحل منفصلة، كل منها بنموذج مخصص. هذا التصميم يعني أن التعرف على النص العربي RTL يُعالَج بصراحة في مُصنِّف الاتجاه لا يُرمَّم بعد الحقيقة. اكتشاف الجداول دقيق بما يكفي لمعظم أنواع المستندات المؤسسية، بما فيها الجداول المالية والنماذج الحكومية.
التعرف على النصوص غير اللاتينية - ولا سيما العربية بالتشكيل - أفضل بشكل ملموس من Tesseract. تقسيم الوصل يتعامل بشكل صحيح مع تركيبات الأحرف العربية الشائعة، ومعالجة النص ثنائي الاتجاه (bidi) تُنتج ترتيب قراءة صحيحاً في المستندات العربية الإنجليزية المختلطة في معظم الأوقات.
النشر الذاتي لـ PaddleOCR للاستدلال على المعالج المركزي CPU في أنبوب دفعي ممكن. الاستدلال على GPU يقلل زمن الاستجابة لكل صفحة بشكل كبير وهو موصى به للأحمال الحساسة للزمن أو استيعاب البيانات بتزامن عالٍ. لفرق تراجع معايير دقة OCR عبر مجموعات مستندات متعددة اللغات، يتصدر PaddleOCR v3 باستمرار خيارات مفتوحة المصدر على المحتوى العربي وCJK.
Docling (IBM): تحليل يُعطي الأولوية للمستند مع تكامل LLM
فتح IBM Research مصدر Docling عام 2024 وهو يمثل فلسفة مختلفة: بدلاً من OCR ثم التحليل، يطبق Docling الفهم الأصيل للمستند من البداية. صُمم لحالة استخدام استخراج البيانات المهيكلة التي تحتاجها معظم أنابيب RAG المؤسسية فعلاً - ليس نصاً خاماً، بل بنية هرمية: أقسام وأقسام فرعية وجداول بعلاقات صحيحة للخلايا وتعليقات توضيحية للأشكال وترتيب قراءة يحترم التنظيم الدلالي للمستند الأصلي.
استخراج الجداول هو حيث ينفصل Docling فعلاً. يستخدم نموذج تعرف مخصصاً على بنية الجداول يُخرج الجداول ككائنات مهيكلة مع صفوف رأسية وصفوف بيانات وعلاقات الأعمدة - لا كنص مسطح بمحاذاة تقريبية بالمسافات. لأنبوب ذكاء اصطناعي للمستندات يستوعب التقارير المالية والمواصفات التقنية ومستندات الامتثال، هذه الدقة الهيكلية تُحسّن جودة المقاطع ودقة الاسترجاع بشكل كبير.
تكاملات LangChain وLlamaIndex في المستوى الأول ومُصانة بنشاط. DoclingLoader يُنتج كائنات مستندات تحمل البيانات الوصفية والتسلسل الهرمي والبنية إلى مرحلة التضمين. الفرق التي تبني على أطر RAG الراسخة يمكنها إدراج Docling في أنبوب الاستيعاب بأدنى كود مخصص.
القيد هو التغطية متعددة اللغات، ولا سيما العربية. Docling يتعامل جيداً مع مستندات النصوص اللاتينية واللغات الأوروبية الشائعة. دعم RTL محدود في الإصدارات الحالية. لسير العمل المؤسسية في الخليج التي تتضمن مستندات عربية ممسوحة ضوئياً، Docling هو الأنسب في أنبوب مرحلتين مقترن مع PaddleOCR: يتولى PaddleOCR OCR والتحليل على مستوى النص، ويتولى Docling استخراج البيانات المهيكلة من النص المُتعرَّف عليه.
Surya: كشف تخطيط مُسرَّع بـ GPU
Surya هو أحدث المشاركين في هذه القائمة والأسرع تطوراً. مبني على بنية محول transformer بتصميم GPU أولاً، يركز على تحليل تخطيط المستند الدقيق كمهمة أساسية، مع OCR كمستهلك لاحق للمناطق المكتشفة بشكل صحيح.
جودة كشف التخطيط من بين الأفضل المتاحة في مفتوح المصدر، ولا سيما للأوراق الأكاديمية والتقارير الكثيفة والمستندات متعددة الأعمدة. مخرجات ترتيب القراءة أكثر موثوقية من Tesseract عبر التخطيطات المعقدة، واكتشاف الأشكال والجداول والتعليقات التوضيحية يتعامل مع الحالات الحدية التي تُفوّتها الأساليب الأبسط.
لاستيعاب الدفعات المُسرَّعة بـ GPU - نمط شائع في أنابيب مستندات المؤسسات حيث تحل المعالجة الدفعية الليلية محل الاستيعاب الفوري - إنتاجية Surya على أجهزة A10 أو A100 مقنعة. وتيرة التطوير النشطة تعني تحسناً جوهرياً للنموذج على مدى العام الماضي.
المقايضة هي النضج. تغطية OCR ودعم اللغات المتعددة في Surya أضيق من PaddleOCR. للفرق التي تعالج بشكل رئيسي مستندات إنجليزية أو أوروبية بتخطيطات معقدة، Surya خيار قوي. للعربية أو التعرف على النصوص غير اللاتينية على نطاق واسع، يبقى PaddleOCR الخيار الأفضل.
TrOCR: تعرف قائم على المحولات للمسوحات الصعبة
TrOCR من Microsoft Research يطبق بنية نموذج رؤية-لغة - تحديداً مشفِّر ViT مع مُفكِّك تشفير نموذج لغوي - على مهمة OCR. هذا يجعله مختلفاً نوعياً عن محركات OCR القائمة على CNN: يتعامل مع السياق عبر الصورة بدلاً من معالجة مناطق الأحرف بشكل مستقل.
النتيجة أداء أفضل بشكل ملموس على الخطوط اليدوية والمستندات التاريخية المتدهورة والمسوحات منخفضة الجودة التي تفشل فيها محركات OCR التقليدية. للفرق التي تستوعب مستندات أرشيفية أو نماذج يدوية أو صور مستندات بإضاءة متغيرة، كثيراً ما يتفوق TrOCR على البدائل بهامش كبير.
القيد هو النطاق. TrOCR لا يملك قدرة تحليل التخطيط - يقرأ أسطر نص لا مستندات. لا يستخرج جداول ولا يكتشف أعمدة ولا يُنتج مخرجات مهيكلة. يفتقر أيضاً إلى دعم واسع متعدد اللغات خارج الإنجليزية وعدد محدود من اللغات الأخرى. في أنبوب استيعاب البيانات غير المهيكلة للإنتاج، TrOCR هو الأفعل كمكوّن متخصص: وجِّه المستندات التي تفشل في عتبات الجودة في نظام OCR الأساسي إلى TrOCR لتمرير ثانٍ، ثم ادمج المخرجات.
كيف يبدو أنبوب OCR إلى RAG في بيئة الإنتاج فعلاً؟
استخراج PDF لنظام RAG في الإنتاج ليس مشكلة أداة واحدة. الأنبوب هو تسلسل من القرارات، كل منها يقيّد التالي:
- تصنيف المستند - النوع (ممسوح ضوئياً، رقمي أصلي، مختلط)، اللغة/اللغات، وجود جداول/أشكال
- اختيار OCR - توجيه المستندات متعددة اللغات/RTL إلى PaddleOCR، وملفات PDF الرقمية المهيكلة إلى Docling، والمسوحات المتدهورة إلى TrOCR
- تحليل التخطيط - كشف الأعمدة، تصحيح ترتيب القراءة، استخراج الجداول
- نقاط الثقة - عتبات ثقة OCR لكل صفحة؛ وضع علامة على الصفحات منخفضة الثقة للمراجعة البشرية بدلاً من استيعاب الضوضاء بصمت
- تقسيم المستند - حدود دلالية تحترم التخطيط لا أعداد أحرف اعتباطية
- التضمين - اختيار نموذج مناسب للغة لكل مقطع (حرج للمحتوى العربي الإنجليزي المختلط)
- استيعاب الفهرس - مع البيانات الوصفية: المستند المصدر، الصفحة، وسم اللغة، نقاط الثقة
مرحلة تقسيم المستند هي حيث تتراكم أخطاء OCR بأوضح شكل. مقطع يمتد عبر حد جدول بلا بيانات وصفية هيكلية سيُضمَّن كنثر غامض. مقطع ينقسم في منتصف جملة بسبب كشف خاطئ لفاصل الصفحة سيُسترجع بشكل رديء لكلا النصفين. الصواب في التخطيط ببداية أنبوب العمل هو ما يجعل التقسيم قابلاً للإدارة.
تكلفة النشر الذاتي: الاستدلال على CPU لـ PaddleOCR على نسخة حوسبة قياسية يُكلف تقريباً 0.002-0.005 دولار لكل صفحة عند إنتاجية الدفعة. الاستدلال على GPU على نسخة A10 مشتركة يمكنه المعالجة بسرعة أكبر 10-20 مرة وهو فعّال من حيث التكلفة لأنابيب تتجاوز ~100,000 صفحة شهرياً.
دراسة حالة: RAG مؤسسي عربي-إنجليزي لعميل خليجي
هذا تسليم حقيقي. تعاقد عميل مؤسسي خليجي مع Seven Labs لبناء أنبوب ذكاء اصطناعي للمستندات قادر على استيعاب مجموعة بيانات غير متجانسة: تصاريح حكومية ممسوحة ضوئياً باللغة العربية، وتقارير داخلية مكتوبة بالعربية والإنجليزية معاً، وجداول مالية بكلا الخطين. يحتاج المخرج إلى تغذية نظام RAG ثنائي اللغة يستخدمه أكثر من 300 موظف لاستفسارات السياسات والأنظمة.
مجموعة المستندات كانت أصعب من عمل الاستيعاب المؤسسي المعتاد. التصاريح الحكومية كانت مسوحات مصوَّرة لا ملفات PDF نظيفة. اللغة العربية تراوحت بين الفصحى المعيارية الحديثة الرسمية ولهجة خليجية بتشكيل غير متسق. الجداول المالية كانت ذات خلايا مدمجة ورؤوس متعددة الصفوف ومحتوى ثنائي الاتجاه داخل الخلايا الفردية. كان على أنبوب استيعاب واحد التعامل مع كل هذا.
طبقة OCR استخدمت PaddleOCR v3 كمحرك أساسي لجميع المستندات الممسوحة ضوئياً والمستندة إلى الصور. تجزئة الأحرف العربية كانت أول تحدٍّ في الإنتاج. مُصنِّف الاتجاه في PaddleOCR حدَّد بشكل صحيح الكتل RTL في الصفحات المختلطة، لكن حوالي 8% من المستندات الحكومية الممسوحة كانت ذات اتجاه مسح غير متسق - صفحات مُصوَّرة بزوايا أربكت نموذج الاتجاه. الحل كان مرحلة معالجة مسبقة باستخدام OpenCV للكشف عن اتجاه الصفحة وتصحيحه قبل OCR، مما قلل التصنيف الخاطئ للاتجاه إلى أقل من 1%.
معالجة التشكيل تطلبت قرارات تطبيع صريحة. جُرِّد التشكيل (حركات التشكيل الصوتي) قبل التضمين، لأن الكلمة الجوهرية ذاتها ظهرت بتشكيل ودونه عبر أنواع المستندات المختلفة. بدون التطبيع، كان المصطلح القانوني ذاته سيُنتج تضمينات متمايزة متعددة يعاملها نظام الاسترجاع كمفاهيم مختلفة. بُني منطق التطبيع كمرشح بعد-OCR يُطبَّق قبل التقسيم.
تولّى Docling الاستخراج المهيكل لملفات PDF الرقمية الأصلية - التقارير الداخلية ومستندات السياسات غير الممسوحة ضوئياً. استخراج الجداول أنتج كائنات مهيكلة احتفظت بعلاقات الأعمدة إلى مرحلة التضمين. لنظام استعلام الامتثال، كان هذا مهماً: مقطع مسترجع يقول "الموافقة مطلوبة: نعم" مع السياق الصحيح للجدول مفيد؛ القيمة ذاتها دون سياق الصف/العمود عديمة الجدوى.
استراتيجية التقسيم ثنائية اللغة عملت على مستوى المقطع لا مستوى المستند. كل مقطع حمل وسم لغة (عربي، إنجليزي، أو مختلط)، مما حدد التوجيه إلى نموذج التضمين المناسب. المقاطع المختلطة - تبادل الشفرات في منتصف الفقرة - وُجِّهت إلى نموذج متعدد اللغات بدلاً من إجبارها عبر نموذج أحادي اللغة.
استوعب الأنبوب الشامل حوالي 45,000 صفحة عبر 1,200 مستند. دقة الاسترجاع على الاستفسارات العربية مقابل المستندات المصدر العربية بلغت 87% في المواضع الثلاثة الأولى - أعلى بشكل ملحوظ من أنبوب مُحسَّن لإنجليزي أولاً ومُكيَّف للعربية، الذي بلغ 61% على مجموعة التقييم ذاتها. استخراج الجداول المهيكلة أسهم بنحو 12 نقطة مئوية من هذا الفارق: الاستفسارات عن حدود تنظيمية محددة أو حدود مالية استرجعت خلية الجدول الصحيحة لا فقرة مجاورة.
للاطلاع على الهيكل المعماري الكامل لهذا النشر، راجع RAG مؤسسي عربي-إنجليزي في منطقة الخليج.
أي أداة OCR يجب أن تختار لأنبوب RAG الخاص بك؟
إطار القرار لأنظمة الإنتاج:
- ملفات PDF رقمية نظيفة بالإنجليزية فقط بتخطيطات بسيطة - Docling وحده مع تكامل LlamaIndex أو LangChain. لا مرحلة OCR مطلوبة للمستندات الرقمية الأصلية.
- مستندات ممسوحة ضوئياً بالإنجليزية فقط بتخطيطات معقدة - Surya لكشف التخطيط + Tesseract 5 أو نموذج Surya OCR للتعرف. GPU مُفضَّل.
- متعدد اللغات شاملاً العربية/RTL، ممسوح ضوئياً - PaddleOCR v3 كمحرك أساسي، مع معالجة مسبقة للاتجاه وتطبيع تشكيل في المعالجة اللاحقة.
- مختلط: بعضها رقمي وبعضها ممسوح ضوئياً، جداول مهيكلة - PaddleOCR للمستندات الممسوحة، Docling للرقمية الأصلية، استخراج جداول من Docling للمخرجات المهيكلة. أنبوب مرحلتين مع تصنيف المستند عند الاستيعاب.
- خط يدوي أو مسوحات متدهورة بشدة - TrOCR كمرحلة احتياطية للمستندات التي تفشل في عتبات ثقة OCR الأساسية.
لمعظم سير عمل المستندات المؤسسية غير الإنجليزية البحتة والرقمية البحتة، الإجابة هي أنبوب يستخدم أدوات متعددة في مراحل توجيه مختلفة لا محرك واحد لجميع أنواع المستندات.
إذا كنت تُقيِّم مشروع OCR واستيعاب RAG، فإن تقييم جاهزية RAG هو أسرع طريقة لتحديد أين تُنشئ معالجة مستنداتك الحالية فجوات في الاسترجاع. تتضمن صفحة دراسات الحالة لذكاء اصطناعي المؤسسات عدة نشرات تتضمن مجموعات بيانات ثقيلة بالمستندات.
لتعمق أكبر في استراتيجية التقسيم بعد إحكام طبقة التحليل، وثّق فريق Seven Labs أيضاً أنماط الفشل في مرحلة المجرى السفلي في بيئة الإنتاج في استراتيجيات تقسيم RAG المتقدمة.
تغطي صفحة خدمات هندسة منصات الذكاء الاصطناعي الإطار الكامل الذي نُطبّقه في هذه النشرات، شاملاً تصميم أنبوب الاستيعاب واختيار نموذج التضمين وأطر التقييم لأنظمة الاسترجاع ثنائية اللغة.
الأسئلة المتكررة
أي أداة OCR مفتوحة المصدر هي الأفضل للمستندات العربية في أنبوب RAG؟ PaddleOCR v3 هو الخيار مفتوح المصدر الأقوى لـ OCR العربي في الإنتاج. يدعم اتجاه النص RTL، ويتعامل مع التشكيل العربي أفضل من البدائل، وله تطوير نشط للنماذج متعددة اللغات. يتطلب معالجة لاحقة لتطبيع التشكيل وتصحيح اتجاه المسح في مجموعات المستندات المؤسسية الحقيقية.
هل يتعامل Docling مع المستندات العربية وRTL؟ دعم RTL في Docling محدود في الإصدارات الحالية. يُؤدي أفضل ما لديه على المستندات المهيكلة ذات النصوص اللاتينية. للمجموعات العربية، استخدم PaddleOCR لمرحلة OCR والتحليل، ثم طبّق نماذج استخراج الجداول والبنية في Docling على مخرجات النص المُتعرَّف عليه.
ما الفرق بين دقة OCR وتحليل التخطيط في أنبوب RAG؟ تقيس دقة OCR مدى صحة التعرف على الأحرف الفردية. يُحدد تحليل التخطيط العلاقات الهيكلية بين مناطق النص المُتعرَّف عليها: ترتيب الأعمدة وبنية الجداول وتسلسل القراءة وإقران الأشكال بتعليقاتها. في أنبوب RAG، كثيراً ما تُحدث أخطاء التخطيط ضرراً أكبر في الاسترجاع من أخطاء OCR على مستوى الأحرف لأنها تُدمر تماسك المقاطع.
كيف أحدد الاختيار بين الاستدلال على CPU وGPU للـ OCR المُستضاف ذاتياً؟ للأنابيب التي تعالج أقل من 50,000 صفحة شهرياً بجدول دفعي يمكن التنبؤ به، الاستدلال على CPU على نسخة حوسبة قياسية فعّال من حيث التكلفة. فوق هذا الحد، أو لأي حمل حساس للزمن حيث يجب إتاحة المستندات للاستعلام في غضون دقائق من الاستيعاب، يُقلل الاستدلال على GPU تكلفة الصفحة على نطاق واسع. يستفيد كل من PaddleOCR وSurya بشكل كبير من تسريع GPU.
ما الذي يُسبب فشل استرجاع RAG على المستندات الممسوحة ضوئياً حتى حين يبدو OCR صحيحاً؟ السبب الأكثر شيوعاً هو خطأ في تحليل التخطيط غير مرئي في مخرجات OCR الخام لكنه يُدمر جودة المقاطع. مستند ثنائي العمود مُعالَج باكتشاف خاطئ للأعمدة سيُنتج نصاً متداخلاً من كلا العمودين في ترتيب القراءة، يبدو نصاً صالحاً لكنه لا يحمل محتوى دلالياً متماسكاً. خلايا الجداول المُستخرجة دون سياق الصف والعمود تُضمَّن كنقاط بيانات منفصلة. الحل هو الاستثمار في تحليل التخطيط - ولا سيما التعرف على بنية الجداول وكشف الأعمدة - لا مجرد دقة OCR على مستوى الأحرف.