Der erste belastbare Aufruf

Der erste belastbare Aufruf

0:00 Einen Aufruf an ein Sprachmodell zu schreiben, dauert zwei Minuten. Einen zu schreiben, der im Produktivbetrieb aushält, dauert etwas länger — und es sind nicht die Stellen, die man erwartet. Es geht nicht um die Wahl der Zufälligkeit oder um besonders raffinierte Formulierungen. Es geht darum, den Abbruchgrund auszuwerten, Fehler richtig zu klassifizieren, Token zu zählen statt zu schätzen und den Prompt wie Quelltext zu behandeln.

0:24 Vier unspektakuläre Dinge, die den Unterschied zwischen einem Prototypen und einem Feature ausmachen, das man jemandem in die Hand geben kann.

Anatomie einer Anfrage

0:33 Beginnen wir mit den Bestandteilen eines Aufrufs. Es sind fünf Stück, und sie sauber auseinanderzuhalten klingt nach Ordnungsliebe. Tatsächlich hat es zwei sehr handfeste Folgen: Es entscheidet darüber, ob die Zwischenspeicherung greift und Sie deutlich weniger zahlen, und es entscheidet darüber, wie leicht sich Ihre Regeln durch fremden Text aushebeln lassen.

0:52 Beide Themen kommen später ausführlich wieder — hier legen wir die Grundlage dafür. Ein Aufruf besteht aus der Modellangabe, einer Systemanweisung, dem Nachrichtenverlauf, den Werkzeugdefinitionen und Angaben zur Ausgabe. Das klingt nach einer Aufzählung, die man überfliegen kann — bis auf einen Punkt: Die Reihenfolge ist nicht beliebig.

1:12 Stellen Sie sich den Prompt wie ein Fließband vor, an dessen Anfang immer dieselben Teile liegen und an dessen Ende das Wechselnde eingelegt wird. Stabiles nach vorn, Veränderliches nach hinten. Warum das mehr ist als Ordnungsliebe, sehen wir gleich — und in Modul elf noch einmal, wenn es um Geld geht. Was Sie hier sehen, ist bewusst unspektakulär: die Systemanweisung als eigene Größe, die Frage als Nutzernachricht, dazwischen nichts.

1:38 Zwei Dinge sind daran wichtig, und keines davon ist Syntax. Erstens liegt die Systemanweisung in einer eigenen Datei im Repository, nicht als Zeichenkette mitten im Code — dazu kommen wir im letzten Kapitel dieses Moduls ausführlich. Zweitens steht sie vor der Frage, nicht dahinter. Diese eine Zeile Reihenfolge entscheidet später darüber, ob die Zwischenspeicherung greift oder ob Sie jeden Aufruf voll bezahlen.

2:03 Vier Gründe, und der letzte ist der tückischste. Der stabile Anfang lässt sich zwischenspeichern und wird dadurch deutlich billiger. Regeln, die in der Systemanweisung stehen, sind schwerer durch fremden Text zu überschreiben — ein Sicherheitsargument, das in Modul zehn wiederkommt. Beim Debuggen sehen Sie sofort, was Konfiguration war und was Eingabe. Und dann der vierte: Ein einziger Zeitstempel im Vorspann macht die Zwischenspeicherung unwirksam.

2:29 Ohne Fehlermeldung, ohne Warnung — Sie zahlen einfach das Mehrfache und merken es in der Monatsrechnung.

Systemanweisung und Nutzernachricht trennen

2:36 Damit zum häufigsten Übertrag aus dem Prototyp: alles in eine einzige lange Nachricht zu schreiben — Rolle, Regeln, Beispiele, Kontext und die eigentliche Frage. Das funktioniert auf Anhieb, und genau deshalb bleibt es oft so. Wir sehen uns jetzt an, was wohin gehört und warum die Trennung mehr ist als eine Frage des Stils.

