Kev-4B

Resumen del modelo

Kev-4B es un modelo de decisión. Lee un documento (el estado) y un conjunto de preguntas tipadas sobre él, y devuelve una distribución de probabilidad calibrada sobre las opciones facilitadas con cada pregunta, en una sola pasada hacia adelante y sin generar texto. Está pensado para desarrolladores que clasifican, enrutan, triajan o comprueban documentos y que necesitan probabilidades sobre las que se pueda aplicar un umbral, por ejemplo para enviar los casos inciertos a revisión humana. Implementa la API pública System One de TypeSafe (POST /v1/systemone), así que el SDK de TypeSafe funciona contra él sin cambios. Es un adaptador LoRA y una cabeza de puntero sobre Qwen3.5-4B-Base, lo bastante pequeño para una GPU de 24 GB o un Mac con Apple Silicon de 32 GB. Esta tarjeta describe el checkpoint de Kev 1.0, publicado por primera vez el 2026-09-24.

Detalles del modelo

Entrada. Un estado (texto, o un objeto o array JSON renderizado como texto etiquetado) y cualquier número de preguntas con nombre, cada una de uno de tres tipos:

Cada pregunta se responde como su propia fila que continúa desde el estado compartido, así que las preguntas no pueden influirse entre sí; el estado se calcula una vez y se guarda en caché.

Usos previstos

• Decisiones tipadas sobre documentos de unos miles de tokens: clasificación, enrutamiento, triaje, elecciones de extracción, comprobaciones de política y elegibilidad, y juzgar una respuesta propuesta contra criterios enunciados.
• Flujos de trabajo que actúan según la confianza: automatizar los casos con confianza y poner en cola el resto, con umbrales congelados sobre una muestra etiquetada de la propia carga de trabajo del usuario.
• Un sustituto autoalojado y directo de un endpoint System One en hardware modesto, y un punto de partida para hacer fine-tuning con las propias etiquetas del usuario (kev.train --init_from jaredpalmer/kev-4b).

Usos fuera de alcance

• Generación de texto, chat, resumen o respuesta a preguntas abiertas. El modelo solo puntúa las opciones que se le dan.
• Decisiones totalmente automatizadas con consecuencias legales, médicas, financieras, laborales o similares para personas, sin revisión humana.
• Preguntas cuya respuesta depende de hechos que no están en el estado ni son conocimiento general, y exámenes con mucho conocimiento (véase Limitaciones).
• Aritmética de fechas con precisión de día sin el preprocesador KEV_DATE_FACTS=1, estados de más de 65,536 tokens e idiomas distintos del inglés.

Cómo usarlo

Sírvelo con el repositorio de Kev. En CUDA se ejecuta en bf16 con kernels fusionados de DeltaNet y CUDA graphs (una L40S, una H100 o cualquier GPU con unos 16 GB libres); en Apple Silicon el mismo comando lo sirve mediante MLX, elegido automáticamente.

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 temperatura calibrada se aplica por defecto; KEV_TEMPERATURE=1.0 devuelve las probabilidades sin calibrar. KEV_DTYPE=fp32 selecciona la ruta exacta usada para la evaluación. KEV_DATE_FACTS=1 añade el número de días entre cada par de fechas encontradas en el estado, que el modelo se entrenó para usar. Un estado de más de 65,536 tokens se rechaza con un 422 que indica su número de tokens.

Datos de entrenamiento

Cada etapa de fine-tuning después de la primera repite registros de decision-v7 (2,000, 2,000 y 4,000). No se usó ninguna salida de Jev (el modelo de decisión alojado de TypeSafe). CodeReviewer y FlakeFlagger proceden de Zenodo; las narrativas del CFPB son obras del gobierno de EE. UU.; las licencias y revisiones por fuente se registran en los manifiestos de las suites. Las suites solo de evaluación de abajo (breadth-v1, tasksource-heldout-v1, transfer-v4, longdoc-v1 y las fuentes de When2Call e inyección de prompts de devtools-v1) nunca entran en el entrenamiento.

Procedimiento de entrenamiento

