Semantischer LLM-Cache: Wie man Kosten und Latenzen bei wiederholten Anfragen reduziert

Ein Unternehmen, das monatlich 8.000 Anfragen an einen KI-Assistenten stellt, kann 800-1.600 € für Token ausgeben, wobei 40-55% dieser Kosten auf Fragen entfallen, die in nahezu identischer Form wiederholt auftreten. Ein semantischer Cache eliminiert diese Kostenkategorie, ohne die Antwortqualität zu beeinträchtigen – vorausgesetzt, er wird mit dem richtigen TTL und Ähnlichkeitsschwellenwert implementiert.

Der Ablauf sieht wie folgt aus: Die Benutzeranfrage gelangt zunächst in die Cache-Schicht vor dem Modell. Das System generiert ein Embedding (z. B. BGE-M3, text-embedding-3-small) und vergleicht es mit den Embeddings zuvor gespeicherter Anfragen in der Vektordatenbank. Überschreitet die kosinusbasierte Ähnlichkeit den konfigurierten Schwellenwert, wird die gespeicherte Antwort zurückgegeben. Liegt sie darunter, wird die Anfrage an das Modell weitergeleitet, und das neue Paar (Anfrage, Antwort) wird mit einem zugewiesenen TTL im Cache gespeichert.

Drei Parameter steuern das Verhalten des gesamten Mechanismus:

Ähnlichkeitsschwellenwert (Threshold): Werte von 0,92-0,96 haben sich in den meisten Kundenservice-Implementierungen bewährt. Ein niedrigerer Schwellenwert erhöht die Hit-Rate, erhöht jedoch das Risiko, dass semantisch ähnliche Anfragen eine Antwort aus einem falschen Kontext erhalten. Ein höherer Schwellenwert ist sicherer, lässt aber mehr Anfragen zum Modell durch.

TTL (Time to Live): Bestimmt, wie lange eine Antwort gültig bleibt. Öffnungszeiten eines Geschäfts können ein TTL von 24 Stunden haben, während Produktpreise oder Bestellstatus ein TTL von 5-15 Minuten oder eine ereignisbasierte Invalidierung nach jeder Aktualisierung im Quellsystem erfordern.

Kontextschlüssel: In Multi-Tenant-Systemen (SaaS, Service für mehrere Unternehmen) sollte der Cache-Schlüssel die Tenant-ID enthalten. Andernfalls könnte Firma A eine Antwort erhalten, die auf die Daten von Firma B zugeschnitten ist.

Die physische Architektur ist einfach: Eine Vektordatenbank (z. B. Qdrant, Redis mit Vektormodul) speichert die Embedding-Antwort-Paare, und das Embedding-Modell läuft lokal oder über eine schnelle API. Die Latenz eines Cache-Treffers beträgt typischerweise 10-30 ms im Vergleich zu 300-1500 ms für eine vollständige Inferenz.

Nicht jede Art von Anfragen eignet sich für das Caching. Die höchste Hit-Rate erzielst du dort, wo Fragen wiederholbar sind und sich die Antworten selten ändern.

Der Kundenservice ist ein klassischer Anwendungsfall: Fragen wie „Wann haben Sie geöffnet?“, „Wie lange dauert die Lieferung?“ oder „Kann ich das Produkt nach 30 Tagen zurückgeben?“ tauchen innerhalb einer Woche dutzende Male auf. Ein FAQ-Korpus mit 50-100 Fragen und Antworten mit einem TTL von 24 Stunden ergibt eine Hit-Rate von 50-65% bei stabilem Sortiment.

Technische Dokumentation und interne Wissensdatenbanken sind ein weiterer starker Anwendungsfall. Fragen von Entwicklern zu Konfigurationen, API-Parametern oder Installationsschritten sind wiederholbar, und die Antworten ändern sich selten (bei einer neuen Softwareversion reicht eine Masseninvalidierung nach Versions-Tag).

