وكلاء الذكاء الاصطناعي بنظام Human-in-the-Loop: بناء أنظمة يثق بها الناس حقاً

إذا قام وكيل ذكاء اصطناعي بـ صياغة عقد إيجار تجاري وإرساله مباشرة عبر البريد الإلكتروني إلى المستأجر دون مراجعة، فأنت لا تملك نظام أتمتة (automation system). بل تملك مسؤولية قانونية غير مدارة (unmanaged liability). في بيئات المؤسسات الكبرى عالية الحساسية في الولايات المتحدة ومنطقة الخليج العربي — حيث الامتثال التنظيمي صارم وسمعة العلامة التجارية بالغة الأهمية — يمكن أن يكلف أي خطأ غير خاضع للرقابة من الذكاء الاصطناعي ملايين الدولارات في النزاعات القانونية، أو التأخيرات التشغيلية، أو فقدان ثقة العملاء.

على مستوى قطاع التكنولوجيا، تتعثر مشاريع الذكاء الاصطناعي للمؤسسات في مرحلة التجربة (pilot purgatory) لأن الفرق تركز بشكل مفرط على بناء أنظمة ذاتية التشغيل بالكامل (fully autonomous). يشاهدون عرضاً توضيحياً (demo) ينفذ فيه الوكيل عملية بحث وصياغة مكونة من عشر خطوات بلا أخطاء، فيفترضون أن التقنية جاهزة للتشغيل الفعلي (production). ولكن، أثناء الاختبار الفعلي في العالم الحقيقي، يهلوِس الوكيل بنسبة خصم وهمية، أو يسيء تفسير بند امتثال، أو يحذف فقرة مطلوبة.

رد الفعل المعتاد هو تراكم الديون التقنية للذكاء الاصطناعي (AI technical debt). تقوم فرق الهندسة بتعقيد الكود البرمجي عبر سلاسل موجّهات (prompt chains) معقدة للغاية، محاولين توجيه النموذج (model) بـ "عدم تكرار هذا الخطأ المحدد أبداً". والنتيجة هي بناء كود متشابك (AI spaghetti)، مما يرفع تكاليف التطوير دون القضاء على المخاطر الأساسية.

تحل هندسة الأنظمة الجاهزة للتشغيل الفعلي (production-grade engineering) هذه المشكلة بطريقة مختلفة. بدلاً من محاولة هندسة الموجّهات (prompt engineering) لنموذج لغوي للوصول إلى موثوقية بنسبة 100% — وهو أمر مستحيل عملياً نظراً للطبيعة الاحتمالية للنماذج اللغوية الكبيرة LLMs — فإنك تقوم بهندسة البنية التحتية (architecture) لتوقع عدم اليقين. تقوم ببناء وكيل ذكاء اصطناعي بنظام human-in-the-loop. يقوم النظام بالجزء الأكبر من العمل الشاق، ثم يوقف حالة التنفيذ (execution state) مؤقتاً، ويعرض العمل على موظف بشري للموافقة أو التصحيح، وعندها فقط يستأنف مهمته.

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

فخ الاستقلالية الكاملة: لماذا تتعثر الوكلاء ذاتية التشغيل في مرحلة التجربة

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

عندما يصل المشروع التجريبي إلى سقف الدقة هذا، تسلك الفرق عادةً الطريق الخاطئ. يقومون باستبدال النماذج، منتقلين من عائلة Claude 3.5 إلى فئة GPT-4o، آملين في قفزة سحرية في قدرات الاستدلال (reasoning). ويضيفون طبقات من وكلاء التقييم الذاتي (self-reflection agents)، حيث يقوم ذكاء اصطناعي بمراجعة عمل ذكاء اصطناعي آخر. ورغم أن بنيات التصحيح الذاتي (self-correction architectures) قيّمة، إلا أنها تزيد من زمن الاستجابة (latency) للـ API وتكلفة الرموز (tokens) دون تقديم ضمان حتمي للدقة.

