Cache semantyczny LLM: jak ciąć koszty i opóźnienia powtarzalnych zapytań

Firma obsługująca 8 000 zapytań miesięcznie do asystenta AI może płacić 800-1 600 zł za tokeny, z czego 40-55% pochodzi z pytań, które pojawiają się wielokrotnie w niemal identycznej formie. Cache semantyczny likwiduje tę kategorię kosztów bez zmiany jakości odpowiedzi, o ile wdrożysz go z właściwym TTL i progiem podobieństwa.

Przepływ wygląda następująco. Zapytanie użytkownika trafia do warstwy cache przed modelem. System generuje jego embedding (np. BGE-M3, text-embedding-3-small) i porównuje go z embeddingami wcześniej zapisanych zapytań w bazie wektorowej. Jeśli podobieństwo cosinusowe przekracza skonfigurowany próg, zwraca zapisaną odpowiedź. Poniżej progu zapytanie wędruje do modelu, a nowa para (zapytanie, odpowiedź) trafia do cache z przypisanym TTL.

Trzy parametry sterują zachowaniem całego mechanizmu:

Próg podobieństwa (threshold): wartości 0,92-0,96 sprawdzają się w większości wdrożeń obsługi klienta. Niższy próg zwiększa hit-rate, ale rośnie ryzyko, że semantycznie bliska para dostanie odpowiedź z innego kontekstu. Wyższy próg jest bezpieczniejszy, lecz przepuszcza więcej zapytań do modelu.

TTL (Time to Live): określa, jak długo odpowiedź pozostaje ważna. Godziny otwarcia sklepu mogą mieć TTL 24 h, ale cena produktu lub status zamówienia wymagają TTL rzędu 5-15 minut albo inwalidacji zdarzeniowej po każdej aktualizacji w systemie źródłowym.

Klucz kontekstu: w systemach wielodostępowych (SaaS, obsługa wielu firm) klucz cache powinien zawierać identyfikator tenanta. Bez tego firma A może dostać odpowiedź dopasowaną do danych firmy B.

Architektura fizyczna jest prosta: baza wektorowa (np. Qdrant, Redis z modułem wektorowym) przechowuje pary embedding-odpowiedź, a model embeddingów działa lokalnie lub przez szybkie API. Latencja trafienia cache wynosi typowo 10-30 ms wobec 300-1500 ms dla pełnej inferencji.

Nie każdy rodzaj zapytań nadaje się do cachowania. Najwyższy hit-rate uzyskujesz tam, gdzie pytania są powtarzalne i odpowiedź nie zmienia się często.

Obsługa klienta to klasyczny przypadek: „kiedy jesteście czynni?", „jak długo trwa dostawa?", „czy mogę zwrócić produkt po 30 dniach?" to pytania, które w ciągu tygodnia pojawią się dziesiątki razy. Corpus FAQ z 50-100 pytaniami i odpowiedziami z TTL 24 h daje hit-rate 50-65% przy stabilnym asortymencie.

Dokumentacja techniczna i wewnętrzna baza wiedzy to drugi silny przypadek. Pytania deweloperów o konfigurację, parametry API czy kroki instalacji mają charakter powtarzalny, a odpowiedzi zmieniają się rzadko (przy nowej wersji oprogramowania wystarczy masowa inwalidacja według tagu wersji).

Asystent onboardingowy dla nowych pracowników to trzeci scenariusz: setki osób przechodzą przez ten sam zestaw pytań o procedury, systemy i uprawnienia.

Kiedy cache nie pomaga albo szkodzi: zapytania wymagające świeżych danych (ceny giełdowe, statusy zamówień w czasie rzeczywistym), zapytania personalizowane zawierające specyficzne dane użytkownika, oraz długie dialogi konwersacyjne, gdzie kontekst sesji zmienia znaczenie każdego kolejnego komunikatu.

False-positive trafienia to najpoważniejsze ryzyko operacyjne. Przy progu 0,90 zapytanie „czy produkt X jest dostępny w kolorze niebieskim?" może trafić na wcześniej zapisaną odpowiedź dla „czy produkt Y jest dostępny w kolorze czerwonym?", jeśli struktury zdań są semantycznie zbliżone. Rozwiązanie: prowadź monitoring false-positive rate (FPR) na zbiorze testowym i podnoś próg, gdy FPR przekracza 1-2%.

Przeterminowane odpowiedzi uderzają w zaufanie klientów mocniej niż wolny asystent. Firma, która zmieniła politykę zwrotów z 14 na 30 dni, ale nie zinwalidowała cache, wysyła przez kilka godzin błędne informacje. Mechanizm inwalidacji zdarzeniowej (webhook z systemu CMS lub CRM → DELETE cache po tagu) jest tu ważniejszy niż samo TTL.

Różne odpowiedzi na te same pytania mogą pojawić się, gdy model jest aktualizowany, a cache przechowuje odpowiedzi starej wersji. Dołącz do klucza cache identyfikator wersji modelu lub flush po każdej aktualizacji.

Wzrost kompleksowości operacyjnej: cache to dodatkowy komponent, który może paść (baza wektorowa niedostępna), wymagać monitoringu i zajmować pamięć. Zanim wdrożysz, oceń, czy hit-rate w twoim przypadku uzasadnia dodatkowe utrzymanie, korzystając z kalkulatora ROI.

