تبدأ معظم المؤسسات بمزوّد واحد للذكاء الاصطناعي. يختار فريق نموذجاً، ويكتب الشيفرة باستخدام SDK الخاصة بذلك المزوّد، ويطلق شيئاً مفيداً. ثم يظهر نموذج أرخص، أو نموذج أفضل لمهمة معينة، أو يطلب عميل أن تبقى بياناته لدى مزوّد يستخدمه بالفعل. فيأتي مزوّد ثانٍ، ثم ثالث، ولكل منهم SDK خاصة به، وأسماء معاملات ومفاتيح وحدود مختلفة.
تضع بوابة النماذج (LLM gateway) طبقة واحدة بين تطبيقاتكم وهؤلاء المزوّدين. تطلب التطبيقات النموذج باسمه، فترسل البوابة الطلب إلى المزوّد المناسب، وتطبّق السياسات، وتسجّل ما حدث. يشرح هذا المقال كيف تُصمَّم هذه الطبقة، استناداً إلى بوابة أنشأناها لشركة استشارات عالمية تختار فرقها من بين 45 نموذج محادثة لدى ستة مزوّدين.
حدود التكامل المباشر
ربط كل سير عمل بمزوّد مباشرة هو أسرع طريقة للبدء، لكنه يصبح مكلفاً من ثلاث نواحٍ مع ازدياد عدد مسارات العمل والمزوّدين.
ارتباط بالمزوّد على مستوى الشيفرة
لكل مزوّد SDK ومعاملات وأسماء نماذج خاصة به. والشيفرة المكتوبة لمزوّد لا تنتقل بسهولة إلى آخر عندما تتغير الأسعار أو الجودة أو التوفر، وتزداد تكلفة التبديل مع كل سير عمل جديد.
غياب نقطة تحكم واحدة
تتوزع المفاتيح على خدمات متعددة. ولا يظهر الاستخدام إلا في فاتورة كل مزوّد على حدة. وتُطبَّق سياسات الأمان في كل سير عمل بشكل منفصل، هذا إن طُبّقت أصلاً.
غياب الرؤية لما يفعله الوكلاء
يخفق الوكلاء الأذكياء متعددو الخطوات بطرق يصعب إعادة إنتاجها. ومن دون سجل لكل استدعاء للنموذج ومدخلاته، يصبح تصحيح الأخطاء تخميناً.
البنية المعمارية في خمسة أجزاء
البوابة أكثر من مجرد وسيط يمرّر الطلبات. تعمل الأجزاء أدناه معاً بحيث يصبح اختيار النموذج قراراً في الإعدادات، وتتركز الرقابة في مكان واحد.
واجهة محايدة تجاه المزوّدين
تستدعي التطبيقات واجهة واحدة بدلاً من SDK خاصة بمزوّد. توفر مكتبات مثل LangChain ذلك، وكذلك البوابات التي تقبل صيغة طلب واحدة لكل المزوّدين. والقاعدة بسيطة: لا يستورد أي سير عمل SDK مزوّد بشكل مباشر.
فهرس للنماذج يُدار كإعدادات
صِفوا كل نموذج بالمزوّد واسم النموذج ومجموعة صغيرة من إعدادات السلوك: درجة الحرارة (temperature)، وقيمة بذرة (seed) حيث يجب أن تكون المخرجات قابلة للتكرار، وحدّ أقصى لعدد الرموز (tokens). تحققوا من صحة هذه الإعدادات قبل إنشاء النموذج، كي يظهر الخطأ عند تحميل الإعدادات لا في بيئة الإنتاج. واحفظوا نماذج الاستدلال في فهرس مستقل، لأنها تأخذ إعدادات مختلفة وتخدم أعمالاً مختلفة.
بوابة في مسار الطلب
يمرّ كل استدعاء للنموذج عبر البوابة، فتوجّهه إلى المزوّد، وتطبّق السياسات المرتبطة بالجهة المستدعية، وتسجّل الاستدعاء. احفظوا مفاتيح المزوّدين في البوابة أو في مخزن للبيانات السرية، كي لا تحتاج التطبيقات إلى الاحتفاظ بها أبداً.
سياسات تُربط بالإحالة إليها
عرّفوا سياسات ضوابط الحماية في البوابة، ثم اربطوها بوكيل ذكي أو سير عمل عن طريق اسمها. يمكن تغيير السياسة من دون إعادة نشر، وتُطبَّق السياسة نفسها في كل مكان ترتبط به.
تتبع لكل سلسلة
سجّلوا التعليمات المُدخلة للنموذج، والاستجابة، والتوقيت، والنموذج المستخدم في كل خطوة من خطوات الوكيل الذكي متعدد الخطوات. وعندما يتصرف الوكيل على نحو غير متوقع، يُظهر التتبع الخطوة التي أخطأت وما الذي أُعطي لها. استخدمنا LangSmith لهذا الغرض.
بوابة قابلة للاستبدال
تزيل البوابة الارتباط بمزوّدي النماذج، لكن منتج البوابة نفسه قد يصبح الارتباط التالي. والحل هو النمط نفسه على مستوى أدنى: ضعوا البوابة خلف واجهة تملكونها.
تغيير النموذج بأمان
تجعل البوابة تغيير النموذج قليل التكلفة، لكنها لا تجعله آمناً. فقد يختلف نموذجان يتلقيان التعليمات نفسها في الدقة والصيغة والطول والتكلفة والسرعة، وكثيراً ما تحتاج التعليمات التي ضُبطت لنموذج إلى تعديل عند استخدامها مع آخر.
احتفظوا بمجموعة تقييم لكل استخدام
اجمعوا مدخلات تمثيلية مع المخرجات التي تتوقعونها، بما فيها الحالات الصعبة. شغّلوا النموذج المرشح عليها وقارنوا النتائج قبل أن يحل محل النموذج الحالي.
سجّلوا قدرات كل نموذج
تختلف النماذج في نافذة السياق، واستدعاء الأدوات، والمخرجات المنظمة، وقبول الصور كمدخلات. احفظوا هذه الخصائص في الفهرس كي لا يُوجَّه سير عمل إلى نموذج يفتقر إلى ما يحتاجه.
غيّروا شيئاً واحداً في كل مرة
انقلوا سير عمل واحداً أو فريقاً واحداً إلى النموذج الجديد أولاً، وراقبوا السجلات ونتائج التقييم، ثم وسّعوا نطاق التغيير. ويجعل الفهرس العودة إلى النموذج السابق بالسهولة نفسها.
قرارات قبل البناء
بوابة مُدارة أم بوابة خاصة بكم
يمنحكم المنتج المُدار التوجيه والسياسات والتسجيل بسرعة. أما بناء بوابتكم الخاصة فيمنحكم تحكماً كاملاً، ومعه عبء صيانتها. وفي الحالتين، ضعوها خلف واجهتكم الخاصة.
أين يُسمح للبيانات أن تذهب
حددوا أيّ المزوّدين يجوز أن يتلقوا أيّ البيانات قبل إدخال أي نموذج إلى الفهرس. وبالنسبة لبعض المؤسسات، يستبعد هذا مزوّدين أو مناطق بعينها تماماً.
ماذا يعني النموذج نفسه
ثبّتوا إعدادات السلوك لكل مدخل في الفهرس كي يتصرف النموذج بشكل متسق عبر الفرق. وسجّلوا قيمة البذرة (seed) حيث يلزم إعادة إنتاج النتائج.
من يملك الفهرس
لا بد أن يتولى أحد إضافة النماذج ومراجعتها وإيقاف استخدامها. تعاملوا مع الفهرس كأي إعدادات مشتركة أخرى، مع مراجعة وسجل للتغييرات.
البدائل والحدود
يتعرض المزوّدون لانقطاعات وحدود لمعدل الطلبات. حددوا أيّ الطلبات يجوز تحويلها إلى نموذج بديل، وأيّها ينتظر ويعيد المحاولة، وأيّها يجب أن يفشل بوضوح. والنموذج البديل يحتاج إلى التقييم نفسه الذي يحتاجه أي تغيير آخر.
ما الذي يجوز أن تحتويه السجلات
تسجّل سجلات البوابة والتتبع التعليمات المُدخلة والاستجابات، وقد تتضمن بيانات العملاء أو بيانات شخصية. حددوا من يمكنه الاطلاع عليها، ومدة الاحتفاظ بها، وما يجب إخفاؤه قبل تسجيل أي شيء.
التكلفة حسب الفريق والاستخدام
لأن كل استدعاء يمرّ عبر مكان واحد، فالبوابة هي المكان الذي يمكن فيه نسبة الاستخدام إلى فريق أو سير عمل ووضع حدود له. اتفقوا على الميزانيات والتنبيهات قبل أن يزداد الاستخدام، لا بعد أول فاتورة كبيرة.
البوابة كاعتمادية
كل استدعاء للنموذج يعتمد الآن على البوابة، لذا تحتاج إلى المراقبة والتخطيط للاستعادة كأي خدمة حرجة أخرى. كما أن البوابة المُدارة تطّلع على كل الطلبات المتجهة إلى نماذجكم، وهذا يدخل ضمن قرار البيانات المذكور أعلاه.
قائمة تحقق
- لا يستورد أي سير عمل SDK مزوّد بشكل مباشر
- كل نموذج مُدخل في الفهرس بإعدادات تم التحقق منها
- مفاتيح المزوّدين محفوظة في البوابة أو في مخزن للبيانات السرية، لا في التطبيقات
- السياسات تُعرَّف مرة واحدة وتُربط بالإحالة إليها
- كل سلسلة وكلاء خاضعة للتتبع، والسجلات تتبع قواعد متفقاً عليها للاحتفاظ والإخفاء
- النموذج المرشح يجتاز مجموعة التقييم قبل أن يحل محل النموذج الحالي
- البدائل وحدود معدل الطلبات وحدود التكلفة محددة لكل استخدام
- منتج البوابة يعمل خلف واجهة تملكونها
في التطبيق العملي
تصف دراسة الحالة أدناه المنصة التي يستند إليها هذا المقال: فهرس النماذج، وخيارا البوابة، وضوابط الحماية المرتبطة بكل وكيل، والتتبع لسلاسل الوكلاء.
بوابة واحدة إلى 45 نموذجًا من ستة مزوّدين للذكاء الاصطناعي، مع ضوابط الحماية والتتبع
طبقة نماذج موحدة تتيح للفرق اختيار النماذج وتغييرها دون إعادة بناء سير العمل لديها، مع إدارة التوجيه والسياسات والتتبع في مكان واحد.
قراءة دراسة الحالةأسئلة شائعة
ما بوابة النماذج (LLM gateway)؟
خدمة تقع بين تطبيقاتكم ومزوّدي نماذج الذكاء الاصطناعي. تستقبل كل طلب موجّه إلى نموذج، وترسله إلى المزوّد المختار، وتطبّق سياسات مثل ضوابط الحماية وقواعد الوصول، وتسجّل كل استدعاء لأغراض تصحيح الأخطاء والرقابة.
هل نحتاج إلى بوابة إذا كنا نستخدم مزوّداً واحداً فقط؟
ليس دائماً. لكن إنشاء واجهة محايدة تجاه المزوّدين وفهرس للنماذج في وقت مبكر لا يكلّف كثيراً، ويجعل إضافة مزوّد ثانٍ تغييراً في الإعدادات بدلاً من مشروع كامل.
هل تُبطئ البوابة الطلبات؟
تضيف خطوة إلى كل طلب. في معظم التطبيقات تكون هذه الخطوة صغيرة مقارنة بالوقت الذي يستغرقه النموذج للرد، لكن قيسوها في الاستخدامات التي يكون فيها زمن الاستجابة مهماً.