Wie integriert man ein lokales LLM in eine Java-Anwendung?

Das Problem

Ihr Betrieb nutzt eine Anwendung, die in Java geschrieben ist: eine Branchenlösung, ein internes Verwaltungsprogramm oder eine Webanwendung auf einem Anwendungsserver. Sie soll um eine KI-gestützte Textfunktion erweitert werden, etwa «Text zusammenfassen» oder «Antwort vorschlagen».

Die Daten sollen den Betrieb nicht verlassen, deshalb läuft das Sprachmodell lokal auf einem eigenen Rechner. Die Java-Anwendung muss mit diesem Modellserver reden.

Das geschieht über eine Schnittstelle (API): eine Netzwerkadresse, an die die Anwendung eine Anfrage schickt und von der sie Text zurückbekommt. Java bringt dafür seit Version 11 einen eigenen HTTP-Client mit. Weniger einfach ist die Frage, wo der Aufruf im Programm stattfindet, damit nichts blockiert.

So lösen Sie es mit KI – Schritt für Schritt

1. Java-Version klären. Der eingebaute HTTP-Client steht ab Java 11 zur Verfügung. Läuft Ihre Anwendung auf einer älteren Version, braucht es eine Alternative oder ein Update. Das entscheidet Ihre IT.
2. Modellserver notieren. Adresse, Port und genauer Modellname, zum Beispiel bei Ollama http://localhost:11434.
3. Aufgabe eng umreissen. Was geht an das Modell, was kommt zurück, und wo wird es angezeigt? Je klarer, desto leichter das Testen.
4. JSON-Werkzeug nutzen. Die Anfrage ist ein JSON-Text. Bauen Sie ihn mit einer JSON-Bibliothek, die Ihre Anwendung schon verwendet, nicht mit Textverkettung. Sonst brechen Anführungszeichen und Zeilenumbrüche die Anfrage.
5. Zeitgrenze setzen. Setzen Sie für Verbindung und Antwort feste Grenzen, damit die Anwendung nicht ewig wartet. Siehe Zeitüberschreitung behandeln.
6. Aufruf vom Bedienfenster trennen. Bei Desktop-Anwendungen läuft der Aufruf in einem eigenen Arbeitsablauf (Thread), bei Webanwendungen am besten als Hintergrundauftrag. Möglichkeit zum Abbrechen einplanen, siehe Anfrage abbrechen.
7. Fehler abfangen. Server nicht erreichbar, Zeit überschritten, leere Antwort: Zeigen Sie jeweils eine klare Meldung.
8. Testen und abnehmen. Prüfen Sie mit erfundenen Beispieldaten. Eine zweite Person gleicht Ergebnisse mit dem Erwarteten ab.

Adresse und Modell konfigurierbar halten

Die Adresse des Modellservers gehört nicht fest in den Quellcode. Hinterlegen Sie sie als Konfiguration, beispielsweise in einer Umgebungsvariablen wie LLM_BASE_URL, und lesen Sie sie beim Start der Anwendung ein. Java stellt dafür System.getenv("LLM_BASE_URL") bereit. Fehlt der Wert, sollte die Anwendung mit einer verständlichen Meldung abbrechen oder einen bewusst festgelegten Standardwert verwenden. Zugangsdaten gehören ebenfalls nicht in den Quellcode oder in Fehlermeldungen.

So kann die IT für Entwicklung, Test und Betrieb unterschiedliche Serveradressen setzen, ohne jedes Mal ein neues Programm zu bauen. Prüfen Sie die Adresse beim Start auf ein gültiges Format und erlauben Sie nur erwartete Zielsysteme. Modellname und weitere Einstellungen lassen sich nach demselben Prinzip konfigurieren.

Fehlerbehandlung und Zeitgrenzen

Eine gesetzte Zeitgrenze verhindert nicht jede Störung, macht sie aber behandelbar. connectTimeout begrenzt den Verbindungsaufbau; die Zeitgrenze der Anfrage begrenzt, wie lange die Anwendung auf eine Antwort wartet. Wählen Sie die Grenzen passend zur Aufgabe und machen Sie sie konfigurierbar. Eine Zusammenfassung kann andere Wartezeiten haben als ein längerer Entwurf. Die Bedienoberfläche sollte währenddessen ansprechbar bleiben und den Status anzeigen.

