Jared Palmer: Kev 4B

Kev-4B ist ein kompaktes Entscheidungsmodell zur Beantwortung typisierter Fragen über einen bereitgestellten Zustand. Der Zustand ist das zu bewertende Dokument oder der zu bewertende Datensatz, und jede Frage definiert die Optionen, die das Modell bewerten kann. Sein Ergebnis ist eine Wahrscheinlichkeitsverteilung und ein typisierter Entscheidungsdatensatz; das macht es nützlich für Dokumentklassifikation, Routing, Triage, Extraktionsentscheidungen und Prüfungen anhand festgelegter Kriterien.

Das Modell kombiniert ein eingefrorenes Qwen3.5-4B-Base-Backbone mit einem LoRA-Adapter und einem Pointer-Head. Das Backbone hat 32 Schichten, davon 24 Gated-DeltaNet-Schichten und acht Full-Attention-Schichten. Der Adapter zielt auf Attention-, MLP- und DeltaNet-Projektionen; der Pointer-Head bewertet die bereitgestellten Optionen und wandelt diese Scores in Wahrscheinlichkeiten um. Es handelt sich um einen reinen Prefill-Entscheidungsworkflow, bei dem die Optionen den Antwortraum bilden.

Drei Fragetypen können in derselben Anfrage vorkommen. Eine Auswahlfrage akzeptiert 1–255 benannte Optionen, optional mit Beschreibungen, und gibt die wahrscheinlichste Option, einen separaten Konfidenzwert und Wahrscheinlichkeiten für die Optionen zurück. Eine Ja/Nein-Frage, im Format des Herstellers noul genannt, gibt die Wahrscheinlichkeit für Ja zurück. Definieren Sie die Bedeutung von Ja in der Frage, statt anzunehmen, dass eine hohe Zahl für die Anwendung immer ein positives Ergebnis bedeutet.

Eine geordnete Score-Frage akzeptiert 1–255 Stufen und gibt Wahrscheinlichkeiten für die Stufen sowie deren erwarteten Index zurück. Die Stufenindizes beginnen bei null. Das Ergebnisformat des Herstellers enthält außerdem die Legende der Stufen und einen separaten Konfidenzwert. Ein erwarteter Index kann Nachkommastellen haben: Er fasst die Verteilung über Ihre geordneten Stufen zusammen, statt eine neue Textbezeichnung auszuwählen. Bewahren Sie Reihenfolge und Legende der Stufen zusammen mit dem Ergebnis auf, damit eine Bewertung konsistent interpretiert werden kann.

Fragen teilen sich denselben Zustand, werden aber unabhängig voneinander ausgewertet. Eine Frage kann die Antwort einer anderen nicht lesen, und der Zustand wird einmal berechnet und wiederverwendet. Hängt eine spätere Entscheidung vom Ergebnis einer früheren ab, machen Sie diese Abhängigkeit in einem nachfolgenden Zustand explizit, statt zu erwarten, dass die Fragen einer Anfrage eine Kette bilden. Dadurch eignet sich der Workflow mit gemeinsamem Zustand für mehrere unabhängige Prüfungen desselben Dokuments.

Bereiten Sie den Zustand mit den Belegen vor, die die Fragen tatsächlich benötigen. Er kann Klartext sein oder ein JSON-Objekt bzw. -Array, das als beschrifteter Text dargestellt wird. Halten Sie Feldnamen, Einheiten, Richtlinienbedingungen und die relevanten Quellpassagen klar. Formulieren Sie für jede Frage eine konkrete Anweisung und geben Sie ihren Optionen Bedeutungen, die sich anhand des Datensatzes unterscheiden lassen. Bei einer eigens konzipierten Aufgabe zum Support-Routing kann der Zustand die Anfrage und ihren Kontext enthalten, während die Auswahlmöglichkeiten die Kategorien Lieferung, Zugriff und Produktsupport mit kurzen Beschreibungen definieren.