واقع الأعمال يفرض أن الثقة ثنائية (إما موجودة أو معدومة). إذا كان مدير العمليات لا يثق في قدرة الوكيل على التعامل مع الحالات الاستثنائية (edge cases) بأمان، فلن يقوم بنشره على الإطلاق. يفشل المشروع التجريبي، وتستمر الشركة في خسارة الأموال بسبب العمليات اليدوية البطيئة.

تتجاوز بنية human-in-the-loop (HITL) هذا الفخ. من خلال تصميم النظام صراحةً للتوقف وطلب المساعدة، فإنك تضع حداً أقصى للمخاطر. يعمل الوكيل كمحلل مبتدئ ذو كفاءة عالية؛ يجمع السياق، وينظم البيانات، ويصيغ الرد، ويجهز حمولات الـ API (payloads). ثم يتوقف. يسلم العمل المنجز إلى موظف خبير يراجعه في ثوانٍ معدودة، بدلاً من القيام بالعمل من الصفر على مدار ساعات.

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

ماذا يعني مصطلح "Human-in-the-Loop" فعلياً في بيئة التشغيل؟

غالباً ما يُستخدم مصطلح "Human-in-the-loop" ككلمة رنانة مبهمة تشير إلى واجهة دردشة بسيطة. ولكن في تصميم الأنظمة الفعلية (production systems)، يشير هذا المصطلح إلى نقاط تدخل محددة وقابلة للبرمجة داخل مخطط التنفيذ (execution graph) الخاص بالوكيل. تم تصميم كل نمط لموازنة السرعة التشغيلية مقابل مخاطر أعمال محددة.

1. بوابة الموافقة (Go/No-Go) النمط الأكثر شيوعاً. يكمل الوكيل جزءاً محدداً من العمل ويتوقف مؤقتاً قبل تنفيذ أي إجراء قد يكون له أثر لا يمكن التراجع عنه أو إجراء موجه للجمهور الخارجي. على سبيل المثال، يقرأ الوكيل طلب تقديم عروض (RFP) وارداً، ويبحث في قاعدة المعرفة الخاصة بالشركة، ويصيغ مقترحاً مكوناً من 10 صفحات. قبل إرسال المقترح عبر البريد الإلكتروني أو رفعه إلى البوابة الإلكترونية، يتوقف مخطط التنفيذ (execution graph) مؤقتاً. ينقر الموظف البشري على "موافقة" أو "رفض". في حال الموافقة، ينفذ الوكيل استدعاء الـ API النهائي. هذا يقلل تماماً من خطر إرسال شروط خاطئة للعملاء.

2. حالة التصحيح (التعديل والاستئناف) غالباً ما تكون الموافقة الثنائية البسيطة (نعم/لا) غير كافية. إذا كانت مسودة الوكيل صحيحة في معظمها، فإن رفضها بالكامل يهدر تكاليف الحوسبة والرموز (tokens) المستهلكة بالفعل. في نمط التصحيح، يتدخل الموظف البشري لتعديل نصوص أو حقول بيانات محددة في حمولة البيانات (payload)، ثم يرسل الحالة المصححة مجدداً إلى الوكيل. يستأنف الوكيل بعد ذلك سير عمله مستخدماً البيانات التي صححها الإنسان كمرجعية أساسية جديدة (ground truth). يوفر هذا الوقت وتكاليف استنتاج (inference) النماذج اللغوية الكبيرة LLM.

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

اقتصاديات الحلقة (The Loop): التكلفة، وزمن الاستجابة، ومعدل الإنتاجية

غالباً ما يعارض قادة الأعمال بنيات HITL خوفاً من أنها قد تلغي الغرض من الأتمتة. فإذا كان على الإنسان مراجعة العمل، ألا نزال ندفع مقابل العمالة البشرية؟

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

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