2:55 Eine Zeile in der folgenden Tabelle ist sogar eine handfeste Sicherheitsregel. Die ersten fünf Zeilen sind Handwerk, die letzte ist eine Sicherheitsregel, und über die möchte ich kurz sprechen. Die Kennung der Werkstatt gehört nirgendwohin in den Prompt — sie kommt aus der Sitzung. Der Grund ist einfach: Alles, was im Prompt steht, kann das Modell auch anders wieder herausgeben.

3:17 Wenn die Identität ein Parameter ist, den das Modell füllt, dann kann es eine andere Identität füllen. Merken Sie sich diese Zeile; wir bauen in Modul zehn ein ganzes Rechtemodell darauf auf. Vier Fallen, die alle aus derselben Bequemlichkeit entstehen. Regeln in die Nutzernachricht zu schreiben ist die schwerwiegendste, weil fremder Text sie dort überschreiben kann.

3:39 Beispiele bei jedem Aufruf neu zusammenzubauen zerstört den Cache, ohne dass irgendetwas kaputtgeht. Die Frage vor die Fundstellen zu setzen führt dazu, dass die Fundstellen weniger beachtet werden — was viele erst nach Tagen der Prompt-Optimierung entdecken. Und Identitäten als Text in den Prompt zu geben ist, wie ich eben sagte, keine Abkürzung, sondern eine offene Tür.

Was die Parameter wirklich bewirken

4:00 Jetzt zu den Stellschrauben — und zu einer Erkenntnis, die viele überrascht: Die wichtigste Größe eines Aufrufs ist gar keine Stellschraube, die Sie setzen. Sie kommt in der Antwort zurück. Wir schauen uns an, was die Parameter tatsächlich bewirken, welche Missverständnisse sich hartnäckig halten und warum der Abbruchgrund in jeden produktiven Aufruf gehört.

4:21 Zwei Missverständnisse räumen wir hier aus. Die maximale Ausgabelänge ist keine Bitte an das Modell, sich kurz zu fassen — sie ist eine harte Grenze, an der die Antwort mitten im Satz abgeschnitten wird. Und eine niedrige Zufälligkeit macht Antworten gleichförmiger, aber nicht richtiger; sie ersetzt keine Prüfung. Wichtiger als beides ist der Abbruchgrund, den die Antwort mitbringt.

4:43 Er sagt Ihnen, ob das Modell fertig war, ob es an die Längengrenze gestoßen ist, ob es ein Werkzeug aufrufen will oder ob es abgelehnt hat. Diese vier Zeilen sind das Gerüst jedes produktiven Aufrufs. Was ich Ihnen mitgeben möchte, ist die zweite: Wenn die Längengrenze erreicht wurde, haben Sie keine kurze Antwort bekommen, sondern eine abgeschnittene.

5:04 Wer nur auf den Text zugreift, merkt davon nichts — die Anwendung verarbeitet einen halben Satz und findet ihn plausibel. Das ist der häufigste stille Fehler in Code, der aus einem Prototypen übernommen wurde. Die dritte Zeile führt uns übrigens direkt zu Modul sieben, wenn wir Werkzeuge bauen. Drei Zeilen, und sie stehen bewusst vor dem Zugriff auf den Inhalt — das ist die ganze Pointe.

5:27 Erst prüfen, ob die Antwort vollständig ist, dann prüfen, ob sie überhaupt eine Antwort ist, und erst danach den Text anfassen. Sie werden diesen Block in jedem Aufruf brauchen, und deshalb gehört er nicht in jeden Aufruf kopiert, sondern in eine gemeinsame Funktion. Was Sie im Fehlerfall tun, ist eine fachliche Entscheidung: erneut anfordern, die Aufgabe teilen oder die Nutzerin sauber informieren.

5:49 Was Sie nicht tun dürfen, ist weitermachen, als sei nichts gewesen.

Streaming und die wahrgenommene Geschwindigkeit

