Po ograniczeniu modelu open source pierwszą rzeczą, która musi być niezależna, jest warstwa neutralna modelu.

Kiedy model open source zaczyna być ograniczany, pierwszą ujawnianą rzeczą często nie jest wpis dotyczący pobierania, ale domyślne założenia w kodzie. Nazwa modelu została zmieniona, ale interfejs nadal istnieje, ale proces biznesowy nie jest już zsynchronizowany ze starym zachowaniem: format wyjściowy, sekwencja wywołań funkcji, dźwięk odrzucenia, długość kontekstu, parametry próbkowania. Każdy z nich można oglądać osobno, ale ułożenie ich razem spowoduje przeciągnięcie całego łącza.

Tego rodzaju problem zwykle trudno uznać za problem architektoniczny. Na etapie programowania widziałem tylko „można uruchomić”. Po wejściu do Internetu odkryłem, że wybór modelu został już zapisany w logice biznesowej. Niektóre pola dostosowują się tylko do jednego formatu zwracanego, niektóre ponowne próby rozpoznają tylko jedną metodę odrzucenia, a w przypadku niektórych wyjątków funkcja zastępcza domyślnie przywraca oryginalny model, aby podać dłuższe wyjaśnienie. Po nałożeniu ograniczeń wszystkie te ukryte stosy zostały odsłonięte.

Domyślne zachowanie powiąże model z firmą

Na etapie dostępu model jest często uważany za dodanie pakietu SDK, połączenie interfejsu API i dodanie słowa podpowiedzi. Po połączeniu najtrudniejszą rzeczą do oczyszczenia nie jest samo połączenie, ale gałęzie, które wyrosły wokół domyślnego zachowania. Określa, czy dane wyjściowe powinny być w formacie ściśle JSON, czy należy ponowić próbę wywołania narzędzia po niepowodzeniu, gdzie obciąć zbyt długie dane wejściowe i w której warstwie umieścić monity kontroli ryzyka. Kwestie te często mieszczą się w kodeksie biznesowym.

Gdy model open source zostanie ograniczony lub usunięty z półek albo obraz lokalny i wersja źródłowa zaczną się rozdzielać, te domyślne zachowania przestaną być niezawodne. Na pozór jest to po prostu zmiana modelu, ale pod spodem konieczna jest jednoczesna zmiana parsowania, monitorowania, wycofywania i testowania. Najtrudniejsze jest nie napisanie jeszcze kilku linijek adaptacji, ale to, że pierwotny zestaw założeń nie jest wyraźnie zaznaczony od początku do końca.

Rolą warstwy neutralnej jest rozpowszechnianie ukrytych założeń

Warstwy neutralne pod względem modelu nie są abstrakcyjne dla samej abstrakcji. Jego funkcja jest bardzo prosta: umieszcza słowa podpowiedzi, weryfikację schematu, routing, ponowną próbę, obniżenie wersji, dzienniki i ocenę w jednym miejscu, tak aby różnice w modelach najpierw przeszły przez ten sam zestaw granic. W ten sposób, nawet jeśli model zostanie zastąpiony chmurą, oprogramowaniem open source, wnioskowaniem lokalnym lub innymi dostawcami, firma nadal będzie widzieć ujednoliconą umowę dotyczącą danych wejściowych i wyjściowych.

Gdy ta warstwa się utworzy, wiele rzeczy, które początkowo były niejasne, nagle stanie się jasne. Które pola są wartościami wymaganymi, które pola są jedynie preferencjami modelu, które błędy można ponowić, które błędy należy wycofać, które konteksty zostaną obcięte, a które wskaźniki naprawdę można porównać – wszystko to zmieni się z „zapamiętanych z doświadczenia” na „ograniczone przez interfejsy”. Oddziaływanie, jakie powoduje ograniczony model, nie jest już wpisane bezpośrednio w kod biznesowy, ale najpierw w warstwę neutralną.

Nie wszystkie sceny zasługują na tę warstwę

Niektóre sceny wcale nie wymagają tak grubych warstw. Jednorazowe podsumowania, tymczasowa generacja, wewnętrzne eksperymenty i całkowicie jednomodelowe zablokowane łańcuchy narzędzi, wystarczy podłączyć model w tych miejscach. Zbudowanie kompletnej neutralnej warstwy dla krótkotrwałego procesu spowoduje jedynie przekroczenie kosztów z góry.

Ta warstwa jest potrzebna, gdy model naprawdę będzie brał udział w ocenie biznesowej. Takie jak wyodrębnianie, wyznaczanie trasy, wykonanie narzędzia, reakcja obsługi klienta, pomoc w przeglądaniu i przepisywanie partii. W tych scenariuszach model nie jest zabawką, ale częścią procesu. Dopóki model może się zmienić lub zewnętrzne ograniczenia mogą zdestabilizować dane wejście, warstwa neutralna nie jest dekoracją, ale ścianą, która utrzymuje zmianę w granicach.

Tym, co tak naprawdę wymusza ograniczenie modelu open source, nie jest alternatywa konkretnego dostawcy, ale to, czy zespół traktuje „różnice modelowe” jak obywateli pierwszej kategorii. Im wcześniej domyślne zachowanie w kodzie zostanie rozłożone, tym mniej pasywne będzie przy późniejszej zmianie modeli. Model może się zmieniać, ale granice nie mogą być przestrzegane.