Nadat het open source-model is beperkt, is het eerste dat onafhankelijk moet zijn de modelneutrale laag.

Zodra een open source-model aan beperkingen wordt onderworpen, is het eerste dat aan het licht komt vaak niet de downloadinvoer, maar de standaardaannames in de code. De modelnaam is gewijzigd, maar de interface is er nog steeds, maar het bedrijfsproces loopt niet langer synchroon met het oude gedrag: uitvoerformaat, functieaanroepvolgorde, afwijzingstoon, contextlengte, bemonsteringsparameters, elk van deze kan afzonderlijk worden bekeken, maar als u ze op elkaar stapelt, wordt de hele link versleept.

Dit soort problemen zijn doorgaans moeilijk als een architectonisch probleem te beschouwen. Tijdens de ontwikkelingsfase zag ik alleen “can run”. Nadat ik online was gegaan, ontdekte ik dat de modelselectie al in de bedrijfslogica was geschreven. Sommige velden passen zich slechts aan één retourformaat aan, sommige nieuwe pogingen herkennen slechts één afwijzingsmethode, en sommige fallback voor uitzonderingen gebruiken standaard het oorspronkelijke model om een ​​langere uitleg te geven. Toen de beperkingen eenmaal waren opgelegd, kwamen al deze verborgen stapels bloot.

Het standaardgedrag koppelt het model aan het bedrijf

In de toegangsfase wordt het model vaak gezien als het toevoegen van een SDK, het verbinden van een API en het toevoegen van een promptwoord. Nadat er verbinding is gemaakt, is het moeilijkste om op te ruimen niet de oproep zelf, maar de vertakkingen die rond het standaardgedrag zijn gegroeid. Of de uitvoer strikt JSON moet zijn, of de toolaanroep opnieuw moet worden geprobeerd na een fout, waar te lange invoer moet worden afgekapt en op welke laag risicobeheersingsprompts moeten worden geplaatst. Deze kwesties vallen vaak onder de bedrijfscode.

Zodra een open source-model wordt beperkt of uit de schappen wordt gehaald, of het lokale imago en de upstream-versie beginnen te splitsen, is dit standaardgedrag niet langer betrouwbaar. Op het eerste gezicht verandert het alleen maar het model, maar daaronder is het noodzakelijk om tegelijkertijd het parseren, monitoren, terugdraaien en testen te veranderen. Het moeilijkste deel is niet om nog een paar aanpassingsregels te schrijven, maar dat de oorspronkelijke reeks aannames niet expliciet van begin tot eind wordt gemarkeerd.

De rol van de neutrale laag is het verspreiden van de impliciete aannames

Modelneutrale lagen zijn niet abstract omwille van de abstractie. De functie ervan is heel eenvoudig: plaats promptwoorden, schemaverificatie, routering, opnieuw proberen, downgraden, logs en evaluatie op één plek, zodat modelverschillen eerst dezelfde reeks grenzen overschrijden. Op deze manier zal het bedrijf, zelfs als het model wordt vervangen door cloud, open source, lokale inferentie of andere aanbieders, nog steeds een uniform input- en outputcontract zien.

Als deze laag eenmaal is gelegd, zullen veel dingen die oorspronkelijk onduidelijk waren, plotseling duidelijk worden. Welke velden verplichte waarden zijn, welke velden slechts modelvoorkeuren zijn, welke fouten opnieuw kunnen worden geprobeerd, welke fouten moeten worden teruggedraaid, welke contexten worden ingekort en welke indicatoren echt kunnen worden vergeleken, zullen allemaal veranderen van ‘onthouden door ervaring’ in ‘beperkt door interfaces’. De impact die het beperkte model veroorzaakt, wordt niet meer rechtstreeks in de bedrijfscode vastgelegd, maar eerst in de neutrale laag.

Niet alle scènes zijn deze laag waardig

Bij sommige scènes hoeven de lagen helemaal niet zo dik te zijn. Eenmalige samenvattingen, tijdelijke generatie, interne experimenten en volledig op één model vergrendelde gereedschapsketens, het is voldoende om het model op deze plaatsen te verbinden. Het bouwen van een volledig neutrale laag voor een kortstondig proces zal de kosten alleen maar op voorhand te boven gaan.

Deze laag is nodig waar het model echt zal deelnemen aan het zakelijke oordeel. Zoals extractie, routering, uitvoering van tools, reactie van de klantenservice, hulp bij beoordelingen en herschrijven van batches. In deze scenario’s is het model geen speelgoed, maar een onderdeel van het proces. Zolang het model kan veranderen, of externe beperkingen een bepaalde ingang kunnen destabiliseren, is de neutrale laag geen decoratie, maar een muur die verandering binnen de grenzen houdt.

Wat het open source-model echt aan banden legt, is niet het alternatief van een specifieke leverancier, maar de vraag of het team ‘modelverschillen’ als eersteklas burgers behandelt. Hoe eerder het standaardgedrag in de code wordt verspreid, hoe minder passief het zal zijn bij het later wijzigen van modellen. Het model kan veranderen, maar de grenzen kunnen niet volgen.