مع انتقال وكلاء الذكاء الاصطناعي من نماذج تجريبية إلى تطبيقات في العالم الحقيقي، تصبح القدرة على فهم سلوكهم، ومراقبة أدائهم، وتقييم مخرجاتهم بشكل منهجي أمراً مهماً.
بعد إكمال هذا الدرس، ستعرف كيفية/وتفهم:
- المفاهيم الأساسية لرصد الوكلاء وتقييمهم
- تقنيات تحسين الأداء والتكاليف وفعالية الوكلاء
- ما الذي يجب تقييمه وكيفية تقييم وكلاء الذكاء الاصطناعي لديك بشكل منهجي
- كيفية التحكم في التكاليف عند نشر وكلاء الذكاء الاصطناعي في الإنتاج
- كيفية قياس أدوات الوكلاء المبنية باستخدام AutoGen
الهدف هو تزويدك بالمعرفة اللازمة لتحويل وكلائك "صناديق سوداء" إلى أنظمة شفافة، قابلة للإدارة، ومعتمدة.
ملاحظة: من المهم نشر وكلاء ذكاء اصطناعي آمنين وموثوقين. اطلع أيضاً على درس بناء وكلاء ذكاء اصطناعي موثوقين.
تمثل أدوات الرصد مثل Langfuse أو Microsoft Foundry عادة تشغيلات الوكلاء كتتبعات وسبانات.
- Trace تمثل مهمة وكيل كاملة من البداية إلى النهاية (مثل التعامل مع استعلام مستخدم).
- Spans هي خطوات فردية داخل التتبع (مثل استدعاء نموذج لغوي أو استرجاع بيانات).
بدون الرصد، قد يبدو وكيل الذكاء الاصطناعي كـ"صندوق أسود" - حالته الداخلية ومنطقه غامضان، مما يصعّب تشخيص المشكلات أو تحسين الأداء. مع الرصد، يصبح الوكلاء "صناديق زجاجية"، مما يوفر شفافية ضرورية لبناء الثقة وضمان عملهم كما ينبغي.
يؤدي انتقال وكلاء الذكاء الاصطناعي إلى بيئات الإنتاج إلى ظهور مجموعة جديدة من التحديات والمتطلبات. لم يعد الرصد ميزة "ممتازة إن وُجدت" بل أصبح قدرة حاسمة:
- التقصي وتحليل الأسباب الجذرية (Debugging and Root-Cause Analysis): عندما يفشل الوكيل أو ينتج مخرجاً غير متوقع، توفر أدوات الرصد التتبعات اللازمة لتحديد مصدر الخطأ. هذا مهم بشكل خاص في الوكلاء المعقدين الذين قد يتضمنون عدة استدعاءات لـLLM، وتفاعلات مع أدوات، ومنطق شرطية.
- إدارة الكمون والتكلفة: كثيراً ما تعتمد الوكلاء على نماذج لغوية كبيرة وواجهات برمجة خارجية تُحاسب حسب التوكن أو كل استدعاء. يسمح الرصد بتتبع هذه الاستدعاءات بدقة، مما يساعد في تحديد العمليات البطيئة أو المكلفة بشكل مفرط. يتيح ذلك للفرق تحسين المطالبات، اختيار نماذج أكثر كفاءة، أو إعادة تصميم سير العمل للتحكم في التكاليف التشغيلية وضمان تجربة مستخدم جيدة.
- الثقة والسلامة والامتثال: في العديد من التطبيقات، من المهم التأكد من أن الوكلاء يتصرفون بأمان وأخلاقية. يوفر الرصد سجلاً تدقيقياً لإجراءات وقرارات الوكيل. يمكن استخدام هذا لاكتشاف ومعالجة مشكلات مثل حقن المطالبات، إنتاج محتوى ضار، أو التعامل غير السليم مع المعلومات التعريفية الشخصية (PII). على سبيل المثال، يمكنك مراجعة التتبعات لفهم سبب تقديم الوكيل لإجابة معينة أو استخدام أداة محددة.
- دوائر التحسين المستمرة: تُعد بيانات الرصد أساس عملية تطوير تكرارية. من خلال مراقبة أداء الوكلاء في العالم الحقيقي، يمكن للفرق تحديد مجالات للتحسين، جمع بيانات لضبط النماذج، والتحقق من تأثير التغييرات. يخلق هذا حلقة تغذية راجعة حيث تُعلم رؤى الإنتاج من التقييم عبر الإنترنت التجارب المختبرية والتكرار، ما يؤدي إلى تحسين أداء الوكلاء تدريجياً.
لمراقبة وفهم سلوك الوكيل، يجب تتبع مجموعة من المقاييس والإشارات. بينما قد تختلف المقاييس المحددة بناءً على غرض الوكيل، هناك بعض المقاييس الشائعة ذات الأهمية العالمية.
فيما يلي بعض من أشهر المقاييس التي تراقبها أدوات الرصد:
Latency: ما مدى سرعة استجابة الوكيل؟ تؤثر أوقات الانتظار الطويلة سلباً على تجربة المستخدم. يجب قياس الكمون للمهام والخطوات الفردية عن طريق تتبع تشغيلات الوكيل. على سبيل المثال، وكيل يستغرق 20 ثانية لجميع استدعاءات النموذج يمكن تسريع عمله باستخدام نموذج أسرع أو تشغيل استدعاءات النماذج بالتوازي.
Costs: ما تكلفة كل تشغيل للوكيل؟ تعتمد وكلاء الذكاء الاصطناعي على استدعاءات LLM التي تُحاسب حسب التوكن أو واجهات برمجة خارجية. يمكن أن يؤدي استخدام الأدوات بشكل متكرر أو وجود عدة مطالبات إلى زيادة التكاليف بسرعة. على سبيل المثال، إذا كان الوكيل يستدعي نموذجاً لغوياً خمس مرات لتحسين طفيف في الجودة، يجب تقييم ما إذا كانت التكلفة مبررة أم يمكنك تقليل عدد الاستدعاءات أو استخدام نموذج أرخص. يمكن أن تساعد المراقبة في الوقت الحقيقي أيضاً في تحديد الارتفاعات غير المتوقعة (مثل أخطاء تؤدي إلى حلقات استدعاء مفرطة في API).
Request Errors: كم عدد الطلبات التي فشل فيها الوكيل؟ يمكن أن يشمل ذلك أخطاء API أو فشل استدعاءات الأدوات. لجعل وكيلك أكثر صلابة أمام هذه الحالات في الإنتاج، يمكنك إعداد آليات احتياطية أو إعادة محاولة. مثلاً إذا كان مزود LLM A معطلاً، تنتقل إلى مزود LLM B كنسخة احتياطية.
User Feedback: تنفيذ تقييمات المستخدم المباشرة يوفر رؤى قيمة. يمكن أن يشمل ذلك تقييمات صريحة (👍إعجاب/👎عدم إعجاب، ⭐1-5 نجوم) أو تعليقات نصية. يجب أن تنبهك التعليقات السلبية المتكررة لأنها علامة على أن الوكيل لا يعمل كما هو متوقع.
Implicit User Feedback: سلوكيات المستخدم توفر ملاحظات غير مباشرة حتى دون تقييمات صريحة. يمكن أن يشمل ذلك إعادة صياغة السؤال فوراً، تكرار الاستفسارات أو النقر على زر المحاولة مرة أخرى. على سبيل المثال، إذا رأيت أن المستخدمين يطرحون نفس السؤال مراراً، فهذه علامة على أن الوكيل لا يعمل كما هو متوقع.
Accuracy: كم مرة ينتج الوكيل مخرجات صحيحة أو مرغوبة؟ تختلف تعريفات الدقة (مثل صحة حل المشكلات، دقة استرجاع المعلومات، رضا المستخدم). الخطوة الأولى هي تحديد شكل النجاح لوكيلك. يمكنك تتبع الدقة عبر الفحوصات الآلية، درجات التقييم، أو تسميات إتمام المهمة. على سبيل المثال، تعليم التتبعات كـ "ناجح" أو "فشل".
Automated Evaluation Metrics: يمكنك أيضاً إعداد تقييمات آلية. على سبيل المثال، يمكنك استخدام LLM لتقييم مخرجات الوكيل، مثلاً إذا كانت مفيدة أو دقيقة أم لا. هناك أيضاً عدة مكتبات مفتوحة المصدر تساعدك على تسجيل جوانب مختلفة من الوكيل. على سبيل المثال RAGAS لوكلاء RAG أو LLM Guard لاكتشاف اللغة الضارة أو حقن المطالبات.
عملياً، يعطي مزيج من هذه المقاييس أفضل تغطية لصحة وكيل الذكاء الاصطناعي. في دفتر الملاحظات example notebook في هذا الفصل، سنعرض كيف تبدو هذه المقاييس في أمثلة حقيقية لكن أولاً، سنتعلم كيف يبدو سير عمل التقييم النموذجي.
لجمع بيانات التتبعات، ستحتاج إلى قياس كودك. الهدف هو قياس كود الوكيل لإصدار تتبعات ومقاييس يمكن التقاطها ومعالجتها وتصويرها بواسطة منصة رصد.
OpenTelemetry (OTel): OpenTelemetry بروز كمعيار صناعي لرصد LLM. يوفر مجموعة من واجهات برمجة التطبيقات، وSDKs، وأدوات لتوليد وجمع وتصدير بيانات القياس.
هناك العديد من مكتبات القياس التي تغلف أطر عمل الوكلاء الحالية وتجعل من السهل تصدير سبانات OpenTelemetry إلى أداة رصد. أدناه مثال على قياس وكيل AutoGen باستخدام مكتبة القياس OpenLit:
import openlit
openlit.init(tracer = langfuse._otel_tracer, disable_batch = True)سيعرض دفتر الملاحظات المثال في هذا الفصل كيفية قياس وكيل AutoGen الخاص بك.
إنشاء السبان يدوياً: بينما توفر مكتبات القياس قاعدة جيدة، هناك حالات غالباً ما تحتاج فيها إلى معلومات أكثر تفصيلاً أو مخصصة. يمكنك إنشاء سبانات يدوياً لإضافة منطق تطبيق مخصص. والأهم من ذلك، يمكنك إثراء السبانات المُنشأة تلقائياً أو يدوياً بسمات مخصصة (المعروفة أيضاً بالوسوم أو بيانات التعريف). يمكن أن تتضمن هذه السمات بيانات خاصة بالعمل، حسابات وسيطة، أو أي سياق قد يكون مفيداً للتصحيح أو التحليل، مثل 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 (حيث يعمل إصدار جديد من الوكيل بالتوازي للمقارنة مع القديم). التحدي هو أنه قد يكون من الصعب الحصول على تسميات أو درجات موثوقة للتفاعلات الحية – قد تعتمد على تغذية راجعة المستخدم أو مقاييس لاحقة (مثل هل نقر المستخدم النتيجة أم لا).
لا يستبعد التقييمان عبر الإنترنت وغير المتصل بعضهما البعض؛ فهما يكملان بعضهما كثيراً. يمكن استخدام الرؤى من المراقبة عبر الإنترنت (مثل أنواع جديدة من استعلامات المستخدم التي يؤدّي فيها الوكيل بشكل سيئ) لتعزيز وتحسين مجموعات الاختبار غير المتصلة. وعلى العكس، الوكلاء الذين يؤدون جيداً في اختبارات غير متصلة يمكن نشرهم ومراقبتهم عبر الإنترنت بثقة أكبر.
في الواقع، تتبنى العديد من الفرق حلقة:
قيّم غير المتصل -> انشر -> راقب عبر الإنترنت -> اجمع حالات الفشل الجديدة -> أضف إلى مجموعة بيانات غير المتصلة -> حسّن الوكيل -> كرر.
عند نشر وكلاء الذكاء الاصطناعي في الإنتاج، قد تواجه تحديات مختلفة. فيما يلي بعض المشكلات الشائعة وحلولها المحتملة:
| المشكلة | الحل المحتمل |
|---|---|
| وكيل الذكاء الاصطناعي لا ينفذ المهام بشكل متسق | - حسّن المطالبة المقدمة للوكيل؛ كن واضحاً حول الأهداف. - حدّد الأماكن التي يمكن فيها تقسيم المهام إلى مهام فرعية ومعالجتها بواسطة وكلاء متعددين. |
| وكيل الذكاء الاصطناعي يدخل في حلقات مستمرة | - تأكد من وجود شروط وأحكام إنهاء واضحة حتى يعرف الوكيل متى يوقف العملية. - للمهام المعقدة التي تتطلب استدلال وتخطيط، استخدم نموذجاً أكبر ومتخصصاً في مهام الاستدلال. |
| استدعاءات أدوات وكيل الذكاء الاصطناعي لا تعمل جيداً | - اختبر وتحقق من مخرجات الأداة خارج نظام الوكيل. - حسّن المعلمات المحددة، والمطالبات، وتسميات الأدوات. |
| نظام متعدد الوكلاء لا يعمل باستقرار | - حسّن المطالبات المقدمة لكل وكيل لضمان أنها محددة ومتميزة عن الأخرى. - بنِ نظاماً هرميًا باستخدام وكيل "توجيه" أو متحكم لتحديد الوكيل الصحيح. |
يمكن تحديد العديد من هذه المشكلات بشكل أكثر فعالية عندما يكون الرصد مفعلًا. تساعد التتبعات والمقاييس التي ناقشناها سابقاً في تحديد بالضبط أين تحدث المشكلات في سير عمل الوكيل، مما يجعل التصحيح والتحسين أسرع بكثير.
Here are some strategies to manage the costs of deploying AI agents to production:
Using Smaller Models: نماذج اللغة الصغيرة (SLMs) يمكن أن تؤدي أداءً جيدًا في بعض حالات الاستخدام المعتمدة على الوكلاء وستقلل التكاليف بشكل كبير. كما ذُكر سابقًا، فإن بناء نظام تقييم لتحديد ومقارنة الأداء مع النماذج الأكبر هو أفضل طريقة لفهم مدى كفاءة SLM في حالة الاستخدام الخاصة بك. ضع في اعتبارك استخدام SLMs للمهام الأبسط مثل تصنيف النية أو استخراج المعلمات، مع الاحتفاظ بالنماذج الأكبر للمهام التي تتطلب استدلالًا معقدًا.
Using a Router Model: استراتيجية مماثلة هي استخدام تنوُّع في النماذج والأحجام. يمكنك استخدام LLM/SLM أو دالة بدون خادم لتوجيه الطلبات بناءً على التعقيد إلى النماذج الأنسب. سيساعد ذلك أيضًا في تقليل التكاليف مع ضمان الأداء في المهام المناسبة. على سبيل المثال، قم بتوجيه الاستفسارات البسيطة إلى نماذج أصغر وأسرع، ولا تستخدم النماذج الكبيرة المكلفة إلا لمهام الاستدلال المعقدة.
Caching Responses: التخزين المؤقت للاستجابات: تحديد الطلبات والمهام الشائعة وتقديم الاستجابات قبل أن تمر عبر نظامك المعتمد على الوكلاء هو وسيلة جيدة لتقليل حجم الطلبات المماثلة. يمكنك حتى تنفيذ سير عمل لتحديد مدى تشابه الطلب مع الطلبات المخزنة مؤقتًا باستخدام نماذج ذكاء اصطناعي أبسط. يمكن أن تقلل هذه الاستراتيجية التكاليف بشكل كبير للأسئلة المتكررة أو سير العمل الشائع.
In the دفتر الملاحظات المثال في هذا القسم, we’ll see examples of how we can use observability tools to monitor and evaluate our agent.
انضم إلى Microsoft Foundry Discord للالتقاء بمتعلمين آخرين، وحضور ساعات الاستشارة والحصول على إجابات لأسئلتك حول وكلاء الذكاء الاصطناعي.
إخلاء المسؤولية: تمت ترجمة هذا المستند باستخدام خدمة الترجمة الآلية Co-op Translator. بينما نسعى إلى الدقة، يرجى العلم أن الترجمات الآلية قد تحتوي على أخطاء أو عدم دقة. يجب اعتبار المستند الأصلي بلغته الأصلية المرجع المعتمد. للمعلومات الحرجة، يُنصح بالاستعانة بترجمة بشرية محترفة. نحن غير مسؤولين عن أي سوء فهم أو تفسير خاطئ ينشأ عن استخدام هذه الترجمة.