كلما أصبح الذكاء الاصطناعي أكثر قدرة على تنفيذ المهام، أصبحت معرفة ما يحدث داخل النظام أثناء التنفيذ أكثر أهمية.
فالنموذج قد يقدم إجابة صحيحة أحيانًا، لكنه قد يستخدم أداة خاطئة أو يستغرق وقتًا طويلًا أو يكرر خطوات غير ضرورية أو يستهلك عددًا كبيرًا من الرموز دون أن تعرف السبب.
هنا يظهر مفهوم AI Observability أو مراقبة أنظمة الذكاء الاصطناعي، ومعه مفهوم Tracing أو تتبع خطوات التنفيذ. الهدف ليس فقط معرفة أن النظام نجح أو فشل، بل معرفة ماذا حدث أثناء تشغيله، وأين حدثت المشكلة، وما الذي أدى إلى النتيجة النهائية.
وتوفر منصات تطوير الوكلاء الحديثة أدوات مخصصة لهذا الغرض. فعلى سبيل المثال، توضح وثائق OpenAI الخاصة بالمراقبة والتكاملات أن الـTracing يمكن أن يسجل تشغيل النموذج واستدعاءات الأدوات والـhandoffs والـguardrails والعمليات المخصصة.
ما هو AI Observability؟
يمكن ترجمة Observability إلى قابلية المراقبة أو القدرة على فهم ما يحدث داخل النظام من خلال البيانات التي ينتجها أثناء التشغيل.
في تطبيق تقليدي قد تراقب أشياء مثل:
- عدد الطلبات.
- زمن الاستجابة.
- الأخطاء.
- استهلاك الموارد.
- حالة الخوادم.
لكن تطبيق الذكاء الاصطناعي يحتاج إلى رؤية إضافية، لأن هناك نموذجًا لغويًا قد يتخذ قرارات مختلفة، وأدوات خارجية، وسياقًا، وعمليات استرجاع للمعلومات، وربما عدة وكلاء يعملون معًا.
لذلك يمكن أن تشمل مراقبة نظام AI معلومات مثل:
- النموذج الذي تم استخدامه.
- الطلبات والاستجابات.
- الأدوات التي تم استدعاؤها.
- ترتيب خطوات التنفيذ.
- زمن كل خطوة.
- عدد الرموز المستخدمة.
- الأخطاء والاستثناءات.
- نتيجة كل خطوة.
- النتيجة النهائية للمهمة.
وتوضح وثائق Google Cloud الخاصة بمراقبة وكلاء الذكاء الاصطناعي أن جمع بيانات مثل الطلبات والاستجابات واستخدام الرموز يمكن أن يساعد في تقييم جودة المخرجات واكتشاف المشكلات وتحسين استهلاك الموارد.
ما هو AI Tracing؟
إذا كان الـObservability هو الصورة الكبيرة عن حالة النظام، فإن Tracing يساعدك على تتبع رحلة تنفيذ طلب معين خطوة بخطوة.
تخيل أن المستخدم طلب من AI:
"ابحث عن بيانات المبيعات، حللها، ثم اكتب تقريرًا مختصرًا."
قد ينفذ الوكيل الخطوات التالية:
طلب المستخدم → النموذج → البحث في البيانات → استدعاء أداة → استرجاع النتائج → تحليل البيانات → إنشاء التقرير.
إذا كانت النتيجة النهائية خاطئة، فإن الـTrace يساعدك على الرجوع إلى الخطوات ومعرفة مكان الخلل.
وهذا بالضبط ما توضحه وثائق OpenAI حول Tracing، حيث يمكن للـtrace عرض خطوات التنفيذ، واستدعاءات الأدوات، واستجابات النموذج، والـspans التي تمثل أجزاء مختلفة من العمل.
لماذا لا يكفي تسجيل النتيجة النهائية؟
لنفترض أن لديك AI Agent مسؤولًا عن خدمة العملاء، وأن النظام أعطى العميل إجابة خاطئة.
إذا كنت تسجل الإجابة النهائية فقط، فأنت تعرف أن هناك خطأ، لكنك لا تعرف سببه.
أما إذا كان لديك Trace، فقد تكتشف أن الوكيل:
- قرأ طلب العميل بشكل صحيح.
- اختار أداة صحيحة.
- أرسل رقم طلب خاطئًا إلى الأداة.
- حصل على بيانات غير صحيحة.
- استخدم هذه البيانات في الإجابة.
وهنا تصبح عملية إصلاح المشكلة أسهل بكثير.
بدل تعديل النموذج بالكامل، يمكنك إصلاح الخطوة التي حدث فيها الخطأ.
ما العلاقة بين Observability وAI Evals؟
في المقال السابق تحدثنا عن AI Evals وتقييم الذكاء الاصطناعي.
التقييم والمراقبة مرتبطان، لكنهما ليسا الشيء نفسه.
AI Evals يساعدك على الإجابة عن سؤال:
هل النظام يحقق النتيجة المطلوبة؟
بينما يساعدك Observability وTracing على الإجابة عن سؤال:
ماذا حدث داخل النظام حتى وصل إلى هذه النتيجة؟
لذلك يمكن أن يعمل الاثنان معًا:
Tracing → اكتشاف ما حدث → Evals → قياس جودة النتيجة → تحسين النظام → إعادة الاختبار.
ما هو Span في AI Tracing؟
من المصطلحات المهمة في عالم التتبع Span.
الـSpan يمثل وحدة محددة من العمل داخل Trace.
مثلًا يمكن أن يكون لديك Span لاستدعاء نموذج AI، وSpan آخر لاستدعاء أداة، وSpan ثالث لعملية البحث في قاعدة البيانات.
يمكن تجميع هذه الـSpans داخل Trace واحد يمثل تنفيذ المهمة كاملة.
وتشرح وثائق Google Cloud حول Tracing للوكلاء أن الـTrace يمكن أن يتكون من عدة Spans، يمثل كل منها عملية محددة مثل استدعاء دالة أو تفاعل مع نموذج لغوي.
هذه البنية مفيدة جدًا عند تحليل الأنظمة التي تحتوي على عشرات العمليات الصغيرة.
كيف تستخدم Tracing لاكتشاف خطأ في AI Agent؟
افترض أن الوكيل يجب أن يبحث في قاعدة بيانات ثم يرسل النتيجة إلى المستخدم.
حدثت المشكلة، والنتيجة كانت خاطئة.
يمكنك فتح Trace والبحث عن:
- ما هو Prompt الذي وصل إلى النموذج؟
- ما الأداة التي اختارها النموذج؟
- ما البيانات التي أرسلها إليها؟
- ما النتيجة التي عادت من الأداة؟
- كيف تعامل النموذج مع النتيجة؟
- هل حدث خطأ أو Timeout؟
- هل تم تنفيذ خطوة إضافية؟
- ما سبب النتيجة النهائية؟
وبذلك تستطيع الانتقال من مجرد رؤية الخطأ إلى تحليل السبب الجذري Root Cause.
مراقبة الأداء والسرعة
ليست جودة الإجابة هي المعيار الوحيد.
قد يكون النظام دقيقًا لكنه بطيء جدًا.
مثلًا، إذا كان Agent يحتاج إلى 20 ثانية لإجابة سؤال بسيط، فقد تكون هناك مشكلة في تصميم سير العمل.
من خلال Tracing يمكنك معرفة الوقت الذي استغرقته كل خطوة، وبالتالي تحديد المرحلة التي تسبب التأخير.
وتوضح Google Cloud Trace أن التتبع يساعد على تحليل زمن الطلبات واكتشاف اختناقات الأداء وفهم الاعتماديات بين مكونات النظام.
مراقبة تكلفة الذكاء الاصطناعي
من أهم الأسباب التي تجعل Observability مهمة للشركات هي التكلفة.
قد يبدو Agent بسيطًا من الخارج، لكنه قد ينفذ عدة استدعاءات للنموذج ويستخدم أدوات متعددة ويستهلك عددًا كبيرًا من الرموز.
إذا كنت لا تراقب هذه العمليات، فقد ترتفع تكلفة التشغيل دون معرفة السبب.
من خلال بيانات التتبع يمكنك تحليل:
- عدد استدعاءات النموذج.
- عدد الرموز المستخدمة.
- الأدوات الأكثر استخدامًا.
- الخطوات التي يمكن حذفها.
- الطلبات التي تستغرق وقتًا طويلًا.
وتوضح وثائق OpenAI الخاصة بالمراقبة أن بيانات الاستخدام يمكن أن تساعد في فحص استهلاك الرموز عبر تشغيل الوكلاء، وهو أمر مهم عند حساب تكلفة المهام متعددة الخطوات. اطلع على دليل OpenAI للمراقبة والاستخدام.
AI Observability وRAG
عند استخدام RAG في الذكاء الاصطناعي، تصبح المراقبة أكثر أهمية.
قد تكون المشكلة في الإجابة النهائية، لكن السبب الحقيقي قد يكون أن نظام الاسترجاع أعاد المستندات الخطأ.
من خلال التتبع يمكنك تحليل:
- السؤال الذي تم إرساله إلى نظام البحث.
- المستندات التي تم استرجاعها.
- ترتيب النتائج.
- المعلومات التي وصلت إلى النموذج.
- الإجابة التي تم توليدها.
وهكذا يمكنك معرفة هل المشكلة في الاسترجاع أم في النموذج نفسه.
AI Observability وFunction Calling وMCP
كلما زادت الأدوات التي يستطيع AI استخدامها، أصبحت الحاجة إلى التتبع أكبر.
في Function Calling يمكن أن يسجل النظام الأداة التي تم اختيارها والبيانات التي أرسلها النموذج إليها والنتيجة التي عادت.
أما عند استخدام MCP، فيمكن أن يصبح النظام متصلًا بعدد أكبر من الأدوات والخدمات. لذلك يساعد التتبع على معرفة أي خادم أو أداة تم استخدامها أثناء تنفيذ المهمة.
وهذا مهم بشكل خاص عند وجود عشرات الأدوات، لأن اكتشاف المشكلة يدويًا يصبح أكثر صعوبة كلما زاد تعقيد النظام.
AI Observability والـMulti-Agent Systems
عندما يعمل أكثر من Agent داخل النظام، تصبح الصورة أكثر تعقيدًا.
قد يكون هناك Agent رئيسي يستقبل المهمة، ثم يرسل جزءًا منها إلى Agent متخصص في البحث، ثم إلى Agent آخر للتحليل، ثم يعود بالنتيجة إلى الوكيل الرئيسي.
إذا حدث خطأ في النتيجة النهائية، فمن الضروري معرفة أي Agent تسبب في المشكلة.
لهذا السبب تعتبر الـtraces مهمة جدًا في الأنظمة متعددة الوكلاء، لأنها تستطيع إظهار التسلسل بين الوكلاء والأدوات والنماذج المستخدمة.
وتوضح وثائق OpenAI الحالية أن الـtraces يمكن أن تتضمن نشاط الوكيل الأساسي والوكلاء الفرعيين واستدعاءات الأدوات، مما يساعد على فحص سير العمل كاملًا.
هل Observability تعني تسجيل كل شيء؟
ليس بالضرورة.
هذه نقطة مهمة جدًا عند تصميم أنظمة الذكاء الاصطناعي.
قد تحتوي الطلبات والاستجابات على بيانات شخصية أو معلومات تجارية سرية أو بيانات حساسة.
لذلك يجب تحديد ما الذي سيتم تسجيله، ومن يستطيع الوصول إليه، ومدة الاحتفاظ به.
وتوضح Google Cloud في وثائقها الخاصة بتتبع الوكلاء أن تسجيل محتوى الـprompts والاستجابات يمكن أن يتطلب إعدادات صريحة، كما تشير إلى ضرورة وجود الموافقات والإشعارات وسياسات التعامل مع البيانات المناسبة عند جمع هذه المعلومات. راجع إعدادات Tracing في Google Cloud.
لذلك يجب أن تكون المراقبة متوازنة بين الرؤية الفنية وحماية البيانات.
مثال عملي بسيط
لنفترض أن لديك AI Agent للرد على العملاء.
يمكن أن يحتوي Trace على:
المستخدم:
أين طلبي رقم 1524؟
Agent:
تحليل الطلب
Tool:
البحث عن الطلب 1524
Tool Result:
الطلب خرج للتوصيل
Agent:
تفسير النتيجة
Final Response:
طلبك خرج للتوصيل.
هذا المثال يبدو بسيطًا، لكنه يصبح مفيدًا جدًا عندما تحدث مشكلة.
إذا قال النظام للعميل إن الطلب تم تسليمه بينما قاعدة البيانات تقول إنه خرج للتوصيل، يمكنك الرجوع إلى Trace ومعرفة أين تغيرت المعلومة.
كيف تبدأ AI Observability لمشروع صغير؟
لا تحتاج إلى بناء نظام ضخم من اليوم الأول.
ابدأ بتسجيل المعلومات الأساسية:
- رقم أو معرف العملية.
- وقت بداية الطلب ونهايته.
- النموذج المستخدم.
- الأدوات التي تم استدعاؤها.
- الأخطاء.
- المدة الزمنية.
- استهلاك الرموز إن كان متاحًا.
- النتيجة النهائية.
بعد ذلك يمكنك إضافة تفاصيل أكثر حسب احتياجات النظام.
وعند استخدام OpenAI Agents SDK مثلًا، توفر المنصة حاليًا Tracing مدمجًا يمكن استخدامه لفحص تشغيل الوكلاء قبل الانتقال إلى حلقات تقييم أكثر تعقيدًا. تعرف على OpenAI Agents SDK.
Prompt لتصميم خطة Observability
يمكنك استخدام Prompt التالي مع نموذج ذكاء اصطناعي لتصميم خطة مراقبة لمشروعك:
أنت مهندس متخصص في AI Observability.
لدي نظام ذكاء اصطناعي يقوم بالمهمة التالية:
[اكتب وصف النظام]
النظام يستخدم:
[النموذج]
[الأدوات]
[RAG إن وجد]
[MCP إن وجد]
[AI Agents إن وجد]
صمم لي خطة Observability تشمل:
1. ما البيانات التي يجب تسجيلها؟
2. ما الـTraces التي يجب إنشاؤها؟
3. ما الـSpans المهمة؟
4. كيف أكتشف أخطاء الأدوات؟
5. كيف أقيس زمن التنفيذ؟
6. كيف أراقب استهلاك الرموز والتكلفة؟
7. ما التنبيهات التي يجب إنشاؤها؟
8. ما البيانات التي يجب عدم تسجيلها لحماية الخصوصية؟
9. كيف أربط Observability مع AI Evals؟
اجعل الخطة مناسبة لمشروع إنتاجي وقابلة للتوسع.
AI Observability في مستقبل الوكلاء
مع زيادة استخدام AI Agents، لن تكون مراقبة النظام مجرد تسجيل للأخطاء التقليدية.
سيحتاج المطورون إلى فهم طريقة تفاعل النموذج مع الأدوات، وتسلسل القرارات، واستهلاك الموارد، ونتائج الوكلاء الفرعيين، ومشكلات الأمان، وجودة النتائج.
وهذا واضح في الاتجاه الحالي للمنصات الكبرى؛ فـOpenAI توفر tracing ومراقبة لسير عمل الوكلاء، بينما توفر Google Cloud أدوات لتتبع عمليات الوكلاء وتحليل الـspans، كما تعرض Anthropic وGoogle Cloud استخدام الـtraces وأحداث التدقيق لمراقبة الوكلاء على نطاق واسع.
وبالتالي يمكن النظر إلى AI Observability باعتبارها طبقة أساسية بين تشغيل النظام وتحسينه.
الخلاصة
AI Observability وTracing يساعدانك على فهم ما يحدث داخل أنظمة الذكاء الاصطناعي أثناء تنفيذ المهام.
إذا كان AI Evals يخبرك بأن النظام يحتاج إلى تحسين، فإن Tracing يمكن أن يساعدك في معرفة أين حدثت المشكلة، وما الخطوة التي أدت إليها.
وتزداد أهمية هذه التقنيات مع AI Agents وRAG وFunction Calling وMCP والأنظمة متعددة الوكلاء، لأن النظام الحديث لم يعد مجرد نموذج يقدم إجابة، بل أصبح مجموعة من العمليات المتصلة التي يجب مراقبتها وتحليلها.
لذلك إذا كنت تبني مشروع ذكاء اصطناعي قابلًا للتوسع، فمن الأفضل أن تفكر في المراقبة والتتبع منذ المراحل الأولى، وليس بعد ظهور المشكلات فقط.
الأسئلة الشائعة حول AI Observability
ما هو AI Observability؟
هو مجموعة من أساليب وأدوات مراقبة أنظمة الذكاء الاصطناعي لفهم أدائها وسلوكها واكتشاف الأخطاء والتكلفة ومشكلات التشغيل.
ما هو AI Tracing؟
هو تتبع الخطوات التي ينفذها نظام الذكاء الاصطناعي أثناء معالجة مهمة معينة، مثل استدعاءات النموذج والأدوات والوكلاء الفرعيين.
ما الفرق بين Logging وTracing؟
الـLogging يسجل أحداثًا أو رسائل معينة، بينما يساعد الـTracing على رؤية رحلة الطلب وتسلسل العمليات والعلاقة بين الخطوات المختلفة.
هل يحتاج AI Agent إلى Observability؟
نعم، خصوصًا عندما يكون الوكيل قادرًا على استخدام الأدوات أو تنفيذ عدة خطوات، لأن تتبع التنفيذ يساعد على اكتشاف مكان حدوث الخطأ.
هل AI Observability مرتبط بـAI Evals؟
نعم. يمكن استخدام التقييم لقياس جودة النتائج، بينما يساعد التتبع والمراقبة على فهم أسباب النتائج والأخطاء وتحسين النظام.
هل تسجيل Prompts واستجابات AI آمن دائمًا؟
ليس بالضرورة. يجب مراعاة الخصوصية وحماية البيانات وتحديد ما يتم تسجيله ومن يستطيع الوصول إليه ومدة الاحتفاظ بالمعلومات.

التعليقات