De risico's van het open source-model liggen in de eerste plaats op de toegangslaag

De afgelopen dagen is er discussie geweest over de vraag of open source-modellen vast zullen komen te zitten door het verkrappende beleid van de Verenigde Staten. Het eerste dat verandert in de techniek zijn niet de modelmogelijkheden, maar de standaardtoegankelijkheid. Het model is er nog, evenals de papieren. Wat het eerst echt trilt zijn het pull-adres, de mirrorbron, het hostingplatform, de licentievoorwaarden en de regionale beschikbaarheid. Het eerste waar mensen die wel toegang tot werk hebben vaak tegenaan lopen is niet ‘het model is niet sterk genoeg’, maar ‘kunnen we het vandaag de dag nog wel stabiel krijgen?’

De standaard bereikbaarheid wordt eerst slechter

In het verleden was het meest vervelende probleem bij het verkrijgen van toegang tot modellen “hetzelfde model kon gisteren worden gedownload, maar kreeg vandaag plotseling een 403.” Dit type verandering lijkt op een kleine fluctuatie in de toeleveringsketen, maar sleept in feite de hele link in een onstabiele toestand: het downloaden van het gewicht moet opnieuw worden geprobeerd, de bron van de afbeelding moet worden gewijzigd, de controlesom moet opnieuw worden berekend, de implementatie-image moet opnieuw worden verpakt en de cache in de CI wordt ook ongeldig. Op het eerste gezicht wordt alleen de stap om het model te verkrijgen broos gemaakt, maar in feite wordt het uitgangspunt van ‘bruikbaarheid’ uit het systeem weggenomen.

Het open source-model wordt vaak opgevat als “nadat de code open source is, zal deze niet langer door anderen worden beheerd.” Deze zin klopt maar half. Open source-code betekent niet dat deze standaard toegankelijk is, en zichtbaar zijn in het magazijn betekent niet dat de productieomgeving stabiel kan worden gelanceerd. Wie host het, in welke regio het bestaat, of de licentie is gewijzigd en of er beperkingen zijn op de downloadfrequentie. Zodra deze details worden geblokkeerd door het platform, het beleid of de zakelijke voorwaarden, ziet het team niet dat het model verdwijnt, maar dat dingen die gemakkelijk verkrijgbaar waren een infrastructuur worden die moet worden onderhouden.

De modelinterface wordt vergroot tot aan de systeemgrens

In het verleden, toen ik alle details van modelrouting schreef, was het moeilijkste om te verzamelen niet dat de score twee of drie punten verschilde, maar dat de modelinterface niet stabiel genoeg was. Zodra een basis is vervangen, zullen de promptgewoonten, de uitvoerstructuur, het toolaanroepformaat en het lange contextgedrag allemaal dienovereenkomstig veranderen. De modelnaam lijkt niet te zijn veranderd, maar de parser, evaluatieset, replay-log en foutafhandeling in het systeem moeten opnieuw worden uitgevoerd. Wat op dat moment het gemakkelijkst aan het licht kwam, was dat het systeem ‘een bepaald model’ aanzag voor ‘een bepaald vermogen’.

Dit is ook het meest over het hoofd geziene gebied in discussies over open source-modellen. Wat echt waardevol is, is niet de naam zelf, maar de reeks vervangbare mogelijkheden die deze kan bieden: voltooiing, classificatie, extractie, dialoog, het aanroepen van tools, een lange samenvatting van artikelen en het genereren van code. Zolang de toegangslaag deze mogelijkheden aan specifieke modellen koppelt, zullen eventuele daaropvolgende wijzigingen worden uitvergroot in de migratiekosten. Aan de andere kant, als de interfacelaag eerst wordt gecondenseerd tot een stabiel contract, kan de basis als een afhankelijkheid worden vervangen en zal het risico slechts in beperkte mate worden beperkt.

Routing en fallback zijn belangrijker dan zelfstandige naamwoorden

Of het open source-model nu ‘verzegeld’ zal zijn of niet, de impact op het uiteindelijke systeem is meestal niet de naam van het model, maar of er een uitweg is. Als een team alle taken op één enkel extern model plaatst, zullen eventuele geografische beperkingen, toegangsbeperkingen of veranderingen in bedrijfsstrategieën direct tot bedrijfsonderbrekingen leiden. Integendeel, zolang lokaal uitvoerbare modellen, back-uphostingbronnen, modelpools met verschillende capaciteitsniveaus en herspeelbare evaluatiesets allemaal aanwezig zijn, zullen externe beperkingen op zijn best de overstapkosten verhogen en het systeem niet onmiddellijk onbeschikbaar maken.

Daarom kun je bij het beoordelen op modelniveau niet alleen de vraag stellen “welk model is sterker”, maar ook de vraag “kan deze vermogensketen worden vervangen door een basis?” Kunnen de gewichten in een controleerbaar magazijn worden bewaard? Kunnen afhankelijkheden worden opgesloten in vaste versies? Kunnen routering, caching, afspelen en terugdraaien worden omgezet in een complete reeks acties? Deze vragen liggen dichter bij de echte grens dan de modelnaam. Het risico dat het model wordt beperkt zal niet eerst verdwijnen, maar de standaardbereikbaarheid zal eerst veranderen; en wat het systeem moet onderhouden is nooit een model, maar een reeks mogelijkheden die continu geleverd kunnen worden.