الجلسات والتتبعات والفترات في مراقبة LLM: أحدها ليس مستوى بنيويًا

الجلسات والتتبعات والفترات في مراقبة LLM: أحدها ليس مستوى بنيويًا

صفحة المصطلحات في Datadog، النتيجة الأولى على Google لعبارة "LLM observability sessions traces spans"، تعرّف كلمتين من هذه الكلمات الثلاث. ليس ثلاثًا. الكلمة المفقودة تُقابل gen_ai.conversation.id، وسبب غيابها أن مواصفات OpenTelemetry لم تجعلها مستوى بنيويًا قط. إن كنت بحاجة إلى الحجة لصالح المراقبة ذاتها، ابدأ من هنا. هذا المقال يلتقط حيث يتوقف ذلك المقال: نموذج البيانات.

أبرز النقاط

• الفترات تتداخل داخل التتبعات؛ والتتبعات تتجمع في جلسات. التداخل يسير من الداخل إلى الخارج: فترة، ثم تتبع، ثم جلسة.
• الفترة هي عملية واحدة مُقاسة زمنيًا. التتبع هو طلب واحد من البداية إلى النهاية. الجلسة هي محادثة واحدة متعددة الأدوار.
• اتفاقيات GenAI في OpenTelemetry تعرّف الفترات وسمة gen_ai.conversation.id. لكنها لا تعرّف مستوى الجلسة.
• معرّفات التتبع والفترات تنتشر تلقائيًا عبر السياق. معرّف الجلسة لا ينتشر. أنت تحدده، في كل دور.

الجلسات مقابل التتبعات مقابل الفترات، في لمحة

في مراقبة LLM، الفترة هي عملية واحدة مُقاسة زمنيًا (استدعاء نموذج، خطوة استرجاع)، والتتبع هو شجرة الفترات التي يُنتجها طلب واحد، والجلسة تجمّع تتبعات متعددة من المحادثة نفسها. التداخل يسير إلى الداخل: فترات داخل تتبعات، تتبعات داخل جلسات. التجميع الثالث هو الذي ليس كما يبدو.

أرقام العدد والعمر هذه نطاقات نموذجية تتوقعها في روبوت محادثة RAG أو حلقة وكيل، وليست قياسات من اختبار مُتحكَّم به. أرقامك ستختلف. ما لن يختلف: صف الجلسة هو الذي ليس مستوى بنيويًا في المواصفات، وقسم "الجلسات: المستوى الذي اخترعته أداتك على الأرجح" يُثبت ذلك.

ما الفترة، وما نوع الفترة؟

الفترة هي عملية واحدة مُقاسة زمنيًا لها اسم، وطابع زمني للبداية، وطابع زمني للنهاية، ورمز حالة، وحقيبة من السمات المفتاحية-القيمية. في تتبع LLM، السمات هي nơi تعيش البيانات المفيدة: gen_ai.usage.input_tokens وgen_ai.usage.output_tokens وgen_ai.request.model تُخبرك بما كلّفه التشغيل وأي نموذج نفّذه.

الفترة هي عملية واحدة، وليست استدعاء دالة واحدًا

كل فترة تحمل مؤشر معرّف الفترة الأم (فارغ في الفترة الجذرية) الذي يبني الشجرة. حقيبة السمات مفتوحة: تُرفق أي سياق تحتاجه. اتفاقيات فترات GenAI في OpenTelemetry (الحالة: قيد التطوير) تتطلب gen_ai.operation.name وgen_ai.provider.name في كل فترة GenAI، وتوصي بسمات استخدام الرموز المذكورة أعلاه.

قاعدة عملية واحدة من صفحة مصطلحات Datadog: فترات LLM وWorkflow وAgent يمكن أن تعمل كـفترة جذرية؛ فترات Tool وTask وEmbedding وRetrieval لا يمكنها ذلك. هذه قاعدة Datadog، وليست قاعدة عالمية، لكنها المزود الوحيد الذي ينص عليها، وهي تُجنّبك بناء تتبع يبدأ من استدعاء أداة بلا أم.

أنواع الفترات: الفكرة نفسها، خمس مفردات

