Briefing-Generator Cache-Bug gefixt (Semantic-Cache-Hit auf aehnliche Prompts)

Ich habe kürzlich ein seltsames Verhalten in einem meiner Briefing-Generatoren beobachtet: Nutzer bekamen Ergebnisse, die nicht exakt zu ihren Eingaben passten. Der Schuldige war schnell gefunden: der Semantic Cache.

Um API-Kosten zu sparen und Latenzen zu senken, nutze ich vor meinem LLM-Gateway einen semantischen Cache. Dieser speichert Antworten und liefert sie bei ähnlichen Anfragen direkt aus, ohne das Sprachmodell neu zu befragen. Was bei allgemeinen Wissensfragen hervorragend funktioniert, wurde hier zum Problem. Der Generator erstellt spezifische Dokumente basierend auf Parametern wie Zielgruppe, Tonfall und Produktmerkmalen. Wenn sich nur ein kleines Detail im Prompt änderte – etwa "Zielgruppe: B2B" statt "B2C" – stufte der Cache die Anfragen oft immer noch als "semantisch gleichwertig" ein und lieferte ein veraltetes, falsches Briefing aus.

Die Lösung: Caching-Strategie anpassen

Für kreative oder stark parametrisierte Generatoren habe ich das semantische Caching entschärft. Stattdessen setze ich hier auf striktes Exact-Matching oder habe den Similarity-Threshold (den Schwellenwert für die Ähnlichkeit) drastisch nach oben korrigiert. Ein Prompt muss nun nahezu identisch sein, um einen Cache-Hit auszulösen. Zusätzlich werden kritische Dropdown-Parameter nun separat als eindeutiger Cache-Key verarbeitet, sodass eine kleine Änderung im Setup zwingend einen neuen LLM-Aufruf erzwingt.

Für das eigene Setup

* Auf den Use-Case achten: Semantic Caching ist ideal für FAQs oder Support-Bots. Bei präzisen Generatoren (Briefings, Code, Spezifikationen) ist es fehleranfällig. * Schwellenwerte justieren: Wenn semantisches Caching genutzt wird, muss der Similarity-Threshold für generative Aufgaben sehr hoch angesetzt werden. * Parameter isolieren: Binde kritische Variablen (wie Zielgruppe oder Format) direkt in den Cache-Key ein, anstatt nur den finalen Fließtext-Prompt vom Cache bewerten zu lassen.