تخطّ إلى المحتوى
كل الرؤى بنية الذكاء الاصطناعي للقطاع المالي

أنماط التحقق من مخرجات الذكاء الاصطناعي في المالية

الإجابة الخاطئة الواثقة هي وضع الفشل الذي يهمّ فعلاً. إليك طبقات المخطط والقيود والتحقق التي نضعها بين النموذج وسير العمل المالي.

متخصصون في القطاع المالي يعملون على مبادرة للذكاء الاصطناعي

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

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

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

المخطط الصارم هو الأرضية

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

هناك طريقتان للحصول على الشكل الصحيح، وهما ليستا متبادلتين:

  • فك التشفير المقيّد (constrained decoding) يجبر النموذج على إصدار الرموز التي تسمح بها القواعد النحوية فقط، بحيث لا يستطيع حقل التعداد أن يُنتج فيزيائياً سوى أحد أعضائه، ويطابق معرّف الحساب نمطه لحظة التوليد. إنه الأداة المناسبة للمفردات الثابتة والصيغ الجامدة.
  • التحقق اللاحق (post-hoc validation) يدع النموذج يولّد بحرية، ثم يرفض ويصلح أي شيء يفشل في اجتياز المخطط. إنه الأداة المناسبة لأي شيء طويل أو مفتوح، حيث تصارع القواعد النحوية النموذج وتكلّفك زمن استجابة مقابل مكسب ضئيل.

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

ما لن يفعله المخطط أبداً هو أن يخبرك بأن الرقم صحيح. يمكن للنموذج أن يعيد {"exposure": 4200000, "currency": "EUR"} بحيث يستوفي كل قيد، ويكون مبتعداً عن الصواب بعامل عشرة لأنه قرأ الصف الخطأ. يمرّر التحقق من المخطط ذلك دون اعتراض. فالأرضية مهمة، لكنها مجرد أرضية.

طبقة التحقق تقوم بالعمل الحقيقي

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

  • ثبّت كل رقم في مصدره. إذا أبلغ النموذج عن رصيد أو عتبة تعهّد (covenant threshold) أو انكشاف تجاه طرف مقابل، فيجب أن تتتبّع تلك القيمة إلى سجل مصدر. أرفق السلسلة المرجعية (lineage). وإذا تعذّر تتبعها، فإنها لا تُشحَن.
  • طابِق عبر المصادر. حين تُبلغ ثلاثة أنظمة عن رقم بثلاث طرق، تُظهر خطوة التحقق التناقض بدلاً من أن تترك النموذج يختار أحدها بصمت. المطابقة (reconciliation) ترفع التعارض ليحلّه إنسان؛ وهي لا تخمّن أبداً.
  • أعِد حساب أي شيء قابل للاشتقاق. النِّسَب والمجاميع والمتوسطات المرجّحة وحساب التواريخ ينبغي حسابها بالشيفرة من المدخلات المثبَّتة، لا الوثوق بها من حساب النموذج نفسه. النماذج آلات حاسبة غير موثوقة، ولا يوجد سبب للسماح لها بإجراء جمع يمكنك إجراؤه بشكل حتمي.
  • افرض الصحة الزمنية اللحظية (point-in-time correctness). الرقم المرتبط بتاريخ إبلاغ يجب أن يأتي من البيانات كما كانت في ذلك التاريخ. هنا يتسلل الاستشراف (lookahead): يسحب النموذج بارتياح رقماً مُعاد بيانه أو قيمة تلي تاريخ القطع، ويبدو المخرَج سليماً حتى يسأل مدقّق عن سبب استشهاد مذكرة للربع الثاني برقم لم يوجد إلا في الربع الثالث.

