Ent­schei­dungs­mo­delle

Ein Programm, das eingehende Anfragen verteilt, stellt an jeder Stelle dieselbe Art von Frage: Gehört das hierhin oder dorthin, trifft diese Bedingung zu, wie dringend ist das. Die Antwort ist jedes Mal ein Wert aus einer bekannten Liste. Ein Sprachmodell schreibt stattdessen einen Satz, und das Programm muss daraus den Wert herauslesen.

Ein Ent­schei­dungs­mo­dell gibt den Wert direkt zurück, und zu jedem möglichen Wert eine Wahr­schein­lich­keit. Ollama hat eine Schnittstelle dafür am 28.09.2026 mit Version 0.35.0 eingebaut. Die Release-Notizen (externe Seite, github.com) fassen die Sache in einem Satz: Ein Ent­schei­dungs­mo­dell liefert eine Auswahl, Wahr­schein­lich­keiten und Bewertungen, wo ein Sprachmodell Text liefert.

Eine Antwort aus einer Liste, die man selbst vorgibt

Eine Anfrage an ein Ent­schei­dungs­mo­dell hat zwei Teile. Der erste ist der Text, über den entschieden wird: ein Ticket, eine Nachricht, ein Datensatz. Der zweite ist die Frage samt der erlaubten Antworten. Heraus kommt eine dieser Antworten, nie etwas anderes.

Das Beispiel aus Ollamas Release-Notizen ist eine Kundenmeldung, nach der der Bezahlvorgang seit neun Uhr mit Serverfehlern abbricht. Gefragt ist, welches von drei Etiketten passt: Abrechnung, Softwarefehler oder Konto. Die Antwort lautet Softwarefehler, mit einer Wahr­schein­lich­keit von 97,8 Prozent, dazu 1,3 Prozent für Abrechnung und 0,9 Prozent für Konto (Beleg (externe Seite, github.com)). Die drei Zahlen addieren sich zu eins, weil nur diese drei Antworten zur Wahl standen.

Das Vorbild stammt von TypeSafe. Die Firma hat ihr Modell Jev am 15.09.2026 in einer Ankündigung (externe Seite, typesafe.ai) als neue Klasse von Spitzenmodellen vorgestellt, gebaut für schnelle, strukturierte Entscheidungen, die Software unmittelbar weiterverarbeiten kann. Die Klasse heißt dort System-One-Modelle, nach Daniel Kahnemans schnellem, intuitivem Denken (Beleg (externe Seite, docs.typesafe.ai)).

Die Liste steht in der Anfrage

Einordnen ist eine alte Aufgabe der KI, und Kapitel 04 beschreibt, wie ein Klassifikator sie löst: Die Liste der Klassen steht fest, bevor das Training beginnt, und was darin fehlt, kann nicht herauskommen. Wer eine neue Klasse braucht, trainiert neu.

Beim Ent­schei­dungs­mo­dell steht die Liste in jeder Anfrage. Heute sind es drei Etiketten für Tickets, morgen fünf Abteilungen oder die Frage, ob eine Rückgabe in der Frist liegt. Das Modell hat gelernt, aus einer vorgelegten Liste zu wählen, und kennt die einzelne Liste vorher nicht. Das ist die Eigenschaft, die es vom Klassifikator trennt, und sie hat es vom Sprachmodell, auf dem es aufbaut: Es versteht die Beschreibung einer Antwort in gewöhnlicher Sprache.

Die Wahrscheinlichkeit gehört zur Antwort

Ein Sprachmodell sagt nicht von selbst, wie sicher es sich ist, und wer danach fragt, bekommt wieder einen Satz. Ein Ent­schei­dungs­mo­dell liefert die Zahl mit. Aus ihr wird eine Entscheidung erst durch eine Schwelle: Liegt die Wahr­schein­lich­keit darüber, handelt das Programm, liegt sie darunter, geht der Fall an einen Menschen oder an ein größeres Modell.

