Back home

Prawdziwym przełomem w chińskim modelu open source jest sieć współpracy

Można zastosować wagę, a aktualizacje, przeglądy i konsensus będą bardziej kruche.

Mówiąc o tym, „czy zostanie on zapieczętowany” w modelu open source, najłatwiej jest spojrzeć na plik wagi jako na wszystko.

Po pobraniu ciężarów sam model często nie znika tak łatwo. Najpierw łatwiej jest złamać sieć, która się wokół niej obraca: witryny lustrzane, zestawy ewaluacyjne, szablony wnioskowania, skrypty dostrajające, poprawki problemów, domyślne parametry wdrażania i konsensus wśród społeczności, że „ta wersja może działać i tej wersji nie należy dotykać”.

Część, która może uderzyć o ziemię, najmniej boi się pęknięcia.

Dopóki model open source trafi do lokalnego magazynu, magazynu obiektów lub obrazu intranetowego, niezależnie od tego, jak ciasny jest świat zewnętrzny, plik zazwyczaj nadal tam będzie. Kopie offline, wewnętrzne pamięci podręczne i historyczne produkty kompilacji na długi czas opóźnią kwestię „czy nadal można z niej korzystać”.

To także największa różnica pomiędzy modelem open source a usługami czysto chmurowymi. Po zablokowaniu usługi w chmurze często nie ma już dostępu; nawet jeśli usługa nadrzędna modelu open source zostanie zatrzymana, wagi, tokenizator i obraz wnioskowania mogą nadal działać. Pytanie nie brzmi: „czy to masz?” ale „czy możesz nadal używać go w taki sam sposób jak inne?”

To, co naprawdę rzuca się w oczy, to relacja synchronizacji

To, że model może nadal działać, nie oznacza, że zespół może w dalszym ciągu za nim nadążać.

Pierwszą rzeczą, którą należy poluzować, są zazwyczaj relacje synchronizacji:

  • Upstream wypuścił nową wersję, ale wewnętrzne lustro nie nadążało za czasem.
  • Zestaw ocen został zmieniony, a wyników regresji nie można już dostosowywać do starych rekordów.
  • Szablon czatu lub tokenizer został nieco przeniesiony, ale styl wyjściowy znacznie się zmienił.
  • Pewna poprawka wpłynęła tylko na PR społeczności, a nie na wizerunek korporacyjnego intranetu
  • Domyślna kwantyzacja, domyślna długość kontekstu i domyślne parametry próbkowania są rozbieżne.

Te rzeczy same w sobie nie wyglądają na duże, ale ułożenie ich razem spowoduje podział „tego samego modelu” na kilka części.

Na tym etapie prawdziwą szkodą wyrządzoną przez zewnętrzne ograniczenia nie jest wymazanie ze świata ważkiego dokumentu, ale przełamanie faktu, że „wszyscy patrzą na to samo”. Zespół wciąż mówi o tej samej nazwie modelu, ale tak naprawdę otrzymuje pakiet kombinacji z różnymi wersjami, różnymi szablonami i różnymi parametrami.

Recenzje, poprawki i doświadczenia zostaną zebrane razem

Gdy model open source wejdzie do rzeczywistego przepływu pracy, prawdziwą wartością zwykle nie jest sama waga, ale ocena zgromadzona wokół wagi.

Która wersja jest stabilniejsza, który tokenizer złamie długi tekst, który zestaw parametrów próbkowania jest bardziej odpowiedni dla scenariuszy obsługi klienta, który skrypt dostrajający zwiększy iluzję, wszystkie te doświadczenia opierają się na ciągłej wymianie. Dopóki istnieje sieć współpracy, każdy może nadal majsterkować wokół tego samego punktu odniesienia; po zerwaniu sieci współpracy każdy zespół będzie powoli opracowywał własną, prywatną wersję.

Wersje prywatne nie są złe, ale cena rośnie:

  • Powrót do stanu wyjściowego staje się coraz trudniejszy do ponownego wykorzystania
  • Przegląd wypadków staje się coraz trudniejszy do dostosowania
  • Napraw łatkę, która staje się coraz trudniejsza do synchronizacji
  • Ten sam problem będzie pojawiał się wielokrotnie w różnych zespołach

W tej chwili wygląda na to, że „model nadal tam jest”, ale w rzeczywistości powstało „wiele lokalnych kopii, które są ledwo przydatne” i nie ma między nimi wspólnej ścieżki aktualizacji.

To, czym naprawdę warto się martwić, to nie blokowanie, ale rozwidlenie

Model open source trudno jest całkowicie zapieczętować jak internetowe API, ponieważ istnieje możliwość jego powielania. Tak naprawdę powinniśmy zachować ostrożność, ponieważ gdy presja zewnętrzna zrywa dystrybucję, naprawy i współpracę, model zaczyna się różnić w zależności od rytmu pracy różnych organizacji.

Gdy pojawi się więcej widelców, nie będzie już kwestią „czy można je pobrać?” ale „kto może zagwarantować, że jest to nadal ten sam rodzaj rzeczy?” Ta kwestia bezpośrednio zwiększy koszt dostępu: trzeba będzie powtórzyć nowe recenzje, ponownie wyjaśnić stare błędy, zmienić położenie różnic w wersjach, a zespół musi opracować własne strategie wycofywania i zamrażania dla każdej rozwidlonej linii.

Odporność modelu open source jest rzeczywiście większa niż w przypadku usług czysto chmurowych; ale jego wrażliwość jest również bardzo wyraźna, nie chodzi tu o to, czy odjęto od tego ciężar, ale czy sieć współpracy może nadal zachowywać tę samą nazwę i to samo.