خط معالجة LLM لملفات مطالبات التأمين والتذاكر وKYC داخل بنيتك التحتية الخاصة: الاستخراج والتحقق والمراجعة والتدقيق

تشترك ملفات مطالبات التأمين وتذاكر الدعم ومستندات KYC في المشكلة نفسها: يقرؤها أشخاص ليملؤوا حقولًا يحتاجها نظام آخر. فالمطالبة تصير رقم وثيقة تأمين وتاريخ وقوع الضرر وبنودًا تفصيلية؛ والتذكرة تصير فئة وعميلًا؛ ووثيقة الهوية تصير اسمًا وتاريخ ميلاد وتاريخ انتهاء صلاحية. والمتطلب المصاحب لهذا العمل يُعلَن عادةً قبل أي شيء آخر: لا يجوز أن تذهب المستندات إلى OpenAI ولا إلى أي مزوّد نماذج خارجي آخر.

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

سبع مراحل، وكل واحدة منها تبقى في الداخل

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

الاستقبال: صنّف المستند قبل أن يقرأه أي شيء

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

• سجّل القناة والمرسل وتجزئة المحتوى (content hash) عند الوصول، كي يُتعرَّف على المستند المرسل مرتين قبل أن يصبح ملفين
• صنّف من قائمة مغلقة من الأنواع؛ تُدرج وثائق vLLM بشأن المخرجات المهيكلة (structured outputs) المعامل choice، الذي تكون المخرجات معه واحدًا من الخيارات بالضبط، فلا يستطيع المصنِّف اختلاق نوع
• أرسل المستند الذي لا يطابق أي نوع، أو يطابق بدرجة اتفاق منخفضة، إلى شخص بدل أقرب مخطط

النص والتخطيط أولًا، والنموذج اللغوي ثانيًا

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

المحركات مفتوحة المصدر لهذه الخطوة تعمل محليًا. تُظهر وثائق سطر الأوامر في Tesseract مخرجات TSV فيها عمود للثقة لكل كلمة، ومخرجات hOCR فيها سمة لثقة الكلمة، وهي إشارة على مستوى الكلمة يمكن لمرحلة التوجيه استخدامها. أما Docling، وهي مكتبة تحويل مفتوحة المصدر بترخيص MIT، فتُدرج تخطيط الصفحة وترتيب القراءة وبنية الجداول ضمن ميزاتها الخاصة بملفات PDF، إلى جانب دعم OCR لملفات PDF الممسوحة ضوئيًا والصور، والتشغيل المحلي للبيانات الحساسة والبيئات المعزولة عن الشبكة (air-gapped).

• اقرأ الطبقة النصية حيث توجد، ولا تستخدم OCR إلا حيث لا توجد، كي لا تلتقط المستندات النظيفة أخطاء التعرّف
• احتفظ برقم الصفحة ومربع الإحاطة (bounding box) لكل كلمة، كي يمكن لاحقًا عرض كل حقل مستخرج على المراجِع في الصفحة التي جاء منها
• احفظ الجداول جداولَ: الفاتورة التي تُسطَّح أعمدتها في سطر نصي واحد تفقد معرفة أي مبلغ يعود إلى أي بند

ويمكن بدلًا من ذلك أن يقرأ نموذج رؤية ولغة صورة الصفحة: تنص وثائق vLLM بشأن المدخلات متعددة الوسائط على أن إدخال الصور مدعوم وفقًا لـ OpenAI Vision API. وأيّ الطريقتين أفضل يُقاس على مستنداتك، مع مراعاة أن مرحلة OCR المنفصلة تُرجع مواضع الكلمات ودرجات الثقة فيها، أما النموذج الذي يقرأ صورة فلا يُرجعها.

مخرجات مقيَّدة بمخطط: الشكل مفروض، أما المحتوى فلا

يحصل كل نوع مستند على مخطط مخرجات خاص به، تُدار إصداراته كما تُدار الشيفرة. تُدرج وثائق vLLM بشأن المخرجات المهيكلة خمسة أنواع من القيود: choice، وregex، وJSON schema، وقواعد نحوية خالية من السياق (context-free grammar)، وstructural tag، مع backends منها xgrammar وguidance وoutlines وlm-format-enforcer، وقيمة افتراضية هي auto تحاول اختيار backend مناسب بناءً على تفاصيل الطلب.

• اجعل «غير موجود» قيمة صريحة لكل حقل، كي يُسجَّل تاريخ وقوع الضرر الغائب على أنه غائب بدل أن يُخمَّن
• استخدم التعدادات (enumerations) لكل ما سيتفرّع نظام آخر بناءً عليه: نوع المطالبة، وفئة التذكرة، ونوع المستند، ورمز البلد
• أضف إلى كل حقل مرجعًا لمصدره، أي الصفحة والكلمات التي أُخذ منها، كي يتمكن التحقق والمراجعة من مطابقته مع المستند

