Worum es geht: Ein Sprachmodell einzubinden ist technisch unspektakulär: Sie schicken ein Wörterbuch los und bekommen eines zurück. Interessant sind die vier Punkte drumherum – Schlüssel, Kosten, Fehler und Prüfung der Antwort. Genau die entscheiden, ob aus einem Versuch etwas Betriebsfähiges wird.
1. Der Ablauf
Jeder Aufruf besteht aus denselben Teilen: das Modell, eine Obergrenze für die Antwortlänge, der Gesprächsverlauf als Liste von Nachrichten und der Schlüssel im Kopf der Anfrage. Zurück kommt eine Antwort mit dem Text und einer Abrechnung der verbrauchten Token. Im anschließenden Lab bauen Sie genau das Schritt für Schritt selbst.
2. Der Schlüssel
Der zweite Übungsschritt ist der wichtigste der ganzen Lektion. Ein Schlüssel im Code landet in Git, und wenn das Projekt öffentlich ist, wird er innerhalb von Minuten automatisch abgegriffen und benutzt – auf Ihre Rechnung. Der Schlüssel gehört in eine .env-Datei, die in der .gitignore steht, und wird zur Laufzeit aus der Umgebung gelesen.
Auf dem Server wird er als Umgebungsvariable gesetzt, nicht als Datei hochgeladen. Und er gehört niemals in Code, der im Browser läuft – dort ist er für jeden sichtbar, der die Entwicklerwerkzeuge öffnet.
.env in der .gitignore? Diese eine Frage verhindert den teuersten Anfängerfehler im Umgang mit KI-Schnittstellen.3. Kosten im Blick behalten
Abgerechnet wird nach Token – grob ein Token je drei bis vier Zeichen. Eingabe ist deutlich billiger als Ausgabe. Der vierte Übungsschritt zeigt, warum die Rechnung wichtig ist: Ein einzelner Aufruf mit viel Kontext kostet wenige Cent, tausend davon am Tag ergeben eine Summe, die vorher niemand veranschlagt hat.
| Hebel | Wirkung |
|---|---|
| Kontext kürzen | Der größte Hebel – nur mitgeben, was gebraucht wird |
max_tokens begrenzen | Verhindert unerwartet lange und teure Antworten |
| Kleineres Modell für einfache Aufgaben | Sortieren und Einordnen braucht selten das größte Modell |
| Ergebnisse zwischenspeichern | Dieselbe Frage zweimal zu stellen kostet zweimal |
4. Fehler einplanen
Schnittstellen antworten nicht immer. Häufig sind: Überlastung mit Statuscode 429, Zeitüberschreitungen und vorübergehende Serverfehler. Alle drei behandelt man gleich – erneut versuchen, mit wachsendem Abstand zwischen den Versuchen, und nach drei Fehlversuchen aufgeben und das dem Aufrufer sagen.
Wichtig ist der letzte Teil. Ein Ablauf, der bei einem Fehler stillschweigend nichts tut, ist schlimmer als einer, der abbricht: Niemand merkt, dass etwas fehlt, bis ein Kunde nachfragt.
5. Die Antwort prüfen
Ein Modell liefert Text, keine Wahrheit. Wenn Sie strukturierte Daten erwarten – etwa ein JSON-Objekt mit bestimmten Feldern –, dann verlangen Sie das Format ausdrücklich und prüfen Sie es nach dem Empfang, bevor Sie damit weiterarbeiten. Fehlt ein Feld oder steht dort Text statt einer Zahl, ist das kein Sonderfall, sondern ein normaler Betriebszustand.
In Python bietet sich dafür eine kleine Prüfung mit einem Datenmodell an. Der Aufwand von zehn Zeilen verhindert, dass eine unerwartete Antwort später an ganz anderer Stelle zu einem unverständlichen Fehler führt.
6. Häufige Fragen
Brauche ich die Bibliothek des Anbieters? Nötig ist sie nicht – ein einfacher HTTP-Aufruf genügt. Sie nimmt aber Arbeit ab: Wiederholungsversuche, Streaming und Typen sind bereits eingebaut.
Was ist mit Datenschutz? Sobald personenbezogene Daten an einen Anbieter gehen, braucht es eine Rechtsgrundlage und einen Vertrag zur Auftragsverarbeitung. Für viele Aufgaben lassen sich die Daten vorher anonymisieren – das ist der einfachere Weg.
Wie testet man so etwas? Indem man die Antwort im Test durch eine feste Beispielantwort ersetzt. So laufen Tests ohne Kosten, ohne Netz und mit immer demselben Ergebnis.
Stand: September 2026. Die Übungen laufen vollständig in Ihrem Browser – es wird nichts gespeichert oder übertragen.