Caching-Strategien für LLM-Systeme im Finanzwesen

Der günstigste Modellaufruf ist der, den man nie macht. In einem Finanz-LLM-System ist vieles, was wie Inferenz aussieht, in Wahrheit Wiederholung: dasselbe Policy-Dokument, das bei jeder Anfrage in den Kontext geladen wird, dieselbe Anreicherung, die neu berechnet wird, weil zwei Services kein Ergebnis geteilt haben. Caching entfernt diese Wiederholung auf drei Ebenen – und jede Ebene versagt auf andere Weise.

Der Grund zur Vorsicht: Ein Cache ist eine Korrektheits-Fläche, nicht bloß ein Kostenhebel. Eine falsche Antwort, die aus einem Cache ausgeliefert wird, ist schlimmer als eine falsch neu berechnete Antwort, denn sie ist billiger und schneller auszuliefern – und sie kommt bei jeder Wiederholung identisch zurück. Im Finanzwesen landet die Zahl hinter dieser Antwort in einer Entscheidung, einem Report oder einem Audit-Trail. Die Frage lautet also nie nur „trifft das zu?”, sondern „worauf genau bilde ich den Key, und was macht diesen Eintrag falsch?”.

Prompt-Caching: die kostenlose Ebene

Prompt-Caching liegt beim Anbieter. Du markierst ein stabiles Präfix des Prompts, und der Anbieter speichert den dafür berechneten Attention-State, sodass der nächste Aufruf mit demselben Präfix die erneute Verarbeitung dieser Tokens überspringt. In Finanz-Prompts ist das Präfix meist groß und statisch: System-Anweisungen, die Tool- und Funktions-Schemas, ein Ausschnitt einer Policy oder eine Konditionsübersicht, manchmal ein paar durchgerechnete Beispiele. Dieser Inhalt ändert sich zwischen den Anfragen nicht und umfasst oft Tausende Tokens. Dafür bei jedem Aufruf den vollen Input-Preis zu zahlen, ist Verschwendung.

Zwei Regeln machen sich hier bezahlt:

• Ordne den Prompt so, dass alles Statische am Anfang steht und alles Anfragebezogene am Ende. Der Cache matcht auf dem Präfix, sodass ein einziges variables Token weit oben das Ganze invalidiert. Setze Kunde, Konto, Stichtag und die abgerufenen Passagen ans Ende.
• Halte das Präfix byte-identisch. Ein neu generierter Timestamp, ein umsortierter JSON-Key oder ein Leerzeichen am Ende bricht den Match. Wenn du den System-Prompt templatest, friere das Template ein und injiziere Variablen erst nach der Cache-Grenze.

Diese Ebene solltest du zuerst aktivieren, weil sie dich nichts kostet zu bauen und nichts daran ändert, was das Modell sieht. Der Haken ist die kurze Time-to-Live auf Anbieterseite; ein Cache, der in ein paar Minuten abläuft, hilft nur bei stoßweisem Traffic. Bei gleichmäßiger Last ist es nahezu geschenktes Geld. Für einen nächtlichen Reprocessing-Job, der dasselbe Präfix hunderttausendfach trifft, ist es ein großer Kostenposten.

Semantic Caching: schnell, aber scharfkantig

Ein Semantic Cache speichert Antworten, deren Key die Bedeutung des Inputs ist statt seiner exakten Bytes. Du embeddest die eingehende Anfrage, suchst nach einem gespeicherten Eintrag innerhalb einer bestimmten Ähnlichkeitsdistanz und lieferst, falls du einen findest, dessen Antwort aus, ohne das Modell aufzurufen. Hier liegen die echten Latenz- und Kostengewinne – und hier schneiden sich Finanzteams auch in den Finger.

Die Falle: Ähnlicher Text bedeutet nicht dieselbe Antwort. Frage „Wie hoch ist der ausstehende Saldo auf diesem Konto?” für zwei verschiedene Kunden, und du erhältst einen Satz mit zwei verschiedenen korrekten Antworten – und das Embedding kann das Konto hinter den Worten nicht sehen. Zwei KYC-Fragen können in der Formulierung nahezu identisch sein und gegensätzliche korrekte Antworten haben, sobald sich der Betroffene ändert. Wenn das Embedding dein gesamter Key ist, lieferst du die Antwort des einen Kunden an einen anderen aus – das ist ein Leakage-Vorfall, kein Cache-Miss.

