Was ein Sprachmodell im Produkt wirklich leistet

Sprachmodelle im Produkt

0:00 Fast jedes KI-Projekt beginnt mit einem guten Nachmittag. Jemand baut einen Prototyp, stellt drei Fragen, bekommt drei überzeugende Antworten — und alle im Raum sind sich einig, dass das ins Produkt gehört. Ein halbes Jahr später steht dasselbe Projekt still. Nicht, weil das Modell schlecht wäre, sondern weil niemand sagen kann, ob es heute besser oder schlechter antwortet als im Mai.

0:23 Genau diese Lücke schließen wir in diesem Seminar. Wir bauen den Prototyp zwar auch — aber die eigentliche Arbeit beginnt danach.

Vom Prototyp zum Produkt

0:31 Fangen wir mit der ehrlichsten Feststellung an, die man über KI-Features machen kann: Der schwierige Teil ist nicht der, den man in der Vorführung sieht. Was danach kommt, hat mit dem Modell selbst erstaunlich wenig zu tun — es sind Fragen nach Herkunft, Prüfbarkeit, Rechten und Kosten. In diesem ersten Kapitel schauen wir uns an, woran der Übergang vom Prototyp zum Produkt tatsächlich hängt. Sie bekommen dabei zugleich den Fahrplan für die nächsten drei Tage.

0:58 Stellen Sie sich den Unterschied wie bei einem Hausbau vor: Der Rohbau steht schnell und sieht beeindruckend aus. Bewohnbar wird das Haus aber erst durch alles, was danach kommt — Leitungen, Dämmung, Abnahme. Bei einem KI-Feature sind das vier Dinge: Die Antwort muss belegt sein, damit jemand sie prüfen kann. Sie muss gemessen werden, damit man Verschlechterungen bemerkt.

1:20 Sie muss begrenzt sein, damit ein Fehlgriff nicht teuer wird. Und sie muss bezahlbar bleiben. Der Prototyp zeigt von alledem nichts. Er zeigt nur: Das Modell kann antworten. Diese vier Punkte klingen nach Bürokratie, sind aber die Diagnose gescheiterter Projekte. Der wichtigste steht ganz oben: Niemand kann sagen, ob eine Änderung am Prompt geholfen hat. In gewöhnlichem Code merkt man einen Rückschritt, weil ein Test rot wird.

1:46 Hier wird nichts rot — die Antwort kommt weiter, klingt weiter gut, ist nur seltener richtig. Dazu kommt, dass eine falsche Antwort exakt so flüssig formuliert ist wie eine richtige. Es gibt also kein Warnsignal in der Sprache selbst. Wer das akzeptiert, versteht, warum Messung in diesem Seminar so viel Raum bekommt. Diese Tabelle ist zugleich der Ablaufplan der nächsten drei Tage.

2:10 Sie werden merken, dass wir uns strikt daran entlanghangeln: erst die Frage, woher das Wissen kommt, dann die Frage, wie man einer Antwort ansieht, dass sie stimmt, dann die Messung, dann die Grenzen, und ganz am Ende der Betrieb. Diese Reihenfolge ist kein Zufall. Jede Zeile setzt die darüber voraus — Belege funktionieren nur mit ordentlichem Retrieval, und Messung funktioniert nur mit Belegen.

2:32 Behalten Sie die Tabelle im Kopf, wir kommen mehrfach darauf zurück.

Aufgabentypen und ihre Trefferquote

2:37 Bevor wir bauen, sortieren wir. Denn ein KI-Feature ist kein Ding, sondern eine ganze Familie sehr unterschiedlicher Aufgaben — vom Klassifizieren über das Extrahieren bis zur freien Auskunft auf eigenem Bestand. Diese Aufgaben unterscheiden sich erheblich darin, wie verlässlich sie sind und wie leicht ein Fehler auffällt.

2:55 Wer sie im Projekt nicht auseinanderhält, verspricht am Ende etwas, das der gewählte Aufgabentyp gar nicht leisten kann. Lesen Sie die Tabelle nicht als Rangliste, sondern als Risikokarte. Ganz oben stehen Aufgaben mit kleiner Ausgabe — klassifizieren, extrahieren. Da ist ein Fehler sichtbar, weil man das Ergebnis gegen bekannte Beispiele halten kann.

