Semantisches Caching für LLM-Apps: wann Antworten wiederverwenden sicher ist und wann nicht

Support-Assistenten und FAQ-Bots beantworten immer wieder dieselben Fragen: Wie setze ich mein Passwort zurück, wo ist meine Rechnung, wie lange dauert die Lieferung. Jede dieser Fragen kostet einen Modellaufruf. Ein semantischer Cache speichert die Antwort beim ersten Mal und liefert sie, wenn eine spätere Frage dasselbe meint, auch wenn sie anders formuliert ist. Gut gemacht, entfällt ein großer Teil der Aufrufe und die Antwort kommt in Millisekunden. Nachlässig gemacht, liefert er selbstsichere Antworten auf Fragen, die niemand gestellt hat.

Dieser Artikel trennt semantisches Caching vom Prompt-Caching der Anbieter, zeigt die Architektur und verbringt die meiste Zeit mit den Teilen, die über die Sicherheit entscheiden: Schwelle, Cache-Bereich, was man nicht cachen sollte und Invalidierung.

Was unterscheidet semantisches Caching vom Prompt-Caching?

Die Dokumentation zum Prompt-Caching von Claude sagt klar, dass Treffer zu 100 % identische Prompt-Abschnitte verlangen und das Caching die Ausgabe nicht beeinflusst. Das ist von Haus aus sicher, und man sollte es zuerst einschalten; mehr dazu in Prompt-Caching und Modell-Routing. Ein semantischer Cache sitzt vor dem Modell und ist eine andere Art Entscheidung, denn er ändert, was der Nutzer bekommt.

Wie funktioniert ein semantischer Cache?

Bibliotheken wie GPTCache teilen das in einen Embedding-Generator, einen Speicher für Antworten, einen Vektorspeicher für Fragen und einen Similarity Evaluator, der entscheidet, ob ein Kandidat passt. Eine Bibliothek braucht man dafür nicht: Eine Embedding-Tabelle mit Vektorindex in Postgres, etwa pgvector, und zwanzig Zeilen Code reichen.

# Illustrative semantic cache on Postgres + pgvector
def cached_answer(question: str, scope: dict) -> str:
    q = normalize(question)
    vec = embed(q)                                       # same model for writes and reads
    row = db.fetchone("""
        SELECT answer, 1 - (embedding <=> %(v)s) AS sim
        FROM answer_cache
        WHERE tenant = %(tenant)s AND lang = %(lang)s AND data_version = %(ver)s
          AND expires_at > now()
        ORDER BY embedding <=> %(v)s LIMIT 1""", {"v": vec, **scope})
    if row and row.sim >= THRESHOLD:
        metrics.hit(row.sim)
        return row.answer
    answer = call_model(question, scope)
    if cacheable(question, answer):
        db.execute("INSERT INTO answer_cache (...) VALUES (...)")   # with expires_at = now() + ttl
    return answer

Wie viel spart ein semantischer Cache?

Das Paper zu GPT Semantic Cache speicherte Anfrage-Embeddings in Redis und testete repetitive, kundenservice-ähnliche Anfragen. Es berichtet bis zu 68,8 % weniger API-Aufrufe, Trefferquoten zwischen 61,6 % und 68,8 % je nach Kategorie und korrekte Treffer, also Treffer mit richtiger Antwort, von über 97 %. Diese Zahlen stammen aus bewusst repetitivem Traffic. Eine Produkt-FAQ sieht so aus; ein offener Assistent oder ein Coding-Tool nicht und wird nur einen Bruchteil der Treffer sehen.

Vor dem Bauen messen: eine Woche Fragen loggen, einbetten und zählen, wie viele einen nahen Nachbarn haben, den ein Mensch als dieselbe Frage akzeptieren würde. Diese Zahl ist die Obergrenze.

Wie wählt man die Ähnlichkeitsschwelle?

