بعد ستة أشهر من إطلاق ميزة الذكاء الاصطناعي في الإنتاج، تتكرر الأسئلة ذاتها في الاجتماع اليومي: لماذا تضاعف زمن الاستجابة في الأسبوع الماضي؟ لماذا قفزت فاتورة OpenAI بنسبة 38 بالمئة دون تغيير في عدد الطلبات؟ ولماذا يقول أحد العملاء إن الوكيل يستدعي نفس الأداة المعطوبة مرارًا؟ لا يستطيع أحد في الفريق الإجابة بثقة، لأن المراقبة الوحيدة المتوفرة هي سجلات التطبيق ولوحة Datadog لا تعرف شيئًا عن البرومبتات أو الرموز أو شجرة التتبع.
هذه هي الفجوة التي تسعى منصات مراقبة LLM إلى سدّها. في عام 2026 ثلاثة مشاريع تهيمن على النقاش: Langfuse و Helicone و LangSmith. تتشابه على الورق وتختلف بشكل حاد في الاستخدام اليومي. هذه المقالة تستعرض ما يتفوق فيه كل واحد منها فعليًا، وأين تظهر حدوده، وكيف تختار دون أن تقع في فخّ التبعية لمورّد واحد.
ما الذي تعنيه مراقبة LLM فعلًا؟
مراقبة التطبيقات التقليدية — السجلات والمقاييس والتتبع — تفترض كودًا حتميًا. نفس المدخل ينتج نفس المخرج، الأخطاء لها أنواع، والـ stack trace يشير إلى رقم سطر بعينه. لا شيء من هذا ينطبق على استدعاء LLM. نفس البرومبت ونفس النموذج ونفس درجة الحرارة قد تنتج مخرجات مختلفة عبر التشغيلات. الأخطاء عادة دلالية وليست استثنائية. استدعاء "ناجح" قد يعيد JSON مهلوس يكسر الخطوة التالية بعد ثلاث ثوانٍ.
لذا فإن مراقبة LLM يجب أن تلتقط نمطًا مختلفًا من البيانات. الحد الأدنى المفيد يشمل:
- شجرة التتبع — كامل شجرة استدعاءات LLM واستدعاءات الأدوات والاسترجاعات والقرارات الوسيطة لطلب مستخدم واحد. بدون هذا، يصبح تصحيح الوكلاء متعددي الخطوات تخمينًا.
- المدخلات والمخرجات الكاملة — لا البيانات الوصفية فحسب. تحتاج البرومبت الفعلي الذي دخل والإكمال الفعلي الذي خرج، بما في ذلك برومبتات النظام وتعريفات الأدوات ومخططات المخرجات المهيكلة.
- عدد الرموز والتكلفة لكل طلب — مقسّمة حسب النموذج والمستخدم والميزة والمستأجر. لوحة OpenAI لا تستطيع الإجابة عن "أي ميزة ترفع الفاتورة" لأنها بلا سياق تطبيقي.
- زمن الاستجابة عند كل عقدة — زمن النموذج، زمن الشبكة، زمن الطابور، زمن تنفيذ الأداة. تجميع الزمن الكلي يخفي العنق الفعلي للزجاجة.
- إشارات تغذية راجعة من المستخدم — إعجاب، عدم إعجاب، إعادة توليد، نسخ المخرج. الحلقة المغلقة بين رد فعل المستخدم وشجرة التتبع هي حيث يبدأ التقييم.
- نتائج التقييم — درجات برمجية أو حكم LLM-as-judge على شجرات التتبع الإنتاجية، تعمل باستمرار لا فقط في CI.
- إصدارات البرومبت — أي برومبت كان منشورًا متى، من غيّره، وأي شجرات تتبع شُغّلت ضد أي إصدار.
أي منصة تعطيك أقل من خمسة من هذه ليست مراقبة، بل تسجيل بواجهة أجمل. بهذا المعيار، إليك كيف تصطف اللاعبات الثلاثة الكبار.
Langfuse: الخيار الافتراضي مفتوح المصدر
Langfuse منصة هندسة LLM مفتوحة المصدر مع طبقة سحابية مستضافة ونشر Docker قابل للاستضافة الذاتية بالكامل. هذا هو المشروع الذي تتقارب نحوه أكثر الفرق عندما تريد تتبعًا جادًا دون الالتزام بمورّد مغلق.
نموذج البيانات هو الأقوى في الفئة. شجرة التتبع هي شجرة من المشاهدات المتداخلة، حيث كل مشاهدة هي توليد أو span أو حدث أو درجة تقييم. يمكنك إرفاق بيانات وصفية اعتباطية ومعرّفات مستخدم ومعرّفات جلسة ووسوم وحمولات input/output مهيكلة عند أي مستوى. يبدو هذا مملًا حتى تحاول تصفية "كل شجرات التتبع للمستأجر 42 في آخر 24 ساعة حيث آخر استدعاء أداة هو payment_charge وتقييم المستخدم سلبي" — يجيب Langfuse عن هذا الاستعلام بنقرتين.
التركيب لا يعتمد على مزوّد. تحزم SDKs بايثون وTypeScript أي عميل LLM؛ وهناك ديكوريترز من الدرجة الأولى لـ OpenAI و Anthropic و LangChain و LlamaIndex و Vercel AI SDK، ووضع OpenTelemetry-compatible عام يأخذ شجرات التتبع من أي شيء يبثّ OTel. مثال تركيب نموذجي:
from langfuse.decorators import observe
from langfuse.openai import openai
@observe()
def answer_question(user_id: str, question: str):
return openai.chat.completions.create(
model="gpt-5-turbo",
messages=[{"role": "user", "content": question}],
)يُنشئ الديكوريتر @observe شجرة تتبع ويرفق توليد OpenAI كمشاهدة متداخلة تلقائيًا. أضف langfuse_context.update_current_trace(user_id=user_id, tags=["beta"]) لإرفاق السياق، فتظهر شجرة التتبع في الواجهة بكامل input/output وعدد الرموز وزمن الاستجابة مقسّمًا لكل خطوة.
تطورت قصة التقييمات في Langfuse بشكل كبير خلال الاثني عشر شهرًا الماضية. يمكنك تعريف مقيّمات في الواجهة (LLM-as-judge أو بايثون مخصص أو regex) وتشغيلها تلقائيًا على عينة من شجرات التتبع الإنتاجية، أو عند الطلب على شجرات تاريخية، أو في CI ضد مجموعة بيانات ثابتة. نفس المقيّم يعمل في السياقات الثلاثة، فالدرجة التي تضبطها على مجموعة بيانات CI هي الدرجة التي تراقبها على حركة الإنتاج. قليل من المنصات تُتقن هذه الحلقة.
إدارة البرومبتات مدمجة. البرومبتات تعيش ككائنات مُصدَّرة مع تسميات A/B اختيارية (إنتاج، staging، تجريبي)، وتجلبها الـSDK بالتسمية عند التشغيل. مقترنة بشجرات التتبع، يمكنك الإجابة عن "هل انخفض معدّل النقر بعد نشر البرومبت v17؟" دون مغادرة المنصة.
الاستضافة الذاتية هي العامل المميّز الذي يربح صفقات المؤسسات في الصناعات المنظّمة. تعمل المنصة الكاملة على Postgres مع ClickHouse للتحليلات، وتُنشر بـ Docker Compose أو Helm، ولا ترسل بايتًا واحدًا إلى Langfuse Cloud. بالنسبة للشركات في منطقة الشرق الأوسط وشمال إفريقيا التي تتعامل مع متطلبات الإقامة المحلية للبيانات — PDPL السعودي، PDPL الإماراتي، قانون 63 التونسي — هذا غالبًا غير قابل للتفاوض.
المقايضة: Langfuse منصة لا منتج. الإعداد أثقل مما توحي به الـSDKs. اللوحة كثيفة، وخط أنابيب التقييم يفترض أنك تفهم ما يقيسه LLM-as-judge فعلًا، والمجموعة المستضافة ذاتيًا تحتاج شخصًا يستطيع تشغيل ClickHouse دون قلق. للفرق التي تطلق ميزات الذكاء الاصطناعي على عجل، هذا احتكاك حقيقي.
Helicone: متتبّع التكلفة المبني على البروكسي
يأخذ Helicone رهانًا معماريًا مختلفًا. بدلًا من أن يطلب منك تركيب التتبع في الكود، يجلس كبروكسي أمام مزوّد النموذج. تغيّر عنوان URL واحدًا — يصبح api.openai.com هو oai.helicone.ai — تضيف ترويسة auth، وتمرّ كل طلباتك عبر حافة Helicone بتسجيل كامل وتخزين مؤقت وتحديد معدّل وتتبع تكلفة.
from openai import OpenAI
client = OpenAI(
base_url="https://oai.helicone.ai/v1",
default_headers={
"Helicone-Auth": f"Bearer {HELICONE_API_KEY}",
"Helicone-User-Id": user_id,
},
)ثلاثة أسطر، صفر إعادة هيكلة. للفرق التي لديها قواعد كود فوضوية حيث يعني التركيب لمس أربعين ملفًا، هذا سحر حقيقي. للفرق التي تشغّل دوال serverless أو edge workers حيث يهم وزن الـSDK، يتجنّب نهج البروكسي ضريبة الإقلاع البارد لـSDK تتبّع ثقيل.
سطح ضبط التكلفة هو السبب الأقوى لاختيار Helicone. ميزات مدمجة تستغرق أيامًا لتركيبها في غيرها:
- لوحات تكلفة لكل مستخدم ولكل مؤسسة جاهزة، مفهرسة بالترويسات التي تمررها
- تخزين مؤقت للبرومبت بـ TTLs قابلة للضبط في طبقة البروكسي، شفّاف للتطبيق
- تحديد معدّل لكل مستخدم ولكل مفتاح API ولكل نموذج، بقواعد مخصصة ("مستخدمو الطبقة المجانية يحصلون على 50 طلب يوميًا إلى gpt-5")
- إعادة محاولة و fallback إلى نموذج مختلف عندما يُعيد الأساسي خطأ، يُضبط في اللوحة
- تنبيهات تكلفة تستدعيك عندما يتجاوز مستخدم واحد عتبة معيّنة (انفجار الفاتورة الكلاسيكي بسبب prompt injection)
نموذج التتبع أكثر تسطّحًا من Langfuse. يجمّع Helicone الطلبات في جلسات بترويسة تمررها، لكنه لا يعبّر بشكل أصلي عن علاقات الأب-الابن التي يحتاجها الوكلاء متعددو الخطوات. هناك نموذج خصائص مخصص يوصلك معظم الطريق، لكن إن كنت تبني تدفقات وكلاء عميقة التداخل ستشعر بالقيد.
التقييمات موجودة لكنها أقل نضجًا. إدارة البرومبتات تتحسّن لكنها ما تزال ثانوية أمام قصة تتبع التكلفة.
الموقع الصادق: Helicone هو الخيار الصحيح عندما يكون أكبر ألم تشغيلي لديك هو رؤية التكلفة وتحديد المعدّل، وعندما تكون منصتك في معظمها استدعاءات OpenAI/Anthropic API مباشرة، وعندما لا تريد لمس كود التطبيق. هو أقل صوابًا عندما تبني أُطر وكلاء حيث شجرة التتبع هي قطعة التصحيح الأساسية.
الاستضافة الذاتية مدعومة عبر Docker، لكن معمارية البروكسي تعني أن عليك أيضًا تشغيل ingress عالي التوفر أمام كل استدعاء نموذج، مما يرفع الشريط التشغيلي.
LangSmith: الأداة الاحترافية الأصلية لـ LangChain
LangSmith مبنية ومُشغَّلة من قبل فريق LangChain، وهذا الأصل يظهر في كل قرار منتج. إذا كانت منصتك LangChain أو LangGraph، فـ LangSmith هو الطريق الأقل مقاومة. اضبط متغيّرَي بيئة وستظهر كل سلسلة ووكيل وتنفيذ رسم بياني كشجرة تتبع، بتداخل صحيح وبيانات وصفية صحيحة، دون الحاجة إلى ديكوريترز:
export LANGCHAIN_TRACING_V2=true
export LANGCHAIN_API_KEY=ls__...
export LANGCHAIN_PROJECT=productionبالنسبة لمستخدمي LangGraph على وجه الخصوص، يرسم LangSmith طوبولوجيا الرسم البياني وانتقالات الحالة بين العقد ومدخلات ومخرجات كل عقدة بدقة لا يضاهيها منافس. تصحيح حلقة وكيل عالقة في LangGraph دون LangSmith مؤلم؛ ومعه يمكنك إعادة تشغيل أي شجرة تتبع من أي عقدة للأمام، تبديل برومبت وإعادة التشغيل.
إطار التقييم هو الأكثر صرامة في السوق. يأتي LangSmith بمقيّمات زوجية ومقيّمات قائمة على المرجع ومقيّمات مخصصة ومجموعات اختبار انحدارية مدفوعة بالبيانات مع دعم من الدرجة الأولى لطوابير مراجعة بشرية. ميزة "Annotation Queue" — حيث تدفع شجرات التتبع الإنتاجية إلى واجهة وسم لمراجعين بشريين — هي أنظف تنفيذ لنمط "البشر في حلقة التقييم" ستجده في أي مكان.
إدارة البرومبتات ناضجة، مع مركز برومبتات عام (قوالب قابلة للتفريع)، وسجل إصدارات، وملعب يسمح لك بتبديل النماذج وإعادة تشغيل أي برومبت ضد أي مجموعة بيانات.
ثلاثة أشياء يجب معرفتها قبل الالتزام.
أولًا، LangSmith منحاز لمنظومة LangChain. الـSDK العام يعمل مع أي استدعاء LLM، لكن السحر — التتبع التلقائي ورسم الرسم البياني والاستبطان العميق لحالة الوكيل — يحتاج LangChain أو LangGraph. إن كانت منصتك Vercel AI SDK أو Pydantic AI أو Mastra أو استدعاءات OpenAI مكتوبة يدويًا، تحصل على تجربة أرقّ.
ثانيًا، LangSmith منتج مستضاف. توجد طبقة مؤسسية للاستضافة الذاتية لكن التسعير مقفل خلف المبيعات، وقصة النشر أثقل من Langfuse. للفرق التي تحتاج on-premise من اليوم الأول وبلا شهيّة لـ AWS marketplace، هذا احتكاك.
ثالثًا، انتقل التسعير صعودًا مع نضوج المنصة. الفوترة لكل شجرة تتبع بعد الطبقة المجانية معقولة على نطاق صغير لكنها تتراكم سريعًا عند تجاوز ملايين شجرات التتبع في الشهر، وهو ما تعيشه منتجات الذكاء الاصطناعي الإنتاجية. ضع ميزانية له قبل الالتزام.
اختيار واحدة: إطار قرار
الرأي الصادق بعد نشر الثلاثة في مشاريع مختلفة:
-
اختر Langfuse إن أردت المنصة الأكثر توازنًا، وتقدّر المصدر المفتوح والاستضافة الذاتية، ولديك مهندس واحد على الأقل قادر على امتلاك مكدّس المراقبة. هو الرهان الأكثر أمانًا على المدى الطويل لفريق منتج ذكاء اصطناعي جاد يريد تجنّب التبعية للمورّد.
-
اختر Helicone إن كانت رؤية التكلفة وتحديد المعدّل أكبر آلامك، وكان تطبيقك في معظمه استدعاءات API مباشرة بدون تداخل وكلاء عميق، وأردت إنهاء التكامل بعد ظهر واحد دون لمس كود التطبيق. هو أسرع طريق إلى "نعرف الآن كم ستكون الفاتورة".
-
اختر LangSmith إن كنت على LangChain أو LangGraph وكانت طوبولوجيا الوكيل هي الشيء الأساسي الذي تحتاج تصحيحه. التتبع الواعي للرسم البياني فعليًا طبقة أعلى مما يقدّمه الاثنان الآخران لتلك الحالة بالذات.
هذه ليست خيارات متعارضة. النمط البراغماتي الذي تتقارب نحوه فرق كثيرة: Helicone كبروكسي لضبط التكلفة وتحديد المعدّل (لأن التكامل مجاني ولوحة التكلفة تسدّد نفسها في أسبوع)، مع Langfuse أو LangSmith للتتبع والتقييم وإدارة البرومبت. الطبقتان لا تتعاركان؛ تلتقطان إشارات مختلفة.
سؤال التكلفة
ملاحظة عمّا تكلّفه هذه المنصات فعلًا في الإنتاج. لتطبيق يجري مليون استدعاء LLM شهريًا بمتوسط عمق تتبع ثلاث مشاهدات لكل استدعاء (أي حوالي ثلاثة ملايين مشاهدة)، توقّع إنفاق نطاق 200 إلى 500 دولار شهريًا على الطبقات المستضافة. Langfuse مستضاف ذاتيًا على صندوق Hetzner واحد يتعامل مع هذا الحجم بأقل بكثير من 50 دولارًا شهريًا في البنية التحتية، بكلفة يوم مهندس شهريًا للصيانة.
قارن ذلك بفاتورة النموذج — نفس المليون استدعاء على gpt-5 بسياق متوسط 2K يكلّف أكثر من 8000 دولار شهريًا — والمراقبة خطأ تقريب. الفرق التي تتخطّاها بسبب التكلفة عادة تُحسّن المتغيّر الخطأ. التأطير الصحيح: إنفاق 3 بالمئة من فاتورة النموذج لمعرفة بالضبط أين تذهب الـ 97 بالمئة الأخرى.
ما الذي تبنيه أولًا؟
لفريق ينشئ مراقبة LLM من الصفر، الترتيب الأعلى رافعة:
- شغّل شجرات التتبع. اختر واحدة من الثلاث، ركّب على المسار الأعلى حركة، اقبل أن أسبوع التتبع الأول سيبدو قبيحًا. الرؤية تتفوّق على الأناقة.
- أرفق معرّفات المستخدم. بدون معرّفات على شجرات التتبع لا يمكنك الإجابة عن تذكرة دعم العميل "لماذا فعل البوت هذا بحسابي يوم الثلاثاء".
- وسم شجرات التتبع بالميزة. بدون وسوم الميزة لا يمكنك الإجابة عن "أي ميزة ترفع الفاتورة" — وهذا السؤال سيأتي خلال الشهر الأول.
- أضف التقاط تغذية راجعة من المستخدم. إعجاب وعدم إعجاب على كل رسالة مساعد، مربوطة بمعرّف شجرة التتبع. هذه هي المجموعة التي تعتمد عليها كل التقييمات المستقبلية.
- شغّل تقييمًا واحدًا. ابدأ بـ LLM-as-judge واحد على نوع شجرة تتبع واحد — "هل أجاب الوكيل عن سؤال المستخدم الفعلي، نعم أم لا". شغّله على كل شجرة تتبع إنتاجية. راقب الدرجة عبر الزمن.
- بعد ذلك تحدّث عن إدارة البرومبت. حتى تحصل على شجرات التتبع ومعرّفات المستخدم ووسوم الميزات والتغذية الراجعة وتقييم واحد على الأقل، إصدار البرومبت سابق لأوانه.
معظم الفرق تحاول البدء بإدارة البرومبت وإطار التقييم، ثم تربط التتبع لاحقًا عندما تصطدم بحادث يواجه العميل. يجب عكس الترتيب. التتبع هو الأساس؛ كل ما عداه طبقة فوقه.
إلى أين يتجه هذا؟
تتجه الجبهة في 2026 نحو مراقبة الوكلاء — أدوات تفهم الفرق بين استدعاء LLM واستدعاء أداة وخطوة تخطيط وكتابة ذاكرة، وقادرة على إعادة تشغيل مسارات الوكيل مع تحوّلات الحالة سليمة. Langfuse و LangSmith يشحنان في هذا الاتجاه؛ توقّع حركة ميزات كبيرة في الربعين القادمين.
لسياق أعمق حول هيكلة تدفقات الوكلاء التي يمكن مراقبتها فعليًا، يغطّي دليل تقييم وكلاء الذكاء الاصطناعي إطار المقاييس، ويغطّي دليل ذاكرة وكلاء الذكاء الاصطناعي سطح تحوّل الحالة الذي يجب أن تنمذجه منصات المراقبة.
الفريق الذي سيربح الاثني عشر شهرًا القادمة من هندسة الذكاء الاصطناعي لن يكون الفريق صاحب أفضل البرومبتات. سيكون الفريق الذي يعرف، في أي لحظة، بالضبط أي البرومبتات شُغّلت، وكم كلفت، وماذا أعادت، وما الذي فعله المستخدم بعد ذلك. هذا ما تسعى هذه المنصات الثلاث إلى جعله ممكنًا.