Warum Ihr Semantic Cache falsche Antworten liefert

Ein Nutzer berichtete, dass unser Übersetzungs-Plugin für jede Anfrage das gleiche zwischengespeicherte Ergebnis lieferte, unabhängig vom Input. Wir untersuchten das Problem und fanden etwas Schlimmeres: 95 % aller semantischen Cache-Treffer auf unserer Plattform waren falsch-positive Ergebnisse. 199 verschiedene Übersetzungsanfragen, 198 eindeutige Anfrage-Bodys, eine einzige zwischengespeicherte Antwort für alle.

Wenn Sie sich für langlebigen Agent-Status und die Verarbeitung von Produktionsanfragen interessieren, ergänzt dieser Beitrag gut die Artikel Why Your AI Agent Keeps Losing Its Memory, den One-Key-Chatbot-Guide und den AI API Rate-Limiting-Guide.

Die wichtigsten Erkenntnisse

• 95 % der semantischen Cache-Treffer auf der Plattform waren falsch-positiv; 198 eindeutige Anfragen erhielten alle dieselbe zwischengespeicherte Antwort.
• Die Grundursache ist strukturierter Input. Fester Vorlagentext dominiert den Embedding-Vektor, sodass variierender Inhalt die Kosinus-Ähnlichkeit kaum beeinflusst.
• Eine Erhöhung des Ähnlichkeitsschwellenwerts löst das Problem nicht, da sich die Verteilungen korrekter und inkorrekter Treffer überschneiden. Aktuelle Forschung zur Zuverlässigkeit semantischer Caches bestätigt dieses Muster.
• Die Lösung erfolgt in zwei Schichten: Extrahieren Sie aussagekräftige Inhalte vor dem Embedding und verifizieren Sie dann jeden Treffer mit einem schnellen FNV-1a-Fingerprint-Hash. Dies senkte die falsch-positiven Ergebnisse von etwa 95 % auf unter 5 %.
• Die Modellwahl beeinflusst die Anfälligkeit. Lange System-Prompts und in JSON verpackte Inputs verschlimmern das Problem, unabhängig davon, welches Modell die Vervollständigung liefert; prüfen Sie das Modellverzeichnis von TokenLab (Stand 07.07.2026) für aktuelle Modelloptionen, wenn Sie entscheiden, welche Modelle für gecachten Traffic genutzt werden sollen.

Der Bug-Report

Der Bericht war einfach: „Ich habe den semantischen Cache deaktiviert, aber jede Übersetzung liefert das gleiche Ergebnis.“

Drei Request-IDs, drei verschiedene Übersetzungssegmente, identische zwischengespeicherte Antworten. Die Anfrage-Bodys reichten von 1.564 bis 8.676 Bytes. Die ID der zwischengespeicherten Antwort war bei allen gleich: chatcmpl-DG6J03nhdvcF7Ek0C8rJkjh7lN9pF.

Erster Verdacht: Die Cache-Einstellungen des Nutzers wurden nicht angewendet. Dies stellte sich als separater Synchronisationsfehler der Datenquelle heraus (das Admin-Panel schrieb in eine Tabelle, das API-Gateway las aus einer anderen). Dies zu beheben löste nur die halbe Miete. Selbst mit aktiviertem und korrekt funktionierendem Cache ordnete der semantische Cache Anfragen zu, die niemals hätten übereinstimmen dürfen.

Die Produktionsdaten

Wir haben 24 Stunden Cache-Treffer-Daten aus ClickHouse ausgewertet. Die Zahlen waren schlecht.

Modell	Gesamt-Anfragen	Cache-Treffer	Eindeutige Anfragen	Eindeutige Antworten	Trefferquote
DeepSeek V4 Flash	200	199	198	1	99,5 %
glm-4.6-thinking	100	38	13	1	38 %
gpt-5-nano	31	29	28	2	93,5 %
gpt-oss-120b	18	17	17	1	94,4 %
qwen3-vl-flash	17	16	16	1	94,1 %

198 eindeutige Übersetzungsanfragen, die alle dieselbe einzelne zwischengespeicherte Antwort zurückgeben. Das ist kein Cache. Das ist eine defekte Funktion, die eine Konstante zurückgibt.

Jedes betroffene Modell teilte zwei Merkmale: Alle Anfragen stammten von einem einzigen Nutzer und alle verwendeten eine feste System-Prompt-Vorlage mit variierendem Nutzerinhalt. Eine aktuelle Liste der auf der Plattform verfügbaren Modelle finden Sie im Modellverzeichnis von TokenLab (Stand 07.07.2026), da sich das Angebot häufig ändert.

Wie Sie dies in Ihrem eigenen System erkennen

