مراقبة نماذج LLM في الإنتاج 2026: OpenTelemetry ولوحة التحكم التي كنت تتمنى بناءها

آخر تحديث: 10 يوليو 2026

مراقبة نماذج LLM في الإنتاج (LLM Observability) هي ممارسة تتبع كل استدعاء لنموذج لغوي في تطبيقك من الطلب حتى الاستجابة عبر مؤشرات زمن الاستجابة (p50/p95/p99)، وعدّ التوكنز، والتكلفة، وجودة المخرجات، ومسارات الوكلاء متعددة الخطوات، باستخدام معايير OpenTelemetry GenAI Semantic Conventions التي تخرّجت من CNCF في مايو 2026. صراحةً، بعد تشغيل ثلاث بيئات إنتاج مختلفة، لوحة التحكم التي كنت أتمنى بناءها في اليوم الأول تعرض ست قطاعات فقط: نسبة الأخطاء، وp99 لزمن الاستجابة، وعدّ التوكنز الوارد والصادر، وهامش حدود المعدل، ومعدل نجاح الاحتياطي، والتكلفة التراكمية اليومية لكل فريق. هذا الدليل يبنيها خطوة بخطوة.

• معايير OpenTelemetry GenAI أصبحت المعيار الرسمي بعد تخرّج المشروع من CNCF في 21 مايو 2026. استخدم سمات gen_ai.request.model وgen_ai.usage.input_tokens وgen_ai.usage.output_tokens بدلاً من مخطط مخصص.
• Langfuse وLangSmith وHelicone ثلاث معماريات مختلفة: بروكسي، وSDK بتتبع أشجار، وإطار مدمج مع LangChain. لا تختر بناءً على نجوم GitHub بل بناءً على شكل مسارات التتبع لديك.
• راقب p99 لزمن الاستجابة وليس المتوسط: التوزيع مائل لليمين بشدة، والاستدعاءات النادرة الطويلة تختفي في المتوسط.
• سجّل مقاييس أساسية (توكنز، تكلفة، زمن) لكل الطلبات، لكن عيّن معدل تتبع كامل بنسبة 10 إلى 20% لتفادي تفجير التكاليف.
• لا تخزّن محتوى الطلب في سمات الـSpan؛ استخدم أحداث Span أو أخفِ البيانات الشخصية على مستوى Collector.
• قاعدة تنبيه عملية: معدل خطأ أعلى من 5%، أو p99 أعلى من 30 ثانية، أو هامش حدود المعدل أقل من 20%.

ما هي مراقبة نماذج LLM ولماذا تختلف عن APM التقليدية؟

مراقبة نماذج LLM هي طبقة قابلية الملاحظة (Observability) الخاصة بتطبيقات الذكاء الاصطناعي التوليدي، وتشمل تتبع كل استدعاء نموذج، وكل استرجاع من قاعدة متجهات، وكل استدعاء أداة داخل وكيل ذكي، كسلسلة واحدة مترابطة. الفرق الجوهري عن APM التقليدية أن الطلبين اللذين يبدوان متطابقين (نفس البرومبت، نفس النموذج، نفس المستخدم) قد ينتجان زمن استجابة مختلفاً بمقدار عشرين ضعفاً. السبب: عدد التوكنز في المخرجات ليس ثابتاً، ومعدل ضربة KV-cache متغيّر، وسياسة التجميع (batching) الديناميكية على الخادم تعيد ترتيب الطوابير.

يعني ذلك أن مؤشرات الخدمات الويبية الكلاسيكية تفشل في وصف الواقع. متوسط زمن الاستجابة يخفي التوزيع المائل بشدة لليمين، ونسبة الأخطاء بحد ذاتها لا تكشف الحالات التي تعيد فيها الواجهة رداً بحالة 200 لكنّه نص هلوسة أو JSON مكسور. أضف إلى ذلك أن التكلفة نفسها متغير تشغيلي بحت: طلب برومبت طويل مع 4000 توكن مخرجات قد يكلّف عشرين ضعف طلب قصير في نفس الدقيقة. لذلك أي منصة مراقبة لا تعرض التكلفة لكل طلب بجانب زمن الاستجابة تعدّ ناقصة بنيوياً.

