docs(i18n,ch9): 13 个译本同步 τ²-bench 转接边界实验

book-ar/chapter9.ar.md

@@ -87,18 +87,6 @@
 
 ويقدّم التعلم من تجارب GAIA مثالًا واضحًا. يتضمن معيار GAIA[^gaia-2023] مسائل متعددة الخطوات تجمع بين البحث وقراءة الويب ومعالجة الملفات والحساب، بينما يوفّر AWorld[^aworld-2025] بيئة لتشغيل الوكلاء واستدعاء الأدوات وتسجيل المسارات. فالأول أشبه بورقة الاختبار، والثاني بقاعة الاختبار ونظام تسجيل نتائجه. وقد يكتفي نهج ساذج بتلخيص استراتيجية تشغيل ناجح وإدخالها مباشرة في الموجّه. أما التطبيق المنضبط فيبدأ بمدقق إجابات GAIA، أو بمدقق بيئي آخر، لتصنيف كل تشغيل إلى ناجح أو ناجح جزئيًا أو فاشل، ثم يقارن مسارات عدة من عائلة المهمة نفسها. تقترح المسارات الناجحة استراتيجيات مرشحة، وتكشف الإخفاقات ما ينبغي تجنبه، وتبيّن النجاحات الجزئية الجزء الذي نجح والجزء الذي بقي عالقًا. وقد يساعد التأمل اللغوي الذي اقترحته Reflexion[^reflexion-2023] على صياغة دروس مرشحة، لكنه ليس دليلًا في ذاته. ولا ينبغي إدخال درس في وثائق الخبرة المعتمدة إلا إذا وافق نتائج البيئة، وتكرر تأييده عبر مسارات عدة، وأظهر أثرًا إيجابيًا عند نقله إلى مهام جديدة.
 