Przydatne metryki do monitoringu: hit-rate (cel: > 35% dla FAQ), FPR na zbiorze testowym (cel: < 2%), średnia latencja cache vs. model, procent odpowiedzi zinwalidowanych przed TTL. Więcej o monitorowaniu systemu AI przeczytasz w artykule o monitoringu jakości agenta AI.

Samo TTL rozwiązuje problem przeterminowania tylko częściowo. W praktyce potrzebujesz trzech mechanizmów działających równolegle.

Inwalidacja zdarzeniowa: webhook lub zdarzenie domenowe z systemu źródłowego (CMS, ERP, CRM) trafia do warstwy zarządzania cache i usuwa wpisy powiązane z określonym tagiem (np. product:P-123, policy:returns). To jedyna skuteczna metoda dla danych zmieniających się nieregularnie.

Inwalidacja oparta na wersji: każda aktualizacja modelu LLM lub korpusu bazy wiedzy wyczyść cache w całości lub per segment. Klucze cache zawierają hash wersji dokumentu, więc po aktualizacji dokumentu stare wpisy są automatycznie nieważne (nie pasuje hash).

TTL jako siatka bezpieczeństwa: minimalne TTL 1 h nawet dla „rzadko zmieniających się" danych chroni przed sytuacją, gdy zdarzenie inwalidacji nie doszło (awaria webhooka, bug deploymentu).

Szczegółowe wzorce zarządzania wiedzą w RAG, w tym wersjonowanie i przyrostowa reindeksacja, opisujemy w artykule o aktualizacji wiedzy RAG.

Minimalny stack do cache semantycznego w obsłudze klienta: model embeddingów (BGE-M3 lokalnie lub API), Qdrant jako baza wektorowa z filtrowaniem po metadanych (tenant, tag, wersja), Redis dla TTL i ewentualnego zapisu tagów inwalidacji, oraz lekki orchestrator (n8n lub kod własny) spinający warstwy.

Wdrożenie w trzech etapach: najpierw uruchom w trybie shadow (zapisuj trafienia i chybienia, ale zawsze odpowiadaj modelem), żeby zmierzyć realistyczny hit-rate przed produkcją. Drugi krok to kalibracja progu: testuj wartości 0,90, 0,92, 0,94, 0,96 na zbiorze walidacyjnym z ręcznie ocenionymi parami. Trzeci krok to stopniowe włączanie cache dla kategorii o najwyższym hit-rate i najniższym ryzyku przeterminowania.

Szczegółowe wzorce optymalizacji kosztów tokenów, w tym prompt caching na poziomie API modelu (komplementarny wobec cache semantycznego), znajdziesz w artykule o optymalizacji kosztów tokenów LLM. Cache semantyczny i klasyfikacja i routing zgłoszeń AI działają dobrze jako warstwa wspólna przed routerem modeli, co opisujemy też przy analizie kosztów utrzymania agenta AI.

Zacznij od 0,94 i testuj na zbiorze 50-100 par z ręcznie ocenioną trafnością. Jeśli false-positive rate przekracza 2%, podnieś do 0,96. Jeśli hit-rate poniżej 20% i masz mało szumu w danych, spróbuj 0,92. Nie ma jednej wartości dla wszystkich scenariuszy.

Z ograniczeniami. Cachowanie całego kontekstu rozmowy jest niepraktyczne (niski hit-rate, duże klucze). Skuteczniejsze podejście to cache tylko dla pierwszego zapytania w sesji lub dla pytań faktograficznych (FAQ-like), które pojawiają się w ramach rozmowy i nie zależą od wcześniejszych tur.

Prowadź dwa liczniki: całkowita liczba zapytań do systemu i liczba zapytań przepuszczonych do modelu. Hit-rate = (zapytania z cache / wszystkie zapytania). Koszt bez cache = wszystkie zapytania x średni koszt tokenów. Koszt z cache = przepuszczone do modelu x koszt tokenów + stały koszt infrastruktury cache (embedding + baza wektorowa). Różnica to rzeczywista oszczędność, zestawiona z kosztem utrzymania dodatkowego komponentu.

Odpowiedzi trafiające do cache nie powinny zawierać danych osobowych (imion, numerów zamówień, adresów konkretnych użytkowników). Cache nadaje się do odpowiedzi generycznych (polityki, procedury, FAQ). Personalizowane zapytania zawierające dane użytkownika powinny omijać cache lub być cachowane z kluczem per user-id i TTL zgodnym z polityką retencji. Przeprowadź DPIA przy każdym scenariuszu, gdzie odpowiedź może zawierać pośrednio dane wrażliwe.

Nie. RAG wyszukuje fragmenty dokumentów wiedzy jako kontekst do odpowiedzi modelu. Cache semantyczny przechowuje gotowe odpowiedzi i zwraca je bez udziału modelu przy podobnych pytaniach. Obie technologie mogą działać razem: RAG dostarcza wiedzy do pierwszej odpowiedzi, a cache zapisuje tę odpowiedź dla kolejnych identycznych pytań. W artykule o wyszukiwaniu semantycznym i embeddingach opisujemy warstwę wektorową wspólną dla obu podejść.