طبقة التحقق هي شيفرة حتمية تجلس أسفل النموذج في مجرى المعالجة. إنها تعرف أن المخطط قد استُوفي أصلاً، فتستطيع افتراض البنية والتركيز كلياً على الصدق. حين يفشل فحص، يُوجَّه العنصر إلى طابور بشري مع إرفاق الفحص الفاشل وقيم المصدر المتعارضة. وهي لا تعيد المحاولة بصمت، لأن إعادة المحاولة الصامتة التي تنجح في النهاية هي الطريق الذي يصل به رقم خاطئ إلى المعالجة المباشرة الكاملة (straight-through processing).

قيود تُرمّز قواعد عملك

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

أمثلة تتكرر باستمرار:

  • الاتساق عبر الحقول. المعاملة المصنّفة على أنها محلية لا يمكن أن تحمل عملة تسوية أجنبية دون تعبئة حقل تفسير. تصنيف مخاطرة “منخفض” يتعارض مع انكشاف يتجاوز سقفاً محدداً.
  • الحدود والمعقولية. احتمال خارج المجال بين صفر وواحد، عدد موظفين سالب، سعر فائدة فوق نطاق معقول. رخيصة الفحص، وهي تمسك النموذج حين يختلق بثقة.
  • سلامة المرجعية (referential integrity). كل كيان يذكره المخرَج يجب أن يُحلّ إلى سجل حقيقي. إخفاقات حلّ الكيانات (entity resolution) مصدر شائع وصامت للمخرجات الخاطئة، لأن النموذج يخترع اسم طرف مقابل معقولاً لا وجود له في سجلاتك.

رمّز هذه بوصفها مسنَدات (predicates) صريحة، وأخضِعها لإصدارات، واحتفظ بها بجوار مجموعة التقييم (eval set). حين يسأل جهة تنظيمية أو مراجع داخلي عن سبب قبول مخرَج، يكون الجواب هو قائمة الفحوص التي اجتازها، وكل واحد منها قابل للتدقيق. بموجب SR 11-7، هذه القابلية للتتبع ليست ترفاً؛ فالنموذج الواقع في مسار قرار يجب أن يكون قابلاً للتفسير وخاضعاً للمراقبة، ومجموعة التحقق جزء كبير من طريقة إثبات ذلك.

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

الأسئلة الشائعة

هل يمنع التحقق من مخطط JSON النموذج من هلوسة الأرقام؟

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

هل يستحق فك التشفير المقيّد (constrained decoding) كلفته في زمن الاستجابة؟

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

إلى أين ينبغي أن يُوجَّه التحقق الفاشل في سير عمل مالي؟

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

قراءات ذات صلة

#البنية المعمارية

كيف نجعل مُخرجات نماذج LLM آمنة كي تتغذى منها الأنظمة المالية

رقمٌ بصيغة نصٍّ حرّ خارجٌ من نموذج لا ينبغي أن يتدفّق مباشرةً إلى دفتر الأستاذ. هذه هي المنهجية التي نتّبعها لجعل مُخرجات LLM موثوقةً بما يكفي للتصرّف بناءً عليها.

#البنية المعمارية

حين يكون المستند هو المهاجم: تأمين RAG في القطاع المالي

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

#مكافحة غسل الأموال

صياغة سرديات تقارير الأنشطة المشبوهة (SAR) بنماذج اللغة، بأمان

سردية تقرير النشاط المشبوه وثيقة قانونية، لا إجابة روبوت محادثة. وفي ما يلي كيف نولّد مسودات تقارير مؤسَّسة على الأدلة وقابلة للمراجعة، تستشهد بمصادرها.

#الاستضافة

داخل الشركة أو VPC أو API: استضافة الذكاء الاصطناعي في التمويل الخاضع للتنظيم

المكان الذي يعمل فيه النموذج قرارٌ يخصّ الامتثال بقدر ما يخصّ التقنية. إليك كيف نوازن بين واجهات API والـ VPC والنماذج المستضافة ذاتيًا لبيانات التمويل الخاضع للتنظيم.

تعمل على شيء مشابه؟

أخبِرنا عن بياناتك وسير العمل المحيط بها، وسنعطيك رأياً صريحاً.

احجز مكالمة تعريفية مدتها 30 دقيقة