TypeChat: Schemata statt Prompt-Bastelei

Das Problem: Absichten aus Text, ohne Entscheidungsbäume

Wer eine natürlichsprachliche Oberfläche baut, kennt das Muster: Ein Satz wie "Bestell mir zwei Tickets für Freitag" muss in eine strukturierte Aktion übersetzt werden. Klassisch löst man das mit Entscheidungsbäumen, die Absicht und Parameter abfragen. Das README beschreibt genau diese Ausgangslage und nennt die Alternative: LLMs erkennen die Absicht direkt. Damit kommen neue Probleme, die das Projekt selbst benennt: Die Antwort des Modells muss eingeschränkt werden, sie muss für die Weiterverarbeitung strukturiert sein, und sie muss gültig sein. Prompt-Engineering adressiert das laut README, bringt aber eine steile Lernkurve und wachsende Fragilität mit, je länger der Prompt wird. TypeChat richtet sich an Entwickler, die eine definierte Menge von Intents haben und diese lieber als Typen beschreiben als als Prompt-Text. Das ist ein enges, aber klar umrissenes Ziel.

Schemata als Vertrag: Typen definieren, Modell füllt sie

Der Kern ist ein Wechsel der Perspektive, den das README als "schema engineering" bezeichnet. Statt dem Modell in Prosa zu erklären, was es tun soll, definiert man TypeScript-Typen, die die unterstützten Intents abbilden. Das kann ein einfaches Interface zur Sentiment-Klassifikation sein oder ein komplexeres Modell für einen Warenkorb. Erweiterung funktioniert über discriminated unions: Ein neuer Intent ist ein neuer Typ in der Union. Hierarchische Schemata entstehen über ein "meta-schema", das abhängig von der Nutzereingabe ein oder mehrere Sub-Schemata auswählt. Der Vertrag liegt damit im Typsystem, nicht im Prompt. Das ist der eigentliche Unterschied zu freien Prompt-Ansätzen: Die Struktur ist versionierbar und reviewbar wie anderer Code.

Der Ablauf in drei Schritten, inklusive Reparaturrunde

Das README beschreibt drei Aufgaben, die die Bibliothek übernimmt. Erstens baut sie aus den Typen einen Prompt an das LLM. Zweitens validiert sie die Antwort gegen das Schema. Schlägt die Validierung fehl, repariert sie die nicht konforme Ausgabe durch weitere Interaktion mit dem Sprachmodell. Drittens fasst sie die Instanz zusammen, ausdrücklich ohne LLM, damit der Nutzer bestätigen kann, dass das Ergebnis der Absicht entspricht. Der dritte Punkt ist der unterschätzteste: Eine deterministische Zusammenfassung ist prüfbar, eine modellgenerierte Zusammenfassung wäre es nicht. Die Reparaturrunde ist gleichzeitig der kostspielige Teil. Jede zusätzliche Runde bedeutet einen weiteren Modellaufruf, und die Latenz hängt damit direkt davon ab, wie oft das Modell das Schema verfehlt. Das README nennt keine Obergrenze für Reparaturversuche und keine Angaben dazu, wie die Bibliothek bei wiederholt ungültigen Antworten verfährt.

Installation und der Weg über die Beispiele

Der Einstieg ist knapp dokumentiert. Für TypeScript und JavaScript lautet der Befehl:

npm install typechat

Das README verweist für Python auf ./python/README.md und für C#/.NET auf das separate Repository microsoft/TypeChat.net. Der TypeScript-Pfad liegt unter ./typescript/README.md, die Beispiele unter ./typescript/examples. Wer den Ablauf sehen will, soll laut README die Beispielprojekte lokal oder in einem GitHub Codespace ausprobieren. Das ist der praktikabelste Einstieg, weil das README selbst keine Konfigurationsschlüssel, keine Umgebungsvariablen und kein Codebeispiel für die Schema-Definition zeigt. Wer wissen will, wie ein Modell angebunden wird, welche Modellanbieter unterstützt werden oder wie das meta-schema konkret aussieht, muss die Dokumentation unter microsoft.github.io/TypeChat oder den Beispielcode heranziehen. Aus dem vorliegenden Material lässt sich das nicht beantworten.

Wo TypeChat das falsche Werkzeug ist

