Cache i pamięć w agentach: 7 strategii, które obniżają koszty tokenów bez spadku jakości

1. Dlaczego cache i pamięć w agentach LLM są kluczowe: koszty tokenów, latencja i jakość

Agenci oparci o LLM rzadko działają jak „jedno zapytanie – jedna odpowiedź”. Zwykle wykonują iteracje: planują, wywołują narzędzia, pobierają kontekst, doprecyzowują i dopiero finalizują wynik. Każdy taki krok zwiększa liczbę przesyłanych tokenów, wydłuża czas odpowiedzi i podnosi ryzyko spadku jakości. Dlatego cache i pamięć stają się fundamentem skalowania agentów w produkcji: redukują nadmiarowe obliczenia, stabilizują zachowanie i pozwalają utrzymać jakość przy ograniczonym budżecie tokenów.

W praktyce „koszty” w agentach mają trzy główne wymiary, które są ze sobą silnie powiązane:

• Koszt tokenów – płacisz za wejście (prompt + kontekst + wyniki narzędzi) i wyjście (odpowiedź modelu). W agentach to często koszt wielokrotny, bo ten sam kontekst lub wyniki mogą być wielokrotnie dołączane i przetwarzane.
• Latencja – czas odpowiedzi rośnie wraz z liczbą kroków, długością kontekstu oraz liczbą zewnętrznych wywołań (bazy danych, API, wyszukiwarki). Nawet jeśli LLM jest szybki, łańcuch zależności może uczynić system „ociężałym”.
• Jakość – paradoksalnie, „więcej kontekstu” nie zawsze pomaga. Przeładowany prompt zwiększa szum, utrudnia modelowi selekcję istotnych informacji i może obniżać trafność, spójność oraz odporność na halucynacje.

Cache i pamięć rozwiązują te problemy na różnych poziomach. Cache jest zwykle mechanizmem „tu i teraz”: przechowuje rezultaty, które da się bezpiecznie wykorzystać ponownie, aby nie płacić drugi raz za to samo. Pamięć natomiast dotyczy tego, co agent powinien utrwalić z przebiegu interakcji lub pracy, by w przyszłości działać lepiej i krócej, bez niepotrzebnego powtarzania pytań czy rekonstrukcji kontekstu.

Kluczowe różnice w zastosowaniach:

• Cache: nastawiony na przyspieszenie i oszczędność poprzez ponowne użycie wyników (np. odpowiedzi lub rezultatów pośrednich). Najczęściej działa w horyzoncie minut–godzin, a jego skuteczność mierzy się m.in. trafieniami (hit-rate) i ryzykiem użycia nieaktualnych danych.
• Pamięć: nastawiona na ciągłość i personalizację (np. preferencje użytkownika, ustalenia, kontekst projektu), ale też na ograniczanie „rozrostu” rozmowy poprzez selektywne utrwalanie tego, co naprawdę potrzebne. Może obejmować zarówno krótką perspektywę (bieżące zadanie), jak i długą (wiele sesji), przy czym wymaga ostrożności w zakresie prywatności i kontroli dostępu.

Dlaczego to bezpośrednio wpływa na jakość? Ponieważ dobrze zaprojektowane mechanizmy cache i pamięci pomagają agentowi zachować spójność (powtarzalne decyzje i odpowiedzi w podobnych sytuacjach), trafność (mniej przypadkowego kontekstu) oraz kontrolę nad budżetem (mniej tokenów na „odtwarzanie” tego, co już było). Jednocześnie źle zaprojektowane mogą zaszkodzić: cache może utrwalać przestarzałe wyniki, a pamięć może przechowywać nieprawdziwe lub wrażliwe informacje.

W ujęciu systemowym cache i pamięć są więc narzędziami do osiągnięcia trzech celów jednocześnie:

• Obniżenie kosztów przez eliminację powtórnych obliczeń i ograniczenie rozmiaru promptu.
• Skrócenie latencji przez ograniczenie liczby kroków i zewnętrznych wywołań.
• Utrzymanie lub podniesienie jakości dzięki lepszej selekcji informacji, spójności odpowiedzi i mniejszemu „szumowi” w kontekście.

Najważniejsze jest podejście pragmatyczne: nie „maksymalnie dużo pamięci” ani „cache wszystkiego”, tylko świadome decyzje, co można bezpiecznie reutilizować, jak długo, oraz co agent powinien pamiętać, by pracować krócej i pewniej, bez pogorszenia odpowiedzi.

Strategia 1: Cache odpowiedzi (response caching) – klucze, TTL, hit-rate i ryzyko „stale data”

Cache odpowiedzi polega na zapisywaniu gotowego wyniku z modelu (treści odpowiedzi oraz ewentualnie metadanych) i ponownym użyciu go, gdy pojawia się to samo zapytanie w tym samym kontekście. To najszybszy sposób na obniżenie kosztów tokenów i latencji, bo w przypadku trafienia w cache omijasz całe wywołanie LLM.

Najlepiej sprawdza się w scenariuszach, gdzie pytania są powtarzalne, a odpowiedź ma być stabilna: FAQ, opisy funkcji, standardowe komunikaty w aplikacji, regułki onboardingowe, odpowiedzi na proste intencje w obsłudze klienta. Najgorzej działa, gdy odpowiedź zależy od szybko zmieniających się danych lub od silnie spersonalizowanego kontekstu.