Ein Onboarding-Assistent für neue Mitarbeiter ist ein drittes Szenario: Hunderte von Personen durchlaufen denselben Fragenkatalog zu Verfahren, Systemen und Berechtigungen.

Wann der Cache nicht hilft oder sogar schadet: Anfragen, die aktuelle Daten erfordern (Börsenkurse, Echtzeit-Bestellstatus), personalisierte Anfragen mit spezifischen Benutzerdaten sowie lange Konversationsdialoge, bei denen der Sitzungskontext die Bedeutung jeder nachfolgenden Nachricht verändert.

False-Positive-Treffer sind das schwerwiegendste operative Risiko. Bei einem Schwellenwert von 0,90 könnte die Anfrage „Ist Produkt X in Blau verfügbar?“ auf eine zuvor gespeicherte Antwort für „Ist Produkt Y in Rot verfügbar?“ treffen, wenn die Satzstrukturen semantisch ähnlich sind. Lösung: Überwache die False-Positive-Rate (FPR) anhand eines Testdatensatzes und erhöhe den Schwellenwert, wenn die FPR 1-2% überschreitet.

Veraltete Antworten untergraben das Kundenvertrauen stärker als ein langsamer Assistent. Ein Unternehmen, das seine Rückgabepolitik von 14 auf 30 Tage ändert, aber den Cache nicht invalidiert, gibt stundenlang falsche Informationen weiter. Ein ereignisbasierter Invalidierungsmechanismus (Webhook vom CMS oder CRM → DELETE Cache nach Tag) ist hier wichtiger als das TTL selbst.

Unterschiedliche Antworten auf dieselben Fragen können auftreten, wenn das Modell aktualisiert wird, der Cache jedoch Antworten der alten Version speichert. Füge dem Cache-Schlüssel die Modellversions-ID hinzu oder leere den Cache nach jedem Update.

Erhöhte operative Komplexität: Der Cache ist eine zusätzliche Komponente, die ausfallen kann (Vektordatenbank nicht verfügbar), Überwachung erfordert und Speicherplatz beansprucht. Bevor du ihn implementierst, prüfe, ob die Hit-Rate in deinem Fall den zusätzlichen Wartungsaufwand rechtfertigt, mithilfe des ROI-Rechners.

Nützliche Metriken zur Überwachung: Hit-Rate (Ziel: > 35% für FAQ), FPR im Testdatensatz (Ziel: < 2%), durchschnittliche Latenz Cache vs. Modell, Prozentsatz der vor TTL invalidierten Antworten. Mehr über die Überwachung von KI-Systemen erfährst du im Artikel über Monitoring der Qualität eines KI-Agenten.

TTL löst das Problem veralteter Daten nur teilweise. In der Praxis benötigst du drei parallel arbeitende Mechanismen.

Ereignisbasierte Invalidierung: Ein Webhook oder ein domänenspezifisches Ereignis aus dem Quellsystem (CMS, ERP, CRM) gelangt in die Cache-Management-Schicht und entfernt Einträge, die mit einem bestimmten Tag verknüpft sind (z. B. product:P-123, policy:returns). Dies ist die einzige wirksame Methode für Daten, die sich unregelmäßig ändern.

Versionsbasierte Invalidierung: Jedes Update des LLM oder des Wissenskorpus löscht den Cache vollständig oder nach Segmenten. Cache-Schlüssel enthalten einen Hash der Dokumentversion, sodass nach einer Aktualisierung des Dokuments alte Einträge automatisch ungültig werden (der Hash passt nicht mehr).

TTL als Sicherheitsnetz: Ein minimales TTL von 1 Stunde selbst für „selten ändernde“ Daten schützt vor Situationen, in denen das Invalidierungsereignis nicht eintrifft (Webhook-Ausfall, Deployment-Fehler).

Detaillierte Muster für das Wissensmanagement in RAG, einschließlich Versionierung und inkrementeller Reindexierung, beschreiben wir im Artikel über Aktualisierung von RAG-Wissen.

