قابلية مراقبة وكلاء LLM: التتبع وحلقات التقييم وتصحيح الأخطاء في الإنتاج
⏱️ وقت القراءة المقدر: 9 دقائق
لماذا يفقد التسجيل معناه في بيئة الوكلاء
يُؤدي التسجيل التقليدي مهمته جيداً مع استدعاءات LLM الفردية: تسجيل أزواج الإدخال والإخراج، وقياس زمن الاستجابة، والتقاط الأخطاء.
الصورة تتغير حين ننتقل إلى الوكلاء المتعددين. يستدعي الوكيل الأدوات من تلقاء نفسه، ويُحيل التحكم إلى وكلاء آخرين، ويتسلسل عبر استدعاءات LLM متعددة. لمعرفة أين أخفق الوكيل ولماذا، لا يكفي معرفة “ما الذي جرى”، بل يجب إعادة بناء “بأي ترتيب، وفي أي سياق، واتُّخذت أي قرارات”.
خلص تحليل عام 2025 إلى أن نحو 65% من إخفاقات الوكلاء لا تعود إلى قدرات النموذج، بل إلى مشكلات في تركيب السياق. بلا قابلية للمراقبة، يستحيل تشخيص هذا النوع من الإخفاقات.
العناصر الثلاثة لتتبع الوكلاء
1. النطاقات المتشعبة
تنفيذ الوكيل هو هيكل شجري: النطاق الجذر يُغلّف تنفيذ الوكيل بالكامل، والنطاقات الفرعية تُمثل كل استدعاء LLM واستدعاء أداة واستدعاء وكيل فرعي.
إن اخترت التنفيذ المباشر على OpenTelemetry، فاتبع هذه البنية:
with tracer.start_as_current_span("agent_run") as root_span:
root_span.set_attribute("agent.name", "research_agent")
root_span.set_attribute("input.query", query)
with tracer.start_as_current_span("llm_call") as llm_span:
llm_span.set_attribute("model", "claude-sonnet-4-6")
llm_span.set_attribute("prompt_tokens", prompt_tokens)
response = llm.invoke(prompt)
llm_span.set_attribute("completion_tokens", completion_tokens)
with tracer.start_as_current_span("tool_call") as tool_span:
tool_span.set_attribute("tool.name", "web_search")
tool_span.set_attribute("tool.input", search_query)
result = search_tool.run(search_query)
المحوري هنا هو نقل علاقة الأب بالابن عبر سياق النطاق. في تحويلات الوكلاء المتعددين، يجب أن ينتقل هذا النقل عبر حدود الوكلاء.
2. تتبع الذاكرة والحالة
يجب تسجيل السياق الذي كان لدى الوكيل في كل خطوة. في الوكلاء طويلة التشغيل تحديداً، يُعدّ تتبع تطور السياق أمراً لا غنى عنه في التشخيص.
احفظ لقطات الحالة عند كل نقطة قرار رئيسية. إن كانت اللقطات الكاملة عبئاً ثقيلاً في الإنتاج، يكفي تسجيل تجزئة الحالة والفروقات للتمكن من إعادة البناء.
3. إسناد التكاليف
لا يكفي في خطوط الأنابيب المتعددة الوكلاء تجميع التكاليف فحسب. يجب النزول إلى مستوى النطاق لمعرفة أي خطوة في أي وكيل استهلكت الرموز، لتحديد اتجاه تحسين التكاليف.
# إضافة إسناد التكاليف إلى النطاق
span.set_attribute("cost.input_tokens", input_tokens)
span.set_attribute("cost.output_tokens", output_tokens)
span.set_attribute("cost.model_tier", "sonnet") # haiku/sonnet/opus
span.set_attribute("cost.estimated_usd", estimated_cost)
تصميم حلقة التقييم
إن أجاب التتبع على “ماذا جرى”، فإن التقييم يُجيب على “هل سارت الأمور على ما يرام”. الطبقتان مختلفتان.
التقييم دون اتصال مقابل التقييم المتصل
التقييم دون اتصال يتحقق من تغييرات النموذج والتلقين قبل النشر باستخدام مجموعة بيانات مرجعية ثابتة. دمجه في خط أنابيب CI/CD يُمسك بالانحدارات.
التقييم المتصل يُراقب مقاييس الجودة بأخذ عينات من آثار الإنتاج في الوقت الحقيقي، ويرصد الانجراف في التوزيع أو مشكلات التلقين بعد النشر.
يجب تشغيل كلاهما معاً. الاتكاء على التقييم دون اتصال وحده يُفوّت تغيرات توزيع البيانات الفعلية في الإنتاج، بينما يعني الاقتصار على التقييم المتصل غياب بوابة الجودة قبل النشر.
مخاطر التقييم التلقائي القائم على LLM
شاع توظيف LLM مُقيِّماً، لكن الأمر يستلزم يقظة. استخدام نفس النموذج للتوليد وللتقييم يُولّد تحيز التعزيز الذاتي. يُستحسن استخدام نماذج مختلفة للتوليد والتقييم كلما أمكن.
علاوة على ذلك، يجب أن يتفحص الإنسان دورياً موثوقية حكم LLM المقيِّم ذاته، وتتبع ارتباط درجات التقييم التلقائي بالتغذية الراجعة الفعلية للمستخدمين.
اختيار مقاييس التقييم
تتباين المقاييس باختلاف نوع المهمة:
| نوع المهمة | أمثلة على المقاييس |
|---|---|
| استرجاع المعلومات | الصلة، الاكتمال، الدقة الواقعية |
| توليد الكود | معدل اجتياز الاختبارات، الثغرات الأمنية، الالتزام بأسلوب الكتابة |
| استخدام الأدوات | صحة اختيار الأداة، دقة المعاملات |
| الاستدلال متعدد الخطوات | دقة الخطوات الوسيطة، دقة الإجابة النهائية |
ينبغي كبح الرغبة في تلخيص جودة الوكيل برقم واحد. تتبع مقاييس متعددة الأبعاد وبناء بنية تُرسل إنذارات حين يهبط أي مقياس تحت عتبته أكثر فائدة.
اختيار المنصة: MLflow مقابل LangSmith مقابل Arize
المنصات الثلاث جاهزة للإنتاج، لكن نقاط قوتها تختلف.
MLflow مفتوح المصدر مما يُتيح الاستضافة الذاتية، ويوفر ميزة إعادة تشغيل الوكلاء في التتبع. يتكامل بسهولة مع سير عمل تتبع تجارب ML القائمة. مناسب للبيئات المؤسسية التي تجد صعوبة في إرسال البيانات خارجياً.
LangSmith متكامل عمقاً مع نظام LangChain البيئي. تتميز بآثار عالية الدقة تُصيّر شجرة تنفيذ الوكيل الكاملة. توفر إدارة التلقين والتقييم معاً.
Arize AI تتميز بتتبع على مستوى النطاق ولوحات بيانات فورية على نطاق مؤسسي. تُتيح مكتبة Phoenix مفتوحة المصدر البدء من بيئة التطوير المحلية.
تدعم المنصات الثلاث التكامل مع الأطر الرئيسية مثل LangGraph وOpenAI Agents SDK وCrewAI.
أنماط تصحيح الأخطاء في الإنتاج
إعادة إنتاج آثار الإخفاق
لإعادة إنتاج إخفاق الوكيل محلياً، يلزم حفظ لقطة من الحالة الكاملة عند الإخفاق (الاستعلام الأولي، جميع نتائج استدعاءات الأدوات، حالة الذاكرة). يُتيح تشغيل الوكيل ذاته محلياً بهذه اللقطة إعادة إنتاج الإخفاق.
توفر MLflow لهذا الغرض ميزة إعادة تشغيل الوكلاء: يمكن اختيار نطاق معين من الأثر وإعادة تشغيل التنفيذ من تلك النقطة.
رصد انجراف السياق
نمط إخفاق متكرر في الوكلاء طويلة التشغيل: نسيان الوكيل هدفه الأولي أو تصرفه بما يناقض المعلومات التي جمعها سابقاً.
مقاييس التشخيص: تتبع نسبة استخدام نافذة السياق، وقياس التشابه الدلالي بين التعليمات الأولية والسلوك الراهن للوكيل، وتتبع مدى اختلاف أنماط استدعاء الأدوات عن الخطوات السابقة.
تصنيف أنماط أخطاء الأدوات
لا تكتفِ بالنظر إلى معدل الخطأ الكلي لاستدعاءات الأدوات، بل صنّفها حسب النوع:
- أخطاء المعاملات: الوكيل يُمرر مدخلات بتنسيق خاطئ للأداة. السبب عادة غموض مواصفة الأداة أو وصف سيئ لأسلوب استخدامها في تلقين الوكيل.
- انتهاء المهلة: شائع في الأدوات المعتمدة على APIs خارجية. يستلزم منطق إعادة المحاولة وقاطع الدائرة.
- أخطاء الصلاحيات: الوكيل يحاول استدعاء أداة تتجاوز نطاق صلاحياته.
مشاهدة تكرار كل نوع جنباً إلى جنب مع سياق الوكيل تكشف الأسباب الجذرية المنهجية.
ترتيب بناء قابلية المراقبة
بناء منظومة كاملة من الصفر يستغرق وقتاً طويلاً؛ المقاربة التدريجية أكثر واقعية.
المرحلة 1: تسجيل عدد الرموز وزمن الاستجابة لكل استدعاء LLM. يكفي هذا لفهم التكاليف وتحديد نقاط الاختناق.
المرحلة 2: إضافة نطاقات استدعاء الأدوات. يُوضّح أي الأدوات يُخفق وبأي معدل.
المرحلة 3: تغليف تنفيذ الوكيل بأكمله في نطاق جذر وبناء شجرة متشعبة.
المرحلة 4: بناء مجموعة بيانات تقييم دون اتصال للمهام الأساسية ودمجها في CI.
المرحلة 5: إضافة تقييم متصل قائم على أخذ عينات من آثار الإنتاج.
لا تُحاول تنفيذ المراحل الخمس دفعة واحدة؛ استقرار المرحلتين الأولى والثانية أولاً ثم البناء التدريجي هو النهج المستدام.
خلاصة
تشغيل وكلاء الإنتاج بلا قابلية مراقبة يشبه قيادة طائرة بلا أجهزة قياس: يبدو الأمر على ما يرام حين تسير الأمور حسناً، لكن حين يحدث خطأ لا توجد طريقة لمعرفة مصدره.
التتبع وإسناد التكاليف وحلقات التقييم ليست اختيارية بل هي متطلبات تشغيلية لوكلاء الإنتاج. لا بأس بالبدء بسيطاً؛ لكن البدء بلا أي منظومة بنية على تأجيلها لاحقاً يعني الوقوع في الاضطرار إلى بناء البنية التحتية بعد تراكم أنماط الإخفاق.