أفضل ممارسات تسجيل LLM: 9 قواعد نطبقها في الإنتاج [2026]

أفضل ممارسات تسجيل LLM: 9 قواعد نطبقها في الإنتاج [2026]

هذه الممارسات التسع لتسجيل LLM هي القواعد التي تعمل فعليًا في بيئة الإنتاج لدينا: نسجّل 1.2 مليون طلب LLM شهريًا عبر أربع خدمات، ويصل كل طلب إلى Grafana Loki على شكل سطر JSON واحد يضم النموذج والرموز وزمن الاستجابة وcost_usd وtrace_id. يكتب structlog 25.4.0 السجل، ويزيل Presidio بيانات PII أولًا، ويمثل الخط بأكمله نصف التسجيل في حزمة المراقبة التي نعتمد عليها.

أبرز النقاط

• سجّل كل طلب LLM بصيغة JSON مهيكل يضم 14 حقلًا مسمّى أو أكثر، ولا تسجّل نصًا حرًا أبدًا.
• أخفِ بيانات PII قبل كتابة السجل باستخدام Presidio أو ما يعادله، وليس بعدها.
• أرفق سمات الاصطلاحات الدلالية OpenTelemetry GenAI بكل تتبع.
• عند مليون طلب يوميًا، يكلف حجم البيانات نفسه (60GB) نحو 108 دولارات شهريًا في Datadog، و30 دولارًا في Loki، و1.20 دولار في ClickHouse.

ما المقصود بتسجيل LLM فعليًا (ولماذا تفشل مقولة «سجّل كل شيء»)

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

غريزة «سجّل كل شيء» يصعب التخلص منها، وهي مكلفة. فالموجّهات والإكمالات الكاملة عند مليون طلب يوميًا تنتج نحو 60GB من النصوص شهريًا، وجزء من هذه النصوص هو بيانات عملاء شخصية تخزّنها الآن إلى أجل غير مسمى. وتشترط مادة تقليل البيانات (المادة 5) في GDPR أن تكون البيانات الشخصية «كافية وذات صلة ومحدودة بما هو ضروري»، وتفريغ الموجّهات الخام يسقط في هذا الاختبار من اليوم الأول. تسجيل كل شيء ليس استراتيجية، بل هو مسؤولية قانونية تأتي بفاتورة شهرية.

ما هي قواعد تسجيل LLM التسع؟

القواعد التسع، بالترتيب الذي نطبقها به: تسجيل الموجّهات والاستجابات كاملة مع معرّفات مجزّأة، وإصدار JSON مهيكل، والتقاط الرموز والتكلفة لكل طلب، وإرفاق سياق تتبع OpenTelemetry، وإخفاء PII قبل الكتابة، والمعاينة عند الأحجام الكبيرة، وتحديد طبقات الاحتفاظ، وفصل أحداث السلامة، وجعل النتيجة قابلة للاستعلام. كل قاعدة أدناه تأتي مع الكود أو الجدول الذي يرسّخها.

القاعدة 1: سجّل الموجّه والاستجابة كاملَين (بالتجزئة، لا ببيانات PII خام)

سجّل الموجّه الكامل والإكمال الكامل لكل طلب، لأن السجلات الناقصة هي ما ينتهي بك إلى التحديق في حادث بلا أي سجل لما رآه النموذج فعليًا. الاستثناء الوحيد هو الهوية: لا تكتب أبدًا معرّفات المستخدمين أو بريدهم أو أسماءهم خامًا في السجل. خزّن بدلًا من ذلك تجزئة SHA-256 لمعرّف المستخدم. تتيح التجزئة إعادة بناء سجل جلسة مستخدم واحد كاملًا عبر بحث دون اتصال، بينما يبقى سطر السجل نفسه عديم الفائدة لأي شخص لا ينبغي له قراءته. المنطق نفسه ينطبق على موجّهات النظام: جزّئها، وسجّل التجزئة، واحتفظ بالنص الصريح في سجل الموجّهات حيث هو مُدار بالإصدارات أصلًا.