1. Receta base. Dos épocas sobre decision-v7 desde la base: rango de LoRA 16, α 32; tasa de aprendizaje 5e-5, esquema one-cycle; lote efectivo 8 (4 × 2 de acumulación); autocast bf16, gradient checkpointing; semilla 2. La pérdida es entropía cruzada sobre las opciones de cada pregunta. El orden de las opciones se mezcla, se insertan al azar opciones “none of the above” y distractores, y un cuarto de los registros choice también producen un par mínimo (la pregunta con una opción “none of the above”, una vez con la opción correcta presente y otra con ella eliminada).
2. Fechas y evidencia ausente. Una época desde la etapa 1 con tasa de aprendizaje 2e-5 y 2,000 registros repetidos.
3. Documentos reales. Una época desde la etapa 2 sobre documents-v1 train con tasa de aprendizaje 2e-5 y 2,000 registros repetidos; lote 2 × 4 de acumulación; estados de como máximo 7,552 tokens.
4. Habilidades. Una época desde la etapa 3 sobre hard-v1 y devtools-v1 train juntos con tasa de aprendizaje 2e-5 y 4,000 registros repetidos; lote 2 × 4 de acumulación; estados de como máximo 7,552 tokens; semilla 1; 1,915 pasos de optimizador.
5. Calibración. Una única temperatura, T = 2.41, que minimiza la log-verosimilitud negativa en las filas de desarrollo de decision-v7 del ensayo de la etapa 4 (1,264 preguntas). Son elementos reservados de un corpus de entrenamiento. Se evaluó un reajuste sobre conjuntos de datos reservados y no se adoptó (véase Calibración).

Evaluación

Metodología. Cada número es la ruta de evaluación fp32 a la temperatura distribuida, salvo que se indique otra cosa. Las particiones de desarrollo se usaron para la selección; las particiones de test se leyeron una vez para este checkpoint; el test transfer-v4 está bloqueado (se lee una vez por candidato) y se juzgó contra un listón fijado de antemano. Los intervalos emparejados son bootstraps del 95 % que remuestrean registros completos (2,000 remuestreos), así que las preguntas que comparten un estado se mueven juntas. Las diferencias están en puntos porcentuales (pp). Jev (el modelo alojado de TypeSafe, consultado a través de Vercel AI Gateway) se muestra donde se leyó con los mismos elementos. Las suites:

• breadth-v1: 14 conjuntos de datos públicos reservados en cinco áreas (conocimiento, lenguaje, recuperación, herramientas, artes), nunca entrenados.
• tasksource-heldout-v1: 24 familias de tareas completas de una colección multitarea pública, nunca entrenadas (nombres de familia privados).
• transfer-v4: decisiones fuera de dominio de seis fuentes públicas nunca entrenadas (QNLI, SciQ, TweetEval-offensive, PAWS, MMLU, Emotion) más estructuras de política y reglas reservadas.
• hard-v1: las familias de habilidades de arriba; la partición de test reserva plantillas de generadores entrenados.
• devtools-v1: decisiones de herramientas de desarrollo de seis fuentes con licencia comprobada (cuatro entrenadas, dos solo de evaluación).
• documents-v1 / documents-v2: narrativas de quejas del CFPB; v2 es un conjunto de test reservado privado.
• longdoc-v1: contratos comerciales CUAD y paquetes de acuerdos generados, con estados de 4k a 64k tokens.

Los paneles destacados marcados como “auditados” excluyen los elementos que una auditoría de etiquetas encontró poco sólidos¹; cada exclusión elimina las mismas filas de ambos lados de una comparación.

Datos reservados (nunca entrenados).

Familias entrenadas (elementos y plantillas reservados).

La cifra de devtools-v1 de Jev es sobre las 1,074 preguntas de desarrollo; las filas de Kev descartan un id de CodeReviewer que el constructor de la suite reutilizó para dos registros (2 preguntas).

Frente a la versión anterior (el checkpoint de la etapa de documentos, etiqueta r8-documents-release, a su propia temperatura 2.96; criterios registrados, cada test leído una vez):

Documentos largos.

• Longitud de contexto validada: 8,192 tokens, la longitud entrenada. El cubo de 16k está fuera de la tolerancia: su límite inferior es −3.4 pp, por debajo de −3 pp, así que no se valida ninguna longitud mayor.
• Regla, fijada antes de la lectura: la longitud validada es el tamaño nominal del cubo más grande desde 16,384 tokens hacia arriba tal que él, y todos los cubos entre él y 8,192, estén dentro de la tolerancia. Dentro de la tolerancia significa que la diferencia de precisión en CUAD respecto al cubo de 8k (estados de 6,553–7,618 tokens, la longitud entrenada), emparejada por el mismo contrato, repetición y pregunta, tiene un límite inferior del 95 % de al menos −3 pp, y que se respondió cada registro. Si el cubo de 16k falla, la longitud validada es 8,192 tokens.