Eine zweite Frage kann die Dringlichkeit bewerten, und eine geordnete Frage kann einstufen, wie viel Nachbearbeitung die Anfrage benötigt. Diese beantworten unterschiedliche betriebliche Fragen; definieren Sie daher jede separat. Nehmen Sie eine geeignete Option für Prüfung oder fehlende Belege auf, wenn die Auswahlaufgabe eine benötigt, und bewahren Sie die vollständige Verteilung auf, wenn mehrere Kategorien plausibel sind. Die Anwendung entscheidet, wie ein Ergebnis weitergeleitet oder geprüft wird; das Modell liefert den bewerteten Datensatz.

Kev-4B ist für typisierte Entscheidungen über Dokumente mit einigen tausend Tokens vorgesehen. Das Serving-Profil des Herstellers akzeptiert Zustände mit bis zu 65.536 Tokens und reserviert zusätzlichen Platz für jede Frage, während die validierte Kontextlänge für diesen Checkpoint 8192 Tokens beträgt. Das sind unterschiedliche Grenzen: Dass ein längerer Zustand akzeptiert wird, belegt nicht, dass Entscheidungen bei jeder Länge gleich zuverlässig sind. Halten Sie entscheidende Passagen kompakt und bewahren Sie ihre Beschriftungen, wenn Sie einen langen Datensatz für die Klassifikation vorbereiten.

Das veröffentlichte Profil ist englischsprachig. Seine nützlichen Aufgaben hängen von den Belegen im bereitgestellten Zustand und von den definierten Optionen ab, nicht von offenem Chat, Zusammenfassung oder breiter wissensbasierter Beantwortung. Datumsberechnungen auf Tagesebene sind eine besondere Einschränkung: Der Hersteller stellt einen separaten Präprozessor für Datumsfakten bereit, der berechnete Intervalle liefert. Nehmen Sie bei einer Fristprüfung die relevanten Daten und die berechneten Tagesintervalle zusammen mit der Regel, die sie verwendet, in den Zustand auf.

Der Checkpoint wird mit angepasster Wahrscheinlichkeitskalibrierung ausgeliefert, doch die Konfidenz kann sich mit der Dokumentdomäne und dem Fragendesign ändern. Der Hersteller dokumentiert außerdem das Fine-Tuning des offenen Checkpoints auf aufgabenspezifische Labels und die Anpassung seiner Wahrscheinlichkeitskalibrierung an diesen Workload; das ist ein vom Bewerten eines bereitgestellten Zustands getrennter Anpassungsworkflow. Wählen Sie Entscheidungsschwellen anhand gelabelter Beispiele des tatsächlichen Workloads und halten Sie unsichere Fälle für die Prüfung sichtbar. Der Hersteller schließt vollständig automatisierte folgenreiche Entscheidungen über Personen ohne menschliche Prüfung aus. Auch die Reihenfolge der Optionen kann eine Antwort beeinflussen; behalten Sie daher eine stabile Reihenfolge bei, wenn Sie Ergebnisse vergleichen. Bewerten Sie das gewählte Label, das separate Konfidenzfeld und die Wahrscheinlichkeitsverteilung entsprechend der Rolle, die jedes davon in Ihrem Workflow spielt.

Das aktuelle, vom Hersteller beschriebene Kev-4B-Release gehört zu Kev 1.0 und verwendet die Qwen3.5-Basis. Frühere Qwen3-basierte Releases und Releases, die nur die Dokumentstufe umfassen, bleiben eigenständige Versionen. Halten Sie die gewählte Edition und die Fragedefinitionen mit den Ausgaben verknüpft, wenn Sie einen aufgabenspezifischen Workflow entwickeln, statt Ergebnisse verschiedener Profile zu vermischen.

Ein nützliches Endartefakt ist ein benannter Satz von Entscheidungsdatensätzen mit den ursprünglichen Fragen, Optionsdefinitionen, Verteilungen und allen Legenden geordneter Stufen. Bei einer Prüfung der Antwortqualität sollte der Zustand die vorgeschlagene Antwort, die Belege und das geprüfte Kriterium enthalten. Bei einer Richtlinien-Triage sollte er die anwendbare Regel und die relevanten Fakten enthalten. Bewahren Sie diese Eingabe neben dem Ergebnis auf, damit eine Prüfung feststellen kann, warum eine Entscheidung angemessen war oder welche fehlende Tatsache noch geliefert werden muss.