كل أداة تحتاج طريقة للقول "هذه الفترة هي استدعاء نموذج" مقابل "هذه الفترة هي استرجاع". لكنها لا تتفق على الكلمة:

مواصفات OpenInference تسرد عشرة أنواع. Datadog تسرد سبعة. OTel تسلك طريقًا ثالثًا: سجل سمات GenAI ينشر 15 قيمة معروفة لـgen_ai.operation.name (chat، create_agent، create_memory، create_memory_store، delete_memory، delete_memory_store، embeddings، execute_tool، generate_content، invoke_agent، invoke_workflow، plan، retrieval، search_memory، text_completion) وينص على أنه إن انطبقت إحداها، فيجب استخدام تلك القيمة؛ والقيمة المخصصة يجوز استخدامها فقط حين لا تناسب أي منها. إذن هو تعداد شبه مفتوح، وليس غياب تعداد. ثلاث قوائم، ثلاثة أطوال، ولا توافق بينها. إن كنت تختار أداة، فإن فجوة المفردات هذه أهم من قائمة الميزات، لأنها ما ستُبنى عليه لوحاتك ومرشحات التنبيه.

ما التتبع، ولماذا يهم شكل الشجرة؟

التتبع هو شجرة الفترات التي يُنتجها طلب واحد. فترة جذرية واحدة تجلس في القمة؛ كل فترة أخرى تتدلى تحتها عبر حواف معرّف-الفترة-الأم. شكل الشجرة هو جوهر المسألة: سجل مسطح يُخبرك أن شيئًا كان بطيئًا، لكن الشجرة تُخبرك أي خطوة كانت بطيئة وأي خطوة أنتجت المخرج السيئ.

chat_request (root)                         2,340ms
├── retrieval                                 410ms
│   └── rerank                                 85ms
├── chat gpt-4o                             1,720ms
└── tool_call: search_calendar                190ms

اقرأ تلك الشجرة والتشخيص فوري: 74% من زمن الاستجابة جلس في استدعاء النموذج، وليس الاسترجاع. سجل مسطح من خمسة طوابع زمنية يُعطيك المجموع نفسه لكن بلا أي إسناد.

حلقة الوكيل تجعل هذه الشجرة أعمق وأعرض من طلب RAG عادي. كل استدعاء أداة يُنتج شجرته الفرعية الخاصة؛ دور وكيل من خمس خطوات يمكن أن يُنتج بسهولة 30+ فترة تحت جذر واحد. هذا طبيعي، وهو سبب وجود سؤال دقة الفترات أدناه.

التمييز بين التتبع والتسجيل يهم هنا أيضًا: التسجيل يُسجّل الأحداث، التتبع يُسجّل السببية. إن كنت لا تزال تقرر ماذا تُسجّل مقابل ماذا تتتبع، مقالنا عن أفضل ممارسات تسجيل LLM يرسم ذلك الخط.

الجلسات: المستوى الذي اخترعته أداتك على الأرجح

لا. الجلسة ليست مستوى بنيويًا في اتفاقيات OpenTelemetry GenAI. المواصفات تعرّف الفترات وسمة gen_ai.conversation.id (مطلوبة شرطيًا، "عند التوفر"، الحالة: قيد التطوير)، الموصوفة بأنها المعرّف الفريد لمحادثة أو سلسلة تُستخدم لربط الرسائل. المزودون يبنون كائن الجلسة الخاص بهم فوق تلك السمة. لا أحد غيرنا في صفحة النتائج هذه يذكر حالة المواصفات بصراحة، فها هي.

النتيجة هي الجملة التي وُجد هذا المقال بأكمله ليُقدّمها:

الجلسة مفتاح تجميع، وليست فترة أم. لا تنتشر بالطريقة التي ينتشر بها معرّف التتبع؛ أنت تحددها بنفسك في كل دور.

أخطئ دورًا واحدًا وذلك الدور يسقط من الجلسة. لا يوجد انتشار سياق تلقائي لها.

متى تبدأ الجلسة وتنتهي؟