Z doświadczenia szkoleniowego Cognity wiemy, że ten temat budzi duże zainteresowanie – również wśród osób zaawansowanych.

Klucz cache: co musi identyfikować „tę samą” prośbę

Klucz cache powinien reprezentować wszystko, co ma realny wpływ na odpowiedź. Zbyt ogólny klucz da pozornie wysoki hit-rate kosztem błędów jakościowych; zbyt szczegółowy klucz obniży hit-rate i ograniczy oszczędności.

• Treść zapytania użytkownika w postaci znormalizowanej (np. usunięte nadmiarowe białe znaki, ujednolicona interpunkcja, jeśli to nie zmienia znaczenia).
• Parametry generacji, które wpływają na wynik: model, wersja modelu, temperatura/top-p, maksymalna długość, tryb odpowiedzi (np. „krótko” vs „szczegółowo”).
• Instrukcje systemowe i polityki (system prompt, zasady stylu, wymagany format), bo nawet drobna zmiana może zmienić treść lub ton.
• Istotny kontekst, jeśli odpowiedź zależy od poprzednich wiadomości lub ustawień użytkownika. W praktyce często opłaca się cache’ować tylko te ścieżki, które są mało zależne od historii.
• Wersja logiki aplikacji (np. wersja promptu lub konfiguracji), aby po zmianach nie serwować odpowiedzi niezgodnych z nowymi wymaganiami.

Warto też rozróżnić cache dla odpowiedzi „publicznych” (bez danych wrażliwych) i „prywatnych” (per użytkownik/tenant). Mieszanie tych dwóch światów to prosta droga do wycieku informacji.

TTL: jak długo odpowiedź jest „bezpieczna”

TTL (czas życia wpisu) to kompromis między oszczędnością a aktualnością. Krótszy TTL zmniejsza ryzyko nieaktualnych informacji, ale obniża hit-rate; dłuższy TTL zwiększa oszczędności, ale podnosi ryzyko „stale data”.

• Długie TTL ma sens dla treści stałych: definicje, instrukcje użycia, odpowiedzi niezależne od bieżących danych.
• Krótkie TTL lepiej pasuje do treści, które mogą się zmieniać: ceny, stany, regulaminy, statusy.
• Brak cache bywa najlepszy, gdy odpowiedź opiera się na danych w czasie rzeczywistym lub na kontekście prywatnym, który szybko ewoluuje.

TTL powinien wynikać z „okna prawdy” danych: jeśli informacja starzeje się po godzinie, cache na dobę będzie generował nieprzewidywalne błędy jakościowe.

Hit-rate: jak mierzyć opłacalność

Hit-rate (odsetek trafień w cache) bezpośrednio przekłada się na oszczędności tokenów, ale sam w sobie nie jest metryką jakości. Wysoki hit-rate osiągnięty przez zbyt agresywne uogólnienie kluczy może pogorszyć poprawność odpowiedzi.

• Monitoruj hit-rate osobno dla typów zapytań (np. FAQ vs zapytania transakcyjne) i dla poziomów personalizacji.
• Patrz na hit-rate razem z metrykami jakości: reklamacje użytkowników, korekty agentów, wzrost eskalacji do człowieka, spadek konwersji.
• Uwzględnij „koszt alternatywny”: nawet średni hit-rate bywa bardzo opłacalny, jeśli odpowiedzi są długie i drogie w tokenach.

Ryzyko „stale data”: kiedy cache szkodzi bardziej niż pomaga

Największe ryzyko response caching to podanie poprawnej językowo, ale nieaktualnej lub nieadekwatnej odpowiedzi. Użytkownik często nie rozpozna, że dostał „stary” wynik, bo brzmi on wiarygodnie.

• Zmiany w politykach i instrukcjach: aktualizacje zasad, wymogów prawnych, stylu odpowiedzi.
• Zmiany w danych źródłowych: nowe informacje w bazie wiedzy, zmiany produktów, nowych ograniczeń.
• Konflikt z personalizacją: odpowiedź z cache może pominąć bieżący kontekst użytkownika (np. inny plan, inny język, inne uprawnienia).
• Dryf modelu lub konfiguracji: zmiana modelu/parametrów powinna rozdzielać przestrzeń cache, inaczej odpowiedzi będą niespójne.

W praktyce response caching daje największą wartość, gdy stosujesz go selektywnie: dla klas zapytań o stabilnej treści i niskim ryzyku błędów, z jasnymi zasadami TTL i kluczami, które nie „sklejają” różnych sytuacji w jedno. Tam, gdzie priorytetem jest świeżość danych lub silna personalizacja, cache odpowiedzi powinien być ostrożny albo w ogóle wyłączony.

Strategia 2: Cache narzędzi i wyników wywołań (tool/function caching) – deterministyczność, idempotencja i invalidacja

W agentach LLM spora część kosztów i opóźnień nie wynika z samego „myślenia” modelu, tylko z wywołań narzędzi: API (CRM, płatności, mapy), wyszukiwarek, baz danych, parserów, tłumaczy, transkrypcji czy generatorów raportów. Tool/function caching polega na zapamiętywaniu wyników takich wywołań i ponownym użyciu ich, gdy agent prosi o to samo (lub równoważne) działanie. Zysk jest podwójny: mniej tokenów (mniej round-tripów i opisów wyników w kontekście) oraz mniejsza latencja.