5:54 Kommen wir zu einem Thema, das nach Oberflächenkosmetik aussieht und in Wirklichkeit eine Entwurfsentscheidung ist. Streaming verändert nicht, wie schnell eine Antwort fertig ist — es verändert, wie schnell sie zu lesen beginnt. Das klingt nach einem Detail für die Kollegin aus dem Frontend. Es hat aber eine Konsequenz, die bis in die Sicherheitsfrage reicht, und deshalb besprechen wir es hier und nicht nebenbei.

6:17 Streaming ändert nichts an der Gesamtdauer — die Antwort ist genauso spät fertig wie vorher. Was sich ändert, ist die gefühlte Wartezeit, und die ist für die Akzeptanz eines Features entscheidender als jede Sekunde auf der Stoppuhr. Dazu kommen drei technische Gründe: Lange Antworten laufen ohne Streaming eher in Zeitüberschreitungen, bei großen Ausgabegrenzen verlangen die SDKs es ohnehin, und die Nutzerin kann abbrechen, was bares Geld spart.

6:42 In interaktiven Oberflächen ist Streaming deshalb der Normalfall, nicht die Kür. Und jetzt die Kehrseite, die gern übersehen wird. Sobald Sie streamen, können Sie die Antwort nicht mehr vollständig prüfen, bevor die Nutzerin sie sieht. Wer also eine Ausgabefilterung braucht, muss sich früh entscheiden — nachträglich ist das ein Umbau der Oberfläche, kein Schalter.

7:03 Die übrigen drei Punkte sind Handwerk: den fertigen Text nicht von Hand zusammensetzen, sondern den Helfer des SDK nehmen; und Fehler mitten im Strom behandeln, statt eine halbe Antwort stehen zu lassen und zu hoffen, dass es niemandem auffällt.

Fehler, Wiederholungen und Zeitgrenzen

7:17 Der Aufruf eines Modells ist ein Netzaufruf gegen einen fremden Dienst, und er sollte auch so behandelt werden. Das klingt selbstverständlich, sieht im Code aber oft anders aus: eine weite Ausnahmebehandlung, die alles fängt, und eine Wiederholung, die alles noch einmal versucht. Wir schauen uns deshalb die Fehlerarten einzeln an und klären, welche man wiederholen darf und welche mit Sicherheit nicht.

7:40 Die entscheidende Trennlinie verläuft zwischen den ersten beiden Zeilen und dem Rest. Eine ungültige Anfrage ist ein Programmierfehler: Die Wiederholung liefert exakt dasselbe Ergebnis und kostet nur Zeit. Überlastung, Serverfehler und Verbindungsabbrüche dagegen sind vorübergehend und dürfen wiederholt werden — mit wachsendem Abstand und einer Obergrenze.

8:01 Und ein Detail, das oft übersehen wird: Zeitgrenzen werden bei jedem Versuch neu gezählt. Ihre tatsächliche Wartezeit ist also Zeitgrenze mal Anzahl der Versuche. Das gehört zusammen betrachtet, sonst wartet Ihre Oberfläche minutenlang. Der häufigste Fehler steht oben: Fehlermeldungen mit Zeichenkettenvergleich zu erkennen.

8:20 Die Bibliotheken bringen eigene Fehlerklassen mit, und die überleben auch eine geänderte Formulierung auf Anbieterseite. Der zweite ist die eine weite Ausnahmebehandlung, die alles fängt und deshalb auch aussichtslose Fälle wiederholt. Und der letzte ist eine echte Falle für Umsteiger: Die Einheiten der Zeitgrenze unterscheiden sich je nach SDK — mal Sekunden, mal Millisekunden.

8:42 Ein Faktor tausend fällt in der Entwicklung nicht auf, im Betrieb schon.

Token zählen statt schätzen

8:46 Kommen wir zu einer Größe, die fast jedes Team am Anfang schätzt — und bei der fast jedes Team danebenliegt. Token sind die Einheit, in der abgerechnet wird und in der das Kontextfenster bemessen ist. Wer sie mit einer Faustregel aus englischem Fließtext abschätzt, erlebt bei deutschen Fachtexten eine Überraschung. Sehen wir uns an, warum das so ist und an welchen Stellen gemessen statt geraten wird.