Sie brauchen unsere Logs nicht, um herauszufinden, ob Sie das gleiche Problem haben. Das schnellste Signal ist die Antwortvielfalt pro Modell. Wenn ein Modell eine hohe Cache-Trefferquote, aber fast keine eindeutigen Antworten hat, liefern Sie eine Antwort auf viele verschiedene Fragen.

Hier ist die verallgemeinerte ClickHouse-Abfrage, die wir verwendet haben:

SELECT
  model,
  count() AS total_hits,
  uniqExact(substring(response_body, 1, 200)) AS unique_responses,
  round(uniqExact(substring(response_body, 1, 200)) / count(), 3) AS diversity_ratio
FROM request_logs
WHERE cache_hit = true
GROUP BY model
ORDER BY total_hits DESC;

Ein gesunder Cache hat eine diversity_ratio nahe 1,0, was bedeutet, dass die meisten Treffer unterschiedliche Antworten für unterschiedliche Inputs liefern. Ein Verhältnis nahe 0 bedeutet, dass viele Anfragen auf eine Handvoll zwischengespeicherter Antworten kollabieren. Alles unter etwa 0,5 bei einem Modell mit echter Input-Vielfalt ist untersuchungswürdig.

Wenn Sie Antwort-Bodys nicht protokollieren, funktioniert auch ein günstigerer Proxy: Vergleichen Sie die Anzahl der eindeutigen Anfrage-Bodys mit der Anzahl der eindeutigen Antworten aus dem Cache. Wenn 198 eindeutige Anfragen auf 1 Antwort mappen, gleicht der Cache nicht die Bedeutung ab, sondern das Boilerplate.

Ein zweites Warnsignal sind Nutzerbeschwerden, die sich bei strukturierten Arbeitslasten häufen. Übersetzungs-Plugins, Zusammenfassungs-Tools, Formular-Ausfüller und JSON-in/JSON-out-Tools sind die üblichen Verdächtigen, da sie variablen Inhalt in eine feste Vorlage verpacken.

Warum Embeddings bei strukturiertem Input versagen

Das Übersetzungs-Plugin sendet Anfragen wie diese:

System: "Act as a translation API. Output a single raw JSON object only.
         Input: {"targetLanguage":"<lang>","title":"...","segments":[...]}"

User:   {"targetLanguage":"zh","title":"Product Page",
         "description":"Translate product descriptions",
         "tone":"formal",
         "segments":[{"text":"actual varying content here"}]}

Der System-Prompt ist bei allen Anfragen identisch. Die User-Nachricht ist ein JSON-Objekt, bei dem targetLanguage, title, description und tone fest sind. Nur segments[].text ändert sich.

Wenn unser semantischer Cache Text für das Embedding extrahiert, verkettet er den System-Prompt und die User-Nachricht. Die feste Vorlage macht etwa 80 % des Textes aus. Das Embedding-Modell (all-mpnet-base-v2, 768 Dimensionen) komprimiert dies in einen Vektor, in dem die Vorlagenstruktur dominiert. Der eigentliche Übersetzungsinhalt verändert das Ergebnis kaum.

Ergebnis: Die Kosinus-Ähnlichkeit zwischen „translate 'Hello world'“ und „translate 'The quarterly financial report shows a 15% increase in revenue'“ übersteigt 0,95. Unser Schwellenwert liegt bei 0,95. Jede Übersetzungsanfrage stimmt mit dem ersten zwischengespeicherten Eintrag überein.

Beim Durchsuchen der Logs fanden wir drei Wege, wie dies fehlschlägt:

Das Übersetzungs-Plugin ist der größte Übeltäter. Feste JSON-Schlüssel und -Werte übertönen die tatsächlichen Übersetzungssegmente. DeepSeek V4 Flash und gpt-5-nano sind beide davon betroffen.

Ein Assistent zur Zusammenfassung von Kontexten hatte eine andere Variante desselben Problems. Sein System-Prompt war so lang, dass der Nutzerinhalt, der von 5 KB bis 47 KB reichte, im Embedding kaum registriert wurde. So kam es, dass glm-4.6-thinking für jede Konversation dieselbe Zusammenfassung lieferte.

Das dritte Muster war subtiler. Bei gpt-oss-120b und qwen3-vl-flash waren die ersten 500 Zeichen jeder Anfrage Byte für Byte identisch. Der variierende Inhalt kam danach, aber das Embedding wurde bereits durch das gemeinsame Präfix dominiert.

Was die Forschung sagt

Dies ist kein neues Problem. Aktuelle Studien haben es quantifiziert.

