دفتر الحسابات11 دقائق قراءة

لماذا لن يتسامح الذكاء الاصطناعي الوكيلي مع دفاتر الحسابات غير القابلة للتسلسل

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

44% من الفرق المالية نشرت ذكاءً اصطناعيًا وكيليًا في workflows إنتاجية بحلول 2026 (Forrester). أعلنت 50 بنكًا كبيرًا عن أكثر من 160 حالة استخدام للذكاء الاصطناعي في 2025. أصبح الوكلاء الآن يُبادرون بالمعاملات، ويعدّلون حدود المخاطر، ويُشغّلون workflows التسوية، ويتخذون قرارات الامتثال في بيئات الإنتاج. معظمهم يعملون ضد بنية تحتية صممت لأنماط معاملات بوتيرة بشرية وإرسال منفرد.

مشكلة التنفيذ مرة واحدة تحت الحمل الوكيلي

إنسان يُبادر بدفع عبر واجهة مستخدم ينشئ حدثًا واحدًا منفصلًا. هناك نية، وخطوة تأكيد، وإرسال واحد. الوكيل يعمل بشكل مختلف. يُعيد المحاولة عند انتهاء مهمة الشبكة دون معرفة ما إذا كانت الطلبة الأصلية قد نُفذت commit. يُشغّل workflows فرعية متزامنة تستهدف الحسابات نفسها. يتلقى إشارات غامضة: 408 Request Timeout أخفى write ناجحًا، 502 Bad Gateway أخفى تنفيذًا جزئيًا، 200 OK من بوابة API لم تصل إلى قاعدة البيانات.

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

عندما يتعطل الوكيل ويعيد التشغيل من نقطة checkpoint، قد يعيد تشغيل الأحداث بترتيب مختلف عن التنفيذ الأصلي. عندما يتنسق وكيلان على هدف مشترك عبر نافذة سياق مشتركة، قد يُبادر كلاهما بنفس المعاملة الأساسية بمفاتيح مولدة بشكل مستقل. عندما ينتهي workflow متعدد الخطوات عند الخطوة 3 من 5، قد لا يعرف الوكيل المستأنف أي الخطوات نُفذت commit وأيها لم يُنفذ.

المشكلة البنيوية الأعمق: التحقق من الاستقلالية وكتابة دفتر الحسابات ليست عمليتين متجاورتين. التسلسل هو تحقق ثم كتابة: التحقق من غياب المفتاح، ثم إدراج التحويل. بين الخطوة الأولى والخطوة الثانية، قد يكون وكيل آخر، أو thread آخر، أو إعادة محاولة أخرى قد كتبت تحويلًا لنفس العملية. تحت عزل READ COMMITTED، هذه الفترة غير مرئية. تحت REPEATABLE READ، قد يكون نتيجة التحقق قديمة بحلول وقت تنفيذ الكتابة. فقط SERIALIZABLE تغلق هذه الثغرة، و SERIALIZABLE تحت حمل وكيلي متزامن هو بالضبط النقطة التي تصل فيها قواعد البيانات العامة الأغراض إلى سقف التنافس.

حالات التنافس عند معدل إنتاجية الوكلاء

إنسان واحد يُرسل دفعة واحدة لكل تفاعل. وكيل يعالج 500 تعليمة في الثانية قد يُبادر بمئات المعاملات ضد حساب تسوية مشترك خلال نفس الثانية. عندما يُعيد 50 وكيلًا متزامنًا توازن مراكز الخزانة عبر 200 زوج عملات، يتضمن كل توازن تحويلات متعددة الأرجل عبر عدد صغير من الحسابات المجمعة: حساب التسوية EUR الذي تلمسه كل رجل EUR، وحساب التعليق للمقاصة الذي تلمسه كل عملية دفع صادرة.

PostgreSQL تُسلسل الكتابات على الصفوف المتنازع عليها. تحت عزل SERIALIZABLE، تضيف كشف التعارف حملًا إضافيًا: عندما تلمس معاملتان نفس الحساب في نوافذ متداخلة، تتلقى إحداهما ERROR: could not serialize access due to concurrent update ويجب أن تُعيد المحاولة. عند 50 وكيلًا متزامنًا يرسل كل منهم 10 معاملات في الثانية إلى حساب تسوية مشترك، تتجاوز نسبة إعادة المحاولة تحت التنافس 60% في غضون ثوانٍ. كل إعادة محاولة تستهلك رحلة ذهاب وإياب إلى قاعدة البيانات، وتحتفظ باتصال، وتتنافس مرة أخرى على نفس الصف.

