Start / Seminare / KI-Features im eigenen Produkt

Modul

Strukturierte Ausgaben statt Textparsen

6 Kapitel in diesem Modul-Video · Laufzeit

Vertonung mit synthetischer Stimme · Inhalte redaktionell verantwortet · © 2026 HECKER CONSULTING, alle Rechte vorbehalten

Transkript

Der gesprochene Text dieses Moduls zum Mitlesen, Überfliegen und Durchsuchen. Ein Klick auf einen Zeitstempel springt an die Stelle im Video.

Strukturierte Ausgaben

0:00 In diesem Modul geht es um eine Verschiebung, die klein aussieht und viel verändert: Sie bitten das Modell nicht mehr um ein Format, Sie geben eines vor. Das klingt nach einem technischen Detail, ist aber der Moment, in dem aus einem Textgenerator eine Komponente wird, mit der anderer Code arbeiten kann. Und es ist die erste Anwendung des Grundsatzes aus Modul eins: Was exakt sein muss, gehört aus dem Modell heraus — hier eben die Form.

Warum das Parsen von Freitext scheitert

0:25 Fangen wir mit dem an, was fast jeder zuerst probiert — und was fast jeder nach einigen Wochen bereut: die Antwort des Modells als Text entgegenzunehmen und mit einem regulären Ausdruck auseinanderzunehmen. Der Weg funktioniert erstaunlich gut, und genau darin liegt seine Tücke. Wir schauen uns an, wie er scheitert, warum das Scheitern so spät auffällt und was den Schaden am Ende so teuer macht.

0:47 Der übliche erste Versuch geht so: Man bittet das Modell höflich um ein Datenobjekt und liest die Antwort mit einem regulären Ausdruck aus. In neun von zehn Fällen klappt das wunderbar. Der zehnte ist das Problem — und zwar nicht, weil er häufig wäre, sondern weil er still ist. Es fliegt keine Ausnahme, es bricht nichts ab.

1:05 Stattdessen wandert ein leeres oder falsches Feld weiter durch die Verarbeitung und taucht drei Module später auf, an einer Stelle, an der niemand mehr an das Sprachmodell denkt. Diese vier Fälle sehen harmlos aus, und jeder einzelne hat schon Produktivsysteme lahmgelegt. Eine Erklärung vor dem Ergebnis verschiebt die Auswertung.

1:24 Eine Formatierungsmarkierung umschließt den Block, und plötzlich passt der reguläre Ausdruck nicht mehr. Ein Feld fehlt, weil es im konkreten Fall nicht anwendbar schien — das Modell meint es gut. Und ein Anführungszeichen im Freitext bricht die Struktur. Was diese vier verbindet: Sie treten selten auf, lassen sich schwer nachstellen, und jede Korrektur am regulären Ausdruck erzeugt den nächsten Sonderfall.

1:48 Teuer ist nicht der Fehler selbst, teuer ist die Distanz zwischen Ursache und Wirkung. Ein Fehler, der sofort auffliegt, kostet zehn Minuten. Ein Fehler, der sich als leeres Feld tarnt und drei Wochen später in einem Bericht auftaucht, kostet einen Tag Suche und ein Stück Vertrauen. Genau das ist hier der Fall. Und das Tückische: Die Fehlerquote wirkt niedrig genug, um sie zu ignorieren, und ist hoch genug, um regelmäßig zuzuschlagen.

2:13 Aus dieser Kombination entsteht die Neigung, immer weiter an der Auswertung zu flicken statt das Verfahren zu wechseln.

Das Schema als Vertrag

2:21 Der Ausweg ist erfreulich unspektakulär: Die Form wird nicht mehr erbeten, sondern vorgegeben. Damit verschiebt sich die Arbeit von der Nachbearbeitung in den Entwurf — und dorthin gehört sie auch, denn dort lässt sie sich diskutieren, prüfen und versionieren. In diesem Kapitel sehen wir, wie ein Schema aussieht, wie es dem Aufruf mitgegeben wird und woran man ein gutes Schema von einem überladenen unterscheidet.

2:44 Ein Schema beschreibt die erwartete Struktur und wird dem Aufruf mitgegeben. Die Antwort erfüllt die Struktur dann, statt sie zu imitieren — das ist der ganze Unterschied. Denken Sie an ein Formular gegenüber einem Brief: Beim Brief hoffen Sie, dass alle Angaben drinstehen; beim Formular ist jedes Feld an seinem Platz. Der eigentliche Gewinn liegt aber woanders.