Diese Schwelle legt der Betreiber fest, genau wie bei jedem Klassifikator. Wer sie hoch ansetzt, bekommt weniger Fehler und mehr Fälle zum Nachsehen. Und die Zahl selbst ist eine Aussage des Modells über sich. Ob sie stimmt, muss man an den eigenen Daten nachmessen. Bespoke Labs, der Hersteller eines der ersten offenen Ent­schei­dungs­mo­delle, schreibt das in seinem Repository (externe Seite, github.com) ausdrücklich: Auch eine Wahr­schein­lich­keit von 0,9 heißt nicht, dass die Antwort auf den eigenen Daten in 90 Prozent der Fälle stimmt.

Warum das so ist und wie man damit umgeht, steht auf der Ebene „Für Profis“.

Drei Arten von Fragen

Die Schnittstelle von Ollama kennt, wie ihr Vorbild, drei Formen (Beleg (externe Seite, github.com)):

• Auswahl (choice): eine Möglichkeit aus einer Liste, mit einer Wahr­schein­lich­keit für jede. Das Ticket-Beispiel oben ist eine.
• Ja oder nein (noul): die Wahr­schein­lich­keit, dass eine Bedingung zutrifft. Enthält die Nachricht eine Bitte um Erstattung?
• Einstufung (score): eine Stufe auf einer geordneten Skala, deren Stufen man beschreibt. Wie verärgert klingt die Kundin, von ruhig bis sehr verärgert?

Mehrere Fragen an denselben Text gehen in einer Anfrage.

Wofür man es einsetzt

Ollama nennt drei Aufgaben: Tickets sortieren, Anfragen an das passende Modell weitergeben und Inhalte einordnen (Beleg (externe Seite, github.com)). Gemeinsam ist ihnen, dass die Entscheidung klein ist, oft vorkommt und das Programm danach selbst weitermacht. Dort zählt, was ein Ent­schei­dungs­mo­dell billig macht: Es gibt ein einziges Token aus statt eines Satzes, kommt entsprechend schnell zurück, und die Antwort passt ohne Nacharbeit in den Code.

Wo eine Antwort begründet, formuliert oder zusammengefasst werden muss, ist es das falsche Werkzeug. Es kann keinen Text schreiben, auch keine Begründung für seine eigene Wahl.

Woran Sie den Einsatz festmachen

• Steht die Liste der Antworten fest und gibt es viele Beispiele? Dann ist ein eigens trainierter Klassifikator meist billiger und genauer. Wechselt die Liste oder fehlen Beispiele, spricht das für ein Ent­schei­dungs­mo­dell.
• Gibt es eine Antwort für keinen der Fälle? Das Modell wählt immer eine der erlaubten, auch wenn keine passt. Also eine anbieten.
• Ist die Schwelle an eigenen Daten eingestellt? Eine Stichprobe mit bekannten Antworten ist die einzige Grundlage dafür.
• In welcher Sprache sind die Texte? Die heutigen Modelle sind vor allem auf Englisch trainiert.

Wie das Modell unter der Haube zu seiner Zahl kommt, zeigt die Ebene „Mit Vorwissen“. Welche Modelle es gibt und was Hersteller und ein erster Vergleich von außen messen, steht im Beitrag Ent­schei­dungs­mo­delle geben eine Auswahl mit Wahr­schein­lich­keit zurück.

Wer Grundkurs, Kapitel 12 gelesen hat, kennt den Aufbau schon zur Hälfte. Ein Sprachmodell rechnet für jedes mögliche nächste Token einen Rohwert, macht daraus eine Rangliste mit Wahr­schein­lich­keiten, und ein Programm zieht daraus ein Token. Ein Ent­schei­dungs­mo­dell hört eine Stufe früher auf.

Bewertet werden nur die erlaubten Antworten

Die beiden offenen Modelle, mit denen Ollama die Schnittstelle eröffnet hat, sind beide feinjustierte Sprachmodelle. Nimble von Bespoke Labs ist ein LoRA-Adapter für Qwen3.5-9B, und seine Modellkarte (externe Seite, huggingface.co) beschreibt den Kern in einem Halbsatz: Das Modell bewertet die erlaubten Antwort-Tokens unmittelbar. Das Repository erklärt, wie (Beleg (externe Seite, github.com)):

1. Jede erlaubte Antwort bekommt einen Code, der genau ein Token lang ist, etwa einen Buchstaben.
2. Das Modell liest den Text, die Frage und die Liste der Codes mit ihren Beschreibungen.
3. Es rechnet wie jedes Sprachmodell für das nächste Token einen Rohwert je Token des Vokabulars, im Fachjargon Logits.
4. Das Programm liest davon nur die Werte der erlaubten Codes ab und rechnet sie mit der Softmax-Funktion in Wahr­schein­lich­keiten um, die sich zu eins addieren.

