Mniejsze, surowsze modele mają rację bytu
Model, który wiedział za dużo
Pierwszym sygnałem ostrzegawczym nie była awaria. Awarie są przynajmniej uczciwe. Sygnałem ostrzegawczym była piękna odpowiedź na złe pytanie. Zespół zbudował wewnętrznego asystenta do wsparcia technicznego. Potrafił czytać podręczniki produktów, historię zgłoszeń, notatki o wydaniach i niewielki pakiet zasad wyjaśniający, co pracownicy mogą obiecywać klientom. Model był duży, płynny i na tyle pewny siebie, że sala konferencyjna wydawała się przez chwilę nowoczesna.
Podczas pilotażu dobrze odpowiadał na szerokie pytania. Streszczał długie zgłoszenia. Przekształcał gniewne wypowiedzi klientów w coś użytecznego. Znajdował ukryte powiązania między objawami a wcześniejszymi poprawkami. Potem pojawiło się rutynowe pytanie o gwarancję. Prawidłowa odpowiedź zależała od trzech wąskich faktów: regionu produktu, kanału zakupu i wersji oprogramowania sprzętowego. Model znalazł prawdopodobny akapit zasad, zignorował cichy wyjątek w notatkach o wydaniu i napisał odpowiedź, która brzmiała, jakby ktoś wyprasował prawdę, aż wyglądała przyzwoicie. Nikt nie prosił o poezję. Potrzebowali ograniczonej decyzji.
Naprawa nie polegała na powiększeniu modelu. Naprawa polegała na uczynieniu części systemu mniejszą i bardziej rygorystyczną. Drobny klasyfikator określał ścieżkę gwarancyjną. Ograniczony ekstraktor pobierał trzy wymagane fakty. Kontrola reguł odrzucała sprawę, jeśli brakowało któregokolwiek faktu. Duży model nadal pomagał pisać końcową czytelną notatkę, ale nie był już właścicielem decyzji. Wynik był mniej efektowny i znacznie lepszy. To częsty wzorzec. Szeroki model robi wrażenie, dopóki praca nie wymaga komponentu, który potrafi dokładnie powiedzieć, co zobaczył, co dokładnie zdecydował i kiedy dokładnie odmawia kontynuowania.
Argument za mniejszymi, bardziej rygorystycznymi modelami zaczyna się tutaj. Nie z nostalgii za starym oprogramowaniem i nie z moralnego sprzeciwu wobec skali. Duże modele są użyteczne. Potrafią poradzić sobie z nieuporządkowanym językiem, tłumaczyć intencje, streszczać dowody i dawać ludziom szybszą drogę do złożonych materiałów. Ale rozmiar kupuje szerokość. Nie kupuje automatycznie kontroli. Poważne systemy potrzebują komponentów, które można ograniczyć, ocenić, wdrożyć, monitorować i wymienić bez zamieniania każdego incydentu w filozoficzne seminarium z logami.
Rygor to cecha, nie nastrój
Rygor brzmi nieprzyjaźnie, bo ludzie mylą go z głupotą. Komponent rygorystyczny to nie taki, który z jakiegoś powodu rozumie mniej. To taki, któremu celowo pozwala się robić mniej. Może przyjmować wyłącznie znany schemat. Może zwracać wyłącznie ustalony zestaw etykiet. Może czytać wyłącznie nazwany pakiet dowodów. Może nie wywoływać żadnych narzędzi. Może być zmuszony do zwrócenia niewystarczających dowodów zamiast improwizowania. Te ograniczenia nie są karą. To one sprawiają, że komponent nadaje się do użytku w systemie, w którym inne części od niego zależą.
Inżynieria oprogramowania nauczyła się tej lekcji na długo zanim AI stała się kategorią zakupową. Typy są rygorystyczne. Ograniczenia baz danych są rygorystyczne. Deterministyczne automaty skończone są rygorystyczne. Kontrola dostępu jest rygorystyczna. System płatności nie prosi modelu o wyrażenie uczuć na temat stanu konta. Reprezentuje pieniądze w dokładnych jednostkach, sprawdza uprawnienia, rejestruje stan i odrzuca niedozwolone przejścia. To właśnie rygor sprawia, że system można audytować i naprawiać. Komunikat o błędzie może się nie podobać, ale zwykle można znaleźć linię, która go spowodowała. To nie jest drobny prezent.
Komponenty AI potrzebują tej samej dyscypliny, bo działają w przepływach pracy, które mają konsekwencje. Klasyfikator, który wybiera między zwrotem pieniędzy, wymianą, eskalacją a odrzuceniem, nie powinien wymyślać piątego stanu zwanego może później, z wyrazami szczerego żalu. Ekstraktor czytający umowę nie powinien umieszczać niejasnej daty w polu terminu tylko dlatego, że tekst brzmiał jak termin. Model wyszukujący nie powinien po cichu przekraczać granicy uprawnień, bo pobliskie dokumenty wyglądały na pomocne. Rygor daje reszcie systemu coś solidnego, czego może się trzymać.
Właściwe pytanie nie brzmi, czy model jest inteligentny w abstrakcji. Właściwe pytanie brzmi, czy model ma właściwy kontrakt do danego zadania. Jakie dane wejściowe może zobaczyć. Jakie dane wyjściowe może wytworzyć. Jaka niepewność musi być ujawniona. Które przypadki muszą być odrzucone. Jakie dowody muszą towarzyszyć wynikowi. Jakie metryki dowodzą, że działa. Mniejszy model z jasnym kontraktem często bije większy model z bohaterskim promptem, bo kontrakt przetrwa kontakt z operacjami.
Rozmiar kupuje szerokość, a szerokość ma rachunek
Duże modele są trenowane, by być ogólne. To ich siła. Potrafią przechodzić między dziedzinami, radzić sobie z nietypowym sformułowaniem, wnioskować z kontekstu i generować płynne odpowiedzi nawet wtedy, gdy dane wejściowe są nierówne. Dlatego w eksploracji wydają się magiczne. Człowiek może zadać pytanie swobodnie i nadal otrzymać coś spójnego. Spójność jest użyteczna. Jest też niebezpieczna, gdy przepływ pracy wymaga wąskiego zobowiązania.
Szerokość ma rachunek. Szeroki model ma więcej sposobów na pomocne błędy. Może importować kontekst z niewłaściwej części rozmowy. Może wygładzać brakujące dowody. Może odpowiadać z wcześniejszej wiedzy, gdy system oczekiwał dowodu opartego na wyszukiwaniu. Może podążać za wzorcem, który wygląda na powszechny, zamiast za wyjątkiem, który ma zastosowanie. Może zbudować prawdopodobny most przez lukę, która powinna była zatrzymać proces. Wynik może brzmieć lepiej właśnie dlatego, że model jest dobry w języku. To wygodne na demonstracjach i niewygodne dla rozliczalności.
Mniejsze modele zmniejszają część tego rachunku, zawężając przestrzeń możliwych zachowań. Klasyfikator dziedzin z dwunastoma etykietami wciąż może zawieść, ale jego błąd jest czytelny. Ograniczony ekstraktor wciąż może pominąć pole, ale brakujące pole można policzyć. Mały model rankingowy wciąż może preferować nieaktualne dowody, ale tę preferencję można przetestować na znanym korpusie. To błędy inżynieryjne, co jest znakomitą wiadomością. Błędy inżynieryjne można mierzyć, budżetować i naprawiać. Mistyczne błędy wymagają większej liczby spotkań.
Istnieje też poznawczy rachunek dla zespołów. Jeden szeroki model rozmywa odpowiedzialność. Kto odpowiada za uzasadnienie gwarancji, sformułowania zgodności, dobór źródeł, ton, odmowy i eskalację, skoro wszystko to żyje w jednym promptcie i jednym punkcie końcowym. Gdy coś się zmienia, który zestaw testów powinien zostać uruchomiony. Gdy użytkownik kwestionuje wynik, który komponent jest winny. Model staje się bardzo utalentowaną szafą, w której złożono każdą instytucjonalną decyzję. W końcu ktoś otwiera drzwi i wypada segregator z politykami.
Mniejsze modele uwidaczniają awarie
Widoczność ma znaczenie, bo każdy system produkcyjny jest w końcu systemem do ustalania, co poszło nie tak. Duży model może zawodzić w sposób trudny do rozdzielenia. Czy prompt był niejednoznaczny. Czy dane do wyszukiwania były nieaktualne. Czy model nadmiernie uogólnił. Czy instrukcja polityki znajdowała się zbyt nisko w kontekście. Czy ustawienia dekodowania zachęcały do różnorodności tam, gdzie liczyła się spójność. Czy wynik narzędzia dotarł za późno. Czy zabezpieczenie przepisało odpowiedź. Każda z tych możliwości może być prawdziwa. Przegląd incydentu staje się historią detektywistyczną z kodem budżetowym.
Mniejsze komponenty rodzą mniejsze pytania. Jeśli ekstraktor pominął kanał zakupu, sprawdź ekstraktor. Jeśli klasyfikator wybrał zwrot zamiast eskalacji, przejrzyj zbiór oznaczony i próg. Jeśli weryfikator nie wychwycił niepopartego twierdzenia, dodaj wzorzec twierdzenia i regułę źródła do ewaluacji weryfikatora. To nie czyni pracy trywialną. To czyni ją lokalną. Lokalność jest dobra. Lokalność oznacza, że promień rażenia można ograniczyć, a poprawkę przetestować bez naruszania całej katedry.
Rygorystyczne wyniki tworzą też lepszą telemetrię. Model, który zwraca jeden z dwunastu stanów, można śledzić w czasie. Model, który zwraca pola strukturalne, może raportować braki, niezgodności, przedziały ufności i dryf. Model, który odmawia, może powiedzieć dlaczego. Odpowiedź prozą może zawierać to wszystko, ale wtedy każdy odbiorca na dalszym etapie musi analizować zdanie napisane przez maszynę nagradzaną za naturalne brzmienie. Tak oto system monitorowania zamienia się w klub książki.
Widoczność awarii zmienia kulturę. Zespoły przestają się spierać, czy AI jest dobra, a zaczynają pytać, który komponent zawiódł i w jakich warunkach. To zdrowszy spór. Może prowadzić do nowego wycinka danych, lepszego progu, mniejszego zbioru dowodów, ściślejszego schematu lub stanu przeglądu ludzkiego. Zamienia lęk w utrzymanie. Utrzymanie jest mniej efektowne niż egzystencjalna debata, ale zwykle trafia na produkcję przed obiadem.
Interfejs to połowa modelu
Gdy ludzie porównują modele, często porównują wagi, parametry, benchmarki i rankingi. To się liczy, ale w produkcji interfejs liczy się tak samo. Interfejs decyduje o tym, jakie obietnice model może składać. Interfejs dowolnego tekstu zachęca do zachowań otwartych. Interfejs strukturalny oczekuje kontrolowanego wyniku. Dekoder ograniczony gramatyką, schemat narzędzia, typowany obiekt wyjściowy czy stały zestaw etykiet mogą zmienić charakter operacyjny tej samej inteligencji.
Rozważmy model czytający faktury. Jeśli zwraca akapit wyjaśniający fakturę, zespół nadal musi wyodrębnić dostawcę, numer NIP, sumy pozycji, walutę, termin płatności i pewność. Jeśli zwraca typowany obiekt z wymaganymi polami, walidacja może działać natychmiast. Jeśli brakuje terminu płatności, obiekt może to zgłosić jako brak. Jeśli sumy się nie zgadzają, weryfikator może odrzucić import. Model może być mniej rozmowny, ale dział księgowości nie płaci mu za charyzmę. Chcą, aby księga przestała się chwiać.
Interfejsy kształtują też trenowanie. Model szkolony do zwracania stałych etykiet można oceniać pod kątem błędów etykiet. Model szkolony do wyodrębniania pól można oceniać pod kątem dokładnego dopasowania, poprawności zakresu, braków i zmyślonych wartości. Model szkolony do tworzenia prozy wymaga więcej osądu, więcej rubryk i więcej przeglądu ludzkiego. To może być właściwe w przypadku niektórych zadań. Jest to marnotrawstwo w przypadku zadań, w których pożądany wynik jest już ustrukturyzowany. Zaskakująco duża część pracy nad AI to zwykłe wprowadzanie danych w aksamitnej marynarce.
Mniejsze, ściślejsze modele skłaniają więc zespoły do myślenia o kształcie pracy. Czy to klasyfikacja, ekstrakcja, ranking, transformacja, weryfikacja, planowanie czy wyjaśnianie. Czy w ogóle potrzebny jest model, czy lepsza będzie reguła, solver, ograniczenie bazy danych lub indeks wyszukiwania. Która część wymaga rozumienia języka, a która pewności. Taki podział nie jest pedanterią. To różnica między projektowaniem systemu a wynajmowaniem ust.
Dane treningowe stają się mniej teatralne
Modele ogólne potrzebują ogromnych, zróżnicowanych zestawów treningowych, ponieważ mają pokrywać ogromne, zróżnicowane zachowania. Wąskie modele często można ulepszyć dzięki mniejszym, lepiej oznaczonym i bardziej trafnym danym. To brzmi mniej spektakularnie, co jest kolejną zaletą. Spektakl nie jest wskaźnikiem jakości. Tysiąc starannie przejrzanych przykładów dla klasyfikatora roszczeń może zrobić więcej dla niezawodności produkcji niż wielkie jezioro danych, do którego zaproszono każdy dokument, a nikt nie sprawdził listy gości.
Mniejsze zadania sprawiają, że znaczenie etykiety jest jaśniejsze. Jeśli etykieta to escalate, recenzenci mogą przedyskutować, które dokładnie warunki uzasadniają eskalację. Jeśli pole to contract end date, recenzenci mogą określić, jak postępować z klauzulami odnowienia, aneksami, brakującymi podpisami i sprzecznymi datami. Jeśli wynik to permission blocked, zespoły ds. bezpieczeństwa i prawne mogą wskazać granicę. To tworzy wiedzę instytucjonalną jako efekt uboczny projektowania modelu. Zespół uczy się, co oznacza proces. To jest niewygodne tylko wtedy, gdy organizacja wolała nie wiedzieć.
Wąskie szkolenie sprawia też, że ocena jest bardziej reprezentatywna. Można budować zestawy testowe wokół rzeczywistych trybów awarii: brakujących pól, nieaktualnych polityk, sformułowań nastawionych na obejście, wyjątków regionalnych, nietypowego formatowania, niskiej pewności oraz przypadków, w których odmowa jest właściwa. Można mierzyć precyzję i kompletność tam, gdzie mają znaczenie. Można zdecydować, że fałszywa akceptacja jest dziesięć razy gorsza niż fałszywa eskalacja. Można dostrajać progi względem kosztów operacyjnych. To konkretne wybory. Nie są efektowne, ale mają rzadką właściwość bycia użytecznymi.
Wciąż jest miejsce na szerokie pretrenowanie i transfer. Mały, rygorystyczny model może działać na osadzeniach z większego modelu. Ograniczony model językowy może korzystać z ogólnej wiedzy językowej, jednocześnie generując ustalony schemat. Model ogólny może tworzyć kandydatów, których sprawdza rygorystyczny weryfikator. Argument nie dotyczy czystości. Argument dotyczy umiejscowienia. Używaj szerokich możliwości tam, gdzie potrzebna jest szerokość. Używaj rygorystyczności tam, gdzie system potrzebuje zobowiązania.
Ekonomia jest cichsza i lepsza
Koszt to nie tylko faktura za wnioskowanie. Koszt to opóźnienie, pamięć, energia, złożoność operacyjna, nakład na ocenę, ciężar przeglądu, reagowanie na incydenty oraz liczba inżynierów potrzebnych do wyjaśnienia, dlaczego wtorek zachowywał się inaczej niż poniedziałek. Mniejsze modele mogą pomóc na wszystkich tych wymiarach. Mogą działać bliżej danych. Mogą mieścić się na zwykłym sprzęcie. Mogą być buforowane, kwantyzowane, przetwarzane wsadowo lub osadzone w usłudze bez zamieniania wdrożenia w ceremonię z trzema kalendarzami i rezerwacją mocy obliczeniowej.
Opóźnienie zmienia zachowanie produktu. Jeśli klasyfikator zwraca wynik w milisekundach, może działać wewnątrz przepływu pracy bez zmuszania użytkownika do wpatrywania się w spinner i rozważania wyborów zawodowych. Jeśli ekstraktor działa lokalnie, wrażliwy materiał nie musi podróżować do zdalnej usługi, aby wyciągnąć proste pole. Jeśli weryfikator jest tani, może działać na każdym wyniku, a nie na próbkach. Te szczegóły nie są drobne. Decydują o tym, czy mechanizmy bezpieczeństwa i kontroli jakości są faktycznie używane, czy tylko podziwiane na diagramach architektury.
Operacyjnie mniejsze modele łatwiej zastąpić. Zespół może wytrenować nowy ekstraktor, uruchomić go obok starego, porównać rozbieżności i wdrożyć go fragmentami. Może zachować poprzednią wersję do odtworzenia. Może przypisać wersję modelu i próg do każdej decyzji. Ogromny, uniwersalny punkt końcowy też można wersjonować, ale porównanie często staje się bardziej mętne, ponieważ wiele zachowań zmienia się naraz. Duże zestawy zmian to miejsce, w którym pewność zamienia się w gradient w prezentacji PowerPoint.
Jest też przewaga w zakresie zakupów. Mniejsze, rygorystyczne komponenty sprawiają, że zmiana dostawcy jest bardziej realistyczna. Jeśli kontrakt to znany schemat i znany zestaw testów ewaluacyjnych, zespół może porównać implementacje. Jeśli kontrakt to ogromny prompt pełen ukrytej polityki i osobowości, zmiana staje się ryzykowna. Organizacja może odkryć, że jej przepływ pracy nie jest napędzany przez model, ale z nim splątany. Splątanie jest romantyczne w powieściach. W produkcji to plan migracji z zębami.
Gdzie duże modele wciąż mają swoje miejsce
To nie znaczy, że duże modele należy zamykać w naukowej szufladzie. Świetnie radzą sobie z wieloma rzeczami. Są przydatne do eksploracji, szkicowania, streszczania, tłumaczenia, niejednoznacznych danych od użytkownika, wspomagania pisania kodu oraz zadań, w których pożądany wynik jest naprawdę otwarty. Mogą pomagać ludziom w zrozumieniu nieznanego materiału. Mogą generować proponowane wyjaśnienia. Mogą przekształcać chaotyczny język naturalny w bardziej uporządkowane żądanie. Mogą być hojnymi drzwiami wejściowymi do bardziej rygorystycznego zaplecza.
Błędem jest pozwolić, by drzwi wejściowe stały się całym budynkiem. Duży model może interpretować intencje, ale mniejszy klasyfikator może wybierać przebieg pracy. Duży model może szkicować odpowiedź, ale weryfikator może sprawdzać twierdzenia. Duży model może streszczać dokument, ale ekstraktor może wypełniać pola podlegające regulacjom. Duży model może proponować plan, ale brama polityk może decydować, które kroki są dozwolone. Szeroki model pozostaje cenny. Po prostu przestaje udawać, że jest źródłem wszelkiej władzy.
Taki podział jest też łaskawszy dla użytkowników. Ludzie nie chcą negocjować z modelem, czy istnieje status zwrotu. Chcą jasnych wyników, jasnych dowodów i ścieżki odwołania. System złożony ze ścisłych komponentów może wyjaśnić się w kategoriach operacyjnych: wykorzystano to źródło, brakowało tego pola, osiągnięto ten próg, ta polityka wymagała przeglądu. Takie wyjaśnienie może być mniej urocze niż akapit płynnej empatii, ale jest bardziej użyteczne, gdy w grę wchodzą pieniądze, prawa, bezpieczeństwo lub zaufanie.
Przyszłość to prawdopodobnie nie jeden model rządzący całym przebiegiem pracy. To kompozycja modeli, reguł, solverów, indeksów, weryfikatorów i przeglądu ludzkiego. Niektóre części będą duże i elastyczne. Niektóre będą maleńkie i uparte. Sztuka polega na tym, by wiedzieć, która jest która. Dobry inżynier powinien być podejrzliwy wobec każdej architektury, w której każdy problem rozwiązuje się przez powiększanie tego samego komponentu. To nie jest projektowanie. To jest inflacja.
The case
The case for smaller, stricter models is not that small is morally superior. It is that many valuable tasks are smaller than our current model vocabulary admits. Classify this case. Extract these fields. Rank these sources. Verify this claim. Refuse without evidence. Route to a human. Preserve a reason. These are not lesser forms of intelligence. They are the forms that make larger systems dependable.
Gdy zespoły zaczynają od największego dostępnego modelu, często odkładają trudne pytania projektowe na później. Jaka jest przestrzeń stanów. Które wyniki są dozwolone. Jakie dowody są wymagane. Co oznacza niepewność. Kto ponosi odpowiedzialność za błąd. Jak testowany jest komponent. Kiedy musi odmówić. Gdy te pytania są ignorowane, model przejmuje je jako ukrytą politykę. Ukryta polityka może działać w pilotażu. Źle się starzeje w produkcji, zwykle w momencie, gdy ktoś prosi o ślad audytowy.
Zaczynanie od mniejszego modelu wymusza zadawanie tych pytań wcześniej. Pyta, czy problem ma znany kształt. Pyta, czy ścisły interfejs może przenieść wynik. Pyta, czy model potrzebuje szerokich zdolności językowych, czy wąskiego osądu. Pyta, co należy zmierzyć, zanim udzieli się zaufania. Ta dyscyplina nie ogranicza ambicji. Daje ambicji szkielet. Bez niego system może się poruszać, ale nikt nie powinien stać zbyt blisko.
Mniejsze i ściślejsze modele są łatwiejsze do utrzymania. Są tańsze w eksploatacji, łatwiejsze do oceny, jaśniejsze w debugowaniu, bezpieczniejsze w komponowaniu i bardziej uczciwe w kwestii swoich ograniczeń. Nie zastępują szerokich modeli wszędzie. Sprawiają, że szerokie modele są użyteczne tam, gdzie użyteczność oznacza coś więcej niż płynność. W poważnej inżynierii AI to właśnie ta różnica ma znaczenie. Najlepszy system to rzadko ten z największym modelem na każdym etapie. To ten, w którym na każdym etapie znajduje się najmniejszy komponent zdolny do wykonania zadania, najściślejszy kontrakt, który wciąż pasuje do rzeczywistości, i wystarczająca ilość pozostawionych dowodów, aby następny człowiek zrozumiał, co się wydarzyło.