ai-agents-for-beginners
وكلاء الذكاء الاصطناعي في الإنتاج: الرصد والتقييم
مع انتقال وكلاء الذكاء الاصطناعي من نماذج تجريبية إلى تطبيقات العالم الحقيقي، تصبح القدرة على فهم سلوكهم، ومراقبة أدائهم، وتقييم مخرجاتهم بشكل منهجي أمرًا مهمًا.
أهداف التعلم
بعد إتمام هذا الدرس، ستعرف كيف/تفهم:
- المفاهيم الأساسية لرصد وتقييم الوكلاء
- تقنيات لتحسين أداء الوكلاء وتكاليفهم وفعاليتهم
- ماذا وكيف تقيم وكلاء الذكاء الاصطناعي لديك بشكل منهجي
- كيفية السيطرة على التكاليف عند نشر وكلاء الذكاء الاصطناعي في الإنتاج
- كيفية تركيب أدوات للرصد لوكلاء تم بناؤهم باستخدام إطار عمل Microsoft Agent
الهدف هو تزويدك بالمعرفة لتحويل وكلائك “الصناديق السوداء” إلى نظم شفافة، يمكن إدارتها، وموثوقة.
ملاحظة: من المهم نشر وكلاء ذكاء اصطناعي آمنين وموثوقين. اطلع أيضًا على درس بناء وكلاء ذكاء اصطناعي موثوقين.
التتبعات والفترات الزمنية
أدوات الرصد مثل Langfuse أو Microsoft Foundry تمثل عادة تشغيل الوكيل كتتبعات وفترات زمنية.
- التتبع يمثل مهمة كاملة للوكيل من البداية إلى النهاية (مثل معالجة استعلام المستخدم).
- الفترات الزمنية هي خطوات فردية داخل التتبع (مثل استدعاء نموذج لغة أو استرجاع بيانات).
بدون الرصد، يمكن أن يبدو وكيل الذكاء الاصطناعي كـ “صندوق أسود” — حالته الداخلية ومنطقه غير واضحة، مما يصعب تشخيص المشكلات أو تحسين الأداء. مع الرصد، يصبح الوكلاء “صناديق زجاجية”، توفر الشفافية الضرورية لبناء الثقة وضمان تشغيلهم كما هو مقصود.
لماذا الرصد مهم في بيئات الإنتاج
يؤدي انتقال وكلاء الذكاء الاصطناعي إلى بيئات الإنتاج إلى تحديات ومتطلبات جديدة. لم يعد الرصد “ميزة مرغوبة” بل قدرة حاسمة:
- تصحيح الأخطاء وتحليل الجذر: عندما يفشل الوكيل أو يُنتج مخرجات غير متوقعة، توفر أدوات الرصد التتبعات اللازمة لتحديد مصدر الخطأ بدقة. هذا مهم خصوصًا في الوكلاء المعقدين الذين قد يتضمنون عدة استدعاءات لنماذج لغة كبيرة، تفاعلات مع أدوات منطقية مشروطة.
- الكمون وإدارة التكلفة: يعتمد وكلاء الذكاء الاصطناعي على نماذج لغة كبيرة وواجهات برمجة تطبيقات خارجية تُفوتر بناءً على عدد الرموز أو الاستدعاءات. يتيح الرصد تتبع هذه الاستدعاءات بدقة، مما يساعد في تحديد العمليات التي تكون بطيئة أو مكلفة جدًا. يمكن للفرق تحسين الطلبات، اختيار نماذج أكثر كفاءة، أو إعادة تصميم سير العمل لإدارة التكاليف التشغيلية وضمان تجربة مستخدم جيدة.
- الثقة، السلامة، والامتثال: في العديد من التطبيقات، من المهم التأكد من أن الوكلاء يتصرفون بأمان وأخلاقية. يوفر الرصد سجلاً تدقيقياً لأفعال الوكيل وقراراته. يمكن استخدامه لاكتشاف ومعالجة مشكلات مثل حقن الطلبات، إنشاء محتوى ضار، أو سوء التعامل مع المعلومات الشخصية المعروفة (PII). على سبيل المثال، يمكنك مراجعة التتبعات لفهم سبب تقديم الوكيل لرد معين أو استخدام أداة محددة.
- دوائر التحسين المستمرة: بيانات الرصد هي أساس عملية تطوير تكرارية. بمراقبة أداء الوكلاء في العالم الحقيقي، يمكن للفرق تحديد مجالات للتحسين، جمع بيانات لضبط النماذج، والتحقق من تأثير التغييرات. يخلق هذا حلقة تغذية راجعة حيث تُعلم رؤى الإنتاج من التقييم الإلكتروني التجريبي التحسينات والتجارب غير المتصلة بالإنترنت، مما يؤدي إلى أداء وكيل أفضل تدريجياً.
المقاييس الأساسية التي يجب تتبعها
لمراقبة وفهم سلوك الوكيل، يجب تتبع مجموعة من المقاييس والإشارات. بينما قد تختلف المقاييس المحددة بناءً على غرض الوكيل، هناك بعض المقاييس الهامة عالميًا.
إليك بعض المقاييس الأكثر شيوعًا التي تراقبها أدوات الرصد:
الكمون: ما مدى سرعة استجابة الوكيل؟ أوقات الانتظار الطويلة تؤثر سلبًا على تجربة المستخدم. يجب قياس الكمون للمهام والخطوات الفردية من خلال تتبع تشغيل الوكيل. على سبيل المثال، وكيل يستغرق 20 ثانية لجميع استدعاءات النموذج يمكن تسريعه باستخدام نموذج أسرع أو بتشغيل الاستدعاءات بشكل متوازي.
التكاليف: ما تكلفة كل تشغيل للوكيل؟ يعتمد وكلاء الذكاء الاصطناعي على استدعاءات نماذج اللغة والفواتير بناءً على الرموز أو واجهات برمجة تطبيقات خارجية. الاستخدام المتكرر للأدوات أو الطلبات المتعددة يمكن أن يزيد التكاليف سريعًا. على سبيل المثال، إذا استدعى الوكيل نموذج لغة خمس مرات لتحسين طفيف في الجودة، يجب تقييم ما إذا كانت التكلفة مبررة أو إذا يمكن تقليل عدد الاستدعاءات أو استخدام نموذج أرخص. تساعد المراقبة في الوقت الحقيقي على تحديد الزيادات غير المتوقعة (مثل الأخطاء التي تسبب حلقات مفرطة في واجهة برمجة التطبيقات).
أخطاء الطلبات: كم عدد الطلبات التي فشل الوكيل في تنفيذها؟ هذا يمكن أن يشمل أخطاء واجهة برمجة التطبيقات أو فشل استدعاءات الأدوات. لجعل الوكيل أكثر متانة ضد هذه الأخطاء في الإنتاج، يمكن إعداد الخطط الاحتياطية أو عمليات إعادة المحاولة. مثلاً، إذا توقف مزود نموذج اللغة A، يتم التبديل إلى مزود B كخطة بديلة.
تغذية المستخدم: يوفر التقييم المباشر من المستخدمين رؤى قيمة. يمكن أن يشمل ذلك تقييمات صريحة (👍إعجاب/👎عدم إعجاب، ⭐1-5 نجوم) أو تعليقات نصية. يجب أن تنبهك التغذية السلبية المستمرة على أن الوكيل لا يعمل كما هو متوقع.
تغذية المستخدم الضمنية: تقدم سلوكيات المستخدم تغذية غير مباشرة حتى بدون تقييمات صريحة. يمكن أن تشمل إعادة صياغة السؤال فورًا، تكرار الاستفسارات، أو الضغط على زر إعادة المحاولة. مثلاً، إذا رأيت أن المستخدمين يكررون نفس السؤال، فهذا علامة على أن الوكيل لا يعمل كما هو متوقع.
الدقة: كم مرة ينتج الوكيل مخرجات صحيحة أو مرغوبة؟ تختلف تعاريف الدقة (مثل صحة حل المشكلات، دقة استرجاع المعلومات، رضا المستخدم). الخطوة الأولى هي تحديد كيف يبدو النجاح لوكيلك. يمكنك تتبع الدقة عبر الفحوصات الآلية، درجات التقييم، أو علامات إكمال المهام. مثال: وضع علامات على التتبعات بأنها “ناجحة” أو “فاشلة”.
مقاييس التقييم الآلي: يمكنك أيضًا إعداد تقييمات آلية. على سبيل المثال، يمكنك استخدام نموذج لغة كبير لتقييم مخرجات الوكيل كمدى فائدتها، دقتها، أو عدمها. هناك أيضًا عدة مكتبات مفتوحة المصدر تساعدك في تقييم جوانب مختلفة من الوكيل. مثل RAGAS لوكلاء RAG أو LLM Guard لاكتشاف اللغة الضارة أو حقن الطلب.
عمليًا، يوفر استخدام مزيج من هذه المقاييس أفضل تغطية لحالة صحة وكيل الذكاء الاصطناعي. في دفتر المثال لهذا الفصل، سنعرض كيف تبدو هذه المقاييس في أمثلة حقيقية، لكن أولًا، سنتعلم كيف يبدو سير عمل التقييم النموذجي.
تركيب أدوات لوكيلك
لجمع بيانات التتبع، ستحتاج إلى تركيب الكود الخاص بك. الهدف هو تركيب كود الوكيل لإصدار التتبعات والمقاييس التي يمكن التقاطها، معالجتها، وتصويرها بواسطة منصة الرصد.
OpenTelemetry (OTel): OpenTelemetry برز كمعيار صناعي لرصد نماذج اللغة الكبيرة. يوفر مجموعة من واجهات برمجة التطبيقات، SDKs، وأدوات لإنشاء وجمع وتصدير بيانات التليمترية.
هناك مكتبات تركيب كثيرة تغلف أُطُر الوكلاء الحالية وتجعل من السهل تصدير الفترات الزمنية OpenTelemetry إلى أداة رصد. يتكامل إطار عمل Microsoft Agent بشكل أصيل مع 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"):
# Agent execution is traced automatically
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) أن تقدم أداءً جيدًا في بعض حالات الاستخدام الوكيلة وستقلل التكاليف بشكل كبير. كما ذُكر سابقًا، فإن بناء نظام تقييم لتحديد ومقارنة الأداء مقابل النماذج الأكبر هو أفضل طريقة لفهم مدى كفاءة النموذج الصغير في حالتك الخاصة. فكر في استخدام نماذج صغيرة للمهام الأبسط مثل تصنيف النية أو استخراج المعاملات، مع تخصيص النماذج الأكبر للاستدلالات المعقدة.
استخدام نموذج الموجه: استراتيجية مشابهة هي استخدام تنوع في النماذج والأحجام. يمكنك استخدام نموذج لغة كبير/صغير أو دالة بدون خادم لتوجيه الطلبات بناءً على التعقيد إلى النماذج الأكثر ملاءمة. هذا سيساعد أيضًا على تقليل التكاليف مع ضمان الأداء في المهام المناسبة. على سبيل المثال، وجّه الاستفسارات البسيطة إلى نماذج أصغر وأسرع، واستخدم النماذج الكبيرة المكلفة فقط لمهام الاستدلال المعقدة.
تخزين الردود مؤقتًا: يعد تحديد الطلبات والمهام الشائعة وتقديم الردود قبل مرورها خلال نظامك الوكيل طريقة جيدة لتقليل حجم الطلبات المماثلة. يمكنك حتى تنفيذ تدفق لتحديد مدى تشابه الطلب مع الطلبات المخزنة مؤقتًا باستخدام نماذج ذكاء اصطناعي أبسط. يمكن أن تقلل هذه الاستراتيجية التكاليف بشكل كبير للأسئلة المتكررة أو سير العمل الشائع.
لنرَ كيف يَعمل هذا في الممارسة
في دفتر الملاحظات النموذجي لهذا القسم، سنرى أمثلة على كيفية استخدام أدوات المراقبة لتتبع وتقييم وكيلنا.
هل لديك المزيد من الأسئلة حول وكلاء الذكاء الاصطناعي في الإنتاج؟
انضم إلى خادم Microsoft Foundry Discord للقاء متعلمين آخرين، وحضور ساعات المكتب، والحصول على إجابات لأسئلتك حول وكلاء الذكاء الاصطناعي.
الدرس السابق
الدرس التالي
تنويه: تمت ترجمة هذا المستند باستخدام خدمة الترجمة بالذكاء الاصطناعي Co-op Translator. بينما نسعى للدقة، يرجى العلم أن الترجمات الآلية قد تحتوي على أخطاء أو عدم دقة. يجب اعتبار المستند الأصلي بلغته الأصلية المصدر الرسمي والمعتمد. للمعلومات الهامة، يُنصح بالاستعانة بترجمة بشرية محترفة. نحن غير مسؤولين عن أي سوء فهم أو تفسير ناتج عن استخدام هذه الترجمة.