التدهور ليس خطيًا. عند 50 TPS مع توزيع متساوٍ للحسابات، التنافس ضئيل. عند 500 TPS مقابل توزيع Zipfian للحسابات، حيث تستقبل أعلى 1% من الحسابات 30% من التحويلات، ينطبق قانون أمدال مباشرة: إذا كان 10% من الحمل العمل متأصلاً تسلسليًا بسبب تنافس الحسابات الساخنة، فإن أقصى تسريع نظري للتوازي هو 10x بغض النظر عن الأجهزة. إضافة المزيد من سعة تجمع الاتصالات تُفاقم التنافس: مزيد من الخيوط تتنافس على نفس قفل الصف.

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

ما توفره إزالة التكرار على مستوى البروتوكول

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

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

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

المعالجة الدفعية ونموذج الإنتاجية المعكوس

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

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

تحت الحمل الوكيلي المتزايد، يتحسن نموذج الإنتاجية: عدد أكبر من الوكلاء المتزامنين يعني دفعات أكثر امتلاءً. دفعات أكثر امتلاءً تعني استهلاكًا أفضل للحمل الثابت لكل دفعة (جولة الإجماع، تدفيق WAL، I/O التخزين). عند 1000 معاملة في الثانية يُبادرها وكلاء، المحرك أكثر كفاءة منه عند 100، لأن الدفعات تقترب من معامل ملئها الأقصى. العلاقة بين الحمل والإنتاجية أحادية الاتجاه حتى الحدود الفيزيائية لعرض نطاق الذاكرة وI/O القرص، وليست التدهور اللاخطي لنظام قائم على القفل.

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

متطلبات تتبع DORA المطبقة على الوكلاء

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

بالنسبة للأنظمة الوكيلية، يعني التتبع أن قرار الوكيل بإطلاق معاملة، والمعلمات التي استخدمها، ومسار التنفيذ عبر workflow، والنتيجة النهائية، يجب أن تكون كلها قابلة للاسترداد من معرف تدقيق واحد. سجلات التطبيقات المتناثرة عبر أطر عمل توجيه الوكلاء، ومحركات workflow، وجداول قواعد البيانات، لا تلبي هذا المتطلب إذا لم تكن قابلة للربط بمثيل معاملة واحد.

التنفيذ الدائم يوفر هذه الخاصية معماريًا. يُسجل كل خطوة في workflow في journal قبل التنفيذ. تحمل كل إدخال في journal معرف workflow، ورقم الخطوة، والمدخلات، والمخرجات، والتوقيت. يتلقى مدقق يتتبع دفعة أطلقها وكيل معرف workflow واحد ويمكنه إعادة بناء كل خطوة: تعليمة الوكيل، واستدعاء فحص AML، والخصم في دفتر الحسابات، وإرسال المقاصة، وأي تعويض تلاه. ليس لأن التسجيل أُضيف كفكرة لاحقة. نموذج التنفيذ يتطلب journal للعمل، والjournal هو سجل التدقيق.

المادة 5 من DORA تتطلب من الكيانات المالية إدارة مخاطر ICT عبر "جميع الوظائف التجارية المدعومة بـ ICT". عندما يصبح وكلاء الذكاء الاصطناعي أنظمة ICT تنفذ عمليات مالية، يجب تقييم وتوثيق أوضاع فشلها. الوضع الفاشل الأساسي لنظام وكيلي ضد دفتر حسابات غير قابل للتسلسل هو الحالة الجزئية: عملية متعددة الخطوات تُنفذ commit لبعض الخطوات وليس لأخرى دون مسار استرداد حتمي. تتراكم الحالة الجزئية بوتيرة أسرع من دورات المطابقة التي يمكنها تصريفها.

بُعد قانون الذكاء الاصطناعي في الاتحاد الأوروبي

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

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

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

المفاضلات

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

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

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

Fernel Context

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

المصادر:

Forrester، تحليل Post-Money20/20 Europe 2026، اعتماد الذكاء الاصطناعي الوكيلي في الخدمات المالية
Money20/20 Europe 2026، 50 بنكًا كبيرًا: 160+ حالة استخدام للذكاء الاصطناعي أُعلنت في 2025
DORA، اللائحة (EU) 2022/2554، المواد 5-6 (إدارة مخاطر ICT)، المواد 11-12 (الاستجابة، الاسترداد، التتبع)
قانون الاتحاد الأوروبي للذكاء الاصطناعي، اللائحة (EU) 2024/1689، الملحق الثالث (أنظمة الذكاء الاصطناعي عالية المخاطر في الخدمات المالية)، المادة 9 (نظام إدارة المخاطر)، المادة 11 (التوثيق التقني)
Amdahl، Gene M. "Validity of the single processor approach to achieving large scale computing capabilities." AFIPS '67، 1967
توثيق PostgreSQL: Serializable Isolation و Serializable Snapshot Isolation (SSI)، https://www.postgresql.org/docs/current/transaction-iso.html