Hinweis: Dieser Podcast und dieses Video wurden mithilfe von KI erstellt. Dabei wurden die Originalinhalte und technischen Erkenntnisse des Autors des Blogbeitrags adaptiert.

Eine Spring-Boot-Anwendung soll eingehende Supporttickets automatisch beantworten, E-Mails zusammenfassen oder Informationen aus internen Dokumenten bereitstellen. Für solche Aufgaben eignen sich Large Language Models besonders gut, da sie natürliche Sprache verstehen und generieren können. Viele Funktionen, die früher komplexe Regeln oder spezialisierte Machine-Learning-Verfahren erforderten, lassen sich heute durch einen passenden Prompt beschreiben.

Die direkte Integration eines LLM ist jedoch anspruchsvoller, als es zunächst vielleicht erscheinen mag. OpenAI, Anthropic, Mistral und lokal betriebene Modelle über Ollama stellen jeweils eigene APIs, SDKs und Konfigurationsparameter bereit. Wer sich direkt an einen Anbieter bindet, muss seine Anwendung bei einem Modell- oder Anbieterwechsel anpassen. Gleichzeitig unterscheiden sich LLMs grundlegend von klassischer Anwendungslogik: Sie antworten nicht deterministisch, verursachen tokenbasierte Kosten und können Informationen erzeugen, die nicht den bereitgestellten Fakten entsprechen.

Spring AI abstrahiert die unterschiedlichen APIs und Konfigurationsparameter der Modelle. Die Interfaces ChatClient und ChatModel bieten ein einheitliches API für verschiedene Anbieter und erleichtern den Wechsel zwischen ihnen erheblich.

Darüber hinaus stellt Spring AI die Infrastruktur und eine Reihe von Features bereit, um die genannten Schwierigkeiten zu behandeln und produktive AI-Anwendungen zu erstellen. Dazu gehören Advisors als technischer Erweiterungsmechanismus sowie darauf aufbauende Features wie Chat Memory, Structured Output, Retrieval-augmented Generation (RAG), Tool Calling und das Model Context Protocol (MCP).

Das erste LLM mit Spring AI aufrufen

Bevor das erste LLM aufgerufen werden kann, benötigt das Projekt lediglich zwei Dinge: eine Abhängigkeit zur gewünschten Modellintegration und einige wenige Konfigurationsparameter.

Seit Spring AI 2.0 wird ein Chatmodell ausschließlich über einen modellspezifischen Spring-Boot-Starter integriert. Soll beispielsweise ein GPT-Modell von OpenAI verwendet werden, genügt die Abhängigkeit zu spring-ai-starter-model-openai. Für lokal betriebene Modelle über Ollama wird stattdessen spring-ai-starter-model-ollama eingebunden. Weitere Spring-AI-Abhängigkeiten sind für den Einstieg nicht erforderlich.

Anschließend muss das verwendete Modell konfiguriert werden. Bei extern betriebenen Modellen geschieht das in erster Linie über einen API Key, der bei OpenAI beispielsweise über den Konfigurationsparameter spring.ai.openai.api-key bereitgestellt wird. Der API Key sollte dabei niemals direkt in der Anwendungskonfiguration hinterlegt, sondern als Umgebungsvariable referenziert werden. Darüber hinaus können weitere Parameter angepasst werden, etwa das zu verwendende Modell über spring.ai.openai.chat.options.model oder eine alternative API-Adresse über spring.ai.openai.base-url. Für einfache Anwendungen reichen die Standardwerte jedoch aus.

Lokale Modelle benötigen keinen API Key. Stattdessen muss das gewünschte Modell ausgewählt werden. Bei Ollama wird das über den Konfigurationsparameter spring.ai.ollama.chat.model realisiert, dessen Wert beispielsweise qwen3:8b oder gemma3 sein kann. Spring AI verbindet sich anschließend automatisch mit der lokal laufenden Ollama-Instanz.

Sind Abhängigkeit und Konfiguration vorhanden, genügen für den ersten Aufruf eine ChatClient-Instanz und drei Methodenaufrufe. Der Service in Listing 1 implementiert einen einfachen Supportticketassistenten.

