Praktyczny standard budżetowania tokenów w systemach LLM: stałe rezerwy, warstwy kontekstu, degradacja kontrolowana oraz instrumentacja. Bez zgadywania, bez przypadkowych przycięć.
Czas czytania: ~12 minAktualizacja: 2026-01-09
W skrócie
tokeny jako budżet jakości i kosztu
warstwy kontekstu i rezerwy
degradacja kontrolowana + telemetryka
Dlaczego tokeny są jednostką budżetu
W praktyce inżynierii promptów i kontekstu „limit” nie jest ograniczeniem znaków, lecz tokenów.
Token to jednostka, którą model rzeczywiście przetwarza. Dwie konsekwencje są kluczowe:
Koszt i latencja rosną w przybliżeniu wraz z liczbą tokenów wejścia i wyjścia.
Jakość często spada, gdy kontekst jest przeładowany (spada sygnał, rośnie szum, a model zaczyna „zgadywać”).
Zasada tradycyjna, ale skuteczna: najpierw budżet, potem „upiększanie”.
Jeżeli kontekst nie ma rezerwy na wynik i polityki, system będzie niestabilny.
Podział budżetu kontekstu: elementy stałe (policy/task/output) i elastyczne (RAG/historia/narzędzia).
Składniki kontekstu
W Luage sensownie jest myśleć o kontekście jako o pakiecie, który składa się z warstw:
Policy
Reguły, zakazy, format. Powinny być krótkie, stabilne i wersjonowane.
Task
Cel bieżącego zapytania + kryteria sukcesu.
Knowledge
RAG: dokumenty, fragmenty, cytowania. Limitowane i filtrowane.
Historia / pamięć
Tylko to, co realnie potrzebne. Reszta: streszczenie.
Reguły budżetowania
Kluczem jest utrzymanie stałych rezerw. Praktyczny wzorzec:
context_window = N
reserve_output = 0.10 * N # nigdy nie schodzić poniżej
reserve_policy = fixed # stały koszt
reserve_task = small_fixed # stały koszt
budget_flexible = N - (reserve_output + reserve_policy + reserve_task)
# flexible dzielimy:
budget_rag = min(max_rag, 0.45 * budget_flexible)
budget_history = budget_flexible - budget_rag
Rezerwa na wynik: jeżeli model nie ma miejsca na poprawną odpowiedź, zacznie skracać, urywać lub tracić strukturę.
Policy nie jest „opcją”: to element sterujący; przycinanie policy jest jak wyjmowanie bezpiecznika.
RAG limituj: lepiej 6–10 dobrych fragmentów niż 40 przeciętnych.
Streszczanie i kompresja
Gdy historia rozmowy rośnie, standardowa praktyka to utrzymywanie:
krótkiej historii (np. ostatnie 3–6 tur),
streszczenia (z provenance: co pochodzi od użytkownika, co jest wnioskiem systemu),
stanu (klucz‑wartość), który jest deterministyczny i łatwy do walidacji.
Degradacja kontrolowana
W systemach produkcyjnych nie da się uniknąć „ciśnienia” na kontekst.
Różnica między rozwiązaniem dojrzałym a amatorskim polega na tym, że degradacja jest jawna i logowana.
Minimalny zestaw kroków degradacji (w kolejności): (1) redukcja historii → (2) redukcja RAG → (3) skrócenie wyniku → (4) eskalacja / no‑answer.
Instrumentacja i testy
Budżet jest użyteczny tylko wtedy, gdy jest mierzony. Zalecane pola telemetryczne:
input_tokens, output_tokens, context_window
policy_version, context_packet_hash, retrieval_k
degradation_step (0..n)
Checklist
Ustal rezerwę na wynik i nie naruszaj jej bez decyzji architektonicznej.
Policy i Task traktuj jako koszt stały (krótkie, wersjonowane).
