Was ist Semantic Caching bei KI-Agenten? Ähnliche Anfragen wiederverwenden

Semantic Caching ist ein Verfahren, bei dem ein KI-System Anfragen nicht nach ihrem exakten Wortlaut, sondern nach ihrer Bedeutung vergleicht: Wurde eine inhaltlich gleiche Frage schon einmal beantwortet, gibt das System die gespeicherte Antwort direkt zurück, statt das Sprachmodell (LLM) erneut aufzurufen. Das reduziert Rechenkosten und Antwortzeiten, weil überflüssige Modellaufrufe entfallen.

Ein klassischer Cache (Zwischenspeicher) funktioniert nur bei exakt identischem Text. Fragt eine Person „Wie setze ich mein Passwort zurück?" und eine andere „Ich habe mein Passwort vergessen", erkennt ein klassischer Cache diese als verschiedene Anfragen – obwohl die Antwort dieselbe ist. Genau diese Lücke schließt Semantic Caching, indem es die Bedeutung der Anfragen vergleicht (LogicMonitor).

Wie Semantic Caching funktioniert

Der Ablauf besteht aus wenigen Schritten. Zunächst wird jede eingehende Anfrage in einen Vektor umgewandelt – eine Zahlenreihe, die die Bedeutung des Textes abbildet. Diese Zahlenreihen heißen Embeddings und haben typischerweise 768 oder 1.536 Dimensionen (Redis).

Anschließend vergleicht das System den neuen Vektor mit den bereits gespeicherten Vektoren. Als Maß dient meist die Kosinus-Ähnlichkeit, die den Winkel zwischen zwei Vektoren misst. Überschreitet die Ähnlichkeit einen festgelegten Schwellenwert – häufig zwischen 0,85 und 0,95 –, gilt die Anfrage als bedeutungsgleich, und das System liefert die gespeicherte Antwort zurück (Redis).

Jeder Cache-Eintrag besteht dabei aus drei Teilen: dem Vektor der Anfrage, der gespeicherten Antwort und einem Zeitstempel, der steuert, wann der Eintrag verfällt (DEV Community). Für die schnelle Suche nach ähnlichen Vektoren kommen Vektordatenbanken mit Index-Verfahren wie HNSW zum Einsatz (Emergent Mind). Der Cache sitzt in der Regel zwischen Anwendung und Sprachmodell und lässt sich mit gängigen LLMs von Anbietern wie OpenAI, Anthropic oder Cohere sowie mit Open-Source-Modellen nutzen (Redis).

Warum sich das für KI-Agenten lohnt

Der Nutzen liegt in zwei messbaren Größen: Kosten und Antwortzeit. Jeder LLM-Aufruf verursacht Token-Kosten und braucht Zeit. Wird ein großer Teil der Anfragen aus dem Cache bedient, sinken beide Werte deutlich.

In Q&A-Szenarien wie Unternehmenssuche oder Kundenservice fand ein Anbieter heraus, dass über 20 Prozent der Anfragen bedeutungsähnlich waren – diese ließen sich ohne erneuten Modellaufruf beantworten (Portkey). Ein Praxisexperiment mit einem IT-Helpdesk-Chatbot reduzierte die LLM-Inferenzkosten mit Semantic Caching um bis zu 86 Prozent (AWS).

Besonders relevant ist der Ansatz bei Agenten- und Workflow-Systemen. KI-Agenten formulieren während mehrstufiger Überlegungen oft ähnliche Teilfragen neu. Werden diese Zwischenanfragen zwischengespeichert, sinken Latenz und Token-Verbrauch über den gesamten Ablauf (LogicMonitor). Das ist ein Baustein, um die Retrieval-Latenz bei KI-Agenten im Griff zu behalten.

Semantic Caching in RAG-Systemen

In Retrieval-Augmented-Generation-Systemen – also KI, die vor der Antwort passende Dokumente aus einer Wissensbasis heraussucht – sitzt der Cache am Anfang der Verarbeitungskette. Findet er eine bedeutungsgleiche, bereits beantwortete Anfrage, wird der komplette Ablauf aus Vektorsuche, Kontextzusammenstellung und Modellaufruf übersprungen (DEV Community).

Das ist sinnvoll, weil sich Anfragen im Kundenservice häufig um dieselben Themen gruppieren. „Wie setze ich mein Passwort zurück?", „Ich kann mich nicht einloggen" und „Mein Konto ist gesperrt" verweisen oft auf dieselbe Lösung und lassen sich aus einer einzigen gespeicherten Antwort bedienen (LogicMonitor).

