TypeSafe AI Jev im Test: Wie gut ist das neue Modell für KI-Klassifikation?

Am 15. September 2026 hat TypeSafe AI sein erstes öffentliches Modell vorgestellt: Jev; zugeschnitten auf Klassifikationsaufgaben (TypeSafe AI, 2026a). Statt mit Text antwortet es mit Zahlen und bei Auswahlfragen zusätzlich mit der gewählten Option aus einer vorgegebenen Liste. Typische Fragen sind „Ist das Spam?“, „Welches Team ist zuständig?“ oder „Wie dringend ist das?“. TypeSafe nennt die Zahlen Wahrscheinlichkeiten und Modelle dieser Art „System One“, nach dem schnellen, intuitiven Denken, das der Psychologe Daniel Kahneman als System 1 beschrieben hat (Kahneman, 2011).¹

Klassifikation selbst ist nichts Neues. Klassische Modelle dafür gibt es seit Jahrzehnten, allerdings muss man sie für jede Aufgabe eigens trainieren. Spätestens seit GPT-3 lassen sich LLMs auch ohne eigenes Training als Klassifikatoren nutzen: Man lässt sie eine feste Liste von Antworten bewerten und liest bei Bedarf dabei Wahrscheinlichkeiten ab (Brown et al., 2020). Technisch ermöglicht Jev also keine neue Art der Anwendung. Es senkt Kosten und Wartezeit und bietet eine einfachere, direktere Schnittstelle. Damit könnten sich Anwendungen erschließen, die bisher wegen Datenmenge, Kosten oder Wartezeit nicht gut abgedeckt waren.

In diesem Beitrag teilen wir die Ergebnisse unserer ersten Experimente mit und unsere Eindrücke von Jev. Im ersten Teil beschreiben wir, was Jev neu macht, welche Funktionen es vorher schon gab und was wir in eigenen Tests beobachtet haben. Im Anschluss daran ordnen wir nach unserer Einschätzung ein, wo wir Potenzial und Grenzen sehen. Dabei betrachten wir Jev nicht nur als Produkt, sondern als Vertreter einer neuen Modellklasse, die sich etablieren könnte.

Die wichtigsten Einschränkungen vorab:

• Antworten auf zusammenhängende Fragen können sich widersprechen; Jev eignet sich vor allem für einzelne Klassifikationen.
• Dieselbe Anfrage liefert über mehrere Läufe leicht unterschiedliche Zahlen.
• Ob die Wahrscheinlichkeiten für die eigenen Daten stimmen, muss man selbst prüfen.
• Jev ist ein allgemeiner Klassifikator; für sehr eigene Kategorien sollte man nicht zu viel erwarten.
• Eine Begründung liefert Jev nicht.
• Das Produkt Jev gibt es nur als Dienst, gehostet in den USA; offene Nachbauten lassen sich selbst betreiben.

Was kann Jev?

Bei Jev besteht eine Anfrage aus dem State, also dem, worüber entschieden wird (eine Kundennachricht, ein Dokument, ein Datensatz, als Text oder als Objekt mit benannten Feldern), und einer oder mehreren Fragen dazu. TypeSafe beschreibt das als „frontier-intelligence function call: unstructured state in, typed probabilistic decisions out“ (TypeSafe AI, 2026a). Jede Frage hat einen von drei Typen (TypeSafe AI, 2026b):

Das folgende Beispiel stellt zu einem Support-Ticket je eine Frage jedes Typs, alle drei in einer Anfrage. Ist sich Jev beim Team weniger als 80 % sicher, prüft ein Mensch das Ticket.

Eindeutige Tickets ordnet Jev mit 0,99 oder 1,00 zu. Das Ticket aus dem Codebeispiel ist absichtlich uneindeutig: Ein falscher Betrag nach einem App-Update kann ein Fehler der App oder der Abrechnung sein. Mit 0,68 für die Abrechnung landet es bei einem Menschen.

