In Men in Black II besucht Agent J den Agenten K in einem scheinbar ganz normalen Postamt. Er öffnet eine Briefsortiermaschine und entdeckt darin einen Alien, der rasend schnell die Briefe sortiert.
Es ist eine absurde kleine Szene, aber sie liefert uns auch einen nützlichen Gedankenansatz für KI.
Zwischen dem Empfang einer Information und der Reaktion darauf steht oft eine kleinere Entscheidung: Wohin gehört das?
Wenn diese Entscheidung früh richtig getroffen wird, kann der Rest des Systems dem passenden Pfad folgen.
Während ich an einer KI-Software arbeite, muss ich ständig an diesen kleinen Alien denken.
Eine Anwendung erhält eine Abrechnungsfrage, einen Fehlerbericht, ein Produktfoto und die Bitte um eine Demo-Buchung. Jedes Anliegen erfordert eine andere Bearbeitung. Trotzdem neigen wir dazu, dasselbe große Sprachmodell alles prüfen und entscheiden zu lassen, was als Nächstes passiert. Weder effizient noch kostengünstig.
Deshalb bin ich überzeugt, dass spezialisierte Modelle in der Zukunft der KI eine viel größere Rolle spielen werden. Ein Beispiel: Jev wurde für strukturierte Entscheidungen entwickelt, auf die Software direkt reagieren kann. Coinbase hat Qwen3.5-9B speziell für die Betrugserkennung in seinem Onramp-Dienst angepasst. Jedes Modell konzentriert sich auf eine klar definierte Aufgabe mit messbaren Ergebnissen.
https://x.com/brian_armstrong/status/2109412046244913643
Ich baue gerade die Sortierschicht
Vertraute Anfragen können direkt in einen definierten Workflow fließen. Anfragen, die mehr Schlussfolgerungen erfordern, werden an ein anderes Modell weitergeleitet. Mehrdeutige Fälle werden zur Klärung oder Überprüfung markiert.
Das Einsparpotenzial entsteht dadurch, dass jede Anfrage genau so viel Verarbeitungsleistung erhält, wie sie benötigt. Danach müssen wir messen, ob der Sortierer genug Entscheidungen richtig trifft, um seinen Einsatz zu rechtfertigen.
Unser Ausgangspunkt war CludeMem. Wir wollten herausfinden, woran sich eine KI erinnern sollte, was sie abrufen sollte und was unnötig Tokens verbrauchte. Eine dauerhafte Präferenz, eine temporäre Anweisung und eine offene Frage verdienen eine unterschiedliche Behandlung. Bevor wir diese Entscheidungen treffen konnten, mussten wir die Informationen klassifizieren.
Daraus entstand die Idee einer umfassenderen Klassifizierungsschicht. Derselbe Schritt könnte helfen, eine Support-Anfrage zu sortieren, ein Dokument weiterzuleiten oder auszuwählen, welcher Spezialist eine Aufgabe übernehmen soll.
GIF
Je mehr spezialisierte Modelle entstehen, desto mehr müssen Anwendungen entscheiden, welche Eingaben ihre Aufmerksamkeit verdienen. Genau daran arbeiten wir: eintreffende Daten klassifizieren, vertraute Fälle lokal bearbeiten und die schwierigeren an das passende Modell oder einen Prüfprozess übergeben.
Hier kommt Clude Cat ins Spiel (Cat für Kategorisierung 😉)
Bevor eine Erinnerung gespeichert, ein Dokument abgerufen, ein Tool aufgerufen oder eine Antwort generiert wird, steht meist die Entscheidung darüber, mit welcher Art von Information wir es zu tun haben.
Solche Entscheidungen gibt es überall.
Stell dir vor, jemand schreibt an ein Softwareunternehmen:
„Wo kann ich meine Rechnung herunterladen?“
Ein KI-Agent könnte die Nachricht lesen, seine Tools prüfen, die Absicht des Kunden abwägen und beschließen, nach einer Rechnung zu suchen.
Ein direkterer Workflow könnte so aussehen:
Nachricht → Anfrage nach Rechnungsbeleg → Kontoverifizierung → Rechnungsabruf.
Ein Sprachmodell könnte weiterhin die Antwort formulieren. Die anfängliche Routing-Entscheidung ließe sich lokal erledigen.
Nun ändern wir die Nachricht:
„Mir wurde doppelt abgebucht, mein Konto ist gesperrt und ich möchte kündigen.“
Diese Nachricht einfach in einen einzigen Rechnungs-Workflow zu schicken, würde nur mehr Arbeit verursachen. Es gibt mehrere Probleme zu lösen, und die richtige Reaktion erfordert möglicherweise Rückfragen oder einen menschlichen Mitarbeiter.
Der Sortierer muss die Erlaubnis haben zu sagen: „Das kann ich nicht zuverlässig zuordnen.“
Das ist ein wesentlicher Bestandteil des Produkts. Ein System, das Anfragen selbstbewusst an die falsche Stelle leitet, macht seinen Geschwindigkeitsvorteil durch den Aufwand zur Fehlerbehebung wieder zunichte.
Für den Kunden bedeutet der gewünschte Nutzen weniger Wartezeit und weniger Wiederholungen.
Für Entwickler ist es eine explizite Entscheidung, die sie prüfen, testen und ändern können. Sie sehen die gewählte Kategorie, die Modellversion, die Verarbeitungszeit und ob das System keine Entscheidung getroffen hat.
Im Hintergrund beginnt die Textimplementierung mit einem kleinen vortrainierten Modell, dem sogenannten Encoder.
Er wandelt eine Nachricht in eine Liste von Zahlen um, die Aspekte ihrer Bedeutung repräsentieren. Entwickler nennen diese Darstellung ein Embedding.
„Wo ist meine Rechnung?“ und „Ich brauche eine Kopie meiner Rechnung“ verwenden unterschiedliche Wörter. Ihre numerischen Darstellungen können sich dennoch so stark ähneln, dass das System dieselbe Art von Anfrage erkennt.
Eine Klassifizierungsschicht nutzt diese Darstellungen, um vom Entwickler definierte Kategorien zu bewerten.
Wir haben zwei Ansätze implementiert. Der eine vergleicht die eingehende Nachricht mit Beispielen jeder Kategorie. Der andere lernt die Grenzen zwischen den Kategorien anhand gelabelter Beispiele.
Beim Fitted-Ansatz halten wir den Encoder fest und trainieren eine kleinere Entscheidungsschicht darüber. Wir müssen also nicht für jede Anwendung ein neues Basismodell trainieren.
Der Entwickler muss trotzdem definieren, was die Kategorien bedeuten, und sie mit sinnvollen Aktionen verknüpfen. Der Klassifizierer kann sich die Abteilungen eines Unternehmens, die Rückerstattungsrichtlinien oder Kontoberechtigungen nicht selbst ausdenken.
Außerdem braucht er eine Akzeptanzrichtlinie.
Die Kategorie mit der höchsten Punktzahl passt vielleicht trotzdem schlecht. Zwei Kategorien liegen möglicherweise fast gleichauf. Eine unbekannte Anfrage könnte etwas Vertrautem ähneln.
Unsere aktuellen lokalen Scores sind keine kalibrierten Wahrscheinlichkeiten. Ein Score von 0,92 bedeutet nicht automatisch „mit 92 % Wahrscheinlichkeit korrekt“.
Wir müssen testen, was passiert, wenn diese Scores Entscheidungen steuern.
Die Ausgabe unterscheidet daher zwischen einer akzeptierten Kategorie, einer prüfbedürftigen Anfrage und einem technischen Fehler. Auch Timeouts, Abbrüche und Modellfehler brauchen eine vorhersehbare Behandlung.
Das ist die technische Arbeit rund um den Sortierer. Sie entscheidet darüber, ob eine andere Anwendung das Ergebnis sicher und konsistent nutzen kann.
Wir haben ein Experiment mit 770 Banking-Anfragen durchgeführt, um zu prüfen, ob dieser Ansatz die Arbeit generativer Modelle reduzieren kann.
Bei der ersten Konfiguration wurde jede Anfrage zur Klassifizierung an ein lokal laufendes Qwen2.5-7B-Modell gesendet.
Die zweite nutzte zuerst unseren lokalen Klassifizierer und leitete nur ungeklärte Anfragen an Qwen weiter.
Die Ergebnisse:
- Die Qwen-Aufrufe sanken von 770 auf 227.
- Die korrekten Klassifizierungen stiegen von 535 auf 642.
- Die Genauigkeit über alle Eingaben hinweg erhöhte sich von 69,5 % auf 83,4 %.
- Die Summe der gemessenen Abfragezeiten fiel von 299,7 Sekunden auf 87,7 Sekunden.
Die lokale Stufe verhinderte 543 Qwen-Aufrufe – eine Reduzierung um 70,5 %.
Caching blieb aktiviert, und der direkte Ansatz lief vor dem kombinierten Ansatz. Die Zeitangaben enthalten weder Setup noch Warm-ups. Wir haben nur die Klassifizierung gemessen, ohne finale Kundenantworten zu generieren oder einen Modellanbieter zu bezahlen.
Diese Zahlen beschreiben genau diese Konfiguration. Sie beweisen keinen Vorteil gegenüber jedem LLM und belegen keine Kundeneinsparungen.
In einem späteren, separaten Experiment testeten wir einen angepassten lokalen Klassifizierer mit 24 Intents aus den Bereichen Reisen und Arbeitsplatz.
Von 720 Anfragen bearbeitete er 688 lokal. Davon waren 681 korrekt und sieben falsch. 32 ließ er zur Überprüfung übrig.
Das ergibt zwei verschiedene Messwerte:
- Abdeckung: Er bearbeitete 95,6 % der Anfragen lokal.
- Akzeptierte Präzision: Bei 99,0 % der akzeptierten Entscheidungen lag er richtig.
Beide Werte gehören zum Ergebnis. Ein Klassifizierer könnte eine beeindruckende Präzision erreichen, indem er nur eine Handvoll einfacher Anfragen akzeptiert.
Wir haben außerdem 100.000 unbekannte Eingaben getestet, die außerhalb seiner unterstützten Kategorien liegen sollten. In über 94 % der Fälle lag er richtig.
Zu erkennen, was das System nicht weiß, bleibt Teil der Arbeit.
Geschwindigkeit erfordert dieselbe Sorgfalt. In einem separaten Warm-CPU-Test benötigte der vollständige Banking-Klassifizierer auf dem M4 Max im Median etwa 1,8 Millisekunden pro Anfrage. Das umfasste Tokenisierung, Embedding und Scoring.
Ausgenommen waren das Herunterladen und Starten des Modells. Es handelt sich um eine reine Klassifizierungsmessung, nicht um die Zeit, die nötig ist, um die gesamte Anfrage des Nutzers zu lösen. Außerdem garantiert das nicht dieselbe Leistung auf einem Smartphone oder einem gewöhnlichen Laptop.
Jev passt in diese Diskussion, weil es bereits eine ähnliche Klasse von Entscheidungen abdeckt.
TypeSafe dokumentiert Jev als Modell für begrenzte Urteile, darunter die Auswahl zwischen vorgegebenen Optionen und das Weiterleiten von Anfragen an regulären Code, spezialisierte Modelle oder Menschen. \Jevs Dokumentation zum Intent-Routing\
Die Rolle, die ich für Jev sehe, ist ein optionaler Eskalationspfad für Anfragen, die der lokale Klassifizierer nicht zuverlässig lösen kann.
Die Architektur, auf die wir hinarbeiten, ist unkompliziert:
Eingehende Anfrage → lokale Klassifizierung → vertraute Anfragen nehmen einen definierten Pfad; unsichere Anfragen gehen an Jev, ein anderes Modell oder in die manuelle Prüfung.
Ohne Jev kann dieselbe lokale Klassifizierungsstufe ungeklärte Anfragen an das bestehende LLM der Anwendung, einen Klärungsschritt oder einen Prüfprozess zurückgeben.
Der Entwickler kontrolliert die Kategorien, Akzeptanzschwellen und Fallbacks. Er kann den lokalen Klassifizierer in einen bestehenden Workflow einbinden und messen, welche Entscheidungen er übernehmen kann.
Derzeit läuft die Jev-Integration im Shadow-Modus und vergleicht Entscheidungen über fünf breite Themenbereiche hinweg, ohne das Verhalten der Anwendung zu verändern. Der nächste Schritt ist zu testen, ob eine selektive Eskalation den gesamten Workflow verbessert. Die oben genannten Qwen-Ergebnisse sind kein Jev-Benchmark.
Genau das müssen wir messen: weniger unnötige Modellaufrufe, schnellere Bearbeitung vertrauter Anfragen und ein klarer Pfad für Fälle, die mehr Aufmerksamkeit erfordern.
Wir haben begonnen, denselben Ansatz auf Bilder auszuweiten.
Stell dir ein Unternehmen vor, das einen Kassenbon, einen Screenshot eines Fehlers und ein Produktfoto erhält. Jedes Bild braucht einen anderen Verarbeitungspfad.
Ein Kassenbon könnte in die Belegerfassung fließen. Ein Screenshot in einen Support-Workflow. Ein Produktfoto in einen Katalog-Workflow. Ein unsicheres Bild geht in die manuelle Prüfung.
Der Klassifizierer wählt das Ziel aus. Den Kaufbetrag auszulesen, den Fehler zu diagnostizieren und Produktdetails zu identifizieren bleiben separate Aufgaben.
Unsere experimentelle Bildimplementierung nutzt einen vortrainierten CLIP-Encoder, um eine numerische Darstellung des Bildes zu erzeugen.
Ein angepasster Forschungskandidat klassifizierte in einem kleinen Diagnosetest 19 von 20 Fotos von Lebensmittelprodukten korrekt. Außerdem leitete er alle 30 Bilder von Bohnenblättern zur Überprüfung weiter.
Der einzige Fehler: Das Nährwertetikett und der Barcode einer Flasche wurden als Kassenbon eingestuft.
Du siehst das Problem. Beides kann dichten Text, Zahlen und rechteckige Layouts enthalten. Wir brauchen Beispiele, die dem System genau die Grenze beibringen, die für unsere Anwendung relevant ist.
Diese Stichprobe ist zu klein für eine Aussage zum Produktivbetrieb. Die Labels stammten aus dem Datensatz und wurden nicht unabhängig geprüft, zudem gab es im Test keine neuen Kassenbon- oder Screenshot-Beispiele. Die öffentliche Demo nutzt eine separate Baseline, das Ergebnis des angepassten Kandidaten darf ihr also nicht zugeschrieben werden.
Die Bildverarbeitung war außerdem aufwendiger als die Textklassifizierung. Im Warm-Zustand dauerte die Verarbeitung im Median etwa 36 Millisekunden in Node und 197 Millisekunden in Chromium auf dem M4 Max. Der Browser benötigt zunächst rund 85 MiB an Modelldateien plus seine Laufzeitumgebung.
Auch lokale Ausführung verursacht Kosten. Download-Größe, Speicherbedarf, Startzeit und Geräteperformance gehören alle in die Bewertung.
Das Produkt, das mir vorschwebt, fügt sich in eine bestehende Anwendung ein und entscheidet dort, was als Nächstes passiert.
Ein Entwickler definiert Kategorien, liefert repräsentative Beispiele, verknüpft die Ziele und legt fest, was bei einer unsicheren Klassifizierung geschehen soll.
Das erste Deployment sollte den aktuellen Workflow beobachten, ohne dessen Ergebnis zu verändern. Dann können wir vorgeschlagene Entscheidungen mit verifizierten Ergebnissen vergleichen, bevor der Klassifizierer das Routing steuert.
Wir müssen akzeptierte Fehler genauso sorgfältig prüfen wie abgelehnte Anfragen. Sonst verschwindet eine selbstbewusst falsche Entscheidung hinter einem beruhigenden Score.
Training, Kalibrierung und Tests benötigen zudem getrennte Daten. Das Training vermittelt die Kategorien. Die Kalibrierung legt die Akzeptanzregeln fest. Ein geschützter Test überprüft das eingefrorene Ergebnis.
Sobald ein Testfehler das nächste Modell beeinflusst, wird dieses Beispiel zu Entwicklungsdaten. Die nächste Auswertung braucht dann einen frischen Test.
Der kleine Alien in der Briefsortiermaschine hilft Menschen, sich die Aufgabe vorzustellen. Eine nützliche Version zu bauen bedeutet herauszufinden, welche Eingaben sie genau verarbeiten kann, wann sie Hilfe anfordern sollte und was ihre Fehler kosten.
Der nächste Schritt ist ein repräsentativer Workflow mit unabhängigen Labels und einer Aufzeichnung jedes Ergebnisses. Wir müssen messen, wie viele Anfragen den lokalen Weg nehmen, wie viele ein anderes Modell erreichen, wie viele schiefgehen und ob die gesamte Anwendung schneller oder günstiger wird, wenn man diese Fehler einrechnet.
Zeit, das Ganze zu skalieren und diesem lokalen Modell etwas mehr Power zu geben.