Die Rangliste, beschnitten auf die zulässigen Antworten, ist schon das Ergebnis; eine Ziehung folgt nicht mehr. Die Antwort mit der höchsten Wahr­schein­lich­keit gilt als gewählt. Deshalb meldet Ollamas Beispielantwort genau ein Token Ausgabe (Beleg (externe Seite, github.com)), und deshalb kann das Modell keine Antwort geben, die nicht auf der Liste steht: Es gibt für sie keinen Wert, der abgelesen würde.

Seit Version 0.35.1 gehören laut den Release-Notizen (externe Seite, github.com) auch Clef und Clef Flash von Cloudflare dazu. Beide beurteilen auch Bilder und verlangen laut Ollamas Doku (externe Seite, docs.ollama.com) mindestens diese Version. Der Aufbau wird hier an Nimble und Tev1 erklärt.

Ollamas eigene Umsetzung arbeitet nach demselben Muster. Laut dem Kopf ihres Quelltexts übersetzt sie jede typisierte Frage in eine Eingabe, deren Antwortkandidaten das Modell bewertet, und rechnet aus den Rohwerten die Antwort (Beleg (externe Seite, github.com)).

Ein Buchstabe als Antwort, der zweite Weg

Tev1 von Together AI geht den einfacheren Weg. Es ist ein Fine-Tuning von Qwen3.5-4B, das gelernt hat, auf Zustand, Frage und zwei bis 24 beschriftete Möglichkeiten mit genau einem Buchstaben zu antworten (Beleg (externe Seite, huggingface.co)). Es erzeugt diesen Buchstaben wie jedes Sprachmodell, bei Temperatur null und mit höchstens acht Token Ausgabe. Wahr­schein­lich­keiten liefert es über die Log-Wahr­schein­lich­keiten der Buchstaben, die das Beispielskript im Repository mit ausgibt (Beleg (externe Seite, github.com)).

Der Unterschied liegt im Detail. Bei Nimble ist die Liste der möglichen Ausgaben technisch geschlossen, bei Tev1 hat das Modell nur gelernt, sich an sie zu halten. Die Karte von Tev1 nennt als Grenze, dass eine gewöhnliche Chatanfrage wieder Fließtext erzeugen kann. Beide Modelle entstanden mit wenigen Trainingsdaten: Nimble mit 2.676 Beispielen (Beleg (externe Seite, github.com)), Tev1 mit 37.840 (Beleg (externe Seite, github.com)).

Und Jev, das Vorbild? TypeSafe spricht von einer neuen Architektur, einem parallelen Abtastverfahren und einem eigenen Trai­nings­ver­fahren und legt keines davon offen (Beleg (externe Seite, typesafe.ai)). Von außen ist nur die Schnittstelle zu sehen.

Was aus den drei Fragearten im Innern wird

Die Ebene „Überblick“ hat die drei Fragearten eingeführt. Im Innern sind es Varianten derselben Rechnung:

• Auswahl: Jede Möglichkeit bekommt ihren Code, die Softmax läuft über alle. Nimble erlaubt bis zu 255 Möglichkeiten je Frage (Beleg (externe Seite, huggingface.co)).
• Ja oder nein: eine Auswahl mit zwei Codes. Ausgegeben wird die Wahr­schein­lich­keit, dass die Bedingung zutrifft (Beleg (externe Seite, github.com)).
• Einstufung: Die Stufen sind Codes wie 0, 1, 2, und neben der gewählten Stufe liefert Nimble einen mit den Wahr­schein­lich­keiten gewichteten Mittelwert (Beleg (externe Seite, huggingface.co)). Liegt die Wahr­schein­lich­keit zur Hälfte auf Stufe 1 und zur Hälfte auf Stufe 2, ergibt das 1,5. Ein solcher Wert sagt mehr als die gewählte Stufe allein, denn er zeigt, dass das Modell zwischen zwei Stufen schwankt.

Mehrere Fragen an denselben Text