@Service
public class TicketAssistantService {

  private final ChatClient chatClient;

  public TicketAssistantService(ChatClient.Builder chatClientBuilder) {
    this.chatClient = chatClientBuilder.build();
  }

  public Flux<String> answer(String ticketText) {
    return chatClient.prompt()
      .user(ticketText)
      .stream()
      .content();
  }
}

Wenn nur ein anbieterspezifischer Spring-Boot-Starter im Projekt verfügbar ist, kann Spring die ChatClient.Builder-Instanz per Constructor Injection bereitstellen. Mit ihr kann dann eine ChatClient-Instanz konfiguriert und erzeugt werden. In diesem einfachen Beispiel wird auf eine weitere programmatische Konfiguration verzichtet.

Die prompt()-Methode der ChatClient-Instanz kann mit einem String– oder Prompt-Objekt aufgerufen werden, um einen Prompt zu erzeugen, oder, wie in diesem Beispiel, ohne Parameter. Dann wird der Prompt über ein Fluent API erzeugt. Mit Hilfe der user()-Methode wird dabei der User-Prompt definiert. Durch Aufruf der system()-Methode kann ein System-Prompt gesetzt werden. Die unterschiedlichen Aufgaben beider Prompts betrachten wir im nächsten Abschnitt genauer.

Die stream()-Methode führt mit dem definierten Prompt einen reaktiven Aufruf des LLM aus. Die generierte Antwort wird dann als Flux<String> zurückgegeben, sodass die Oberfläche bereits Teile der Antwort anzeigen kann, während das Modell noch generiert. Da die vollständige Generierung einer längeren Antwort mehrere Sekunden dauern kann, bietet der reaktive Aufruf häufig ein besseres Nutzererlebnis. Für Anwendungsfälle ohne Streaming-Anforderung steht mit der call()-Methode eine blockierende Alternative zur Verfügung.

Der gezeigte Code bietet bereits eine vollständige Integration eines LLM. Die Supportanfrage wird an das Modell übergeben und es generiert eine Antwort. Die Qualität der Antworten wird allerdings noch stark schwanken. Das LLM kennt seine Rolle nicht und weiß auch nicht, welche Art von Antwort erwartet wird. In der Praxis besteht der nächste Schritt deshalb fast immer darin, den Prompt gezielt zu verbessern. Bevor wir das Thema jedoch vertiefen, möchte ich kurz die Struktur einer Spring-AI-Anwendung vorstellen.

Architektur einer Spring-AI-Anwendung

Hinter dem einfachen API-Aufruf aus dem vorherigen Abschnitt verbirgt sich eine mehrschichtige Architektur. Das ChatClient-Interface ist für die meisten Anwendungen das zentrale API zur Arbeit mit einem LLM. Es bietet ein Fluent API, mit dem sich Prompts bauen und ausführen sowie verschiedene andere Features aktivieren und konfigurieren lassen. Das Interface setzt auf dem ChatModel– und dem StreamingChatModel-Interface auf, über die das LLM mittels eines blockierenden oder reaktiven API aufgerufen werden kann. Für beide Interfaces werden Implementierungen durch anbieterspezifische Spring-Boot-Starter bereitgestellt und konfiguriert. Diese folgen dem Namenspattern spring-ai-starter-model-<Anbieter>, z. B. spring-ai-starter-model-openai für die Integration der von OpenAI angebotenen GPT-Modelle.

Für die Integration extern betriebener Modelle wird darüber hinaus ein API Key benötigt. Er kann über anbieterspezifische Konfigurationsparameter, z. B. spring.ai.openai.api-key konfiguriert werden. Der API Key sollte jedoch nie direkt in der Anwendungskonfiguration hinterlegt, sondern beispielsweise als Umgebungsvariable referenziert werden. Das verhindert, dass er über die Konfigurationsdatei versehentlich in einem Repository veröffentlicht wird.

