لماذا بدأت أدوات تتبّع نماذج اللغة الكبيرة ببناء بوابات للذكاء الاصطناعي؟

في عام 2026، أضافت LangSmith وLangfuse وOpik وBraintrust جميعها بوابةً أمام مزوّدي النماذج. والسبب الرئيسي هو التحكم: فأداة التتبّع لا تستطيع سوى تسجيل استدعاء النموذج، بينما تستطيع البوابة إيقافه.

أداتان تؤديان مهمتين منفصلتين

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

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

أربعة إطلاقات خلال ستة أشهر

أعلنت LangChain عن بوابة LangSmith لنماذج اللغة الكبيرة في إصدار تجريبي خاص في مايو 2026، وأتاحتها في إصدار تجريبي عام في 30 يوليو، ثم أدرجتها لاحقًا ضمن عمليات النشر السحابية الخاصة بالعملاء في LangSmith أيضًا. وأوقفت Braintrust العمل بوسيطها السابق للذكاء الاصطناعي، ووجّهت المستخدمين إلى بوابة جديدة ما تزال في مرحلة المعاينة ومتاحة مجانًا إلى حين طرحها عمومًا. وأطلقت Comet بوابة Opik لنماذج اللغة الكبيرة كنقطة نهاية تجريبية تقبل الطلبات المتوافقة مع تنسيق OpenAI. وفي 4 نوفمبر، أتاحت Langfuse بوابتها للذكاء الاصطناعي في إصدار تجريبي عام، على Langfuse Cloud ولعمليات النشر المستضافة ذاتيًا. والبوابة مرخّصة بموجب MIT ومكتوبة بلغة Rust.

MLflow، الذي بدأ أداةً لإدارة دورة حياة تعلّم الآلة لا أداةً للتتبّع، يوفّر بوابة للذكاء الاصطناعي منذ فترة أطول، مع تنبيهات للميزانية وحدود للإنفاق.

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

لماذا تتطلب إدارة الميزانية المرور عبر مسار الطلب؟

تسجّل أداة التتبّع استدعاء النموذج بعد أن يردّ المزوّد وتُسدَّد تكلفة الرموز. ويكفي هذا السجل لإنشاء رسم بياني للإنفاق، لكن أداة التتبّع لا تستطيع إيقافه. ففرض ميزانية الفريق أو حظر نموذج أو إزالة سرّ من مطالبة، كلها أمور تتطلب التحقق من الطلب قبل وصوله إلى المزوّد. ولا يستطيع فعل ذلك سوى المكوّن الموجود في مسار الطلب.

تطرح LangChain هذه الحجة في منشور الإعلان عن إطلاقها. وتصف فرقًا تجمع بين بوابة منفصلة ومنتج للضوابط الوقائية وأداة للرصد، وتقول إن منع المشكلات يتطلب فرض السياسات على مستوى الطلب. وتردّ بوابتها برمز حالة HTTP 402 على أي استدعاء من شأنه تجاوز الميزانية، بدلًا من تمريره إلى المزوّد.

نقطة دخول واحدة لتسجيل كل استدعاء

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

تبني Langfuse بوابتها انطلاقًا من هذه الفكرة. ووفقًا لوثائق البوابة، يرتبط كل مفتاح للبوابة بمستخدم أو بحساب خدمة، ويمكن أن يتضمن بيانات وصفية مثل الفريق أو مركز التكلفة. ولا يحتفظ ببيانات اعتماد المزوّد إلا البوابة، ويوافق المسؤولون على النماذج التي يجوز لكل بيانات اعتماد استدعاؤها. وتنشر LangSmith صفحات إعداد لتوجيه Claude Code وCodex وGemini CLI عبر بوابتها. وتستدعي هذه الوكلاء النماذج من جهاز المطوّر، خارج نطاق شيفرة التتبّع في أي تطبيق.

ما تضيفه بوابة أداة التتبّع

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

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

هناك أيضًا قراءة تجارية للأمر، لا يصرّح بها الموردون أنفسهم. فالجهة التي تدير البوابة تملك مفاتيح مزوّدي الخدمة وتقرير الإنفاق، وهو التقرير الذي تطّلع عليه فرق الشؤون المالية والمنصات. وهذا يجعل استبدال البوابة أصعب من استبدال عارض آثار التتبّع. وتستفيد LangSmith وLangfuse من هذا الموقع بطرق مختلفة بالفعل: تبيع LangSmith أرصدة Gateway Credits، التي تتيح للعملاء استدعاء نماذج مستضافة مثل Kimi من دون استخدام مفتاحهم الخاص لدى مزوّد الخدمة، بينما يذكر قسم الأسئلة الشائعة في Langfuse أنها لا تعيد بيع الرموز.

ما لا تستطيع البوابات التجريبية فعله بعد

لا تزال هذه البوابات حديثة العهد، ويشرح الموردون أوجه القصور فيها بأنفسهم. لا تدعم بوابة Langfuse حاليًا سوى OpenAI وAnthropic، فيما تُدرج Amazon Bedrock وGoogle Vertex AI وGoogle AI Studio ضمن خطتها المستقبلية. ومن المقرر إضافة التحويل الاحتياطي بين مزوّدي الخدمة وسقوف الإنفاق الصارمة لكل فريق أو مستخدم أو مفتاح، لكن هذه الميزات لم تُطرح بعد. وفي الوقت الراهن، توفر البوابة لوحة معلومات للإنفاق وتنبيهات بشأنه. ولا تتناول وثائقها تحديد معدلات الطلبات أو التخزين المؤقت للاستجابات.