Der Key ist also niemals das Embedding allein. Er ist ein Composite:

• Zuerst eine harte Partitionierung. Mandant, Kunden- oder Entity-ID und Stichtag bzw. Datenversion gehen in eine Exact-Match-Komponente des Keys. Das Semantic Matching läuft nur innerhalb dieser Partition. Das verhindert außerdem, dass der Traffic eines Mandanten den Cache eines anderen aufwärmt – wichtig für Isolation und für die Audit-Story.
• Setze den Ähnlichkeitsschwellwert hoch und behandle Beinahe-Treffer als Misses. Für eine Marketing-FAQ ist ein lockerer Schwellwert in Ordnung. Für alles, was eine Zahl oder eine Entscheidung erzeugt, ist ein naher Nachbar eine andere Frage. Die Kosten eines False Hit sind hier eine falsche Zahl in einem Report – also verschiebe den Schwellwert in Richtung Neuberechnung.
• Pflege ein Eval-Set aus Paraphrasen-Paaren und bekannten Nicht-Matches und miss die False-Hit-Rate dagegen, bevor du den Schwellwert aufweitest. Ein Semantic Cache hat ein False-Positive-Budget genau wie ein Screening-Modell, und du solltest den Drift dieser Rate über die Zeit verfolgen.

Wo sich Semantic Caching sauber verdient, sind deterministische, referenzartige Fragen: Policy-Lookups, definitorische Anfragen, Klassifikationen über eine stabile Taxonomie. Bei allem, was Live-Kontostände liest, halte den Schwellwert eng oder überspringe diese Ebene und verlasse dich stattdessen auf Result Caching.

Result Caching: Key auf den Daten, nicht auf der Uhr

Result Caching speichert das fertige Output einer Pipeline, mit einem Key auf den exakten Inputs. Das ist die älteste Idee und die sicherste, und im Finanzwesen ist es meist die wichtigste, weil so viel Arbeit idempotent ist. Eine Transaktion anreichern, eine Entity auflösen, Felder aus einer Meldung extrahieren, ein Dokument gegen eine Policy scoren: Schick dieselben Inputs durch dieselbe Pipeline-Version, und du solltest denselben Output erhalten. Es zweimal zu berechnen ist reine Verschwendung.

Der Key ist die vollständige Determinante der Antwort, und ihn richtig hinzubekommen ist die ganze Aufgabe:

• Content-Hash des Inputs, nicht eine ID, die wiederverwendet werden kann. Wenn ein Dokument unter derselben ID mit anderen Bytes neu hochgeladen wird, liefert der ID-basierte Cache die alte Extraktion aus. Hashe den Inhalt.
• Pipeline-Version, Prompt-Version und Model-ID. Wenn du den Prompt änderst oder das Modell wechselst, sind alte Ergebnisse keine gültigen Antworten auf die neue Frage. Ein Versionssprung invalidiert sie ohne Flush.
• Der Daten-Snapshot oder die Ledger-Version, die die Berechnung gelesen hat. Das ist die Point-in-Time-Disziplin, die einen Cache ehrlich hält. Bilde den Key auf der Version der Quelle, und eine Restatement oder eine spät eintreffende Korrektur ändert den Key – sodass ein Reprocessing-Lauf keine Zahlen ausliefern kann, die vor der Korrektur berechnet wurden. Eine TTL allein rettet dich hier nicht; eine Fünf-Minuten-TTL liefert vier Minuten nach einer Buchung fröhlich einen veralteten Saldo zurück.

Result Caching liefert dir außerdem Lineage fast geschenkt. Weil der Key Input-Hash, Pipeline-Version, Modell und Daten-Snapshot kodiert, ist ein gecachter Eintrag ein Nachweis dessen, was genau einen bestimmten Output erzeugt hat. Wenn ein Freigeber oder ein Prüfer fragt, warum eine Zahl so ist, wie sie ist, ist der Cache-Key der Anfang dieser Antwort.

Über alle drei Ebenen hinweg ist die Disziplin dieselbe. Schreibe auf, was eine korrekte Antwort determiniert, packe all das in den Key, und lass alles, was du weggelassen hast, zu einem Bug werden, den du benennen kannst. Kosten und Latenz sind das, was du gewinnst. Korrektheit ist das, was du schützt – und im Finanzwesen ist diese Reihenfolge nicht verhandelbar.