Kev-4B

Résumé du modèle

Kev-4B est un modèle de décision. Il lit un document (l’état) et un ensemble de questions typées à son sujet, et renvoie une distribution de probabilité calibrée sur les options fournies avec chaque question, en une seule passe avant et sans générer de texte. Il est destiné aux développeurs qui classent, routent, trient ou vérifient des documents et qui ont besoin de probabilités sur lesquelles poser un seuil, par exemple pour envoyer les cas incertains en revue humaine. Il implémente l’API System One publique de TypeSafe (POST /v1/systemone), donc le SDK TypeSafe fonctionne avec lui sans modification. C’est un adaptateur LoRA et une tête pointeur sur Qwen3.5-4B-Base, assez petit pour un GPU 24 GB ou un Mac Apple Silicon 32 GB. Cette fiche décrit le checkpoint de Kev 1.0, publié pour la première fois le 2026-09-24.

Détails du modèle

Entrée. Un état (du texte, ou un objet ou tableau JSON rendu en texte étiqueté) et un nombre quelconque de questions nommées, chacune de l’un des trois types :

Chaque question est traitée comme sa propre ligne qui continue depuis l’état partagé, donc les questions ne peuvent pas s’influencer mutuellement ; l’état est calculé une fois et mis en cache.

Usages prévus

• Décisions typées sur des documents de quelques milliers de jetons : classification, routage, triage, choix d’extraction, contrôles de politique et d’éligibilité, et jugement d’une réponse proposée contre des critères énoncés.
• Flux de travail qui agissent sur la confiance : automatiser les cas confiants et mettre les autres en file, avec des seuils figés sur un échantillon étiqueté de la propre charge de travail de l’utilisateur.
• Un remplaçant auto-hébergé, sans modification, d’un point de terminaison System One sur du matériel modeste, et un point de départ pour un fine-tuning sur les propres étiquettes de l’utilisateur (kev.train --init_from jaredpalmer/kev-4b).

Usages hors périmètre

• Génération de texte, chat, résumé ou réponse à des questions ouvertes. Le modèle ne fait qu’évaluer les options qu’on lui donne.
• Décisions entièrement automatisées ayant des conséquences juridiques, médicales, financières, professionnelles ou similaires pour des personnes, sans revue humaine.
• Questions dont la réponse dépend de faits absents de l’état et hors des connaissances générales, et examens très dépendants de connaissances (voir Limites).
• Arithmétique de dates à précision du jour sans le préprocesseur KEV_DATE_FACTS=1, états de plus de 65 536 jetons et langues autres que l’anglais.

Comment l’utiliser

Sers-le avec le dépôt Kev. Sur CUDA, il tourne en bf16 avec les noyaux DeltaNet fusionnés et CUDA graphs (une L40S, une H100 ou tout GPU avec environ 16 GB libres) ; sur Apple Silicon, la même commande le sert via MLX, choisi automatiquement.

git clone https://github.com/jaredpalmer/kev.git && cd kev && uv sync --extra serve
uv run --extra serve python -m kev.serve --run jaredpalmer/kev-4b --port 8008           # Kev 1.0 (this card)
uv run --extra serve python -m kev.serve --run jaredpalmer/kev-4b@v1.0 --port 8008      # the same weights, pinned

from typesafe_sdk import Choice, Noul, TypeSafeClient

client = TypeSafeClient(api_key="local", base_url="http://127.0.0.1:8008", model="kev-latest")
response = client.system_one(
    state="I was charged twice for order 1182. Please refund one of the charges.",
    questions={
        "team": Choice(instructions="Which team should handle this?",
                       criteria={"billing": "Charges and refunds", "shipping": "Deliveries", "returns": "Exchanges"}),
        "urgent": Noul(instructions="Does this need a reply today?"),
    },
)
print(response.choices["team"].choice, response.nouls["urgent"].noul)

La température calibrée est appliquée par défaut ; KEV_TEMPERATURE=1.0 renvoie les probabilités brutes. KEV_DTYPE=fp32 sélectionne le chemin exact utilisé pour l’évaluation. KEV_DATE_FACTS=1 ajoute le nombre de jours entre chaque paire de dates trouvée dans l’état, ce que le modèle a été entraîné à utiliser. Un état de plus de 65 536 jetons est refusé par un 422 qui donne son nombre de jetons.

Données d’entraînement

Chaque étape de fine-tuning après la première rejoue des enregistrements de decision-v7 (2 000, 2 000 et 4 000). Aucune sortie de Jev (le modèle de décision hébergé de TypeSafe) n’a été utilisée. CodeReviewer et FlakeFlagger viennent de Zenodo ; les récits CFPB sont des œuvres du gouvernement américain ; les licences et révisions par source sont consignées dans les manifestes des suites. Les suites d’évaluation seule ci-dessous (breadth-v1, tasksource-heldout-v1, transfer-v4, longdoc-v1, et les sources When2Call et injection de prompt de devtools-v1) n’entrent jamais dans l’entraînement.