Um den ChatModel-Aufruf herum legt Spring AI eine Kette aus Advisors, vergleichbar mit Servlet-Filtern. Ein Advisor kann den Prompt vor dem Aufruf verändern und die Antwort danach prüfen oder anpassen. Mehrere Advisors lassen sich zu einer Kette kombinieren und in einer festgelegten Reihenfolge ausführen. Dadurch lassen sich Cross-cutting Concerns wie Logging, Guardrails oder Chat Memory sauber von der Anwendungslogik trennen, statt sie in jedem Service erneut zu implementieren. Dieses Prinzip bildet die Grundlage vieler Spring-AI-Features. Ob Chat Memory, Structured Output oder später RAG: Sie alle erweitern den Prompt vor dem Modellaufruf oder verarbeiten die Antwort danach.

Prompt Engineering mit Spring AI

Das Erstellen und schrittweise Verbessern eines Prompts wird als Prompt Engineering bezeichnet. Ziel ist es, einen Prompt zu entwickeln, auf dessen Basis das LLM zuverlässig Antworten erzeugt, die den fachlichen Anforderungen entsprechen. Dafür existiert eine Vielzahl etablierter Techniken, deren vollständige Betrachtung den Rahmen dieses Artikels sprengen würde. Für den Einstieg in Spring AI reichen jedoch einige wenige Konzepte aus, die in nahezu jeder AI-Anwendung zum Einsatz kommen.

In der Praxis entstehen gute Prompts außerdem selten beim ersten Versuch. Sie werden anhand realer Anfragen kontinuierlich verbessert und an den jeweiligen Anwendungsfall angepasst. Dabei geht es weniger darum, die perfekte Formulierung zu finden, sondern dem Modell alle Informationen bereitzustellen, die es für eine gute Antwort benötigt.

Eine wichtige Grundlage bildet die Trennung zwischen System-Prompt und User-Prompt. Der System-Prompt beschreibt die Rolle des Modells sowie allgemeine Vorgaben, beispielsweise den gewünschten Schreibstil, die Zielgruppe oder Einschränkungen bei der Beantwortung. Der User-Prompt enthält dagegen die konkrete Anfrage. Im Beispiel des Supportticketassistenten beschreibt der System-Prompt einen erfahrenen Supportmitarbeiter, während der User-Prompt den eigentlichen Tickettext enthält.

Ebenso wichtig ist die Bereitstellung zusätzlicher Informationen. Ein LLM kann ausschließlich auf Basis der Daten antworten, die ihm im Prompt zur Verfügung stehen. Daher werden häufig weitere Informationen wie Produktnamen, Dokumente oder frühere Nachrichten einer Konversation ergänzt. Je vollständiger der bereitgestellte Kontext ist, desto fundierter und anwendungsspezifischer kann das Modell antworten. Im Beispiel in Listing 2 wird deshalb neben dem eigentlichen Ticket auch der Name des betroffenen Produkts übergeben.

Eine weitere bewährte Technik ist das Few-Shot Prompting. Dabei enthält der Prompt zusätzlich ein oder mehrere Beispiele für gewünschte oder unerwünschte Antworten. Das Modell erkennt dadurch leichter, welches Ergebnis erwartet wird, und kann dieses Muster auch auf neue Eingaben übertragen.

Schließlich sollte ein Prompt möglichst präzise beschreiben, wie das Ergebnis aussehen soll. Neben der eigentlichen Aufgabe können beispielsweise Tonalität, Umfang oder die gewünschte Struktur der Antwort vorgegeben werden. Ein Prompt, der lediglich „Beantworte das Ticket“ verlangt, liefert deutlich schwankendere Ergebnisse als einer, der zusätzlich den gewünschten Stil und den Aufbau der Antwort definiert.

Der TicketAssistantService in Listing 2 setzt einige dieser Techniken mit Spring AI um.

@Service
public class TicketAssistantService {

  private static final String SYSTEM\_PROMPT = """
    You are an experienced support engineer for our SaaS product.
    Answer precisely, suggest a concrete next step and avoid speculation.
    """;