Kiedy cache narzędzi ma największy sens

• Wysoka powtarzalność zapytań: te same parametry funkcji pojawiają się w wielu rozmowach lub krokach tego samego zadania.
• Drogie lub wolne narzędzia: płatne API, zapytania do hurtowni, skomplikowane obliczenia.
• Wyniki stabilne w czasie: dane referencyjne (np. kursy historyczne dla konkretnej daty), konfiguracje, słowniki, metadane.
• Łańcuchy agentowe: wiele kroków pyta o te same dane w różnych formach (np. „pobierz szczegóły klienta” oraz później „sprawdź status klienta”).

Deterministyczność: czy to samo wejście daje to samo wyjście?

Kluczowe pytanie brzmi: czy wynik narzędzia jest deterministyczny względem wejścia i kontekstu? Jeśli tak, cache jest prostszy i bezpieczniejszy. Jeśli nie (np. zależy od czasu, losowości, stanu sesji), trzeba dodać ograniczenia i lepszą invalidację.

Idempotencja: bezpieczne powtórzenie tej samej akcji

W agentach często zdarzają się ponowienia: retry po timeoucie, ponowne wywołanie po doprecyzowaniu, równoległe kroki lub „zapętlenie” planowania. Dla narzędzi wykonujących modyfikacje (write) ważniejsza od cache jest idempotencja: wielokrotne wywołanie z tym samym identyfikatorem nie powinno tworzyć duplikatów ani wykonywać akcji drugi raz.

• Idempotency key: klient (agent) wysyła unikalny klucz operacji; serwer zwraca ten sam rezultat przy powtórzeniu.
• Oddziel odczyt od zapisu: cache stosuj głównie do operacji read; write zabezpieczaj idempotencją i rejestrem wykonania.
• Cache „wyniku potwierdzenia”: czasem opłaca się cache’ować odpowiedź potwierdzającą (np. numer zgłoszenia), ale tylko w powiązaniu z idempotency key.

Jak budować klucze cache dla wywołań funkcji

Klucz powinien jednoznacznie opisywać to, co wpływa na wynik. W praktyce oznacza to: nazwa narzędzia, parametry w postaci kanonicznej oraz kontekst wykonania, jeśli ma znaczenie (np. uprawnienia użytkownika, tenant, wersja API).

• Kanoniczna serializacja: te same parametry muszą zawsze dawać identyczny klucz (np. sortowanie pól JSON, normalizacja whitespace).
• Scope: rozdziel cache per użytkownik / organizacja / środowisko, aby uniknąć wycieku danych.
• Wersjonowanie: uwzględnij wersję narzędzia lub schematu odpowiedzi; zmiana kontraktu powinna odciąć stary cache.

// Pseudokod: deterministyczny klucz dla call(tool, args, authScope)
key = hash(
  toolName + "|" + toolVersion + "|" + authScope + "|" + canonicalJson(args)
)

Invalidacja: najtrudniejsza część

Nawet idealny klucz nie wystarczy, jeśli dane się zmieniają. W cache narzędzi zwykle stosuje się trzy proste mechanizmy, które dają dobry kompromis między świeżością a oszczędnościami:

• TTL: automatyczne wygasanie po czasie (krótsze dla danych dynamicznych).
• Event-based: unieważnianie po zdarzeniu (np. „zaktualizowano profil klienta” → usuń cache zapytań o profil).
• Wersja/etag: gdy źródło zwraca wersję rekordu, cache można wiązać z wersją i odświeżać tylko po zmianie.

Ryzyko biznesowe zwykle wynika nie z samego cache, tylko z błędnie dobranej invalidacji: agent może podjąć decyzję na podstawie nieaktualnego stanu. Dlatego cache narzędzi najlepiej traktować jako kontrolowane przyspieszenie dla danych, które mogą być „wystarczająco świeże” w danym scenariuszu.

Minimalna polityka: co cache’ować, a czego nie

• Cache’uj: odczyty, obliczenia czysto funkcjonalne, metadane, wyniki kosztownych zapytań o niskiej zmienności.
• Ostrożnie: odczyty silnie zależne od „teraz”, dane wrażliwe (wymagają ścisłego scopu i szyfrowania), wyniki zależne od sesji.
• Nie cache’uj jako substytutu kontroli: operacji, które mają skutki uboczne; tu priorytetem jest idempotencja i audyt.

Efekt na koszty tokenów i jakość

Tool caching obniża koszty tokenów głównie pośrednio: agent nie musi wielokrotnie „dopytywać” narzędzi i wprowadzać do kontekstu tych samych odpowiedzi. Jakość zwykle rośnie (mniej błędów z timeoutów, stabilniejsze dane wejściowe), o ile polityka invalidacji nie dopuszcza do użycia nieakceptowalnie starych wyników.

Strategia 3: Cache embeddingów i wyszukiwania (vector cache) – deduplikacja, wersjonowanie modeli i odświeżanie indeksu