Unterscheiden Sie zwischen Server nicht erreichbar, Zeitüberschreitung, unerwartetem HTTP-Status und ungültiger oder leerer Antwort. Zeigen Sie eine kurze Meldung und protokollieren Sie den technischen Grund, aber keine vollständigen Eingabetexte. Automatische Wiederholungen sind mit Bedacht einzusetzen: Bei einer vorübergehenden Störung kann ein erneuter Versuch sinnvoll sein. Begrenzen Sie Anzahl und Wartezeit. Bei einer langen Generierung kann ein erneuter Aufruf die Wartezeit verlängern oder dieselbe Arbeit doppelt auslösen. Ein Abbruch sollte eine Wiederholung verhindern.

Streaming und lange Antworten

Manche Modellserver liefern die Antwort in mehreren Teilen, statt bis zum fertigen Text zu warten. Dieses Streaming kann bei längeren Ausgaben früher sichtbaren Fortschritt ermöglichen. Es verändert aber die Verarbeitung: Die Anwendung muss die einzelnen Ereignisse oder Datenzeilen lesen, korrekt zusammensetzen und erkennen, wann die Antwort abgeschlossen oder ein Fehler gemeldet wurde. Das Format hängt vom Server ab; die einfache Variante mit BodyHandlers.ofString() sammelt dagegen zunächst die ganze Antwort.

Klären Sie, ob Nutzende Teilantworten sehen sollen. Streaming erfordert eine passende Anzeige, Abbruchlogik und Fehlerbehandlung während der Übertragung. Prüfen Sie, ob Zwischenstände gespeichert werden dürfen. Eine vollständige Antwort ist einfacher zu testen und zu betreiben.

Schnittstelle abstrahieren und ohne Modellserver testen

Lagern Sie den Modellaufruf hinter eine kleine eigene Schnittstelle aus, zum Beispiel eine Methode, die Eingabetext entgegennimmt und einen Antworttext liefert. Der Rest der Anwendung kennt dann nicht die konkrete HTTP-Adresse und muss keine JSON-Details verarbeiten. Im Produktivbetrieb ruft eine Implementierung den Modellserver auf; im Test liefert eine einfache Ersatzimplementierung einen festgelegten Antworttext oder simuliert einen Fehler.

Damit lassen sich Oberflächen und Abläufe ohne laufenden Modellserver testen. Prüfen Sie den HTTP-Teil mit kontrollierten Antworten: Statuscode, leere Antwort, ungültiges JSON und Zeitüberschreitung. Verwenden Sie Beispieldaten und halten Sie erwartete Antworten fest. So werden Änderungen an Server oder Modell sichtbar.

Datenschutz und Protokollierung

«Lokal» beschreibt den Betrieb des Modellservers, beantwortet aber nicht automatisch alle Datenschutzfragen. Ermitteln Sie, welche Textteile tatsächlich gesendet werden: Nutzereingabe, ausgewählte Dokumentpassagen, Systemanweisungen und technische Metadaten. Entfernen oder ersetzen Sie Namen, Adressen und andere Angaben, wenn sie für die Aufgabe nicht nötig sind. Klären Sie auch, ob Modellserver, Proxy oder Anwendungsprotokoll Inhalte speichern und wer darauf zugreifen kann.

Protokollieren Sie für den Betrieb möglichst technische Angaben wie Zeitpunkt, Dauer, Status und eine Korrelationskennung. Vollständige Prompts und Antworten sollten nicht standardmässig in Logs landen. Falls sie für einen klar definierten Zweck nötig sind, braucht es eine begrenzte Aufbewahrung und geregelte Zugriffe. Auch Fehlermeldungen an die Oberfläche dürfen keine vertraulichen Anfrageinhalte offenlegen.

Vorlage zum Kopieren

Lassen Sie sich mit diesem Auftrag ein Codebeispiel für die IT erstellen.

Schreibe ein Java-Beispiel (Java 17), das mit java.net.http.HttpClient eine Anfrage an einen lokalen KI-Modellserver sendet.