3:05 Das Schema ist die einzige Stelle im ganzen Projekt, an der die Schnittstelle zwischen Modell und Anwendung schriftlich festgehalten ist. Es ist Dokumentation und Test in einem. Der Aufruf sieht fast aus wie der aus Modul zwei — mit einer zusätzlichen Angabe, die die Ausgabeform festlegt. Mehr ist es technisch nicht. Wichtig ist mir das Danach: Sie brauchen keinen regulären Ausdruck mehr, und Sie sollten auch keinen mehr schreiben.

3:30 Dasselbe Prinzip gilt übrigens für Werkzeugparameter, die wir in Modul sieben bauen — auch dort lässt sich die strikte Einhaltung des Schemas zusichern. Es ist derselbe Gedanke an zwei Stellen: Struktur ist nichts, was man nachträglich aus Text herausholt. Fünf Regeln, und die erste ist die wichtigste: Denken Sie vom nachfolgenden Code her, nicht vom Modell. Welche Felder braucht die Anwendung wirklich?

3:55 Danach: feste Wertelisten statt freier Zeichenketten, wo die Menge bekannt ist — das ist der größte Qualitätsgewinn pro Zeile Aufwand. Pflichtfelder nur dort, wo der Code ohne sie nicht auskommt. Ein ausdrücklicher Weg für Unwissen, dazu gleich mehr. Und die Schlussprüfung: Hat jedes Feld eine Fortsetzung im Code? Ein Feld, das niemand weiterverarbeitet, gehört nicht ins Schema.

Validierung an der Grenze

4:19 Die Form stimmt jetzt — das erledigt das Schema zuverlässig. Damit ist allerdings noch nichts darüber gesagt, ob der Inhalt fachlich Sinn ergibt. Eine erfundene Katalognummer erfüllt jedes Formatkriterium und ist trotzdem falsch. Genau hier setzt dieses Kapitel an: Ihre Validierung bekommt eine neue Aufgabe, und ihre Ergebnisse liefern nebenbei eine der aussagekräftigsten Kennzahlen über Ihr Feature.

4:43 Ihre Validierung bekommt eine neue Aufgabe. Sie prüft nicht mehr, ob die Antwort richtig aufgebaut ist — das erledigt das Schema. Sie prüft, ob sie fachlich plausibel ist: Existiert die Katalognummer überhaupt? Gehört sie zur genannten Baureihe? Liegt das Baujahr in einem möglichen Bereich? Diese Prüfung sitzt unmittelbar an der Systemgrenze, direkt hinter dem Aufruf.

5:05 Und ihr Ergebnis gehört protokolliert, denn die Quote fachlich unplausibler Antworten ist eine der aussagekräftigsten Kennzahlen, die Sie über Ihr Feature haben können. Schauen Sie auf die erste Zeile, denn sie fängt einen Fehler, den kein Formatprüfer sieht. Eine erfundene Katalognummer ist formal völlig einwandfrei — sie hat die richtige Länge, das richtige Muster, sie sieht aus wie eine echte. Nur gibt es sie nicht.

5:30 Solche Angaben sind der klassische Fall einer Erfindung, die glaubwürdig daherkommt, und sie werden ausschließlich durch den Abgleich mit den eigenen Stammdaten entdeckt. Nehmen Sie das als Muster: Jede Angabe, die es in Ihrer Welt entweder gibt oder nicht gibt, sollte gegen Ihre Welt geprüft werden.

Wenn das Schema nicht erfüllbar ist

5:47 Jetzt zum gefährlichsten Nebeneffekt strukturierter Ausgaben — und der entsteht genau dadurch, dass wir das Format erzwingen. Wenn die Antwort im Bestand nicht steht, muss das Modell die Felder trotzdem füllen. Was dann passiert, ist vorhersehbar. Die Gegenmaßnahme ist einfach und wird trotzdem selten eingebaut: Unwissen braucht einen eigenen, ausdrücklich erlaubten Weg durch das Schema.

6:10 Ein Schema erzwingt die Form, nicht den Inhalt. Wenn die Antwort auf die Frage in den Handbüchern schlicht nicht steht, muss das Modell die Felder trotzdem füllen — und es füllt dann, was plausibel klingt. Deshalb braucht jedes Schema einen ausdrücklichen Weg für Unwissen: ein Feld für „nicht beantwortbar", dazu eine Begründung.