Abgrenzung: Semantic Caching, Prompt Caching und Embedding Caching

Diese drei Begriffe werden leicht verwechselt, meinen aber Unterschiedliches. Prompt Caching speichert identische Prompt-Anfänge wieder, um wiederholte Token-Arbeit zu sparen; es setzt exakte Übereinstimmung des Prompt-Beginns voraus. Semantic Caching dagegen nutzt Ähnlichkeit auf Bedeutungsebene, um Antworten über verschieden formulierte, aber inhaltsgleiche Anfragen hinweg wiederzuverwenden (Redis).

Vom Embedding Caching unterscheidet es sich ebenfalls: Dort werden berechnete Embeddings zwischengespeichert, um die Vektorberechnung nicht zu wiederholen. Semantic Caching speichert dagegen die fertige Antwort. In der Praxis lassen sich beide kombinieren.

Worauf man achten muss

Der größte Risikofaktor ist der Schwellenwert. Ist er zu niedrig gewählt, gibt der Cache eine Antwort für eine Anfrage zurück, die nur oberflächlich ähnlich ist – das führt zu falschen Ergebnissen. Ist er zu hoch, greift der Cache kaum, und der Nutzen verpufft. Der Schwellenwert braucht daher sorgfältige Abstimmung (Oracle).

Ein zweiter Punkt ist die Aktualität. Cache-Einträge brauchen ein Verfallsdatum (TTL, Time-to-live), damit veraltete Antworten nicht dauerhaft ausgeliefert werden – etwa nachdem sich eine Preisliste oder Richtlinie geändert hat. Und da Fehler hier leise auftreten – der Cache liefert einfach eine plausibel klingende, aber falsche Antwort –, ist Überwachung wichtig. Nachvollziehbarkeit über Traces hilft, Cache-Treffer und deren Qualität zu prüfen.

Für unsere AI-Mitarbeiter ist Semantic Caching ein technischer Baustein im Hintergrund: Er senkt Kosten und Antwortzeiten bei wiederkehrenden Fragen, ohne dass Nutzer davon etwas merken – sofern Schwellenwert und Verfallszeiten passend gesetzt sind.

Häufige Fragen

Wie unterscheidet sich Semantic Caching von einem normalen Cache?

Ein normaler Cache trifft nur bei exakt gleichem Text zu. Semantic Caching vergleicht dagegen die Bedeutung: Es wandelt Anfragen in Vektoren um und misst deren Ähnlichkeit. Dadurch erkennt es auch unterschiedlich formulierte, aber inhaltsgleiche Anfragen als denselben Fall.

Wie viel Kosten spart Semantic Caching?

Das hängt stark davon ab, wie oft ähnliche Anfragen vorkommen. Ein Anbieter berichtet, dass in Q&A-Szenarien über 20 Prozent der Anfragen bedeutungsähnlich waren (Portkey). In einem IT-Helpdesk-Experiment sanken die Inferenzkosten um bis zu 86 Prozent (AWS). Bei stark variierenden Einzelanfragen fällt der Effekt geringer aus.

Welcher Schwellenwert ist der richtige?

Als Orientierung nennen Anbieter Werte zwischen 0,85 und 0,95 für die Kosinus-Ähnlichkeit (Redis). Der passende Wert hängt vom Anwendungsfall ab: Wo falsche Antworten teuer wären, wählt man ihn hoch; wo Wiederverwendung im Vordergrund steht, etwas niedriger. In der Praxis wird er anhand echter Anfragen getestet und nachjustiert.

Funktioniert Semantic Caching mit jedem Sprachmodell?

Ja. Semantic Caching sitzt zwischen Anwendung und Modell und funktioniert mit verschiedenen LLMs, darunter Modelle von OpenAI, Anthropic und Cohere sowie Open-Source-Modelle (Redis). Es ist unabhängig vom konkreten Modell einsetzbar.

Kann der Cache falsche Antworten liefern?

Ja, das ist das zentrale Risiko. Ist der Schwellenwert zu niedrig, wird eine gespeicherte Antwort für eine nur scheinbar ähnliche Anfrage ausgegeben (Oracle). Zusätzlich können Einträge veralten, wenn kein Verfallsdatum gesetzt ist. Deshalb sind eine sorgfältige Schwellenwert-Wahl und Überwachung nötig.