Eine solche Anfrage ist billig und schnell: Laut TypeSafe kostet eine Million Token Eingabe 0,042 USD, die Ausgabe nichts. Eine Anfrage darf bis zu 64.000 Token umfassen und dauert 70 bis 500 ms, in unseren Tests rund 300 ms (TypeSafe AI, 2026c). Jev verarbeitet nur Text und bevorzugt Englisch.

Welche Funktionen gab es schon vor Jev?

Keine dieser Fähigkeiten ist für sich neu.

Vor den LLMs
Lange trainierte man für jede Frage ein eigenes Klassifikationsmodell, etwa ein BERT (Devlin et al., 2019), mit Beispielen, deren richtige Antwort bekannt ist. Ein solches Modell läuft in Millisekunden auf eigener Hardware und liefert immer dieselbe Antwort, beantwortet aber nur die Frage, für die es trainiert wurde. Erste Verfahren ohne eigenes Training gab es schon damals: Man fragt ein Modell, ob ein Text eine Aussage wie „Dieser Text handelt von einer Rechnung“ stützt, und liest die Wahrscheinlichkeit dafür ab (Yin et al., 2019). Das entspricht Jevs Ja-Nein-Frage.

Mit LLMs
Zero-Shot und Few-Shot. Ein LLM kann eine Klassifikation allein aus der Anweisung lösen und stützt sich dabei auf sein allgemeines Wissen – wie Jev. Gibt man im Prompt zusätzlich Beispiele mit, wie Fälle einzuordnen sind, passt es sich an die eigene Domäne an (Brown et al., 2020).

Structured Output
Eine Verfeinerung legt fest, welche Werte die Antwort annehmen darf. Beim Constrained Decoding werden an jeder Stelle alle Token gesperrt, die nicht zu einer erlaubten Antwort passen: Ist nur „abrechnung“, „technik“ oder „vertrieb“ erlaubt, kann das Modell nichts anderes schreiben – auf Wunsch mit vorangestellter Begründung. Die großen Anbieter bieten das über ihre APIs an (OpenAI, 2024; Anthropic, 2026; Google, 2026a), für selbst betriebene Modelle etwa die Bibliothek Outlines (Willard & Louf, 2023; dottxt, 2026).² Liest man zusätzlich die Logprobs der erlaubten Token aus, also den Logarithmus ihrer Wahrscheinlichkeit, erhält man einen Wert je Label. Bei selbst betriebenen Modellen geht das immer; die aktuellen Gemini-Modelle geben Logprobs über ihre API nicht mehr heraus (geprüft am 28. September 2026).

Was macht Jev anders?

LLMs sind in zweierlei Hinsicht Generalisten: in der Aufgabe und im Wissen. Jev ist spezialisiert in der zu erledigenden Aufgabe – es urteilt nur. In Bezug auf Wissen und Kontext bleibt Jev jedoch ein Generalist.

Die Spezialisierung steckt laut TypeSafe im Training: Jev ist kein angepasstes LLM, sondern ein eigenes, direkt auf Entscheidungen trainiertes Modell; das Verfahren heißt Reinforcement Learning for Calibrated Decisions (RLCD). Veröffentlicht sind weder das Verfahren noch der Aufbau des Modells (TypeSafe AI, 2026a). Verwandt dazu ist das veröffentlichte Verfahren RLCR, das ein Modell nur dann voll belohnt, wenn seine angegebene Sicherheit zu seiner Trefferquote passt (Damani et al., 2025).

Jev macht vor allem aus einem bekannten Verfahren ein Produkt: Wie bei einem LLM legt eine Anweisung die Aufgabe fest – das Training pro Aufgabe entfällt. Das kann die Hürde für den Einsatz senken. Gegenüber einem LLM ist Jev günstiger und schneller. Gemini 3.5 Flash-Lite, Googles kleinstes Modell und unser Vergleichsmodell, kostet 0,30 USD pro Million Token Eingabe, gut siebenmal so viel wie Jev, dazu 2,50 USD pro Million Token Ausgabe einschließlich der Reasoning-Tokens (Google, 2026c). In unseren Tests antwortete Jev nach rund 0,3 Sekunden, Flash-Lite nach 2 bis 7 Sekunden, zum Teil weil es standardmäßig Reasoning-Tokens erzeugt (Google, 2026b).