في التطبيقات الوكيلة (Agentic) يزيد التعقيد. تعثّر أداة في الخطوة الثالثة قد يُفسد الاستدلال في الخطوة الثامنة دون رفع أي علم، وتتبع الاستدعاءات فرداً فرداً لن يكشف السبب. لهذا تعتمد المنصات الحديثة نموذج شجرة المسارات (traces) والأجزاء (spans) بدل السجلات المسطحة. راجع دليلنا حول هندسة السياق للوكلاء الذكية لفهم كيف يتراكم السياق عبر خطوات الوكيل قبل تصميم مخطط التتبع.

معايير OpenTelemetry GenAI: العمود الفقري في 2026

في 21 مايو 2026 أعلنت مؤسسة CNCF تخرّج مشروع OpenTelemetry رسمياً، وتزامن ذلك مع اكتمال معايير الدلالات الخاصة بالذكاء الاصطناعي التوليدي (GenAI Semantic Conventions). هذه المعايير تعرّف مفردات موحّدة للسمات والأحداث والمقاييس، بحيث يمكن لأي أداة تصدير أو منصة استقبال أن تفهم مسار LLM دون تحويلات مخصصة. راجع تدوينة OpenTelemetry الرسمية عن مراقبة GenAI للتفاصيل الكاملة، وكذلك مواصفات GenAI في مستودع OpenTelemetry الرسمي على GitHub للمرجع التقني.

السمات الأساسية التي يجب أن يحتوي عليها كل Span لاستدعاء LLM هي:

• gen_ai.system: مزوّد النموذج، مثل openai أو anthropic.
• gen_ai.request.model: معرّف النموذج المطلوب، مثل claude-opus-4-8.
• gen_ai.request.temperature وgen_ai.request.top_p: معاملات التوليد للربط بين تغييرات الإعداد وتراجع الجودة.
• gen_ai.usage.input_tokens وgen_ai.usage.output_tokens: عدّ التوكنز، وهما المدخل الأساسي لأي حساب تكلفة.
• gen_ai.response.finish_reasons: سبب توقف النموذج، مفيد لكشف حالات length التي تعني اقتطاع المخرجات.
• gen_ai.response.model: النموذج الفعلي الذي ردّ، لأن بعض المزودين يحوّلون الطلبات بين إصدارات فرعية.

للوكلاء، تكون البنية شجرة: Span أعلى باسم invoke_agent، وتحته Spans أبناء بأسماء chat لكل استدعاء نموذج، وexecute_tool لكل استدعاء أداة، وembeddings لكل استدعاء تضمين. هذه التسمية موحّدة عبر المزودين، ما يعني أن لوحة تحكم بنيتها لتطبيق يستخدم OpenAI ستعمل دون تعديل عندما تنتقل إلى Anthropic أو نموذج مفتوح المصدر.

ما هي المقاييس التي يجب تتبعها؟

أقسّم المقاييس التي أراقبها إلى أربع فئات، كل فئة لها مخطط تنبيه مختلف. الفئة الأولى هي مقاييس الأداء، وأهمها زمن أول توكن (Time To First Token, TTFT) وزمن الاستجابة الكامل. TTFT هو الأهم لتجربة المستخدم في التطبيقات البثيّة (streaming): إن تجاوز 800 ميلي ثانية شعر المستخدم أن التطبيق معلّق. زمن الاستجابة الكامل يعتمد على عدد التوكنز الصادرة، ولذلك لا يجب مقارنته دون تطبيعه بعدد التوكنز.

