تشتت السياق: لماذا تنهار وكلاء الذكاء الاصطناعي بعد الخطوة الرابعة؟ وكيف تحلها هندسياً

خلاصة سريعة (Key Takeaways):

• جذر المشكلة: حين يتعثر الوكيل الذكي (AI Agent) في خطوة متقدمة، لا تَلُمْ ذكاء النموذج؛ المشكلة الحقيقية تكمن في "تلوّث السياق" وتراكم مسودات التفكير العشوائية عبر الخطوات.
• فخ الاحتمالات: حتى لو بلغت دقة كل خطوة منفردة 90%، فإن الرياضيات تحتم أن مساراً من 4 خطوات فقط ستهبط موثوقيته إلى نحو 65% على الورق، وأقل من 40% على أرض الواقع في بيئة الإنتاج.
• المخرج الهندسي: عزل سياق كل خطوة برمجياً، وفرض عقود بيانات صارمة وحتمية (بـ Pydantic أو JSON Schema)، بدلاً من التعويل على "وعود" النموذج اللغوي.

---

أن تطلب من نموذج لغوي متقدم قراءة مستند وتلخيصه مهمة سهلة؛ فغالباً ستتجاوز نسبة النجاح 90% بكل أريحية. لكن جرّب أن تدمج أربع خطوات متتابعة في مسار مؤتمت بالكامل: قراءة الملف، استخراج الحقول، فحص شروط العمل (Business Logic)، وصولاً إلى حفظ النتيجة في قاعدة البيانات... هنا تحديداً ستلاحظ المفاجأة غير السارة: موثوقية النظام في بيئة الإنتاج تنهار فجأة إلى ما دون 40%.

لماذا يحدث هذا؟ نادراً ما يكون السبب غباء النموذج أو نفاد نافذة السياق. المتهم الحقيقي هو تشتت السياق (Context Drift)؛ تلك الظاهرة التي تتآكل فيها تعليمات النظام الأساسية تدريجياً بعدما تغرق ذاكرة العمل بمسودات التفكير اللحظية (Reasoning traces)، وردود الأدوات الخارجية، وتفاصيل مرحلية لا تهم المراحل التالية إطلاقاً.

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

---

الرياضيات القاسية لانهيار المسارات المتسلسلة

حسابات الفشل هنا لا ترحم؛ فالمعادلة أبسط مما نتوقع. لو افترضنا بتفاؤل أن كل خطوة تنجح بنسبة مستقلة قدرها 90%، فإن سلسلة من أربع خطوات فقط تهبط بموثوقية المسار ككل إلى نحو 65.6% ($0.90^4$). وبحلول الخطوة السابعة، تنحدر النسبة إلى ما دون 48% — أي أنك تبني نظاماً وتترك نجاحه في الإنتاج لمجرد الحظ!

```text الخطوة 1: قراءة الملف وتصنيفه (90%) └── الخطوة 2: استخراج الكيانات (81% تراكمي) └── الخطوة 3: التأكد من صحة الأرقام (72.9% تراكمي) └── الخطوة 4: صياغة الحمولة وإرسالها (65.6% تراكمي) ← [نقطة الانهيار] ```

لكن الواقع الميداني أسوأ بكثير من هذه الحسبة النظرية؛ لأن خطوات الوكيل ليست أحداثاً مستقلة إحصائياً.

فكل فكرة عابرة (Reasoning Trace)، وكل فشل استرجاع مؤقت، وكل رد خام (Raw Payload) من أداة خارجية يُقحم تلقائياً داخل نافذة السياق التراكمية. ومع الوصول إلى الخطوة الرابعة، تصبح تعليمات النظام الأساسية (System Prompt) مدفونة تحت ركام من آلاف التوكنز وضجيج المحادثة. النتيجة الحتمية؟ تشتت رؤوس الانتباه (Attention Heads) في النموذج، ليبدأ في الهلوسة، واختراع مفاتيح JSON وهمية، وتجاهل أدق الشروط المنطقية التي بُني عليها نظامك.

---

مقارنة معمارية: التمرير الساذج مقابل ماكينات الحالة المعزولة

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

| المعيار الهندسي | التمرير الساذج (يتعثر عند الخطوة 4) | ماكينات الحالة المعزولة (جاهز للإنتاج) | | :--- | :--- | :--- | | إدارة السياق | نافذة محادثة تراكمية متضخمة بلا داعٍ | سياق مؤقت يُفرغ تماماً بعد انتهاء كل خطوة | | عقود البيانات | نصوص حرة وصياغة ماركداون فضفاضة | نماذج بيانات حتمية صارمة (Pydantic / Zod) | | معالجة الأخطاء | تصحيح ذاتي عشوائي داخل الجلسة نفسها | اعتراض برمجي خارجي وإعادة محاولة نظيفة | | استهلاك التوكنز | تضخم تصاعدي وانفجار مفاجئ في التكلفة | استهلاك ثابت ومحدد بدقة لكل خطوة | | صمامات الأمان | تسليم زمام الأمور لوعود النموذج وحدها | بوابات فحص برمجية تقليدية (Deterministic Gates) |

---

3 حلول معمارية لاستعادة ثبات الوكلاء

