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

تنسيق الوكلاء المتعددين في التمويل، ومتى ينبغي تجنّبه

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

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

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

معظم العروض التوضيحية للوكلاء المتعددين تحلّ مشكلةً اخترعها العرض نفسه. “باحث” يسلّم إلى “كاتب” يسلّم إلى “ناقد”، فيبدو كلّ شيء منظّماً. لكنّ حالات الفشل المثيرة في نظام مالي حقيقي نادراً ما تحدث داخل الوكيل الواحد؛ بل تحدث عند الوصلة (seam) بين وكيلين، حيث يُقرَّب رقمٌ في صمت، أو يُبلَّغ عن اكتمال عملٍ لم يُنجَز قطّ. تلك الوصلة هي ما تصمّمه فعلياً حين تختار التنسيق.

ما الذي يجب أن تحمله عملية التسليم

عملية التسليم بين الوكلاء عقدُ بيانات (data contract)، والتمويل لا يتسامح مع عقود البيانات. حين يمرّر وكيلٌ عملاً إلى آخر، يحتاج الطرف المستقبِل إلى ما يكفي ليكون صحيحاً بذاته. فقرة نثرية تلخّص الحالة لا تفي بذلك؛ الوكيل المستقبِل يحتاج إلى الحالة نفسها.

في مهمّة تسوية، يعني ذلك أن يتلقّى الوكيل المستقبِل سطور دفتر الأستاذ، والنظام المصدر لكلّ سطر منها، وطابع “بتاريخ” الزمني (as-of timestamp)، والهوامش (tolerances) المطبَّقة سلفاً. وفي حساب انكشافٍ (exposure)، يتلقّى المراكز مع تسعيراتها في لحظتها المحدّدة (point-in-time marks)، لا تسعيرات صادف أن جلبها الوكيل السابق في ثانيةٍ مختلفة. فإذا كانت عملية التسليم نثراً، فقد أدخلت خطوة ضغطٍ فاقدة (lossy compression) بين نظامين كلاهما احتاج إلى الأرقام الدقيقة نفسها.

لذا فإنّ أوّل اختبارٍ نجريه على أيّ فصلٍ مقترح مملٌّ في ظاهره: هل يمكن أن تكون عملية التسليم مُنتَجاً (artifact) ذا نوع محدّد مستعدّاً لتخزينه وإعادة تشغيله؟ إن كان الجواب نعم، فالحدّ الفاصل غالباً حقيقي. أمّا إذا كان الشيء الوحيد العابر للحدّ ملخّصاً سيعيد الوكيل التالي تفسيره، فقد أضفت موضعاً تنجرف فيه الأرقام في صمت دون أن تضيف أيّ قدرة. اطوِ ذلك الحدّ.

أين يؤتي الفصل ثماره حقّاً

ثمّة حدود قليلة يستحقّ عندها الوكلاء المنفصلون كلفتهم، وهي تميل إلى مشاركة خاصّيّة واحدة: للطرفين سلطةٌ مختلفة أو أنماط فشلٍ مختلفة.

  • صلاحيات أدوات مختلفة. وكيلٌ يُعِدّ المسوّدات ويقرأ من مستودع البيانات، ووكيلٌ يرحّل القيود (journal entries) ويكتب، لا ينبغي أن يكونا الفاعل نفسه. فصلهما يتيح لك تضييق نطاق بيانات الاعتماد (credentials)، ووضع بوّابة بشرية أو قواعديّة على مسار الكتابة. هذا هو التفويض (authorization) مُعبَّراً عنه بوصفه معماريّة.
  • احتياجات سياق مختلفة. استبانة الكيانات (entity resolution) عبر قائمة أطرافٍ مقابلة فوضوية مهمّة قائمة بذاتها ولها بياناتها المرجعية. وعزلها يُبقي مئة ألف رمز (token) من جداول الأسماء البديلة خارج نافذة الوكيل الذي لا يحتاج سوى المعرّفات (IDs) بعد استبانتها.
  • مجموعات تقييم مختلفة. مصنِّفٌ يرفع المعاملات للمراجعة، ومُلخِّصٌ يشرح سبب الرفع، لكلٍّ منهما معيار جودةٍ منفصل. تقيس الأوّل مقابل ميزانية للنتائج الإيجابية الكاذبة (false-positive budget)، وتقيس الثاني مقابل الدقّة الوقائعيّة. إبقاؤهما منفصلين يتيح لكلٍّ منهما مجموعة تقييمه الخاصّة ورصد انحرافه (drift) الخاصّ، بدلاً من مقياسٍ ممزوجٍ واحد يخفي الاثنين معاً.
  • عملٌ متوازٍ حقيقيّ. جلب إفصاحات (filings) أربعين شركة محفظة عند نهاية الربع عملٌ متوازٍ إلى حدٍّ محرج. توزيعه على وكلاء عاملين قرارٌ يخصّ الإنتاجية (throughput)، لا الذكاء، ولا بأس به ما دامت خطوة التجميع (fan-in) تسوّي ما عاد من نتائج.