القاعدة 2: استخدم JSON مهيكلًا: كل حقل مسمّى، ولا شيء كنص حر

فيما يخص أفضل ممارسات تسجيل LLM في Python أو أي لغة أخرى، فإن التسجيل المهيكل بصيغة JSON هو الشرط الذي لا يقبل التفاوض: كل حقل مسمّى ومحدد النوع وقابل للاستعلام، ولا شيء يُسكب كسلسلة منسقة. سطر نص حر مثل INFO called gpt-4o, took 812ms لا يمكن سوى البحث فيه نصيًا. أما سجل JSON فيمكن تجميعه حسب النموذج، وجمع تكاليفه، وضمه إلى تتبع. وحتى أفضل ممارسات الإنتاج من OpenAI تدفع بالفكرة نفسها: التقاط البيانات الوصفية المهيكلة في طبقة SDK بدلًا من عبارات الطباعة.

إليك المخطط الذي تصدره كل خدمة من خدمات Techsy، أربعة عشر حقلًا:

{
  "request_id": "req_01J9XK4M7Q",
  "timestamp": "2026-07-18T09:24:31.482Z",
  "environment": "production",
  "model": "claude-sonnet-4-20250514",
  "prompt_tokens": 1284,
  "completion_tokens": 396,
  "latency_ms": 812,
  "cost_usd": 0.0098,
  "system_prompt_hash": "sha256:9f2c1a4e...",
  "user_id_hash": "sha256:b7e4d831...",
  "rag_sources": ["kb/pricing-2026.md", "kb/refund-policy.md"],
  "guardrail_result": "pass",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span_id": "00f067aa0ba902b7"
}

ثلاثة حقول تستحق وقفة. cost_usd تُحسب وقت الطلب من عدد الرموز وسعر النموذج المعلن، ولا تُستكمل أبدًا بمهمة ليلية لاحقة. وحقلًا التجزئة هما حل وسط القاعدة 1: قابلان للربط دون اتصال، وغامضان داخل السجل. أما trace_id وspan_id فهما قيمتا سياق تتبع وفق W3C، وهذا تحديدًا موضوع القاعدة 4.

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

القاعدة 3: التقط عدد الرموز والتكلفة لكل طلب

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

القاعدة 4: أرفق سياق التتبع (اصطلاحات OpenTelemetry GenAI الدلالية)

سطر السجل بلا معرّف تتبع يتيمٌ: يمكنك قراءته، لكنك لا تستطيع معرفة أي إعادة محاولة، أو أي خطوة RAG، أو أي دور مستخدم أنتجه. الحل هو الاصطلاحات الدلالية لـ GenAI من OpenTelemetry، وهي أسماء السمات القياسية لتجهيز استدعاءات النماذج. أصدر السجل داخل span نشط وسيرتبط trace_id وspan_id تلقائيًا، بحيث تنقلك نقرة واحدة في Grafana من شلال التتبع مباشرة إلى السجل الخام.

السمات التي تستحق الضبط في كل span من نوع gen_ai:

from opentelemetry import trace

tracer = trace.get_tracer("ai-sdr")

with tracer.start_as_current_span("chat.completion") as span:
    span.set_attribute("gen_ai.system", "anthropic")
    span.set_attribute("gen_ai.request.model", "claude-sonnet-4-20250514")
    response = client.messages.create(**payload)
    span.set_attribute("gen_ai.usage.input_tokens", response.usage.input_tokens)
    span.set_attribute("gen_ai.usage.output_tokens", response.usage.output_tokens)
    span.set_attribute("gen_ai.response.finish_reasons", [response.stop_reason])
    log.info("llm.request", cost_usd=cost)  # Rule 2 record, trace IDs auto-attached

القاعدة 5: أخفِ PII قبل كتابة السجل