Eine Anfrage darf mehrere Fragen enthalten, und das spart Rechenzeit: Der Text, meistens der längste Teil, wird einmal eingelesen. Nimble tut das auf einem Mac so und bewertet danach alle Fragen parallel (Beleg (externe Seite, github.com)).

Jede Frage wird dabei für sich bewertet. Die Antwort auf die eine sieht die andere nicht. Fragt man, ob eine Nachricht eine Erstattung verlangt und welche Abteilung zuständig ist, kann ein Ja bei der ersten und die Abteilung Konto bei der zweiten herauskommen. Ob das zusammenpasst, prüft das eigene Programm. Das Repository von Nimble schreibt es ausdrücklich so hin.

Die Mechanik ist älter als der Name

Ein Sprachmodell, das einordnet, statt zu schreiben, gibt es auf dieser Seite schon im Kapitel Conversational AI, Kapitel 07. Metas Llama Guard stuft Eingaben und Antworten als sicher oder unsicher ein, und die Zahl dafür stammt aus der Wahr­schein­lich­keit des ersten Tokens, das es erzeugt. Den Rest beschreibt die Modellkarte (externe Seite, huggingface.co): Wer das Modell einsetzt, legt an diese Wahr­schein­lich­keit eine Schwelle seiner Wahl an und trifft damit eine Ja-Nein-Entscheidung.

Das ist die Ja-Nein-Frage eines Ent­schei­dungs­mo­dells, mit einer fest eingebauten Frage. Neu ist, dass die Frage und ihre Antworten mit jeder Anfrage wechseln, dass es dafür eine eigene Schnittstelle gibt und dass Modelle eigens auf diese Form trainiert werden.

Was eine strukturierte Ausgabe anders macht

Viele Anbieter können die Antwort eines Sprachmodells an ein Schema binden, sodass sie immer gültiges JSON mit den erwarteten Feldern ist; Grundkurs, Kapitel 15 beschreibt das. Auch damit bekommt ein Programm eine Antwort aus einer festen Liste.

Die Wahr­schein­lich­keit fehlt dort. Das Schema erzwingt die Form und sagt nichts darüber, wie knapp die Wahl war. Und das Modell schreibt weiter Token für Token, bei einem langen Schema also viele. Ein Ent­schei­dungs­mo­dell braucht für jede Frage eines.

Was daraus für die Praxis folgt

• Die Liste der Antworten ist Teil der Frage. Jede Beschreibung einer Möglichkeit wirkt auf das Ergebnis, also lohnt es sich, sie so sorgfältig zu schreiben wie eine Anweisung.
• Mehrere Fragen an einen Text sind billig, aber jede steht für sich. Abhängigkeiten zwischen den Antworten gehören ins Programm.
• Ein Modell, das nur gelernt hat, sich an die Liste zu halten, braucht eine Prüfung, ob die Antwort auf der Liste steht. Bei einem, das nur die erlaubten Tokens bewertet, entfällt sie.

Wie verlässlich die Zahlen sind, die dabei herauskommen, ist die Frage der Ebene „Für Profis“.

Ein Ent­schei­dungs­mo­dell verkauft sich über seine Zahl. Wer es einsetzt, stellt eine Schwelle ein und lässt das Programm oberhalb davon allein entscheiden. Diese Ebene fragt, was die Zahl wert ist, wovon sie abhängt und wie man sie nachprüft.

Kalibrierung heißt, dass die Zahl zur Trefferquote passt

Ein Modell ist gut kalibriert, wenn es von allen Antworten, die es mit 90 Prozent angibt, auch ungefähr neun von zehn richtig hat. Das ist eine Aussage über viele Antworten. TypeSafe, dessen Jev ausdrücklich auf kalibrierte Wahr­schein­lich­keiten trainiert ist, schreibt es in die eigene Doku zu System One (externe Seite, docs.typesafe.ai): Kalibrierung wird über Gruppen von Vorhersagen gemessen und sagt für die einzelne Antwort nicht zu, dass sie stimmt.

Über den einzelnen Fall sagt die Zahl also wenig. Sie wird brauchbar, wo viele gleichartige Entscheidungen anfallen und die Schwelle an ihnen eingestellt ist.

Vortrainiert gut kalibriert, nachtrainiert schlechter

