Kiedy wystarczy promptowanie

Zanim sięgnie Pan/Pani po fine-tuning, należy traktować prompting jako hipotezę zerową. Współczesne modele frontier mają wystarczające ukryte możliwości, więc większość zadań jest problemem wyszukiwania i wydawania instrukcji, a nie aktualizacji wag.

Najbardziej kosztownym błędem zespołów jest rozpoczęcie trenowania, gdy dobrze ustrukturyzowany prompt, kilka przykładów i dostęp do narzędzi pozwoliłyby zlikwidować lukę bez krańcowego kosztu trenowania. Fine-tuning jest uzasadniony tylko wtedy, gdy prompting dowodnie osiąga limit.

• Prompting zmienia zachowanie dla każdego żądania, a fine-tuning zmienia model
• Prompting można odwrócić w kilka sekund; dostrojony checkpoint jest utrwalonym artefaktem
• Zacznij tanio, zwiększaj zaangażowanie tylko na podstawie dowodów

Porównuj podejścia wzdłuż trzech niezależnych osi kosztów, a nie tylko pod kątem kwot:

• Koszt iteracji - jak szybko można zmienić zachowanie? Prompting: minuty. Fine-tuning: od godzin do dni na cykl.
• Koszt inferencji - prompting ponosi koszt za tokeny długich instrukcji i przykładów przy każdym wywołaniu; dostrojony model może włączyć to zachowanie do wag i skrócić prompt.
• Koszt utrzymania - prompt znajduje się w kontroli wersji i można go audytować; checkpoint trzeba dostrajać ponownie za każdym razem, gdy bazowy model zostaje wycofany.

Prompting wygrywa pod względem kosztu iteracji i utrzymania; fine-tuning może wygrywać pod względem kosztu inferencji przy dużym wolumenie.

Argument za dostrajaniem oparty na koszcie inferencji ma zastosowanie dopiero powyżej progu wolumenu. Należy jawnie zamodelować punkt przejścia: długi prompt few-shot, który dodaje 2000 tokenów wejściowych do każdego wywołania, generuje powtarzalny koszt, podczas gdy dostrojony model rozkłada koszt trenowania na cały wolumen.

Jeśli ruch jest poniżej progu rentowności, prompt few-shot jest bezwzględnie tańszy i bardziej elastyczny.

Najsilniejszym argumentem za promptowaniem jest możliwość wyboru w warunkach niepewności. Wymagania się zmieniają: pojawia się nowy przypadek brzegowy, zmienia się zasada, dochodzi nowe pole wyjściowe. W przypadku promptowania wystarczy zmodyfikować tekst, natomiast w przypadku dostrojonego modelu trzeba ponownie zebrać dane i przeprowadzić trenowanie.

Gdy definicja zadania wciąż się zmienia — na wczesnym etapie produktu, przy niejednoznacznej specyfikacji i częstych zmianach oczekiwań interesariuszy — promptowanie jest niemal zawsze właściwym wyborem. Wagi należy utrwalać dopiero wtedy, gdy cel przestanie się zmieniać.

Wiele problemów, które wydają się wymagać dostrajania, można rozwiązać za pomocą technik stosowanych po stronie promptu:

• Zgodność z formatem — ustrukturyzowane wyjście / ograniczenia schematu JSON, a nie trenowanie
• Styl właściwy dla domeny — blok z przykładem stylu oraz jawny opis sposobu wypowiedzi
• Głębokość rozumowania — dekompozycja, chain-of-thought lub etap planowania
• Luki w wiedzy — retrieval (RAG) dostarcza fakty, a dostrajanie utrwala nieaktualne fakty

Po dostrajanie należy sięgać tylko w przypadku rzeczy, których promptowanie z natury nie potrafi zapewnić: kompresji promptu wymaganej ze względu na opóźnienia, bardzo specyficznych formatów lub zachowania, któremu model opiera się mimo stanowczych instrukcji.

Częste nieporozumienie polega na tym, że zespoły dostrajają model, aby wprowadzić do niego wiedzę, choć powinny ją pobierać. Dostrajanie słabo nadaje się do uczenia faktów — jest stratne, jego aktualizacja jest kosztowna, a ponadto sprzyja halucynowanej interpolacji między przykładami treningowymi.

Heurystyka: jeśli problem dotyczy tego, co model wie, należy użyć retrieval. Jeśli dotyczy tego, jak model się zachowuje, można rozważyć dostrajanie. Wiedza zmienia się codziennie, a zachowanie — rzadko.