W agentach LLM dużą część kosztu i latencji potrafią generować nie same odpowiedzi, lecz operacje „dookoła”: tworzenie embeddingów zapytań/dokumentów oraz wyszukiwanie podobieństwa w bazie wektorowej. Vector cache polega na ponownym wykorzystaniu już policzonych embeddingów i/lub wyników wyszukiwania (top-k), aby ograniczyć liczbę wywołań modelu embeddingowego oraz zapytań do indeksu.

Co dokładnie cachujemy?

• Embedding zapytania (query embedding) – gdy użytkownicy zadają powtarzalne lub bardzo podobne pytania, można przechowywać wektor dla kanonicznej postaci zapytania.
• Embedding dokumentu/chunku – przy ingestowaniu treści; zamiast przeliczać embeddingi po każdej aktualizacji pipeline’u, zapisujemy je i aktualizujemy tylko gdy treść się zmieni.
• Wyniki wyszukiwania (search result cache) – np. lista ID dokumentów + score dla (zapytanie, filtry, top-k). To często daje największą redukcję latencji, ale wymaga ostrożnej invalidacji.

Deduplikacja: mniej embeddingów, mniej indeksowania

Deduplikacja to praktyka redukowania powielonych treści, zanim trafią do kosztownych kroków (embedding + indeks). W typowych systemach te same fragmenty pojawiają się wielokrotnie (kopie, wersje, cytaty, stopki, powtarzalne sekcje regulaminów). Bez deduplikacji płacisz za:

• ponowne obliczenie embeddingu,
• większy indeks (koszt storage + wolniejsze wyszukiwanie),
• gorszą jakość (retrieval zwraca duplikaty zamiast zróżnicowanych źródeł).

Praktycznie deduplikację robi się na dwóch poziomach:

• Dokładna (exact): hash kanonicznej treści (np. po normalizacji białych znaków). Szybka i tania.
• Przybliżona (near-duplicate): wykrywa „prawie to samo” (np. różne daty, drobne zmiany). Zmniejsza indeks i poprawia różnorodność wyników, ale wymaga progu podobieństwa i akceptacji ryzyka fałszywych trafień.

Wersjonowanie modeli: embedding bez kontekstu wersji jest pułapką

Embeddingi są ściśle zależne od: (1) modelu embeddingowego, (2) jego ustawień, (3) sposobu segmentacji tekstu, (4) normalizacji i preprocessing’u. Zmiana któregokolwiek elementu może sprawić, że stare wektory staną się nieporównywalne z nowymi albo pogorszą trafność wyszukiwania. Zespół trenerski Cognity zauważa, że właśnie ten aspekt sprawia uczestnikom najwięcej trudności — najczęściej dlatego, że „działało wczoraj”, a po zmianie modelu lub chunkingu jakość retrieval potrafi spaść bez oczywistego błędu w logach.

Dlatego cache i indeks wektorowy powinny być wprost wersjonowane. Minimalny zestaw metadanych wersji to:

• model_id (nazwa/wersja modelu embeddingowego),
• embedding_dim (wymiar wektora),
• pipeline_version (chunking + preprocessing),
• index_version (konfiguracja indeksu i metryka podobieństwa).

W praktyce oznacza to, że klucz cache powinien zawierać wersję. Bez tego system może „zjadać” pozornie poprawne cache-hit’y, które w rzeczywistości degradują jakość retrieval.

Odświeżanie indeksu: kiedy cache szkodzi jakości

Cache wyników wyszukiwania jest szczególnie wrażliwy na zjawisko „stale retrieval”: zapytanie zwraca stare top-k, mimo że baza wiedzy lub uprawnienia dostępu się zmieniły. Żeby tego uniknąć, odświeżanie indeksu i invalidacja cache powinny być częścią projektu:

• Zmiana treści (nowe/zmienione dokumenty) → odśwież odpowiednie embeddingi i wpisy indeksu; unieważnij cache wyników wyszukiwania dla zapytań zależnych od tej kolekcji.
• Zmiana filtrów/ACL (np. dostęp per użytkownik/rola) → nie cachuj „gołych” wyników bez kontekstu uprawnień; w przeciwnym razie ryzykujesz wyciek danych.
• Zmiana modelu lub pipeline’u → buduj nowy indeks równolegle (nowa wersja), a cache traktuj jako „per wersja”, nie globalnie.

Porównanie: co daje największy zwrot z inwestycji?

Minimalny szkic implementacji (klucze i wersjonowanie)

# Pseudokod: klucze cache dla embeddingów i wyników wyszukiwania

def canon(text):
    return normalize_whitespace(text.strip().lower())

MODEL_ID = "embed-model@2026-01"
PIPELINE_VERSION = "chunk:v3|prep:v2"
INDEX_VERSION = "hnsw:v5|cosine"

query_key = f"qemb:{MODEL_ID}:{hash(canon(query))}"

# embedding dokumentu zależny od treści i pipeline’u
content_hash = hash(canon(chunk_text))
doc_key = f"demb:{MODEL_ID}:{PIPELINE_VERSION}:{doc_id}:{content_hash}"

# cache wyników wyszukiwania zależny od filtrów, top-k, wersji indeksu i zakresu uprawnień
filters_key = hash(serialize(filters))
acl_scope = f"role:{role_id}"  # lub user_id, tenant_id itp.
search_key = f"srch:{INDEX_VERSION}:{MODEL_ID}:{filters_key}:{top_k}:{acl_scope}:{hash(canon(query))}"