9:09 Die bekannte Faustregel stammt aus englischem Fließtext, und genau den haben wir hier nicht. Deutsche zusammengesetzte Wörter zerfallen in überraschend viele Teile. Teilenummern und Fehlercodes sind teurer, als sie aussehen — jedes Sonderzeichen zählt. Text aus PDF bringt unsichtbare Zeichen mit, die niemand sieht und alle bezahlen.

9:29 Und bei einem Modellwechsel kann sich die Zählung verschieben, ohne dass sich an Ihrem Text etwas geändert hätte. Deshalb gilt hier eine einfache Regel: messen, nicht raten. Vier Stellen, und keine davon ist optional. Beim Entwurf prüfen Sie, ob das Vorhaben überhaupt ins Kontextfenster passt — das erspart Ihnen unter Umständen eine ganze Architektur.

9:51 Vor dem Aufruf entscheiden Sie, wie viele Fundstellen mitgehen; dazu kommen wir in Modul fünf. Im Betrieb werten Sie die Kosten je Anfragetyp aus, denn nicht jede Frage ist gleich teuer. Und nach einem Modellwechsel bestimmen Sie die Grundlinie neu. Für all das gibt es eine eigene Funktion in der API — benutzen Sie die, nicht eine selbstgebaute Heuristik.

Der Prompt gehört in die Versionsverwaltung

10:13 Zum Abschluss dieses Moduls eine Regel, die technisch trivial und in der Praxis folgenreich ist. Es geht darum, wo ein Prompt eigentlich lebt — in einer Datenbank, in einer Umgebungsvariablen oder im Repository. Die Antwort entscheidet darüber, ob Sie später nachvollziehen können, wie eine bestimmte Antwort entstanden ist.

10:31 Und sie ist die Voraussetzung für alles, was wir in Modul neun über Messung sagen werden. Prompts werden erstaunlich oft wie Konfiguration behandelt: ein Feld in einer Datenbank, eine Umgebungsvariable, etwas, das man mal eben ändert. Das ist bequem und macht das Feature unprüfbar, denn niemand kann rekonstruieren, mit welchem Text eine bestimmte Antwort entstanden ist. Ein Prompt ist Quelltext.

10:55 Er gehört ins Repository, ins Codereview, in die Historie und in die Tests. Eine Änderung daran ist eine Änderung am Produktverhalten — und die behandelt man nicht anders als eine Änderung an einer Berechnungsroutine. Fünf Schritte, die zusammen etwa einen halben Tag Einrichtung kosten. Eigene Dateien statt eingebetteter Zeichenketten.

11:15 Ein Versionsbezeichner, der bei jedem Aufruf mitprotokolliert wird — das ist die Brücke zwischen einer schlechten Antwort im Betrieb und der Fassung, die sie erzeugt hat. Änderungen im Codereview begründen. Vor der Auslieferung gegen den Goldstandard laufen lassen. Und alte Fassungen behalten, damit ein Rückschritt möglich bleibt.

11:35 Wer diese fünf Punkte hat, kann später mutig am Prompt arbeiten, statt sich davor zu fürchten. Damit sind Sie dran. Bauen Sie den Aufruf so, dass er im Betrieb etwas über sich selbst verrät: System und Nutzernachricht getrennt, Abbruchgrund ausgewertet, wiederholbare Fehler von endgültigen unterschieden, Prompt-Version und Tokenzahl protokolliert.

11:55 Wer schneller fertig ist, ergänzt eine Wiederholung mit wachsendem Abstand und Obergrenze. Das Ergebnis ist noch kein KI-Feature — es ist das Fundament, auf dem alles Weitere steht. Im nächsten Modul sorgen wir dafür, dass die Antwort nicht mehr als Text zurückkommt, den jemand auseinandernehmen muss.