Minimaler Stack für einen semantischen Cache im Kundenservice: Embedding-Modell (BGE-M3 lokal oder API), Qdrant als Vektordatenbank mit Metadatenfilterung (Tenant, Tag, Version), Redis für TTL und optionale Speicherung von Invalidierungstags sowie ein leichter Orchestrator (n8n oder eigener Code), der die Schichten verbindet.

Implementierung in drei Schritten: Zuerst im Shadow-Modus starten (Treffer und Fehlschläge aufzeichnen, aber immer mit dem Modell antworten), um die realistische Hit-Rate vor der Produktion zu messen. Zweiter Schritt: Kalibrierung des Schwellenwerts – teste Werte von 0,90, 0,92, 0,94, 0,96 an einem Validierungsdatensatz mit manuell bewerteten Paaren. Dritter Schritt: Schrittweise Aktivierung des Caches für Kategorien mit der höchsten Hit-Rate und dem geringsten Risiko veralteter Daten.

Detaillierte Muster zur Optimierung von Token-Kosten, einschließlich Prompt-Caching auf API-Ebene des Modells (komplementär zum semantischen Cache), findest du im Artikel über Optimierung der Token-Kosten von LLM. Semantischer Cache und Klassifizierung und Routing von KI-Anfragen funktionieren gut als gemeinsame Schicht vor dem Modell-Router, wie wir auch in der Analyse der Kosten für die Wartung eines KI-Agenten beschreiben.

Beginne mit 0,94 und teste an einem Datensatz von 50-100 Paaren mit manuell bewerteter Relevanz. Wenn die False-Positive-Rate 2% überschreitet, erhöhe auf 0,96. Liegt die Hit-Rate unter 20% und es gibt wenig Rauschen in den Daten, probiere 0,92. Es gibt keinen universellen Wert für alle Szenarien.

Mit Einschränkungen. Das Caching des gesamten Gesprächskontexts ist unpraktisch (niedrige Hit-Rate, große Schlüssel). Effektiver ist es, nur die erste Anfrage in einer Sitzung oder faktografische Fragen (FAQ-ähnlich) zu cachen, die im Gespräch auftauchen und nicht von vorherigen Interaktionen abhängen.

Führe zwei Zähler: Gesamtzahl der Anfragen an das System und Anzahl der Anfragen, die an das Modell weitergeleitet werden. Hit-Rate = (Anfragen aus Cache / alle Anfragen). Kosten ohne Cache = alle Anfragen × durchschnittliche Token-Kosten. Kosten mit Cache = weitergeleitete Anfragen × Token-Kosten + feste Infrastrukturkosten des Caches (Embedding + Vektordatenbank). Die Differenz ist die tatsächliche Einsparung, verglichen mit den Kosten für die Wartung der zusätzlichen Komponente.

Antworten, die in den Cache gelangen, sollten keine personenbezogenen Daten enthalten (Namen, Bestellnummern, Adressen konkreter Nutzer). Der Cache eignet sich für generische Antworten (Richtlinien, Verfahren, FAQ). Personalisierte Anfragen mit Benutzerdaten sollten den Cache umgehen oder mit einem Schlüssel pro User-ID und einem TTL gemäß der Aufbewahrungsrichtlinie gecacht werden. Führe eine DPIA bei jedem Szenario durch, in dem die Antwort indirekt sensible Daten enthalten könnte.

Nein. RAG sucht Wissensdokumentfragmente als Kontext für die Modellantwort. Ein semantischer Cache speichert fertige Antworten und gibt sie ohne Modellbeteiligung bei ähnlichen Fragen zurück. Beide Technologien können zusammenarbeiten: RAG liefert das Wissen für die erste Antwort, und der Cache speichert diese Antwort für nachfolgende identische Fragen. Im Artikel über semantische Suche und Embeddings beschreiben wir die Vektorschicht, die beiden Ansätzen gemeinsam ist.