Wniosek praktyczny: vector cache działa najlepiej, gdy jest sprzężony z deduplikacją (mniej danych do utrzymania), wersjonowaniem (bezpieczne zmiany modeli/pipeline’u) oraz przewidywalnym odświeżaniem indeksu (brak „starej wiedzy” i ryzyk bezpieczeństwa). Dzięki temu obniżasz koszty tokenów pośrednio — poprzez mniej wywołań embeddingów i szybsze retrieval — bez utraty jakości odpowiedzi.

Strategia 4: Pamięć krótkotrwała vs długotrwała – architektura, polityki zapisu/odczytu i prywatność

W agentach LLM „pamięć” to wszystko, co pozwala ograniczyć liczbę tokenów wysyłanych w każdym zapytaniu, a jednocześnie utrzymać spójność działania w czasie. Kluczowe jest rozdzielenie pamięci krótkotrwałej (na potrzeby bieżącej sesji i natychmiastowego kontekstu) od pamięci długotrwałej (utrwalającej wybrane fakty i preferencje między sesjami). Ten podział porządkuje architekturę, ułatwia kontrolę kosztów oraz zmniejsza ryzyko naruszeń prywatności.

1) Dwie warstwy pamięci: po co i kiedy

Pamięć krótkotrwała ma służyć temu, by agent „nie gubił wątku” bez konieczności doklejania pełnej historii rozmowy do każdego promptu. To zwykle dane o wysokiej zmienności i niskiej wartości po zakończeniu zadania (np. aktualne cele, tymczasowe ustalenia, ostatnie decyzje).

Pamięć długotrwała jest sensowna tylko wtedy, gdy to, co zapamiętujemy, realnie obniża koszty i poprawia trafność w przyszłości (np. stałe preferencje użytkownika, konfiguracja środowiska, stabilne fakty domenowe). Zbyt agresywne zapisywanie „wszystkiego” prowadzi do zaśmiecenia, gorszego doboru kontekstu i ryzyk prywatności.

2) Szybkie porównanie (zastosowania i konsekwencje)

3) Minimalna architektura pamięci agenta

Praktyczna architektura zwykle wygląda jak warstwowy „stos”:

• Warstwa sesji – stan bieżącej rozmowy i zadania (krótkotrwała).
• Warstwa użytkownika – preferencje i ustawienia specyficzne dla osoby/zespołu (długotrwała).
• Warstwa aplikacji/domeny – stabilne reguły, procedury, definicje pojęć (długotrwała, często współdzielona).

Istotne jest, aby agent nie traktował pamięci jak „drugiej historii czatu”. Pamięć powinna być strukturalna (np. pola, atrybuty, fakty) i celowa (zapisywana tylko wtedy, gdy to realnie pomoże w kolejnych interakcjach).

4) Polityki zapisu: co wolno utrwalać, a co nie

Najczęstszy błąd to zapisywanie zbyt dużej ilości danych „na wszelki wypadek”. Lepsze są proste reguły:

• Domyślnie nie zapisuj niczego długotrwale bez powodu (opt-in zamiast opt-out).
• Zapisuj tylko stabilne i użyteczne informacje (preferencje, ustawienia, stałe ograniczenia).
• Oddziel fakty od hipotez i niepewnych wniosków; jeśli musisz zapisać wniosek, oznacz go jako niezweryfikowany.
• Unikaj utrwalania danych wrażliwych; jeśli są konieczne do działania, stosuj minimalizację i ograniczoną retencję.
• Wprowadzaj czas życia dla wpisów pamięci (retencja) i mechanizm korekty/wycofania.

5) Polityki odczytu: jak korzystać z pamięci bez „przeładowania” promptu

Odczyt pamięci powinien być kontrolowany budżetem tokenów i dopasowany do zadania. Dobre, podstawowe zasady:

• Ładuj pamięć warstwami: najpierw sesja, potem użytkownik, na końcu domena (tylko jeśli potrzebna).
• Preferuj formę zwięzłą i ustrukturyzowaną (np. lista preferencji) zamiast długich fragmentów tekstu.
• Jeżeli pamięć jest niepewna lub nieaktualna, agent powinien zadać pytanie doprecyzowujące zamiast „zgadywać”.
• Stosuj priorytety: preferencje i ograniczenia mają pierwszeństwo przed „ciekawostkami”.

6) Prywatność i bezpieczeństwo: podstawowe praktyki

Pamięć długotrwała praktycznie zawsze oznacza większą odpowiedzialność. Nawet prosta implementacja powinna uwzględniać:

• Minimalizację danych: zapisuj tylko to, co jest niezbędne do celu.
• Separację tenantów/użytkowników: brak współdzielenia pamięci między kontami, jasne granice dostępu.
• Kontrolę retencji: automatyczne wygasanie i okresowe czyszczenie.
• Audytowalność: możliwość sprawdzenia, co zostało zapamiętane i dlaczego.
• Prawo do usunięcia: możliwość ręcznego usunięcia/wyłączenia pamięci dla użytkownika.
• Ograniczenie wrażliwych kategorii: w miarę możliwości nie przechowuj danych wrażliwych; jeśli musisz, redukuj zakres i czas oraz wzmacniaj kontrolę dostępu.

