لماذا تنسى وكلاء الذكاء الاصطناعي المنزلية الإجراءات المكتملة بعد إعادة تشغيل الخدمة؟

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

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

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

سجل المحادثة ليس حالة سير عمل دائمة

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

يفصل دليل Augment Code حول حالة سير العمل المستمرة التنفيذ طويل الأمد عن عملية واحدة أو طلب متزامن.

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

تحتاج استدعاءات الأدوات المكتملة إلى حد تثبيت دائم

قد تنجح الأداة خارجيًا قبل أن يكتب الوكيل علامة الإكمال المحلية. وتؤدي إعادة التشغيل خلال هذه الفجوة إلى بقاء الإجراء قائمًا بينما يجهله الوكيل.

يصف Zylos حدود التنفيذ الدائم التي تحافظ على العمل المكتمل قبل مواصلة التعافي.

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

عندما يتعذر التثبيت الذري، يجب أن تتيح الأداة البحث عن الحالة حتى يتمكن الوكيل الذي أعيد تشغيله من تسوية النتائج غير المؤكدة.

قد لا تكفي نقطة التحقق وحدها لإعادة بناء تنفيذ آمن

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

يميز Diagrid بين نقاط تحقق التطبيق وبيئات التشغيل التي تتولى إعادة المحاولات وسجل الأحداث وإكمال التأثيرات الجانبية.

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

وإلا فقد تستأنف نقطة تحقق صحيحة التنفيذ برسالة مكررة أو نقل ملف متكرر أو أمر ثانٍ إلى جهاز.

تمنع هويات التشغيل والخطوة المستقرة بدء مهمة جديدة عن طريق الخطأ

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

يوضح Inference.sh كيف تتيح هوية التشغيل الدائمة للوكيل الاستئناف من أحدث نقطة تحقق مكتملة.

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

ينبغي إعادة استخدام الخطوات المكتملة بدلًا من إعادة التفكير فيها

قد تؤدي إعادة تشغيل استدعاءات النموذج السابقة إلى خطة مختلفة أو وسيطات أدوات مختلفة أو تفسير مختلف للعمل المكتمل.

تذكر مقالة Pydantic حول بيئة التشغيل أن نقاط التحقق المكتملة تظل مكتملة، بينما يعيد التعافي تشغيل الحد الفاشل فقط.

يقلل ذلك تكلفة الرموز ويمنع الوكيل الذي أعيد تشغيله من اختراع مسار ثانٍ عبر أنظمة المنزل التي عُدّلت بالفعل.

ينبغي أن تتضمن النتائج المخزنة أدلة كافية للتحقق من أن مخرجات الأداة ما زالت تتوافق مع الحالة الحالية للهدف.

تحمي قابلية التكرار والتسوية التعافي من التأثيرات المكررة

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

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

توضح مقالة ZimaSpace حول الأتمتة الآمنة عند التكرار لماذا تكون الحالة النهائية المقصودة أكثر أمانًا من إعادة تشغيل الأوامر الإضافية بشكل أعمى.

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

يجب أن تشمل اختبارات إعادة التشغيل كل نوافذ الفشل

أوقف الخدمة قسرًا قبل استدعاء الأداة وأثناءه وبعد التأثير الخارجي وبعد نقطة التحقق المحلية وأثناء انتظار الموافقة. ويجب أن تؤدي كل إعادة تشغيل إلى استمرارية متوقعة واحدة.

يصف DBOS التنفيذ المقاوم للأعطال لسير العمل الذي يتضمن واجهات برمجة التطبيقات والتفاعل البشري.

راجع ما إذا كانت الإجراءات المكتملة تُعاد الاستفادة منها، والإجراءات غير المؤكدة تُسوّى، والإجراءات المعلّقة تبقى معلّقة، ولا يُعاد إنشاء أي تفويض دون إشعار.

لا يتذكر الوكيل العمل المكتمل إلا عندما يُخزّن التقدم بوصفه دليلًا تشغيليًا دائمًا، لا مجرد نص احتفظت به العملية القديمة بالمصادفة.

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

هل يكفي حفظ نص المحادثة؟

لا. فقد يغفل النص معرّفات العمليات والتأثيرات الجانبية المثبتة وحالة إعادة المحاولة والموافقات والحد الدقيق الذي ينبغي أن يُستأنف التنفيذ منه.

هل ينبغي للوكيل إعادة تشغيل كل استدعاء أداة بعد إعادة التشغيل؟

لا. ينبغي إعادة استخدام الاستدعاءات المكتملة من السجل الدائم، بينما تتطلب الاستدعاءات غير المؤكدة قابلية للتكرار أو التسوية قبل أي إعادة محاولة.

هل يمكن لنقطة تحقق في قاعدة البيانات أن تمنع كل إجراء مكرر؟

لا. يجب تنسيقها مع التأثير الجانبي الخارجي. فحدوث عطل بين التأثير ونقطة التحقق يؤدي إلى نتيجة غير مؤكدة.

مركز التكنولوجيا والذكاء الاصطناعي

المزيد للقراءة

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.