Das vCache-Projekt der UC Berkeley fand heraus, dass sich die Ähnlichkeitsverteilungen von korrekten und inkorrekten Cache-Treffern stark überschneiden. Das bedeutet, dass kein fester Schwellenwert eine echte Übereinstimmung sauber von einer strukturell ähnlichen, aber falschen trennt. Diese Erkenntnis deckt sich genau mit dem, was wir in der Produktion gesehen haben: Die falsch-positiven Ergebnisse des Übersetzungs-Plugins häuften sich über 0,95, genau in dem Bereich, in dem auch legitime Paraphrasen liegen.

Andere aktuelle Arbeiten zur Zuverlässigkeit semantischer Caches kommen zu ähnlichen Schlussfolgerungen: Die rohe Embedding-Ähnlichkeit ist ein notwendiges, aber kein hinreichendes Signal für die Cache-Korrektheit. Jedes Produktionssystem, das sich allein darauf verlässt, muss bei strukturiertem, vorlagenlastigem Traffic mit einer signifikanten Rate an falsch-positiven Ergebnissen rechnen.

Die Zwei-Schichten-Lösung

Schicht 1 ist die Inhaltsextraktion. Entfernen Sie vor dem Embedding den festen System-Prompt und das Vorlagen-Gerüst und betten Sie nur die variable Nutzlast ein: den tatsächlichen segments[].text-Inhalt, nicht die umgebenden JSON-Schlüssel und Boilerplate. Dies allein erhöht das Signal-Rausch-Verhältnis im Embedding-Vektor drastisch.

Schicht 2 ist die Fingerprint-Verifizierung. Selbst mit besserer Extraktion können nahezu identische Inhalte hohe Ähnlichkeitswerte erzeugen. Berechnen Sie vor der Auslieferung eines Cache-Treffers einen schnellen Hash (wir verwendeten FNV-1a) über den extrahierten Inhalt sowohl der eingehenden Anfrage als auch des zwischengespeicherten Eintrags. Wenn die Hashes exakt übereinstimmen, liefern Sie den Cache aus. Wenn nicht, führen Sie entweder eine neue Vervollständigung durch oder leiten Sie bei wertvollerem Traffic einen günstigen Verifizierungsaufruf ein, der die Bedeutung bewertet, nicht die Bytes.

Der Fehler besteht darin, die Verifizierung komplett zu überspringen und der rohen Kosinus-Ähnlichkeit zu vertrauen. Jeder Ansatz in der Tabelle schlägt das. Beginnen Sie mit dem günstigsten, der zu Ihrem Abfragetyp passt, und gehen Sie erst die Leiter hinauf, wenn Sie echte verpasste Paraphrasen messen.

Zusammen senkten diese beiden Schichten unsere Falsch-Positiv-Rate bei dem betroffenen Traffic von etwa 95 % auf unter 5 %.

Wann semantisches Caching das falsche Werkzeug ist

Caching ist keine kostenlose Technik, und manche Arbeitslasten sind es gar nicht wert, gecacht zu werden.

• Traffic mit hoher Kardinalität und geringer Wiederholungsrate. Wenn fast jede Anfrage einzigartig ist, z. B. bei einmaliger kreativer Generierung, ist die Trefferquote zu niedrig, um den Embedding-Overhead zu rechtfertigen. Sie zahlen für das Embedding von allem und profitieren selten davon.
• Ausgaben, die aktuell sein müssen. Alles, was zeitkritisch ist, Live-Daten, personalisierte Ergebnisse, alles mit einem „heute“ darin, kann veraltete Antworten aus dem Cache liefern, selbst wenn die Übereinstimmung technisch korrekt ist. Die Antwort war vor einer Stunde richtig und ist es jetzt nicht mehr.
• Bereiche mit strenger Korrektheitsanforderung. Bei medizinischen, rechtlichen oder finanziellen Antworten kann ein einziges falsch-positives Ergebnis schlimmer sein als die eingesparten Kosten. Wenn Sie hier cachen, ist die Verifizierungsschicht obligatorisch, nicht optional, und eine Prüfung auf LLM-Niveau könnte die einzig akzeptable sein.
• Winzige Prompts, bei denen der Modellaufruf bereits günstig ist. Embedding, Ähnlichkeitssuche und Verifizierung haben ihre eigenen Kosten. Wenn die zugrunde liegende Vervollständigung nur ein paar hundert Token bei einem günstigen Modell kostet, kann Caching mehr kosten, als es einspart.