Precisión en CUAD, ECE y la diferencia emparejada respecto al cubo de 8k por longitud nominal del estado (desarrollo longdoc-v1):

ECE a la T distribuida de 2.41. Δ está emparejada sobre las 445–447 preguntas formuladas sobre los mismos contratos en ambas longitudes. El cubo de 4k contiene contratos distintos y no es una referencia para la regla. Fuente: runs/r28-readout/context.json (la lectura registrada de la ronda 28, runs/r28-4b-r10-longdoc).

Calibración (error de calibración esperado, ECE, a la T distribuida de 2.41; más bajo es mejor):

La temperatura distribuida se ajustó sobre elementos reservados de un corpus de entrenamiento, algo que las reglas del proyecto ya no permiten para una nueva versión. Un reajuste registrado sobre 648 preguntas de conjuntos de datos reservados (la partición de calibración de transfer-r3, ocho fuentes, y 200 preguntas de MMLU-Pro) da T = 2.30 (intervalo bootstrap del 90 % [2.05, 2.52]). En las 4,468 preguntas de desarrollo auditadas de breadth-v1 y tasksource-heldout-v1 no mejora el valor distribuido: Brier 0.368 en ambos, una diferencia de −0.0001 [−0.0005, +0.0003], y ECE 0.025 frente a 0.024. La regla exigía un intervalo de Brier por debajo de cero y un ECE menor, así que T = 2.41 se queda. Las respuestas no dependen de T.

Otros resultados.

Servicio. CUDA, bf16 con kernels fusionados y CUDA graphs; tiempo de modelo por solicitud (mediana de 20) para un estado nuevo / repetido:

La memoria de GPU residente es 14.3 GB. Las probabilidades servidas se mantienen dentro de 0.017 de la ruta de evaluación fp32 en 280 preguntas, sin respuestas cambiadas. En la ruta de evaluación fp32 (H100), los estados de 16k / 32k / 64k tokens tardan 3.0 / 6.8 / 17.2 s y 4.3 / 8.6 / 17.2 GiB por encima de los pesos.

Apple Silicon (MLX, bf16, M5 con 32 GB; tres preguntas, una sobre un hecho plantado al 60 % de profundidad; el estado se prellena en fragmentos de undefined tokens):

En 60 preguntas de estado corto, la ruta de MLX se mantiene dentro de 0.018 de la ruta de evaluación fp32, sin respuestas cambiadas.

¹ Excluidos de los paneles auditados: cuatro conjuntos de datos de breadth-v1 (routerbench, cuyos estados carecen de la información pedida; cfcolor y humicroedit, en el nivel del azar para todos los sistemas; chessbench, en el suelo para todos los sistemas); siete familias de tasksource-heldout-v1 con etiquetas inválidas o irrecuperables (nombres privados); dos tareas de devtools-v1 cuyas etiquetas no determina el estado (flakeflagger, tipo de cambio de commit).

² El índice corregido por azar del Decision Index 0.2 de la comunidad: por conjunto de datos (puntuación − azar) / (1 − azar), promediado dentro de cada área, y luego 100 × la media de las cinco áreas. El índice de Jev proviene de una lectura separada de los mismos elementos de test.

Limitaciones y compromisos