Der Preis dafür ist die Nachvollziehbarkeit: Jev gibt keine Begründung aus. Ein LLM mit Structured Output kann das, wie dasselbe Ticket mit Gemini zeigt (Google, 2026a):

Gemini liefert ein gültiges Label, eine lesbare Begründung und hier zusätzlich eine Selbsteinschätzung. Das Ticket stuft es als „moeglich“ ein und nennt den Grund gleich mit: Abrechnungsfehler und technisches Problem zugleich. Die Anwendung übergibt es deshalb, wie Jev, einem Menschen, wenn der Wert unter die Schwelle fällt. Eine Wahrscheinlichkeit ist das nicht, wohl aber ein Unsicherheitssignal, das sich direkt aus der Bedeutung der Antwort ergibt. Der Aufwand liegt beim User: Er muss die Stufen der Selbsteinschätzung festlegen und prüfen, ob das Modell sie verlässlich anwendet.³

Offene Alternativen

Jevs Schnittstelle blieb nicht lange exklusiv: Wenige Tage nach der Veröffentlichung gab es mehrere offene Modelle mit derselben Schnittstelle, die man selbst betreiben kann:

Wir haben Jev getestet

Wir haben einige hundert Anfragen an Jev und Gemini 3.5 Flash-Lite gestellt. Die Fälle sind klein und teils konstruiert.

Zusammenhängende Felder können sich widersprechen

Jev bewertet jede Frage getrennt; geteilt ist nur der State (TypeSafe AI, 2026d). TypeSafe sieht darin eine Stärke: Die verlässlichsten Workflows bestehen laut TypeSafe aus vielen unabhängigen, zerlegten Fragen (TypeSafe, 2026a). Heikel wird das, sobald Antworten zusammenpassen müssen. Ein Beispiel: Aus einem Museum ist über Nacht ein Gemälde verschwunden, und genau eines von drei Szenarien trifft zu.

Beide Modelle bekamen dieselben zwei Fragen: „Auf welchem Weg hat das Gemälde das Gebäude verlassen?“ und „War es ein Innentäter?“. Jev beantwortet sie unabhängig voneinander. Gemini beantwortet beide in einer einzigen Anfrage (Request): Mit Reasoning wägt es die Fragen gemeinsam ab, bevor es antwortet, und auch ohne Reasoning liest es beim zweiten Feld die erste Antwort mit. Zusätzlich fragten wir beide direkt nach dem Szenario.⁴

Wie Jevs Wahrscheinlichkeiten zu lesen sind

Der Museumsfall wirft eine zweite Frage auf: Was bedeutet Jevs 0,96 für das Dach, wenn der Text 45 % nennt? Eine Wahrscheinlichkeit ist kalibriert, wenn von allen Antworten mit 0,8 etwa 80 % stimmen, und das immer bezogen auf eine bestimmte Menge von Fällen (Hájek, 2007). Worauf sich Jevs 0,8 beziehen, sagt TypeSafe nicht. Als Maßstab dienen ihm aber die Antworten von Frontier-LLMs, der Mittelwert von GPT-6 Astra und Claude Fable 5.1 (TypeSafe AI, 2026a). Jevs Zahl sagt damit am ehesten, wie wahrscheinlich ein Frontier-LLM diese Antwort geben würde, nicht, wie oft sie stimmt.

Ein erster unabhängiger, nicht begutachteter Test fand Jev auf bekannten Benchmarks gut kalibriert, auf 900 neu erzeugten Support-Tickets weniger: bei Auswahlfragen zu selbstsicher, bei Ja-Nein-Fragen zu vorsichtig (scienthoon, 2026). Unser Museumsfall passt zur Beobachtung bei Auswahlfragen: Als Auswahlfrage bekam das Dach 0,96 bis 0,98 statt der im Text genannten 0,45.