لا تحوّل بوابة Langfuse بين تنسيقات واجهات API، لذا لا يستطيع عميل OpenAI استدعاء سوى نماذج OpenAI. ولا يستدعي الإصدار المستضاف ذاتيًا سوى عناوين URL الرسمية لمزوّدي الخدمة، ما يستبعد Azure OpenAI وBedrock أو استخدام وكيل داخلي في الوقت الراهن. وتصف Comet بوابة Opik بأنها مصممة للتطوير والاختبار. ولم تعلن Braintrust عن أسعار بوابتها.

تقدم بوابة LangSmith بالفعل أكثر مما تقدمه البوابات الأخرى. وتدرج وثائقها التحويل الاحتياطي وحدود الإنفاق ومعدلات الطلبات وسياسات البيانات ضمن الميزات المتاحة حاليًا، كما تقبل تنسيقات OpenAI Chat Completions وOpenAI Responses وAnthropic Messages. وقد أُدرج التحويل الاحتياطي وتحديد معدلات الطلبات في مايو ضمن الأعمال المستقبلية، ثم أُضيفا خلال المرحلة التجريبية. ومع ذلك، لا يزال المنتج بأكمله مصنّفًا على أنه تجريبي.

يكشف اختبار التحميل عن نوع مختلف من أوجه القصور. ووجد اختبار معياري مستضاف ذاتيًا لبوابة Langfuse وLiteLLM وAcruxCore أن بوابة Langfuse أضافت زمن استجابة أقل لكل استدعاء مقارنةً بـLiteLLM. لكنها أخفقت، عند استخدام إعدادات Docker الافتراضية، في التعامل مع 739 من أصل 1,000 تدفق متزامن، لأن عمليتها أبقت الحد الافتراضي في Docker، وهو 1,024 ملفًا مفتوحًا. وقد عالج سطر واحد في ملف Compose الخاص بـLangfuse المشكلة.

وبالمقارنة مع هذه الإصدارات التجريبية، تدعم LiteLLM، وهي بوابة مستقلة منذ سنوات، أكثر من 100 مزوّد خدمة، وتضم بالفعل مفاتيح افتراضية وتتبعًا للإنفاق وضوابط وقائية وموازنة للأحمال ولوحة تحكم إدارية. كما تنقل LiteLLM مسار الطلبات من Python إلى Rust. أما بوابة ذكاء اصطناعي مكتوبة بلغة Rust الخاصة بها، فهي في مرحلة تجريبية، ويتوقع فريق LiteLLM أن تعمل طلبات /v1/messages المتوافقة مع أسلوب Anthropic بالكامل بلغة Rust بحلول 1 ديسمبر، مع زمن استجابة أقل بنحو 20 مرة. وتوفر بعض المنصات مفتوحة المصدر، مثل MLflow وAcruxCore، بوابةً وأداةً لتتبّع الطلبات ضمن منتج واحد.

مبررات إبقائهما منفصلين

ينطوي دمج البوابة في أداة التتبّع على تكاليف، وأكبرها الترابط. فعند استخدام بوابة منفصلة، يستطيع الفريق تغيير مزوّد أداة التتبّع بتغيير دالة ردّ نداء للتسجيل. أما عندما تكون أداة التتبّع هي البوابة أيضًا، فيلزم تغيير عنوان URL الأساسي والمفاتيح ومعرّفات النماذج في كل خدمة. فعلى سبيل المثال، تكتب Langfuse معرّفات النماذج بصيغة credential:model.

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

تسعى شركات الأمن إلى تولي الموقع نفسه في مسار الطلبات. وقد أتمّت Palo Alto Networks استحواذها على Portkey، وهي بوابة مستقلة، في مايو 2026، وجعلتها بوابة الذكاء الاصطناعي لمنصة Prisma AIRS التابعة لها. وقد يفضّل فريق الأمن أن تكون البوابة تحت سيطرته بدلًا من أن تكون جزءًا من أداة للرصد والمراقبة. وأصبحت البوابات أيضًا هدفًا للمهاجمين، كما أظهر الاختراق الذي استهدف سلسلة توريد LiteLLM في مارس.

كيف تختار الفرق

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

بعد ذلك، يأتي دور تغطية مزوّدي الخدمة. ينبغي للفريق تدوين كل مزوّد خدمة وتنسيق واجهة API يستخدمه في بيئة الإنتاج، بما في ذلك Azure OpenAI وBedrock، ثم مقارنة هذه القائمة بما تدعمه كل بوابة حاليًا، لا بما تدرجه ضمن خطتها المستقبلية.

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

صُنّفت معظم هذه البوابات على أنها تجريبية أو في مرحلة المعاينة، لذا ستتقلص قائمة أوجه القصور بسرعة. والسؤال المفتوح هو: من سيتولى إدارة مسار الطلبات داخل الشركة المعتادة؟ أهو فريق الرصد والمراقبة، أم فريق المنصات الذي يدير بوابة مستقلة، أم فريق الأمن؟ في هذا العام، أنشأت LangSmith وLangfuse بوابتين خاصتين بهما، واستحوذت Palo Alto Networks على إحداهما، ومع ذلك لا يزال مسار الطلبات يمر عبر LiteLLM في كثير من بيئات التقنية.