6:29 Und dieser Weg muss nicht nur existieren, er muss in der Anweisung auch erlaubt sein. Sonst ist die Verweigerung für das Modell ein Regelverstoß — und es wird sie vermeiden. Sie sehen hier zwei Felder, und die feste Werteliste beim Grund ist kein Zufall. Sie zwingt zur Unterscheidung: Steht es nicht im Handbuch, widersprechen sich die Angaben, oder war die Frage unklar?

6:50 Das sind drei völlig verschiedene Befunde mit drei verschiedenen Konsequenzen. Der erste ist eine Lücke im Bestand, der zweite ein Pflegefall — den sehen wir in Modul sechs wieder —, der dritte ein Fall für eine Rückfrage. Aus einer Verweigerung wird so eine Information statt eines Achselzuckens.

Die Versuchung, alles zu erzwingen

7:08 Sobald strukturierte Ausgaben funktionieren, kommt der Appetit: noch ein Feld, noch eine Kategorie, noch ein Vertrauenswert. Über diesen Appetit möchte ich kurz sprechen, denn er führt verlässlich in eine Sackgasse. Mit jedem Feld wird die Aufgabe für das Modell schwerer, und manche Felder sind schlicht bedeutungslos, so überzeugend sie auch aussehen. Wir sehen uns an, wo die Grenze verläuft.

7:31 Der erste Punkt ist der wichtigste und wird am häufigsten falsch gemacht: Vertrauenswerte, die ein Modell über sich selbst angibt, sind nicht kalibriert. Eine Neun von Zehn bedeutet nicht, dass die Antwort in neunzig Prozent der Fälle stimmt. Sie darf deshalb im Code keine Schwelle steuern. Die anderen drei sind Entwurfsfragen: Klassifizierung, Antwort und Priorisierung in einem Aufruf zu verlangen, überfordert die Aufgabe.

7:56 Felder aufzunehmen, die niemand weiterverarbeitet, bläht sie auf. Und Freitext zu erzwingen, wo eine feste Liste möglich wäre, verschenkt Qualität. Das ist eine Erkenntnis, die den meisten Teams gegen den Strich geht, weil zwei Aufrufe nach Verschwendung aussehen. Rechnen Sie nach: Die Kosten unterscheiden sich kaum, weil sich die Arbeit ja nur verteilt.

8:17 Dafür lässt sich jede Stufe getrennt messen und getrennt verbessern — und das ist in Modul neun bares Geld wert. Die Fehlersuche wird erheblich leichter, weil Sie sehen, welche Stufe gepatzt hat. Und eine Stufe lässt sich später womöglich ganz durch Code ersetzen. Einfach schlagen kompliziert, auch hier.

Die Störungsmeldung als Datensatz

8:36 Zum Abschluss werden wir konkret und schauen uns das Schema an, mit dem wir die nächsten Module tatsächlich arbeiten: die Störungsmeldung der Talwerk- Hotline. Sie ist der erste Berührungspunkt zwischen Modell und Fachlichkeit — und sie ist bewusst so geschnitten, dass jedes einzelne Feld später wieder auftaucht. Genau daran können Sie hinterher Ihr eigenes Schema messen.

8:56 Diese Tabelle ist mir wichtiger, als sie aussieht. Rechts steht zu jedem Feld, wo es später wieder auftaucht: Baureihe und Baujahr filtern in Modul vier das Retrieval, die Baugruppe grenzt in Modul fünf die Suche ein, die Katalognummer wird in Modul sieben gegen den Bestand geprüft, die Dringlichkeit entscheidet über den Rückruf.

9:14 Kein Feld steht für sich. Genau das ist der Prüfstein für Ihr eigenes Schema: Wenn Sie zu einem Feld keine rechte Spalte hinschreiben können, gehört es nicht hinein. Jetzt sind Sie dran. Entwerfen Sie das Schema so, dass der nachfolgende Code ohne jede Textauswertung auskommt — feste Wertelisten, wo möglich, ein Weg für Unwissen, und zu jedem Feld eine benannte Fortsetzung.

9:36 Achten Sie auf eine Abgrenzung, die viele zuerst falsch ziehen: Die fachliche Prüfung der Katalognummer gehört bewusst nicht ins Schema, sondern hinter den Aufruf. Das Schema sagt, wie die Antwort aussieht. Ob sie zur Wirklichkeit passt, weiß nur Ihr Katalog. Und woher die Antwort überhaupt kommt, klären wir im nächsten Modul.

Lieber mit Trainer? Dieses Modul ist Teil unserer Team-Schulungen — mit Übungen, Ihrem eigenen Code und Fragen, die ein Video nicht beantwortet. Mehr erfahren →