Wenn der Chat im Browser nicht mehr reicht
Ein Softwarehaus im Maschinenbau-Umfeld hat ein Problem, das viele kennen: Die Servicetechniker dokumentieren ihre Einsaetze in Freitext, und die Innendienst-Software soll daraus automatisch Ersatzteilbedarf, Fehlerkategorie und Folgetermine erkennen. Der Prototyp war schnell gebaut — ein Mitarbeiter kopierte Berichte in einen KI-Chat und war beeindruckt von den Ergebnissen. Nur laesst sich Copy-and-paste nicht in eine Software einbauen, die taeglich hunderte Berichte verarbeitet. Was fehlt, ist der programmatische Zugriff: die LLM-API.
Eine LLM-API — API steht fuer Application Programming Interface, also Programmierschnittstelle — ist der Weg, ein grosses Sprachmodell direkt aus eigenem Code anzusprechen. Statt einer Chat-Oberflaeche gibt es einen Endpunkt im Netz: Die Anwendung schickt eine strukturierte Anfrage mit Text und Parametern, das Modell antwortet mit generiertem Text oder strukturierten Daten, und die Anwendung verarbeitet das Ergebnis weiter. Alle grossen Anbieter stellen solche Schnittstellen bereit, und sie aehneln sich im Aufbau so stark, dass die Konzepte uebertragbar sind. Dieser Beitrag geht die Bausteine durch, die man fuer eine ernsthafte Integration verstehen sollte — vom Token bis zum Modell-Routing.
Token, Preise und die Anatomie einer Anfrage
Abgerechnet wird bei LLM-APIs nicht pro Anfrage, sondern pro Token. Ein Token ist die kleinste Verarbeitungseinheit des Modells, meist ein Wortbestandteil; als grobe Richtschnur entsprechen tausend Token etwa 700 bis 750 deutschen Woertern. Bezahlt wird zweifach: fuer die Eingabe-Token, also alles, was man dem Modell schickt, und fuer die Ausgabe-Token, also die generierte Antwort — Letztere sind in der Regel deutlich teurer. Wer lange Dokumente in jede Anfrage packt, bezahlt sie bei jeder Anfrage aufs Neue. Kostenbewusstsein beginnt deshalb beim Kontext: nur mitschicken, was das Modell fuer die konkrete Aufgabe wirklich braucht.
Die Anfrage selbst besteht im Kern aus einer Liste von Nachrichten mit unterschiedlichen Rollen. Die wichtigste Unterscheidung ist die zwischen System-Message und User-Message. Die System-Message ist die Regieanweisung des Entwicklers: Sie legt fest, welche Rolle das Modell einnimmt, in welchem Ton es antwortet, welche Regeln gelten und welches Format erwartet wird. Die User-Message enthaelt die eigentliche Eingabe — im Beispiel des Softwarehauses den Servicebericht. Diese Trennung ist mehr als Kosmetik: Modelle sind darauf trainiert, der System-Message besonderes Gewicht zu geben. Verhaltensregeln gehoeren dorthin, nicht in den Nutzertext, wo sie mit den eigentlichen Daten konkurrieren.
Ein weiterer Parameter mit grosser Wirkung ist die Temperature. Sie steuert, wie stark das Modell bei der Wortwahl vom Wahrscheinlichsten abweicht. Ein niedriger Wert nahe null macht die Ausgaben fokussiert und weitgehend reproduzierbar — richtig fuer Datenextraktion, Klassifikation und alles, was verlaesslich gleich ablaufen soll. Hoehere Werte erhoehen die Variabilitaet und eignen sich fuer kreative Aufgaben wie Textentwuerfe, bei denen Abwechslung erwuenscht ist. Fuer den Servicebericht-Parser waere eine niedrige Temperature die richtige Wahl; fuer einen Vorschlagsgenerator im Marketing eine hoehere.
Streaming: Antworten, waehrend sie entstehen
Sprachmodelle erzeugen Text Token fuer Token, und bei laengeren Antworten kann es etliche Sekunden dauern, bis die Antwort vollstaendig ist. Wartet die Anwendung auf das komplette Ergebnis, starrt der Nutzer so lange auf einen Ladeindikator — gefuehlt eine Ewigkeit. Die Loesung heisst Streaming: Die API liefert die Antwort haeppchenweise aus, sobald die ersten Token feststehen, und die Oberflaeche zeigt den Text an, waehrend er waechst. Genau diesen Effekt kennt jeder aus den Chat-Oberflaechen der Anbieter.
Technisch laeuft Streaming ueblicherweise ueber Server-Sent Events, kurz SSE: eine langlebige HTTP-Verbindung, ueber die der Server fortlaufend kleine Ereignisse schickt, bis die Antwort abgeschlossen ist. Fuer den Entwickler bedeutet das etwas Mehraufwand — die Anwendung muss Bruchstuecke zusammensetzen, Abbrueche behandeln und den Abschluss erkennen —, aber fuer jede Anwendung mit direkter Nutzerinteraktion ist Streaming praktisch Pflicht. Die wahrgenommene Wartezeit sinkt drastisch, obwohl die Gesamtdauer dieselbe bleibt. Bei reiner Hintergrundverarbeitung, etwa der naechtlichen Analyse von Serviceberichten, kann man sich das Streaming dagegen sparen.
Strukturierte Ausgaben und Tool-Calling
Die haeufigste Ernuechterung beim Umstieg vom Chat zur Integration: Man bittet das Modell, "bitte als JSON" zu antworten — und bekommt meistens korrektes JSON, aber eben nur meistens. Mal umschliesst das Modell die Ausgabe mit einem erklaerenden Satz, mal fehlt ein Feld, mal ist ein Anfuehrungszeichen falsch. Fuer eine Software, die die Antwort maschinell weiterverarbeitet, ist "meistens" zu wenig; ein einziges fehlerhaftes Zeichen laesst den Parser scheitern.
Die Anbieter haben dafuer strukturierte Ausgaben eingefuehrt: Man uebergibt der API ein JSON-Schema, also eine formale Beschreibung der erwarteten Felder und Typen, und die API garantiert, dass die Antwort diesem Schema entspricht. Aus der hoeflichen Bitte wird ein technischer Vertrag. Fuer den Servicebericht hiesse das: Die Antwort enthaelt garantiert die Felder fuer Fehlerkategorie, Ersatzteile und Folgetermin, mit den definierten Typen. Wo strukturierte Ausgaben verfuegbar sind, sollten sie der Standard sein — Prompt-Bitten um Formattreue sind die fehleranfaellige Notloesung.
Eng verwandt ist das Function-Calling, auch Tool-Calling genannt. Dabei beschreibt der Entwickler dem Modell eine Reihe von Funktionen der eigenen Anwendung — Name, Zweck, Parameter mit Typen. Das Modell antwortet dann nicht mit Freitext, sondern mit dem Wunsch, eine dieser Funktionen mit bestimmten Argumenten aufzurufen. Wichtig zum Verstaendnis: Das Modell fuehrt nichts selbst aus. Es liefert einen strukturierten Aufruf-Wunsch, die eigene Anwendung fuehrt die Funktion aus und gibt das Ergebnis zurueck, woraufhin das Modell weiterarbeiten kann. So entsteht die Bruecke zwischen Sprachverstaendnis und echten Aktionen: Auftragsstatus nachschlagen, Termin anlegen, Datensatz aktualisieren. Tool-Calling ist damit auch das Fundament, auf dem agentische Systeme aufbauen.
Robuste Integration: Wenn die API nicht mitspielt
Eine LLM-API ist ein externer Dienst uebers Netz, und externe Dienste fallen aus, drosseln oder antworten langsam. Der Prototyp darf das ignorieren, die Produktivanwendung nicht. Drei Bausteine gehoeren in jede ernsthafte Integration.
Erstens Retries mit Backoff: Schlaegt eine Anfrage fehl — etwa wegen Ueberlastung oder Ratenbegrenzung —, wird sie automatisch wiederholt, aber mit wachsendem Abstand: nach einer Sekunde, dann zwei, dann vier, sinnvollerweise mit etwas Zufallsstreuung. Dieses exponentielle Zuruecknehmen verhindert, dass viele Clients einen ueberlasteten Dienst im Sekundentakt weiter bombardieren. Wichtig ist die Unterscheidung nach Fehlertyp: Ueberlastung und Zeitueberschreitungen sind wiederholbar, ein ungueltiger API-Schluessel oder eine fehlerhafte Anfrage nicht — die scheitern beim zehnten Versuch genauso.
Zweitens Timeouts: Jede Anfrage braucht eine klare Obergrenze, nach der die Anwendung nicht mehr wartet, sondern reagiert. Ohne Timeout blockiert eine haengende Verbindung im schlimmsten Fall den ganzen Verarbeitungsstrang.
Drittens Fallbacks: Was passiert, wenn der Anbieter grossflaechig gestoert ist? Je nach Anwendung kann die Antwort lauten, auf ein zweites Modell oder einen zweiten Anbieter umzuschalten, Anfragen in eine Warteschlange zu legen und spaeter zu verarbeiten, oder dem Nutzer transparent mitzuteilen, dass die KI-Funktion gerade nicht verfuegbar ist, waehrend der Rest der Anwendung weiterlaeuft. Entscheidend ist, dass dieser Fall vor dem ersten Ausfall durchdacht wurde und nicht waehrenddessen.
Dazu kommt Beobachtbarkeit: Wer Latenzen, Fehlerraten und Token-Verbrauch pro Funktion protokolliert, erkennt Kostentreiber und schleichende Qualitaetsprobleme, bevor sie im Monatsabschluss oder beim Kunden auffallen.
Modellwahl: Komplexitaet, Kosten, Latenz, Datenschutz
Jeder Anbieter fuehrt mehrere Modelle, vom kleinen, schnellen und guenstigen bis zum grossen, langsamen und teuren. Die reflexhafte Wahl des staerksten Modells fuer alles ist fast immer falsch. Die bessere Methode: die Aufgabe ehrlich einordnen. Klassifikation, einfache Extraktion und Zusammenfassungen erledigen kleine Modelle meist genauso gut — bei einem Bruchteil der Kosten und deutlich geringerer Latenz. Mehrstufiges Schlussfolgern, heikle Formulierungsarbeit oder komplexe Tool-Nutzung rechtfertigen das grosse Modell. Neben Komplexitaet, Kosten und Antwortzeit spielt der Datenschutz in die Wahl hinein: Wo laufen die Daten durch, welche Vertraege zur Auftragsverarbeitung bietet der Anbieter, gibt es eine Verarbeitung in der EU, und duerfen die konkreten Daten den gewaehlten Weg ueberhaupt nehmen?
Zwei Praktiken haben sich in Projekten bewaehrt. Die erste: Modell-Versionen pinnen. Anbieter aktualisieren ihre Modelle regelmaessig, und ein Alias wie "das jeweils neueste Modell" kann sich unter der Hand aendern — mit ihm das Verhalten der Anwendung, ohne dass im eigenen Code eine Zeile angefasst wurde. Produktivsysteme sollten deshalb eine konkrete, datierte Modellversion ansprechen und Upgrades bewusst vollziehen: neue Version gegen die eigenen Testfaelle laufen lassen, Ergebnisse vergleichen, dann umstellen.
Die zweite: Modell-Routing. Statt eine Anwendung fest an ein Modell zu binden, entscheidet eine kleine Logik pro Anfrage, welches Modell sie bekommt. Die Routineklassifikation geht ans guenstige Modell, der komplizierte Grenzfall ans starke; manchmal uebernimmt sogar ein kleines Modell die Vorsortierung und reicht nur die schwierigen Faelle nach oben weiter. In datenintensiven Anwendungen senkt ein durchdachtes Routing die Kosten haeufig um einen zweistelligen Prozentsatz, ohne dass die Qualitaet messbar leidet.
Fazit: Vom Prototyp zum verlaesslichen System
Der Weg vom beeindruckenden Chat-Experiment zur belastbaren KI-Funktion in der eigenen Software fuehrt ueber eine Handvoll Konzepte: Token als Kosten- und Groesseneinheit, die Trennung von System- und User-Message, Temperature passend zur Aufgabe, Streaming fuer interaktive Oberflaechen, strukturierte Ausgaben und Tool-Calling fuer maschinenlesbare Ergebnisse — und drumherum die unspektakulaere, aber entscheidende Ingenieursarbeit aus Retries, Timeouts, Fallbacks und bewusster Modellwahl.
Drei naechste Schritte, wenn Sie eine Integration planen: Definieren Sie einen einzigen, klar umrissenen Anwendungsfall und formulieren Sie, woran Sie dessen Erfolg messen. Bauen Sie einen schmalen Durchstich mit strukturierten Ausgaben und einer gepinnten Modellversion, und legen Sie von Anfang an ein kleines Set eigener Testfaelle an, gegen das jede Aenderung laufen muss. Und kalkulieren Sie die Token-Kosten fuer Ihr realistisches Volumen, bevor die Funktion live geht — nicht danach. FJ Design unterstuetzt Unternehmen bei Konzeption und Umsetzung solcher LLM-Integrationen, von der Modellwahl bis zum Produktivbetrieb.