  private final ChatClient chatClient;
  private final PromptTemplate userPromptTemplate =
    new PromptTemplate("Product: {product}\\nTicket:\\n{ticketText}");

  public TicketAssistantService(ChatClient.Builder chatClientBuilder) {
    this.chatClient = chatClientBuilder
      .defaultSystem(SYSTEM\_PROMPT)
      .build();
  }

  public Flux<String> answer(String product, String ticketText) {
    var userMessage = userPromptTemplate.create(
      Map.of("product", product, "ticketText", ticketText));
    return chatClient.prompt(userMessage).stream().content();
  }
}

Mit Spring AI kann der System-Prompt über die defaultSystem()-Methode der ChatClient.Builder-Instanz als Standard für alle daraus erzeugten ChatClient-Instanzen definiert werden. Soll die Rolle des Modells zwischen verschiedenen Aufrufen variieren, kann stattdessen die system()-Methode des ChatClient verwendet werden.

Für strukturierte User-Prompts bietet Spring AI mit der PromptTemplate-Klasse eine einfache Möglichkeit, Platzhalter in einem Template zu ersetzen. Im Beispiel werden dadurch der Produktname und der Tickettext zu einem einheitlich aufgebauten Prompt zusammengesetzt. Das erleichtert die Wiederverwendung von Prompts und sorgt dafür, dass Informationen stets in derselben Struktur an das Modell übergeben werden.

System-Prompt und der Text des PromptTemplate können außerdem als Resource in externen Dateien abgelegt werden. Dadurch lassen sich Prompts unabhängig vom Anwendungscode versionieren und anpassen.

Fast alle Aufrufe eines LLM basieren auf einem Prompt. Daher bildet er auch für viele weitere Spring-AI-Features eine zentrale Grundlage. Chat Memory und Retrieval-augmented Generation folgen beispielsweise demselben Grundprinzip: Sie erweitern den Prompt automatisch um zusätzlichen Kontext, bevor er an das Modell übergeben wird.

NEUES AUS DER JAVA-BACKEND-WELT

Java-Backend-Track entdecken

Mehr erfahren

Konversationskontext mit Chat Memory verwalten

Ein LLM ist zustandslos und merkt sich daher keine vorherigen Nachrichten. Jeder Prompt wird unabhängig verarbeitet, ohne Wissen über frühere Anfragen oder Antworten. Beschreibt ein Kunde in einem Supportticket zunächst einen Fehler und stellt anschließend Rückfragen zur Antwort, kennt das Modell diese schon nicht mehr.

Spring AI löst dieses Problem über das Chat-Memory-Feature. Dabei speichert die Anwendung die aktuelle Konversation und stellt sie dem LLM bei jedem Aufruf als Teil des Prompts zur Verfügung. Somit erscheint es dem Nutzer, als ob das LLM sich an die vorherigen Nachrichten erinnern würde. Das ist jedoch nicht der Fall. Das LLM kennt ausschließlich die vorhergehenden Nachrichten, die die Anwendung zum Prompt hinzugefügt hat.

Chat Memory enthält dabei in der Regel nicht alle Nachrichten einer Konversation. Das wird als Chat History bezeichnet und würde zu einem hohen Tokenverbrauch und damit zu hohen Kosten führen. Im Chat Memory wird daher nur ein begrenzter, relevanter Ausschnitt der Konversation gespeichert und dem LLM bereitgestellt. Im einfachsten Fall wird das Chat Memory in Spring AI durch den MessageChatMemoryAdvisor zusammen mit einer ChatMemory-Implementierung bereitgestellt (Listing 3).

@Service
public class TicketChatService {

  private final ChatClient chatClient;

  public TicketChatService(ChatClient.Builder chatClientBuilder, ChatMemory chatMemory) {
    this.chatClient = chatClientBuilder
      .defaultAdvisors(MessageChatMemoryAdvisor.builder(chatMemory).build())
      .build();
  }

  public Flux<String> chat(String ticketId, String message, String conversationId) {
    return chatClient.prompt(message)
      .advisors(spec -> spec.param(ChatMemory.CONVERSATION\_ID, conversationId))
      .stream()
      .content();
  }
}

