Was ist Semantic Caching?
„Was kostet der Versand?“ und „Wie hoch sind die Lieferkosten?“ sind dieselbe Frage. Ein normaler Zwischenspeicher, auch Cache genannt, sieht zwei verschiedene Texte. Semantic Caching erkennt: Das meint dasselbe, die Antwort liegt schon vor.
So läuft es ab:
- Die Anfrage wird in ein Embedding übersetzt, also eine Zahlenreihe, die ihre Bedeutung abbildet.
- Das System sucht im Speicher nach der ähnlichsten früheren Anfrage.
- Liegt der Wert über der eingestellten Schwelle, kommt die gespeicherte Antwort zurück.
- Sonst antwortet das Sprachmodell normal, und das Ergebnis wandert in den Speicher.
Das spart den ganzen Aufruf des Modells, also Kosten und Wartezeit. Der Preis dafür: Redis beschreibt offen, dass du die Garantie aufgibst, dass ein Treffer immer stimmt.
Semantic Caching oder Prompt Caching?
Die beiden klingen gleich, tun aber etwas anderes:
Merkmal
Prompt Caching
Semantic Caching
Treffer
Exakt gleich
Ähnlich
Modell
Antwortet neu
Wird übersprungen
Ersparnis
Teil der Eingabe
Ganzer Aufruf
Falsche Treffer
Nein
Ja
Beides lässt sich kombinieren. RAG ist wieder etwas anderes: Es holt Wissen als Eingabe, das Modell antwortet trotzdem. Und der Seiten-Cache deiner Website hat mit all dem nichts zu tun.
Die Schwelle entscheidet
Die wichtigste Einstellung ist die Ähnlichkeitsschwelle. Zu locker heißt falsche Antworten, zu streng heißt kaum Treffer. Redis LangCache startet mit 0,85 und empfiehlt als Anfang 0,8 bis 0,9. Eine allgemeine FAQ verträgt lockerere Werte als Fragen zu Vertrag oder Geld.
Was bringt das? Im Test von AWS mit 63.796 Chatbot-Anfragen sanken die Modellkosten um bis zu 86 %, die Latenz im Schnitt um bis zu 88 %. Das sind Bestwerte eines Anbieters mit öffentlichem Datensatz. Ein zurückhaltenderes Bild gibt die MeanCache-Studie: Dort ähnelten rund 31 % der Anfragen von 20 ChatGPT-Nutzern früheren Fragen. Live-Messungen aus Marketing-Projekten habe ich nicht gefunden. Rechne also mit deinem eigenen Verkehr, nicht mit Prospektwerten.
Häufige Fehler
Fehler 1 · Jeden Treffer für korrekt halten
„Kann ich stornieren?“ und „Kann ich nicht stornieren?“ liegen sprachlich nah beieinander. Ein Cache erkennt solche Feinheiten nicht zuverlässig. Prüf Stichproben von Treffern.
Fehler 2 · Folgefragen ohne Kontext
„Und was kostet das?“ hängt ganz vom Gespräch davor ab. Im MeanCache-Test mit 100 solcher Folgefragen, die nicht treffen durften, lieferte GPTCache 54 falsche Treffer. MeanCache schaffte 3, das Paper vergleicht allerdings zugunsten des eigenen Systems.
Fehler 3 · Keine Trennung nach Kunde oder Produkt
Ohne Filter landet die Antwort für Firma A bei Firma B. Trenne den Speicher nach Mandant, Produkt und Region. Azure und Redis bieten dafür Attribute an.
Fehler 4 · Zeitkritisches zu lange aufheben
Eine Antwort zu Preisen oder Verfügbarkeit veraltet schnell. Redis rät bei Echtzeitdaten zu einer Lebensdauer von 15 bis 30 Minuten, bei FAQ zu Tagen bis Wochen.
Wann es sich lohnt
Gut passt Semantic Caching, wenn viele Menschen ähnliche Fragen stellen und die Antwort nicht von der Person abhängt. Das sind vor allem FAQ-Bots und Support für Standardfragen. Schlecht passt es bei persönlichen Daten, bei kreativen Texten, wo du Abwechslung willst, und bei langen Gesprächen.
- Erst messen: Wie viele Anfragen wiederholen sich wirklich? Eine Woche Logs reicht als Anhaltspunkt.
- Streng starten: Lockere die Schwelle schrittweise und beobachte Fehltreffer.
- Lebensdauer setzen: Jede Antwort bekommt ein Ablaufdatum.
- Wechselnde Inhalte ausschließen: Preise, Bestände und alles Persönliche bleiben draußen.
Fertige Lösungen sind Redis LangCache und RedisVL, Azure API Management, Google Apigee sowie Amazon ElastiCache mit Bedrock. GPTCache war lange der Einstieg, unterstützt laut eigener Seite aber keine neuen Modelle mehr.
Häufige Fragen
Was ist der Unterschied zu Prompt Caching?
Prompt Caching braucht einen exakt gleichen Textanfang und spart bei der Eingabe, das Modell antwortet aber neu. Semantic Caching erkennt ähnliche Fragen und überspringt das Modell ganz. Das spart mehr, kann dafür falsch treffen.
Welche Schwelle ist die richtige?
Eine allgemeine gibt es nicht. Redis empfiehlt für LangCache den Start zwischen 0,8 und 0,9. Du musst sie an echten Anfragen prüfen, weil der Wert vom Embedding-Modell und von deinem Thema abhängt.
Kann der Cache falsche Antworten liefern?
Ja, das ist das Grundrisiko. Zwei ähnliche Fragen können unterschiedliche Antworten brauchen. Schütze dich mit strenger Schwelle, Trennung nach Produkt und Kunde sowie Stichproben.
Wie viel spart Semantic Caching wirklich?
Das hängt davon ab, wie oft sich Anfragen wiederholen. Der AWS-Test erreichte bis zu 86 % geringere Modellkosten, das ist ein Bestwert. Hinzu kommen Kosten für Embeddings und den Speicher. Miss deshalb selbst.
Lohnt sich das für kleine Anwendungen?
Meist nicht. Die Technik braucht Pflege, und bei wenig Verkehr fällt die Ersparnis klein aus. Sinnvoll wird es, wenn ein Bot viele gleichartige Fragen bekommt.
