بوابة نماذج لغوية (LLM gateway) للوصول والتكلفة والحوكمة

مفتاح واجهة برمجية (API) واحد لفريق واحد، مشترك بين ثلاث خدمات ومُلصَق داخل دفتر ملاحظات (notebook)، هو الطريقة التي يبدأ بها معظم إنفاق النماذج ومعظم التعرّض للامتثال. بوابة النماذج اللغوية (LLM gateway) هي وسيط تستدعيه كل التطبيقات بدل استدعاء المزوّد مباشرةً. تحتفظ البوابة بالاعتمادات (credentials)، وتُرفق هوية بكل طلب، وتفرض الحصص والسياسات، وتكتب أثرًا للتدقيق. فتحصل على مكان واحد ترى وتضبط منه ما يغادر المؤسسة.

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

ما الذي يقع بين تطبيقاتك والمزوّدين

البوابة وسيط عكسي (reverse proxy) يتحدّث بواجهات المزوّدين على الجانب الصادر، وبواجهة موحّدة (normalized API) على الجانب الوارد. تصادق التطبيقات عليها باعتماداتها الخاصة قصيرة العمر. ولا ترى قط مفاتيح المزوّد. فتلك تعيش في مدير أسرار (secrets manager) وتُدوَّر وفق جدول لا يلزم التطبيقات معرفته.

بشكل ملموس، يصل طلب، وقبل أن يذهب إلى أي مكان تنفّذ البوابة تسلسلًا ثابتًا:

• تحلّ هوية المُستدعي إلى هوية تطبيق وفريق، حتى يكون لقرارات التكلفة والوصول موضوع محدّد.
• تتحقق من الطلب مقابل السياسة: هل يُسمح لهذا التطبيق باستدعاء هذا النموذج، بهذا التصنيف من البيانات، لهذا الغرض المُعلَن.
• تطبّق الحصص وحدود المعدّل (rate limits) على مستوى الهوية، وترفض أو تضع في الطابور عند نفاد الميزانية بدل تمرير الاستدعاء.
• تعيد كتابة الطلب على أيّ مزوّد ونموذج تختاره قواعد التوجيه (routing rules)، وتحقن الاعتماد الحقيقي.
• تدفّق الاستجابة عائدةً مع تسجيل التبادل الكامل وأعداد الرموز (tokens) التي يعيدها المزوّد.

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

ضوابط تكلفة تعضّ قبل أن تفعل الفاتورة

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

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

• حصص صارمة لكل هوية، حتى لا يتمكن فريق من إنفاق هامش فريق آخر.
• تنبيهات مرنة قبل الحدّ الصارم، مُوجَّهة إلى الفريق المالك، لا إلى قناة عمليات عامة لا يقرؤها أحد.
• نسبٌ حسب الغرض، ليرى قسم المالية أن صياغة المستندات كلّفت شيئًا ومراقبة المعاملات (transaction monitoring) كلّفت شيئًا آخر، ويسعّر إعادة التحميل الداخلي (chargeback) وفق ذلك.
• سياسة لفئة النموذج (model tier)، حتى لا تُوجَّه مهمّة تلخيص خفية إلى أغلى نموذج لمجرّد أن مطوّرًا نسخ مقتطفًا.

النسب هو ما يحوّل التكلفة من مفاجأة شهرية إلى بند يملكه شخص ما. وهو يغذّي أيضًا تخطيط السعة (capacity planning)، لأنك أصبحت تملك طلبًا حقيقيًا لكل حِمل عمل بدل فاتورة مزوّد واحدة معتمة.

أثر التدقيق وطبقة السياسات

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

هذا ما يجعل سؤال الطرف الثالث قابلًا للإجابة. إرسال بيانات عميل إلى نموذج خارجي هو علاقة معالِج (processor)، وبموجب لائحة DORA يُعدّ المزوّد طرفًا ثالثًا لتقنية المعلومات والاتصالات (ICT third party) يُتوقَّع منك مراقبته والقدرة على الخروج منه. تمنحك البوابة سطح المراقبة: ما الذي ذهب، إلى مَن، ومتى، وهل كان ينبغي أن يذهب. وحين تحتاج إلى قطع مزوّد، تفعل ذلك عند البوابة فتتوقف الاستدعاءات في كل مكان دفعة واحدة.

تجلس السياسة عند نقطة الاختناق نفسها. ولأن كل استدعاء يمرّ عبرها، يمكنك فرض قواعد لا يمكن الوثوق بأي تطبيق منفرد لفرضها على نفسه:

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

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