Jeden dobry przykład mówi modelowi więcej niż akapit instrukcji.
Pięć złych — zjada budżet i uczy nie tego.
Z pięciu warstw okna została nam ostatnia: przykłady. Few-shot, czyli pokazanie modelowi kilku wzorców „o, takiej odpowiedzi oczekuję” zamiast opisywania jej słowami. To jedna z najskuteczniejszych dźwigni jakości — i jedna z najłatwiejszych do przesadzenia, bo każdy przykład to tokeny, które rywalizują z resztą okna.
Mechanikę few-shot w połączeniu z chain-of-thought rozkłada artykuł serii o tym, jak agent myśli. Po samą głębię promptowania — powtarzalność, namiastkę determinizmu, dobór przykładów jako osobne rzemiosło — prowadzimy działający PoC na promptujemy.pl. Tu patrzymy z jednej, węższej strony: jak sprawić, żeby przykłady zarobiły na miejsce, które zajmują w oknie.
Dlaczego przykłady działają lepiej niż instrukcje
Możesz modelowi opisać format odpowiedzi: „odpowiadaj zwięźle, rzeczowym tonem, zaczynaj od konkluzji, bez wstępów”. Albo możesz pokazać mu jedną odpowiedź, która taka jest. To drugie zwykle działa lepiej — bo wzorzec niesie informacje, których instrukcja nie umie ująć: rytm, długość, ton, sposób układania myśli.
Instrukcja mówi, co ma być. Przykład pokazuje, jak to wygląda. Przy formacie, stylu i strukturze — czyli tam, gdzie „jak” jest trudne do opisania słowami — przykład wygrywa.
I właśnie dlatego few-shot jest tak kuszący do nadużycia. Skoro jeden przykład pomaga, to pięć pomoże bardziej, prawda? Nie. Tu wracamy do budżetu okna.
Jakość bije ilość — zawsze
Każdy przykład to tokeny, które zajmują miejsce kosztem innych warstw: pamięci, retrievalu, samego zadania. Więc pytanie nie brzmi „ile przykładów mogę wcisnąć”, tylko „które przykłady realnie zmieniają wynik”.
Trzy zasady doboru, które robią różnicę.
Reprezentatywne, nie losowe. Przykład ma pokazać wzorzec, który chcesz powielić. Trzy warianty tego samego prostego przypadku uczą mniej niż jeden przypadek prosty plus jeden brzegowy. Pokrywaj różne sytuacje, nie tę samą trzy razy.
Trudny przypadek, nie łatwy. Model i tak poradzi sobie z oczywistym. Wartość przykładu jest największa tam, gdzie łatwo o błąd — pokaż mu ten przypadek, w którym zwykle się myli, z poprawnym rozwiązaniem. Łatwy przykład zajmuje budżet i niczego nie uczy.
Spójne w formacie. Jeśli Twoje przykłady różnią się między sobą strukturą czy tonem, uczysz model niespójności. Wszystkie powinny wyglądać dokładnie tak, jak ma wyglądać docelowa odpowiedź. Przykład jest wzorcem — a wzorzec ma być jeden.
Ile ich dać
Reguła praktyczna: zacznij od jednego, najwyżej dwóch. Dodawaj kolejny tylko wtedy, gdy widzisz, że realnie poprawia wynik — nie „na wszelki wypadek”.
Przy few-shot bardzo szybko wchodzą malejące przychody: drugi przykład pomaga mniej niż pierwszy, trzeci mniej niż drugi, a od pewnego momentu kolejne już tylko jedzą budżet i podsuwają context rot. Punkt, w którym to się dzieje, zależy od zadania — dlatego dobór liczby przykładów to coś, co się mierzy, a nie zgaduje. I to jest dokładnie ten rodzaj eksperymentu, który prowadzimy na promptujemy.pl: ile przykładów, jakich, i jak to wpływa na powtarzalność wyniku.
Few-shot dynamiczny — przykłady też można pobierać
Tu spina się wątek z wpisu o retrievalu. Nie musisz mieć jednego, sztywnego zestawu przykładów na wszystko. Możesz trzymać bibliotekę przykładów poza oknem i przy każdym zadaniu pobierać te kilka, które są najbliższe bieżącemu przypadkowi.
To few-shot just-in-time: zamiast „te same trzy przykłady zawsze” — „trzy przykłady najbardziej podobne do tego, co agent robi teraz”. Dla agenta operującego w zróżnicowanej domenie to często skok jakości większy niż dorzucenie kolejnego stałego przykładu. Bo trafność przykładu liczy się bardziej niż ich liczba — a najtrafniejszy jest ten najbliższy bieżącemu zadaniu.
Pułapka: nieświeży albo sprzeczny przykład
Dwa sposoby, w jakie few-shot psuje wynik zamiast go poprawiać.
Przykład nieaktualny. Jeśli wzorzec pokazuje format, którego już nie używasz, albo dane, które się zmieniły — uczysz model wczorajszego stanu. Przykłady wymagają przeglądu tak samo jak reszta kontekstu.
Przykład sprzeczny z instrukcją. Jeśli w system prompcie piszesz „nigdy nie podawaj cen”, a w przykładzie pokazujesz odpowiedź z ceną — model dostaje dwa sprzeczne sygnały i pójdzie raczej za przykładem niż za instrukcją, bo wzorzec jest konkretniejszy niż reguła. Przykłady muszą zgadzać się z resztą okna, nie walczyć z nią.
Krótko dla twórców treści
Few-shot to nie jest temat tylko dla budujących agentów. Jeśli generujesz treści — opisy produktów, alty, warianty nagłówków — to dwa-trzy wzorcowe przykłady robią więcej dla spójności niż akapit wytycznych o „tonie marki”. Pokaż modelowi dwa opisy napisane dokładnie tak, jak chcesz — reprezentatywne, w docelowym formacie, spójne ze sobą — a dostaniesz powtarzalny styl zamiast loterii. Reguła jest ta sama co dla agenta: lepiej dwa trafne przykłady niż pięć przypadkowych.
Jak to wygląda w n8n
W prostym przepływie few-shot to po prostu kilka par „wejście → oczekiwane wyjście” w prompcie węzła z modelem. Działa, dopóki jeden zestaw przykładów pasuje do wszystkich przypadków.
Krok dalej to few-shot dynamiczny: osobny węzeł, który na podstawie bieżącego wejścia wybiera z biblioteki te przykłady, które najlepiej pasują, i dopiero one trafiają do promptu. Więcej konstrukcji, ale przykłady są zawsze trafne dla tego, co przepływ akurat przetwarza — i nie nosisz w oknie pięciu wzorców, z których cztery są nie na temat.
Co z tego wynika
Few-shot to najgęstsza informacyjnie warstwa okna — jeden dobry przykład potrafi zastąpić akapit instrukcji. Ale właśnie dlatego płaci się go budżetem, i właśnie dlatego liczy się dobór, nie liczba. Trafny, trudny, spójny przykład zarabia na swoje miejsce. Przypadkowy, łatwy, sprzeczny — tylko je zajmuje.
Zasada do zabrania: nie pytaj, ile przykładów zmieścisz — pytaj, które realnie zmieniają wynik. A skoro warstwy okna mamy już obrobione od strony „co i ile”, zostaje pytanie o formę: jak to, co wraca do okna z narzędzi, ma wyglądać, żeby model w ogóle umiał z tego skorzystać. O tym ostatni wpis bazowy tej kategorii — formatowanie wyników narzędzi i structured output.
Pojęcia ze słownika: Few-shot · Zero-shot · Prompt template · Okno kontekstu · Just-in-time retrieval · Budżet tokenów