Zanim uzna się promptowanie za niewystarczające, należy przejść przez całą drabinę. Większość zespołów rezygnuje na drugim szczeblu:

• Szczebel 1: jasna instrukcja + rola + jawny kontrakt wyjścia
• Szczebel 2: przykłady few-shot obejmujące przypadki brzegowe
• Szczebel 3: dekompozycja na wiele połączonych wywołań
• Szczebel 4: użycie narzędzi / retrieval w celu odciążenia modelu z wiedzy i obliczeń
• Szczebel 5: samokrytyka lub przebiegi weryfikujące

Dopiero po wyczerpaniu szczebli 1–5 na wydzielonym zbiorze ewaluacyjnym dostrajanie staje się uzasadnione.

Długie prompty kosztują więcej niż pieniądze — kosztują czas. W wielu stosach do obsługi modeli tokeny wejściowe mają największy wpływ na czas do pierwszego tokenu. Prompt zawierający łącznie 4000 tokenów instrukcji i przykładów generuje mierzalne opóźnienie przy każdym wywołaniu.

To jedyny obszar, w którym promptowanie rzeczywiście przegrywa przy dużej skali: gdy potrzebne jest jednocześnie zachowanie wynikające z długiego promptu i odpowiedzi w czasie poniżej 100 ms, właściwym rozwiązaniem jest skondensowanie tego zachowania w małym dostrojonym modelu. Należy jednak potwierdzić, że limit opóźnienia jest rzeczywisty, a nie tylko założony.

Decyzję należy podejmować na podstawie całkowitego kosztu posiadania w całym cyklu życia artefaktu, a nie pierwszej faktury. Dostrojony checkpoint wiąże się z ukrytymi kosztami stałymi:

• ponowne dostrajanie po wycofaniu modelu bazowego przez dostawcę — często co 6–12 miesięcy
• potok danych i proces etykietowania, które trzeba stale utrzymywać
• infrastruktura ewaluacyjna wykrywająca regresje po każdym ponownym dostrojeniu
• złożoność wersjonowania, wycofywania zmian i obsługi A/B

Całkowity koszt posiadania promptowania obejmuje głównie plik tekstowy i zbiór ewaluacyjny. W przypadku zespołów bez dojrzałości w zakresie ML Ops sama ta asymetria sprawia, że promptowanie pozostaje korzystniejsze znacznie dłużej, niż można się spodziewać.

Promptowanie wystarcza, gdy na większość z poniższych pytań można odpowiedzieć „TAK”:

• Czy specyfikacja zadania wciąż zmienia się z miesiąca na miesiąc?
• Czy wolumen jest poniżej obliczonego progu rentowności?
• Czy problem dotyczy wiedzy, którą można pobrać, a nie zachowania?
• Czy wydzielony zbiór ewaluacyjny pokazuje, że po przejściu przez drabinę promptowania można osiągnąć akceptowalną jakość?
• Czy limit opóźnienia z zapasem uwzględnia długość promptu?
• Czy zespołowi brakuje utrzymywanego potoku dostrajania i ewaluacji?

Trzy lub więcej odpowiedzi „TAK” oznaczają, że należy pozostać przy promptowaniu i wrócić do tematu dopiero wtedy, gdy odpowiedzi się zmienią.

Decyzję należy zapisać jako dane, a nie opierać na przeczuciach. Niewielka funkcja punktowa zmusza zespół do jawnego określenia założeń — wolumenu, opóźnienia i stabilności specyfikacji — oraz sprawia, że rekomendację można później poddać audytowi.

Zespół chce, aby model odpowiadał na pytania dotyczące dokumentów aktualizowanych codziennie. Jakie podejście jest najbardziej odpowiednie i dlaczego?

Promptowanie jest rozwiązaniem domyślnym, a dostrajanie — kolejnym krokiem. Należy pozostać przy promptowaniu, gdy specyfikacja wciąż się zmienia, wolumen jest poniżej progu rentowności, a problem dotyczy wiedzy, a nie zachowania.

• Porównywać koszty iteracji, inferencji i utrzymania — nie tylko kwoty
• Obliczyć próg rentowności dla danego wolumenu, zanim uzna się, że dostrajanie obniży koszty
• Przejść przez całą drabinę optymalizacji promptu, zanim uzna się promptowanie za niewystarczające
• Pobierać wiedzę, a dostrajanie rezerwować dla uporczywych problemów z zachowaniem lub kompresji promptu wymuszonej opóźnieniem
• Oceniać całkowity koszt posiadania w całym cyklu życia, uwzględniając wycofanie modelu bazowego