بعد تقييد نموذج المصدر المفتوح في الصين، فإن أول شيء يجب زيادته هو تكلفة التحقق.

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

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

الافتراض الافتراضي هو أنه سيتم ربطه وإعادته أولاً.

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

سيؤدي التوزيع والتراجع إلى تضخيم التغييرات الصغيرة

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

أول ما تغلقه الطبقة المحايدة ليس قدرة النموذج.

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

ليست كل المشاريع تستحق القيام بهذه الطبقة أولاً.

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

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