7) Krótki przykład struktury „pamięci” jako danych

Zamiast przechowywać wielostronicowe notatki, lepiej utrzymywać mały, czytelny rekord. To ułatwia kontrolę jakości i ogranicza tokeny przy odczycie.

{
  "session": {
    "goal": "przygotować ofertę",
    "constraints": ["język: pl", "format: PDF"],
    "open_questions": ["budżet klienta"],
    "expires_at": "2026-03-24T18:00:00Z"
  },
  "user": {
    "preferences": {
      "tone": "konkretny",
      "units": "PLN"
    },
    "do_not_store": ["dane wrażliwe"],
    "updated_at": "2026-03-24T10:12:00Z"
  }
}

Taki podział pomaga agentowi pobierać tylko to, co potrzebne, i nie „zalewać” modelu treścią, która nie wnosi wartości.

Strategia 5: Kompresja kontekstu – streszczanie, distill, formaty kanoniczne i kontrola degradacji jakości

Kompresja kontekstu polega na zmniejszeniu liczby tokenów przekazywanych do modelu przy zachowaniu tego, co jest faktycznie potrzebne do poprawnej odpowiedzi. To podejście szczególnie dobrze działa w agentach, gdzie kontekst narasta: wieloetapowe rozumowanie, logi narzędzi, historia rozmowy, notatki i wnioski pośrednie. Zyski są podwójne: niższy koszt i często niższa latencja, ale istnieje ryzyko utraty niuansów, dlatego kompresję warto traktować jako proces kontrolowany.

Co kompresować (i dlaczego to działa)

• Historię dialogu – stare wiadomości zwykle są mniej istotne niż aktualny cel i ustalenia.
• Ślady narzędzi (tool logs) – często zawierają nadmiarowe pola, powtórzenia i dane, które nie wpływają na decyzję.
• Dokumenty źródłowe – zamiast pełnych fragmentów można przenieść do kontekstu jedynie tezy, cytaty lub fakty istotne dla zadania.
• Ustalenia i ograniczenia – warto utrzymywać je w krótkiej, stabilnej postaci, aby nie „rozmywały się” w długiej historii.

Streszczanie vs distill vs format kanoniczny

„Kompresja” to nie jedna technika. Najczęściej spotkasz trzy klasy podejść, które można łączyć:

Praktyczne wzorce kompresji

• Rolling summary – okresowo zamieniaj starszą część historii na krótkie podsumowanie + zachowuj kilka ostatnich tur w pełnej postaci.
• Decision log – zamiast trzymać całą dyskusję, przechowuj listę decyzji, uzasadnień i otwartych pytań.
• Key facts – utrzymuj „pamięć faktów” jako krótką listę (np. dane użytkownika, cele, ograniczenia), aktualizowaną przy zmianach.
• Tool output trimming – zapisuj tylko pola/fragmenty odpowiedzi narzędzia, które są używane w kolejnych krokach (np. liczby, statusy, identyfikatory).

Formaty kanoniczne: po co i jak minimalizują tokeny

Ujednolicenie zapisu redukuje „szum językowy” i liczbę tokenów marnowanych na parafrazy. Dodatkowo ułatwia porównywanie wersji i aktualizację. Typowe schematy to:

• JSON dla danych strukturalnych (preferencje, parametry, wyniki),
• YAML dla konfiguracji czy list wymagań,
• krótki DSL (mały, własny format) dla powtarzalnych stanów, o ile jest stabilny i prosty.

Kluczowe jest, by kanon zawierał tylko to, co model ma wykorzystać. Jeśli przechowujesz tam wszystko, kompresja staje się pozorna.

Kontrola degradacji jakości: jak kompresować bez „psucia” odpowiedzi

Kompresja zawsze jest kompromisem. Żeby uniknąć spadku jakości, stosuj proste mechanizmy kontroli:

• Polityka „must-keep” – zdefiniuj kategorie, których nie wolno streszczać (np. wymagania, ograniczenia, liczby, definicje).
• Weryfikacja spójności – po kompresji sprawdź, czy zachowane są kluczowe fakty (np. lista punktów kontrolnych).
• Budżet minimalny – utrzymuj minimalny zestaw „kotwic” (cele, kontekst, stan), nawet jeśli resztę mocno skracasz.
• Reguły anty-halucynacyjne – w kompresji zapisuj wprost, co jest pewne, a co jest hipotezą lub nieznane.

Minimalny przykład: destylacja do formatu kanonicznego

Poniżej przykład, jak „rozlaną” historię zamienić na krótką postać, którą agent może bezpiecznie dokleić do promptu:

{
  "goal": "Przygotować odpowiedź na reklamację",
  "constraints": [
    "Nie ujawniać danych osobowych",
    "Odpowiedź w języku polskim",
    "Ton uprzejmy i konkretny"
  ],
  "known_facts": {
    "order_id": "12345",
    "issue": "Uszkodzony produkt",
    "requested_resolution": "Wymiana"
  },
  "open_questions": [
    "Czy klient przesłał zdjęcia uszkodzenia?"
  ]
}

Taki zapis jest krótki, jednoznaczny i łatwy do aktualizacji. Jednocześnie nie udaje, że ma pełną treść rozmowy – przechowuje to, co najczęściej wpływa na decyzję.