Die Zahlen schwanken zudem. Das Rechnungs-Ticket bekam in 20 identischen Läufen 0,67 bis 0,76, bei vertauschter Reihenfolge der Optionen rund 0,1 mehr oder weniger, auf Englisch nur 0,5 bis 0,6. Eine Schwelle von 0,70 würde identische Anfragen also mal durchwinken, mal einem Menschen vorlegen.

Potenzial

Wie groß Jevs Potenzial ist, hängt davon ab, womit man es vergleicht. TypeSafe misst Jev an Frontier-Modellen (TypeSafe, 2026a). Viele Klassifikationsaufgaben brauchen aber kein Frontier-Modell; dafür reichen kleine Modelle wie Claude Haiku oder Gemini Flash-Lite. Diese sind nach unserer Erfahrung aus Kundenprojekten in Unternehmen kein nennenswerter Kostenfaktor, ins Gewicht fallen die Frontier-Modelle. Jevs Kostenvorteil zählt also vor allem dort, wo man für eine Klassifikation bisher ein Frontier-Modell braucht, und dieser Bereich ist womöglich recht speziell. Ob Jev dort mithält, zeigt erst ein Benchmark auf der eigenen Aufgabe.

Gegenüber kleinen Modellen zählt eher die Wartezeit: Mit 0,3 statt 2 bis 7 Sekunden lassen sich Prüfungen in laufende Prozesse einbauen, die sonst zu lange dauern würden.

Den größten Nutzen sehen wir beim Screening großer Datenmengen, wenn man die Nadel im Heuhaufen sucht: Ein Screening mit hohem Recall verkleinert eine lange Liste von Kandidaten drastisch, und erst die wenigen verbleibenden sieht sich ein LLM oder ein Mensch an. In großen Infrastrukturen fallen täglich Millionen von Logzeilen und Ereignissen an; ob eine Folge von Einträgen auffällig ist, lässt sich oft nicht mit festen Regeln entscheiden. Beim Retrieval kann ein Jev-artiges Modell, je nach Wirtschaftlichkeit, eine Frage gegen einige hundert bis wenige tausend Kandidaten einzeln prüfen, als semantische Suche oder beim Reranking. Bei diesen Mengen werden auch kleine LLMs teuer und langsam. Profitieren dürften vor allem Organisationen mit sehr großen Datenströmen, etwa Behörden oder Energieversorger.

Mit Modellen wie Jev unterscheiden sich die Bausteine einer KI-Architektur nicht mehr nur in der Größe, sondern auch in der Modellart. Denkbar sind Systeme, in denen jede Modellart die Aufgabe übernimmt, die ihr liegt. Ein Jev-artiges Modell stellt die vielen kleinen Weichen: welches Werkzeug, welcher Kontext, welches Modell. Muss eine Klassifikation später geprüft werden, übernimmt ein LLM und schreibt eine Begründung dazu. Am Ende fasst ein großes LLM die Ergebnisse zu einem Bericht zusammen, den Menschen lesen.

Wahrscheinlichkeit oder Konfidenz

Neben Kosten und Wartezeit wirbt TypeSafe vor allem mit den Wahrscheinlichkeiten. In den Anwendungsfällen, die wir aus Projekten kennen, zählt meist etwas anderes: ein Konfidenzwert, an dem man eine Schwelle festmacht. Dafür muss die Zahl nicht kalibriert sein. Sie muss nur sichere Fälle höher einstufen als unsichere; wo die Schwelle liegt, legt man ohnehin an eigenen Daten fest. Jev liefert zu Auswahl- und Skalenfragen auch einen solchen Wert. Er wird aber aus den Wahrscheinlichkeiten berechnet, bei drei Optionen als (3 × größte Wahrscheinlichkeit – 1) / 2 (TypeSafe AI, 2026e), und sagt deshalb nichts darüber, wie sicher sich Jev bei den Wahrscheinlichkeiten selbst ist. Echte Wahrscheinlichkeiten braucht man erst, wenn man mit ihnen rechnet, etwa mehrere Einschätzungen nach der Bayes-Regel kombiniert. Ob ein Modell, dessen Aufbau unbekannt ist und das sich über den Kontext nur begrenzt steuern lässt, für solche Anwendungen taugt, ist offen.