Procédure d’entraînement

1. Recette de base. Deux époques sur decision-v7 depuis la base : LoRA rang 16, α 32 ; taux d’apprentissage 5e-5, schedule one-cycle ; batch effectif 8 (4 × 2 d’accumulation) ; autocast bf16, gradient checkpointing ; graine 2. La perte est l’entropie croisée sur les options de chaque question. L’ordre des options est mélangé, des options « none of the above » et des distracteurs sont insérés au hasard, et un quart des enregistrements choice produisent aussi une paire minimale (la question avec une option « none of the above », une fois avec l’option correcte présente et une fois retirée).
2. Dates et preuves manquantes. Une époque depuis l’étape 1 au taux d’apprentissage 2e-5 avec 2 000 enregistrements rejoués.
3. Documents réels. Une époque depuis l’étape 2 sur documents-v1 train au taux d’apprentissage 2e-5 avec 2 000 enregistrements rejoués ; batch 2 × 4 d’accumulation ; états d’au plus 7 552 jetons.
4. Compétences. Une époque depuis l’étape 3 sur hard-v1 et devtools-v1 train réunis au taux d’apprentissage 2e-5 avec 4 000 enregistrements rejoués ; batch 2 × 4 d’accumulation ; états d’au plus 7 552 jetons ; graine 1 ; 1 915 pas d’optimiseur.
5. Calibration. Une température unique, T = 2.41, minimisant la log-vraisemblance négative sur les lignes de développement decision-v7 de l’essai de l’étape 4 (1 264 questions). Ce sont des éléments tenus à l’écart d’un corpus d’entraînement. Un réajustement sur des jeux de données tenus à l’écart a été évalué et non adopté (voir Calibration).

Évaluation

Méthodologie. Chaque chiffre est le chemin d’évaluation fp32 à la température livrée, sauf indication contraire. Les partitions de développement ont servi à la sélection ; les partitions de test ont été lues une fois pour ce checkpoint ; le test transfer-v4 est verrouillé (lu une fois par candidat) et a été jugé contre une barre fixée à l’avance. Les intervalles appariés sont des bootstraps à 95 % qui rééchantillonnent des enregistrements entiers (2 000 rééchantillonnages), donc les questions qui partagent un état bougent ensemble. Les différences sont en points de pourcentage (pp). Jev (le modèle hébergé de TypeSafe, interrogé via Vercel AI Gateway) est montré là où il a été lu sur les mêmes éléments. Les suites :

• breadth-v1 : 14 jeux de données publics tenus à l’écart dans cinq domaines (connaissances, langue, recherche d’information, outils, arts), jamais entraînés.
• tasksource-heldout-v1 : 24 familles de tâches entières d’une collection multi-tâches publique, jamais entraînées (noms des familles privés).
• transfer-v4 : décisions hors domaine issues de six sources publiques jamais entraînées (QNLI, SciQ, TweetEval-offensive, PAWS, MMLU, Emotion) plus des structures de politique et de règles tenues à l’écart.
• hard-v1 : les familles de compétences ci-dessus ; la partition de test met de côté des gabarits de générateurs entraînés.
• devtools-v1 : décisions d’outillage pour développeurs issues de six sources vérifiées quant à leur licence (quatre entraînées, deux en évaluation seule).
• documents-v1 / documents-v2 : récits de plaintes CFPB ; v2 est un ensemble de test privé tenu à l’écart.
• longdoc-v1 : contrats commerciaux CUAD et ensembles d’accords générés, avec des états de 4k à 64k jetons.

Les panneaux phares marqués « audited » excluent les éléments qu’un audit d’étiquettes a jugés non valables¹ ; chaque exclusion retire les mêmes lignes des deux côtés d’une comparaison.

Données tenues à l’écart (jamais entraînées).

Familles entraînées (éléments et gabarits tenus à l’écart).

Le chiffre devtools-v1 de Jev porte sur les 1 074 questions de développement ; les lignes de Kev retirent un id CodeReviewer que le constructeur de la suite a réutilisé pour deux enregistrements (2 questions).

Contre la version précédente (le checkpoint de l’étape documents, étiquette r8-documents-release, à sa propre température 2.96 ; critères enregistrés, chaque test lu une fois) :

Documents longs.