Strategia 6: Selekcja kontekstu – RAG, re-ranking, okna ważności i budżet tokenów

Selekcja kontekstu to zestaw praktyk, których celem jest podanie modelowi tylko tych informacji, które realnie zwiększają trafność odpowiedzi, zamiast „dokarmiania” go pełną historią rozmowy lub dużą paczką dokumentów. W agentach LLM jest to jedna z najszybszych dróg do obniżenia kosztów tokenów i latencji przy utrzymaniu jakości, bo większość zbędnych tokenów pochodzi właśnie z nadmiarowego kontekstu.

W przeciwieństwie do cache (który ogranicza liczbę powtórnych obliczeń), selekcja kontekstu ogranicza rozmiar wejścia do modelu. Jej skuteczność mierzy się nie tylko oszczędnością tokenów, ale też spadkiem błędów wynikających z „szumu” informacyjnego: sprzecznych fragmentów, nieaktualnych instrukcji, duplikatów czy długich dygresji.

RAG: kiedy kontekst pochodzi z wiedzy zewnętrznej

RAG (Retrieval-Augmented Generation) polega na tym, że agent najpierw wyszukuje relevantne fragmenty w bazie wiedzy (np. dokumentach, notatkach, regulaminach, wiki), a dopiero potem dołącza je do promptu. Zastosowanie RAG jest szczególnie opłacalne, gdy:

• nie chcesz utrzymywać dużej „pamięci” w samym kontekście rozmowy,
• wiedza jest rozproszona i często aktualizowana,
• odpowiedzi muszą bazować na źródłach (mniej halucynacji, większa weryfikowalność).

Kluczowa różnica względem „pełnego kontekstu” rozmowy jest taka, że RAG dostarcza tylko wybrane dowody z repozytorium, zamiast utrzymywać wszystko w oknie kontekstowym.

Re-ranking: mniej, ale trafniej

Samo wyszukanie top-k fragmentów bywa za słabe, bo wyniki mogą być podobne do zapytania, ale niekoniecznie odpowiadają na intencję użytkownika. Re-ranking to etap, w którym agent (lub osobny model/heurystyka) porządkuje wstępnie znalezione fragmenty i wybiera mniejszy zestaw do włączenia w prompt.

Praktyczna rola re-rankingu w strategii kosztowej jest prosta: pozwala zmniejszyć k (liczbę dołączanych fragmentów), utrzymując lub poprawiając jakość. To ogranicza tokeny wejściowe, a często także liczbę „rozproszeń” w odpowiedzi.

Okna ważności: priorytetyzacja w czasie i w zadaniu

Nie każdy element kontekstu jest równie istotny w danym momencie. Okna ważności to zasada, że agent pracuje na warstwach informacji o różnym priorytecie, np.:

• „Tu i teraz”: ostatnia intencja użytkownika, bieżące ograniczenia, aktualny stan zadania.
• „Najważniejsze ustalenia”: zwięzłe fakty i decyzje, które powinny przetrwać dłużej niż kilka tur.
• „Historia”: treści o malejącej wartości, używane tylko gdy są potrzebne do rozstrzygnięcia niejednoznaczności.

W praktyce oznacza to, że agent nie traktuje całej historii rozmowy jako jednego bloku. Zamiast tego dobiera kontekst według ważności: najpierw to, co krytyczne dla poprawnej odpowiedzi, a dopiero potem elementy „miłe mieć”.

Budżet tokenów: twarde limity i świadome kompromisy

Selekcja kontekstu działa najlepiej, gdy jest wsparta budżetem tokenów – z góry ustalonym limitem na kontekst (a czasem także na generację). Budżet wymusza podejmowanie decyzji: co jest warte swojej „ceny” w tokenach. Dobre praktyki na poziomie zasad (bez wchodzenia w implementację) obejmują:

• Najpierw instrukcje i stan, potem dowody (RAG), na końcu historia – jeśli jeszcze jest miejsce.
• Eliminację duplikatów i fragmentów o niskiej wartości informacyjnej.
• Minimalny zestaw źródeł: mniej cytatów, ale bardziej trafnych (wspierane re-rankingiem).
• Kontrolę ryzyka: w zadaniach wysokiej stawki większy budżet na dowody; w zadaniach rutynowych bardziej agresywne cięcie.

Warto pamiętać, że budżet tokenów to nie tylko optymalizacja kosztu. To także narzędzie poprawy jakości: mniejszy, lepiej dobrany kontekst redukuje sprzeczności i ogranicza przypadkowe „przesterowanie” modelu nadmiarem informacji.

Kiedy selekcja kontekstu daje największy zwrot

• Długie rozmowy, w których historia szybko rośnie, a większość wcześniejszych tur traci znaczenie.
• Agenci wielonarzędziowi, gdzie stan i wyniki pośrednie mogą zasypać okno kontekstowe.
• Duże bazy wiedzy, w których nie da się „wkleić wszystkiego”, a trafność zależy od dobrego wyszukania i doboru fragmentów.
• Systemy o wysokim wolumenie, gdzie każdy nadmiarowy token jest mnożony przez liczbę zapytań.

Selekcja kontekstu jest więc praktyką „mniej, ale lepiej”: kontrolujesz, co trafia do promptu, dlaczego tam trafia i ile tego może być. Dzięki temu agent utrzymuje jakość odpowiedzi, jednocześnie ograniczając koszty i opóźnienia.