Adresse: [z. B. http://localhost:11434/api/chat]
Modellname: [Modellname]
Aufgabe: [z. B. Text in drei Sätzen zusammenfassen]
JSON-Bibliothek in unserem Projekt: [z. B. Jackson oder Gson]

Anforderungen:
- Zeitgrenze für Verbindung und Antwort
- JSON nicht per Textverkettung bauen
- Statuscode prüfen und Fehler abfangen
- Kommentare auf Deutsch
Erfinde keine Klassen oder Methoden. Nenne am Schluss drei Punkte, die vor dem Einsatz geprüft werden müssen.

Der Entwurf muss kompiliert und getestet werden. Fügen Sie ihn nie ungeprüft in eine produktive Anwendung ein.

Die Grundform, wie sie ein Entwickler schreibt (der JSON-Text kommt aus der Bibliothek):

HttpClient client = HttpClient.newBuilder()
    .connectTimeout(Duration.ofSeconds(10)).build();
HttpRequest anfrage = HttpRequest.newBuilder()
    .uri(URI.create("http://localhost:11434/api/chat"))
    .timeout(Duration.ofSeconds(90))
    .header("Content-Type", "application/json")
    .POST(HttpRequest.BodyPublishers.ofString(jsonText))
    .build();
HttpResponse<String> antwort =
    client.send(anfrage, HttpResponse.BodyHandlers.ofString());

Worauf Sie achten müssen

• Blockierte Oberfläche: Ein Aufruf im Hauptablauf lässt Fenster einfrieren. Lagern Sie ihn aus.
• Zugang zum Modellserver: Er ist meist ungeschützt. Erlauben Sie nur die Rechner, die ihn brauchen.
• Datenschutz: Senden Sie nur Daten, die für die Aufgabe nötig sind. Prüfen Sie, ob Anfragen in Protokollen der Anwendung landen.
• Antwortformat: Prüfen Sie, ob der Server wirklich das erwartete JSON und einen Antworttext liefert. Eine erfolgreiche Verbindung allein bedeutet noch keine gültige Antwort.
• Konfiguration: Verwenden Sie für Serveradresse und Modellname Einstellungen statt hart codierter Werte und halten Sie Test- und Produktivkonfiguration auseinander.
• Modellantworten als Vorschlag: Die Antwort kann falsch sein. Speichern oder versenden Sie sie erst nach Prüfung durch eine Person.
• Altlasten: Alte Java-Versionen und fehlende Updates sind ein Sicherheitsthema für sich. Klären Sie das mit Ihrem Softwarehersteller.

Ein Beispiel aus der Praxis

Ein Beispiel: Eine Gemeindeverwaltung im Kanton Solothurn nutzt eine Java-Anwendung für Korrespondenz. Die Sachbearbeitenden wünschen einen Knopf, der aus Stichworten einen Briefentwurf erstellt.

Der Dienstleister baut die Funktion ein. Die erste Version friert das Fenster bei längeren Texten für rund eine Minute ein. Nach der Umstellung läuft der Aufruf im Hintergrund, ein Hinweis «Entwurf wird erstellt» erscheint, und die Person kann abbrechen. Der Entwurf landet als Vorschlag im Textfeld und wird von der Sachbearbeiterin überarbeitet, bevor er unterschrieben wird.

So hilft Ihnen Alpasana

Wie Sie so ein Vorhaben planen, klärt Alpasana mit KI-Beratung und digitaler Transformation: Prozesse aufnehmen, KI-Potenziale analysieren, Schnittstellen konzipieren, Systeme verbinden und die Umsetzung dokumentieren. Die Umsetzung in Ihrer konkreten Anwendung richtet sich nach Ihrem Softwarehersteller.

Projekte werden individuell offeriert, nach Klärung von Funktionen, bestehenden Systemen sowie Zeit- und Budgetrahmen.

Häufige Fragen

Reicht der eingebaute HTTP-Client von Java?

Für eine einfache Textfunktion ja. Für anspruchsvollere Fälle gibt es Bibliotheken. Bevor Sie eine zusätzliche Abhängigkeit hinzufügen, prüfen Sie, ob der eingebaute Client genügt.

Kann die Anwendung mehrere Anfragen gleichzeitig senden?

Technisch ja, aber ein lokales Modell arbeitet Anfragen oft nacheinander ab. Mehrere gleichzeitige Nutzende führen zu Wartezeiten. Planen Sie eine Warteschlange, siehe Hintergrundaufträge.

Muss ich meine Anwendung dafür umbauen?

Meist nicht grundlegend. Eine kleine Funktion kommt hinzu, die den Modellserver aufruft. Der Aufwand hängt von Aufbau und Alter der Anwendung ab und lässt sich nur im Einzelfall beurteilen.