• Longueur de contexte validée : 8 192 jetons, la longueur d’entraînement. Le bucket 16k est hors tolérance : sa borne inférieure est −3.4 pp, sous −3 pp, donc aucune longueur supérieure n’est validée.
• Règle, fixée avant la lecture : la longueur validée est la taille nominale du plus grand bucket à partir de 16 384 jetons tel que lui-même, et chaque bucket entre lui et 8 192, soit dans la tolérance. Être dans la tolérance signifie que la différence d’exactitude CUAD par rapport au bucket 8k (états de 6 553–7 618 jetons, la longueur d’entraînement), appariée sur le même contrat, la même répétition et la même question, a une borne inférieure à 95 % d’au moins −3 pp, et que chaque enregistrement a reçu une réponse. Si le bucket 16k échoue, la longueur validée est 8 192 jetons.

Exactitude CUAD, ECE et différence appariée par rapport au bucket 8k selon la longueur nominale de l’état (longdoc-v1 développement) :

ECE à la température livrée T = 2.41. Δ est apparié sur les 445–447 questions posées sur les mêmes contrats aux deux longueurs. Le bucket 4k contient d’autres contrats et ne sert pas de référence pour la règle. Source : runs/r28-readout/context.json (le read-out enregistré de la ronde 28, runs/r28-4b-r10-longdoc).

Calibration (erreur de calibration attendue, ECE, à la température livrée T = 2.41 ; plus bas est mieux) :

La température livrée a été ajustée sur des éléments tenus à l’écart d’un corpus d’entraînement, ce que les règles du projet n’autorisent plus pour une nouvelle publication. Un réajustement enregistré sur 648 questions issues de jeux de données tenus à l’écart (la partition de calibration de transfer-r3, huit sources, et 200 questions MMLU-Pro) donne T = 2.30 (intervalle bootstrap à 90 % [2.05, 2.52]). Sur les 4 468 questions de développement breadth-v1 et tasksource-heldout-v1 audited, il n’améliore pas la valeur livrée : Brier 0.368 pour les deux, une différence de −0.0001 [−0.0005, +0.0003], et ECE 0.025 contre 0.024. La règle exigeait un intervalle de Brier sous zéro et un ECE plus bas, donc T = 2.41 reste. Les réponses ne dépendent pas de T.

Autres résultats.

Service. CUDA, bf16 avec noyaux fusionnés et CUDA graphs ; temps de modèle par requête (médiane sur 20) pour un état nouveau / répété :

La mémoire GPU résidente est de 14.3 GB. Les probabilités servies restent à moins de 0.017 du chemin d’évaluation fp32 sur 280 questions, sans réponse changée. Sur le chemin d’évaluation fp32 (H100), les états de 16k / 32k / 64k jetons prennent 3.0 / 6.8 / 17.2 s et 4.3 / 8.6 / 17.2 GiB au-dessus des poids.

Apple Silicon (MLX, bf16, M5 avec 32 GB ; trois questions, une portant sur un fait planté à 60 % de profondeur ; l’état est prérempli par blocs de 1 024 jetons) :

Sur 60 questions à état court, le chemin MLX reste à moins de 0.018 du chemin d’évaluation fp32, sans réponse changée.

¹ Exclus des panneaux audited : quatre jeux de données breadth-v1 (routerbench, dont les états n’ont pas l’information demandée ; cfcolor et humicroedit, au hasard pour tout système ; chessbench, au plancher pour tout système) ; sept familles tasksource-heldout-v1 avec des étiquettes invalides ou irrécupérables (noms privés) ; deux tâches devtools-v1 dont les étiquettes ne sont pas déterminées par l’état (flakeflagger, type de changement de commit).

² L’indice corrigé du hasard du Decision Index communautaire 0.2 : par jeu de données (score − hasard) / (1 − hasard), moyenné dans chaque domaine, puis 100 × la moyenne des cinq domaines. L’indice de Jev vient d’une lecture séparée des mêmes éléments de test.

Limites et compromis