Die Bibliothek setzt voraus, dass es überhaupt ein Schema gibt. Für offene Dialoge, Zusammenfassungen von Freitext oder Aufgaben, bei denen die Antwortform variieren darf, ist der Validierungsschritt kein Gewinn, sondern ein Hindernis. Ein zweiter Grenzfall: Wenn das gewählte Modell unzuverlässig JSON liefert, wird die Reparaturrunde zum Regelfall statt zur Ausnahme. Das README beschreibt die Reparatur als Mechanismus, nicht als Randfall, was nahelegt, dass nicht konforme Ausgaben eingeplant sind. Wer ein Modell ohne verlässliche strukturierte Ausgabe verwendet, zahlt die Kosten in Latenz und Token-Verbrauch. Drittens: Die Qualität des Ergebnisses hängt an der Schema-Gestaltung. Ein zu grob geschnittenes Schema lässt dem Modell zu viel Spielraum, ein zu feines erzeugt mehr Validierungsfehler. Das README gibt hier keine Heuristik an die Hand. Und schließlich ist TypeChat kein Ersatz für Autorisierung: Dass eine Aktion schema-konform ist, sagt nichts darüber aus, ob sie ausgeführt werden darf.

Abgrenzung zu freiem Prompt-Engineering

Die naheliegende Alternative ist der direkte Weg: einen eigenen Prompt mit JSON-Anweisung und einen JSON-Parser plus Validierung selbst bauen. Der Unterschied liegt nicht in der Antwortqualität des Modells, sondern in der Verantwortung für die Struktur. Beim Selbstbau liegt der Prompt als String im Code, Änderungen an der erwarteten Form sind Textänderungen ohne Typprüfung. TypeChat zieht die Struktur in das Typsystem und macht sie damit für den Compiler sichtbar. Der Preis dafür ist Bindung: Die Schemata müssen in TypeScript vorliegen, und die Bibliothek gibt den Ablauf vor. Wer bereits eine eigene Validierungsschicht mit Zod, JSON Schema oder ähnlichem betreibt, baut mit TypeChat eine zweite, parallele Struktur auf. Ein weiterer Unterschied ist die Zusammenfassung ohne LLM. Wer selbst einen zweiten Modellaufruf zur Bestätigung nutzt, erzeugt eine nicht deterministische Kontrollinstanz; TypeChat vermeidet das konstruktiv.

Pflege, Lizenz und was vor dem Einsatz zu klären ist

Das Repository steht unter der MIT-Lizenz, was die Nutzung und Weitergabe auch in kommerziellen Projekten erlaubt. Wer zum Projekt beitragen will, muss laut README einen Contributor License Agreement über den CLA-Bot akzeptieren, einmalig pro Repository. Für die Nutzung der Bibliothek selbst entsteht daraus keine Verpflichtung. Der Hinweis auf Marken und Logos im README betrifft die Verwendung von Microsoft-Marken, nicht den Code. Zur Pflege lässt sich aus dem Material wenig Sicheres sagen: Das Repository ist nicht archiviert, der letzte Push auf main wird mit 2026-08-28 angegeben, und es wurden keine Releases abgerufen. Ob und in welchem Rhythmus neue Versionen erscheinen, geht daraus nicht hervor. Wer TypeChat produktiv einsetzt, sollte die Abhängigkeit deshalb selbst beobachten und im eigenen Lockfile festhalten, welche Version im Einsatz ist. Ein Kostenfaktor, den das README nicht beziffert, ist der Token-Verbrauch: Jeder Aufruf enthält den aus den Typen erzeugten Prompt, und jede Reparaturrunde kommt hinzu.

Redaktionelles Fazit

TypeChat passt für Teams, die natürlichsprachliche Eingaben in klar typisierte Aktionen überführen wollen und bereit sind, ihre Typdefinitionen als Vertrag mit dem Modell zu pflegen. Wer nur Freitext oder offene Dialoge braucht, greift zu einem einfachen Chat-Wrapper ohne Schema. Vor dem Einsatz sollte man prüfen, ob das eigene Modell zuverlässig JSON liefert, wie viele Reparaturrunden die eigene Schema-Komplexität erzeugt und ob die MIT-Lizenz zu den eigenen Compliance-Vorgaben passt.

Offizielle Quellen

1. Issues
2. License: MIT
3. microsoft/TypeChat on GitHub
4. Project website
5. README