تحقّق من المخرجات مرة أخرى في شيفرة التطبيق بأداة تحقق JSON Schema عادية. فالـ backends تختلف: تذكر الصفحة نفسها أن xgrammar وguidance وoutlines تستخدم تعبيرات نمطية على طريقة Rust بينما يستخدم lm-format-enforcer الوحدة re في Python، وأنه في نماذج Qwen3 Coder التي فُعِّل فيها الاستدلال (reasoning)، قد تتعطّل المخرجات المهيكلة إذا لم يُحلَّل محتوى الاستدلال إلى حقل منفصل. كما أن التوليد الذي يتوقف عند حدّ الـ tokens ينتهي في منتصف السجل. والفحص الثاني رخيص.

التحقق: قواعد العمل الموجودة أصلًا، مكتوبةً في صورة شيفرة

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

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

لوثائق الهوية أداة تحقق خاصة بها. تحدّد ICAO Doc 9303، وهي المواصفة الخاصة بوثائق السفر المقروءة آليًا، أرقام تحقق في المنطقة المقروءة آليًا تُحسب بالمقياس 10 (modulus 10) بأوزان 7 و3 و1 تتكرر باستمرار، مع احتساب الحروف من A إلى Z بقيم من 10 إلى 35 وحرف الحشو صفرًا، وتنص على أن أرقام التحقق تتيح لأجهزة القراءة التحقق من أن البيانات فُسِّرت تفسيرًا صحيحًا.

التوجيه: القواعد والإشارات تحسم أي الحقول يراها شخص

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

• أي إخفاق في أداة تحقق، بما في ذلك حقل يشترطه المخطط ووسمه النموذج بأنه غير موجود
• انخفاض ثقة OCR في الكلمات التي بُني منها الحقل، مع ضبط العتبة لكل حقل على مجموعة التقييم
• مصدران لا يتفقان، مثل المنطقة المقروءة آليًا والمنطقة المرئية في جواز سفر واحد
• حقول تقرّر ألا تُؤتمت أبدًا، مثل مبلغ مُطالَب به يتجاوز حدًا مقررًا
• عيّنة عشوائية من الحقول التي اجتازت كل شيء، كي يُقاس معدل الأخطاء التي لم يرصدها أحد بدل أن يُفترض

استُبعد ما يعلنه النموذج نفسه عن يقينه عن قصد؛ وتشرح مقالة سابقة في هذه المدونة لماذا هو بوابة ضعيفة.

تعرض شاشة المراجعة الصفحة مع تظليل الكلمات المستشهد بها بجوار القيمة المقترحة، فيتحقق المراجِع بدل أن يعيد القراءة. ويُخزَّن كل تصحيح لكل حقل مع القيمة القديمة والقيمة الجديدة والمراجِع وسبب يُختار من قائمة قصيرة. وحين يؤكده شخص ثانٍ، ينضم إلى مجموعة التقييم، لكنه لا ينضم أبدًا إلى الجزء المجمَّد الذي تُتخذ على أساسه قرارات الإصدار.

التقييم لكل نوع مستند ولكل حقل، لا درجة إجمالية واحدة

رقم دقة واحد لخط المعالجة يُخفي النتيجة المهمة، كأن تخفق تواريخ انتهاء الصلاحية في بطاقات هوية بلد واحد بينما تجتاز كل الحقول الأخرى. قِس على المحاور نفسها التي يستخدمها التوجيه:

• لكل حقل: التطابق التام بعد التطبيع، وبشكل منفصل عدد مرات إغفال الحقل أو اختلاقه حين يحتويه المستند أو لا يحتويه
• لكل نوع مستند ولكل نوع إدخال، مثل ملف PDF رقمي ومستند ممسوح ضوئيًا وصورة هاتف، لأن لكل منها نمط أخطاء خاصًا به
• لكل مسار: نسبة الحقول المؤتمتة، ومعدل الأخطاء في العيّنة المأخوذة منها
• موزونًا بالتكلفة: رقم حساب مصرفي خاطئ واسم شارع مكتوب بخطأ إملائي ليسا الخطأ نفسه

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

مسار التدقيق: أي نموذج وأي موجّه أنتجا أي حقل

المطالبة المتنازع عليها، أو سؤال المدقق عن هوية جرى قبولها، يتعلقان بحقل واحد في مستند واحد. والسجل الذي يجيب عنهما يُكتب أثناء عمل خط المعالجة، بقيد واحد لكل حقل، في مخزن للإلحاق فقط:

• معرّف المستند وتجزئة المحتوى، والصفحة والكلمات التي يستشهد بها الحقل
• إصدار محرك OCR أو محرك التخطيط، ودرجة ثقته في تلك الكلمات
• اسم النموذج والمجموع الاختباري (checksum) للأوزان، وإصدار قالب الموجّه، وإصدار المخطط
• نتيجة كل أداة تحقق، والمسار المتّبع وسببه
• المراجِع، والقيمة قبل التغيير وبعده، والوقت، إن غيّرها شخص

يفرض EU AI Act متطلبًا للتسجيل على الأنظمة التي يعدّها عالية المخاطر: تنص المادة 12(1) على أن أنظمة الذكاء الاصطناعي عالية المخاطر يجب أن تتيح تقنيًا التسجيل التلقائي للأحداث (السجلات) طوال عمر النظام. ويُدرج الملحق III الاستخدامات عالية المخاطر، ومنها تقييم الجدارة الائتمانية للأشخاص الطبيعيين، باستثناء كشف الاحتيال المالي، وتقييم المخاطر والتسعير في التأمين على الحياة والتأمين الصحي؛ وتبيّن المادة 6(3) متى لا يُعدّ نظام مُدرج عالي المخاطر مع ذلك، كأن يؤدي مهمة إجرائية ضيقة. أما ما إذا كان خط معالجة بعينه يقع ضمن النطاق فمسألة يحسمها الفريق القانوني لدى العميل؛ والسجل لكل حقل المكتوب وقت التشغيل مفيد في الحالتين.

البيانات الشخصية: كل مرحلة لا ترى إلا ما تحتاجه مهمتها

ينسخ خط المعالجة البيانات الشخصية إلى أماكن أكثر من المجلد الأصلي. تشترط المادة 5(1)(c) من GDPR أن تكون البيانات الشخصية كافية وذات صلة ومقتصرة على ما هو ضروري بالنسبة إلى الأغراض التي تُعالَج من أجلها. وتطلب المادة 25(2) تدابير تضمن ألا تُعالَج افتراضيًا إلا البيانات الشخصية الضرورية لكل غرض محدد، وتطبّق ذلك على كمية البيانات المجموعة، ونطاق معالجتها، ومدة تخزينها، وإمكانية الوصول إليها. وبلغة خط المعالجة:

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

تُدرج OWASP Logging Cheat Sheet البيانات الشخصية الحساسة وبعض أشكال معلومات التعريف الشخصية، مثل البيانات الصحية والمعرّفات الحكومية، ضمن البيانات التي لا ينبغي عادةً تسجيلها مباشرةً في السجلات، وتنص على أنه ينبغي بدلًا من ذلك إزالة هذه البيانات أو إخفاؤها أو تنقيتها أو تجزئتها (hashing) أو تشفيرها.

تختلف مدة الاحتفاظ باختلاف نوع المستند، وفي حالة KYC في الاتحاد الأوروبي يحدّدها قانون مكافحة غسل الأموال. تُلزم المادة 77 من اللائحة (EU) 2024/1624، التي تسري اعتبارًا من 10 يوليو 2027، الجهاتِ الملزَمة بالاحتفاظ بنسخة من المستندات والمعلومات التي حصلت عليها في إطار العناية الواجبة تجاه العملاء، وبضمان عدم حجب أي جزء من هذه السجلات (redaction). وتحدّد مدة احتفاظ قدرها خمس سنوات، تُحسب من انتهاء علاقة العمل أو من تاريخ المعاملة العرضية، يتعيّن بعدها حذف البيانات الشخصية، مع مراعاة الاستثناءات الواردة في المادة نفسها. ويبقى سجل KYC الأصلي كاملًا في نظام السجل المعتمد (system of record)؛ أما النسخ الخاصة بخط المعالجة، من التتبعات إلى لقطات المراجعة، فتُقلَّص إلى الحد الأدنى وتُحذف وفق جدول أقصر خاص بها.

الإنتاجية: طابور للذروة، وسعة للحالة المستقرة

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

• افصل الطوابير حسب الإلحاح: فحص KYC الذي ينتظره عميل أثناء التسجيل (onboarding) لا يقف في الطابور خلف دفعة من المطالبات التاريخية
• وسّع عمّال OCR على وحدات CPU وخوادم النماذج على المسرِّعات كلًّا على حدة، لأنها تتشبّع عند أحجام مختلفة
• راقب طابور محرك التقديم نفسه: يعرض vLLM مقاييس Prometheus عند نقطة النهاية /metrics الخاصة به، ومنها عدد الطلبات التي تنتظر المعالجة ونسبة كتل ذاكرة key-value المؤقتة المستخدمة
• وسّع العمّال بحسب عمق الطابور لا بحسب حِمل CPU؛ تصف وثائق KEDA توسيع أي حاوية في Kubernetes بناءً على عدد الأحداث التي تحتاج إلى معالجة، مع أدوات توسيع (scalers) لأنظمة المراسلة وغيرها، والتقليص إلى الصفر (scale-to-zero)

