يمكن لوكيلين من وكلاء الذكاء الاصطناعي تعديل الملف نفسه، ويتلقى كلاهما إشعار "نجاح"، ومع ذلك تنجو عملية تغيير واحدة فقط. في اختبار بسيط مع خمسة وكلاء متزامنين، اختفت أربع من أصل خمس عمليات كتابة دون أي خطأ أو إدخال في السجل — وهو "شذوذ التحديث المفقود" (lost-update anomaly) الكلاسيكي الذي يهدر التوكنز المدفوعة مقابل العمل الذي تلاشى.
لماذا تهم هذه المشكلة
عندما يكتب وكيل الذكاء الاصطناعي نتيجة ما، تفرض الخدمة الأساسية رسومًا لكل توكن يتم إنشاؤه. إذا تم تجاوز الكتابة بصمت، فإن المزود لا يزال يفوتر الحوسبة التي أنتجت المخرجات المهملة. في مسارات العمل متعددة الوكلاء — مثل أسراب الوكلاء (agent swarms)، أو عمال تنظيف البيانات المتوازيين، أو أي نظام يتشارك فيه عدة بوتات ملف خطة أو مسودة — يمكن أن تتضخم هذه الخسائر الخفية لتصبح تسربًا كبيرًا في التكاليف. كما يهدد هذا الشذوذ سلامة البيانات: فقد تتصرف الخطوات اللاحقة بناءً على معلومات غير كاملة أو قديمة، مما يؤدي إلى أخطاء متتالية.
كيف يحدث هذا الشذوذ
السبب الجذري هو "حالة التسابق" (race condition):
- يقرأ وكيلان (أو أكثر) نفس الإصدار من مورد ما، مثل ملف خطة JSON.
- يقوم كل منهما بعملية الاستنتاج أو التحويل الخاصة به بناءً على تلك اللقطة (snapshot).
- يصدر كلا الوكيلين عملية كتابة إلى التخزين المشترك.
- يقبل نظام التخزين عملية الكتابة الثانية، مما يؤدي إلى تجاوز الأولى دون أي اكتشاف للتعارض.
- يتلقى كلا الوكيلين إشعار "ACK" يؤكد نجاح الكتابة، على الرغم من اختفاء المساهمة الأولى.
إشعار نظام التخزين يثبت فقط حدوث عملية كتابة؛ ولا يضمن أن الكتابة كانت آمنة بالنسبة للتحديثات المتزامنة الأخرى. كما يتصرف "سجل الإضافة فقط" (append-only log)، الذي غالبًا ما يُروج له كوسيلة حماية، بنفس الطريقة: فهو يسجل حدوث الكتابة ولكنه لا يمنع عمليات الكتابة اللاحقة من محو العمليات السابقة.
ماذا تفعل بوابة المقارنة والضبط (CAS)
تضيف بوابة "المقارنة والضبط" (compare-and-set - CAS) فحصًا للإصدار قبل قبول الكتابة:
- القراءة (Read): يجلب الوكيل رقم الإصدار الحالي (أو الـ hash) للملف.
- الحوسبة (Compute): يقوم الوكيل بعمله، منتجًا إصدارًا جديدًا من الملف.
- الكتابة (Write): يرسل الوكيل المحتوى الجديد مع الإصدار الذي قرأه في الأصل.
- التحقق (Validate): تقارن طبقة التخزين الإصدار المقدم بالإصدار الحالي. إذا اختلفا، تُرفض الكتابة؛ وإلا، تستمر العملية ويتم زيادة رقم الإصدار.
إذا تغير الإصدار، يدرك الوكيل أن رؤيته كانت قديمة ويجب عليه إعادة المحاولة في الدورة الكاملة — القراءة، الحوسبة، الكتابة — باستخدام الإصدار الجديد. هذا يحول عملية التجاوز غير المرئية إلى فشل صريح يمكن تسجيله، وإعادة محاولته، ومحاسبته.
ثمن الأمان
بوابة CAS ليست مجانية. في نفس محاكاة الوكلاء الخمسة:
| السيناريو | عمليات الكتابة المحاولة | المساهمات الناجحة | تكلفة التوكنز |
|---|---|---|---|
| بدون بوابة CAS | 5 | 1 | 5 وحدات |
| مع بوابة CAS | 5 | 5 (بعد إعادة المحاولة) | 9 وحدات |
تضيف البوابة دورات إضافية من (القراءة-الحوسبة-الكتابة) للوكلاء الذين يواجهون تعارضًا في الإصدار، مما يرفع استهلاك التوكنز. المقايضة واضحة: بدون البوابة ستفقد البيانات بصمت؛ ومع البوابة ستدفع علاوة متواضعة ولكنك ستكتسب رؤية واضحة لكل تعارض.
ما مدى شيوع هذا الفشل؟
حتى مع وجود وكيلين فقط، أظهر الاختبار احتمالاً بنسبة 75% لفقدان إحدى عمليات الكتابة. ومع خمسة وكلاء، اقترب معدل الفقد من 100%. تشير هذه الأرقام إلى أن افتراض أن الأمور "تسير بشكل جيد عادةً" هو افتراض خطير لأي سير عمل متعدد الوكلاء على مستوى الإنتاج.
حجة مضادة: متى يمكن تجاوز البوابة
إذا كان النظام يشغل وكيلًا واحدًا لكل مورد أو يفرض تسلسلاً صارمًا (strict serialisation) على مستوى أعلى، فقد تكون فحوصات CAS الإضافية غير ضرورية. ومع ذلك، يجب أن تتضمن حسابات المخاطر التكلفة الخفية لإعادة تشغيل العمل الفاشل والتأثير المحتمل لفقدان البيانات على الخطوات اللاحقة.
ما الذي يجب مراقبته لاحقًا
- دعم الأدوات (Tooling support): ابحث عن واجهات برمجة تطبيقات التخزين (storage APIs) التي توفر أرقام الإصدارات أو ETags وتوفر عمليات CAS ذرية (atomic) بشكل مباشر.
- المقاييس (Metrics): قم بتزويد وكلاءك بالأدوات اللازمة لتسجيل عدد المرات التي تُرفض فيها الكتابة بسبب عدم تطابق الإصدار. يشير ارتفاع معدل التعارض إلى حاجتك لتوسيع الموارد أو إعادة تصميم سير العمل.
- استراتيجيات إعادة المحاولة (Retry strategies): يعمل أسلوب "التراجع الأسي" (exponential back-off) البسيط بشكل جيد، ولكن كن على دراية بأن تكرار المحاولات يزيد من استهلاك التوكنز. وازن بين حدود إعادة المحاولة وفقدان البيانات المقبول.
- النهج الهجينة (Hybrid approaches): تدمج بعض الفرق بين "سجل الإضافة فقط" (append-only log) لأغراض التدقيق وبوابة CAS لضمان الاتساق، مما يضمن وجود سجل لما حدث وحماية ضد عمليات التجاوز.
الخلاصة
تحول حالات "التحديث المفقود" (lost-update anomalies) خطوط أنابيب الذكاء الاصطناعي المعتمدة على الرموز (tokens) إلى ثقوب سوداء تستنزف الأموال. وتضيف بوابة إصدار تعتمد على آلية "المقارنة والضبط" (compare-and-set) عبئًا طفيفًا من الرموز، لكنها تحول فقدان البيانات الصامت إلى حدث مرئي وقابل لإعادة المحاولة. وفي أي نظام يتشارك فيه وكلاء متعددون الحالة — سواء كانت قواعد بيانات، أو ملفات خطط، أو مساحات عمل مؤقتة (scratchpads) — فإن تضمين فحص للإصدار قبل عمليات الكتابة يعد أرخص وسيلة تأمين ضد التكاليف الخفية وسير العمل الفاسد.