عندما تقوم بربط نموذج لغوي كبير (LLM) بسير عمل (workflow) يتطلب موافقة بشرية عبر البريد الإلكتروني، فمن النادر أن يكون النموذج هو سبب الخلل. بل يحدث الخلل عند النقطة التي ينتهي عندها الكود ويبدأ عندها صندوق الوارد. عملية تشغيل ذاتية واحدة ترسل طلباً، ثم تبدأ عملية تشغيل أخرى قبل أن تنتهي الأولى. يجمع صندوق وارد مشترك سلاسل الرسائل من عمليات مختلفة. يضغط شخص ما على "موافقة" على رسالة وصلت متأخرة باثنتي عشرة ساعة. الآن لديك مخرجات، ولديك قرار، ولكن لا يمكنك إثبات أي عملية تشغيل أنتجت ماذا، أو ما إذا كانت الموافقة مخصصة لهذا الإصدار أصلاً. لقد قمت بتنظيف ما يكفي من خطوط الأتمتة الداخلية لأعرف هذا النمط؛ فهو يتصاعد من مجرد ارتباك إلى حادث تقني أسرع مما تتوقعه معظم الفرق.
الحدود التشغيلية
الحدود بين المنسق (orchestrator) ومزود البريد الإلكتروني الخاص بك ليست مجرد قفزة شبكية، بل هي حدود للحالة (state boundary). عندما ينتهي النموذج اللغوي الكبير من إنشاء مسودة، تظل عملية التشغيل قائمة، فهي في حالة انتظار. إذا كان نظامك يعامل عملية الإرسال كحدث "أرسل وانْسَ" (fire-and-forget)، فقد فقدت السيطرة بالفعل.
لقد رأيت خطوط أنابيب (pipelines) حيث تولد عملية تشغيل واحدة طلبَي موافقة منفصلين لأن سياسة إعادة المحاولة كانت عدوانية للغاية. ورأيت عملية تشغيل أخرى تعيد استخدام صندوق بريد لا يزال يحتوي على رسائل من الأسبوع الماضي. المعتمد البشري لا يرى معرفات عمليات التشغيل (run IDs)، بل يرى سطر موضوع وزرّاً. وبدون هيكلية، سيكون في حالة تخمين داخل نفس صندوق الوارد الذي توجد فيه النشرات الإخبارية التسويقية وتنبيهات المراقبة.
الخطوة المهملة
تقضي الفرق أسابيع في ضبط الأوامر (prompts)، وإضافة حواجز الحماية (guardrails)، وقياس أداء المخرجات. ثم يقومون بربط خطوة الموافقة بقناة Slack أو صندوق دعم مشترك ويعتبرون المهمة قد انتهت. يؤدي هذا إلى ثلاث مشكلات متوقعة:
- يتحول صندوق الوارد المشترك إلى مكب للأحداث القادمة من عمليات تشغيل متعددة، مما يؤدي إلى انهيار السياق. لا يمكنك إعادة بناء أي رسالة تنتمي إلى أي معاملة تجارية دون فتح سلاسل الرسائل وتحليل الطوابع الزمنية يدوياً.
- تؤدي عمليات إعادة المحاولة إلى الكتابة فوق الأدلة. إذا أعادت عملية تشغيل إرسال طلب الموافقة، فقد تُدفن الرسالة الأصلية، أو تُحذف، أو تُصنف كرسالة مكررة بواسطة عميل بريد إلكتروني مفرط النشاط. وبذلك يتآكل مسار التدقيق (audit trail).
- تطفو القرارات البشرية خارج النظام. يرد شخص ما بكلمة "يبدو جيداً" في تذكرة أو رسالة مباشرة، لكن هذا الشعور لا يتحول أبداً إلى بيانات مهيكلة داخل سير العمل. لا يملك الوكيل (agent) أي وسيلة للتحقق من هوية من قال ماذا، أو متى.
عندما يحدث خطأ ما وتحتاج إلى التحقيق، فإنك تحصل على مجرد أقاويل: "أعتقد أن ذلك كان البريد الإلكتروني الصحيح". الذاكرة ليست وسيلة للتتبع، وسجل التدقيق لا يمكنه استيعاب التخمينات.
من تفصيل تسليم إلى نقطة تفتيش
يتطلب إصلاح هذا الأمر تحولاً في التصميم. توقف عن التفكير في البريد الإلكتروني كأداة تسليم، وابدأ في معاملته كنقطة تفتيش للنظام (system checkpoint). وهذا يعني أن كل رسالة هي انتقال في الحالة (state transition)، وكل انتقال في الحالة يحتاج إلى هوية، وتفويض، وأدلة.
عندما تتبنى هذه العقلية، تتغير الأسئلة. تتوقف عن السؤال عما إذا كان البريد الإلكتروني قد أُرسل بنجاح، وتبدأ في السؤال عن أي عملية تشغيل أرسلته، وما هي الأدلة التي تركها وراءه، وما هي القاعدة التي فوضت سير العمل بالاستمرار. يمكن للوكيل بكل تأكيد كتابة نص البريد الإلكتروني، ولكن يجب على منصتك فرض مسارات الهوية والتحقق. النموذج اللغوي الكبير هو الكاتب، والبنية التحتية هي الموثق.
تصميم أدنى
لا تحتاج إلى ثروة لبناء هذا. تعتمد نسختي الدنيا القابلة للتطبيق على خمس قطع مدروسة:
- يقوم المنسق بإنشاء
run_idفي اللحظة الدقيقة التي يبدأ فيها سير العمل. هذا المعرف هو العمود الفقري لكل إجراء لاحق، وهو لا يتغير أبداً ولا يُعاد استخدامه. - تحمل كل عملية بريد إلكتروني ثلاثة حقول: الـ
run_id، وتسميةmessage_typeمثل "approval_request" أو "evidence_notification"، وسلسلةpolicy_versionالتي تحدد قواعد الحوكمة النشطة. هذا يحول الرسالة العادية إلى حدث محدد النوع (typed event). - تبقى الأدلة في صندوق وارد معزول حسب عملية التشغيل. لا يعني هذا دائماً وجود حساب بريد إلكتروني منفصل لكل عملية تشغيل، بل يمكن أن يعني تسمية مخصصة (label)، أو مجلداً فرعياً، أو قاعدة توجيه تقسم سلاسل الرسائل بحيث لا تتداخل مراسلات عملية تشغيل واحدة مع أخرى.
- يجب أن يكون رد الموافقة حدثاً مهيكلاً، وليس مجرد نص حر مثل "ok". لا يزال الإنسان ينقر أو يرد، ولكن النظام يترجم هذا الإجراء إلى حمولة (payload) قابلة للقراءة آلياً تحدد الـ
run_idوالقرار والطابع الزمني. - يستمر التدفق فقط إذا تطابقت الأدلة مع القرار. لا يثق سير العمل بالموافقة بشكل منعزل، بل يتحقق من حمولة الموافقة مقابل الطلب الأصلي قبل السماح لمخرجات النموذج اللغوي الكبير بالوصول إلى مرحلة الإنتاج.
ما تتحقق منه نقطة التفتيش المفيدة
تفرض نقطة التحقق الفعالة أربعة شروط قبل قبول أي قرار بشري.
- يجب أن ينتمي المستلم إلى سياق التشغيل. إذا لم يكن المعتمد هو المراجع المعين لهذه النسخة المحددة من سير العمل، فإن النظام يرفض الإشارة.
- يجب أن تتطابق البيانات الوصفية للموضوع أو التوجيه مع حالة التدفق الحالية. فالموافقة على الخطوة الثالثة لا تعني تجاوز الخطوة الثانية.
- يجب أن يقع الطابع الزمني ضمن نافذة زمنية متوقعة. فالقرار الذي يصل بعد انتهاء المهلة يجب أن يستدعي مراجعة جديدة، لا اجتيازاً تلقائياً.
- يجب ألا تكون الأدلة قد أُعيد استخدامها في عملية تشغيل أخرى. إذا ظهر نفس معرف الرسالة أو الرمز في طلبين منفصلين للموافقة، فإن ذلك يعد تضارباً، ويجب على النظام التوقف.
التكلفة الحقيقية
هذا النمط ليس بلا ثمن؛ فأنت تخزن المزيد من البيانات الوصفية، وتضيف طبقة سياسات تتطلب صيانة مستمرة، وتجبر فريقك على تسجيل القرارات البشرية كبيانات مهيكلة بدلاً من مجرد تعليقات عابرة. قد يبدو الأمر وكأنه بيروقراطية، لكنه في الواقع مقايضة ممتازة.
أنت تقايض السرعة بالوضوح.