سعة المسرِّعات داخل بنيتك التحتية الخاصة ثابتة على المدى القصير، ولذلك يُحدَّد مسبقًا ترتيب الطوابير التي تتنحّى، لا أثناء الذروة.

المطالبات والتذاكر وKYC: الهيكل نفسه وقواعد مختلفة

• المطالبات: مستندات كثيرة لكل ملف، وجداول في الفواتير، وكثيرًا ما تكون فيها معلومات صحية، تُدرجها المادة 9 من GDPR ضمن الفئات الخاصة التي تُحظر معالجتها ما لم ينطبق استثناء وارد في المادة نفسها. وتمنح المادة 22 الشخصَ الحق في ألا يخضع لقرار قائم على المعالجة الآلية وحدها يُنتج آثارًا قانونية تخصه أو يؤثر فيه تأثيرًا كبيرًا مماثلًا، مع استثناءات في المادة 22(2). ولذلك فإن مسألة ما إذا كان خط المعالجة يقتصر على الاستخراج والفحص بينما يتخذ موظف معالجة المطالبات القرار هي قرار تصميم يُتخذ مع مسؤول حماية البيانات لدى العميل، لا خيار هندسي افتراضي
• التذاكر: نصوص قصيرة، وحجم كبير، وشخص ينتظر ردًا، لذا يهمّ زمن الاستجابة أكثر؛ والمخرجات في الغالب فئة وأولوية وبضعة معرّفات. ونص التذكرة يكتبه أشخاص من خارج الشركة، وهو مدخل غير موثوق للنموذج، وهذا خطر تناولته المقالة السابقة عن المشاريع التجريبية
• KYC: أنواع مستندات قليلة بصيغ صارمة، مثل جوازات السفر وبطاقات الهوية، ما يجعل التحقق القائم على القواعد قويًا. ومطابقة صورة ذاتية (selfie) مع صورة المستند تضيف بيانات بيومترية، تُدرجها المادة 9 من GDPR أيضًا ضمن الفئات الخاصة حين تُعالَج لتحديد هوية شخص على نحو فريد. ويتبع الاحتفاظ قانون مكافحة غسل الأموال، وتغذّي النتيجة قرار امتثال يتخذه شخص أو قاعدة موثّقة

إبقاء المستندات بعيدًا عن مزوّد نماذج خارجي يحسمه مكان تشغيل النموذج. أما ما إذا كان خط المعالجة جديرًا بأن يُؤتمن عليها فيحسمه كل ما يحيط بالنموذج: المخطط، والقواعد، وطابور المراجعة، وسجل من أنتج كل حقل.

أي شركات الهندسة تبني هذا داخل بنيتك التحتية الخاصة؟

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

أيًّا كان النوع الذي تتحدث إليه، فهذه الأسئلة تُظهر ما إذا كان الفريق قد بنى هذا من قبل:

• أي المراحل تستدعي أي خدمة خارج شبكتك، بما في ذلك OCR والمراقبة وتتبّع الأخطاء وأداة الوسم؟
• كيف يبدو مخطط المخرجات لأحد أنواع مستنداتك، وكيف تُمثَّل قيمة «غير موجود»؟
• أي الإشارات ترسل حقلًا إلى المراجعة، وكيف اختيرت العتبات؟
• كيف تصل تصحيحات المراجعين إلى مجموعة التقييم دون أن تلوّث الجزء المستخدم في قرارات الإصدار؟
• هل يستطيعون أن يُظهروا، لحقل واحد في مستند واحد، النموذج والموجّه والمخطط والمراجِع الذين أنتجوا قيمته؟
• لمن تعود ملكية شيفرة خط المعالجة والمخططات ومجموعة التقييم عند انتهاء العمل، وأي الأجزاء تبقى من المكوّنات القابلة لإعادة الاستخدام الخاصة بالمورّد؟

الإجابة التي تبقى عامة عن السؤالين الأول والخامس تعني أن مسار البيانات ومسار التدقيق لم يُصمَّما بعد.

ما تستطيع amBrain قوله عن عملها في هذا المجال

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

تشرح هذه المقالة كيف يعمل خط معالجة كهذا؛ وهي ليست دراسة حالة، ولا تسمّي أي عملاء، ولا تدّعي أن amBrain بنت نظامًا للمطالبات أو التذاكر أو KYC. والعمل الإنتاجي المذكور أعلاه هو استخراج إشعارات الوسطاء ومنصات التداول لصالح نظام تداول.

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