المحتويات
في كيف تبني نظامًا متعدد الوكلاء قلنا: "جهّز القياس (instrumentation) لكل عملية تسليم قبل إضافة الوكلاء". والتقنية التي تشغّل هذا "القياس" في الإنتاج هي AI observability. فهي تُظهر ما تفعله LLMs والوكلاء فعليًا في الإنتاج — أي الأدوات التي يستدعونها، وما يسترجعونه، وأين يفشلون، وكم تكلفته.
على عكس مراقبة التطبيقات العادية، لدى الذكاء الاصطناعي سمة مزعجة: قد يعيد الطلب "200 OK في 50ms" ومع ذلك يكذب بثقة (هلوسة). بعبارة أخرى، قد يكون سريعًا وفي حالة عمل بينما الجودة معطّلة. يأخذ هذا المقال المبتدئين عبر الركائز الثلاث للـobservability، وكيف تختلف عن التقييم (evals)، والمقاييس الجديرة بالمراقبة، والأدوات الرئيسية.
تصوّر "شجرة التنفيذ" لطلب واحد
— يسجّل الـtrace المدخلات واستدعاءات الأدوات والاسترجاع والمخرجات بوصفها spans
* سمات الأدوات والمفاهيم في هذا المقال مقتبسة من مواد عامة ووثائق رسمية (حتى يونيو 2026). تختلف تقييمات الأدوات حسب حالة الاستخدام والإصدار — اقرأها كاتجاه عام.
1. ما هي AI observability؟
تعني AI observability جعل سلوك LLMs ووكلاء الذكاء الاصطناعي في الإنتاج قابلًا للمراقبة من الخارج. فلكل طلب، تسجّل "أي نموذج استُدعي وبأي prompt، وأي أدوات وعمليات بحث استُخدمت، وما الذي أُعيد، وكم استغرق وكم كلّف" — حتى إذا تعطّل شيء، يمكنك التتبّع رجوعًا إلى السبب.
الفرق الحاسم عن مراقبة التطبيقات العادية: المراقبة التقليدية تتحقق من "هل هو يعمل، هل هو سريع؟" لكن الذكاء الاصطناعي قد يستجيب بشكل طبيعي وسريع بينما المحتوى خاطئ. معظم إخفاقات الذكاء الاصطناعي ليست إخفاقات بنية تحتية بل "إخفاقات جودة" — هلوسات، استرجاع ضعيف، إجابات غير آمنة، مهام غير مكتملة، استخدام سيّئ للأدوات، وتراجع بعد تغيير الـprompt.
لذا يحتاج الذكاء الاصطناعي إلى مراقبة مخصّصة. وبخاصة في الأنظمة متعددة الوكلاء، تظهر الإخفاقات داخل سلاسل سببية متعددة الخطوات، لا على مستوى الاستدعاء الفردي. و"أي خطوة أخطأت ولماذا" لا تصبح مرئية إلا حين تلتقط الـtrace الكامل للجلسة.
2. الركائز الثلاث: traces وmetrics وlogs
تُوصف الـobservability تقليديًا بدلالة ثلاث ركائز. وينطبق الأمر نفسه على الذكاء الاصطناعي، والمعيار الصناعي OpenTelemetry (تقاليد GenAI) يتيح لك التعامل مع الثلاث جميعًا عبر مخطط مشترك محايد تجاه المورّد.
Traces
تسجّل مسار تنفيذ طلب واحد بوصفه شجرة من الـspans. ترى كيف تدفّقت استدعاءات LLM والأدوات والاسترجاع وسلاسل الاستدلال. نجم مراقبة الذكاء الاصطناعي.
Metrics
تجمّع زمن الاستجابة والتكلفة وعدد الـtokens ومعدّل الأخطاء والإنتاجية بوصفها أرقامًا. تتبّع الاتجاهات لكل نموذج/وكيل.
Logs
سجلات تفصيلية للأحداث الفردية — الـprompts الكاملة وتفاصيل الأخطاء — الدليل لأجل التحقيق المعمّق.
تسجّل تقاليد GenAI الخاصة بـOpenTelemetry الـprompts واستجابات النموذج واستهلاك الـtokens واستدعاءات الأدوات/الوكلاء وبيانات تعريف المزوّد بصيغة قياسية. وهذا يعني أنك غير مقيّد بمورّد واحد، ويمكنك تغذية traces الذكاء الاصطناعي إلى أنظمة مراقبة خلفية قائمة مثل Datadog أو Grafana.
3. كيف تختلف عن التقييم (evals)
أكثر ما يخلط بين المبتدئين هو الفرق بين "الـobservability" و"التقييم (evals)". فهما شيئان مختلفان، ولا يهمّان إلا كمجموعة.
🔭 Observability
تُظهر "ما الذي حدث": traces، تكلفة، زمن استجابة، أخطاء. سهلة القياس، لكنها وحدها لا تستطيع إخبارك "هل الإجابة صحيحة؟"
✅ التقييم (evals)
يقيس "هل الإجابة جيدة؟": الدقة، groundedness، الأمان. التقييمات الصريحة مطلوبة — هذا هو حارس الجودة.
الجوهر: "التكلفة وزمن الاستجابة سهلا القياس، لكن جودة الإجابة لا يمكن معرفتها دون تقييم صريح." ولهذا لا تكتفي أدوات 2026 الرائدة بعرض traces — بل تسجّل المخرجات بدرجات، وتنبّه على تدهور الجودة، وتعيد الرؤى إلى التطوير. المراقبة والتقييم عجلتان لعربة واحدة.
4. ماذا تراقب: المقاييس الأساسية
المؤشرات التي تتتبّعها على لوحة المعلومات تنقسم عمومًا إلى "تشغيلية" و"جودة".
⚙️ تشغيلية (سهلة القياس)
- التكلفة: فوترة الـtokens لكل طلب
- زمن الاستجابة: زمن الرد (يتباين كثيرًا حسب المدخل)
- استهلاك الـtokens: التقاط الـprompts المتضخّمة مبكرًا
- معدّل الأخطاء / الإنتاجية: لكل نموذج/وكيل
🎯 الجودة (تحتاج تقييمًا)
- الهلوسة: ادعاءات واثقة لكنها خاطئة
- Groundedness: الأهم لـRAG — هل تستند إلى المصادر المسترجَعة؟
- الأمان: تسريب PII، مخرجات ضارة
- إتمام المهمة / الاستخدام الصحيح للأدوات
من بين مقاييس الجودة، في RAG (التوليد المعزّز بالاسترجاع) يُعدّ "groundedness (الإخلاص)" المؤشر الأهم: هل الإجابة مدعومة فعلًا بالمستندات المسترجَعة، أم اخترعها النموذج؟ يستخدم كشف الهلوسة عادةً LLM-as-a-judge (أن يقيّمها ذكاء اصطناعي بدرجة)، والتشابه الدلالي، ودرجات groundedness.
5. مقارنة الأدوات الرئيسية
إليك أدوات AI observability التمثيلية لعام 2026. يتجه كثير منها نحو دمج التتبّع (tracing) والتقييم في مكان واحد.
| الأداة | السمات | الأنسب لـ |
|---|---|---|
| LangSmith | توافق ممتاز مع LangChain/LangGraph. tracing تفصيلي + تقييم + مراقبة. عبء إضافي منخفض. | الإنتاج المبني على LangChain |
| Langfuse | مفتوح المصدر. قابل للاستضافة الذاتية، فلا حاجة لإرسال البيانات إلى SaaS خارجي. | الاستضافة الذاتية / متطلبات بيانات صارمة |
| Arize Phoenix | قوي في تنقيح RAG. بارع في تصوّر جودة الاسترجاع. | التحقيق في RAG وتحسينه |
| MLflow | يركّز دورة حياة GenAI بأكملها في مكان واحد. | من التطوير إلى التشغيل من طرف إلى طرف |
| AgentOps | متخصّص في مراقبة الوكلاء المستقلّين. تتبّع الجلسات متعددة الخطوات. | تشغيل الوكلاء |
| OpenTelemetry | المعيار. محايد تجاه المورّد؛ يتصل بـDatadog/Grafana وغيرها. | التكامل مع المراقبة القائمة |
المصدر: مقارنات أدوات متنوّعة ومعلومات رسمية (يونيو 2026). السمات اتجاهات عامة؛ تختلف التقييمات حسب حالة الاستخدام والإصدار.
عند التردّد، من الآمن أن تبدأ بالتقاط traces بطريقة متوافقة مع OpenTelemetry. تتجنّب بذلك الارتباط بمورّد واحد ويمكنك إعادة اختيار أداة لاحقًا. إذا كنت تستخدم LangChain، فإن LangSmith نقطة دخول سهلة؛ وإذا أردت إبقاء البيانات داخليًا، فـLangfuse.
6. كيف تبدأ، ولماذا تهمّ للوكلاء
لا داعي للإفراط في التفكير — ابدأ صغيرًا. المهم هو وضع المراقبة في مكانها قبل أن تطلق في الإنتاج.
التقط traces
سجّل استدعاءات LLM والأدوات والاسترجاع بوصفها spans. التوافق مع OpenTelemetry يسهّل التبديل لاحقًا.
صوّر المقاييس التشغيلية
ضع التكلفة وزمن الاستجابة والـtokens على لوحة معلومات. اضبط تنبيهات على الشذوذ.
اربط التقييم (evals)
سجّل traces الإنتاج بدرجات جودة واكتشف التدهور. ادمج evals مع guardrails.
وبخاصة في الأنظمة متعددة الوكلاء، ليست المراقبة "ميزة لطيفة" — بل هي ضرورية. ولأن الإخفاقات تختبئ في سلاسل متعددة الخطوات، فدون trace كامل للجلسة لن تعرف أبدًا "أين ولماذا تعطّل." ضع المراقبة قبل إضافة الوكلاء — تلك هي القاعدة. كما تساعد في الكشف المبكر عن حوادث الأمان.
الخلاصة
AI observability هي الأساس التشغيلي الذي "يجعل الذكاء الاصطناعي في الإنتاج مرئيًا". لنلخّص.
النقاط الرئيسية
- 🔭 تجعل دواخل الذكاء الاصطناعي في الإنتاج مرئية. ثلاث ركائز: traces وmetrics وlogs.
- ⚠️ 200 OK قد يكذب رغم ذلك. معظم إخفاقات الذكاء الاصطناعي إخفاقات جودة، لا بنية تحتية.
- 🔁 راقب + قيّم معًا. traces لـ"ماذا"، وevals لـ"هل هي جيدة".
- 🛠️ الأدوات: LangSmith/Langfuse/Phoenix/MLflow/AgentOps. والمعيار هو OpenTelemetry.
- 🤖 ضرورية للوكلاء. الإخفاقات متعددة الخطوات لا تُرى إلا في trace كامل للجلسة.
"سريع ويعمل" لا يكفي للوثوق بالذكاء الاصطناعي. لا يكون بجودة الإنتاج إلا حين تستطيع رؤية الداخل وقياس الجودة. ابدأ بالتقاط traces بطريقة متوافقة مع OpenTelemetry، ثم اربط evals. لبناء الوكلاء، انظر هنا؛ ولتصميم الأمان، guardrails.
الأسئلة الشائعة
س. كيف تختلف الـobservability عن التقييم (evals)؟
ج. تُظهر الـobservability "ما الذي حدث" (traces، تكلفة، زمن استجابة)؛ ويقيس التقييم "هل الإجابة جيدة". وبما أن الرد قد يكون سريعًا ويعمل لكنه خاطئ، فالنهج الأساسي هو استخدامهما معًا كمجموعة.
س. ألا يكفي استخدام أداة مراقبة تطبيقات عادية؟
ج. يمكنها قياس وقت التشغيل والسرعة، لكن ليس الجودة الخاصة بالذكاء الاصطناعي مثل الهلوسة أو groundedness. يحتاج الذكاء الاصطناعي إلى مراقبة مخصّصة (أو تقاليد GenAI الخاصة بـOpenTelemetry) تسجّل الـprompts والـtokens واستدعاءات الأدوات.
س. من أين أبدأ؟
ج. من الآمن البدء بالتقاط traces بطريقة متوافقة مع OpenTelemetry. تتجنّب الارتباط بمورّد واحد ويمكنك إعادة اختيار أدوات مثل LangSmith أو Langfuse لاحقًا. ثم صوّر التكلفة وزمن الاستجابة، وأخيرًا اربط التقييم.
س. لماذا تهمّ بشكل خاص للوكلاء؟
ج. تظهر إخفاقات الوكلاء لا في استدعاء واحد بل داخل سلاسل سببية متعددة الخطوات. ودون trace كامل للجلسة لا يمكنك تحديد "أي خطوة أخطأت ولماذا"، مما يجعل التنقيح مستحيلًا.
