Zagrożenia modelu open source w pierwszej kolejności spadają na warstwę dostępu

W ciągu ostatnich kilku dni toczyła się dyskusja na temat tego, czy modele open source utkną w obliczu zaostrzającej polityki Stanów Zjednoczonych. Pierwszą rzeczą, która zmienia się w inżynierii, nie są możliwości modelu, ale domyślna dostępność. Model nadal tam jest, podobnie jak papiery. To, co naprawdę drży w pierwszej kolejności, to adres ściągania, źródło lustrzane, platforma hostingowa, warunki licencji i dostępność regionalna. Pierwszą rzeczą, z którą często spotykają się osoby pracujące z dostępem, nie jest „model nie jest wystarczająco mocny”, ale „czy nadal możemy go dzisiaj uzyskać stabilnie?”

Domyślna osiągalność najpierw ulega pogorszeniu

W przeszłości najbardziej irytującym problemem podczas uzyskiwania dostępu do modelu było to, że „wczoraj można było pobrać ten sam model, ale nagle dzisiaj otrzymał komunikat 403”. Tego typu zmiany wyglądają jak niewielkie wahania w łańcuchu dostaw, ale w rzeczywistości powodują niestabilność całego łącza: należy ponowić próbę pobrania wagi, zmienić źródło obrazu, przeliczyć sumę kontrolną, przepakować obraz wdrożenia, a pamięć podręczna w CI również stanie się nieważna. Na pozór kruchy jest jedynie etap tworzenia modelu, ale w rzeczywistości z systemu zostaje odjęte założenie „użyteczności”.

Model open source jest często rozumiany jako „kiedy kod stanie się open source, nie będzie już kontrolowany przez innych”. To zdanie jest poprawne tylko w połowie. Otwarty kod źródłowy nie oznacza, że ​​jest domyślnie dostępny, a bycie widocznym w hurtowni nie oznacza, że ​​można stabilnie uruchomić środowisko produkcyjne. Kto go hostuje, w jakim regionie istnieje, czy licencja się zmieniła i czy istnieją jakieś ograniczenia dotyczące częstotliwości pobierania. Gdy te szczegóły zostaną zablokowane przez platformę, zasady lub warunki biznesowe, zespół widzi nie tyle, że „model znika”, ale „rzeczy, które były łatwo dostępne, zaczynają stać się infrastrukturą, którą należy utrzymać”.

Interfejs modelu zostanie powiększony do granic systemu

W przeszłości, kiedy pisałem wszystkie szczegóły dotyczące routingu modelu, najtrudniejszą rzeczą do zebrania nie było to, że wynik był gorszy o dwa lub trzy punkty, ale to, że interfejs modelu nie był wystarczająco stabilny. Po zastąpieniu bazy nawyki podpowiedzi, struktura wyników, format wywoływania narzędzi i zachowanie długiego kontekstu ulegną odpowiedniej zmianie. Wydaje się, że nazwa modelu się nie zmieniła, ale należy ponownie uruchomić parser, zestaw ewaluacyjny, dziennik powtórek i obsługę błędów w systemie. W tamtym momencie najłatwiej było ujawnić, że system pomylił „pewny model” z „pewną zdolnością”.

Jest to również najczęściej pomijany obszar w dyskusjach związanych z modelami open source. Tym, co jest naprawdę cenne, nie jest sama nazwa, ale zestaw wymiennych możliwości, jakie może zapewnić: uzupełnianie, klasyfikacja, ekstrakcja, dialog, wywoływanie narzędzi, długie podsumowanie artykułu i generowanie kodu. Dopóki warstwa dostępu powiąże te możliwości z konkretnymi modelami, wszelkie późniejsze zmiany będą powiększone o koszty migracji. Z drugiej strony, jeśli najpierw skondensujemy warstwę interfejsu w stabilny kontrakt, bazę można zastąpić niczym zależność, a ryzyko będzie ograniczone tylko w ograniczonym stopniu.

Routing i rezerwa są ważniejsze niż rzeczowniki

Niezależnie od tego, czy model open source zostanie „zapieczętowany”, czy nie, wpływ na końcowy system zwykle nie ma nazwy modelu, ale tego, czy istnieje wyjście. Jeśli zespół umieści wszystkie zadania w jednym zdalnym modelu, wszelkie ograniczenia geograficzne, ograniczenia dostępu lub zmiany w strategiach biznesowych bezpośrednio spowodują przerwę w działalności. Wręcz przeciwnie, dopóki dostępne są modele uruchamialne lokalnie, źródła hostingu kopii zapasowych, pule modeli o różnych poziomach możliwości i zestawy ewaluacyjne, które można odtwarzać, ograniczenia zewnętrzne w najlepszym przypadku zwiększą koszty zmiany i nie spowodują natychmiastowej niedostępności systemu.

Dlatego też dokonując oceny na poziomie modelu, najlepiej nie tylko pytać, „który model jest silniejszy”, ale także pytać, „czy ten łańcuch zdolności można zastąpić bazą?” Czy ciężarki można przechowywać w kontrolowanym magazynie? Czy zależności można zablokować w ustalonych wersjach? Czy routing, buforowanie, odtwarzanie i wycofywanie można przekształcić w kompletny zestaw działań? Pytania te są bliższe rzeczywistej granicy niż nazwie modelu. Ryzyko ograniczenia modelu nie zniknie najpierw, ale najpierw zmieni się domyślna osiągalność; a tym, co system musi utrzymywać, nie jest nigdy model, ale zestaw możliwości, które można stale dostarczać.