Strategia 7: Routing modeli i adaptacyjne budżetowanie – wybór tańszych modeli, fallbacki i mierzenie oszczędności

Nie każde zapytanie wymaga tego samego „kalibru” modelu. Routing modeli polega na świadomym kierowaniu zadań do różnych modeli (tańszych lub droższych) zależnie od ryzyka błędu, wymagań jakościowych i konsekwencji biznesowych. Adaptacyjne budżetowanie tokenów uzupełnia to podejście: zamiast stałego limitu kontekstu i odpowiedzi, agent dynamicznie decyduje, ile tokenów „może wydać” na daną sprawę, aby utrzymać jakość przy możliwie niskim koszcie.

W praktyce ta strategia sprowadza się do prostego założenia: większość interakcji obsłuż najtaniej, jak się da, a droższe modele uruchamiaj tylko wtedy, gdy są naprawdę potrzebne lub gdy tańsza ścieżka nie spełniła kryteriów jakości.

Gdzie routing daje największy efekt

• Intencje o niskiej złożoności (FAQ, krótkie odpowiedzi, formatowanie treści, parafraza, proste klasyfikacje) – zwykle mogą korzystać z tańszych modeli.
• Zadania wysokiego ryzyka (wnioskowanie wieloetapowe, złożone instrukcje, krytyczne decyzje, teksty o wysokiej odpowiedzialności) – częściej uzasadniają droższy model lub dodatkową walidację.
• Przepływy agentowe z narzędziami – model „orkiestrujący” może być lepszy jakościowo, ale poszczególne kroki (np. ekstrakcja danych, normalizacja, opis wyników) da się delegować do tańszych wariantów.

Typowe mechanizmy routingu (bez wchodzenia w implementację)

• Reguły i progi – kierowanie po typie zadania, długości kontekstu, języku, wymaganym formacie, czy poziomie zgodności (np. potrzeba cytowań, rygor formalny).
• Ocena trudności – wstępna kwalifikacja zapytania do „łatwe/trudne” na podstawie sygnałów takich jak niejednoznaczność, liczba wymagań, konieczność rozumowania lub łączenia wielu źródeł.
• Routing etapowy – rozpoczęcie od tańszego modelu i eskalacja dopiero, gdy wykryto problemy z jakością lub brak pewności.

Fallbacki: jak eskalować bez utraty jakości

Fallback to kontrolowana „druga próba” droższą ścieżką. Kluczowe jest, by eskalacja była uruchamiana na podstawie sygnałów, a nie nawyku. Najczęstsze sygnały to: niespełnienie wymagań formatu, wykryta sprzeczność, zbyt duża ogólność odpowiedzi, brak odpowiedzi na część pytań, lub niska pewność weryfikowana prostymi kryteriami. Wariantem fallbacku jest też ponowne uruchomienie tego samego modelu z inną instrukcją, ale nadal z kontrolą kosztu.

Adaptacyjne budżetowanie tokenów

Budżet tokenów staje się zasobem, którym agent zarządza jak limitem czasu lub pieniędzy. Zamiast zawsze wysyłać maksymalny kontekst i oczekiwać długich odpowiedzi, agent dopasowuje:

• maksymalną długość odpowiedzi do celu (krótko i konkretnie vs. pełne uzasadnienie),
• poziom szczegółowości do ryzyka (więcej wyjaśnień, gdy stawka jest wysoka),
• liczbę iteracji (np. jedna próba dla prostych spraw, wieloetapowo tylko gdy konieczne),
• koszt narzędzi i modeli w całym przepływie, a nie w pojedynczym wywołaniu.

Efekt jest podwójny: mniej tokenów w typowych przypadkach oraz bardziej przewidywalne koszty w przypadkach trudnych. W Cognity łączymy teorię z praktyką – dlatego ten temat rozwijamy także w formie ćwiczeń na szkoleniach.

Mierzenie oszczędności i kontrola jakości

Routing i budżetowanie mają sens tylko wtedy, gdy są mierzone. Warto myśleć o nich jak o systemie optymalizacji: minimalizujesz koszt, ale przy utrzymaniu akceptowalnej jakości. Podstawowe miary to:

• koszt na zadanie (średni i percentyle),
• udział eskalacji (jak często uruchamia się fallback),
• czas odpowiedzi (czy tańsza ścieżka rzeczywiście skraca latencję),
• stabilność jakości (odsetek spraw zakończonych poprawnie bez poprawek, reworku lub ręcznej interwencji).

Jeśli obserwujesz spadek jakości, najczęściej oznacza to, że routing jest zbyt agresywny (za dużo zadań trafia do tańszych modeli) albo budżety są zbyt ciasne dla określonych typów zapytań. Dobrze zaprojektowany system powinien umożliwiać szybkie dostrojenie progów i zasad, tak by oszczędności nie były „pozorne” i nie generowały kosztów po stronie użytkownika lub operacji.

Copilot w Outlooku i Teams: 11 zasad bezpiecznego streszczania wątków (żeby nie wysłać tajemnicy) 29 marca 2026

Copilot w Excelu 2026: 9 zadań, które dalej robi źle (i jak to obejść formułami) 27 marca 2026