الفئة الثانية هي مقاييس التكلفة. تتبّع عدد التوكنز الوارد والصادر لكل طلب، واضربه في سعر النموذج لتحصل على تكلفة الطلب. لكن لا تكتفِ بالوسيط. راقب p95 وp99 لعدد التوكنز، لأن الأخيرين هما ما يحدد الفاتورة الشهرية فعلياً. طلب واحد بمحادثة طويلة أو استرجاع RAG سيء قد يكون بعشرة أضعاف تكلفة الطلب المتوسط.

الفئة الثالثة هي مقاييس الجودة: معدل الهلوسة، وملاءمة الإجابة، والولاء للسياق (faithfulness في أنظمة RAG). هذه لا يمكن حسابها في الوقت الحقيقي عادةً، لذلك تُحسب على عيّنة غير متزامنة (offline) عبر «نموذج قاضٍ» (LLM-as-Judge). راجع دليلنا حول تقييم وكلاء الذكاء الاصطناعي لتفاصيل مقاييس الجودة وأدوات LLM-as-Judge.

الفئة الرابعة هي المقاييس التشغيلية: معدل الأخطاء (مصنّفة حسب المزود وحسب النوع: 429 حد المعدل، 500 عطل الخادم، 400 فشل التحقق من المخطط)، ونجاح الاحتياطي (fallback)، ومعدل ضربة الذاكرة المخبأة الدلالية (semantic cache). هذه الأخيرة هي المقياس الذي يفاجئك عادةً؛ تفعيل تخزين الردود حسب التطابق الدلالي قد يخفض الفاتورة بنسبة 30% إذا كانت البرومبتات متكررة.

مقارنة Langfuse وLangSmith وHelicone

الأدوات الثلاث الرائدة في مراقبة LLM في 2026 ليست ثلاث نكهات من نفس المنتج، بل ثلاث معماريات مختلفة جذرياً. Helicone بروكسي: تغيّر عنوان قاعدة OpenAI وتحصل على تسجيل فوري دون SDK. Langfuse منصة تتبع قائمة على SDK بدعم أصيل لمعايير OTel GenAI، ولها ترخيص Apache-2.0 يسمح بالاستضافة الذاتية. LangSmith مدمج مع نظام LangChain وLangGraph، ويقدم أفضل واجهة لعرض مسارات الوكلاء عندما تكون داخل ذلك النظام. بصراحة، عانيتُ مع اختيار الأداة في أول مشروع؛ تصفّح النجوم على GitHub ضلّلني، والاختبار الفعلي على مسار وكيل حقيقي هو ما حسم الأمر.

الميزة	Langfuse	LangSmith	Helicone
المعمارية	SDK / تتبع أشجار	مدمج مع LangChain	بروكسي أمامي
زمن التركيب	SDK: 30 دقيقة	متغير بيئة واحد	سطر واحد (تغيير URL)
الاستضافة الذاتية	نعم (Apache-2.0)	محدودة (خطة مؤسسية)	لا (سحابي فقط)
دعم OTel GenAI	أصيل ومتقدم	مخصص جزئياً	أساسي
عمق تتبع الوكلاء	عالٍ (Spans متداخلة)	الأعلى داخل LangGraph	مسطح، يتطلب توثيقاً يدوياً
السعر عند حجم منخفض	معتدل (طبقة مجانية سخية)	يبدأ من 39$ لكل مستخدم/شهر	الأرخص (طبقة مجانية 10k طلب)
الأفضل للامتثال / PII	الأفضل (استضافة ذاتية)	محدود	سحابي فقط

القاعدة العملية التي أتّبعها: لو كنت أبدأ مشروعاً جديداً في 2026 ولم أحدد إطاراً بعد، سأختار Langfuse مع OTel GenAI. الأسباب: التزام واضح بمعيار محايد للمزوّد، ومسار ترقية من السحابي إلى الاستضافة الذاتية دون إعادة كتابة الشيفرة، وأعمق دعم لتتبع الوكلاء متعددي الخطوات. إذا كان الفريق داخل LangGraph بالكامل فـLangSmith هو الأنسب. أما إذا كنت تحتاج تسجيل استدعاءات بروكسي بسيط لواجهة OpenAI دون تعقيد، فـHelicone كافٍ.