Einen Konfidenzwert bekommt man auch von LLMs, ausdrücklich oder implizit. Ausdrücklich, indem das Modell seine Sicherheit selbst angibt, als Wort, Kategorie oder Zahl; solche Angaben sind oft zu hoch (Xiong et al., 2024). Implizit über die Logprobs: Die Ausgabeschicht eines LLM berechnet für jedes mögliche nächste Token eine Wahrscheinlichkeit, nicht nur für das gewählte. Bei selbst betriebenen Modellen kann man sie immer auslesen, bei APIs nicht mehr überall. Ob Jevs Zahlen als Wahrscheinlichkeiten stimmen müssen oder als Konfidenzwert genügen, muss sich im Einsatz zeigen. Im zweiten Fall ist Jev günstiger und schneller als ein LLM, aber nicht grundsätzlich neu.

Ob Wahrscheinlichkeit oder Konfidenzwert: Welche Fehlerquote eine Schwelle auf den eigenen Daten bedeutet, zeigt erst ein Test an einigen hundert eigenen Fällen mit bekannter Antwort: Wie viele Tickets landen bei 0,8 im falschen Team, wie viele bei 0,9? Mit denselben Fällen lässt sich auch nachträglich kalibrieren (Guo et al., 2017). Die Schwelle wählt man danach, was ein Fehler kostet und was eine Prüfung durch einen Menschen kostet; so empfiehlt es auch TypeSafe (TypeSafe AI, 2026e). Bei Auswahlfragen gehört außerdem eine Option für „nicht erkennbar“ dazu. Sonst verteilt das Modell die Wahrscheinlichkeit auf die vorhandenen Antworten, auch wenn der Text nichts hergibt.

Grenzen

Grenzen der Technologie

Einige Schwächen nennt TypeSafe selbst (TypeSafe AI, 2026f): Jev zählt unzuverlässig und liest Datumsangaben als Text, deshalb vergleicht es Termine schlecht. Doppelte Verneinungen und Schlüsse über mehrere Stufen bereiten ihm Mühe, überflüssige Informationen im State lenken es ab, und in den Daten versteckte Anweisungen können seine Antworten beeinflussen. Rechnen, Datumslogik und das Aussortieren überflüssiger Daten gehören deshalb in den Code.
Diese Schwächen haben vermutlich eine gemeinsame Ursache. Ein LLM mit Reasoning kann bei einer schwierigen Frage mehr Tokens erzeugen und so mehr Rechenaufwand einsetzen. Jev erzeugt keine Reasoning-Tokens. Das macht es schnell und günstig, nimmt ihm aber diesen Ausweg. Um ihn zurückzugewinnen, ohne wieder zum LLM zu werden, müsste ein solches Modell den Aufwand intern an die Schwierigkeit der Frage anpassen, ohne Text zu erzeugen. Ob Jev das kann, ist nicht bekannt.