3:16 Je weiter Sie nach unten kommen, desto größer wird die Ausgabe und desto schwerer die Prüfung. Die vorletzte Zeile ist die interessante: Frage und Antwort auf eigenem Bestand ist das, was neunzig Prozent aller Kunden bestellen — und der Fall mit den meisten unbemerkten Fehlern. Die letzte Zeile ist die einzige, bei der die Antwort schlicht lautet: gar nicht ins Modell.

3:37 Diese Sortierung ist kein akademisches Vergnügen, sie hat vier sehr praktische Folgen. Sie bestimmt, wie streng Sie Belege verlangen müssen. Sie entscheidet, was überhaupt ins Modell gehört und was in gewöhnlichen Code. Sie macht den Prüfaufwand vorher abschätzbar, statt ihn im Projektverlauf zu entdecken. Und sie schützt Sie vor Zusagen, die das Feature nachher nicht halten kann.

3:59 Wenn Sie aus diesem Kapitel eine Sache mitnehmen, dann diese: Sagen Sie im Projekt nie „wir machen was mit KI", sondern immer, um welchen dieser Aufgabentypen es geht.

Wann kein Sprachmodell die richtige Wahl ist

4:09 Und jetzt das Kapitel, das man von einem KI-Seminar am wenigsten erwartet: wann Sie besser gar kein Modell einsetzen. Das ist keine Koketterie. Ein erheblicher Teil dessen, was als KI-Feature beauftragt wird, ist mit vorhandenen Mitteln schneller, billiger und zuverlässiger gelöst. Wir gehen gleich eine kurze Prüfung durch, die eine Stunde dauert — und die in Projekten regelmäßig Monate spart, weil sie die Frage vor dem Bauen stellt statt danach.

4:35 Diese fünf Fragen gehen Sie von oben nach unten durch, und die Reihenfolge ist Absicht: Die billigste Lösung wird zuerst geprüft. Hat die Eingabe ein festes Format, genügt ein Parser — der ist schneller und immer richtig. Gibt es feste Kategorien und Beispieldaten, ist ein klassischer Klassifikator überlegen und braucht nicht einmal eine Netzverbindung.

4:55 Suchen Ihre Nutzer nach wörtlichen Treffern, ist eine Volltextsuche ehrlicher. Und wenn ein Fehler nicht auffallen würde, aber teuer wäre, ist ein Sprachmodell schlicht das falsche Werkzeug. Erst was danach übrig bleibt, lohnt den Aufwand. Diese vier Fallen haben eines gemeinsam: Sie entstehen nicht aus Unwissen, sondern aus Erwartungsdruck.

5:16 Ein Modell einzusetzen, weil es im Zielbild der Geschäftsführung steht, ist der häufigste Fall — und er lässt sich nur mit Zahlen entschärfen, nicht mit Meinung. Der zweite ist technischer Natur: Exakte Nachschlagevorgänge dem Modell zu überlassen, statt ein Werkzeug zu bauen. Der dritte ist der Trost über eine schlechte Trefferquote hinweg, weil die Vorführung so gut lief.

5:37 Und der vierte ist Aufwand für Retrieval, bevor überhaupt jemand weiß, welche Fragen die Nutzer stellen.

Die Ausgangslage bei Talwerk

5:43 Damit das alles nicht abstrakt bleibt, arbeiten wir die nächsten drei Tage an einem einzigen durchgehenden Fall. Er ist erfunden, aber so gebaut, dass er die Probleme enthält, die Ihnen im eigenen Projekt begegnen werden: ein großer Dokumentenbestand, wiederkehrende Fragen, Berechtigungen, schreibende Vorgänge und ein Fehler, der Geld kostet.

6:02 Lernen Sie ihn jetzt kennen — wir kommen in jedem der folgenden Module auf ihn zurück. Talwerk baut Lastenräder und beliefert Fachwerkstätten. Zweihundert Anrufe am Tag laufen bei der Hotline auf: Ein Antriebsstrang macht Geräusche, eine Bremse lässt sich nicht entlüften, ein Ersatzteil passt nicht zum Baujahr. Die Antwort steht fast immer in den Servicehandbüchern — nur sind das vierzehn Stück über sechs Baureihen und neun Jahre, dazu Nachträge, und niemand kennt sie vollständig.

6:30 Genau das ist die Situation, in der ein KI-Feature seinen Wert zeigt: viel Text, wiederkehrende Fragen, und Menschen, die heute ein halbes Jahr brauchen, bis sie eigenständig auskunftsfähig sind. Ich habe diesen Fall aus vier Gründen gewählt, und der vierte ist mir der wichtigste. Es gibt viel Text und wiederkehrende Fragen — gut für Retrieval.