إخفاء PII يجب أن يحدث قبل كتابة السجل، لا أن يُنظَّف بعده. فبمجرد دخول عنوان بريد إلكتروني إلى Loki، يصبح موجودًا أيضًا في نسخ التخزين الاحتياطي لديك، و«حذفناه لاحقًا» ليس جوابًا مقبولًا أمام GDPR. في إعدادنا، يعمل Microsoft Presidio كمعالج داخل structlog ويلتقط 94% من عناوين البريد وأرقام الهواتف قبل وصولها إلى Loki؛ والحالات الفائتة كلها تقريبًا تنسيقات غريبة، نضيفها إلى المعرّفات المخصصة فور اكتشافها.

الخطاف كله خمسة عشر سطرًا:

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

PII_ENTITIES = ["PERSON", "EMAIL_ADDRESS", "PHONE_NUMBER", "CREDIT_CARD", "IBAN_CODE"]

def redact_pii(text: str) -> str:
    results = analyzer.analyze(text=text, language="en", entities=PII_ENTITIES)
    return anonymizer.anonymize(text=text, analyzer_results=results).text

# In the structlog processor chain, before JSONRenderer:
# event_dict["prompt"] = redact_pii(event_dict["prompt"])

الإخفاء يقع في طبقة الخط نفسها التي تضم مرشحات الإدخال والإخراج، ويجب اختباره بالطريقة نفسها. خط حواجز الحماية لدينا يعامل بريدًا إلكترونيًا متسربًا في السجل كتقييم فاشل، لا كهامش تشغيلي.

القاعدة 6: عاين بذكاء عند الأحجام الكبيرة

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

الإعداد الشائع هو قواعد عند الأطراف (الإنتاج ومستأجرو المؤسسات: سجّل دائمًا) مع معاينة ذيل في الوسط. الزاوية الخاصة بالتسجيل في هذا الإطار: حقلا guardrail_result وcost_usd هما إشارتا المعاينة، وموجودان أصلًا إن طبقت القاعدتين 2 و8.

القاعدة 7: ضع سياسة احتفاظ قبل أن تحتاج إليها

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

الساخنة تجيب بسرعة وبتكلفة عالية عن «ماذا حدث قبل عشر دقائق؟»، والباردة تجيب ببطء وبتكلفة منخفضة عن «ماذا قلنا لهذا العميل في مارس؟». احذف وفق جدول، تلقائيًا، وإلا فالطبقات مجرد رسم توضيحي.

القاعدة 8: سجّل أحداث حواجز الحماية والسلامة بشكل منفصل

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

القاعدة 9: اجعل السجلات قابلة للاستعلام، لا مخزنة فحسب

السجل الذي لا تستطيع الاستعلام عنه في أقل من دقيقة هو نسخة احتياطية، لا إشارة مراقبة. قابل للاستعلام يعني حقولًا مفهرسة، ولغة استعلام يعرفها مناوبك فعليًا، ولوحات مبنية قبل وقوع الحادث. نشغّل Loki ونستعلم منه أكثر من 30 مرة أسبوعيًا عن شذوذ التكلفة، وتراجعات زمن الاستجابة، و«أرني كل حالة رفض للمستأجر X أمس». وثائق Grafana Loki هي المرجع للصياغة؛ والنمط الذي يثبت جدواه هو الترشيح مباشرة على حقول JSON المحللة:

{service="ai-sdr"} |= "llm.request" | json
  | model = "claude-sonnet-4-20250514"
  | cost_usd > 0.05
  | line_format "{{.timestamp}} {{.request_id}} ${{.cost_usd}} {{.latency_ms}}ms"

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

ما الذي نسجّله فعليًا في الإنتاج

كفى نظرية. هذا هو الإعداد المنقّح من خط AI SDR لدينا، الخدمة التي تقف خلف رقم 1.2 مليون طلب شهريًا في المقدمة. يشغّل structlog 25.4.0 الذي يصيّر JSON، ويُرسل إلى Grafana Cloud Loki عبر Promtail. النموذج على هذا الخط هو claude-sonnet-4-20250514، وكل استدعاء يمر بسلسلة المعالجات نفسها من القاعدتين 2 و5 بالضبط:

import structlog

structlog.configure(
    processors=[
        structlog.contextvars.merge_contextvars,
        structlog.processors.add_log_level,
        structlog.processors.TimeStamper(fmt="iso"),
        redact_pii,          # Rule 5: Presidio, before serialization
        add_otel_trace_ids,  # Rule 4: trace_id + span_id from the active span
        structlog.processors.JSONRenderer(),
    ],
)
log = structlog.get_logger()

رقمان من الربع الأول بهذا الإعداد. استقر الاستيعاب الشهري عند 47GB عبر الخدمات الأربع، وزمن كتابة السجل عند المئين 95 هو 3ms، أي أن الخط لا يضيف شيئًا يُذكر إلى زمن الطلب.

تغيير الإعداد الذي سدد تكلفته بنفسه: أضفنا cost_usd إلى كل إدخال سجل في مارس 2026. خلال أسبوع وجدنا قالب موجّه واحد يحرق 340 دولارًا شهريًا في حلقات إعادة محاولة. كان خطأ API عابر يطلق ثلاث محاولات، كل منها يعيد إرسال السياق الكامل البالغ 4,000 رمز. جعلت السجلات منه استعلامًا من سطر واحد؛ ولولا التكلفة لكل طلب، لظهر كبند غير مفسر في مراجعة الميزانية الفصلية التالية.

كم تكلف تخزين سجلات LLM على النطاق الواسع؟

عند مليون طلب يوميًا، تتراوح تكلفة تخزين سجلات LLM بين نحو 1.20 و108 دولارات شهريًا للبيانات نفسها، بحسب المتجر. الحساب: سجل مهيكل كامل يبلغ في المتوسط نحو 2KB، لذا مليون طلب يوميًا هو 2GB يوميًا، أو 60GB شهريًا. الأسعار المنشورة من البائعين أدناه (يوليو 2026) هي تكلفة تلك الـ 60GB في ثلاثة أنظمة خلفية شائعة.

المصادر: أسعار Datadog، وGrafana Loki، ووثائق المراقبة في ClickHouse.

تحفظان، لأن هذا حسابنا من أسعار البائعين وليس اختبارًا أجريناها. أولًا، رقم Datadog يفترض أنك تفهرس كل شيء؛ معظم الفرق تفهرس مجموعة فرعية وتدفع أقل بكثير، بينما يتقاضى Loki وClickHouse أساسًا مقابل ما تخزنه. ثانيًا، مبلغ 1.20$ لـ ClickHouse ذاتية الاستضافة يخفي فاتورة حقيقية: حوسبة تشغيل الكتلة وساعات المهندس لإدارتها. عند 60GB شهريًا، تكون الخدمة المُدارة تقريبًا دائمًا الإجابة الأرخص إجمالًا. وتبدأ الاستضافة الذاتية في أن تكون منطقية فوق نحو 1TB شهريًا، حيث تطغى فجوة السعر لكل GB على أعباء التشغيل.

الفارق هو الخلاصة. عند مليون طلب يوميًا، تبلغ الفجوة بين Datadog المفهرس وClickHouse ذاتية الاستضافة نحو 90 ضعفًا: 108 دولارات مقابل 1.20 دولار للـ 60GB نفسها. اختر المتجر وقت تصميم البنية، لا بعد وصول الفاتورة.

أي أداة تسجيل يجب أن تختار؟

لمعظم الفرق ينحصر الخيار في أربعة خيارات: منصة أصلية لـ LLM (Langfuse أو LangSmith)، أو أداة طبقة الوسيط (Helicone)، أو خط OpenTelemetry عادي إلى بنية تحتية تشغّلها أصلًا. الجدول يغطي نقاط القرار التي تختلف فعليًا؛ فاللوحات وإعادة التشغيل وإصدارات الموجّهات من الأساسيات المتوفرة في الخيارات الأربعة جميعها.