Der Museumsfall zeigt ein allgemeines Problem: Merkmale, die voneinander abhängen, statistisch gesprochen kovariieren, sind in der Praxis die Regel, nicht die Ausnahme. Wer Jev oder ein Modell derselben Bauart einsetzt, sollte deshalb prüfen, ob die abgefragten Kategorien wirklich unabhängig sind. Sind sie es nicht, überlässt man die Aufgabe besser einem LLM.
Eine zweite Grenze betrifft das Wissen, auf das Jev zurückgreift. Jev ist ein Klassifikator, der ausschließlich allgemeines Wissen nutzt. Er funktioniert, solange die Aufgabe in einer allgemein verständlichen Domäne liegt. Ist sie eigen, etwa mit Kategorien, die nur im eigenen Unternehmen Sinn ergeben, sollte man von einem Modell wie Jev nicht zu viel erwarten. Bei LLMs hat sich dafür In-Context-Learning bewährt: Man gibt im Prompt Beispiele dafür, wie Fälle der eigenen Domäne einzuordnen sind (Brown et al., 2020). Ob Jev Beispiele oder Einordnungsregeln im State ebenso nutzt, haben wir nicht systematisch getestet. Im Museumsfall hat Jev die im State genannten Quoten nicht übernommen. Ob TypeSafe eine Möglichkeit anbieten wird, Jev an die eigene Domäne anzupassen, bleibt abzuwarten.
Hinzu kommt die Regulierung: Bewerbungen sollte man einem solchen Modell nicht zur Bewertung geben: Personalauswahl gilt nach dem EU AI Act als Hochrisiko-Bereich (Verordnung (EU) 2024/1689, Anhang III), und ein Modell ohne Begründung lässt sich dort kaum rechtfertigen. Beim Produkt Jev kommt hinzu, dass sein Aufbau unbekannt ist. Unter solchen Bedingungen sollte ein Modell wie Jev Entscheidungen eher vorbereiten als verantworten: Es liefert einen Beitrag, die Verantwortung für die Entscheidung liegt woanders. Dazu gehört, jede Antwort mit fester Modellversion (nicht jev-latest) und Zeitpunkt zu protokollieren, zumal die Zahlen schwanken. Nur so lässt sich eine Entscheidung später prüfen.

Grenzen des Produkts

Jev ist heute eine Lösung aus den USA; ein Betrieb in der EU ist nicht dokumentiert (TypeSafe AI, 2026c). Für europäische Projekte mit personenbezogenen Daten scheidet das Produkt damit heute oft aus. Zahlt sich die Technologie aus, dürfte es aber eine Frage weniger Monate sein, bis es in Europa nutzbar ist: Entweder bietet TypeSafe einen DSGVO-konformen Betrieb an oder es entstehen geschlossene oder offene Alternativen. Offene Modelle mit derselben Schnittstelle gab es schon nach wenigen Tagen; ob sie mithalten, hat noch niemand unabhängig geprüft.

Fazit

Jev macht Klassifikation ohne eigenes Training günstiger, schneller und einfacher zugänglich, erfindet sie aber nicht neu. Seine Zahlen sagen vermutlich eher, was ein Frontier-LLM antworten würde, als wie oft die Antwort stimmt; als Konfidenzwert für eine Schwelle genügen sie oft trotzdem. Jev passt, wo mehrere Bedingungen zusammenkommen:

• einzelne Fragen, die nicht voneinander abhängen,
• eine allgemein verständliche Domäne,
• große Mengen, für die ein LLM zu teuer oder zu langsam und ein eigener Klassifikator zu aufwendig ist, etwa beim Screening,
• Vorentscheidungen oder unkritische Entscheidungen, die nicht im Einzelfall begründet werden müssen.

Fehlt eine davon, ist meist ein eigener Klassifikator oder ein LLM die bessere Wahl. Auch wo Jev passt, sollte es Entscheidungen vorbereiten, nicht verantworten: Modelle dieser Art bringen dieselben Verzerrungen mit wie LLMs (Kraft, 2021), aber sie lassen sich nur statistisch messen, nicht im Einzelfall an einer Begründung erkennen.
Ob sich Jev als eigene Modellklasse etabliert, ist offen. Wenn ja, bestehen KI-Architekturen künftig nicht mehr nur aus größeren und kleineren LLMs, sondern aus verschiedenen Modellarten.

¹ Die Begriffe System 1 und System 2 übernahm Kahneman von Keith Stanovich und Richard West (2000). Mittlerweile sprechen Stanovich und Jonathan Evans präziser von Typ-1- und Typ-2-Prozessen (Evans & Stanovich, 2013). ↩