يحددها المزود. بعض الأدوات يفتح جلسة عند أول تتبع يحمل معرّف محادثة جديدًا ويُغلقها عند انتهاء مهلة الخمول (Langfuse افتراضيًا نافذة قابلة للتكوين). أدوات أخرى تتطلب استدعاء إغلاق صريحًا. المواصفات لا تقول شيئًا عن دورة الحياة لأن المواصفات لا تُنمذج الجلسة ككائن.

ما الذي ينتقل عبر الأدوار، وما الذي لا ينتقل؟

نافذة سياق النموذج ليست الجلسة. الجلسة مفتاح تجميع فوق تتبعات مستقلة. كل دور يحصل على تتبعه الخاص، وفترة جذرية خاصة، وأعداد رموز خاصة. ما ينتقل هو سمة معرّف المحادثة التي ختمتها على كل فترة جذرية. ما لا ينتقل: زمن الاستجابة، استخدام الرموز، بنية الفترات. تلك لكل تتبع.

ماذا يقيس مقياس مستوى الجلسة؟

أشياء لا يستطيع تتبع واحد قياسها: معدل الحل (هل حلت المحادثة مشكلة المستخدم؟)، والأدوار حتى الإجابة (كم تتبعًا قبل أن يحصل المستخدم على ما يحتاجه؟)، والمحادثات المهجورة (جلسات بلا إشارة إغلاق). تشغيل التقييمات على التتبعات الحية على مستوى الجلسة هو كيف تلتقط إخفاقات متعددة الأدوار تبدو سليمة دورًا بدور.

الكود، محايد للمزود

هذا المقطع يستخدم بدائيات OTel المستقرة فقط. بلا SDK مزود. يُنشئ فترة جذرية لدور واحد، وفترة فرعية للاسترجاع، وفترة فرعية لاستدعاء النموذج، ويضبط gen_ai.conversation.id بحيث تهبط ثلاثة أدوار في جلسة واحدة:

from opentelemetry import trace

tracer = trace.get_tracer("my-llm-app")

SESSION_ID = "conv-8f3a2c"  # same value on every turn

def handle_turn(user_message: str):
    with tracer.start_as_current_span("chat_request") as root:
        # You set this. It does not propagate automatically.
        root.set_attribute("gen_ai.conversation.id", SESSION_ID)

        with tracer.start_as_current_span("retrieval") as ret:
            ret.set_attribute("gen_ai.operation.name", "retrieval")
            docs = retrieve(user_message)

        with tracer.start_as_current_span("chat gpt-4o") as llm:
            llm.set_attribute("gen_ai.operation.name", "chat")
            llm.set_attribute("gen_ai.provider.name", "openai")
            llm.set_attribute("gen_ai.request.model", "gpt-4o")
            response = call_model(user_message, docs)
            llm.set_attribute("gen_ai.usage.input_tokens", 1_204)
            llm.set_attribute("gen_ai.usage.output_tokens", 312)

    return response

استدعِ handle_turn ثلاث مرات بالـSESSION_ID نفسه وجميع التتبعات الثلاثة تتجمع تحت جلسة واحدة في أي خلفية تقرأ السمة. غيّر المعرّف وقد بدأت جلسة جديدة. هذه هي الآلية بأكملها.

قرأنا وثائق خمسة مزودين جنبًا إلى جنب. إنها لا تتفق.

في 30 يوليو 2026 قرأنا وثائق نموذج البيانات الحالية لـLangfuse وLangSmith وOpenInference / Phoenix وDatadog جنبًا إلى جنب، بالإضافة إلى مواصفات فترات GenAI في OpenTelemetry. أربعة من الخمسة تُسمّي الكائن نفسه باسم مختلف. واحد فقط يعامل الجلسة ككائن من الدرجة الأولى وليس كسمة. صفحة مصطلحات Datadog، النتيجة الأولى على Google لهذا الاستعلام، لا تعرّف الجلسة أصلًا.

ملاحظة مصدر واحدة حول ذلك الصف الأول: session.id في OpenInference ليست في مواصفات التتبعات المرتبطة أعلاه، التي تغطي أنواع الفترات العشرة. إنها معرّفة في ملف الاتفاقيات الدلالية الشقيق لـOpenInference كالمعرّف الفريد للجلسة. ملفان، مواصفات واحدة.

