التوافق يحدّد الصيغة، والاتفاق يحدّد السلوك
تقلّل صيغة موحّدة للطلب والاستجابة من التعديلات المطلوبة في التطبيق، وتسهّل تغيير النموذج أو المزوّد. كما تسمح بجمع الوصول خلف واجهة واحدة. لكن تطابق الحقول لا يخبر الفريق هل قُبل الطلب، وأي مزوّد نفّذه، ومتى تجوز إعادته، وكيف تُصنّف الاستجابة الجزئية، وكيف تُطابق بيانات الاستهلاك النهائية. حين يعتمد الناس على النظام، تصبح هذه الأسئلة جزءًا من اتفاق المنتج معهم.
لذلك تحتاج البوابة إلى حدود واضحة للتحقق من المدخلات، وتطبيق شروط السماح والسياسات، واختيار المسار، والتنفيذ، وتصنيف النتيجة، وإثبات الاستهلاك. هذه مسؤوليات تصميمية، وليست ادعاءً بأن كل بوابة تنفذها بالطريقة نفسها. نجاح تبادل HTTP لا يثبت اكتمال العمل؛ وبالعكس، قد يفقد المتصل الاستجابة بعد أن يكون المزوّد قد أنجز العمل. وضع الحالتين تحت وصف «خطأ» عام يخفي القرار الذي يحتاج المشغّل إلى اتخاذه.
البث سلسلة من الأدلة، وليس إجابة واحدة
يتيح البث للتطبيق إظهار بداية المخرجات فيما لا يزال النموذج يولّد بقيتها. فالبث عبر HTTP الموصوف في وثائق OpenAI يستخدم أحداثًا يرسلها الخادم، ويميّز أجزاء النص المتتابعة عن حدث الاكتمال. قد يعرض التطبيق بداية مفيدة قبل أن يعرف هل اكتمل الرد. وإذا وصلته فقرتان ثم انتهت مهلة الاتصال، فلا يثبت النص الظاهر أن العملية اكتملت. [2]
ينبغي للبوابة الاحتفاظ بما تعرفه: هوية الطلب، والمسار المختار، وهل قبل المزوّد الطلب، والأحداث التي رُصدت، وهل تأكّد الاكتمال. ويجب فصل الإجابة الجزئية الظاهرة عن النتيجة النهائية. هذه توصية معمارية، لا وعد بأن كل مزوّد يتيح استئناف البث. يمكن للنظام عرض النتيجة الناقصة، أو طلب قرار صريح بشأن محاولة جديدة، أو فحص سجل لدى المزوّد إن كان متاحًا. المهم تسمية حالة عدم اليقين بدل تحويلها خفية إلى نجاح أو فشل.
قبل الإعادة، احسب احتمال تكرار العمل
لنفترض طلبًا توضيحيًا بحتًا لصياغة نص. يبدأ المزوّد إرسال المخرجات؛ يتلقى التطبيق فقرتين، ثم ينقطع الاتصال بانتهاء المهلة. قد يواصل المزوّد التوليد ويحتسب تكلفة ما أنجزه. وإذا أعاد التطبيق الطلب نفسه فورًا، فقد يحدث توليد ثانٍ وتكلفة ثانية، حتى لو عُرضت إجابة واحدة للمستخدم. انتهاء المهلة لا يثبت أن المحاولة الأولى لم تقع. وتوضح وثائق Chat Completions لدى OpenAI أن انقطاع البث قد يمنع وصول الجزء الأخير الذي يتضمن إجمالي الاستهلاك. [3]
تجعل دلالات HTTP هذا الحذر محددًا: لا ينبغي للعميل أن يعيد تلقائيًا طلبًا غير متّسم بخاصية تساوي أثر التكرار، إلا إذا عرف أن العملية كذلك فعليًا أو أن الطلب الأول لم يُنفّذ؛ ولا يجوز للوسيط إعادته تلقائيًا. وغالبًا ما يُستدعى توليد النماذج عبر POST، لذا لا تكفي هيئة الواجهة المألوفة للحكم بأمان الإعادة. [1] قد تسمح السياسة بالإعادة قبل الإرسال، أو تستخدم آلية منع التكرار إن دعمها المزوّد، أو تتطلب محاولة جديدة صريحة بعد بث ملتبس. إنها موازنة بين السرعة والسهولة من جهة، وتكرار العمل وغموض التكلفة من جهة أخرى.
قرّر هل التنفيذ مسموح قبل اختيار مكانه
يجيب التوجيه عن مكان تنفيذ طلب مؤهل؛ وتجيب السياسة عمّا إذا كان التنفيذ مسموحًا وتحت أي قيود. قد تشترط المهمة نوعًا من المحتوى، أو سعة سياق، أو منطقة، أو قائمة مزوّدين معتمدين، أو صلاحيات أدوات، أو سقف إنفاق. إن تعذّر المزوّد المفضّل، فلا يفيد البديل إلا إذا ظل مستوفيًا لهذه الشروط. التحوّل بصمت إلى مسار غير مؤهل يغيّر الاتفاق مع التطبيق.
يمكن تصور المسار التالي: التحقق من الطلب ← تقييم السياسة والميزانية ← اختيار مسار مؤهل ← التنفيذ ضمن مهلة ← تصنيف النتيجة ← تسجيل الاستهلاك المرصود ← إصدار حدث الفوترة عبر النظام المستقل للمنتج المعني. هذا رسم توضيحي للبنية، وليس وصفًا لآليات داخلية أُطلقت في RouterShift. ينبغي أن يكون اختيار المسار ومعالجة الإخفاق والمحاسبة قابلًا للشرح كلٌّ على حدة. يسهل تدقيق القواعد الحتمية؛ وقد يفيد الاختيار التكيفي مع وجود تغذية راجعة موثوقة، لكنه يتطلب تفسير كل قرار.
قِس ما رُصد قبل تحويله إلى مبلغ
الطلب ومحاولة التنفيذ وسجل الاستهلاك النهائي لدى المزوّد وقائع مختلفة. عند انقطاع البث، قد لا تتوفر القيمة النهائية؛ ولا يصح تقديم تقدير مبني على النص الظاهر بوصفه رسمًا نهائيًا. ينبغي حفظ سجل المزوّد الأصلي وهوية المحاولة وأساس أي تقدير. وعند وصول بيانات موثوقة، يمكن مطابقتها؛ ويجب أن تترك التصحيحات أثرًا قابلًا للتتبع. [3]
تضع اصطلاحات OpenTelemetry الحالية للذكاء الاصطناعي التوليدي أسماء لرموز الإدخال والإخراج، وسياق النموذج والمزوّد، وفئات الأخطاء. إنها مفردات للرصد، وليست نظام فوترة أو ضمانًا لتوحّد وحدات القياس بين المزوّدين. وتحذّر أيضًا من احتمال احتواء الرسائل المسجلة على معلومات حساسة. [4] يأتي التسعير وحركة الرصيد بعد القياس، مع عملة ونسخة سعر ومسار تدقيق. وقد تحتاج مهام الصورة والصوت والفيديو إلى وحدات غير الرموز النصية.
اجعل الاتفاق قابلًا للفحص في التشغيل اليومي
عند وقوع مشكلة، ينبغي للفريق أن يعرف: أي طلب تأثر؟ أي مسار اختير ولماذا؟ هل قبل المزوّد العمل؟ هل المخرجات مكتملة؟ ما الاستهلاك المؤكد أو المقدّر أو المجهول؟ وأي نسخة من السياسة والسعر طُبقت؟ تساعد معرّفات الطلبات والمحاولات، وحالات النتائج، وروابط التتبع في الإجابة دون تسجيل محتوى الطلبات النصية افتراضيًا. ويجب أن تكون الواجهة مفهومة للفريق الذي يشغّل المنتج، لا للمطورين وحدهم.
تختبر هذه الأسئلة أيضًا وعود البوابة. فإذا حدث الإخفاق قبل إرسال الطلب، قد يصلح مسار بديل مؤهل. وإذا انقطع البث بعد بدء التوليد، ينبغي إعلان النتيجة ناقصة أو غير مؤكدة وشرح الخيارات التالية. وإذا غابت بيانات الاستهلاك، تبقى قيد المطابقة. يخفض توافق الواجهة تكلفة البدء؛ أما اتفاق التشغيل فيجعل السلوك متوقعًا عندما تنتهي الظروف المثالية. RouterShift منتج SlateMoth العامل للوصول إلى النماذج. يشرح هذا الإطار مشكلة التصميم، ولا يدّعي أن كل آلية ذُكرت قد أُطلقت فيه.