پس از محدود شدن مدل منبع باز چین، اولین چیزی که باید افزایش یابد هزینه تأیید است.

پس از محدود شدن مدل‌های منبع باز، اولین چیزی که گران می‌شود معمولاً خود مدل نیست، بلکه تأیید است. اینکه آیا مدل هنوز می تواند پایین کشیده شود یا خیر، تنها لایه اول است. پس از پایین کشیدن، اینکه آیا فرمت خروجی، فراخوانی ابزار، خط مشی رد، طول زمینه و پارامترهای نمونه می‌توانند همچنان با نسخه قدیمی تراز باشند یا خیر، تعیین می‌کنند که آیا سیستم همچنان پایدار است یا خیر.

چیزی که به نظر می رسید یک مشکل تامین بود وقتی به تیم می رسید به یک مشکل مهندسی تبدیل می شد. هنگامی که یک مدل وارد فرآیند می شود، لایه دسترسی به ندرت تنها با یک آدرس API باقی می ماند. کلمات سریع، طرحواره، تلاش‌های مجدد، زمان‌بندی‌ها، موقعیت‌های کوتاه‌سازی، و دنباله‌های فراخوانی ابزار به تدریج به مقدمات ضمنی تبدیل می‌شوند. هنگامی که نسخه پایدار است، این مکان ها می توانند توسط تجربه پشتیبانی شوند. هنگامی که مدل محدود است، تصویر انشعابات دارد، یا عملکرد نسخه ای با همین نام تغییر می کند، تجربه شروع به شکست می کند. اولین چیزی که اثر خود را از دست می دهد اغلب قضاوت رگرسیون است، زیرا مجموعه تست فقط به سیستم می گوید که چه چیزی خراب نیست و نمی تواند مستقیماً بگوید چه چیزی تغییر کرده است.

فرض پیش فرض این است که ابتدا گره خورده و برگردانده می شود.

در گذشته، گروهی از کیس های طلایی می توانستند برای مدت طولانی اجرا شوند. بیشتر اوقات، آنها فقط به این موضوع نگاه می کردند که آیا خروجی به وضوح منحرف شده است یا خیر. مدل ثابت است و کلمه prompt نیز ثابت است. همه به طور پیش فرض روی “این پیوند تایید شده است” خواهند بود. به محض ظاهر شدن محدودیت ها، این پیش فرض شروع به فروپاشی می کند. مدل‌ها ممکن است مناطق، تصاویر یا نسخه‌ها را تغییر دهند و حتی مدل‌هایی با نام یکسان ممکن است در دوره‌های زمانی مختلف رفتار متفاوتی داشته باشند. در این زمان، رگرسیون دیگر درباره قضاوت در مورد اینکه آیا می توان از آن استفاده کرد نیست، بلکه درباره قضاوت این است که تغییر روی کدام لایه قرار می گیرد و آیا ارزش تغییر ارزش تغییر را دارد یا خیر.

توزیع و بازگشت تغییرات کوچک را بزرگتر می کند

پس از محدود شدن مدل، اولین کارهایی که باید انجام دهید دانلود، آینه‌سازی، تأیید، ممیزی و بازگشت است. در ظاهر، فقط به یک مدل موجود تغییر می کند. در واقع، قفل نسخه، همگام سازی حافظه پنهان، کنترل مجوز و failover را اضافه می کند. تا زمانی که توزیع مدل لایه مستقلی نداشته باشد، کسب و کار این وظایف را به ریتم انتشار خودش برمی‌گرداند. نتیجه اغلب «انطباق بیشتر» نیست، اما قرارداد ورودی و خروجی باید هر بار که به‌روزرسانی می‌شود دوباره تأیید شود.

اولین چیزی که لایه خنثی خاموش می شود، توانایی مدل نیست.

آنچه واقعاً باید از هم جدا شود، معمولاً خود مدل نیست، بلکه لایه‌ای از مرزهای خنثی در اطراف مدل است: قالب‌های کلمه فوری، تأیید طرحواره، استراتژی‌های مسیریابی، منطق امتحان مجدد، گزارش‌ها و ارزیابی‌ها. کنار هم قرار دادن این موارد برای دنبال کردن نظم نیست، بلکه اجازه دادن به تغییرات در یک مجموعه از قراردادها است. مدل را می توان جایگزین کرد، ورودی و خروجی نمی تواند جابجا شود، و خط پایه رگرسیون نمی تواند پراکنده شود. هنگامی که لایه خنثی ایجاد شد، بسیاری از رفتارهای پیش‌فرض که در ابتدا از طریق تجربه به خاطر سپرده شده‌اند، به مواردی تبدیل می‌شوند که می‌توان آنها را مقایسه کرد، عقب انداخت و دوباره پخش کرد.

همه پروژه ها ارزش انجام این لایه را ندارند.

چکیده‌های یک‌باره، آزمایش‌های داخلی، اسکریپت‌های کوتاه مدت، که مستقیماً به مدل متصل می‌شوند کافی است. آنچه به یک لایه خنثی نیاز دارد سناریویی است که در آن مدل شروع به مشارکت در قضاوت تولید کرده است و احتمال زیادی وجود دارد که تامین کننده یا منطقه بعداً تغییر کند. برای این سیستم‌ها، مشکل اصلی نوشتن چند خط بیشتر از سازگاری نیست، بلکه این است که رفتارهای پیش‌فرض اصلی به صراحت مشخص نشده‌اند. بدون این لایه، هر بار که مدل تغییر می کند، ریتم بازگشت، توزیع و انتشار باید دوباره محاسبه شود.

به اصطلاح مهر و موم اغلب فقط هزینه های تأیید، توزیع و بازگشت ذخیره شده اولیه را به یکباره به تیم بازپرداخت می کند. مدل‌ها تغییر می‌کنند و پیوندها با شانس تثبیت نمی‌شوند. قبل از اینکه بتوانیم در مورد ادامه استفاده از مدل صحبت کنیم، ابتدا باید پیوند تأیید را جدا کنیم.