² Damit ließen sich schon 2023 Kaskaden bauen: Ein kleines, günstiges Modell antwortet, und nur unsichere Fälle gehen an ein größeres (Chen et al., 2023). Mit Outlines kann man die Unsicherheit dabei ins Label legen: GPT-3.5 wählt zwischen Labels wie „eindeutig positiv“ und „vielleicht positiv“, und nur die unsicheren Fälle gehen an GPT-4 (Herreros, 2023). ↩

³ Ausgegebene Selbsteinschätzungen sind oft zu optimistisch (Xiong et al., 2024). ↩

⁴Jevs Einzelantworten stimmen jede für sich: Ein Innentäter ist laut Modell wahrscheinlicher als ein Außentäter (55 %), und das Dach ist der wahrscheinlichste Weg (45 %). Zusammen ergeben sie jedoch eine Kombination, die in keinem der echten Szenarien vorkommt. Fragte man stattdessen direkt nach dem Gesamtszenario, wählten beide Modelle in allen Läufen das korrekte Szenario C. Die erlaubten Kombinationen als eine einzige Auswahlfrage zu stellen, kann also helfen. Dieser Ansatz hat jedoch seine Grenzen: Mehrere einfache Fragen zu einer komplexen zusammenzufassen, widerspricht dem Grundgedanken von Jev. Hinzu kommt, dass die Zahl der möglichen Kombinationen mit jedem weiteren Merkmal schnell ins Unüberschaubare wächst. Vor allem aber löst der Ansatz das eigentliche Problem nicht: Die jeweils beste Antwort auf separat gestellte Einzelfragen ergibt nicht automatisch die beste Gesamtentscheidung (Dembczyński et al., 2012); oder, in Anlehnung an Aristoteles: Was für sich genommen zutrifft, muss in der Verbindung nicht ebenfalls zutreffen (De Interpretatione 11).↩

Referenzen

• Anthropic. (2026). Structured outputs (Dokumentation). https://docs.anthropic.com/en/docs/build-with-claude/structured-outputs

• Aristoteles. De Interpretatione (Lehre vom Satz) (E. Rolf, Übers., 1995). Meiner Verlag. (Original entstanden ca. 350 v. Chr.)

• Brown, T., Mann, B., Ryder, N., Subbiah, M., Kaplan, J. D., Dhariwal, P., Neelakantan, A., Shyam, P., Sastry, G., Askell, A., Agarwal, S., Herbert-Voss, A., Krueger, G., Henighan, T., Child, R., Ramesh, A., Ziegler, D., Wu, J., Winter, C., … Amodei, D. (2020). Language models are few-shot learners. Advances in Neural Information Processing Systems (NeurIPS 2020), 33, 1877–1901. https://proceedings.neurips.cc/paper/2020/hash/1457c0d6bfcb4967418bfb8ac142f64a-Abstract.html

• Chen, L., Zaharia, M., & Zou, J. (2023). FrugalGPT: How to use large language models while reducing cost and improving performance. arXiv preprint arXiv:2305.05176. https://arxiv.org/abs/2305.05176

• Damani, M., Puri, I., Slocum, S., Shenfeld, I., Choshen, L., Kim, Y., & Andreas, J. (2025). Beyond binary rewards: Training LMs to reason about their uncertainty. arXiv preprint arXiv:2507.16806. https://arxiv.org/abs/2507.16806

• Dembczyński, K., Waegeman, W., Cheng, W., & Hüllermeier, E. (2012). On label dependence and loss minimization in multi-label classification. Machine Learning, 88(1-2), 5–45. https://doi.org/10.1007/s10994-012-5292-0

• Devlin, J., Chang, M.-W., Lee, K., & Toutanova, K. (2019). BERT: Pre-training of deep bidirectional transformers for language understanding. NAACL 2019, 4171–4186. https://aclanthology.org/N19-1423/

• dottxt. (2026). Outlines (Software, GitHub Repository). https://github.com/dottxt-ai/outlines

• Evans, J. S. B. & Stanovich, K. E. (2013). Dual-process theories of higher cognition: Advancing the debate. Perspectives on Psychological Science, 8(3), 223–241. https://doi.org/10.1177/1745691612460685