لم نخترع المقارنة عبر المزودين؛ FutureAGI تنشر جدول OTel مقابل المزودين أيضًا. إضافتانا هما صف الجلسة (FutureAGI تتخطاه) وفخ الكلمة-نفسها-المعنى-المختلف: "observation" في Langfuse و"run" في LangSmith هما الكائن نفسه كالفترة، بينما أنواع الفترات في Datadog وOpenInference مفردات مختلفة للفكرة نفسها.

Langfuse تُسميها observation، LangSmith تُسميها run، Datadog تُسميها span. الكائن نفسه، ثلاث لوحات تنكسر حين تُهاجر.

هذه قراءتنا لتكلفة الهجرة، وليست ادعاء مزود. لكنها سبب توقف المرشحات المحفوظة وتكوينات التقييم وقواعد التنبيه المبنية على "observation" أو "run" عن العمل يوم تُبدّل الأدوات. أنت لا تُعيد تسمية حقل. أنت تُعيد تسمية مستوى. إن كنت تُوازن بين هاتين الأداتين تحديدًا، مقارنتنا بين Langfuse وLangSmith تتعمق في التباعد.

قد يكون لدى القراء أيضًا Opik أو PostHog أو Sentry أو Weights & Biases في حزمة أدواتهم بالفعل؛ Google يربط الأربعة بـتتبع LLM، وكل واحد يُعيّن هذه المفاهيم بشكل مختلف قليلًا. تختار المناسب؟ جولتنا في منصات المراقبة تغطي المجال.

ملاحظة حداثة واحدة: اتفاقيات GenAI انتقلت إلى مستودعها الخاص، خارج مستودع semantic-conventions الرئيسي. المسار القديم opentelemetry.io/docs/specs/semconv/gen-ai/ يحمل الآن مؤشرًا فقط.

أي معرّف يذهب أين؟

معرّف التتبع يُعرّف طلبًا واحدًا وينتشر عبر السياق تلقائيًا. معرّف الفترة يُعرّف عملية واحدة ضمن ذلك التتبع، تلقائي أيضًا. معرّف الارتباط (أو معرّف الطلب) يأتي من طبقة الويب لديك قبل أن يبدأ التتبع، وهو الذي يخلط الناس بينه وبين معرّف التتبع أكثر من غيره. معرّف الجلسة هو الشاذ: أنت تحدده، يدويًا، في كل دور.

القاعدة العملية: أرفق gen_ai.conversation.id كسمة فترة على الفترة الجذرية لكل دور، واختم معرّف المستخدم بجانبه. تخطَّ دورًا واحدًا ومقاييس مستوى الجلسة تفقد ذلك الدور بصمت.

تحذير واحد حول التعددية: معرّفات المستخدمين ومعرّفات الجلسات قيم عالية التعددية. هذا يهم لفاتورة الفهرسة في خلفيتك، وهي مشكلة القسم التالي.

كم يجب أن تكون الفترة دقيقة؟

نمطا فشل، كلاهما شائع:

الإفراط في الفترات. فترة لكل استدعاء دالة تُعطيك تتبعًا من 400 فترة لا يستطيع أحد قراءته وفاتورة لكل فترة لم يوافق عليها أحد. الخلفيات المستضافة (Datadog، Langfuse Cloud) تُسعّر بحجم الفترات. حلقة وكيل ثرثارة تُقيس كل عملية دمج سلاسل نصية ستُحرق الخطة المجانية في ظهيرة واحدة.

التقليل من الفترات. فترة واحدة لـ"السلسلة بأكملها" تُخبرك أنها كانت بطيئة لكن ليس أين. ينتهي بك الأمر بإعادة إضافة عبارات الطباعة، وهو ما كان من المفترض أن يحل التتبع محله.

القاعدة الإرشادية (وهي قاعدة إرشادية، وليست قياسًا): قِس الفترات عند الحدود حيث يحدث قرار أو استدعاء خارجي.