مخطط لوحة التحكم التي كنت تتمنى بناءها أولاً

بعد ثلاث سنوات من تشغيل تطبيقات LLM في الإنتاج، توصّلت إلى أن لوحة التحكم الأولى يجب أن تحتوي على ست قطاعات فقط، لا أكثر. زيادة العدد تصنع «ضجيج لوحة تحكم» يفقد قيمته خلال أسبوعين، والمشغّل الجديد لن يعرف أين ينظر عند حادث. القاعدة: يجب أن يعرف المشغّل خلال ثلاثين ثانية من النظر ما إذا كان هناك شيء يستدعي انتباهه.

القطاعات الستة التي أوصي بها:

1. نسب زمن الاستجابة حسب النموذج (p50 / p95 / p99): رسم بياني خطي بنافذة زمنية افتراضية 24 ساعة، مع طبقات لكل نموذج. أضف خطاً أفقياً عند SLO المعتمد (مثل 5 ثوانٍ لـp99).
2. عدّاد التكلفة التراكمية اليومية حسب الفريق: مخطط أعمدة متراكم، يعيد التصفير عند منتصف الليل UTC، مع عرض التكلفة المتوقعة نهاية اليوم استناداً إلى المعدل الحالي.
3. معدل الأخطاء حسب المزوّد: رسم مساحي 100% مصنّف حسب رمز الحالة (429 / 500 / 400 / timeout)، لأن نوع الخطأ يحدد الاستجابة.
4. معدل نجاح الاحتياطي: مقياس (gauge) بسيط يعرض النسبة المئوية للطلبات التي فشلت عند المزوّد الأساسي ونجحت عند الاحتياطي. إذا انخفض هذا الرقم عن 90% فسياسة الاحتياطي مكسورة.
5. معدل ضربة الذاكرة الدلالية: نسبة الطلبات التي عادت من الذاكرة المخبأة دون استدعاء نموذج. الانخفاض المفاجئ يعني أن سياسة التخزين تعطلت أو أن نمط الطلبات تغيّر.
6. هامش حدود المعدل (Rate Limit Headroom): النسبة المتبقية من حصص TPM (Tokens Per Minute) وRPM (Requests Per Minute) لكل مزوّد. أهم مقياس تحذيري لا يتحدث عنه أحد.

هذه القطاعات الستة تكشف 90% من حوادث الإنتاج. أي قطاع إضافي يجب أن يبرّر وجوده بحادثة سابقة كشفها فعلاً، لا بفرضية «قد يفيد».

كيف تضبط التنبيهات وSLOs في الإنتاج؟

القاعدة الأولى في التنبيهات: كل تنبيه يوقظ مهندساً في الساعة الثالثة صباحاً يجب أن يكون قابلاً للتصرف. تنبيهات «الأداء منخفض» بدون خطة استجابة تُطفأ خلال أسبوعين وتبقى مصدر إزعاج. أوصي بثلاث قواعد أولية فقط، تتفرع منها لاحقاً:

• معدل خطأ يتجاوز 5% لمدة 5 دقائق متتالية: ينبّه فوراً. الاستجابة: تحقق من صفحة حالة المزوّد، فعّل الاحتياطي، أعلم أصحاب المصلحة.
• p99 لزمن الاستجابة يتجاوز 30 ثانية: ينبّه بمستوى تحذير (warning) لا حرج (critical). الاستجابة: افحص إذا كان استدعاءً معيناً (وكيل طويل) أم انحرافاً عاماً.
• هامش حدود المعدل ينخفض تحت 20%: ينبّه بشكل استباقي قبل أن ترد الأخطاء 429. الاستجابة: قسّم حركة المرور على مفاتيح إضافية أو زد الحصة.

