Semantisches Caching
Semantisches Caching speichert frühere Modellantworten und verwendet sie wieder, wenn eine neue Anfrage einer vorherigen semantisch ähnlich ist – der Abgleich erfolgt über die Bedeutung mittels Embeddings, nicht über exakten Text. Dies senkt Kosten und Latenz bei sich wiederholenden oder nahezu identischen Abfragen, wie sie in der Produktion häufig vorkommen.
Problem
Viele Abfragen in der Produktion sind Paraphrasen bereits beantworteter Fragen, sodass die erneute Ausführung des vollständigen Modells für jede Anfrage unnötig Kosten und Latenz verursacht.
Wann zu verwenden
Verwenden Sie semantisches Caching, wenn der Traffic viele ähnliche oder wiederholte Fragen enthält und die Antworten stabil genug für eine Wiederverwendung sind – z. B. bei FAQs, im Support oder bei Dokumentations-Assistenten.
Lösung
Erstellen Sie ein Embedding für jede eingehende Anfrage und durchsuchen Sie einen Cache nach früheren Anfrage-Embeddings. Wenn ein ausreichend ähnlicher Eintrag existiert (oberhalb eines Ähnlichkeitsschwellenwerts), geben Sie die gespeicherte Antwort zurück; andernfalls rufen Sie das Modell auf und speichern Sie das neue Paar.
Stimmen Sie den Ähnlichkeitsschwellenwert sorgfältig ab: Ein zu niedriger Schwellenwert liefert falsche Antworten auf leicht unterschiedliche Fragen; ein zu strenger Schwellenwert verfehlt gültige Treffer. Fügen Sie TTLs und Invalidierungen hinzu, damit zwischengespeicherte Antworten nicht veralten.
Komponenten
Vorteile
- Geringere Kosten durch die Vermeidung wiederholter Modellaufrufe.
- Geringere Latenz bei Cache-Treffern.
- Konsistentere Antworten auf ähnliche Fragen.
Risiken
- Ein zu niedriger Schwellenwert liefert falsche zwischengespeicherte Antworten.
- Veralteter Cache ohne TTL oder Invalidierung.
- Personalisierte oder zeitkritische Antworten lassen sich schlecht zwischenspeichern.
Wann nicht zu verwenden
- Wenn die meisten Anfragen einzigartig sind.
- Wenn Antworten von aktuellen, benutzer- oder zeitspezifischen Daten abhängen.
- Wenn selbst geringfügige Abweichungen inakzeptabel sind.
Technologien
Beispiele
- Wiederverwendung der Antwort auf „Wie setze ich mein Passwort zurück“ über viele verschiedene Formulierungen hinweg.
- Zwischenspeichern häufiger Dokumentationsfragen in einem Support-Assistenten.
- Abkürzen von wiederholten, identischen Analysefragen.
Praxisbelege
- Kontext
- Lokale OpenClaw-Bereitstellung für einen einzelnen Operator, beobachtet über 57 Tage (161 Sitzungen / 2.776 Turns), aggregiert aus den eigenen Trajektorien-Traces des Agenten.
- Szenario
- Prompt- und Kontext-Caching ist mit `cache_control`-Markern sowie einem Workspace-Datei-Cache und einem Route-Cache implementiert, sodass wiederholte Strukturen aus dem Cache bedient werden.
- Technologie
- Anthropic `cache_control`-Injektion auf System und Nachrichten, OpenRouter-Passthrough, Workspace-Datei-Cache, Route-Cache und `cache_read`/`write`-Kostenabrechnung.
- Last
- Insgesamt 28,1 Mio. Token über 57 Tage, wovon ca. 19,6 Mio. als Cache-Read bedient wurden.
- Ergebnisse
- Etwa 70 % der Token wurden aus dem Cache bedient, wodurch die Mischkosten bei 15,21 $ pro 1 Mio. Token gehalten wurden (41 $ für Cache-Reads gegenüber 374 $ für neue Eingaben). Lokale Bereitstellung für einen einzelnen Operator – das Verhältnis spiegelt die Wiederholungsrate dieses Workloads wider; messen Sie Ihre eigene.
KPIs
- Cache-Hit-Rate
- Anteil der aus dem Cache bedienten Anfragen; der Hebel für Kosten- und Latenzeinsparungen.
- False-Hit-Rate
- Wie oft ein semantisch „ähnlicher“ Treffer eine falsche oder veraltete Antwort liefert – das zentrale Risiko beim Caching nach Bedeutung.
- Eingesparte Kosten und Latenz pro Treffer
- Vermeidbare Token und Zeit bei Cache-Treffern – der Vorteil, für den Sie das Risiko von False-Hits in Kauf nehmen.
- Kalibrierung des Ähnlichkeitsschwellenwerts
- Ob der Übereinstimmungsschwellenwert die Hit-Rate gegen False-Hits ausbalanciert; ein zu niedriger Schwellenwert schadet der Qualität, ein zu strenger verhindert Einsparungen.
Beobachtete Fehlermuster
- False-Hits: Zwei Anfragen sind im Embedding-Raum ähnlich, erfordern aber unterschiedliche Antworten, sodass der Cache eine falsche Antwort zurückgibt.
- Veraltung: Zwischengespeicherte Antworten veralten, während sich die zugrunde liegenden Fakten ändern.
- Fehlkalibrierung des Schwellenwerts: Ein zu niedriger Schwellenwert liefert falsche Antworten, ein zu strenger führt zu fast keinen Treffern.
- Cache-Poisoning: Eine fehlerhafte Antwort wird zwischengespeichert und anschließend wiederholt ausgegeben.
Lessons Learned
- Stimmen Sie den Ähnlichkeitsschwellenwert anhand des echten Datenverkehrs ab; er ist der entscheidende Parameter.
- Führen Sie kein Caching durch, wenn Aktualität oder Korrektheit kritisch sind, es sei denn, Sie haben eine Invalidierungsstrategie.
- Validieren oder stichprobenartig prüfen Sie Cache-Treffer, um falsche Übereinstimmungen zu erkennen, bevor die Benutzer es tun.
- Grenzen Sie Caches eng ein (pro Mandant, pro Kontext), um zu verhindern, dass falsche Antworten an andere Benutzer weitergegeben werden.
FAQs
- Wie unterscheidet sich dies von einem normalen Cache?
- Ein normaler Cache gleicht exakte Schlüssel ab; ein semantischer Cache gleicht die Bedeutung mithilfe von Embeddings ab, sodass auch umformulierte Fragen zu Treffern führen.
- Was ist das Hauptrisiko?
- Ein zu niedriger Ähnlichkeitsschwellenwert liefert eine zwischengespeicherte Antwort für eine Frage, die eigentlich anders ist. Stimmen Sie den Schwellenwert ab und validieren Sie ihn anhand des echten Datenverkehrs.
- Wie vermeide ich veraltete Antworten?
- Setzen Sie TTLs und invalidieren Sie Einträge, wenn sich die zugrunde liegenden Daten ändern; vermeiden Sie das Zwischenspeichern von personalisierten oder zeitkritischen Antworten.