Dazu muss eine MessageChatMemoryAdvisor-Instanz an die defaultAdvisors()-Methode auf der ChatClient.Builder-Instanz oder an die advisor-Methode der ChatClient-Instanz übergeben werden. Der Advisor wird dann vor und nach dem Aufruf des LLM ausgeführt. Vor dem Aufruf übergibt er den auszuführenden Prompt an die ChatMemory-Instanz, fragt von dieser die vorherigen Nachrichten ab und fügt sie dem Prompt hinzu. Nachdem Spring AI die generierte Antwort vom LLM erhalten hat, übergibt der Advisor die Antwort ebenfalls an die ChatMemory-Instanz.

In der Standardkonfiguration verwendet Spring AI ein MessageWindowChatMemory-Objekt mit einem InMemoryChatMemoryRepository als ChatMemory-Implementierung. Es speichert ein Fenster der letzten 20 Nachrichten einer Konversation in einer HashMap. Das Chat Memory geht somit beim Neustart der Anwendung verloren und wird nicht über mehrere Anwendungsinstanzen synchronisiert. Spring AI bietet jedoch auch verschiedene Repository-Implementierungen, die Nachrichten in einer Datenbank oder einem anderen persistenten Speicher ablegen.

Für sehr lange Konversationen, bei denen auch ältere Nachrichten relevant bleiben können, bietet Spring AI darüber hinaus mit dem VectorStoreChatMemoryAdvisor eine vektorbasierte Implementierung des Chat-Memory-Features. Statt eines festen Fensters aus den letzten Nachrichten sucht dieser Advisor per Ähnlichkeitssuche gezielt nach relevanten früheren Nachrichten derselben Konversation. Für die meisten Supportszenarien reicht jedoch das Window-basierte Chat Memory aus dem vorherigen Beispiel.

Beide Varianten der Chat-Memory-Implementierung benötigen eine Conversation-ID. Über sie werden zusammengehörige Nachrichten identifiziert und sie wird der AdvisorSpec bei jedem Aufruf als Parameter übergeben. Da meistens nur der Client eine neue Nachricht einer bestehenden Konversation zuordnen kann, gibt er Teile der Conversation-ID vor. Gleichzeitig muss verhindert werden, dass ein Angreifer diese ID vollständig erraten kann und somit Zugriff auf die Inhalte fremder Konversationen erhält. Daher sollte die Conversation-ID immer mit einer Information kombiniert werden, die vom Client nicht beeinflusst werden kann. Typische Beispiele sind die ID des angemeldeten Nutzers oder eine Session-ID.

Enterprise AI & Agentic Systems

Enterprise AI-Track entdecken

Mehr erfahren

LLM-Antworten als strukturierte Java-Objekte verarbeiten

In den bisherigen Beispielen hat das LLM ausschließlich Freitext erzeugt. Das genügt für die Implementierung eines Chatbots, aber nicht, wenn die Antwort durch die Anwendung weiterverarbeitet werden soll. Im Beispiel dieses Artikels kann das LLM etwa eingesetzt werden, um ein Ticket automatisch zu priorisieren. In diesem Fall ist es sinnvoll, das LLM einen definierten Typ anstatt eines Freitexts erzeugen zu lassen. Dieses Verfahren wird als Structured Output bezeichnet.

Spring AI unterstützt Structured Output über ein modellunabhängiges API. Dazu wird das gewünschte Ausgabeformat als Java Record definiert und anschließend an die entity()-Methode übergeben (Listing 4).

public enum Priority { LOW, MEDIUM, HIGH, CRITICAL }

public record TicketClassification(
  String category,
  Priority priority,
  String summary
) {}

@Service
public class TicketClassificationService {

  private final ChatClient chatClient;

  public TicketClassificationService(ChatClient.Builder chatClientBuilder, ChatMemory chatMemory) {
    this.chatClient = chatClientBuilder.build();
  }