• Ses plus grands gains sont en distribution. Les partitions d’entraînement de hard-v1, devtools-v1 et documents-v1 sont dans ses données d’entraînement, et un élément de test hard-v1 est un nouveau gabarit d’un générateur entraîné. Sur les jeux de données tenus à l’écart, il est à 16 points derrière Jev sur l’indice breadth-v1, et sur le palier difficile public de JevBench, un contrôle hors distribution, l’étape compétences a gagné environ un tiers de ce qu’elle a gagné sur hard-v1 (+9.0 pp [+2.7, +15.3] sur 111 éléments).
• Certaines étiquettes devtools-v1 sont des proxys. Avant l’entraînement, tous les modèles évalués, Jev compris, étaient proches du hasard sur CodeReviewer et FlakeFlagger ; après entraînement sur ces sources, il atteint 0.633 et 0.693 en développement, ce qui peut être l’heuristique d’étiquetage apprise plutôt que la décision.
• Les connaissances sont fixées par la base. MMLU-Pro est 0.565 contre 0.840 pour Jev.
• L’arithmétique de dates est sa famille la plus faible : 0.65 sur les questions de politique deadline contre 0.95 pour Jev. Le préprocesseur KEV_DATE_FACTS=1 aide (sur le checkpoint antérieur dont celui-ci descend, 0.60 → 0.85) ; il n’a pas été remesuré sur ce checkpoint.
• La calibration est une seule température en distribution. Il est bien calibré sur les jeux de données tenus à l’écart (breadth-v1 test ECE 0.029), moins sur les familles de compétences et de documents entraînées (ECE 0.084–0.101), et une température unique ne peut pas réordonner les confiances : la couverture à ≤ 5 % d’erreur hors domaine est de 0.620 en développement contre 0.70 pour Jev.
• Longueurs non entraînées. Les états d’entraînement faisaient au plus 7 552 jetons. Les états plus longs sont servis jusqu’à 65 536 jetons ; jusqu’où l’exactitude tient est la longueur de contexte validée ci-dessus.
• L’ordre des options peut changer une réponse ; l’isolation des questions ne l’empêche pas.

Biais, risques et considérations éthiques

• Des probabilités calibrées peuvent créer une confiance injustifiée. La température a été ajustée sur des lignes de développement de la distribution d’entraînement et ne se transfère pas à chaque charge de travail ; mesure l’exactitude et la calibration sur un échantillon étiqueté de tes propres données, et réajuste-y la température (python -m kev.calibrate), avant de fixer des seuils.
• L’exactitude et la calibration bougent sous changement de domaine. Surveille les taux d’erreur en production plutôt que de te fier aux chiffres ci-dessus.
• Ne l’utilise pas pour des décisions automatisées lourdes de conséquences sur des personnes sans revue humaine. Les biais du modèle de base et des données d’entraînement (y compris les étiquettes produites par d’autres modèles) ne sont pas mesurés.
• Les états peuvent contenir des données personnelles ou confidentielles. L’auto-hébergement garde les entrées sur ton propre matériel ; le serveur est ouvert sauf si KEV_API_KEY est défini, donc applique ta propre politique de contrôle d’accès et de traitement des données.

Calcul

• Recette de base : environ 56 minutes sur un NVIDIA H100 (pic 24.6 GB). Étape dates : 9 minutes sur une H100.
• Étape documents : 43 minutes sur un NVIDIA H200. Étape compétences : 1.4 heures sur un H200 (pic 47.7 GB).
• Vérifications d’évaluation et de service : GPU H100 / H200 / L40S uniques sur Modal ; mesures MLX sur un Apple M5.

Provenance et reproductibilité

• Code, suites et rapports d’évaluation : github.com/jaredpalmer/kev. Chiffres de publication : runs/release/kev-4b-r10.json (scripts/release_numbers.py --release kev-4b-r10), la lecture verrouillée runs/locked/kev-4b-r10-ungated/, les lectures de famille du 2026-09-30 runs/fam-4b-breadth/, runs/fam-4b-breadthtest/, runs/fam-4b-docs1test/ et runs/fam-breadth-test-report/, le réajustement de calibration runs/r28-readout/round28.json, le service runs/serve-4b-l40s/, runs/grouping-4b-h100/, runs/long-state-4b-h100/, runs/mlx-long-states/, runs/mlx-full-4b/.
• Étapes : essai de base q35-4b-s23/00-trial-0 (étiquette v7-base) ; dates night2-4b-du/00-trial-0 (étiquette night2-du-release) ; documents ronde 8 r8-small/00-trial-0 (étiquette r8-documents-release) ; compétences ronde 10 r10-skills/00-trial-0 (experiments/round10/skills.json, règle experiments/rounds/r10.json). Réajustement de calibration : bras 28 4b-r10 (experiments/rounds/r28.json).
• Poids publiés : révision Hub 139fdd94 ; sha256 de l’adaptateur 90e81735…, sha256 de head.pt dd633435… (T = 2.4061).
• Historique de publication : publié le 2026-09-24 comme candidat confirmé de la ronde 10 ; inclus sans changement dans Kev 1.0. Le récit de sa sélection, y compris les suites depuis retirées comme non valables (scienthoon, WANLI-v2, TypeSafe), est le README à la révision Hub 139fdd94 et PLAN.md à l’étiquette git research-archive-2026-09-24.

Citation

@misc{palmer2026kev4b,
  title        = {Kev-4B: a calibrated decision model on Qwen3.5-4B},
  author       = {Palmer, Jared},
  year         = {2026},
  howpublished = {\url{https://huggingface.co/jaredpalmer/kev-4b}},
  note         = {Kev 1.0}
}

Contact

Questions et problèmes : github.com/jaredpalmer/kev/issues.