Spring AI im Unternehmensumfeld: Ein Support-Agent mit Tools, RAG und Überprüfungsmöglichkeiten
Spring AI für einen Hilfsprogramm zur Vorrangigkeitsbewertung von Vorfällen: Prompts als Verträge, strukturierte Ausgabe, Aufruf von Tools, MCP-Entdeckung, Qdrant RAG, Trace-Logging sowie begrenzte Agentenschleifen.
Quellen: Leveraging Spring AI for building the next generation of enterprise applications
Ein Support-Ticket als Testfall
Ein internes AI-Entwicklungsseminar für Softwareentwickler in einem Finanztechnologieunternehmen entstand aus einer Situation, der fast jeder Entwickler früher oder später begegnet: Ein Support-Ticket kommt herein. Die Protokolle enthalten nur unvollständige Hinweise. Der relevante Code befindet sich in einem internen Repository. Die Person, die im Dienst ist, benötigt eine gezielte Erstanalyse – nicht eine allgemeine Antwort.
Spring AI eignet sich hervorragend für eine solche Übung, da es KI-Funktionen in ein Ökosystem einbringt, mit dem Java- und Spring-Entwickler bereits täglich arbeiten. Es bietet Abstraktionen für Modelle, Anfragen, strukturierte Ausgaben, Aufruf und Abruf von Tools, die sich nahezu reibungslos in die bestehende Anwendungsarchitektur integrieren lassen.
Die Aufrufung eines LLM aus einer Java-Anwendung ist nicht der interessante Teil. Entscheidend ist vielmehr, dies unter Einhaltung der Disziplin zu tun, die ein FinTech-Umfeld erfordert: explizite Verträge, Tools mit minimalem Berechtigungsgrad, Nachvollziehbarkeit sowie menschliche Überprüfung dort, wo Entscheidungen Gewicht haben.
Daher geht der Umfang hier über das Workshop-Thema hinaus. Ein „Support Agent“-Projekt dient als laufendes Beispiel dafür, wie KI mit bestehenden Systemen verbunden werden kann, wo ein Modell in der Architektur Platz findet, wie es auf Unternehmensfähigkeiten und Daten zugreift sowie wie das umgebende System sein Verhalten nützlich, vorhersehbar und unter Kontrolle hält.
Ein Integrationssproblem, kein Modellproblem
Die Einbindung von KI in Unternehmenssysteme besteht hauptsächlich aus Integrationsarbeiten und hat nur wenig mit der Auswahl eines Modells zu tun. Teams erkennen das in der Regel erst nach dem ersten Prototypen. Es ist einfach, eine Anfrage an ein Modell zu senden, und die Ergebnisse können beeindruckend aussehen. Sobald die KI jedoch in ein Produktionsystem eingeführt wird, treten grundlegende Spannungen zutage.
Unternehmenssoftware basiert auf Determinismus. Sie setzt strenge Vereinbarungen, vorhersehbare Latenzzeiten sowie klar definierte Datenflüsse voraus. Eine bestimmte Eingabe sollte immer zu einem konsistenten Ausgangsergebnis führen, und das Verhalten lässt sich über den Code nachvollziehen.
KI-Systeme funktionieren anders. Sie sind von Natur aus probabilistisch, verwenden oft natürliche Sprache anstelle strukturierter Eingaben und sind auf externe Anbieter angewiesen. Derselbe Anfrage kann unterschiedliche Antworten liefern, und ein Teil der Logik befindet sich innerhalb des Modells und ist somit außerhalb der Kontrolle des Systems.
Das Ergebnis ist eine strukturelle Unstimmigkeit: ein nicht-deterministischer Bestandteil innerhalb einer deterministischen Architektur. Gewohnte Annahmen bezüglich Tests, Überwachung und Zuverlässigkeit gelten nicht mehr. Der schwierige Teil besteht nicht darin, kluge Antworten zu generieren, sondern darin, sie in Systeme einzubauen, die Kontrolle erfordern.
Spring AI geht damit um, KI als weitere Integrationssache im Spring-Ökosystem und nicht als Sonderfall zu betrachten. Spring abstrahiert bereits Datenbanken, Messaging-Systeme und REST-Aufrufe, und Spring AI fügt vergleichbare Abstraktionen für Sprachmodelle, Vektorlagern sowie kI-gesteuerte Workflows hinzu. Ziel ist es nicht, die Komplexität vollständig zu verbergen, sondern sie so zu organisieren, dass sie zu den bestehenden Architekturmustern passt.
In einer typischen Konfiguration befindet sich die KI nicht in einem separaten Service. Sie ist als Integrationsskript im Anwendungs层 eingebettet.
Die Logik des Projekts funktioniert wie folgt: Ein Antrag kommt ein, wobei geschäftliche Anfragen abgewiesen werden. Reale Vorfälle erhalten ein Ticket. Das Spring AI-Tool prüft die Protokolle und wandelt die Diagnose in ein Java-Record um. Der relevante Quellcode wird aus einem von Qdrant unterstützten Vektorlagerraum abgerufen, es wird ein Vorschlag zur Behebung erstellt, und das Ticket wird aktualisiert, damit eine Person es überprüfen kann.
Für Entwickler wird KI zu einer weiteren Abhängigkeit, während die Anwendung weiterhin die Kontrolle über den Workflow behält. Modelle werden wie jede andere Infrastrukturkomponente konfiguriert, und die Interaktionen erfolgen über gut definierte APIs anstelle von ad-hoc HTTP-Aufrufen.
In dem Projekt erhält ein SupportAgentController die eingehende Anfrage als SupportTicketRequest. Er leitet die KI-Logik an den SupportAnalysisService weiter, speichert den Zustand über den SupportTicketService, lädt den Quellcode über den GithubRagService herunter und speichert die erzeugte Lösung im Ticket.
Ein bemerkenswerter Nebeneffekt ist, dass die Geschäftslogik unabhängig vom Modellanbieter bleibt. Das Wechseln der Anbieter oder das Hinzufügen von Fallback-Lösungen beeinflusst den Kerncode nicht. Langfristig geht es dabei weniger um Flexibilität als vielmehr darum, die architektonische Kontrolle zu bewahren. Falls das Modell nicht erreichbar ist, sollte der untenstehende Endpunkt dennoch ein Ticket erstellen, die KI-Analyse als nicht verfügbar markieren und den Fall in die Warteschlange für Menschen übergeben.
@PostMapping("/requests")
public ResponseEntity<?> submitSupportRequest(@Valid @RequestBody SupportTicketRequest request) {
boolean isBusiness = supportAnalysisService.isItBusinessRequest(request);
if (isBusiness) {
return ResponseEntity.status(HttpStatus.BAD_REQUEST)
.body(ErrorResponse.businessRequest());
}
SupportTicket ticket = ticketService.createTicket(request);
LogCauseReport logCauseReport = supportAnalysisService.analyzeLogs(request);
String classCode = ragService.findRelevantClass(null, logCauseReport.repoName(), null, logCauseReport.className()).stream()
.map(SupportAgentController::stripMetadataLines)
.filter(content -> !content.isBlank())
.collect(Collectors.joining(System.lineSeparator() + System.lineSeparator()));
String solution = supportAnalysisService.suggestFix(classCode, logCauseReport.causeOfProblem());
ticketService.updateTicket(ticket.getId(), SupportStatus.SUBMITTED,
"Cause of the problem: " + logCauseReport.causeOfProblem() + "\n\nSuggested fix: " + solution);
return ResponseEntity.status(HttpStatus.CREATED).body(SupportTicketResponse.from(ticket));
}
ChatClient und Prompts als Verträge
Spring AI konzentriert sich auf die ChatClient API, eine strukturierte Methode, um mit Sprachmodellen zu kommunizieren. Anstatt manuell HTTP-Anfragen zu erstellen, nutzen Entwickler eine benutzerfreundliche API, die die Erstellung von Prompts, deren Ausführung sowie die Verarbeitung der Antworten abdeckt.
Der erste Versuch eines Ticketsortierers im Support Agent-Projekt sah so aus.
String result = chatClient.prompt("Analyze if incoming support ticket is about some kind of issue or is it a business request. "
+ "If it's a business request, the text will ask you to create something new or ask for estimation, if it's a support request "
+ "the text will say that something is not working properly, something is down or needs fixing. Answer with true if it's a "
+ "business request and false if it's a support request" + request.description())
.call()
.content();
Es ähnelt einer gewöhnlichen API, mit dem Unterschied, dass der Vertrag durch die Anweisung definiert wird und nicht mehr durch ein JSON-Schema.
Würde es in der Produktion genaue Ergebnisse liefern? Wahrscheinlich nicht. Es mischt dauerhafte Anweisungen mit unzuverlässigen Benutzereingaben in einem einzigen String, grenzt den Inhalt des Tickets nicht ab und geht davon aus, dass das Modell etwas zurückgibt, was Java als Boolean interpretieren kann. Eine für die Produktion konzipierte Version ähnelt eher einem Anwendungsvertrag, bei dem systembezogene Anweisungen von Benutzereingaben getrennt bleiben.
String result = chatClient.prompt()
.system("""
You classify incoming tickets for an L3 support workflow.
Return exactly one token: true or false.
Return true when the request asks for new functionality, estimation, planning, or project work.
Return false when the request reports broken, degraded, unavailable, or incorrect production behavior.
Do not explain your answer.
""")
.user(u -> u.text("""
Ticket title: {title}
Ticket source: {source}
Ticket description:
---
{description}
---
""")
.param("title", request.title())
.param("source", request.source())
.param("description", request.description()))
.call()
.content();
Die Systemanweisungen legen das Verhalten und die Grenzen fest, während die Benutzernachricht die sich ändernden Eingaben enthält. Anfragen werden schließlich zu einem Bestandteil des Designs selbst, indem sie Annahmen festhalten, den Ton vorgeben und beeinflussen, wie Anfragen interpretiert werden.
Das führt zu einer neuen Disziplin: dem Prompt Engineering. Ein Prompt ist nicht mehr nur eine einmalige Zeichenkette. Er ist ein Artefakt, das versioniert, getestet und gewartet werden muss, und eine solche Behandlung ist für stabile Systeme notwendig. Die Referenzseiten von Spring AI zu Prompts sowie zum ChatClient sind die logische nächste Lektüre.
Gestraffte Ausgabe
Eine frühe Herausforderung bei der Einbindung von KI in Backend-Systeme ist die unstrukturierte Antwort. Modelle erzeugen naturgemäß freiformigen Text, während Unternehmensanwendungen strukturierte Daten benötigen.
Spring AI schließt diese Lücke, indem es Antworten direkt in Java-Objekte umwandelt. Dadurch entfällt die manuelle Parsing-Phase und es bleibt weniger Raum für Unklarheiten bei der Auswertung der Ergebnisse.
Anstelle eines Absatzes, der mitteilt, dass etwas fehlgeschlagen ist, verwendet der Support-Agent ein Java-Record, um anzugeben, welches Repository und welche Klasse bei einem Incident beteiligt sein könnten.
@Service
@RequiredArgsConstructor
public class SupportAnalysisService {
private final ChatClient chatClient;
private final LogRetrievalTool logRetrievalTool;
public LogCauseReport analyzeLogs(SupportTicketRequest request) {
var converter = new BeanOutputConverter<>(LogCauseReport.class);
var format = converter.getFormat();
String response = chatClient.prompt("Analyze the support problem and provide solution, use available MCP tools to access logs. "
+ "Incoming support request description: " + request.description()
+ " \n provide response in this format " + format).tools(logRetrievalTool).call().content();
LogCauseReport report = converter.convert(response);
return report;
}
}
public record LogCauseReport(String causeOfProblem, String repoName, String className) {
}
Hier wird das Modell so gesteuert, dass es eine Antwort erzeugt, die direkt in ein stark typisiertes Objekt umgewandelt werden kann, wodurch die Integration von einer flexiblen Textverarbeitung zu expliziten Verträgen übergeht.
Der Vorteil ist erheblich. Unstrukturierte Ausgaben erfordern eine anfällige Parsing-Logik, die bereits bei geringfügigen Änderungen im Wortlaut versagt. Strukturierte Ausgaben hingegen können validiert, protokolliert und wie jeder andere Datentyp weitergegeben werden. Die offiziellen Dokumentationen beschreiben den Ansatz mit Konvertierern.
Neueere Versionen von Spring AI bieten außerdem typisierte Entitätsabbildungen sowie – bei einigen Anbietern – native strukturierte Ausgaben, die beide einen Blick wert sind. Durch die Durchsetzung der Verträge direkt am Modell entfällt ein Großteil des Parsing-Codes, den die Anwendung selbst verwalten muss.
Toolaufruf
Das Erstellen von Texten ist nützlich, doch der eigentliche Wert zeigt sich, wenn KI mit dem System interagieren kann, indem sie Daten abruft, Workflows auslöst oder Geschäftslogik ausführt.
Das Toolrufverfahren macht dies möglich, indem es Anwendungsfunktionen bereitstellt, die das Modell auf der Grundlage seines Schlussfolgerungsvermögens aufrufen kann. Das Modell sollte nicht als Operator mit direktem Zugang zur Infrastruktur betrachtet werden. Es beantragt eine bestimmte Funktionalität, und die Anwendung entscheidet, ob diese Funktionalität vorhanden ist, wie die Argumente überprüft werden, welche Daten zurückgegeben werden und wie die Ausführung aufgezeichnet wird.
Im Projekt stellt SupportAnalysisService ein LogRetrievalTool für den Schritt der Protokalanalyse bereit. Die Definition eines Tools erfolgt mithilfe der @Tool-Anmerkung, und ihr Beschreibungsparameter hilft dem Modell dabei, zu entscheiden, wann die Funktion aufgerufen werden soll.
@Tool(name = "analyze_logs", description = "Analyzes provided logs and summarizes potential issues")
public LogCauseReport analyzeLogs(
@ToolParam(description = "Application name") String applicationName) {
var converter = new BeanOutputConverter<>(LogCauseReport.class);
var format = converter.getFormat();
String prompt = """
You are a support AI specialized in analyzing application logs to identify potential issues.
Given the application name "%s", analyze the relevant logs and provide a structured report.
Respond ONLY with a single JSON object that strictly matches this format:
%s
Do NOT return the schema itself, only valid JSON with values filled in.
""".formatted(applicationName, format);
String jsonResponse = chatClient.prompt()
.user(prompt)
.call()
.content();
return converter.convert(jsonResponse);
}
Wenn das Modell entscheidet, dass es mehr Informationen benötigt, ruft es die Funktion auf, integriert das Ergebnis und setzt die Erstellung fort. Im Grunde wird das Modell zum Orchesterierer der Systemfunktionen.
Doch mit wachsenden Systemen werden hardcodierte Integrationen begrenzend, da jedes neue Tool eine Kopplung zwischen Modell und Anwendung hinzufügt.
Tools mit MCP entdecken
Das Model Context Protocol löst dieses Problem. MCP standardisiert, wie Tools und Dienste den Modellen zur Verfügung gestellt werden, sodass sie dynamisch entdeckt werden können und nicht in die Anwendung eingebettet sein müssen.
MCP verwandelt feste Integrationen in ein dynamisches Ökosystem, in dem Funktionen hinzugefügt oder geändert werden können, ohne dass die Kernanwendung verändert werden muss – ein grundlegender Schritt hin zu skalierbaren agentbasierten Architekturen. Die Dokumentation zur Tool-Aufruffunktion von Spring AI beschreibt das Programmiermodell sowie den Ausführungsfluss. Wenn Tools eine dynamische Erkennung benötigen oder zwischen Prozessen geteilt werden müssen, ist die MCP-Unterstützung die logische Weiterentwicklung.
Retrieval-augmented Generation
Modelle sind leistungsstark, kennen aber nichts über die Daten der Systeme. Kunden, Produkte und interne Prozesse bleiben unbekannt, es sei denn, die Informationen werden bereitgestellt.
RAG löst dieses Problem, indem es vor der Generierung einen Abrufschritt hinzufügt. Relevante Dokumente werden aus einem Vektorlagerraum abgerufen und in die Anfrage eingefügt, wodurch die Ausgabe auf Unternehmensdaten wie Handbüchern, Produktionsprotokollen und Anwendungscode gestützt wird.
Für den Support-Agenten liefert RAG eine Code-Lösung für ein bestimmtes Produktionsproblem, wobei die in den Anwendungsprotokollen genannte Java-Klasse verwendet wird.
Der erste Schritt besteht darin, dass SupportAgentController über GithubRagService Quelltextabschnitte abruft, wobei dieser Dienst auf dem LogCauseReport basiert, der das vermutete Repository sowie die Klasse enthält.
String classCode = ragService.findRelevantClass(null, logCauseReport.repoName(), null, logCauseReport.className()).stream()
.map(SupportAgentController::stripMetadataLines)
.filter(content -> !content.isBlank())
.collect(Collectors.joining(System.lineSeparator() + System.lineSeparator()));
In der zweiten Schritt erstellt der Abrufdienst Metadatenfilter und führt eine Ähnlichkeitssuche im Qdrant-Vektorlagerraum durch.
SearchRequest.Builder searchRequestBuilder = SearchRequest.builder();
if (expressions != null) {
searchRequestBuilder = searchRequestBuilder.filterExpression(expressions.build());
}
Set<String> results = Objects.requireNonNull(vectorStore.similaritySearch(searchRequestBuilder.topK(10).build()))
.stream()
.map(Document::getFormattedContent)
.collect(Collectors.toSet());
Der dritte Schritt injiziert den abgerufenen Code in einen Prompt, der nach einer Korrektur fragt.
String prompt = """
You are a Senior Java Developer. You have the following class code:
%s
The code has the following problem: %s
Provide a detailed suggestion on how to fix the problem in the code.
Format your response in markdown with clear sections.
""".formatted(classCode, problemDescription);
String suggestion = chatClient.prompt(prompt).call().content();
Durch dieses Verfahren wird das Modell von einem allgemeinen Assistenten zu einem Modell, das das jeweilige Fachgebiet kennt. RAG verringert hauptsächlich Halluzinationen und stellt sicher, dass die Antworten mit dem internen Wissen übereinstimmen – allerdings zu Lasten einer erhöhten Komplexität.
Dazu kommen Embedding-Modelle, Vektordatenbanken sowie Suchlogik, die alle Verwaltung und Anpassung erfordern. Im Unternehmensumfeld ist diese Komplexität oft unvermeidlich, da die Qualität der Antworten von mehreren Faktoren abhängt: Wie aktuell die eingegebenen Daten sind, die Qualität der Metadaten, die Strategie zur Aufteilung in Blöcke, die Autorisierung sowie die Nachverfolgung von Belegen. Die Dokumentation von Spring AI zu RAG, Vektorlagern und Qdrant behandelt die Konzepte in diesem Abschnitt.
Überwachbarkeit, Bewertung und betriebliche Kontrollen
Die Überwachbarkeit bei KI funktioniert anders. Herkömmliches Logging und Monitoring gehen von deterministischem Verhalten aus, doch KI erfordert die Erfassung zusätzlicher Dimensionen. Die Verfolgung von Reaktionszeiten und Fehlerraten reicht nicht aus; Teams benötigen außerdem Informationen zu Eingaben, Modellausgaben, Tokenverbrauch sowie Tool-Interaktionen.
Der Support-Agent verwendet Micrometer als Überwachungsframework, um Folgendes aufzunehmen:
- Identifikatoren und Kontext für jede Anfrage, wie Ticket, Anrufer und Quellsystem
- Den Anbieter und Namen des Modells, die Version der Eingabe, die Latenz, den Tokenverbrauch sowie den Grund für die Beendigung
- Ob die Umwandlung in eine strukturierte Ausgabe erfolgreich war
- Jede Tool-Aufrufung mit normalisierten Argumenten, Ergebnisgröße und Latenz
- Welche Repositorien, Dateien, Vektorwerte sowie Abrufteile zurückgegeben wurden
- Den endgültigen Status des Tickets sowie ob der menschliche Prüfer den Vorschlag akzeptiert oder geändert hat
Diese Detailstufe ist für das Debuggen und die Optimierung unerlässlich, da sie erklärt, warum sich das System so verhält. In einer Produktionsanwendung sollten sensible Eingaben und Ausgaben nicht wortwörtlich protokolliert werden. Eine robustere Alternative ist das strukturierte Ereignisprotokollieren mit Request-ID, Modell-ID, Token-Zahlen und Ergebnis der Richtlinie.
Durch die Bewertung der Ausgaben entsteht eine weitere Ebene. Systeme können die Qualität der Antworten anhand vordefinierter Kriterien bewerten und müssen nicht davon ausgehen, dass die Antworten korrekt sind. Dadurch sind Muster wie Evaluator-Optimierer-Schleifen möglich, bei denen eine Antwort vor der Übermittlung an den Benutzer weiter verfeinert wird.
Es verändert außerdem die Art und Weise, wie sich das System weiterentwickelt. Immer wenn sich eine Eingabe, ein Embedding-Modell, ein Chunking-Verfahren oder eine Modellversion ändert, kann das Ergebnis mit bekannten Fällen verglichen werden, sodass das Team feststellen kann, ob die Änderung den Arbeitsablauf verbessert – und nicht nur auf wenige beeindruckende Beispiele angewiesen ist.
Bevor der Assistent anderen Teams zur Verfügung gestellt wurde, wurden für das Projekt eine Reihe von Betriebskontrollen in Betracht gezogen:
- starre Zeitlimits für Anfragen an das Modell, die Tools sowie den Vektorlagert
- Token-Budgets pro Anfrage und pro Anrufer, um Kosten und Fehlermöglichkeiten einzuschränken
- Wiederholungsversuche nur dort, wo sie sicher und begrenzt sind
- Notfallzustände für den Fall, dass das Modell, ein Tool oder Qdrant nicht verfügbar ist
- Entfernung von Geheimnissen, Zugangsdaten und personenbezogenen Daten vor den Eingaben und Protokollen
- Standardmäßiges Ausschalten der Inhaltserfassung oder nur unter genehmigten Zugriffskontrollen
- explizite Aufbewahrungsregeln für Eingaben, Ergebnisse, Embeddings und Tool-Ausgaben
- Dashboards und Warnungen für Konvertierungsfehler, leere Ergebnisse, Tool-Fehler sowie Ablehnungen durch Überprüfer
Die Ablehnungsrate der Überprüfer sagt am meisten über die tatsächliche Nutzung aus. Wenn Ingenieure die generierten Empfehlungen regelmäßig umschreiben oder verworfen, verursacht das zusätzliche Arbeit für den Assistenten. Ein Produktionsystem sollte aus diesem Signal lernen. Eine automatische Feinabstimmung für alles ist nicht der richtige Ansatz. Der bessere Weg ist operativ: Anleitungen, Tools, Suchfunktionen und Richtlinien mithilfe messbarer Erkenntnisse verbessern. Die Dokumentation zur Überwachbarkeit von Spring AI behandelt die integrierten Werkzeuge.
Entwurf begrenzter agenter Workflows
Wenn man all das zusammenführt, entsteht ein neues Muster: das agierende System.
Traditionelle Anwendungen folgen vorgegebenen Workflows. Agierende Systeme führen einen iterativen Zyklus aus Beobachten, Überlegen und Handeln durch. Sie speichern Zustände, nutzen Erinnerungen und entscheiden dynamisch, welche Aktionen ergriffen werden sollen.
Zustände, Erinnerungen und Autonomie werden zu zentralen Aspekten, wobei jeder davon auf eine bereits von Spring AI bereitgestellte Fähigkeit verweist:
- Der Zustand ist das, was in der aktuellen Interaktion bekannt ist
- Das Gedächtnis ist das, was über mehrere Interaktionen hinweg bestehen bleibt
- Werkzeuge definieren, welche Aktionen erlaubt sind
- Richtlinien kennzeichnen, was verboten ist oder Bestätigung benötigt
- Beendigungskriterien legen fest, wann der Kreislauf enden muss
Dies verändert die Rolle der Anwendung im Vergleich zu einem klassischen Unternehmensworkflow. Anstatt jeden Schritt zu definieren, definiert das System Fähigkeiten und Einschränkungen und lässt das Modell das Verhalten innerhalb dieser Grenzen steuern.
In dem Support-Agenten beginnt der Prozesszyklus mit einer Anfrage. Der Agent überlegt darüber nach, ruft Tools auf und holt Code ab. Anschließend erstellt er eine Empfehlung und aktualisiert das Ticket. Es handelt sich dabei nicht um einen autonomen Produktionsoperator, und er sollte auch nicht dazu werden. In der Finanztechnologie bestimmt diese Grenze, welche Aktionen der Agent in einem bestimmten Kontext ausführen darf. Dem Modell kann man zuverlässig zutrauen, Protokolle gut zusammenzufassen, noch bevor man ihm zutrauen kann, ein Ticket zu ändern.
Effektive Agenten zu entwickeln ist schwierig, und die Dokumentation von Spring AI zu diesem Thema ist ein guter Ausgangspunkt.
Von Experimenten zu Unternehmenssystemen
KI ist nicht einfach nur eine weitere Funktion. Sie fügt Unternehmenssystemen eine neue Schicht hinzu – eine schicht, die probabilistisch, dynamisch ist und eng mit externen Abhängigkeiten verbunden ist. Ohne Struktur führt diese Schicht schnell zu brüchigem, unvorhersehbarem Verhalten.
Spring AI bietet eine Möglichkeit, KI zu integrieren, ohne dabei die ingenieurtechnischen Praktiken aufzugeben, die Enterprise-Systeme zuverlässig machen. Bekannte Abstraktionen sowie gut definierte Integrationsmuster ermöglichen es Teams, KI einzuführen, ohne explizite Verträge, kontrollierte Interaktionen sowie vorhersehbares Verhalten aufzugeben.
Daher geht es bei der Veränderung nicht nur darum, KI-Funktionen hinzuzufügen. Es geht vielmehr darum, Systeme weiterzuentwickeln, sodass KI zu einem nützlichen, regulierten und beobachtbaren Bestandteil der Architektur wird. Die nächste Welle an Enterprise-Anwendungen wird danach beurteilt, wie gut sie KI integrieren, und wie sie sie nutzen, spielt dabei eine geringere Rolle.
Verwandte Artikel
- Praktische Anmerkungen: RAG ist tot. LLM Wiki – Andrej Karpathys Idee – ist das, was als Nächstes kommt — Detaillierte Anleitung zu „Praktische Anmerkungen: RAG ist tot. LLM Wiki – Andrej Karpathys Idee – ist das, was als Nächstes kommt“: Verträge, Überprüfungen sowie Code-Blöcke für Teams, die RAG einsetzen.
- Ein RAG-Projekt besteht nicht aus einer einzigen riesigen Python-Datei: Eine skalierbare Ordnerstruktur — Eine Demo-RAG-Anwendung in Komponenten wie Datenaufnahme, Teilung der Daten, Erstellung von Embeddings, Vektorlager, Abruf von Informationen, Prompt-Generierung, LLM-Klient, API, Tests und Protokolle aufteilen, damit sie über die Anfangsphase hinauswachsen kann.