Dass Sprachmodelle ihre Sicherheit bei Auswahlfragen gut einschätzen können, ist gemessen. Eine Arbeit von Anthropic aus dem Jahr 2022 fand große Modelle bei Auswahl- und Wahr-falsch-Fragen gut kalibriert, sofern die Frage im passenden Format steht (Beleg (externe Seite, arxiv.org)). OpenAIs Bericht zu GPT-4 (externe Seite, arxiv.org) misst dasselbe an Auswahlfragen aus dem Wissenstest MMLU, über die Wahr­schein­lich­keit der Antwortbuchstaben A bis D, also genau die Mechanik eines Ent­schei­dungs­mo­dells. Das vortrainierte Modell lag gut. Das Nachtraining hat die Kalibrierung nach dem Bericht deutlich verschlechtert, zu sehen in seiner Abbildung 8.

Jedes Ent­schei­dungs­mo­dell ist nachtrainiert, denn das Fine-Tuning auf die Entscheidungsform ist ein Nachtraining. Ob seine Zahlen danach stimmen, ist deshalb eine eigene Frage, und die Hersteller beantworten sie verschieden. TypeSafe nennt ein eigenes Trai­nings­ver­fahren für kalibrierte Entscheidungen. Together AI schreibt über Tev1, die Kalibrierung sei noch nicht systematisch geprüft (Beleg (externe Seite, huggingface.co)). Im Repository (externe Seite, github.com) heißen die Log-Wahr­schein­lich­keiten deshalb Vorlieben des Modells; eine kalibrierte Sicherheit sind sie dort ausdrücklich nicht.

Die Temperatur ändert die Zahlen und lässt die Wahl stehen

Bei der Umrechnung der Rohwerte in Wahr­schein­lich­keiten lässt sich eine Temperatur einsetzen: Die Rohwerte werden vor der Softmax durch eine Zahl geteilt. Ist sie größer als eins, rücken die Wahr­schein­lich­keiten zusammen, ist sie kleiner, rücken sie auseinander. Die Reihenfolge der Antworten bleibt dabei gleich, und damit die gewählte. Die Stellschraube ist dieselbe wie in Grundkurs, Kapitel 12, hier dient sie der Kalibrierung: Man sucht an Beispielen mit bekannter Antwort die Temperatur, bei der die Zahlen am besten zur Trefferquote passen.

Nimble hat genau das durchlaufen, und zwar zweimal in drei Tagen. Am 22.09.2026 bekam das Modell eine angepasste Temperatur, und das Repository (externe Seite, github.com) hält fest, was das bedeutet: Das Modell wählt dieselben Antworten wie vorher. Die Wahr­schein­lich­keiten der Ja-Nein-Fragen und die Werte der Einstufungen änderten sich dagegen, und der Hersteller rät, jede Schwelle neu zu prüfen. Am 24.09. ersetzte ein neuer Checkpoint das Modell, und laut Modellkarte (externe Seite, huggingface.co) ist für ihn bisher keine eigene Temperatur angepasst worden.

Eine Schwelle gehört also zu einer Fassung des Modells. TypeSafe zieht daraus dieselbe Folgerung für den eigenen Dienst: Wer Schwellen an einer Fassung eingestellt hat, soll deren feste Kennung verwenden statt eines Namens, der mit jeder neuen Fassung weiterwandert (Beleg (externe Seite, docs.typesafe.ai)).

Unsicherheit als eigene Kennzahl

Neben den Wahr­schein­lich­keiten liefert die Schnittstelle ein Feld für die Sicherheit der Antwort insgesamt. Die Idee ist einfach: Liegt fast alles auf einer Antwort, ist die Entscheidung klar; verteilt es sich gleichmäßig, hat das Modell keinen Favoriten. TypeSafe beschreibt die Kennzahl in der Doku zur Sicherheit (externe Seite, docs.typesafe.ai) als Statistik, die aus der Wahr­schein­lich­keits­ver­tei­lung gerechnet wird, die die Antwort ohnehin mitliefert. Die Firma schlägt dazu drei Bereiche vor: automatisch handeln, nachfragen, an einen Menschen geben.