رأينا بصراحة: نشغّل OTel أصليًا مع Loki لأن حزمة Grafana كانت موجودة لدينا أصلًا لكل شيء آخر، وإضافة مصدر بيانات واحد غلبت تبنّي بائع رابع. إذا كنت تبدأ من الصفر بلا أي حزمة مراقبة، فإن نموذج التتبع في Langfuse وخطته المجانية هما أسرع طريق إلى الفائدة، وخيار الاستضافة الذاتية يبقي باب الخروج مفتوحًا. وإذا كنت تختار بين الزعيمين الأصليين لـ LLM، فإن مقارنتنا بين Langfuse وLangSmith تجري المقارنة الكاملة. وإذا كان التسجيل قطعة واحدة من قرار مراقبة أوسع، فإن مقارنة المنصات الكاملة تغطي المجال الأوسع.

ما أكثر أخطاء تسجيل LLM شيوعًا؟

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

• تسجيل PII خام بلا إخفاء. الأكثر شيوعًا والأعلى تكلفة. تصدير دعم واحد أو اختراق حاوية واحد يحوّل سجلات الموجّهات إلى حادث حماية بيانات. أخفِ قبل الكتابة (القاعدة 5)، لا عند القراءة.
• بلا سياسة احتفاظ. التخزين غير المحدود هو الافتراضي في كل مكان، وهو يضاعف فاتورتك بصمت كل عام. إذا لم تحذف أبدًا، فليس لديك نظام تسجيل؛ لديك أرشيف بأوهام العظمة.
• سجلات نصية غير مهيكلة. مخرجات طباعة لا تستطيع سوى البحث النصي فيها تعمل على نطاق العرض التوضيحي وتنهار عند 100 ألف طلب يوميًا، حين يصبح «جد كل طلب فاشل للنموذج X» أمسية سكريبتات shell بدلًا من استعلام.
• تسجيل الأخطاء فقط. الطلبات الناجحة هي خط الأساس الذي تكتشف الانحراف مقابله، وهي المادة الخام لـخط التقييم لديك. سجّل النجاحات أيضًا، وعاينها إن فرض الحجم ذلك.
• تجاهل حقول التكلفة. بلا cost_usd لكل طلب لا تنبيهات تكلفة، ولا إسناد لكل ميزة، وحلقة إعادة المحاولة البالغة 340 دولارًا شهريًا من قسم الإنتاج أعلاه تبقى خفية حتى الفاتورة الفصلية.
• بلا ربط بالتتبع. السجلات المنفصلة عن الـ spans تجعل تصحيح أخطاء الوكلاء متعددة الخطوات تخمينًا. إذا كان سطر سجلك يفتقر إلى trace_id، فالقاعدة 4 هي الحل.

عن الكاتب

مرت باطور هو المؤسس المشارك لـ Techsy.io، حيث يبني الفريق وكلاء ذكاء اصطناعي وأنظمة أتمتة وخطوط صوت/SDR لعملاء B2B. يكتب عن حزمة أدوات LLM التي يستخدمها فريق Techsy فعليًا في الإنتاج. تواصل عبر LinkedIn.

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

ما الذي يجب تسجيله لكل طلب LLM؟

كحد أدنى: الموجّه والإكمال كاملَين مع إخفاء PII، واسم النموذج، وعدد رموز الإدخال والإخراج، وزمن الاستجابة، والتكلفة بالدولار، ومعرّف مستخدم مجزّأ، ومعرّفي التتبع والـ span من OpenTelemetry. أضف معرّفات مصادر RAG وحكم حاجز الحماية إن كان خطك يشمل تلك المراحل. أربعة عشر حقلًا مسمّى، سطر JSON واحد لكل طلب.

ما أفضل صيغة لسجلات LLM؟

JSON مهيكل، كائن واحد لكل طلب، مع تسمية كل حقل صراحة. السجلات النصية الحرة لا يمكن سوى البحث النصي فيها؛ أما سجلات JSON فيمكن تجميعها حسب النموذج، وجمع تكاليفها، وضمها إلى التتبعات. أصدر السجل بمسجّل مهيكل مثل structlog في Python أو pino في Node، وصيّره بمصيّر JSON، لا بتنسيق السلاسل أبدًا.