لتفادي تشتت السياق، يجب أن تفصل فصلاً تاماً بين مساحة التفكير المؤقتة للنموذج ومخزن بيانات النظام الدائم:

1. تصميم خطوات المسار كعُقد عديمة الحالة (Stateless Execution Nodes)

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

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

2. حراس الكود الحتمي: المنطق البرمجي أولى من البرومبت

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

بدلاً من ذلك، ضع بوابات فحص برمجية حتمية بين كل مرحلة وأخرى:

• فحص المخطط (Schema Validation): استخدم مكتبات مثل Pydantic أو Zod للتحقق من أنواع الحقول، والمدى الرقمي، والنصوص الفارغة قبل تمرير البيانات للأمام.
• إعادة المحاولة المعزولة: إذا فشل الفحص، لا تجعل الوكيل يعتذر داخل المحادثة. التقط الخطأ برمجياً، وحدد الحقل المعطوب وحده، ثم أرسل طلباً منفصلاً ونظيفاً لتصحيح ذلك الحقل تحديداً.

3. نقاط التفتيش وإدارة الحالة (State Checkpointing)

إذا تعثر المسار في الخطوة الرابعة، فإعادة تشغيله بالكامل من الخطوة الأولى هو هدر فادح للوقت واستنزاف غير مبرر لميزانية الـ API.

استعن بمحركات آلات الحالة الصريحة (مثل LangGraph أو Temporal أو حتى جدول SQLite محلي). بعد اعتماد وتوثيق مخرجات الخطوات (1 إلى 3)، إذا فشلت الخطوة الرابعة، يمكنك تنفيذ إعادة محاولة محلية معزولة لتلك الخطوة وحدها دون المساس بما أُنجز سابقاً.

---

تشريح حالة واقعية: وكيل تدقيق ومراجعة الكود

خلال تدقيق قمنا به على وكيل أتمتة مخصص لمراجعة طلبات التعديل (Pull Requests) على GitHub، كان المسار مصمماً لأربع مهام:

1. قراءة الفروقات البرمجية (Diffs).
2. فحص الثغرات الأمنية المحتملة.
3. التأكد من شمولية الاختبارات.
4. صياغة تعليق مراجعة منظم وإرساله عبر واجهة GitHub.

في النسخة الأولى (التي اعتمدت على السياق التراكمي)، أنجز الوكيل أول خطوتين بامتياز. لكن مع الخطوة الثالثة، امتلأت نافذة السياق بآلاف الأسطر البرمجية المشوشة، حتى بدأ النموذج يخلط بين الأكواد المحذوفة وملفات الاختبار الغائبة. وفي الخطوة الرابعة، عجز تماماً عن إخراج رد بتنسيق JSON صحيح، وكتب بدلاً منه نصاً إنشائياً طويلاً عطّل الـ Webhook الخاص بالنظام.

ما الذي غيّرناه؟ ألغينا فكرة الذاكرة التراكمية تماماً. أصبحت الخطوة الأولى تسلم نتائجها إلى بنية بيانات محددة (Dataclass)، بينما تتلقى الخطوتان (2 و 3) فقط الأجزاء البرمجية الخاصة بهما وتعملان بالتوازي. أما الخطوة الرابعة فلا يصلها سوى ملخص منظم للمشاكل المرصودة. النتيجة؟ قفزت نسبة نجاح المسار مباشرة من 38% إلى 94.2% عبر اختبارات شملت 200 طلب تعديل حقيقي.

---

أسئلة شائعة (FAQ)

هل استخدام نوافذ سياق ضخمة (مثل مليون توكن) يحل مشكلة تشتت السياق؟ إطلاقاً؛ فالمعضلة ليست سعة التخزين، بل دقة تركيز النموذج وظاهرة "الضياع في المنتصف" (Lost in the Middle). كلما حشوت السياق ببيانات إضافية، زادت الضوضاء، وارتفعت التكلفة وزمن الاستجابة، وتضاعفت احتمالية التشتت.

كيف أتعامل مع العمليات التي تتطلب سياقاً تراكمياً فعلياً؟ قسّم السياق إلى مستويين: مخزن حالة هيكلي خارجي (Structured State) لحفظ الوقائع والبيانات الصافية، ومساحة تفكير مؤقتة (Ephemeral Scratchpad) تُحذف فور انتهاء المعالجة.

---

خطة التنفيذ الميدانية في 3 خطوات

1. راقب استهلاك التوكنز: تفقّد حجم المدخلات في الخطوة الأخيرة من مسارك؛ إن وجدتها تستهلك أضعاف الخطوة الأولى، فهذا مؤشر صريح على وجود تسريب للسياق يستوجب الإيقاف.
2. نظّف مسودات التفكير: احذف وسوم الاستدلال (مثل `thought` والمسودات المؤقتة) وردود الأدوات الخام قبل حفظ النتيجة أو تمريرها للمرحلة التالية.
3. استبدل الرجاء بالكود: بدلاً من محاولة استجداء الدقة في البرومبت ("رجاءً تأكد تماماً من صحة البيانات")، افرض فحوصات صارمة عبر الكود (Schema Validators). لا تدع البيانات غير المطابقة تعبر بوابتك أبداً.