-> **التجربة 9-2 ★★: استخلاص مستندات المعرفة الخاصة بالخبرة من مسارات GAIA**
->
-> **الهدف:** اختبار ما إذا كانت وثائق المعرفة عبر المسارات تنقل بشكل أفضل من ملخص نجاح واحد وتقليل النقل السلبي من النجاحات العرضية والخبرة غير الصحيحة.
->
-> **البيانات والإجراءات:** تقوم `gaia-experience` أولاً بتخزين المسار الكامل و`environment_score` الخارجي لكل تشغيل، ثم تحويلها إلى الحد الأدنى من سجلات التعلم التي تحتوي على `task_family`، و`capabilities` المطلوبة، و`applies_when`، والاستراتيجيات الملحوظة، والأخطاء، والاستثناءات، ومعرفات مسار المصدر. يصنف مدقق النتائج عمليات التشغيل على أنها ناجحة أو ناجحة جزئيًا أو فاشلة. تقوم وحدة التعلم النمطية بمقارنة المسارات ضمن مجموعة المهام نفسها. قد يقترح LLM تعميمات مرشحة، لكن الإستراتيجية الموصى بها يجب أن تكون مدعومة بمسارين غير فاشلين على الأقل. تتضمن وثيقة Markdown الناتجة سيناريوهات قابلة للتطبيق، والاستراتيجيات الموصى بها، والمزالق الشائعة، والاستثناءات، والمصدر، وأحدث وقت للتحقق من الصحة. أثناء التقديم، يتم استرجاع هذه المستندات فقط؛ لا يتم إدراج المسارات الخام الطويلة مباشرة في السياق.
->
-> **ثلاثة ضوابط:** الشرط الأول لا يستخدم أي خبرة تاريخية؛ يسترد الثاني ملخص المسار الأكثر تشابهًا مع المهمة الحالية؛ والثالث يسترد وثيقة معرفية مدعومة بمسارات متعددة. يجب أن تكون مجموعات التعلم والنقل منفصلة حتى لا تتسرب الإجابات على نفس سؤال GAIA إلى التقييم باعتباره "خبرة".
->
-> **المقاييس والقبول:** قم بالإبلاغ عن معدل نجاح مهمة النقل، ومتوسط الأحرف أو الرموز المستردة، ومعدل النقل السلبي، وتحقق من أن كل استنتاج رسمي يستشهد بمسارات مصدره. إذا كانت المستندات عبر المسارات تؤدي فقط إلى تقصير السياق دون تحسين أداء المهام الجديدة، فإنها لا تثبت الخبرة المكتسبة. تفشل التجربة أيضًا إذا كان من الممكن ترقية نجاح عرضي مباشر إلى المعرفة الرسمية أو إذا لم يكن من الممكن تتبع الوثيقة إلى مساراتها الأصلية.
->
-> التنفيذ المصاحب متاح في مشروع [`gaia-experience`](https://github.com/bojieli/ai-agent-book/tree/main/chapter8/gaia-experience). يتم تشغيل `demo_documents.py` دون اتصال بشكل افتراضي؛ مع `--extractor llm`، يمكن لـ LLM الحقيقي أن يقترح مرشحين ذوي خبرة عبر المسارات.
-
 [^reflexion-2023]: شين، N.، وآخرون. *التأمل: وكلاء اللغة مع التعلم المعزز اللفظي.* أرخايف:2303.11366، 2023.
 
 [^gaia-2023]: ميالون، G.، وآخرون. *GAIA: معيار لمساعدي الذكاء الاصطناعي العام.* arXiv:2311.12983, 2023.
@@ -113,13 +101,27 @@
 
 وتعلّمُ الـ Prompt النظامي ليس هو هندسةَ المطالبات في الفصل الثاني. فذلك الفصل ناقش كيف تُنظَّم مطالبة جيدة؛ أما هذا القسم فيناقش أيَّ تغذية راجعة تكفي لتفعيل تعديل، وكيف يُطلَق مقترح التحديث بأمان. وينبغي أن يكون التعديل diff أدنى مقترنًا بمصدره، لا إعادةَ كتابة المطالبة كاملةً في كل مرة — وهذا بالضبط نمط «الـ diff الأدنى مع إمكانية التراجع» الذي سُمِّي في الفصل الأول. ويجب اختبار النسخة المرشَّحة في آنٍ واحد على **مجموعة الحدود التي أطلقت الإخفاق** وعلى **مجموعة احتفاظ تعمل أصلًا بصورة سليمة**: فالأولى ينبغي أن تتحسن، والثانية لا يجوز أن تتراجع.
 
-#### المثال الأول: تحسين القواعد في المطالبات بناءً على مسارات الفشل
+#### المثال الأول: تحويل حدّ التحويل إلى قواعد
+
+في سياسة نطاق telecom من τ²-bench، لا يحكم التحويل إلى موظف بشري سوى نصّين مبدئيين: لا تُحوِّل إلا إذا خرج الطلب عن نطاق أفعال الوكيل، وابذل وسعك في الحل قبل التحويل. حين شرّح الفصل السابع هذه البيئة لم يُظهر هذان السطران أي خلل؛ لكن شغِّل البيئة نفسها بنموذج أضعف فيبرز النقص فورًا — بعد أن تُعيد الأداة خطأً يعاود الوكيل المحاولة مرارًا، ثم ينهي الأمر بالتحويل إلى موظف بشري. بهذه الطريقة انتهت 19 مهمة من أصل 20 في مجموعة الاستخلاص.
 
-استعان الفصل السابع بـ τ-bench/τ²-bench لبيان طريقة تقييم وكيل خدمة عملاء شركة طيران: يكشف المستخدم حاجاته تدريجيًا، ويفحص النظام حالةَ البيئة مثل الحجز، كما يفحص هل قُدِّمت المعلومات الضرورية في الحوار. كما شدّد عزوُ الإخفاق في ذلك الفصل على أنه لا يكفي تسجيل «إخفاق»، بل يجب العثور على **أول خطوة خاطئة**.
+سلِّم هذه المسارات التسعة عشر الفاشلة إلى نموذج، ودعه يستنبط بنفسه بضع قواعد قابلة للتنفيذ تُضاف إلى نهاية السياسة، ثم أعد التشغيل على مجموعة مهام لم تشارك في الاستخلاص إطلاقًا: ترتفع نسبة النجاح من 12.3% إلى 19.3%، ولا تُفسَد ولا مهمة واحدة كانت تنجح من قبل.
 
-والحالة المشكلة هنا هي: يستاء المستخدم من الاسترداد أو رسوم التغيير أو سياسة الأمتعة، فيستدعي الوكيلُ `transfer_to_human` من غير أن يراجع السياسة أو يشرح القاعدة أو يبحث عن بديل مسموح. والخلاف العادي حول السياسة لا يستوجب تحويلًا؛ **وإنما يجب التحويل حين يطلب المستخدم موظفًا بشريًا صراحةً، أو حين ينشأ خطر على السلامة أو على الأشخاص**. فالمشكلة إذن ليست أن «الوكيل غير مهذب بما يكفي»، بل أن المطالبة لم تكتب حدود التحويل كتابةً واضحة.
+**ما يُعرَض على المستخلِص هو ما يحدد ما يستطيع استنباطه.** من المسارات التسعة عشر نفسها، يؤدي الاكتفاء بملخّصات الإخفاق ونصوص الأخطاء إلى «لا تواصل استدعاء أداة تعيد الخطأ نفسه مرارًا»؛ أما إضافة قائمة بالأدوات التي يملكها الوكيل وتلك التي يملكها المستخدم فتحوّل النتيجة إلى «فحص حالة الشبكة وشريحة SIM وإعدادات APN يخص جهاز المستخدم، وينبغي توجيه المستخدم لتنفيذه بنفسه بدل استدعائه مباشرة». الأول تسجيل لدرس، والثاني إدراك لموضع المسؤولية.
+
+**يتعامل النموذج مع السلوك الملاحَظ بوصفه السلوك الواجب.** جاء في قواعد النسخة الأولى بندان: «حوِّل إلى موظف بشري بعد ثلاثة استدعاءات فاشلة متتالية»، و«حوِّل إلى موظف بشري إن لم يقدّم المستخدم رقمه بعد طلبين» — وأكثر ما يتكرر في المسارات هو التحويل إلى البشر، فعدّه النموذج ملاذًا أخيرًا معقولًا. غير أن التحويل في هذا التقييم يُحكم عليه بالإخفاق حتمًا، فهذان البندان يكتبان الإخفاق في صلب اللائحة. لذلك لا يجوز نشر ناتج الاستخلاص مباشرة، بل عليه أن يمر بتحقق مستقل عمّا أنتجه.
+
+**ما يُصلَح غالبًا ما يكون شيئًا بالغ البساطة.** في الذراع الأساسي مسار نموذجي: يحتاج الوكيل إلى رقم هاتف المستخدم فيستدعي أداة الاستعلام، وقد وضع في المعامل عبارة «يُرجى تزويدي برقم هاتفك» — خمس مرات متتالية، وخمسة أخطاء، ثم التحويل. لقد استنتج فعلًا أن عليه سؤال المستخدم، إلا أنه وجّه هذه الجملة إلى الأداة. وبعد سريان القواعد صار يطلب الرقم أولًا داخل الحوار، ثم يستعلم بعد الحصول عليه؛ ولمّا رفضت طبقة الأدوات محاولته فحص حالة شريحة SIM، انتقل إلى توجيه المستخدم لإعادة تركيب الشريحة بنفسه، ونجحت المهمة.
+
+> **التجربة 9-2 ★★: استخلاص قواعد التحويل واستخدام الأدوات من مسارات τ²-bench الفاشلة**
+>
+> تُستعمل بيئة τ²-bench telecom من الفصل السابع كما هي. ومجموعة الاستخلاص ومجموعة النقل هما أصلًا مجموعتا مهام متباينتان في المستودع الأصلي، فلا تمس عملية الاستخلاص مجموعة النقل البتة.
+>
+> شغِّل أولًا مجموعة الاستخلاص بنموذج ضعيف واحفظ المسارات الفاشلة؛ ولتستنبط القواعدَ نموذجٌ لا إنسان، وتُضاف بعد توليدها إلى نهاية السياسة الأصلية؛ ثم قارن على مجموعة النقل بين السياسة الأصلية والنسختين المتطورتين. ولا يُستبدل بين الأذرع الثلاثة سوى ملف السياسة، ويبقى محاكي المستخدم ثابتًا.
+>
+> وإلى جانب نسبة النجاح ينبغي تسجيل ثلاثة مؤشرات سلوكية تقابل القواعد مباشرة: نسبة التحويل إلى البشر، وعدد المرات التي يتجاوز فيها الوكيل حدوده فيستدعي أداة من جانب المستخدم، وعدد الاستدعاءات الصادرة بمعامل ناقص. وقد انخفض المؤشران الأخيران نحو 80% في النسختين المتطورتين، وهو ما يبيّن أن ارتفاع نسبة النجاح ناتج عن إصلاح القواعد لأفعال بعينها.
 
-ويتحول هذا التشخيص مباشرةً إلى قاعدة واحدة داخل المطالبة: راجع السياسة أولًا واشرحها، وتبيّن الهدف الذي يريد المستخدم حلّه فعلًا، واعرض بديلًا موافقًا للأنظمة؛ ولا تحوّل إلا عند طلب موظف بشري صراحةً، أو عند تجاوز الصلاحية أو تعلّق الأمر بالسلامة.
+ويمكن نقل الأسلوب نفسه إلى مجالات أخرى. والحالة الإشكالية النمطية لوكيل خدمة عملاء طيران هي التالية: يعترض المستخدم على رسوم الاسترداد أو رسوم التغيير أو سياسة الأمتعة، فيستدعي الوكيل `transfer_to_human` من غير أن يراجع السياسة أو يشرح القاعدة أو يبحث عن بديل متوافق. والخلاف العادي حول السياسات لا يستدعي التحويل؛ **ولا يصير التحويل واجبًا إلا بطلب صريح لموظف بشري، أو عند نشوء موقف يتصل بالسلامة**. ويشير التشخيص مجددًا إلى حدّ تحويل لم يُنص عليه صراحة، ويظل الإصلاح هو تحويله إلى قاعدة واحدة صغرى موثّقة المصدر.
 
 > **التجربة 9-3 ★★: تحسين المطالبة النظامية لخدمة عملاء الطيران انطلاقًا من المسارات الفاشلة**
 >