LLM-Kosten sparen mit semantischer Caching-Strategie in Spring AI

LLM-APIs wie OpenAI oder Mistral sind teuer – doch viele Unternehmen verschwenden unnötig Budget mit doppelten Abfragen. Das Problem: Klassische Caching-Lösungen wie Redis erkennen semantisch gleiche Anfragen nicht, wenn diese unterschiedlich formuliert sind. Ein Nutzer fragt etwa „Wie setze ich mein Passwort zurück?“, während die nächste Anfrage „Schritte für Passwort zurücksetzen“ lautet. Beide Fragen haben dieselbe Bedeutung, werden aber von herkömmlichen Systemen als unterschiedliche Anfragen behandelt – und führen zu neuen API-Aufrufen.

2026 ist das Jahr, in dem Entwickler diese Ineffizienz nicht mehr ignorieren können. Während einfache String- oder Schlüsselwortvergleiche längst überholt sind, bieten moderne Frameworks wie Spring AI in Kombination mit pgvector eine elegante Lösung: semantisches Caching.

Warum herkömmliche Caching-Ansätze scheitern

Die meisten Entwickler begegnen dem Problem mit veralteten Methoden, die schnell an ihre Grenzen stoßen:

• Fokus auf exakte Übereinstimmung: Traditionelle Caches wie Redis oder Memcached speichern Antworten basierend auf wortwörtlichen Anfragen. Semantisch identische, aber anders formulierte Fragen landen dennoch als neue Anfrage in der API – und verursachen Kosten.

• Manuelle Vektor-Berechnungen: Viele Teams implementieren die Vektorsuche selbst im Anwendungscode. Doch ohne native Unterstützung durch die Datenbank wie pgvector fehlt die Hardware-Beschleunigung, was zu langsamen Antwortzeiten führt.

• Netzwerk-Overhead: Ein häufiger Fehler ist, externe Embedding-Modelle zu nutzen, um Anfragen vor dem Caching zu verarbeiten. Das widerspricht dem Grundgedanken von Caching: niedrige Latenz. Jeder zusätzliche API-Aufruf verlängert die Reaktionszeit.

Semantisches Caching: Die effiziente Alternative

Der Schlüssel liegt darin, Anfragen bereits auf semantischer Ebene zu vergleichen – noch bevor sie die teure LLM-API erreichen. Spring AI Advisors ermöglichen genau das, indem sie die Logik zur Cache-Prüfung in den Framework-Workflow integrieren. Hier die wichtigsten Schritte:

1. Anfrage abfangen: Ein benutzerdefinierter CallAroundAdvisor fängt die LLM-Anfrage ab, bevor sie an den externen Anbieter gesendet wird.

1. Lokale Embeddings generieren: Statt auf externe Dienste wie OpenAI zu warten, wird ein lokales Modell wie `all-MiniLM-L6-v2` (im ONNX-Format) genutzt. Das Modell läuft innerhalb der JVM und benötigt weniger als 5 Millisekunden für die Berechnung des Vektors.

1. Ähnlichkeitssuche mit pgvector: Die generierte Vektor-Darstellung der Nutzeranfrage wird gegen eine PostgreSQL-Datenbank mit pgvector abgeglichen. Dank des HNSW-Index (Hierarchical Navigable Small World) lassen sich auch Millionen von Einträgen in unter 10 Millisekunden durchsuchen.

1. Schwellenwert für Treffer festlegen: Nur Anfragen mit einer Kosinus-Ähnlichkeit von über 0,96 werden als Treffer gewertet. So wird verhindert, dass semantisch unterschiedliche Anfragen fälschlich als identisch erkannt werden.

Praxistipp: Code-Beispiel für Spring AI

Die Implementierung ist dank Spring AI erstaunlich schlank. Hier ein vollständiges Beispiel für einen semantischen Cache-Advisor:

public class SemanticCacheAdvisor implements CallAroundAdvisor {

    private final PgVectorStore vectorStore;
    private final double similarityThreshold = 0.96;

    @Override
    public AdvisedResponse aroundCall(AdvisedRequest request, CallAroundAdvisorChain chain) {
        String query = request.getPrompt().getInstructions().get(0).getContent();

        // Suche nach ähnlichen Anfragen im Vektor-Cache
        var matches = vectorStore.similaritySearch(
            SearchRequest.query(query)
                .withSimilarityThreshold(similarityThreshold)
                .withTopK(1)
        );

        // Falls Treffer: Gebe die gecachte Antwort zurück
        if (!matches.isEmpty()) {
            return AdvisedResponse.from(
                matches.get(0).getMetadata().get("cached_response").toString()
            );
        }

        // Falls kein Treffer: Führe die Anfrage aus und cachee das Ergebnis
        AdvisedResponse response = chain.nextAroundCall(request);
        var cachedDoc = new Document(
            query,
            Map.of("cached_response", response.getMessage())
        );
        vectorStore.add(List.of(cachedDoc));

        return response;
    }
}

Drei Regeln für langfristigen Erfolg

Wer semantisches Caching in Produktionsumgebungen einsetzt, sollte folgende Best Practices beachten:

• Entkopplung der Logik: Halte deinen Anwendungscode sauber. Die Caching-Logik gehört nicht in die Business-Schicht, sondern wird durch Spring AI Advisors transparent verwaltet.

• Skalierbarkeit planen: Ein HNSW-Index auf der pgvector-Spalte ist unverzichtbar. Ohne ihn verlangsamt sich die Suche bei wachsender Datenmenge exponentiell.

• Hohe Ähnlichkeits-Schwellenwerte setzen: Ein Wert von 0,95 oder höher verhindert falsche Treffer. Niedrigere Schwellen führen zu „Halluzinationen“, bei denen unterschiedliche Nutzerintentionen fälschlich als identisch eingestuft werden.

Die Zukunft der LLM-Nutzung liegt nicht in immer größeren Modellen, sondern in intelligentem Caching. Mit der richtigen Architektur lassen sich bis zu 80 % der API-Aufrufe einsparen – und das bei gleichbleibender Antwortqualität. Unternehmen, die jetzt in semantische Caching-Lösungen investieren, sichern sich nicht nur Kostenvorteile, sondern auch einen entscheidenden Geschwindigkeitsvorteil im Wettbewerb.