كيف تتعامل مع PII في سجلات LLM؟

أخفِ قبل كتابة السجل، لا بعدها. مرّر الموجّه والإكمال عبر كاشف مثل Microsoft Presidio داخل خط التسجيل، مستبدلًا الأسماء والبريد وأرقام الهواتف برموز مثل <EMAIL_ADDRESS>. وبمجرد وصول PII خام إلى متجر السجلات يصبح موجودًا أيضًا في نسخك الاحتياطية، والحذف اللاحق نادرًا ما يفي باختبار تقليل البيانات في GDPR.

كم يكلف تخزين سجلات LLM على النطاق الواسع؟

لمليون طلب يوميًا، نحو 60GB شهريًا عند 2KB لكل سجل، توقّع نحو 108 دولارات شهريًا على تسعير Datadog المفهرس لـ LLM Observability، أو 30 دولارًا شهريًا على Grafana Cloud Loki، أو نحو 1.20 دولار شهريًا تخزين S3 مضغوط لـ ClickHouse ذاتية الاستضافة إضافة إلى الحوسبة. تلك أسعار منشورة من البائعين حتى يوليو 2026؛ والاستضافة الذاتية تضيف وقت الهندسة فوقها.

ما الاصطلاحات الدلالية OpenTelemetry GenAI؟

هي أسماء السمات القياسية من OpenTelemetry لتجهيز استدعاءات LLM: gen_ai.system للمزود، وgen_ai.request.model للنموذج، وgen_ai.usage.input_tokens وoutput_tokens لعدد الرموز، وgen_ai.response.finish_reasons لسبب توقف التوليد. استخدامها يعني أن أي نظام خلفي متوافق مع OTel، من Jaeger إلى Tempo إلى Langfuse، يقرأ تتبعاتك بلا محللات مخصصة.

كيف تعاين سجلات LLM عند الحركة العالية؟

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

كم مدة الاحتفاظ بسجلات LLM؟

قسّمها بطبقات: 7 أيام ساخنة للتصحيح الحي، و30 يومًا دافئة لمراجعة الحوادث وتحليل التكلفة، وحتى سنة واحدة باردة في تخزين كائنات مضغوط للامتثال والتدقيق. مبدأ تقييد التخزين في GDPR يمنع حفظ البيانات الشخصية أطول مما هو ضروري، لذا اقرن كل طبقة بحذف تلقائي لا بتنظيف يدوي.

ما الفرق بين تسجيل LLM وتتبع LLM؟

السجل سجل مسطح لحدث واحد: هذا الطلب حدث، بهذه الحقول. التتبع شجرة سببية من الـ spans عبر مسار طلب كامل، مثل الاسترجاع ثم استدعاء النموذج ثم استدعاءَي أدوات. السجلات تخبرك ماذا؛ والتتبعات تخبرك أين ولماذا. إعدادات الإنتاج تصدر كليهما، موصولَين عبر trace_id.

خلاصة

الخلاصة: سجّل كل طلب كـ JSON بحقول مسمّاة، واحسب التكلفة وقت الطلب، وأرفق سياق تتبع OTel، وأخفِ PII قبل الكتابة، وعاين حسب النتيجة بعد تجاوز 100 ألف طلب يوميًا، واختر متجرًا تستطيع الاستعلام منه فعليًا. القواعد التسع مرتبة بحيث تستطيع تبنّيها قاعدة واحدة في كل سبرنت، والقواعد 2 و4 و5 هي الثلاث الأسرع عائدًا. إذا كنت تختار حزمة المراقبة الأوسع حول السجلات، ابدأ بجولتنا عن أفضل منصات مراقبة الذكاء الاصطناعي. وإذا احتجت مساعدة في توصيل التسجيل المهيكل لحزمة LLM لديك، احصل على استشارة مجانية.