لاحظ ما ليس على تلك القائمة: “المهمّة معقّدة”. فالتعقيد وحده حجّةٌ لأدواتٍ أفضل وسياقٍ أطول، لا لمزيدٍ من الوكلاء. حلقة مخطِّط–منفِّذ (planner-executor) واحدة تتولّى قدراً كبيراً من العمل المالي، لأنّ الخطة عادةً قصيرة ويمكنك قراءتها قبل أن يُنفَّذ أيّ شيء.

أين تكون الحلقة الواحدة أكثر أماناً

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

في سياقٍ مالي يظهر ذلك على هيئة قيمٍ وسيطة مُلفَّقة. يقرّر المخطِّط أنّ الخطوة الثالثة هي “التعديل مقابل استبعادات المعاملات البينيّة (intercompany eliminations)”، ولا توجد أداة تُجري ذلك التعديل فعلاً، فينتج المنفِّذ رقماً يبدو تعديلاً لكنّه تخمين. لا شيء يُبلِّغ عن خطأ. ويسجّل أثر التدقيق (audit trail) خطوةً مكتملة. وتكتشف الأمر عند نهاية الربع، إن اكتشفته أصلاً.

لهذا السبب نُبقي على وكيلٍ واحد وحلقةٍ واحدة، حين:

  • يكون العمل حُكماً متماسكاً واحداً لا ينبغي تقطيعه إلى خطواتٍ يبدو كلّ منها مُبرَّراً بمعزلٍ عن غيره. فتقييم الائتمان يستدلّ على الصورة كاملة؛ وتجزئته تُغري بأن يكون كلّ جزءٍ معقولاً محلّيّاً وخاطئاً في مجموعه.
  • يكون تتبّع النَّسَب (lineage) أهمّ من الإنتاجية. فاعلٌ واحد بسجلّ أدواتٍ واحد أسهل بكثير في إعادة البناء من شجرة وكلاء عليك رتق تفاعلاتها لاحقاً.
  • تكون كلفة النتيجة الإيجابية الكاذبة عالية وزمن الاستجابة (latency) ليس هو القيد. فالتنسيق بين الوكلاء يضيف سطح فشلٍ خاصّاً به، وفي قرارٍ يخصّ الامتثال لا يستحقّ ذلك السطح ثوانيَ معدودة موفَّرة.

الخيار الافتراضي الصادق هو وكيلٌ واحد بمجموعة أدواتٍ محكمة التصميم ومخطّط (schema) صارم على مخرجات كلّ أداة. والجأ إلى التنسيق حين تصطدم بجدارٍ لا تستطيع أدواتٌ إضافية تسلّقه: حدّ صلاحيات يجب أن تفرضه، أو سياقٌ لا يتّسع لديك، أو توازٍ تريد استغلاله.

البناء من أجل الوصلة

إن قرّرت الفصل، فصمّم الوصلة أوّلاً. امنح كلّ عملية تسليم إصداراً ومخطّطاً (schema) ومُدقِّقاً (validator) يرفض المُنتَجات المشوّهة أو الخارجة عن الهامش قبل أن يلمسها الوكيل التالي. واجعل قرارات المنسِّق (orchestrator) نفسها إجراءات مُسجَّلة، بحيث يكون “الوكيل أ اختار التوجيه إلى الوكيل ج” سِجلّاً يمكنك إعادة تشغيله، لا سلوكاً ناشئاً تعيد تركيبه من الطوابع الزمنية.

أبقِ البنية (topology) مسطّحة. فالسلاسل العميقة من الوكلاء الذين يستدعون وكلاء آخرين تُراكم مشكلتين معاً: زمن استجابةٍ يمكنك قياسه، وانتشار خطأ لا تستطيع قياسه، لأنّ تشوّهاً صغيراً في القمّة يُعامَل بوصفه حقيقةً راسخة على طول الطريق نزولاً. رسمٌ بيانيّ ضحل بعقودٍ قويّة عند كلّ حافّة يتفوّق على تراتُبيّةٍ بارعة في كلّ مرّةٍ تقريباً.

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

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

متى يستفيد سير العمل المالي فعلياً من وجود وكلاء متعددين؟

عندما تحتاج مهمّتان فرعيّتان إلى أدوات أو صلاحيات أو نوافذ سياق (context windows) مختلفة اختلافاً حقيقياً، وعندما يمكن التعبير عن عملية التسليم بينهما بوصفها مُنتَجاً (artifact) ذا نوع محدّد يمكنك التحقّق منه. أمّا إذا كان الفصل شكليّاً فحسب، فإنّ حلقة واحدة مزوّدة بمزيدٍ من الأدوات تكون أقلّ كلفةً وأسهل في التدقيق.

كيف تحافظ على قابلية مخرجات الوكلاء المتعددين للتدقيق؟

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

ما نمط المخطِّط–المنفِّذ (planner-executor) وأين يناسب استخدامه؟

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

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

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

أين يصلح الذكاء الاصطناعي الوكيل في القطاع المالي، وأين لا يصلح

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

#الوكلاء

حوكمة استخدام الأدوات من قِبَل الوكلاء في سير العمل المالي

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

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

بنية مرجعية لأنظمة الذكاء الاصطناعي في التمويل

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

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

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

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

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

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

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