6:50 Es gibt ein messbares Ziel, nämlich die Einarbeitungszeit. Es gibt einen bezifferten Preis für einen Fehler: Ein falsches Ersatzteil kostet eine Anfahrt. Und es gibt schreibende Vorgänge — einen Rückruf anlegen, ein Teil vormerken. Damit können wir Rechte, Bestätigungen und Angriffswege an einem realistischen Beispiel durchspielen, statt sie theoretisch abzuhandeln.

7:12 Ein reiner Frage-Antwort-Fall wäre bequemer und würde die halbe Wahrheit auslassen. Werfen Sie einen Blick auf die letzten beiden Zeilen, denn dort steckt eine Entscheidung, die viele Projekte falsch treffen. Die Ticketschreibung ist wertvoll — dort stehen frühere Fälle. Sie ist zugleich unser größtes Sicherheitsproblem, weil Werkstätten selbst hineinschreiben, und wir werden in Modul zehn sehen, was ein Angreifer damit anfangen kann.

7:36 Das Bestandssystem wiederum gehört ausdrücklich nicht in den Index: Bestandszahlen ändern sich stündlich, ein indizierter Auszug ist am Tag nach dem Aufbau falsch. Solche Daten holt man über ein Werkzeug, und das bauen wir in Modul sieben.

Was ein KI-Feature vom übrigen Code unterscheidet

7:50 Jetzt wird es grundsätzlich. Drei Eigenschaften unterscheiden ein KI-Feature von jedem anderen Stück Software, das Sie bisher geschrieben haben. Alle drei klingen zunächst nach Theorie und haben doch sehr handfeste Folgen für den Entwurf: Sie bestimmen, wie Sie testen, wie Sie überwachen und wie Sie mit einem Anbieterwechsel umgehen.

8:08 Ich stelle sie hier vor, weil die Antworten darauf das Rückgrat der letzten beiden Module bilden. Der erste Punkt ist bekannt: Dieselbe Eingabe kann zweimal verschieden beantwortet werden. Der zweite ist der gefährlichere, und er wird selten ausgesprochen — die Verschlechterung ist lautlos. Ein schlechterer Prompt wirft keine Ausnahme, er liefert weiter etwas, das aussieht wie vorher.

8:31 Und der dritte: Sie hängen an einer fremden Komponente, die sich unter Ihnen bewegt und die nicht in Ihrem Repository liegt. Kein einziger dieser Punkte ist ein Argument gegen den Einsatz. Sie sind das Argument dafür, anders zu bauen als gewohnt. Diese Tabelle ist die Antwort auf die drei Punkte von eben, und sie ist zugleich das Inhaltsverzeichnis für die letzten beiden Module dieses Seminars.

8:54 Was nicht deterministisch ist, prüft man nicht auf Gleichheit, sondern misst es statistisch an einer Menge von Fällen. Was lautlos schlechter wird, braucht einen Goldstandard und einen Regressionslauf. Und was sich unter einem bewegt, braucht einen geplanten Wechselvorgang statt eines Notfalls. Ich sage das so früh, weil diese drei Antworten kein Beiwerk sind, das man am Ende noch anbaut. Sie bestimmen, wie das Feature von Anfang an aussieht.

9:20 Alle vier Fallen entstehen dadurch, dass man Gewohnheiten aus gewöhnlichem Code überträgt. Tests, die auf Zeichengleichheit prüfen, sind der Klassiker — sie schlagen bei jeder harmlosen Umformulierung fehl und werden deshalb nach zwei Wochen abgeschaltet. Prompts in einer Datenbank zu pflegen fühlt sich flexibel an und nimmt Ihnen Review und Historie. Das Modell fest zu verdrahten fällt erst auf, wenn die Abkündigung kommt.

9:44 Und Qualität am Eindruck einzelner Antworten zu messen ist menschlich völlig verständlich — und statistisch wertlos.

Nichtdeterminismus als Entwurfsproblem

9:51 Kommen wir zu der einen Entwurfsentscheidung, die dieses ganze Seminar zusammenhält. Sie ist in einem Satz zu formulieren und überraschend schwer durchzuhalten, weil sie einen Reflex durchbricht: Man versucht zunächst, schwankende Antworten wegzukonfigurieren. Wir gehen den anderen Weg und grenzen das Variable ein, statt es zu bekämpfen. Wenn Sie aus diesem Modul eine Sache mitnehmen, dann die aus dem folgenden Kapitel.