بخصوص SLOs، الخطأ الشائع هو ضبط هدف طموح لـTTFT دون فهم كلفته البنيوية. من مسح صناعي حديث، الانتقال من TTFT p99 عند 500ms إلى 200ms يزيد نفقات البنية التحتية بنحو 35% لأن الخوادم يجب أن تعمل عند استخدام أدنى. اضبط SLO مقابل تجربة المستخدم الفعلية، لا مقابل رقم يبدو مثيراً. للتطبيقات المحادثية، p99 عند 2 ثانية لـTTFT كافٍ عادةً. لتطبيقات الوكلاء التي تعمل خلفياً، p99 عند 30 ثانية للاستجابة الكاملة مقبول.

لضبط الاحتياطي بشكل صحيح، تحتاج إلى بوابة API موحّدة مثل LiteLLM التي أصبحت المعيار في 2026 لإدارة عدة مزودين. راجع دليلنا حول تنسيق سير عمل الذكاء الاصطناعي لتوصيل بوابة API بمنسقات مثل Temporal التي تدير المحاولات المتكررة.

الخصوصية وإخفاء بيانات PII في مسارات التتبع

تخزين النص الكامل للبرومبت في سمات Span نمط سيء. السبب أن السمات (attributes) تكون مفهرسة دائماً، وتخضع لحدود حجم، وتكشف بيانات المستخدمين الشخصية في الخلفية. معايير OTel GenAI تحل هذا بتخزين المحتوى في أحداث Span (Span Events) بدلاً من السمات، لأن الأحداث يمكن ترشيحها أو إسقاطها في مرحلة Collector دون تعديل شيفرة التطبيق.

في الإنتاج، فعّل ثلاث طبقات من الحماية. الطبقة الأولى هي إخفاء PII الوارد قبل إرسال البرومبت للنموذج. استخدم مكتبات مثل Presidio لاكتشاف أسماء وأرقام هواتف وبطاقات ائتمان واستبدالها برموز. الطبقة الثانية هي تعطيل التقاط المحتوى بشكل افتراضي في إعدادات OTel GenAI (السمة gen_ai.input.messages اختيارية)، ولا تفعّله إلا للبيئات المخصصة لتصحيح الأخطاء. الطبقة الثالثة هي معالجة Collector: أضف معالج تحويل (transform processor) يزيل الحقول الحساسة قبل التصدير للتخزين البعيد.

لو كان تطبيقك يعالج بيانات صحية أو مالية، الاستضافة الذاتية لـLangfuse أو نشر منصة مراقبة داخل شبكتك الافتراضية الخاصة هو الخيار الوحيد المتوافق مع HIPAA وSOC 2 عملياً. تسريب برومبت واحد يحتوي على بيانات مريض إلى منصة SaaS قد يكلّف الشركة أضعاف ما ستوفره في تكلفة الاشتراك السنوية.

أخذ العينات والتحكم في تكلفة التتبع

التتبع الكامل بنسبة 100% مكلف. حجم بيانات تتبع تطبيق LLM يمكن أن يتضاعف مع كل ميزة جديدة، لأن كل استدعاء وكيل ينتج عشرة إلى عشرين Span. القاعدة العملية: سجّل مقاييس أساسية (توكنز، تكلفة، زمن، نموذج، معرّف المستخدم المهشّم) لكل الطلبات، فهذه بيانات بحجم كيلوبايت، لكن احتفظ بالتتبع الكامل مع محتوى الرسائل لنسبة 10 إلى 20% فقط.

خصّص عيّنة كاملة بنسبة 100% لثلاث فئات من الطلبات: أي طلب فشل، أي طلب تجاوز p95 لزمن الاستجابة، وأي طلب من حساب مؤسسي محدد يحتاج ضمان جودة كامل. هذا يسمّى tail sampling ويحل التوتر بين التكلفة والقدرة على تصحيح الحوادث.

