ai-agents-for-beginners
وكلاء الذكاء الاصطناعي في الإنتاج: قابلية الرصد والتقييم
مع انتقال وكلاء الذكاء الاصطناعي من نماذج تجريبية إلى تطبيقات العالم الحقيقي، تصبح القدرة على فهم سلوكهم، ومراقبة أدائهم، وتقييم مخرجاتهم بشكل منهجي أمرًا مهمًا.
أهداف التعلم
بعد إكمال هذا الدرس، ستعرف كيف/تفهم:
- المفاهيم الأساسية لقابلية رصد الوكلاء وتقييمهم
- تقنيات لتحسين الأداء والتكاليف وفعالية الوكلاء
- ما الذي يجب تقييمه وكيفية تقييم وكلاء الذكاء الاصطناعي لديك بشكل منهجي
- كيفية التحكم في التكاليف عند نشر وكلاء الذكاء الاصطناعي للإنتاج
- كيفية مراقبة الوكلاء المبنيين باستخدام Microsoft Agent Framework
الهدف هو تزويدك بالمعرفة لتحويل وكلائك “صندوق أسود” إلى أنظمة شفافة، قابلة للإدارة، وموثوقة.
ملاحظة: من المهم نشر وكلاء ذكاء اصطناعي آمنين ويمكن الوثوق بهم. اطلع أيضًا على درس بناء وكلاء ذكاء اصطناعي موثوقين.
الآثار (Traces) والفترات (Spans)
أدوات القابلية للملاحظة مثل Langfuse أو Microsoft Foundry عادةً ما تمثل تنفيذات الوكيل على شكل آثار (traces) وفترات (spans).
- Trace يمثل مهمة الوكيل كاملة من البداية إلى النهاية (مثل معالجة استعلام مستخدم).
- Spans هي خطوات فردية داخل الأثر (مثل استدعاء نموذج لغوي أو استرجاع بيانات).
بدون القابلية للملاحظة، قد يشعر الوكيل وكأنه “صندوق أسود” - حالته الداخلية واستدلاله غير واضحة، مما يصعّب تشخيص المشكلات أو تحسين الأداء. مع القابلية للملاحظة، يصبح الوكلاء “صناديق زجاجية”، مقدمين شفافية ضرورية لبناء الثقة وضمان عملهم كما هو مقصود.
لماذا تهم القابلية للملاحظة في بيئات الإنتاج
نقل وكلاء الذكاء الاصطناعي إلى بيئات الإنتاج يطرح مجموعة جديدة من التحديات والمتطلبات. القابلية للملاحظة لم تعد “ميزة جيدة أن تكون متاحة” بل أصبحت قدرة حرجة:
- إصلاح الأخطاء وتحليل السبب الجذري: عندما يفشل الوكيل أو ينتج مخرجات غير متوقعة، توفر أدوات القابلية للملاحظة الآثار اللازمة لتحديد مصدر الخطأ. هذا مهم بشكل خاص في الوكلاء المعقدين الذين قد يتضمنون استدعاءات متعددة لـ LLMs، وتفاعلات مع أدوات، ومنطقًا شرطياً.
- إدارة الكمون والتكاليف: غالبًا ما يعتمد وكلاء الذكاء الاصطناعي على نماذج لغوية (LLMs) وواجهات برمجة خارجية تُحاسب حسب التوكنات أو الاستدعاءات. تتيح القابلية للملاحظة تتبع هذه الاستدعاءات بدقة، مما يساعد على تحديد العمليات البطيئة أو المكلفة بشكل مفرط. هذا يمكّن الفرق من تحسين المطالبات، اختيار نماذج أكثر كفاءة، أو إعادة تصميم سير العمل للتحكم في التكاليف التشغيلية وضمان تجربة مستخدم جيدة.
- الثقة والسلامة والامتثال: في العديد من التطبيقات، من المهم ضمان أن يتصرف الوكلاء بأمان وبشكل أخلاقي. توفر القابلية للملاحظة مسار تدقيق لإجراءات وقرارات الوكيل. يمكن استخدام ذلك لاكتشاف وتخفيف قضايا مثل حقن المطالبات، أو إنتاج محتوى ضار، أو التعامل غير الصحيح مع المعلومات الشخصية القابلة للتعريف (PII). على سبيل المثال، يمكنك مراجعة الآثار لفهم سبب تقديم الوكيل لإجابة معينة أو لاستخدام أداة محددة.
- دورات التحسين المستمر: بيانات القابلية للملاحظة هي أساس عملية تطوير تكرارية. من خلال مراقبة كيفية أداء الوكلاء في العالم الحقيقي، يمكن للفرق تحديد مجالات للتحسين، جمع بيانات لضبط النماذج، والتحقق من تأثير التغييرات. هذا يخلق حلقة تغذية راجعة حيث تُستخدم رؤى الإنتاج من التقييم عبر الإنترنت لتحسين التجارب والاختبارات غير المتصلة، مما يؤدي إلى أداء وكلاء أفضل تدريجيًا.
المقاييس الرئيسية لتتبعها
لمراقبة وفهم سلوك الوكيل، يجب تتبع مجموعة من المقاييس والإشارات. بينما قد تختلف المقاييس المحددة بناءً على غرض الوكيل، هناك بعض المقاييس الشائعة عالميًا.
فيما يلي بعض من أكثر المقاييس التي تراقبها أدوات القابلية للملاحظة:
الكمون (Latency): ما مدى سرعة استجابة الوكيل؟ أوقات الانتظار الطويلة تؤثر سلبًا على تجربة المستخدم. يجب قياس الكمون للمهام والخطوات الفردية عن طريق تتبع تنفيذات الوكيل. على سبيل المثال، إذا استغرق الوكيل 20 ثانية لجميع استدعاءات النموذج، يمكن تسريعه باستخدام نموذج أسرع أو عن طريق تشغيل استدعاءات النماذج بالتوازي.
التكاليف: ما تكلفة كل تنفيذ للوكيل؟ يعتمد وكلاء الذكاء الاصطناعي على استدعاءات LLM أو واجهات برمجة خارجية تُحاسب حسب التوكنات أو الاستدعاء. الاستخدام المتكرر للأدوات أو المطالبات المتعددة يمكن أن يزيد التكاليف بسرعة. على سبيل المثال، إذا كان الوكيل يستدعي نموذجًا لغويًا خمس مرات لتحسين طفيف في الجودة، يجب تقييم ما إذا كانت التكلفة مبررة أو إذا كان بالإمكان تقليل عدد الاستدعاءات أو استخدام نموذج أرخص. يمكن أيضًا أن تساعد المراقبة في الوقت الحقيقي على تحديد الارتفاعات غير المتوقعة (مثل أخطاء برمجية تسبب حلقات استدعاء مفرطة).
أخطاء الطلبات: كم عدد الطلبات التي فشل فيها الوكيل؟ يمكن أن يشمل ذلك أخطاء API أو نداءات أدوات فاشلة. لجعل وكيلك أكثر متانة في الإنتاج، يمكنك إعداد آليات احتياطية أو إعادة المحاولة. مثال: إذا كان مزود LLM A معطلاً، يمكنك التحويل إلى مزود LLM B كنسخة احتياطية.
ملاحظات المستخدم: توفير تقييمات مستخدمين مباشرة يوفر رؤى قيمة. يمكن أن يشمل هذا تقييمات صريحة (👍thumbs-up/👎down، ⭐1-5 نجوم) أو تعليقات نصية. يجب أن تنبهك التعليقات السلبية المتكررة لأن هذا مؤشر على أن الوكيل لا يعمل كما هو متوقع.
ملاحظات المستخدم الضمنية: توفر سلوكيات المستخدم ملاحظات غير مباشرة حتى بدون تقييمات صريحة. قد يتضمن ذلك إعادة صياغة السؤال فورًا، تكرار الاستفسارات أو النقر على زر المحاولة مرة أخرى. مثال: إذا لاحظت أن المستخدمين يكررون نفس السؤال مرارًا، فهذا مؤشر على أن الوكيل لا يعمل كما هو متوقع.
الدقة: كم مرة ينتج الوكيل مخرجات صحيحة أو مرغوبة؟ تختلف تعريفات الدقة (مثل صحة حل المشكلة، دقة استرجاع المعلومات، رضا المستخدم). الخطوة الأولى هي تحديد شكل النجاح لوكيلك. يمكنك تتبع الدقة عبر فحوصات مؤتمتة، درجات التقييم، أو تسميات إتمام المهام. على سبيل المثال، وضع علامات على الآثار على أنها “ناجحة” أو “فاشلة”.
مقاييس التقييم الآلي: يمكنك أيضًا إعداد تقييمات آلية. على سبيل المثال، يمكنك استخدام LLM لتسجيل مخرجات الوكيل مثل ما إذا كانت مفيدة، دقيقة، أم لا. هناك أيضًا عدة مكتبات مفتوحة المصدر تساعدك في تسجيل جوانب مختلفة من الوكيل، مثل RAGAS لوكلاء RAG أو LLM Guard لاكتشاف اللغة الضارة أو حقن المطالبات.
في الممارسة العملية، يجمع الجمع بين هذه المقاييس أفضل تغطية لحالة صحة وكيل الذكاء الاصطناعي. في دفتر الملاحظات [المثال] في هذا الفصل (./code_samples/10-expense_claim-demo.ipynb)، سنعرض كيف تبدو هذه المقاييس في أمثلة حقيقية لكن أولًا، سنتعلم كيف يبدو سير عمل التقييم النموذجي.
رصد وكيلك
لجمع بيانات التتبع، ستحتاج إلى رصد كودك. الهدف هو رصد كود الوكيل لإصدار آثار ومقاييس يمكن التقاطها ومعالجتها وتصويرها بواسطة منصة قابلية الملاحظة.
OpenTelemetry (OTel): لقد برزت OpenTelemetry كمعيار صناعي لقابلية ملاحظة LLM. توفر مجموعة من واجهات البرمجة، وSDKs، وأدوات لتوليد وجمع وتصدير بيانات التليمتري.
هناك العديد من مكتبات الرصد التي تغلف أطر الوكلاء الموجودة وتجعل من السهل تصدير فترات OpenTelemetry إلى أداة قابلية الملاحظة. يتكامل Microsoft Agent Framework مع OpenTelemetry بشكل أصلي. فيما يلي مثال على رصد وكيل MAF:
from agent_framework.observability import get_tracer, get_meter
tracer = get_tracer()
meter = get_meter()
with tracer.start_as_current_span("agent_run"):
# يتم تتبع تنفيذ الوكيل تلقائيًا
pass
سيوضح دفتر الملاحظات المثال في هذا الفصل كيفية رصد وكيل MAF الخاص بك.
إنشاء الفترات يدويًا: بينما توفر مكتبات الرصد خط أساس جيدًا، هناك غالبًا حالات تحتاج فيها إلى معلومات أكثر تفصيلًا أو مخصصة. يمكنك إنشاء الفترات يدويًا لإضافة منطق تطبيق مخصص. والأهم من ذلك، يمكنك إثراء الفترات التي تم إنشاؤها تلقائيًا أو يدويًا بسمات مخصصة (المعروفة أيضًا بالوسوم أو البيانات الوصفية). يمكن أن تتضمن هذه السمات بيانات خاصة بالأعمال، حسابات وسطية، أو أي سياق قد يكون مفيدًا للتصحيح أو التحليل، مثل user_id, session_id, أو model_version.
مثال على إنشاء آثار وفترات يدويًا باستخدام Langfuse Python SDK:
from langfuse import get_client
langfuse = get_client()
span = langfuse.start_span(name="my-span")
span.end()
تقييم الوكيل
توفر القابلية للملاحظة مقاييس لنا، لكن التقييم هو عملية تحليل تلك البيانات (وأداء الاختبارات) لتحديد مدى كفاءة وكيل الذكاء الاصطناعي وكيف يمكن تحسينه. بمعنى آخر، بمجرد أن تملك تلك الآثار والمقاييس، كيف تستخدمها للحكم على الوكيل واتخاذ القرارات؟
يُعد التقييم المنتظم مهمًا لأن وكلاء الذكاء الاصطناعي غالبًا ما يكونون غير حتميين ويمكن أن يتطوروا (من خلال التحديثات أو انحراف سلوك النموذج) – بدون التقييم، لن تعرف ما إذا كان “الوكيل الذكي” يؤدي وظيفته جيدًا أم أنه تراجع.
هناك فئتان من التقييمات لوكلاء الذكاء الاصطناعي: التقييم عبر الإنترنت و التقييم دون اتصال. كلاهما ذو قيمة، وهما يكملان بعضهما البعض. عادةً ما نبدأ بالتقييم دون اتصال، حيث إنه الحد الأدنى الضروري قبل نشر أي وكيل.
التقييم دون اتصال
يتضمن هذا تقييم الوكيل في بيئة مسيطرة، عادةً باستخدام مجموعات اختبار، وليس استفسارات المستخدم الحي. تستخدم مجموعات بيانات منسقة حيث تعرف ما هي المخرجات المتوقعة أو السلوك الصحيح، ثم تشغل وكيلك عليها.
على سبيل المثال، إذا أنشأت وكيلًا لحل مسائل كلامية رياضية، قد يكون لديك مجموعة اختبار من 100 مسألة بإجابات معروفة. يُجرى التقييم دون اتصال غالبًا أثناء التطوير (ويمكن أن يكون جزءًا من خطوط CI/CD) للتحقق من التحسينات أو الحماية من التراجع. الفائدة هي أنه قابل للتكرار ويمكنك الحصول على مقاييس دقة واضحة لأن لديك الحقيقة المرجعية. قد تقوم أيضًا بمحاكاة استفسارات المستخدم وقياس ردود الوكيل مقابل الإجابات المثالية أو استخدام مقاييس آلية كما وُصف أعلاه.
التحدي الرئيسي مع التقييم دون اتصال هو ضمان أن تكون مجموعة الاختبار شاملة وتبقى ذات صلة – فقد يؤدي أداء الوكيل الجيد على مجموعة اختبار ثابتة إلى مواجهته لاستفسارات مختلفة تمامًا في الإنتاج. لذلك، يجب أن تحافظ على تحديث مجموعات الاختبار بحالات حافة وأمثلة جديدة تعكس سيناريوهات العالم الحقيقي. مزيج من حالات “اختبار سريعة” الصغيرة ومجموعات تقييم أكبر مفيد: مجموعات صغيرة لفحوصات سريعة ومجموعات أكبر لمقاييس الأداء الأوسع.
التقييم عبر الإنترنت
يشير هذا إلى تقييم الوكيل في بيئة حية وواقعية، أي أثناء الاستخدام الفعلي في الإنتاج. يتضمن التقييم عبر الإنترنت مراقبة أداء الوكيل على تفاعلات المستخدم الحية وتحليل النتائج بشكل مستمر.
على سبيل المثال، قد تتبع معدلات النجاح، درجات رضا المستخدم، أو مقاييس أخرى في حركة المرور الحية. ميزة التقييم عبر الإنترنت هي أنه يلتقط أشياء قد لا تتوقعها في بيئة المختبر – يمكنك مراقبة انحراف النموذج بمرور الوقت (إذا تدهور أداء الوكيل مع تغير أنماط الإدخال) والتقاط استفسارات أو حالات غير متوقعة لم تكن في بيانات الاختبار. إنه يوفر صورة حقيقية لكيفية تصرف الوكيل في العالم الواقعي.
غالبًا ما يتضمن التقييم عبر الإنترنت جمع ملاحظات المستخدم الضمنية والصريحة، كما نوقش سابقًا، وربما تشغيل اختبارات ظل أو اختبارات A/B (حيث يعمل إصدار جديد من الوكيل بالتوازي للمقارنة مع القديم). التحدي هو أنه قد يكون من الصعب الحصول على تسميات أو درجات موثوقة للتفاعلات الحية – قد تعتمد على ملاحظات المستخدم أو مقاييس متابعة (مثل هل نقرت المستخدم على النتيجة).
الجمع بين الاثنين
التقييمان عبر الإنترنت ودون اتصال ليسا متضادين؛ بل يكمل كل منهما الآخر بشكل كبير. يمكن استخدام رؤى المراقبة عبر الإنترنت (مثل أنواع جديدة من استفسارات المستخدم حيث يؤدي الوكيل بشكل ضعيف) لإثراء وتحسين مجموعات الاختبار دون الاتصال. وبالمقابل، يمكن نشر وكلاء يؤدون جيدًا في اختبارات دون الاتصال ومراقبتهم عبر الإنترنت بثقة أكبر.
في الواقع، تتبنى العديد من الفرق حلقة:
قيم دون اتصال -> انشر -> راقب عبر الإنترنت -> اجمع حالات الفشل الجديدة -> أضفها إلى مجموعة الاختبار دون الاتصال -> حسّن الوكيل -> كرر.
المشكلات الشائعة
أثناء نشر وكلاء الذكاء الاصطناعي في الإنتاج، قد تواجه تحديات متنوعة. فيما يلي بعض المشكلات الشائعة والحلول المحتملة لها:
| المشكلة | الحل المحتمل |
|---|---|
| وكيل الذكاء الاصطناعي لا ينفّذ المهام بشكل متسق | - صَغّ المطالبة الموجهة إلى وكيل الذكاء الاصطناعي بشكل أوضح؛ كُن محددًا في الأهداف. - حدّد أين يمكن تقسيم المهام إلى مهام فرعية والتعامل معها بواسطة وكلاء متعددين للمساعدة. |
| وكيل الذكاء الاصطناعي يدخل في حلقات مستمرة | - تأكد من وجود شروط إنهاء واضحة حتى يعرف الوكيل متى يوقف العملية. - للمهام المعقدة التي تتطلب استدلالًا وتخطيطًا، استخدم نموذجًا أكبر متخصصًا لمهام الاستدلال. |
| استدعاءات أدوات وكيل الذكاء الاصطناعي لا تعمل جيدًا | - اختبر وتحقق من مخرجات الأداة خارج نظام الوكيل. - حسن المعلمات المعرفة، والمطالبات، وتسميات الأدوات. |
| نظام متعدد الوكلاء لا يعمل بشكل متسق | - حسّن المطالبات الموجهة لكل وكيل لضمان أنها محددة ومتميزة عن بعضها البعض. - أنشئ نظامًا هرميًا باستخدام وكيل “التوجيه” أو وكيل متحكم لتحديد الوكيل الصحيح. |
يمكن تحديد العديد من هذه المشكلات بشكل أكثر فعالية عندما تكون قابلة الملاحظة مفعلة. تساعد الآثار والمقاييس التي ناقشناها سابقًا في تحديد المكان الدقيق في سير عمل الوكيل حيث تحدث المشاكل، مما يجعل تصحيح الأخطاء وتحسين الأداء أكثر كفاءة.
إدارة التكاليف
فيما يلي بعض الاستراتيجيات لإدارة تكاليف نشر وكلاء الذكاء الاصطناعي في بيئة الإنتاج:
استخدام نماذج أصغر: يمكن أن تحقق نماذج اللغة الصغيرة (SLMs) أداءً جيدًا في بعض حالات الاستخدام الوكلائية وتقلل التكاليف بشكل كبير. كما ذُكر سابقًا، فإن بناء نظام تقييم لتحديد ومقارنة الأداء مقابل النماذج الأكبر هو أفضل طريقة لفهم مدى أداء نموذج صغير في حالتك. ضع في اعتبارك استخدام SLMs للمهام الأبسط مثل تصنيف النوايا أو استخراج المعلمات، مع تخصيص النماذج الأكبر للاستدلال المعقد.
استخدام نموذج الموجّه: استراتيجية مماثلة هي استخدام تنوع من النماذج والأحجام. يمكنك استخدام LLM/SLM أو دالة بدون خادم لتوجيه الطلبات بناءً على التعقيد إلى النماذج الأنسب. سيساعد ذلك أيضًا في تقليل التكاليف مع ضمان الأداء في المهام المناسبة. على سبيل المثال، قم بتوجيه الاستعلامات البسيطة إلى نماذج أصغر وأسرع، ولا تستخدم النماذج الكبيرة والمكلفة إلا لمهام الاستدلال المعقدة.
التخزين المؤقت للردود: إن تحديد الطلبات والمهام الشائعة وتقديم الردود قبل أن تمر عبر نظام الوكلاء الخاص بك هو وسيلة جيدة لتقليل حجم الطلبات المتشابهة. يمكنك حتى تنفيذ تدفق لتحديد مدى تشابه الطلب مع الطلبات المخزنة مؤقتًا باستخدام نماذج ذكاء اصطناعي أبسط. يمكن أن تقلل هذه الاستراتيجية التكاليف بشكل كبير للأسئلة المتكررة أو لسير العمل الشائع.
لنرَ كيف يعمل هذا عمليًا
في دفتر الملاحظات المثال لهذا القسم، سنرى أمثلة عن كيفية استخدام أدوات الرصد لتتبع وتقييم وكيلنا.
هل لديك المزيد من الأسئلة حول وكلاء الذكاء الاصطناعي في الإنتاج؟
انضم إلى Microsoft Foundry Discord للقاء متعلمين آخرين، وحضور ساعات الاستشارة، والحصول على إجابات لأسئلتك حول وكلاء الذكاء الاصطناعي.
الدرس السابق
الدرس التالي
إخلاء المسؤولية: تمت ترجمة هذا المستند باستخدام خدمة ترجمة آلية Co-op Translator (https://github.com/Azure/co-op-translator). بينما نسعى لتحقيق الدقة، يُرجى ملاحظة أن الترجمات الآلية قد تحتوي على أخطاء أو معلومات غير دقيقة. يجب اعتبار المستند الأصلي بلغته الأصلية المصدر المعتمد. بالنسبة للمعلومات الحرجة، يُنصح بالاستعانة بترجمة بشرية محترفة. نحن غير مسؤولين عن أي سوء فهم أو تأويل ناتج عن استخدام هذه الترجمة.