فتح كشوف الحسابات البنكية ليس أمراً ممتعاً لأحد. فهي تصل بصيغة ملفات PDF ممسوحة ضوئياً، أو تصديرات CSV، أو ملفات XML مغلفة باختصارات غامضة مثل OFX. بالنسبة للمحاسبين، ومسؤولي مسك الدفاتر، ومطوري التكنولوجيا المالية (fintech)، فإن تحويل هذه المستندات إلى بيانات نظيفة ومنظمة يمثل صداعاً مستمراً. وعندما ظهرت النماذج اللغوية الكبيرة (LLMs) فجأة، بدت وكأنها تقدم مخرجاً من هذه المشكلة. فقط قم بتغذية الآلة بملف PDF واطلب الحصول على JSON. ما الذي يمكن أن يحدث من خطأ؟

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

العرض التجريبي الذي نجح أكثر من اللازم

كانت محاولتي الأولى بسيطة بشكل مغرٍ. قمت بتمرير كشوف الحسابات البنكية مباشرة إلى LLM وطلبت الحصول على JSON منظم في المقابل. بدت النتائج وكأنها سحر؛ فقد تعامل النموذج مع التخطيطات المختلفة بسهولة، وقرأ ملفات PDF الممسوحة ضوئياً التي تعجز أدوات التحليل (parsers) القياسية عن معالجتها. بدا وكأنه يفهم الجداول، والعناوين، وكشوف الحسابات متعددة الصفحات دون تعليمات صريحة. ولعدة ساعات مجيدة، ظننت أن المشكلة قد حُلت.

ثم اختبرته مقابل بيانات عملاء حقيقية، فتبخر السحر. تستخدم البنوك في المملكة المتحدة تصاميم خاصة بها لكشوف الحسابات، والاختلافات ليست مجرد اختلافات شكلية. تحمل كشوف حسابات Wise سماتها الخاصة في التنسيق، وتبدو تصديرات CSV الخاصة بـ Revolut مباشرة وبسيطة حتى تلاحظ كيفية تعاملها مع معاملات العملات المتعددة وحقول البيانات الوصفية (metadata). أما ملفات OFX القديمة، وهي صيغة تبدو حقاً وكأنها تنتمي إلى التسعينيات، فهي تفرض هياكل وسوم (tags) عتيقة ومشكلات في الترميز (encoding) على أي محلل يتوقع علامات (markup) حديثة.

لا يزال النموذج يستخرج البيانات بشكل أفضل بكثير من أي نظام قوالب جاهز، لكن "أفضل بكثير" ليست كافية عندما يتعلق الأمر بالمال.

عندما تكون دقة 99% بمثابة فشل

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

نادراً ما يلاحظ الإنسان الذي يراجع ملف JSON خام رقماً متبادلاً في مبلغ المعاملة؛ فالتنسيق مثالي، وهو ما يجعل الخطأ أكثر خطورة للمفارقة. لا يمكنك إطلاق أداة مالية تكون صحيحة في معظم الأوقات، بل يجب أن تكون صحيحة دائماً، أو يجب أن تعلن بوضوح أنها غير متأكدة.

كان رد فعلي الأولي متوقعاً؛ قمت بهندسة مطالبات (prompts) أفضل، وترقيت إلى نماذج أكثر قدرة، وجربت أسلوب "سلسلة الأفكار" (chain-of-thought reasoning) لجعل النموذج يوضح خطوات عمله. لم يحل أي من هذا المشكلة الأساسية؛ فقد كنت أطلب من نفس النظام الاحتمالي توليد إجابة، ثم أطلب من نفس النظام ذاته المصادقة على صحة تلك الإجابة. هذا ليس تحققاً، بل هو مجرد "مسرح للاتساق الذاتي".

دع الرياضيات تقرر

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

أعدت بناء البنية التحتية بناءً على هذه الرؤية. الآن، تمر كل عملية استخراج، بغض النظر عن مصدرها، عبر طبقة تحقق قبل أن يراها أي مستخدم. لا يهم ما إذا كانت البيانات قد جاءت من LLM يفسر ملف PDF غير واضح، أو محرك OCR يقرأ صفحة ممسوحة ضوئياً، أو تحليل مباشر لملف CSV؛ إذ يتعامل نظام التحقق مع جميع المصادر على أنها مشبوهة بالتساوي.

عملية التحقق بسيطة للغاية: أضف كل معاملة إلى الرصيد الافتتاحي، ثم قارن النتيجة بالرصيد الختامي المذكور. إذا لم تتطابق الأرقام، فهناك خطأ ما؛ قم بتمييز كشف الحساب للمراجعة، وارفض عملية الاستخراج، ولا تسمح لها بالوصول إلى المستخدم.

هذا التغيير الوحيد غيّر طابع المنتج بالكامل. لم يعد النموذج اللغوي بحاجة إلى أن يكون مثالياً، بل كان يحتاج فقط إلى أن يكون جيداً بما يكفي لإنتاج مخرجات يمكنها الصمود أمام اختبار رياضي. لقد انتقل الضغط من محاولة تحقيق دقة مستحيلة في مجال غير مقيد إلى بناء حلقة تغذية راجعة محكمة بين التوليد والتحقق.

The validator also exposed patterns in the errors. Certain document types consistently failed the math check, which told me exactly where to invest effort. Instead of blindly improving prompt engineering across the board, I could see that specific bank layouts caused systematic mistakes.

Code Where Code Belongs, AI Where It Shines

Perhaps the most humbling lesson was realizing how much of the pipeline did not need AI at all. When I encountered messy Australian OFX files, my instinct was to throw tokens at the problem. I briefly considered feeding the broken XML to the model and asking it to repair the structure before parsing. Instead, I wrote twenty lines of deterministic code. It fixed the encoding quirks and malformed tags instantly, with zero cost per file and perfect reproducibility.

That experience crystallized how extraction pipelines should be organized. There are three distinct jobs, and they should not be mixed together.

  • The model understands messy documents. Scanned PDFs with warped tables, mixed fonts, and handwritten