Caching glänzt bei repetitiven, vorlagenlastigen, teuren Vervollständigungen – genau den Arbeitslasten, bei denen ein falsch-positives Ergebnis auch am einfachsten einzuführen ist. Diese Spannung ist der Grund, warum die Verifizierungsschicht wichtig ist. Wenn Ihr Ziel hauptsächlich die Kostenkontrolle ist, lohnt es sich, Caching auch mit günstigem Modell-Routing zu kombinieren. Der Preisvergleich und der Guide zu den besten KI-Modellen für Coding zeigen, wo die Einsparungen pro Token tatsächlich herkommen, und das Modellverzeichnis von TokenLab (Stand 07.07.2026) zeigt aktuelle Optionen, einschließlich kostengünstiger Routing-Auswahlen wie DeepSeek V4 Flash und Gemini 3.5 Flash, falls Sie abwägen, welches Modell für gecachten versus nicht gecachten Traffic genutzt werden soll. Überprüfen Sie die aktuellen Preise im verlinkten Verzeichnis, bevor Sie sich für einen Routing-Plan entscheiden.

Warum nicht einfach den Schwellenwert erhöhen?

Unser Schwellenwert liegt bereits bei 0,95. Ihn zu erhöhen hilft nicht. Das Problem ist, dass strukturell ähnliche Inputs Ähnlichkeitswerte über 0,95 erzeugen, egal was der eigentliche Inhalt sagt.

Die Daten von vCache untermauern dies: Die Ähnlichkeitsverteilungen korrekter und inkorrekter Treffer überschneiden sich so stark, dass kein einzelner Cutoff sie trennt. Schieben Sie den Schwellenwert auf 0,99, und Sie eliminieren legitime Cache-Treffer für echte Paraphrasen, während strukturell identische Anfragen, wie unsere JSON-Übersetzungs-Payloads, weiterhin über 0,99 liegen werden, unabhängig vom Inhalt. Der Schwellenwert ist nicht der Hebel. Die Input-Repräsentation ist es. Deshalb funktionieren Schicht 1 (Inhaltsextraktion) und Schicht 2 (Fingerprint-Verifizierung), wo eine Schwellenwerterhöhung versagt: Sie ändern, was verglichen wird, nicht wie streng der Vergleich ist.

Wenn Sie einen semantischen Cache aufbauen oder warten, behandeln Sie den Schwellenwert als groben Filter, nicht als Korrektheitsgarantie. Kombinieren Sie ihn mit Inhaltsextraktion, damit das Embedding tatsächlich den variablen Teil der Anfrage repräsentiert, und fügen Sie dann einen günstigen Verifizierungsschritt hinzu, damit ein fast passender Embedding-Treffer niemals unbemerkt zu einer falschen Antwort in der Produktion werden kann.

Beginnen Sie mit dem Modellverzeichnis von TokenLab, um aktuelle Preise und Benchmarks über Frontier-, Coding- und Low-Cost-Routing-Modelle zu vergleichen, bevor Sie Ihre Cache-Verifizierungsschicht verdrahten. Welches Modell auch immer hinter Ihrem Vervollständigungs-Endpunkt steht, der Extraktions-plus-Fingerprint-Ansatz ist das, was falsch-positive Ergebnisse tatsächlich behebt.

FAQ

Behebt eine Erhöhung des Ähnlichkeitsschwellenwerts falsch-positive Ergebnisse im semantischen Cache? Nein. Forschung von vCache und verwandte Studien zeigen, dass sich die Verteilungen korrekter und inkorrekter Treffer über den gesamten Schwellenwertbereich überschneiden. Eine Erhöhung des Cutoffs blockiert daher legitime Übereinstimmungen, ohne strukturell ähnliche, aber semantisch unterschiedliche Anfragen zuverlässig herauszufiltern.

Was ist der günstigste Weg, einen semantischen Cache-Treffer zu verifizieren? Ein Fingerprint-Hash (FNV-1a oder ähnlich) über den extrahierten, aussagekräftigen Inhalt fügt weniger als eine Millisekunde Latenz hinzu und ist kostenlos zu berechnen. Er erkennt keine Paraphrasen, eliminiert aber exakte falsch-positive Ergebnisse wie die hier beschriebenen, was die Hauptursache für Schäden bei strukturierten Arbeitslasten ist.

Hängt dieses Problem davon ab, welches Modell die Vervollständigung liefert? Nein, das Falsch-Positiv-Problem liegt in der Embedding- und Matching-Schicht, nicht im Vervollständigungsmodell. Jedes Modell hinter einem semantischen Cache, ob DeepSeek V4 Flash, glm-4.6-thinking oder etwas Neueres, wird auf die gleiche Weise beeinflusst, wenn der Cache festen Vorlagentext zusammen mit variablem Inhalt einbettet. Prüfen Sie das Modellverzeichnis von TokenLab (Stand 07.07.2026) auf aktuelle Modellverfügbarkeit, wenn Sie entscheiden, welche Modelle durch eine gecachte Pipeline geroutet werden sollen.