لنأخذ على سبيل المثال شركة خدمات لوجستية متوسطة الحجم تعالج 1,000 فاتورة مورد أسبوعياً. الهدف هو استخراج البنود الفردية، والتحقق منها مقابل أوامر الشراء، وتجهيز المدفوعات في نظام ERP.

ملاحظة: تكلفة الذكاء الاصطناعي توضيحية بناءً على استخراج البيانات بالرؤية الحاسوبية بفئة GPT-4o بسعر تقريبي 0.03 دولار لكل فاتورة.

الحسابات واضحة. يبدو النظام ذاتي التشغيل بالكامل أرخص على الورق، لكن تكلفة دفع فاتورة واحدة خاطئة تفوق بكثير الـ 583 دولاراً التي تُنفق على المراجعة البشرية. من خلال تطبيق بنية HITL، تحقق الشركة تخفيضاً بنسبة 91.6% في تكاليف العمالة الأسبوعية (توفير أكثر من 6,400 دولار أسبوعياً، أو ما يزيد عن 330,000 دولار سنوياً) مع الحفاظ على المخاطر التشغيلية عند مستوى يقارب الصفر.

البنية التقنية: إيقاف الحالة (State) مؤقتاً واستئنافها

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

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

لحل هذه المشكلة، نقوم ببناء مخططات متعددة الوكلاء تحفظ الحالة (stateful multi-agent graphs) باستخدام أطر عمل التنسيق (orchestration frameworks) مثل LangGraph.

في المخطط الذي يحفظ الحالة (stateful graph)، يتم التعامل مع تقدم الوكيل كسلسلة من الخطوات المنفصلة، مع حفظ السياق بالكامل ("الحالة" أو "state") في قاعدة بيانات مستمرة (persistent database)، مثل PostgreSQL، عند كل عقدة (node). عندما يصل الوكيل إلى نقطة التدخل البشري المحددة، فإنه لا ينتظر خاملاً. بل يكتب حالته الحالية في قاعدة البيانات، ويرسل إشعاراً إلى الموظف البشري (عبر Slack، أو البريد الإلكتروني، أو لوحة تحكم مخصصة)، ويوقف عملية الحوسبة الخاصة به تماماً.

يمكن للنظام الانتظار لمدة خمس دقائق أو خمسة أيام دون استهلاك موارد الخادم النشطة. وعندما يقوم الموظف البشري بمراجعة البيانات والنقر على "موافقة"، تتلقى الخلفية البرمجية (backend) استدعاء ويب (webhook). حيث تسترجع الحالة الدقيقة من قاعدة البيانات، وتُعيد تشغيل الوكيل، وتستأنف مخطط التنفيذ من النقطة التي توقف عندها تماماً.

هذا هو ما يفرق بين الذكاء الاصطناعي الجاهز للتشغيل الفعلي (production AI) وبين ذكاء العروض التوضيحية (demo AI). تحتفظ تطبيقات العروض التوضيحية بالحالة في الذاكرة المحلية; وإذا أُعيد تشغيل الخادم أو قام المستخدم بتحديث الصفحة، يفقد الوكيل حالته. أما الأنظمة الفعلية فتقوم بحفظ نقاط الحالة (checkpoint state) بشكل مستمر، مما يسمح بتفاعل بشري غير متزامن ومتين يتوسع برمجياً دون زيادة فواتير الاستضافة السحابية.

تصميم آلية التسليم: ماذا يرى الإنسان فعلياً؟

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

واجهة المستخدم لعملية التسليم هي مكون هندسي بالغ الأهمية. يجب أن يعرض نظام HITL الفعلي للموظف البشري ثلاثة أشياء في وقت واحد:

1. ▸الإجراء المقترح: ما ينوي الوكيل فعله بالضبط (مثل: "إرسال البريد الإلكتروني التالي إلى client@domain.com").
2. ▸السياق: البيانات المحددة التي استخدمها الوكيل لاتخاذ قراره.
3. ▸المصادر والاقتباسات: إذا صاغ الوكيل بنداً في عقد بناءً على اتفاقية أساسية، يجب أن تبرز واجهة المستخدم الفقرة الدقيقة في المستند المصدر.