10:15 Die übliche Reaktion auf schwankende Antworten ist der Versuch, sie wegzukonfigurieren — Zufälligkeit senken, engere Anweisungen. Das hilft ein Stück und löst das Problem nicht. Der bessere Weg ist ein anderer: Grenzen Sie das Variable ein, statt es zu bekämpfen. Zahlen, Bezeichner und Zustände kommen aus Werkzeugen. Die Form der Ausgabe kommt aus einem Schema. Die Belege kommen aus dem beigelegten Text. Variabel bleiben darf am Ende die Formulierung — und nur sie.

10:44 Wenn Sie sich einen Satz aus diesem Modul merken, dann diesen. Diese fünf Schritte sehen banal aus und werden trotzdem fast nie gemacht. Schreiben Sie zuerst auf, welche Teile der Antwort exakt stimmen müssen. Suchen Sie dann für jeden dieser Teile eine Quelle außerhalb des Modells. Legen Sie die Form der Ausgabe als Schema fest, statt sie im Prompt zu erbitten.

11:06 Und definieren Sie für den Rest, woran man eine gute Formulierung erkennt. Erst danach schreiben Sie den Prompt. Wer in umgekehrter Reihenfolge arbeitet — erst Prompt, dann Struktur — verbringt anschließend Wochen damit, das Modell zu überreden, was eine Zeile Code erledigt hätte. Genau das machen Sie jetzt selbst, und zwar auf Papier.

11:26 Nehmen Sie eine typische Antwort der Hotline und zerlegen Sie sie in ihre Bestandteile: Welche Angabe kommt aus einem Werkzeug, welche aus einer Handbuchstelle, welche ist reine Formulierung? Erfolgreich sind Sie, wenn keine einzige Angabe ohne Zuordnung bleibt. Und wenn Sie eine finden, die sich partout nicht zuordnen lässt — halten Sie inne.

11:46 Sie haben dann in aller Regel keine technische Lücke gefunden, sondern eine fachliche Anforderung, die bisher niemand geklärt hat. Das ist der wertvollste Fund dieser Übung.

Vier Fragen vor jedem KI-Feature

11:56 Zum Abschluss dieses Moduls vier Fragen, die vor jedem KI-Feature beantwortet sein sollten — schriftlich, nicht im Kopf, und vor der ersten Zeile Code. Sie wirken wie eine Formalie und sind das Gegenteil davon: Jede der vier Antworten wird später zu einem Bauteil, das wir in diesem Seminar tatsächlich bauen. Wer sie überspringt, beantwortet sie trotzdem — nur später und unter Druck.

12:19 Woran erkennen wir eine gute Antwort? Nicht im Gefühl, sondern an einem konkreten Beispiel, das jemand aufgeschrieben hat. Was ist der Schaden einer falschen Antwort, und wer merkt sie überhaupt? Woher stammt das Wissen, und wer pflegt es — denn Wissen ohne Zuständigkeit veraltet still. Und schließlich: Was darf das Feature auslösen, und was ausdrücklich nicht? Vier Fragen, eine halbe Stunde Arbeit.

12:45 Wer sie überspringt, beantwortet sie trotzdem — nur später und unter Druck. Und hier sehen Sie, warum sich der Aufwand lohnt: Jede der vier Antworten wird später zu einem Bauteil. Ihr Beispiel für eine gute Antwort ist der erste Fall des Goldstandard-Datensatzes, mit dem wir in Modul neun messen. Ihre Einschätzung des Schadens bestimmt, wie streng die Belegpflicht ausfällt. Die Frage nach dem Wissen ist die Retrieval-Aufgabe der Module vier und fünf.

13:11 Und die Frage nach dem Auslösen ist das Rechtemodell aus den Modulen sieben und zehn. Die vier Fragen sind also keine Vorbereitung auf die Arbeit — sie sind bereits ein Teil davon. Zum Schluss die Übung, die Sie mit ins eigene Projekt nehmen. Beantworten Sie die vier Fragen für ein Vorhaben aus Ihrem Alltag — je einen Satz.

13:31 Für Frage eins brauche ich mehr: ein ausformuliertes Beispiel einer guten Antwort, so konkret, dass ein Kollege daran messen könnte. Genau dieses Beispiel ist später der Ausgangspunkt Ihrer Evaluierung. Wer gerade kein eigenes Vorhaben hat, nimmt die Talwerk-Hotline. Und im nächsten Modul wird es dann handfest: Wir schreiben den ersten Aufruf, der mehr aushält als eine Vorführung.