• خطوة الاسترجاع: قِسها.
• استدعاء إعادة الترتيب: قِسه.
• كل استدعاء نموذج: قِسه.
• كل استدعاء أداة: قِسه.
• كل فحص حاجز حماية: قِسه.
• التحويلات الداخلية البحتة (تنسيق السلاسل، تحليل JSON، تجميع الموجهات): سمات على الفترة الأم، وليست فترات خاصة بها.

حول التعددية والعينة والاحتفاظ:

• السمات عالية التعددية (معرّفات المستخدمين، الموجهات الكاملة) تُضخّم تكاليف التخزين. خذ عينات منها أو اقطعها.
• معظم الخلفيات تتيح لك أخذ عينات على مستوى التتبع. احتفظ بـ100% من تتبعات الأخطاء؛ خذ عينات من المسار السعيد.
• نوافذ الاحتفاظ تختلف: 7 أيام في الخطط المجانية، 30–90 يومًا في المدفوعة. قرر قبل أن تحتاج البيانات.

لنموذج التكلفة الفعلي وراء حجم الفترات والتسعير لكل فترة، راجع دليل مراقبة تكاليف LLM. لن نُعيد بناءه هنا.

كيف تتعامل Techsy مع هذا

لعمل الوكلاء للعملاء، نُوحّد على ثلاث قواعد:

1. تتبع واحد لكل دور. لا تدمج دوري مستخدم في تتبع واحد أبدًا، حتى لو كان الوكيل يدور داخليًا.
2. معرّف جلسة مختوم على كل فترة جذرية، يُضبط في كود التطبيق، ولا يُفترض أبدًا أنه ينتشر.
3. أنواع الفترات تُحفظ في مجموعة صغيرة ثابتة (استرجاع، استدلال، أداة، حاجز حماية) بحيث تنجو لوحاتك من تغيير المزود.

القاعدة الثالثة هي التي تتخطاها الفرق، وهي التي تُنقذ هجرة. إن كانت مفردات فتراتك مرتبطة بتعداد مزود واحد، كل تنبيه وعرض محفوظ ينكسر يوم تُبدّل.

إن كنت تبني نظام وكيل وتريد رأيًا ثانيًا في بنية التتبع، احصل على استشارة مجانية.

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

ما الفترة في التتبع الموزع؟

الفترة هي وحدة عمل واحدة مُقاسة زمنيًا: لها اسم، ووقت بداية، ووقت نهاية، وحالة، ومجموعة سمات. الفترات ترتبط ببعضها عبر مراجع معرّف-الفترة-الأم، مُشكّلة شجرة. في تطبيقات LLM، الفترة تُغلّف عادة استدعاء نموذج واحد، أو استرجاعًا واحدًا، أو استدعاء أداة واحدًا.

ما الفترة في Datadog؟

في مراقبة LLM من Datadog، الفترة هي العملية المُقاسة زمنيًا نفسها، لكن Datadog تضيف تصنيف نوع الفترة: LLM وWorkflow وAgent وTool وTask وEmbedding وRetrieval. فقط أنواع LLM وWorkflow وAgent يمكن أن تعمل كفترة جذرية. التصنيف خاص بـDatadog؛ وليس جزءًا من معيار OpenTelemetry.

ما أركان المراقبة الأربعة؟

الأركان الأربعة هي السجلات والمقاييس والتتبعات و(حسب إطار من) الملفات الشخصية أو الأحداث. التتبعات هي الركن الذي يعيش فيه هذا المقال. حالة LLM تضيف تعقيدًا: استخدام الرموز وهوية النموذج سمات على فترات التتبع، وليست تدفقات مقاييس منفصلة، مما يُدمج ما كان سيكون ركنين في استعلام واحد.

ما الإشارات الذهبية الأربع للمراقبة؟

زمن الاستجابة، والحركة، والأخطاء، والتشبع. لأنظمة LLM، زمن الاستجابة يعني الوقت حتى أول رمز والوقت الإجمالي للتوليد؛ الحركة تعني الطلبات في الثانية لكل نموذج؛ الأخطاء تعني الفترات الفاشلة (رمز الحالة ERROR)؛ التشبع يعني استنفاد ميزانية الرموز أو عمق قائمة الانتظار. الإشارات هي نفسها؛ الوحدات تختلف.