Wie man die Gleichmäßigkeit misst, ist eine Entscheidung. Zwei Wege liegen nahe: die höchste Wahr­schein­lich­keit ins Verhältnis zur Zahl der Möglichkeiten setzen, oder die Entropie der Verteilung messen, das Maß der Infor­ma­ti­ons­theorie für Streuung. Beide ergeben null bei völliger Gleichverteilung und eins bei völliger Gewissheit, dazwischen gehen sie auseinander. TypeSafe und Ollama haben sich für verschiedene Wege entschieden, bei gleichem Feldnamen; die Zahlen dazu stehen im Beitrag Ent­schei­dungs­mo­delle geben eine Auswahl mit Wahr­schein­lich­keit zurück. TypeSafe liefert deshalb die vollen Wahr­schein­lich­keiten mit und sagt ausdrücklich, dass man eine eigene Kennzahl daraus bilden kann.

Wie man die Schwelle einstellt

Die Arbeit ist dieselbe wie bei jedem Klassifikator, und Kapitel 04 beschreibt sie auf der Ebene „Für Profis“ als Entscheidung über zwei Kosten. Für ein Ent­schei­dungs­mo­dell heißt das:

1. Eine Stichprobe aus dem eigenen Bestand nehmen, groß genug, dass auch seltene Antworten darin vorkommen, und die richtige Antwort von Hand festlegen.
2. Das Modell darauf laufen lassen und je Schwelle zählen, wie viele Fälle es allein entscheiden würde und wie viele davon falsch wären.
3. Die Schwelle dort setzen, wo die Zahl der Fehler zu dem passt, was ein Fehler an dieser Stelle kostet. Bei einer Aktion, die sich nicht zurücknehmen lässt, liegt sie höher als bei einer Anzeige.
4. Den Lauf wiederholen, wenn das Modell, die Temperatur oder die Beschreibung der Antworten sich ändert.

Bespoke Labs empfiehlt genau diesen Weg und schreibt dazu, dass die eigene Messung von Nimble synthetische Referenzantworten aus nur sechs Quellfamilien nutzt und damit ein enger Test ist (Beleg (externe Seite, github.com)). Together AI nennt seine 880 von 1.000 richtigen Entscheidungen im Repository (externe Seite, github.com) Ent­wick­lungs­er­geb­nisse: Der Prüfsatz wurde während der Entwicklung mitbenutzt, ein unberührter Abschlusstest ist er damit nicht. Eine Herstellerzahl ersetzt die eigene Stichprobe in keinem der Fälle.

Wo ein eigens trainierter Klassifikator vorne liegt

Stehen die Klassen fest, liegen genug beschriftete Beispiele vor und ändert sich die Aufgabe selten, ist ein kleiner Klassifikator, der nur diese eine Aufgabe gelernt hat, schneller und billiger im Betrieb. Er lässt sich an genau diesen Daten kalibrieren, und bei mittelgroßen Datenmengen in Tabellenform liegen Verfahren auf Basis von Ent­schei­dungs­bäumen weiterhin vorne, wie Kapitel 04 belegt.

Ein Ent­schei­dungs­mo­dell ist dort im Vorteil, wo die Liste der Antworten mit jeder Anfrage wechselt, wo es kaum Beispiele gibt oder wo sich die Kriterien leichter in Sätzen beschreiben als in Daten sammeln lassen. Eine Mischform liegt nahe und steht in TypeSafes eigener Doku: Das Ent­schei­dungs­mo­dell erzeugt aus freiem Text Merkmale, und ein klassisches Verfahren wird darauf trainiert (Beleg (externe Seite, docs.typesafe.ai)).

Was daraus nicht folgt

• Eine hohe Wahr­schein­lich­keit heißt, dass das Modell unter den angebotenen Antworten keine bessere gesehen hat. Passt keine davon, bekommt auch die falsche Antwort eine hohe Zahl.
• Ein Modell, das keinen Text schreibt, kann sich trotzdem irren. TypeSafe wirbt damit, Jev könne nicht halluzinieren (Beleg (externe Seite, typesafe.ai)), und meint die Form der Antwort: Sie steht immer auf der Liste. Ob es die richtige ist, bleibt offen.
• Die Einordnung fremder Texte bleibt angreifbar. Der Text, über den entschieden wird, kann Anweisungen enthalten, und Together AI nennt Prompt Injection bei Tev1 ausdrücklich als ungeprüft (Beleg (externe Seite, huggingface.co)).