Vor neun Tagen habe ich über ein Modell namens Jev geschrieben.
Was mich interessierte, war nicht die Launch-Sprache rund um «System One Models». Es war die kleinere Idee darunter: Vielleicht ist die brauchbare Einheit von Intelligenz in Software manchmal weder ein Agent, noch ein Gespräch, noch ein Absatz.
Vielleicht ist es ein Urteil.
Eine begrenzte Frage. Ein definierter Antwortraum. Eine Wahrscheinlichkeit. Dann entscheidet der Code, was als Nächstes geschieht.
Seither ist etwas Vorhersehbares geschehen.
Die Flitterwochen dauerten ungefähr keine Zeit.
Die Beiträge erschienen. Einige nachdenklich, einige genervt, einige beinahe beleidigt von der Aufmerksamkeit, die Jev erhielt.
Es ist nur ein Klassifikator.
Das hatten wir vor zwanzig Jahren.
Probabilistische Modelle sind nicht neu.
Kalibrierung ist nicht neu.
Die Branche hat maschinelles Lernen vergessen und entdeckt es jetzt wieder.
Eine Variante ging weiter: Das sei Beleg dafür, dass KI rückwärts gehe. Vielleicht sogar der Beginn eines weiteren KI-Winters.
In der Kritik steckt eine unbequeme Tatsache.
Vieles daran stimmt.
Und ich halte die Schlussfolgerung für falsch.
Ja. Wir hatten Klassifikatoren.
Klassifikation begann nicht im September 2026.
Probabilistische Vorhersage auch nicht.
Konfidenzkalibrierung auch nicht.
2017 veröffentlichten Chuan Guo und Kolleginnen und Kollegen eine viel zitierte Studie zur Kalibrierung neuronaler Netze. Sie prüften, ob vorhergesagte Wahrscheinlichkeiten der beobachteten Trefferquote entsprechen, und zeigten, dass moderne Netze schlecht kalibriert sein können. Temperature Scaling, eine der praktischen Methoden, die sie bewerteten, war selbst die Verfeinerung älterer Ideen.1
SetFit zeigte später, dass relativ kleine Sentence-Transformer-Modelle sich effizient für Few-Shot-Textklassifikation anpassen lassen — ohne grosses generatives Modell und ohne aufwendige Prompts.2
GLiNER zeigte etwas anderes, das für diese Debatte zählt: Ein kompaktes bidirektionales Modell konnte beliebige Entitätsbeschreibungen annehmen und flexible Zero-Shot-Extraktion leisten, ohne die sequenzielle Tokengenerierung eines Gesprächs-LLM.3
Das ist keine versteckte Geschichte.
Das Feld hat nicht Jahrzehnte darauf gewartet, dass jemand if probability > 0.8 erfindet.
Wäre die Behauptung also:
Jev hat die Klassifikation erfunden.
Dann wäre die Kritik vernichtend.
Aber das ist nicht die interessante Behauptung.
Die interessante Frage lautet, was geschieht, wenn eine vertraute Fähigkeit eine neue Grenze von Allgemeinheit, Nutzbarkeit und Ökonomie überschreitet.
Das ist die Schicht, die es sich anzuschauen lohnt.
Das Primitiv ist nicht die Abstraktion
Eine Datenbank hat das Speichern von Information nicht erfunden.
Eine GPU hat die Multiplikation nicht erfunden.
Unix hat Dateien, Prozesse oder Programme nicht erfunden.
Container haben Prozessisolation nicht erfunden.
Brauchbare Abstraktionen kommen oft lange nach ihren darunterliegenden Primitiven.
Was sich ändert, ist die Grenze.
Eine Fähigkeit, die zuvor Spezialarbeit verlangte, wird hinter einer Schnittstelle zugänglich, die andere Ingenieurinnen und Ingenieure nutzen können, ohne die Maschinerie darunter neu zu bauen.
Diese Schnittstelle kann eine Branche verändern, selbst wenn fast jede Zutat Vorfahren hat.
Deshalb ist «das hatten wir schon» in der Technik ein so gefährlicher Satz.
Manchmal ist er die nötige Korrektur am Marketing.
Manchmal ist er Beleg dafür, dass wir auf die falsche Schicht schauen.
Die Frage lautet nicht nur:
Hat schon jemand klassifiziert?
Natürlich.
Die interessanteren Fragen sind:
Kann ein Modell einen wechselnden Satz von Entscheidungskriterien in natürlicher Sprache annehmen, ohne für jedes einen neuen Klassifikator zu trainieren?
Kann es brauchbare Wahrscheinlichkeitsverteilungen liefern — und nicht bloss ein plausibles Label?
Lassen sich mehrere solche Urteile günstig genug anfordern, dass Softwarearchitektinnen und -architekten aufhören, sie zu rationieren?
Kann die Ausgabe zu einer austauschbaren Komponente in gewöhnlichem Code werden — statt zum Beginn eines weiteren Gesprächs?
Das sind Ingenieursfragen.
Und sie beantwortet man nicht mit dem Hinweis auf ein Lehrbuch zur logistischen Regression.
Was Jev tatsächlich verändert hat
TypeSafe stellte Jev am 15. September 2026 als Early-Access-Modell für typisierte probabilistische Entscheidungen vor. Die Schnittstelle nimmt unstrukturierten Zustand und entwicklerdefinierte Fragen entgegen und liefert begrenzte Ausgaben wie Ja-Nein-Wahrscheinlichkeiten, Auswahlmöglichkeiten und Scores.4
Das Unternehmen nennt seine Trainingsmethode Reinforcement Learning for Calibrated Decisions, kurz RLCD, und sagt, es habe eine neue Architektur und einen parallelen Sampler um diese Aufgabe herum gebaut.4
Diese Ansprüche verdienen Prüfung.
Die Architektur ist öffentlich nicht detailliert genug offengelegt, damit Aussenstehende beurteilen können, wie viel davon wirklich neu ist. RLCD ist nicht so dokumentiert, dass unabhängige Forschende das Trainingsverfahren reproduzieren und seine Neuheit feststellen können.
Sebastian Raschka hat hier die brauchbare Unterscheidung getroffen. Sein Befund: Jev könnte durchaus auf vertrauten Zutaten beruhen — möglicherweise einer Encoder-Architektur, kalibrierungsorientiertem Training, starken Daten und einer gut gestalteten API — und trotzdem interessant sein, weil das resultierende System über Klassifikationsaufgaben hinweg ungewöhnlich gut zu generalisieren scheint.5
Das ist die Position, die ich in diesem Stadium am überzeugendsten finde.
Ich weiss nicht, ob Jev einen Forschungsdurchbruch enthält.
Ich meine, es hat eine brauchbare Systemgrenze freigelegt.
Das sind verschiedene Behauptungen.
Und wer sie vermengt, erzeugt beide Arten schlechter Analyse: Hype auf der einen Seite, Abtun auf der anderen.
Die Informatik war schon einmal hier
Allzwecksysteme sind wunderbar, weil sie Dinge ermöglichen, die niemand vorhergesagt hat, als das System gebaut wurde.
Dann wird eine Last wichtig.
Wir verstehen sie besser.
Wir entdecken, wo das allgemeine System Zeit, Energie oder Geld verschwendet.
Und Spezialisierung kehrt zurück.
Die Geschichte der Informatik ist voll von dieser Bewegung.
Googles Tensor Processing Unit erschien nicht, weil man Multiplikation vergessen hatte. Sie erschien, weil Workloads des maschinellen Lernens wichtig genug geworden waren, dass eine domänenspezifische Architektur sie effizienter ausführen konnte als ein Allzweckprozessor.6
John Hennessy und David Patterson machten domänenspezifische Hardware zu einem zentralen Teil ihrer Turing-Lecture 2018 über ein neues goldenes Zeitalter der Computerarchitektur. Ihr Argument war nicht, dass Allzweckrechnen ein Fehler gewesen sei. Es war, dass das Ende leichter Leistungssteigerung Hardware/Software-Co-Design und domänenspezifische Architekturen wieder attraktiv machte.7
Das ist kein Rückschritt.
Es ist Reife der Last.
Dasselbe Muster gibt es weiter oben im Stack.
Das ursprüngliche Unix-System war unter anderem wertvoll, weil unabhängige Programme, Dateien, Pipes und Prozesse über einfache Schnittstellen komponierbar waren.8
Ein Programm musste nicht zum Betriebssystem werden.
Eine Komponente konnte Komponente bleiben.
Das klingt beinahe peinlich offensichtlich.
Doch die KI-Software bewegte sich mehrere Jahre in die entgegengesetzte Richtung.
Wir fanden ein Modell, das Text schreiben, Dokumente zusammenfassen, Daten extrahieren, Nachrichten klassifizieren, Werkzeuge aufrufen, über Regeln nachdenken und Code erzeugen konnte.
Also liessen wir es natürlich all das tun.
Oft in einem Prompt.
Manchmal in einem enormen Prompt.
Das Staunen über das Allzweckmodell förderte eine Allzweckarchitektur um es herum.
Das war verständlich.
Es war auch unwahrscheinlich die endgültige Form.
Das Modell wurde zum System
Die erste Welle generativer KI-Anwendungen sah oft so aus:
Eingabe → LLM → Ausgabe
Dann wurde der Prompt länger.
Dann kam Retrieval hinzu.
Dann Werkzeugaufrufe.
Dann Validatoren.
Dann strukturierte Ausgaben.
Dann Retries.
Dann Routing.
Dann ein zweites Modell, das das erste beurteilt.
Dann ein stärkeres Modell für die schwierigen Fälle.
Dann Code, der entscheidet, welches Modell laufen soll.
Irgendwann war das «Modell» nicht mehr die Anwendung.
Es war wieder eine Komponente innerhalb einer Anwendung.
Berkeley-Forschende beschrieben diesen Übergang 2024 als Wechsel von Modellen zu zusammengesetzten KI-Systemen: Systeme, in denen Modelle mit Retrieval, Werkzeugen, programmatischer Logik und anderen Modellen interagieren, statt die gesamte Aufgabe in einem monolithischen Aufruf zu lösen.9
Dieser Wechsel hält aus einem einfachen Grund an.
Verschiedene Teile der Arbeit haben verschiedene rechnerische Formen.
Arithmetik ist nicht Klassifikation.
Klassifikation ist nicht Retrieval.
Retrieval ist nicht Planung.
Planung ist nicht Berechtigung.
Berechtigung ist nicht Textgenerierung.
Wir können ein hinreichend fähiges Sprachmodell sicher bitten, all das zu approximieren.
Das heisst nicht, dass wir es sollten.
Ein Universalmodell ist nützlich, weil es den Raum dessen erweitert, was Software versuchen kann.
Eine spezialisierte Komponente wird nützlich, wenn wir einen wiederkehrenden Teil dieses Raums gut genug verstehen, um ihm eine schärfere Schnittstelle zu geben.
Die beiden Ideen sind keine Feinde.
Das allgemeine Modell entdeckt Terrain.
Das System baut irgendwann Strassen.
Was die Bitter Lesson tatsächlich sagt
Hier wird die Debatte interessanter.
Rich Suttons The Bitter Lesson ist einer der wichtigsten kurzen Essays der modernen KI. Er lässt sich auch leicht zum Slogan machen.
Der Slogan klingt ungefähr so:
Allgemein schlägt immer speziell. Skalierung gewinnt. Schluss mit Engineering.
Das ist nicht Suttons Argument.
Seine Beobachtung war: KI-Forschende versuchten wiederholt, ihr eigenes Domänenverständnis in Systeme zu kodieren, während allgemeinere Methoden, die wachsende Rechenleistung ausnutzen konnten — insbesondere Suche und Lernen — diese handgefertigten Ansätze schliesslich übertrafen.10
Schach ist ein Beispiel.
Go ein anderes.
Spracherkennung und Computer Vision folgen in Suttons Darstellung ähnlichen Mustern.
Der bittere Teil war nicht, dass jedes System ein riesiges Modell enthalten soll.
Es war, dass Menschen schlecht darin sind, alles Wissen, das Intelligenz braucht, manuell festzulegen — während Lernen und Suche mit wachsender Rechenleistung weiter verbessern können.
Diese Lektion ist mit spezialisierten gelernten Modellen völlig vereinbar.
Ein Entscheidungsmodell, das aus Daten trainiert wird, ist nicht dasselbe wie ein Expertensystem mit Tausenden von Regeln, die ein Gremium geschrieben hat.
Ein TPU ist spezialisierte Hardware, existiert aber genau deshalb, um Lernen im grossen Massstab rechnerisch wirksamer zu machen.
Ein Retrieval-System ist spezialisiert und kann einem allgemeinen Modell dennoch Wissen liefern, das es sonst aus Parametern approximieren müsste.
Ein Klassifikator kann in seinem Ausgaberaum spezialisiert sein und seine Fähigkeiten dennoch durch allgemeines Lernen erworben haben.
Die wichtige Unterscheidung lautet oft nicht:
allgemein versus spezialisiert
sondern:
gelernt versus manuell kodiert,
wiederverwendbar versus spröde,
skalierbar versus in der eigenen Konstruktion gefangen.
TypeSafe ist mit einem Essay namens The Bitterest Lesson direkt in diese Debatte eingetreten. Das Argument: Rechenleistung zählt enorm, aber das zu optimierende Ziel zählt zuerst — ein System kann wunderbar skalieren und dabei besser in der falschen Aufgabe werden.11
Das ist das Argument eines Anbieters und sollte als solches gelesen werden.
Aber die darunterliegende Frage ist legitim.
Wenn die Aufgabe lautet, unter fünf erlaubten Handlungen zu wählen: Ist Next-Token-Generierung das rechnerische Ziel, das wir letztlich optimieren wollen?
Vielleicht.
Vielleicht nicht.
Das ist eine empirische Frage, kein Glaubenssatz.
Dann hat jeder eines gebaut
Es gibt noch einen Grund, weshalb ich die Jev-Episode für beobachtenswert halte.
Die Reaktion war ungewöhnlich schnell.
Bespoke Labs veröffentlichte Nimble, ein offenes, von Jev inspiriertes Modell, das Text und ein Schema entgegennimmt und typisierte Entscheidungen mit Wahrscheinlichkeiten zurückgibt. Das Projekt sagt, die erste Version sei an einem Tag gebaut worden.12
Together AI veröffentlichte Tev1-4B-experimental auf Basis von Qwen3.5 4B. Das veröffentlichte Trainingsrezept nutzt rund 38'000 Klassifikationsbeispiele und nennt Kosten für das Fine-Tuning von etwa 17 US-Dollar.13
Laya implementiert eine nicht-autoregressive, Jev-kompatible Entscheidungsschnittstelle und veröffentlicht Vergleichsbenchmarks, die gerade deshalb nützlich sind, weil sie nicht durchgängig schmeichelhaft sind. Die eigenen Ergebnisse zeigen Bereiche, in denen das feinabgestimmte Modell Jev übertrifft, und Bereiche — einschliesslich grosser Auswahlmengen und einiger Metriken zu Wahrscheinlichkeitsverteilungen —, in denen Jev stärker bleibt.14
Kev führt die Idee nochmals anders weiter: kleine, offene Entscheidungsmodelle im Jev-Stil, einschliesslich eines Prototyps im Laptop-Massstab und grösserer Varianten auf Qwen-Basis. Die Model Cards warnen ausdrücklich: Ein Konfidenzwert ist keine verifizierte Wahrscheinlichkeit der Korrektheit; Kalibrierung sollte an der tatsächlichen Einsatzpopulation gemessen werden.15
Keines dieser Projekte beweist, dass TypeSafe eine dauerhafte Kategorie geschaffen hat.
Sie beweisen etwas Engeres.
Andere Entwicklerinnen und Entwickler sahen die Schnittstelle und dachten sofort:
Das will ich.
Das zählt.
Eine technologische Kategorie entsteht nicht, wenn ein Unternehmen sie benennt.
Sie beginnt real zu werden, wenn Wettbewerber, Open-Source-Entwickler und Nutzer die Form der Sache gut genug erkennen, um sie zu reproduzieren, zu variieren und darüber zu streiten.
Vielleicht wird «System One Model» der Name.
Vielleicht benutzt ihn in einem Jahr niemand mehr.
Der Name ist zweitrangig.
Das entstehende Muster ist interessanter:
Zustand hinein → begrenzte Fragen → Wahrscheinlichkeitsverteilungen hinaus → Code entscheidet, was folgt
Diese Schnittstelle hat jetzt mehrere Implementierungen.
Für etwas, das angeblich so veraltet ist, erzeugt das erstaunlich viel neue Arbeit.
Wiederentdeckung kann trotzdem übertrieben werden
Nichts davon bedeutet, dass Jev gewinnt.
Tatsächlich lautet die stärkste Antwort auf die gegenwärtige Begeisterung nicht «Klassifikatoren sind alt».
Sondern:
Welchen Klassifikator soll ich für genau diese Arbeit verwenden?
Habe ich eine stabile Aufgabe, einen sauberen Labelsatz und Tausende hochwertiger Beispiele, kann ein konventioneller aufgabenspezifischer Klassifikator genau die richtige Antwort sein.
Er kann schneller sein.
Er kann günstiger sein.
Er kann leichter zu bewerten sein.
Er kann vollständig auf Infrastruktur laufen, die ich kontrolliere.
SetFit und Jahre der Textklassifikationsforschung haben nicht aufgehört, nützlich zu sein, weil Jev gestartet ist.2
Ebenso kann ein allgemeines LLM die bessere Komponente bleiben, wenn der Antwortraum sich nicht im Voraus definieren lässt, wenn die Aufgabe Synthese verlangt, wenn Denken über ungewohnte Situationen wichtiger ist als Latenz, oder wenn das System wirklich Sprache erzeugen muss.
Und dann sind da die Wahrscheinlichkeiten.
Ein Dezimalpunkt erzeugt den Eindruck von Präzision, den das System vielleicht nicht verdient.
Guos Arbeit zur Kalibrierung bleibt relevant, weil ein Modell, das 0.92 sagt, nicht reicht. Die betriebliche Frage lautet, ob Vorhersagen auf diesem Niveau in der Population, in der das System eingesetzt wird, ungefähr so oft korrekt sind.1
Verteilungsverschiebung zählt.
Label-Design zählt.
Fehlende Alternativen zählen.
Schlechte Belege zählen.
Das System kann vollkommen typsicher sein und trotzdem die falsche erlaubte Antwort wählen.
Spezialisierung nimmt die Pflicht zum Testen nicht weg.
Sie macht den Test leichter definierbar.
Das ist nur dann ein Vorteil, wenn wir ihn tatsächlich nutzen.
So sieht kein KI-Winter aus
Der Ausdruck «KI-Winter» trägt historisches Gewicht.
Die AI100-Geschichte Stanfords beschreibt den Winter Mitte der 1980er als Phase, in der praktische Enttäuschung die Erwartungen einholte, Interesse sank und Finanzierung austrocknete.16
Das ist ein ganz anderes Phänomen als Entwickler, die feststellen, dass manche Produktionslasten kein riesiges generatives Modell brauchen.
Wenn Unternehmen beginnen, teure Allzweckaufrufe dort durch kleinere gelernte Komponenten zu ersetzen, wo die Aufgabe es zulässt, ist das kein Beleg dafür, dass KI gescheitert ist.
Es ist Beleg dafür, dass Kosten zählen.
Latenz zählt.
Verlässlichkeit zählt.
Architektur zählt.
Anders gesagt: Die Technik unterliegt denselben Druckkräften wie jede andere Technik, die schliesslich die Demonstrationsphase verlassen musste.
Die erste Phase fragt:
Was kann diese Maschine?
Die nächste Phase fragt:
Welche Maschine soll welchen Teil übernehmen?
Die zweite Frage klingt weniger magisch.
Sie ist auch die Frage, die Ingenieurinnen und Ingenieure schliesslich beantworten müssen.
Eine Branche aus LLMs, Entscheidungsmodellen, Embedding-Modellen, Retrievern, Vision-Systemen, deterministischem Code, Datenbanken, Richtlinien und menschlichen Eskalationswegen mag weniger nach Science-Fiction aussehen als ein allmächtiges Modell hinter einer API.
Sie kann auch besser funktionieren.
Langweilig ist ein Meilenstein
In Technikdebatten gibt es eine merkwürdige Gewohnheit.
Wir behandeln Verallgemeinerung als Fortschritt und Spezialisierung als Rückzug.
Aber dass eine Erfindung langweilig wird, ist oft eines der klarsten Zeichen von Erfolg.
Elektrizität verschwand in den Wänden.
Netzwerke verschwanden in Betriebssystemen.
Datenbanken wurden Infrastruktur.
Virtuelle Maschinen wurden gewöhnlich.
Cloud Computing wurde schliesslich die Rechnung von jemand anderem.
Eine reife Technik ist von Komponenten umgeben, deren Neuheit der Person, die sie nutzt, nicht mehr zählt.
Bei KI wird es vermutlich nicht anders sein.
Es wird weiterhin Frontier-Modelle geben.
Sie werden fähiger.
Sie werden neues Terrain öffnen.
Aber die Systeme um sie herum können zunehmend heterogen werden.
Manche Entscheidungen gehen an ein Frontier-Reasoning-Modell.
Manche an einen Klassifikator mit vier Milliarden Parametern.
Manche an ein lokal laufendes Modell.
Manche an eine SQL-Abfrage.
Manche an eine Regel-Engine.
Manche an einen Menschen, weil die Folge zu wichtig oder die Belege zu unvollständig sind.
Gute Architektur wird sich nicht darum kümmern, welche Komponente gerade den beeindruckendsten Benchmark-Screenshot hat.
Sie wird sich darum kümmern, ob die Komponente ihre zugewiesene Arbeit gut genug, günstig genug und vorhersehbar genug erledigt, um sich darauf verlassen zu lassen.
Das ist kein Rückzug von Intelligenz.
Es ist Intelligenz, die zur Infrastruktur wird.
Wiederentdeckung ist kein Rückschritt
Also ja.
Jev ist ein Klassifikator.
Oder zumindest ist «Klassifikator» eine vollkommen vernünftige Beschreibung dessen, was es tut.
Klassifikation ist alt.
Kalibrierung ist alt.
Spezialisierte Modelle sind alt.
Keine dieser Beobachtungen entscheidet, ob Jev nützlich ist.
Sie tun etwas Besseres: Sie entfernen die Mythologie.
Dann können wir die Fragen stellen, die zählen.
Generalisiert die Schnittstelle?
Sind die Wahrscheinlichkeiten brauchbar?
Wie verhält es sich ausserhalb der Beispiele des Anbieters?
Wo schlägt ein gewöhnlicher Klassifikator es?
Wo schlägt ein generatives Modell es?
Lässt sich die Komponente ersetzen, ohne die Anwendung neu zu bauen?
Was tut das Gesamtsystem, wenn das Modell falsch liegt?
Das sind weit gesündere Fragen, als zu fragen, ob wir eine unsichtbare historische Linie zwischen «alter KI» und «neuer KI» überschritten haben.
Technik schreitet selten voran, indem sie dauerhaft alles verwirft, was vorher kam.
Sie schreitet durch Rekombination voran.
Eine Fähigkeit wird allgemein.
Wir nutzen sie überall.
Wir lernen, wo sie passt.
Wir spezialisieren die teuren Teile.
Wir standardisieren die brauchbaren Schnittstellen.
Dann kommt ein weiterer Allzweck-Durchbruch, und der Zyklus beginnt von vorn.
Wenn Jev nächstes Jahr verschwindet, bleibt dieses Muster dennoch wert, verstanden zu werden.
Denn die folgenschwerere Verschiebung hat vielleicht nichts mit Jev zu tun.
Es kann sein, dass die Ära generativer Modelle Entwicklerinnen und Entwicklern beigebracht hat, Intelligenz als etwas zu behandeln, das Software aufrufen kann.
Und jetzt beginnen wir, die naheliegende nächste Frage zu stellen:
Welche Art von Intelligenz soll jeder Aufruf tatsächlich verlangen?
Das ist kein KI-Winter.
Das ist Architektur.
Und Wiederentdeckung ist kein Rückschritt.
Quellen
Quellen wurden am 25. September 2026 konsultiert. Anbieterdokumentation dient dazu, Produktansprüche, Schnittstellen und veröffentlichte Messwerte festzuhalten — nicht als unabhängige Leistungsprüfung. Benchmarks aus Open-Source-Projekten werden als vom Projekt veröffentlichte Ergebnisse berichtet, sofern nicht anders angegeben.
Fussnoten
Footnotes
-
Chuan Guo, Geoff Pleiss, Yu Sun, Kilian Q. Weinberger, “On Calibration of Modern Neural Networks,” ICML 2017 / PMLR 70. https://proceedings.mlr.press/v70/guo17a.html ↩ ↩2
-
Lewis Tunstall et al., “Efficient Few-Shot Learning Without Prompts,” 2022. https://arxiv.org/abs/2209.11055 ↩ ↩2
-
Urchade Zaratiana, Nadi Tomeh, Pierre Holat, Thierry Charnois, “GLiNER: Generalist Model for Named Entity Recognition using Bidirectional Transformer,” NAACL 2024. https://aclanthology.org/2024.naacl-long.300/ ↩
-
Diogo Almeida / TypeSafe AI, “Introducing System One Models & Jev,” 15. September 2026. Launch-Beschreibung, System-One-Schnittstelle, RLCD-Anspruch, Architekturanspruch, Preise und Evaluationsvorbehalte. https://typesafe.ai/blog/introducing-system-one-models-and-jev ↩ ↩2
-
Sebastian Raschka, “It’s Easy to Dismiss Jev as Just a Classifier,” 20. September 2026. Sekundäre technische Analyse; hält ausdrücklich fest, dass Jevs genaue Architektur und Trainingsmethode nicht offengelegt sind. https://www.sebastianraschka.com/blog/2026/jev-classification-generalization.html ↩
-
Norman P. Jouppi et al., “In-Datacenter Performance Analysis of a Tensor Processing Unit,” ISCA 2017. https://research.google/pubs/in-datacenter-performance-analysis-of-a-tensor-processing-unit/ ↩
-
John L. Hennessy and David A. Patterson, “A New Golden Age for Computer Architecture,” Turing Lecture / ISCA 2018. https://iscaconf.org/isca2018/turing_lecture.html ↩
-
D. M. Ritchie and K. Thompson, “The UNIX Time-Sharing System,” Communications of the ACM / Bell System Technical Journal edition. https://people.eecs.berkeley.edu/~brewer/cs262/unix.pdf ↩
-
Matei Zaharia et al., “The Shift from Models to Compound AI Systems,” Berkeley AI Research, 18. Februar 2024. https://bair.berkeley.edu/blog/2024/02/18/compound-ai-systems/ ↩
-
Rich Sutton, “The Bitter Lesson,” 13. März 2019. https://bitterlesson.ai/ ↩
-
TypeSafe AI, “The Bitterest Lesson,” 10. September 2026. Anbieter-Essay: Aufgabenwahl und Daten gehen in der praktischen ML-Systementwicklung Rechenleistung und Algorithmen voraus. https://typesafe.ai/blog/bitterest-lesson ↩
-
Bespoke Labs, “Nimble,” GitHub-Repository, konsultiert am 25. September 2026. Offenes, von Jev inspiriertes typisiertes Entscheidungsmodell; das Projekt gibt an, die Erstversion sei an einem Tag gebaut worden. https://github.com/bespokelabsai/nimble ↩
-
Hassan El Mghari / Together AI, “How to train your own Jev for $17,” 23. September 2026. Tev1-4B-experimental, Qwen3.5-4B-Basis, veröffentlichtes Datenrezept und berichtete Fine-Tuning-Kosten. https://www.together.ai/blog/how-to-train-your-own-jev ↩
-
NandhaKishorM, “Laya,” GitHub-Repository, konsultiert am 25. September 2026. Jev-kompatible nicht-autoregressive Entscheidungs-Engine und vom Projekt veröffentlichte Vergleichsbenchmarks. https://github.com/NandhaKishorM/laya ↩
-
Jared Palmer, “Kev,” GitHub-Repository und Model Cards, konsultiert am 25. September 2026. Offene Entscheidungsmodelle im Jev-Stil und Kalibrierungsvorbehalte. https://github.com/jaredpalmer/kev ↩
-
Stanford One Hundred Year Study on Artificial Intelligence, “Appendix I: A Short History of AI,” Bericht 2016. Historische Beschreibung des KI-Winters. https://ai100.stanford.edu/2016-report/appendix-i-short-history-ai ↩