هل الجلسة جزء من مواصفات OpenTelemetry؟

ليس كمستوى بنيوي. اتفاقيات فترات OTel GenAI تعرّف gen_ai.conversation.id كسمة مطلوبة شرطيًا ("عند التوفر") لربط الرسائل في محادثة أو سلسلة. تجلس على الفترات. مزودون مثل Langfuse وLangSmith يبنون كائنات الجلسة أو السلسلة الخاصة بهم فوقها.

ما الفرق بين معرّف التتبع ومعرّف الفترة ومعرّف الارتباط؟

معرّف التتبع يُعرّف طلبًا واحدًا وينتشر تلقائيًا عبر جميع الخدمات التابعة. معرّف الفترة يُعرّف عملية واحدة ضمن ذلك التتبع. معرّف الارتباط (أو معرّف الطلب) تُنشئه طبقة الويب لديك قبل بدء التتبع وهو القيمة التي يخطئ الناس فيها بمعرف التتبع أكثر من غيرها. تتداخل في النطاق لكنها تنشأ بشكل مختلف.

كم فترة يجب أن يكون للتتبع الواحد؟

لا إجابة ثابتة، لكن النطاقات النموذجية هي 3–30 لطلب RAG و10–50+ لحلقة وكيل ذات استدعاءات أدوات متعددة. القاعدة الإرشادية: قِس الاستدعاءات الخارجية ونقاط القرار، وليس التحويلات الداخلية. إن تجاوز تتبعك 100 فترة، فأنت على الأرجح تُفرط في القياس.

هل "ملاحظات" Langfuse هي الشيء نفسه كالفترات؟

نعم. ملاحظة Langfuse هي الكائن نفسه كفترة OTel: عملية واحدة مُقاسة زمنيًا ذات سمات. Langfuse تقسم الملاحظات إلى ثلاثة أنواع (generation، span، event) حيث تستخدم OTel gen_ai.operation.name. إن كنت تُقيّم أدوات تقرأ تتبعاتك، جولتنا في أدوات تقييم LLM تغطي أيها يقبل كلتا المفردتين.

كيف تُجمّع محادثة روبوت محادثة متعددة الأدوار في جلسة واحدة؟

اضبط معرّف المحادثة نفسه على الفترة الجذرية لكل دور. بمصطلحات OTel، ذلك هو gen_ai.conversation.id. في Langfuse، تُمرّر session_id عند إنشاء التتبعات. في LangSmith، تضبط بيانات session_id أو thread_id الوصفية. أخطئ دورًا واحدًا وذلك الدور يسقط من التجميع.

هل أحتاج جلسات إن كنت أتعامل فقط مع طلبات أحادية الدور؟

على الأرجح لا. الجلسات موجودة لربط تتبعات متعددة في محادثة واحدة. إن كان كل طلب مستقلًا (واجهة تصنيف برمجية، مُلخِّص بطلقة واحدة)، مقاييس مستوى التتبع كافية. أضف جلسات حين تحتاج مقاييس عبر الأدوار: معدل الحل، أو الأدوار حتى الإجابة، أو التكلفة على مستوى المحادثة. دليل تقييم LLM يغطي متى تستحق تقييمات مستوى الجلسة عناءها.

النسخة المختصرة

الفترات تتداخل داخل التتبعات؛ والتتبعات تتجمع في جلسات. التداخل حقيقي، لكن المواصفات تُهيكِل اثنين فقط من المستويات الثلاثة. gen_ai.conversation.id سمة تحددها بنفسك، وليست فترة أم تنتشر. والمزود الذي تختاره اليوم يُسمّي هذه الكائنات بشكل مختلف عن المزود الذي ستنتقل إليه بعد 18 شهرًا، فاحفظ مفردات فتراتك صغيرة ومحمولة.

إن كنت تختار منصة، ابدأ بـمقارنة منصات المراقبة. إن كنت تبني تقييمات فوق تتبعاتك، دليل تقييم LLM يلتقط من هنا.