By submitting, you consent to our use of your data. Privacy Policy.
Category
وكلاء الذكاء الاصطناعي
Share the article
يدعي جميع مزودي برمجيات وكلاء الذكاء الاصطناعي أن منتجاتهم "تتعلم". لكن معظمهم يصف عمليات التخزين المؤقت للمطالبات (prompt caching) بميزانية تسويقية ضخمة.
إن الفجوة بين الادعاء بالتعلم الذاتي وبنائه بالفعل هي واحدة من أوسع الفجوات في مجال الذكاء الاصطناعي للمؤسسات في الوقت الحالي. تقدر شركة غارتنر (Gartner) أن أكثر من 40% من مشاريع الذكاء الاصطناعي الوكيل سيتم إلغاؤها بحلول عام 2027، وذلك بسبب ظاهرة تلميع قدرات الوكلاء "agent washing" كمحرك رئيسي. حوالي 130 فقط من بين آلاف الشركات المصنعة التي تبني ذكاءً اصطناعياً وكيلاً تقدم شيئاً جديداً بحق، بينما يعيد الباقون تسمية روبوتات الدردشة وأنظمة أتمتة العمليات الروبوتية (RPA).
التعلم الذاتي هو المجال الذي يظهر فيه هذا التباين بوضوح أكبر. إذن، ما الذي يتطلبه الأمر فعلياً لبناء وكيل ذكاء اصطناعي يتحسن بمرور الوقت أثناء العمل في بيئة تشغيل فعلية، وليس فقط في العروض التوضيحية؟
مشكلة جمع الملاحظات والآراء
يبدأ التعلم الذاتي بالملاحظات. يبدو هذا بديهياً، لكن التحدي الهندسي لا يكمن في جمع الملاحظات والتقييمات، بل في جمع التقييمات المناسبة بالدقة المطلوبة.
عندما يخبر مستخدم وكيل الذكاء الاصطناعي بأن "هذا خاطئ"، فإن هذا التقييم صادق ولكنه غير دقيق. ففي سير عمل يتكون من 15 عقدة (node)، قد تعني جملة "هذا خاطئ" أن استخراج البيانات قد فشل، أو أن منطق التصنيف كان خاطئاً، أو أن تنسيق المخرجات النهائي قد تعطل. وإذا قمت بتوجيه هذا التقييم إلى العقدة الخاطئة، سيتعلم الوكيل الدرس الخاطئ ويصبح أداؤه أسوأ بدلاً من أن يتحسن.
تتجاهل معظم المنصات هذه المشكلة تماماً. فهم يجمعون تقييمات الإعجاب/عدم الإعجاب على مستوى المهمة ككل، ويطلقون على ذلك حلقة تقييم وملاحظات. لكن التقييم على مستوى المهمة دون توجيهه على مستوى العقدة يشبه إخبار رئيس الطهاة بأن "الوجبة كانت سيئة" دون توضيح ما إذا كانت اللحمة غير ناضجة جيداً أم أن الصلصة كانت خاطئة. ستحصل على طبق مختلف تماماً في المرة القادمة، وليس طبقاً أفضل.
إن بناء بنية تحتية حقيقية لجمع الملاحظات يعني حل ثلاث مشكلات في وقت واحد: التقاط ملاحظات المستخدم باللغة الطبيعية، وربط تلك الملاحظات بخطوة سير العمل المحددة التي تسببت في المشكلة، وتخزينها بطريقة تمكن النظام من العمل بناءً عليها أثناء التنفيذ التالي. وكل من هذه التحديات يمثل مشروعاً هندسياً مستقلاً بذاته.
ربط المهام بالعقد (Task-to-node mapping): الجزء الصعب الذي لا يتحدث عنه أحد
هذا هو المكان الذي تنهار فيه معظم ادعاءات التعلم الذاتي. يقول المستخدم "مطابقة المرشحين غير دقيقة" ويحتاج نظامك إلى معرفة ما إذا كان محلل السير الذاتية، أو نموذج التقييم، أو خوارزمية الترتيب، أو طبقة العرض النهائية هي التي تسببت في المشكلة.
النهج الساذج هو أن تطلب من المستخدم تحديد الخطوة التي حدث فيها الخطأ. هذا ينجح مع الفرق التقنية، لكنه لا ينجح مع مدير الموارد البشرية، أو المراقب المالي، أو مدير العمليات الذي يستخدم الوكيل بشكل فعلي يومياً. فهم يفكرون في النتائج، وليس في خطوات سير العمل.
الحل الهندسي هو طبقة مطابقة وربط تأخذ الملاحظات غير المنظمة (مثل "مبلغ هذه الفاتورة خاطئ") وتتتبعها عبر مخطط التنفيذ لتحديد نقطة الفشل الأرجح. يتطلب هذا الحفاظ على تتبع كامل لعملية التنفيذ لكل مهمة، وبناء نموذج احتمالي يمكنه إرجاع أخطاء النتائج إلى عقد محددة، والقيام بذلك بدقة كافية تجعل التصحيحات تحسن الأداء فعلياً.
هذا هو بالضبط ما تم بناء أداة Tool Tuner من Beam AI لحله. فهي تكتشف حالات الفشل الشائعة — مثل الهلوسة، والمخرجات الفارغة، والتنسيقات الخاطئة — وتتتبعها لتصل إلى الأداة أو العقدة المحددة التي تسببت في المشكلة، ثم تقوم بترقيع السلوك تلقائياً. من بين 12 عملية نشر فعالة في بيئة الإنتاج، حققت 10 عمليات دقة بلغت أكثر من 80% في مطابقة الملاحظات بالعقد المعنية. وحققت العمليتان المتبقيتان دقة تقارب 60% و 78%. وهنا تكمن الهندسة الأكثر إثارة، لأن هذا يرجع عادةً إلى مسارات عمل غامضة ومبهمة حيث يمكن أن تكون عدة عقد هي نقطة الفشل المحتملة.
انحراف الأداء (Drift detection): القاتل الصامت
الوكيل الذي يعمل بشكل مثالي في الأسبوع الأول ويتراجع أداؤه بحلول الأسبوع الثامن هو أسوأ من وكيل لم يعمل أبداً. فعند الفشل الكلي، يتدخل شخص ما للتحقيق. أما مع انحراف الأداء وتراجعه، فإن جودة المخرجات تتدهور ببطء شديد بحيث لا يلاحظها أحد حتى يقع الضرر بالفعل.
يظهر تحليل لأكثر من 4 ملايين مكالمة لوكلاء في بيئة التشغيل الفعلية أن الانحراف هو أكثر أنماط الفشل شيوعاً للوكلاء المستخدمين. ويظهر ذلك في أربعة أشكال: انحراف الامتثال (يتوقف الوكيل عن اتباع قواعده الخاصة)، وانحراف الطول (تصبح الاستجابات أطول أو أقصر بمرور الوقت)، والانحراف الدلالي (يتغير معنى المخرجات تدريجياً)، والتراجع (ينخفض الأداء في المهام التي كانت تعمل بنجاح سابقاً).
يتطلب الكشف عن الانحراف تقييماً مستمراً مقابل المقاييس الأساسية، وليس مجرد تسجيل الأخطاء. تحتاج إلى تتبع توزيع المخرجات بمرور الوقت، ورصد الانحرافات الإحصائية قبل أن تصبح واضحة للمستخدمين، وتجهيز آليات تراجع أو تصحيح مؤتمتة. تمنحك معظم أدوات المراقبة معدلات الخطأ وزمن الاستجابة فقط؛ لكن لا أحد منها تقريباً يتتبع الانحراف الدلالي، وهو النوع الذي يدمر القيمة الفعلية للأعمال.
إن بناء نظام لكشف الانحراف يعني تشغيل خط تقييم موازٍ لخط الإنتاج والتشغيل الفعلي الخاص بك. حيث يتم تقييم واحتساب نقاط كل عملية تنفيذ رقم (N) مقارنة بمعاييرك الأساسية، وتطلق الانحرافات تنبيهات قبل أن يلاحظ مستخدمو الوكيل هذا التدهور. هذه ليست بنية تحتية براقة، ولكن بدونها، فوزن أي "تعلم" يقوم به وكيلك قد يؤدي إلى تفاقم الأمور بدلاً من تحسينها.
مشكلة البداية الباردة (Cold start)
يتطلب التعلم الذاتي بيانات. والوكلاء الجدد لا يملكون أي بيانات. يخلق هذا مشكلة بدء التشغيل الذاتي: يحتاج الوكيل إلى ملاحظات وتقييمات من بيئة العمل الفعلية ليتحسن، ولكنه يحتاج إلى أن يكون جيداً بما فيه الكفاية في هذه البيئة ليولد ملاحظات وتقييمات مفيدة.
الحل البديل الشائع هو التدريب المسبق على بيانات اصطناعية أو أمثلة تاريخية. يوصلك هذا إلى حد أساسي مقبول، لكن البيانات الاصطناعية لها سقف محدد. فبيئات التشغيل الحقيقية تحتوي على حالات استثنائية، واختلافات في التنسيق، وتفاصيل دقيقة خاصة بمجال العمل لا يمكن للبيانات الاصطناعية توقعها. سيتعامل الوكيل مع 80% من الحالات العادية من اليوم الأول ولكنه سيواجه صعوبة في الـ 20% المتبقية التي تصنع الفارق الفعلي.
النهج الأفضل هو النشر على مراحل: ابدأ بتشغيل الوكيل في نطاق ضيق حيث يمكن للبيانات الحالية تغطية معظم الحالات، واجمع التقييمات والملاحظات في الحالات الاستثنائية، ثم وسع النطاق مع تحسن الدقة. يتطلب هذا بنية تحتية تدعم حدود النطاق الديناميكي والانتشار التدريجي، وهو مستوى آخر من الهندسة لا تخطط له معظم الفرق.
متى تعيد التدريب مقابل متى تعيد صياغة المطالبة (Prompt)
لا تتطلب كل ملاحظة أو تقييم إعادة تدريب على مستوى النموذج. في بعض الأحيان يكون الحل هو تعديل في صيغة المطالبة. وفي أحيان أخرى يكون تغييراً في الإعدادات. وفي أحيان أخرى يكون تحديثاً حقيقياً للنموذج. إن معرفة أي منها يجب تطبيقه، وأتمتة هذا القرار، هي واحدة من أصعب المهام في بناء وكلاء التعلم الذاتي.
تتوزع شجرة القرار كالتالي: إذا كان الخطأ ناتجاً عن نقص في السياق، فالحل هو تعديل المطالبة. وإذا كان الخطأ ناتجاً عن تفكير خاطئ في مدخلات مفهومة جيداً، فالحل هو تعديل النموذج أو درجات القياس. وإذا تكرر نمط الخطأ عبر مهام متعددة وكان يزداد سوءاً بمرور الوقت، فهذا مؤشر يحتم إعادة التدريب.
هذا هو المكان الذي تعمل فيه طبقة التحسين التلقائي في أداة Tool Tuner. فهي تقوم تلقائياً بإعادة كتابة مطالبات الأداة عندما تكون المشكلة في الوضوح أو السياق، وتضبط المعلمات الافتراضية عندما تكون المدخلات هي المشكلة، وتعدل تنسيق الاستجابة عندما تنحرف المخرجات عن المتطلبات. والأهم من ذلك، يتم التحقق من كل تغيير مقترح مقابل مجموعة بيانات مرجعية ذهبية قبل أن يصبح معتمداً؛ فإذا تسبب الإصلاح في جعل الأمور أسوأ، فلن يتم إطلاقه ونشره. بوابة الأمان هذه هي الفارق الحقيقي بين نظام يتعلم فعلياً ونظام آخر يتغير عشوائياً.
إن بناء هذا النظام من الصفر يعني تصنيف الأخطاء حسب السبب الجذري في الوقت الفعلي، والحفاظ على نظام إصدارات للمطالبات يمكنه إجراء اختبارات المقارنة (A/B testing) للتغييرات، وامتلاك خط أنابيب لإعادة التدريب يمكن تشغيله دون إيقاف الوكيل عن العمل. كل هذه العناصر تعتبر بنية تحتية أساسية للتعلم الذاتي الحقيقي، ويستغرق بناء كل منها أشهراً من الصفر.
لماذا تعد معظم ادعاءات التعلم الذاتي مجرد تسويق؟
يوضح تقرير مؤسسة غارتنر الصادر في مايو 2026 حول تلميع قدرات الوكلاء وزخرفتها (agent washing) في تكنولوجيا سلاسل الإمداد الأمر بصراحة: يعيد معظم الموردين تسمية الأتمتة الحالية على أنها أنظمة وكيلة. وينطبق النمط نفسه على التعلم الذاتي. إذا أخبرك أحد الموردين أن وكيله "يتعلم"، فاطرح عليه هذه الأسئلة:
هل يوجه التقييمات والملاحظات إلى عقد مسار عمل محددة، أم يكتفي بجمع تقييمات الإعجاب على مستوى المهمة بالكامل؟
هل يمكنه اكتشاف انحراف الأداء تلقائياً، أم يعتمد على إبلاغ المستخدمين بالمشكلات؟
هل يميز بين إصلاحات المطالبات وتحديثات النموذج، أم يعامل جميع الملاحظات والتعليقات بالتساوي؟
كيف يتعامل مع مشكلة البداية الباردة (cold start) لمسارات العمل الجديدة؟
هل يمكنه أن يوضح لك منحنى تحسن الدقة بمرور الوقت باستخدام بيانات حقيقية من بيئة التشغيل الفعلية؟
إذا كانت الإجابة على معظم هذه الأسئلة مبهمة وغير واضحة، فأنت أمام عملية تخزين مؤقت للمطالبات مع نموذج لجمع التقييمات والملاحظات، وليس تعلماً ذاتياً حقيقياً.
وكما أشار الفريق الهندسي في شركة Anthropic، فإن بناء وكلاء موثوقين "لا يتعلق بالبحث عن الكلمات الصحيحة بقدر ما يتعلق بتحديد طبيعة تركيبة السياق الأكثر احتمالية لتوليد السلوك المطلوب من النموذج". التعلم الذاتي هو في الأساس مشكلة هندسة سياق: إيصال المعلومات الصحيحة، من التقييم الصحيح، إلى المكان الصحيح في النظام، وفي الوقت المناسب تماماً.
ما يتطلبه بناء هذا النظام بنفسك
إذا كنت تفكر في بناء بنية تحتية للتعلم الذاتي داخلياً وبنفسك، فإليك جرد تقريبي لما ستحتاج إليه:
بنية تحتية لجمع الملاحظات والتقييمات: طبقة التقاط تتعامل مع الملاحظات المنظمة وغير المنظمة، وطبقة تخزين تربط الملاحظات بعمليات تنفيذ محددة، وطبقة توجيه تطابق الملاحظات على مستوى المهمة مع التصحيحات على مستوى العقدة.
خط أنابيب التقييم: تقييم مستمر ومقارنة مع المقاييس الأساسية، وكشف الانحراف عبر أبعاد متعددة، وتنبيهات مؤتمتة مع إمكانية التراجع الفوري.
محرك التصحيح: نظام لإدارة إصدارات المطالبات مع اختبارات المقارنة (A/B testing)، وطبقة اتخاذ قرار تصنف الأخطاء حسب أسبابها الجذرية وتختار نوع الإصلاح المناسب، وخط أنابيب لإعادة التدريب في الحالات التي تتطلب تحديثات على مستوى النموذج.
إدارة النطاق والأهداف: حدود ديناميكية تتوسع مع تحسن الدقة، وبنية تحتية للنشر التدريجي على مراحل، وتخفيف مشكلة البداية الباردة من خلال إدخال بيانات اصطناعية للبدء بها.
المراقبة والقدرة على الرصد (Observability): لا تقتصر على معدلات الخطأ وزمن الاستجابة فحسب، بل تشمل التتبع الدلالي، ومراقبة توزيع المخرجات، وبناء منحنيات الدقة عبر عمليات النشر في بيئات التشغيل الفعلية.
هذا يمثل استثماراً هندسياً يمتد من 6 إلى 12 شهراً قبل أن تحصل على شيء جاهز للاستخدام الفعلي في بيئة العمل. كما أنه يتطلب صيانة مستمرة ومتابعة مع توسع محفظة الوكلاء لديك؛ فكل مسار عمل جديد يحتاج إلى منطق توجيه التقييمات والملاحظات الخاص به، ومقاييسه المرجعية، وعتبات انحراف الأداء الخاصة به.
أو استخدم منصة تحتوي على كل ذلك بالفعل
هذه هي المشكلة التي تعمل شركة Beam AI على حلها منذ أكثر من عامين. حيث تم دمج حزمة التعلم الذاتي بالكامل؛ بما في ذلك توجيه التقييمات، وربط المهام بالعقد، وكشف انحراف الأداء، وضبط المطالبات، والنشر التدريجي على مراحل، مباشرة في المنصة من خلال أداة Tool Tuner. وفي إحدى عمليات النشر الفعلي في بيئة العمل، رفعت أداة Tool Tuner دقة وكيل معالجة التحقق من العناوين من 60.6% إلى 95.7% من خلال ثلاث دورات تحسين مؤتمتة دون أي تدخل هندسي بشري. هكذا يبدو التعلم الذاتي الحقيقي عندما تكون البنية التحتية موجودة بالفعل.
إذا كنت تفاضل بين بناء بنية تحتية للتعلم الذاتي بنفسك أو شرائها جاهزة، فإن الإجابة الصادقة هي أن بناءها داخلياً أمر ممكن ولكنه مكلف، وتكلفة الصيانة تزداد مع كل وكيل جديد تضيفه. الشركات التي تنجح في إدخال وكلاء التعلم الذاتي إلى بيئة العمل والإنتاج بأسرع وقت هي تلك التي لا تحاول إعادة اختراع البنية التحتية وتصميمها من الصفر.
تعرف على كيفية عمل وكلاء التعلم الذاتي من Beam AI في بيئة التشغيل الفعلية.