  public TicketClassification classify(String ticketText) {
    return classification = chatClient.prompt(ticketText)
      .call()
      .entity(TicketClassification.class);
  }
}

Im Anwendungscode sieht Structured Output damit kaum anders aus als die Erzeugung einer Textantwort. Statt eines Strings liefert Spring AI direkt eine Instanz des gewünschten Typs. Das vereinfacht die Weiterverarbeitung erheblich und vermeidet zusätzlichen Code zum Parsen und Validieren der Antwort.

Intern erzeugt Spring AI mit Hilfe der Jackson-Bibliothek zunächst ein JSON-Schema aus dem übergebenen Typ. Das Schema beschreibt die erwartete Struktur der Antwort und dient dem LLM als Vorgabe. Nach der Generierung wird die Antwort wiederum mit Jackson in das gewünschte Java-Objekt umgewandelt.

Die konkrete Umsetzung hängt vom verwendeten Modellanbieter ab. Unterstützt er ein natives API für Structured Output, nutzt Spring AI es in vielen Fällen automatisch. Andernfalls erweitert Spring AI den Prompt um das erzeugte JSON-Schema sowie zusätzliche Anweisungen zur Ausgabe. Moderne Modelle befolgen diese Vorgaben in der Regel sehr zuverlässig.

Da LLMs dennoch nicht deterministisch arbeiten, kann die Antwort im Einzelfall vom erwarteten Schema abweichen. Der StructuredOutputValidationAdvisor erhöht deshalb die Zuverlässigkeit der Verarbeitung. Er validiert die erzeugte Antwort gegen das erwartete Schema und wiederholt den Modellaufruf mit einer erweiterten Fehlerbeschreibung, falls die Validierung fehlschlägt. Standardmäßig werden bis zu drei Versuche unternommen. Erst wenn auch diese fehlschlagen, gibt Spring AI die zuletzt erzeugte Antwort zurück, und die Anwendung muss die daraus resultierende Exception behandeln.

Bei Anwendungen, die strukturierte Antworten automatisiert weiterverarbeiten, ist diese zusätzliche Absicherung häufig sinnvoll. Im Beispiel der Ticketklassifikation verhindert sie, dass ein ungültiges Ergebnis die anschließende Priorisierung oder das Routing eines Tickets blockiert.

Manche Modelle, darunter aktuelle von Anthropic und OpenAI, unterstützen Structured Output zusätzlich über ein spezialisiertes API. Es ermöglicht eine noch zuverlässigere Erzeugung strukturierter Antworten. Spring AI kann diese APIs für unterstützte Modellanbieter automatisch verwenden. Dazu muss lediglich die Konstante AdvisorParams.ENABLE\_NATIVE\_STRUCTURED\_OUTPUT als Advisor aktiviert werden (Listing 5).

@Service
public class TicketClassificationService {

  private final ChatClient chatClient;

  public TicketClassificationService(ChatClient.Builder chatClientBuilder, ChatMemory chatMemory) {
    this.chatClient = chatClientBuilder
      .defaultAdvisors(AdvisorParams.ENABLE\_NATIVE\_STRUCTURED\_OUTPUT)
      .build();
  }

  public TicketClassification classify(String ticketText) {
    return classification = chatClient.prompt(ticketText)
      .call()
      .entity(TicketClassification.class);
  }
}

Fazit

Die in diesem Artikel gezeigten Features zum Prompting sowie zur Verwendung von Chat Memory und Structured Output bilden die Grundlage für viele Spring-AI-Anwendungen. Alle drei Bausteine folgen derselben Grundmechanik: Der ChatClient führt einen Prompt aus, während Advisors den Prompt vor seiner Ausführung erweitern und das generierte Ergebnis anschließend verarbeiten.

Für komplexere Anwendungen, die beispielsweise auf eigene Dokumente, externe Daten oder APIs zugreifen müssen, bietet Spring AI weitere Konzepte wie Retrieval-augmented Generation, Tool Calling und das Model Context Protocol. Das grundlegende Zusammenspiel von ChatClient, Prompt und Advisors bleibt dabei jedoch erhalten.