نقوم عادةً ببناء واجهات أمامية مخصصة (custom frontend interfaces) لهذا الغرض باستخدام Next.js، أو نقوم بتوجيه الموافقات مباشرة إلى الأدوات التي يستخدمها فريق العمليات بالفعل. إذا كان فريقك يعتمد على Slack، يرسل الوكيل رسالة Slack block kit تحتوي على المسودة المقترحة، ورابط المصدر، وزرين: "موافقة" أو "تعديل". وإذا نقروا على تعديل، تفتح نافذة منبثقة (modal) ليقوموا بتعديل النص، ثم يتابع الوكيل عمله.

من خلال تقليل العبء المعرفي (cognitive load) على المراجع البشري، تحافظ على معدل إنتاجية (throughput) مرتفع. يعمل الإنسان كمحرر وليس ككاتب، مما يحافظ على سرعة العمليات دون التضحية بمراقبة الجودة.

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

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

هل تؤدي بنية human-in-the-loop إلى إبطاء العملية؟ من حيث زمن استجابة الآلة (machine latency) المجرد، نعم، لأن النظام ينتظر التدخل البشري. أما من حيث دورة حياة العمل (business cycle time)، فلا. فوكيل يصيغ تقريراً في 10 ثوانٍ وينتظر ساعتين للحصول على موافقة بشرية لا يزال أسرع بكثير من موظف يستغرق 3 أيام ليجد الوقت الكافي لكتابة التقرير من الصفر.

كيف نمنع الموظفين من النقر على 'موافقة' بشكل أعمى؟ هذا خطر معروف يسمى "انحياز الأتمتة" (automation bias). ولمواجهته، يجب أن تفرض الواجهة تفاعلاً حقيقياً. بدلاً من زر "موافقة" واحد، يمكن لواجهة المستخدم أن تطلب من المراجع تحديد خانات اختيار (checkboxes) تؤكد صراحةً مراجعة متغيرات محددة عالية الخطورة (مثل: "تأكيد أن الخصم أقل من 15%"). بالإضافة إلى ذلك، يمكنك حقن حالات استثنائية (edge cases) معروفة بشكل منهجي في طابور المراجعة لتدقيق مدى انتباه المراجعين.

ما هو العائد على الاستثمار (ROI) وفترة الاسترداد المعتادة لنظام وكيل ذكاء اصطناعي بنظام HITL؟ يرى معظم عملاء المؤسسات عائداً إيجابياً على الاستثمار (ROI) في غضون 60 إلى 90 يوماً من النشر. من خلال تقليل وقت المعالجة اليدوية بنسبة 80-90% مع تجنب التكاليف الباهظة للضبط الدقيق (fine-tuning) للنماذج المخصصة وأخطاء الامتثال، يسترد النظام تكاليف تطويره الأولية بسرعة. على سبيل المثال، توفر أتمتة معالجة الفواتير أو مراجعة العقود آلاف الدولارات من تكاليف العمالة وتصحيح الأخطاء شهرياً.

هل يمكننا الاستغناء عن التدخل البشري تدريجياً بمرور الوقت؟ نعم. الميزة الكبرى لأنظمة HITL هي أن كل تصحيح بشري يعمل كبيانات تدريب عالية الجودة. من خلال تسجيل ما اقترحه الذكاء الاصطناعي مقابل ما وافق عليه الإنسان بالفعل، فإنك تبني مجموعة بيانات للحالات الاستثنائية (edge cases). بمرور الوقت، يمكنك استخدام هذه البيانات لتحسين توجيهات الوكيل، أو تطبيق التوجيه بالأمثلة القليلة (few-shot prompting), أو في النهاية إجراء الضبط الدقيق (fine-tuning) للنموذج، مما يقلل بأمان من نسبة المهام التي تتطلب مراجعة بشرية.

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