الأدوات مثل OTel Collector تدعم قواعد أخذ العينات هذه أصلاً. مثال قاعدة: احتفظ بكل Trace يحتوي على Span بحالة خطأ، وكل Trace بمدة تتجاوز 10 ثوانٍ، وعشوائياً 10% من الباقي. هذا يخفّض حجم البيانات المُخزّنة بنسبة تفوق 80% دون فقدان المسارات المهمة تشخيصياً.

مثال كامل: توصيل OpenAI بـOpenTelemetry في Python

المثال التالي يوصل تطبيق FastAPI بمزوّد OpenAI ويصدّر مسارات التتبع إلى Langfuse (أو أي منصة تدعم OTLP) وفقاً لمعايير GenAI Semantic Conventions. الشيفرة كاملة وقابلة للتشغيل، لا شبه شيفرة.

# requirements.txt
# fastapi==0.115.5
# openai==1.55.0
# opentelemetry-api==1.29.0
# opentelemetry-sdk==1.29.0
# opentelemetry-instrumentation-openai-v2==2.1b0
# opentelemetry-exporter-otlp-proto-http==1.29.0

import os
from fastapi import FastAPI
from openai import OpenAI
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.sdk.resources import Resource
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter
from opentelemetry.instrumentation.openai_v2 import OpenAIInstrumentor

resource = Resource.create({
    "service.name": "chat-api",
    "service.version": "2026.07.10",
    "deployment.environment": os.getenv("ENV", "production"),
})

provider = TracerProvider(resource=resource)
provider.add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter(
        endpoint=os.environ["OTEL_EXPORTER_OTLP_ENDPOINT"],
        headers={"Authorization": f"Bearer {os.environ['LANGFUSE_KEY']}"},
    ))
)
trace.set_tracer_provider(provider)

# Content capture stays off in production; enable only in debug envs.
OpenAIInstrumentor().instrument(capture_content=False)

client = OpenAI()
app = FastAPI()
tracer = trace.get_tracer(__name__)

@app.post("/chat")
def chat(user_id: str, message: str):
    with tracer.start_as_current_span("chat.request") as span:
        span.set_attribute("app.user.id_hash", hash(user_id))
        try:
            resp = client.chat.completions.create(
                model="gpt-4o-mini",
                messages=[{"role": "user", "content": message}],
                max_tokens=500,
            )
            span.set_attribute("app.result", "ok")
            return {"reply": resp.choices[0].message.content}
        except Exception:
            span.set_attribute("app.result", "primary_failed")
            fallback = client.chat.completions.create(
                model="gpt-4o-mini-2024-07-18",
                messages=[{"role": "user", "content": message}],
                max_tokens=500,
            )
            return {"reply": fallback.choices[0].message.content, "fallback": True}

ما ينتجه هذا المثال في منصة المراقبة: شجرة Spans لكل طلب، فيها Span أعلى باسم chat.request، تحته Span بنمط chat gpt-4o-mini مع سمات gen_ai.usage.input_tokens وgen_ai.usage.output_tokens وgen_ai.response.finish_reasons. عند فشل الاستدعاء الأساسي، يظهر Span إضافي للاحتياطي كسليل تحت نفس الجذر، ما يسهّل رصد أنماط الفشل.

ملاحظة عملية: capture_content=False إعداد افتراضي حكيم للإنتاج. تفعيله يلتقط نص البرومبت والرد الكاملين في أحداث Span، وهذا مفيد لبيئات التصحيح لكنه يخالف معظم متطلبات الامتثال في الإنتاج دون طبقة إخفاء PII واضحة. إذا احتجت مقارنة الوكلاء والتطبيقات الوكيلة الكاملة، تفقّد دليلنا حول بناء خوادم MCP للوكلاء الذكية لدمج بروتوكول MCP مع طبقة قابلية الملاحظة.