Embedding-Ähnlichkeit misst das Thema, nicht die Absicht. Wie storniere ich meine Bestellung? und Wie kündige ich mein Abo? liegen im Vektorraum sehr nah und brauchen verschiedene Antworten. Kann ich geöffnete Artikel zurückgeben? und Kann ich ungeöffnete Artikel zurückgeben? unterscheiden sich um eine Vorsilbe und haben gegensätzliche Antworten. Eine auf durchschnittliche Ähnlichkeit getrimmte Schwelle liefert die eine für die andere.

1. Einige hundert Paare echter Fragen sammeln und jedes labeln: gleiche oder andere Antwort. Die kniffligen Negativbeispiele bewusst aufnehmen.
2. Die Ähnlichkeit jedes Paars mit dem Embedding-Modell berechnen, das in Produktion läuft.
3. Die niedrigste Schwelle wählen, bei der falsche Treffer bei oder nahe null bleiben, und die daraus folgende Trefferquote akzeptieren.
4. Die Prüfung bei jedem Wechsel des Embedding-Modells wiederholen, denn Ähnlichkeitsskalen unterscheiden sich zwischen Modellen.

Eine zweite Prüfung hilft im Grenzbereich: Bei Treffern knapp über der Schwelle ein kleines, günstiges Modell fragen, ob beide Fragen dieselbe Antwort haben. Das kostet weit weniger als die Antwort zu erzeugen und entfernt die meisten Beinahe-Treffer.

Wie verhindert man, dass ein semantischer Cache Daten preisgibt?

Ein Cache ist gemeinsamer Speicher zwischen Nutzern. Wird die Antwort auf Wie hoch ist mein aktueller Rabatt? ohne Kundennummer im Schlüssel gecacht, bekommt der nächste Kunde den Rabatt des ersten. Jede Abfrage nach allem trennen, wovon die Antwort abhängt:

• Mandant und bei persönlichen Antworten der Nutzer. Oder persönliche Antworten ganz vom Cache ausschließen.
• Sprache, damit eine deutsche Frage keine gecachte englische Antwort bekommt.
• Rolle oder Berechtigungsstufe, wenn interne Mitarbeitende mehr sehen als Kunden.
• Daten- und Prompt-Version: Eine neue Preisliste, ein neuer Richtlinientext oder System-Prompt sollte einen frischen Cache-Namensraum starten.

Gecachte Antworten mit personenbezogenen Daten sind gespeicherte personenbezogene Daten, mit den entsprechenden Löschpflichten; siehe PII-Redaktion in LLM-Pipelines. Ein Cache ist außerdem ein Schreibweg: Können Nutzer beliebige Modellausgaben speichern lassen, die anderen ausgeliefert werden, kann sich eine per Prompt Injection manipulierte Antwort verbreiten. Nur Antworten aus vertrauenswürdigen Abläufen speichern und nie aus Sitzungen, die die Guardrails markiert haben.

Wie lässt man gecachte Antworten ablaufen und invalidiert sie?

Drei Mechanismen kombinieren. Eine TTL für jeden Eintrag, eher Stunden oder Tage als Monate. Eine Version im Cache-Schlüssel für Daten und Prompt, aus denen die Antwort stammt, damit eine Inhaltsänderung in einen frischen Namensraum wechselt, statt Zeilen einzeln zu löschen. Und eine manuelle Bereinigung pro Dokument: Ändert jemand die Rückgaberichtlinie, alle Einträge löschen, deren Antwort dieses Dokument zitiert hat. Dafür muss man die Quell-IDs mit jeder Antwort speichern, was sich für Zitate ohnehin lohnt, wie bei Grounding und Zitaten.

Was sollte man überwachen?

Cache-Treffer wie jeden anderen Schritt tracen, mit Ähnlichkeitswert und ID des Eintrags, damit sich eine falsche Antwort auf die Frage zurückführen lässt, für die sie ursprünglich erzeugt wurde; siehe Observability für LLM-Agenten.

Quellen

1. Regmi and Pun: GPT Semantic Cache: Reducing LLM Costs and Latency via Semantic Embedding Caching (2024)
2. Zilliz: GPTCache README (modules, similarity evaluation, eviction)
3. Claude Platform Docs: Prompt caching
4. pgvector README: vector types and indexes