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

Once an open source model begins to be restricted, the first thing exposed is often not the download entry, but the default assumptions in the code. The model name has been changed, but the interface is still there, but the business process is no longer in sync with the old behavior: output format, function call sequence, rejection tone, context length, sampling parameters, any one of them can be viewed individually, but stacking them together will drag the entire link.

این نوع مشکل معمولاً دشوار است که به عنوان یک مشکل معماری در نظر گرفته شود. در مرحله توسعه، من فقط “can run” را دیدم. After going online, I discovered that the model selection had already been written into the business logic. Some fields only adapt to one return format, some retries only recognize one rejection method, and some exception fallback defaults to the original model to give a longer explanation. Once the restrictions were imposed, all these hidden piles were exposed.

رفتار پیش‌فرض مدل را با کسب‌وکار مرتبط می‌کند

In the access stage, the model is often regarded as adding an SDK, connecting an API, and adding a prompt word. After being connected, the most difficult thing to clean up is not the call itself, but the branches that have grown around the default behavior. آیا خروجی باید کاملاً JSON باشد، آیا فراخوانی ابزار باید دوباره پس از شکست امتحان شود، در کجا باید ورودی بیش از حد کوتاه شود، و در کدام لایه باید اعلان‌های کنترل ریسک را قرار داد. این مسائل اغلب در کد کسب و کار قرار می گیرند.

Once an open source model is restricted or removed from the shelves, or the local image and the upstream version begin to fork, these default behaviors are no longer reliable. On the surface, it is just changing the model, but underneath it is necessary to change the parsing, monitoring, rollback and testing at the same time. دشوارترین بخش نوشتن چند خط دیگر از اقتباس نیست، بلکه این است که مجموعه فرضیات اصلی به صراحت از ابتدا تا انتها مشخص نشده است.

نقش لایه خنثی گسترش مفروضات ضمنی است

لایه های مدل خنثی به خاطر انتزاع انتزاعی نیستند. عملکرد آن بسیار ساده است: کلمات سریع، تأیید طرحواره، مسیریابی، تلاش مجدد، تنزل رتبه، گزارش‌ها و ارزیابی را در یک مکان قرار دهید، به طوری که تفاوت‌های مدل ابتدا از همان مجموعه مرزها عبور کنند. In this way, even if the model is replaced by cloud, open source, local inference or other providers, the business will still see a unified input and output contract.

Once this layer is established, many things that were originally unclear will suddenly become clear. کدام فیلدها مقادیر مورد نیاز هستند، کدام فیلدها فقط ترجیحات مدل هستند، کدام خرابی‌ها را می‌توان دوباره امتحان کرد، کدام خرابی‌ها را باید به عقب بازگرداند، کدام زمینه‌ها کوتاه می‌شوند، و کدام شاخص‌ها واقعاً قابل مقایسه هستند، همگی از «به‌خاطر تجربه» به «محدود شده توسط رابط‌ها» تغییر خواهند کرد. تأثیر ناشی از مدل محدود دیگر مستقیماً وارد کد کسب و کار نمی شود، بلکه ابتدا در لایه خنثی وارد می شود.

همه صحنه ها شایسته این لایه نیستند

بعضی صحنه ها اصلا نیازی به ضخیم بودن لایه ها ندارند. One-time summaries, temporary generation, internal experiments, and completely single-model locked tool chains, it is enough to connect the model in these places. ساختن یک لایه خنثی کامل برای یک فرآیند کوتاه مدت فقط هزینه را از قبل افزایش می دهد.

This layer is needed where the model will really participate in business judgment. Such as extraction, routing, tool execution, customer service response, review assistance, and batch rewriting. در این سناریوها، مدل یک اسباب بازی نیست، بلکه بخشی از فرآیند است. تا زمانی که مدل ممکن است تغییر کند، یا محدودیت‌های خارجی ممکن است ورودی خاصی را بی‌ثبات کند، لایه خنثی دکوراسیون نیست، بلکه دیواری است که تغییرات را در محدوده‌ها نگه می‌دارد.

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