للتوسع في تفاصيل تنفيذ المزودين تحت الطبقة الموحّدة، انظر أيضاً دليل استدعاء الدوال في LLM الذي يشرح كيف تختلف مخططات JSON بين OpenAI وAnthropic وGoogle، وهذا الاختلاف ينعكس في سمات gen_ai.tool.name عبر المزودين.

لتحقق أنك تصدّر ما تتوقعه، راجع تدوينة Datadog حول دعم OTel GenAI Semantic Conventions التي تعرض شكل السمات الفعلية في مستقبل ناضج. المعايير موحّدة لدرجة أنك تستطيع تبديل Langfuse بـDatadog دون تعديل أي سطر شيفرة في التطبيق، فقط تغيير عنوان OTLP.

الأسئلة الشائعة

ما الفرق بين Langfuse وLangSmith؟

Langfuse منصة مفتوحة المصدر (Apache-2.0) تدعم الاستضافة الذاتية ومحايدة تجاه إطار العمل، وتعتمد على SDK بتتبع أشجار مع دعم أصيل لـOpenTelemetry GenAI. LangSmith منصة مغلقة مصنوعة من قبل شركة LangChain، ومدمجة بعمق مع LangChain وLangGraph، ومناسبة أكثر للفرق التي بنت تطبيقاتها فوق هذين الإطارين.

كم تكلفة مراقبة تطبيقات LLM في الإنتاج؟

بالنسبة لتطبيق يعالج مليون طلب شهرياً: Helicone حوالي 20$ شهرياً، وLangfuse Cloud بين 60$ و120$ شهرياً حسب الحجم، وLangSmith يبدأ من 39$ لكل مستخدم شهرياً، وDatadog حوالي 800$ شهرياً بمعدل 8$ لكل 10 آلاف طلب. الاستضافة الذاتية لـLangfuse تصبح الأرخص فوق 100 مليون مسار شهرياً لكنها تتطلب خبرة ClickHouse.

هل يجب تسجيل نص البرومبت الكامل في مسارات التتبع؟

لا في الإنتاج، ونعم في بيئات التصحيح فقط. تخزين البرومبت الكامل يعرّض بيانات المستخدمين الشخصية (PII)، ويكبّر حجم التخزين بشكل حاد، ويخالف متطلبات HIPAA وSOC 2 دون طبقات حماية إضافية. استخدم أحداث Span بدل السمات، وفعّل إخفاء PII على مستوى OTel Collector، وأبقِ التقاط المحتوى مطفأ افتراضياً.

ما هو p99 لزمن الاستجابة ولماذا هو أهم من المتوسط؟

p99 هو زمن الاستجابة الذي يتجاوزه 1% فقط من الطلبات، أي أنه يمثل أسوأ حالة يعانيها 1 من كل 100 مستخدم. توزيع زمن استجابة LLM مائل بشدة لليمين لأن طلبات نادرة بمخرجات طويلة أو محاولات متكررة قد تكون أبطأ بعشرين ضعف الوسيط. المتوسط يخفي هذه الحالات تماماً، بينما p99 يكشف أسوأ ما ينتجه نظامك ويجب أن يكون هو مقياس SLO الفعلي.

كيف أراقب الوكلاء متعددي الخطوات بشكل صحيح؟

استخدم بنية شجرة Spans: Span أعلى باسم invoke_agent يحتوي Spans أبناء بأسماء chat لكل استدعاء نموذج، وexecute_tool لكل استدعاء أداة، وembeddings لكل استرجاع. مرّر سياق التتبع (trace context) بشكل صريح عبر الخطوات إذا لم يفعل إطار العمل ذلك تلقائياً. هذا يجعل فشل الأداة في الخطوة الثالثة قابلاً للتشخيص عندما يظهر أثره في الخطوة الثامنة.