• Sus mayores ganancias son en distribución. Las particiones de entrenamiento de hard-v1, devtools-v1 y documents-v1 están en sus datos de entrenamiento, y un elemento de test de hard-v1 es una plantilla nueva de un generador entrenado. En conjuntos de datos reservados va 16 puntos por detrás de Jev en el índice de breadth-v1, y en el nivel difícil público de JevBench, una comprobación fuera de distribución, la etapa de habilidades ganó aproximadamente un tercio de lo que ganó en hard-v1 (+9.0 pp [+2.7, +15.3] sobre 111 elementos).
• Algunas etiquetas de devtools-v1 son aproximaciones. Antes del entrenamiento, todos los modelos puntuados, incluido Jev, estaban cerca del azar en CodeReviewer y FlakeFlagger; tras entrenar con esas fuentes alcanza 0.633 y 0.693 en desarrollo, lo que puede ser que se esté aprendiendo la heurística de etiquetado y no la decisión.
• El conocimiento lo fija la base. MMLU-Pro es 0.565 frente al 0.840 de Jev.
• La aritmética de fechas es su familia más débil: 0.65 en las preguntas de política deadline frente al 0.95 de Jev. El preprocesador KEV_DATE_FACTS=1 ayuda (en el checkpoint anterior del que desciende este, 0.60 → 0.85); no se volvió a medir en este checkpoint.
• La calibración es una temperatura en distribución. Está bien calibrado en conjuntos de datos reservados (ECE del test breadth-v1 0.029), menos en las familias de habilidades y documentos entrenadas (ECE 0.084–0.101), y una sola temperatura no puede reordenar las confianzas: la cobertura con ≤ 5 % de error fuera de dominio es 0.620 en desarrollo frente al 0.70 de Jev.
• Longitudes no entrenadas. Los estados de entrenamiento eran de como máximo undefined tokens. Los estados más largos se sirven hasta 65,536 tokens; hasta dónde aguanta la precisión es la longitud de contexto validada de arriba.
• El orden de las opciones puede cambiar una respuesta; el aislamiento de preguntas no lo impide.

Sesgo, riesgos y consideraciones éticas

• Las probabilidades calibradas pueden crear una confianza injustificada. La temperatura se ajustó sobre filas de desarrollo de la distribución de entrenamiento y no transfiere a todos los flujos de trabajo; mide la precisión y la calibración con una muestra etiquetada de tus propios datos, y reajusta allí la temperatura (python -m kev.calibrate), antes de fijar umbrales.
• La precisión y la calibración cambian bajo un cambio de dominio. Vigila las tasas de error en producción en lugar de fiarte de los números anteriores.
• No lo uses para decisiones automatizadas trascendentales sobre personas sin revisión humana. Los sesgos del modelo base y de los datos de entrenamiento (incluidas las etiquetas producidas por otros modelos) no se miden.
• Los estados pueden contener datos personales o confidenciales. El autoalojamiento mantiene las entradas en tu propio hardware; el servidor está abierto a menos que se defina KEV_API_KEY, así que aplica tu propia política de control de acceso y tratamiento de datos.

Cómputo

• Receta base: unos 56 minutos en una NVIDIA H100 (pico 24.6 GB). Etapa de fechas: 9 minutos en una H100.
• Etapa de documentos: 43 minutos en una NVIDIA H200. Etapa de habilidades: 1.4 horas en una H200 (pico 47.7 GB).
• Comprobaciones de evaluación y servicio: GPUs H100 / H200 / L40S individuales en Modal; mediciones de MLX en un Apple M5.

Procedencia y reproducibilidad

• Código, suites e informes de evaluación: github.com/jaredpalmer/kev. Números de publicación: runs/release/kev-4b-r10.json (scripts/release_numbers.py --release kev-4b-r10), la lectura bloqueada runs/locked/kev-4b-r10-ungated/, las lecturas familiares del 2026-09-30 runs/fam-4b-breadth/, runs/fam-4b-breadthtest/, runs/fam-4b-docs1test/ y runs/fam-breadth-test-report/, el reajuste de calibración runs/r28-readout/round28.json, servicio runs/serve-4b-l40s/, runs/grouping-4b-h100/, runs/long-state-4b-h100/, runs/mlx-long-states/, runs/mlx-full-4b/.
• Etapas: ensayo base q35-4b-s23/00-trial-0 (etiqueta v7-base); fechas night2-4b-du/00-trial-0 (etiqueta night2-du-release); documentos ronda 8 r8-small/00-trial-0 (etiqueta r8-documents-release); habilidades ronda 10 r10-skills/00-trial-0 (experiments/round10/skills.json, regla experiments/rounds/r10.json). Reajuste de calibración: ronda 28, brazo 4b-r10 (experiments/rounds/r28.json).
• Pesos publicados: revisión del Hub 139fdd94; sha256 del adaptador 90e81735…, sha256 de head.pt dd633435… (T = 2.4061).
• Historial de publicaciones: publicado el 2026-09-24 como candidato confirmado de la ronda 10; incluido sin cambios en Kev 1.0. El registro de cómo se seleccionó, incluidas suites retiradas después por poco sólidas (scienthoon, WANLI-v2, TypeSafe), es el README en la revisión del Hub 139fdd94 y PLAN.md en la etiqueta de git research-archive-2026-09-24.

Cita

@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}
}

Contacto

Preguntas e incidencias: github.com/jaredpalmer/kev/issues.