• Google. (2026a). Structured outputs (Gemini API Dokumentation). https://ai.google.dev/gemini-api/docs/structured-output

• Google. (2026b). Gemini thinking / Interactions API (Gemini API Dokumentation). https://ai.google.dev/gemini-api/docs/thinking

• Google. (2026c). Gemini Developer API pricing (Preisliste, abgerufen am 24. September 2026). https://ai.google.dev/pricing

• Guo, C., Pleiss, G., Sun, Y., & Weinberger, K. Q. (2017). On calibration of modern neural networks. ICML 2017, 1321–1330. https://proceedings.mlr.press/v70/guo17a.html

• Hájek, A. (2007). The reference class problem is your problem too. Synthese, 156(3), 563–585. https://doi.org/10.1007/s11229-006-9090-y

• Herreros, I. (2023). Cascaded LLMs for sentiment labelling with Outlines [LinkedIn-Post]. LinkedIn. https://www.linkedin.com/posts/dr-ivan-herreros-b64a204_cascaded-llms-for-sentiment-labelling-a-activity-7140970944268873730-J5L2

• Kahneman, D. (2011). Thinking, fast and slow. Farrar, Straus and Giroux.

• Kahneman, D. & Tversky, A. (1973). On the psychology of prediction. Psychological Review, 80(4), 237–251. https://doi.org/10.1037/h0034747

• Kraft, A. (2021, 9. Dezember). Social Bias in großen KI-Modellen und wie man damit umgeht. inovex Blog. https://www.inovex.de/de/blog/social-bias-in-grossen-ki-modellen/

• Maisa. (2026). djev (Software, GitHub Repository). https://github.com/Davipar/djev-dev

• OpenAI. (2024, 6. August). Introducing Structured Outputs in the API. OpenAI Blog. https://openai.com/index/introducing-structured-outputs-in-the-api/

• Palmer, J. (2026). Kev: Open decision models (Software, README). GitHub. https://github.com/jaredpalmer/kev

• scienthoon. (2026). jev-ood-calibration (Software, README). GitHub. Nicht begutachtet.

• Stanovich, K. E. & West, R. F. (2000). Individual differences in reasoning: Implications for the rationality debate? Behavioral and Brain Sciences, 23(5), 645–665. https://doi.org/10.1017/S0140525X00003435

• TheoLeeCJ. (2026). SemIf (früher OpenJev) (Software). GitHub.

• TypeSafe AI (2026a). Introducing System One Models & Jev. https://typesafe.ai/blog/introducing-system-one-models-and-jev

• TypeSafe AI (2026b). The Three Primitives. https://docs.typesafe.ai/primitives

• TypeSafe AI (2026c). Models. https://docs.typesafe.ai/models

• TypeSafe AI (2026d). Asking Parallel Questions (Cookbook). https://docs.typesafe.ai/cookbooks/parallel_questions

• TypeSafe AI (2026e). Confidence (Dokumentation). https://docs.typesafe.ai/confidence

• TypeSafe AI (2026f). Known Limitations (Dokumentation). https://docs.typesafe.ai/limitations

• Verordnung (EU) 2024/1689 (KI-Verordnung). (2024). Amtsblatt der Europäischen Union, L 2024/1689. http://data.europa.eu/eli/reg/2024/1689/oj

• Willard, B. T. & Louf, R. (2023). Efficient guided generation for large language models. arXiv preprint arXiv:2307.09702. https://arxiv.org/abs/2307.09702

• Xiong, M., Hu, Z., Lu, X., Li, Y., Fu, J., Liu, Y., & Liu, Q. (2024). Can LLMs express their uncertainty? An empirical evaluation of confidence elicitation in LLMs. ICLR 2024. https://openreview.net/forum?id=1TqD4fF5yJ

• Yin, W., Hay, J., & Roth, D. (2019). Benchmarking zero-shot text classification: Datasets, evaluation and entailment approach. EMNLP-IJCNLP 2019, 3914–3923. https://aclanthology.org/D19-1395/