Kev-4B

Resumo do modelo

O Kev-4B é um modelo de decisão. Ele lê um documento (o estado) e um conjunto de perguntas tipadas sobre ele, e devolve uma distribuição de probabilidade calibrada sobre as opções fornecidas com cada pergunta, em uma única passada direta e sem gerar texto. Ele é indicado para desenvolvedores que classificam, roteiam, fazem triagem ou conferem documentos e que precisam de probabilidades que possam receber limiar, por exemplo para enviar casos incertos à revisão humana. Ele implementa a API pública System One da TypeSafe (POST /v1/systemone), de modo que o SDK da TypeSafe funciona contra ele sem alterações. É um adaptador LoRA e uma cabeça de ponteiro sobre o Qwen3.5-4B-Base, pequeno o bastante para uma GPU de 24 GB ou um Mac Apple Silicon de 32 GB. Esta ficha descreve o checkpoint no Kev 1.0, publicado pela primeira vez em 2026-09-24.

Detalhes do modelo

Entrada. Um estado (texto, ou um objeto ou array JSON renderizado como texto rotulado) e qualquer número de perguntas nomeadas, cada uma de um dos três tipos:

Cada pergunta é respondida como a sua própria linha, que continua a partir do estado compartilhado, então as perguntas não podem influenciar umas às outras; o estado é calculado uma vez e armazenado em cache.

Usos pretendidos

• Decisões tipadas sobre documentos de alguns milhares de tokens: classificação, roteamento, triagem, escolhas de extração, verificações de política e elegibilidade, e julgar uma resposta proposta contra critérios declarados.
• Fluxos de trabalho que agem com base na confiança: automatize os casos confiantes e coloque o resto na fila, com limiares congelados em uma amostra rotulada da carga de trabalho do próprio usuário.
• Um substituto direto e auto-hospedado para um endpoint System One em hardware modesto, e um ponto de partida para ajuste fino nos rótulos do próprio usuário (kev.train --init_from jaredpalmer/kev-4b).

Usos fora de escopo

• Geração de texto, chat, sumarização ou respostas a perguntas abertas. O modelo apenas pontua as opções que recebe.
• Decisões totalmente automatizadas com consequências legais, médicas, financeiras, trabalhistas ou semelhantes para pessoas, sem revisão humana.
• Perguntas cuja resposta depende de fatos que não estão no estado e não são conhecimento geral, e exames com muito conhecimento (veja Limitações).
• Aritmética de datas com precisão de dia sem o pré-processador KEV_DATE_FACTS=1, estados maiores que 65,536 tokens e idiomas diferentes do inglês.

Como usar

Sirva-o com o repositório do Kev. Em CUDA ele roda em bf16 com kernels DeltaNet fundidos e CUDA graphs (uma L40S, H100 ou qualquer GPU com cerca de 16 GB livres); no Apple Silicon o mesmo comando o serve através do MLX, escolhido automaticamente.

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)

A temperatura calibrada é aplicada por padrão; KEV_TEMPERATURE=1.0 devolve as probabilidades brutas. KEV_DTYPE=fp32 seleciona o caminho exato usado na avaliação. KEV_DATE_FACTS=1 anexa o número de dias entre cada par de datas encontrado no estado, que o modelo foi treinado para usar. Um estado acima de 65,536 tokens é recusado com um 422 que informa a sua contagem de tokens.

Dados de treinamento

Cada estágio de ajuste fino depois do primeiro repete registros do decision-v7 (2,000, 2,000 e 4,000). Nenhuma saída de Jev (o modelo de decisão hospedado da TypeSafe) foi usada. CodeReviewer e FlakeFlagger vêm do Zenodo; as narrativas do CFPB são obras do governo dos EUA; licenças e revisões por fonte são registradas nos manifestos das suítes. As suítes apenas de avaliação abaixo (breadth-v1, tasksource-heldout-v1, transfer-v4, longdoc-v1, e as fontes When2Call e de injeção de prompt do devtools-v1) nunca entram no treinamento.

Procedimento de treinamento

1. Receita base. Duas épocas no decision-v7 a partir da base: LoRA rank 16, α 32; taxa de aprendizado 5e-5, agenda one-cycle; lote efetivo 8 (4 × 2 de acúmulo); autocast bf16, gradient checkpointing; semente 2. A perda é entropia cruzada sobre as opções de cada pergunta. A ordem das opções é embaralhada, opções “nenhuma das opções acima” e distratores são inseridos aleatoriamente, e um quarto dos registros de choice também gera um par mínimo (a pergunta com uma opção “nenhuma das opções acima”, uma vez com a opção correta presente e uma vez com ela removida).
2. Datas e evidência ausente. Uma época a partir do estágio 1 com taxa de aprendizado 2e-5 e 2,000 registros repetidos.
3. Documentos reais. Uma época a partir do estágio 2 no documents-v1 train, com taxa de aprendizado 2e-5 e 2,000 registros repetidos; lote 2 × 4 de acúmulo; estados de no máximo 7,552 tokens.
4. Habilidades. Uma época a partir do estágio 3 no hard-v1 e no devtools-v1 train juntos, com taxa de aprendizado 2e-5 e 4,000 registros repetidos; lote 2 × 4 de acúmulo; estados de no máximo 7,552 tokens; semente 1; 1,915 passos do otimizador.
5. Calibração. Uma única temperatura, T = 2.41, minimizando a log-verossimilhança negativa nas linhas de desenvolvimento do decision-v7 do trial do estágio 4 (1,264 perguntas). Estes são itens reservados de um corpus de treinamento. Um reajuste em conjuntos de dados reservados foi avaliado e não adotado (veja Calibração).

Avaliação

Metodologia. Todo número é o caminho de avaliação em fp32 na temperatura de entrega, salvo indicação em contrário. Partições de desenvolvimento foram usadas para seleção; partições de teste foram lidas uma vez para este checkpoint; o teste do transfer-v4 é bloqueado (lido uma vez por candidato) e foi julgado contra uma régua fixada de antemão. Os intervalos pareados são bootstraps de 95% que reamostram registros inteiros (2,000 reamostragens), então perguntas que compartilham um estado se movem juntas. As diferenças estão em pontos percentuais (pp). O Jev (o modelo hospedado da TypeSafe, consultado pelo Vercel AI Gateway) é mostrado onde ele foi lido nos mesmos itens. As suítes:

• breadth-v1: 14 conjuntos de dados públicos reservados em cinco áreas (conhecimento, linguagem, recuperação, ferramentas, artes), nunca treinados.
• tasksource-heldout-v1: 24 famílias de tarefa inteiras de uma coleção pública multitarefa, nunca treinadas (nomes das famílias privados).
• transfer-v4: decisões fora do domínio de seis fontes públicas nunca treinadas (QNLI, SciQ, TweetEval-offensive, PAWS, MMLU, Emotion) mais políticas e estruturas de regra reservadas.
• hard-v1: as famílias de habilidade acima; a partição de teste reserva templates de geradores treinados.
• devtools-v1: decisões de ferramentas de desenvolvimento de seis fontes com licença verificada (quatro treinadas, duas apenas de avaliação).
• documents-v1 / documents-v2: narrativas de reclamação do CFPB; a v2 é um conjunto de teste reservado privado.
• longdoc-v1: contratos comerciais CUAD e pacotes de acordo gerados, com estados de 4k a 64k tokens.

Os painéis principais marcados como “audited” excluem itens que uma auditoria de rótulos considerou insólidos¹; cada exclusão remove as mesmas linhas dos dois lados de uma comparação.

Dados reservados (nunca treinados).

Famílias treinadas (itens e templates reservados).

O número do Jev para devtools-v1 cobre todas as 1,074 perguntas de desenvolvimento; as linhas do Kev descartam um id do CodeReviewer que o construtor da suíte reutilizou para dois registros (2 perguntas).

Contra a versão anterior (o checkpoint do estágio de documentos, tag r8-documents-release, na própria temperatura 2.96; critérios registrados, cada teste lido uma vez):

Documentos longos.

• Comprimento de contexto validado: 8,192 tokens, o comprimento treinado. O bucket de 16k está fora da tolerância: seu limite inferior é −3.4 pp, abaixo de −3 pp, então nenhum comprimento maior é validado.
• Regra, fixada antes da leitura: o comprimento validado é o tamanho nominal do maior bucket a partir de 16,384 tokens tal que ele, e todo bucket entre ele e 8,192, esteja dentro da tolerância. “Dentro da tolerância” significa que a diferença de acurácia CUAD em relação ao bucket de 8k (estados de 6,553–7,618 tokens, o comprimento treinado), pareada no mesmo contrato, repetição e pergunta, tem um limite inferior de 95% de pelo menos −3 pp, e todo registro foi respondido. Se o bucket de 16k falha, o comprimento validado é 8,192 tokens.

Acurácia CUAD, ECE e a diferença pareada em relação ao bucket de 8k por comprimento nominal do estado (longdoc-v1 development):

ECE na T de entrega = 2.41. Δ é pareado nas 445–447 perguntas feitas sobre os mesmos contratos nos dois comprimentos. O bucket de 4k contém contratos diferentes e não é uma referência para a regra. Fonte: runs/r28-readout/context.json (o read-out registrado da rodada 28, runs/r28-4b-r10-longdoc).

Calibração (erro de calibração esperado, ECE, na T de entrega = 2.41; menor é melhor):

A temperatura de entrega foi ajustada em itens reservados de um corpus de treinamento, o que as regras do projeto não permitem mais para um novo release. Um reajuste registrado em 648 perguntas de conjuntos de dados reservados (a partição de calibração do transfer-r3, oito fontes, e 200 perguntas de MMLU-Pro) dá T = 2.30 (intervalo bootstrap de 90% [2.05, 2.52]). Nas 4,468 perguntas de desenvolvimento auditadas do breadth-v1 e do tasksource-heldout-v1 ele não melhora o valor de entrega: Brier 0.368 nos dois, uma diferença de −0.0001 [−0.0005, +0.0003], e ECE 0.025 contra 0.024. A regra exigia um intervalo de Brier abaixo de zero e um ECE menor, então T = 2.41 permanece. As respostas não dependem de T.

Outros resultados.

Serviço. CUDA, bf16 com kernels fundidos e CUDA graphs; tempo de modelo por requisição (mediana de 20) para um estado novo / repetido:

A memória residente da GPU é 14.3 GB. As probabilidades servidas ficam dentro de 0.017 do caminho de avaliação em fp32 em 280 perguntas, sem respostas alteradas. No caminho de avaliação em fp32 (H100), estados de 16k / 32k / 64k tokens levam 3.0 / 6.8 / 17.2 s e 4.3 / 8.6 / 17.2 GiB acima dos pesos.

Apple Silicon (MLX, bf16, M5 com 32 GB; três perguntas, uma sobre um fato plantado a 60% de profundidade; o estado é preenchido em blocos de 1,024 tokens):

Em 60 perguntas de estado curto, o caminho MLX fica dentro de 0.018 do caminho de avaliação em fp32, sem respostas alteradas.

¹ Excluídos dos painéis auditados: quatro conjuntos do breadth-v1 (routerbench, cujos estados não contêm a informação pedida; cfcolor e humicroedit, no nível do acaso para todo sistema; chessbench, no piso para todo sistema); sete famílias do tasksource-heldout-v1 com rótulos inválidos ou irrecuperáveis (nomes privados); duas tarefas do devtools-v1 cujos rótulos o estado não determina (flakeflagger, tipo de mudança do commit).

² O índice corrigido pelo acaso do Decision Index 0.2 da comunidade: por conjunto de dados, (score − acaso) / (1 − acaso), com média dentro de cada área, depois 100 × a média das cinco áreas. O índice do Jev vem de uma leitura separada dos mesmos itens de teste.

Limitações e trade-offs

• Seus maiores ganhos estão dentro da distribuição. As partições de treinamento do hard-v1, do devtools-v1 e do documents-v1 estão nos seus dados de treinamento, e um item de teste do hard-v1 é um template novo de um gerador treinado. Em conjuntos de dados reservados ele fica 16 pontos atrás do Jev no índice do breadth-v1, e no nível difícil público do JevBench, uma checagem fora da distribuição, o estágio de habilidades ganhou cerca de um terço do que ganhou no hard-v1 (+9.0 pp [+2.7, +15.3] em 111 itens).
• Alguns rótulos do devtools-v1 são proxies. Antes do treinamento, todo modelo pontuado, incluindo o Jev, ficava perto do acaso no CodeReviewer e no FlakeFlagger; depois de treinar nessas fontes ele chega a 0.633 e 0.693 no desenvolvimento, o que pode ser a heurística de rotulagem sendo aprendida em vez da decisão.
• O conhecimento é definido pela base. O MMLU-Pro é 0.565 contra 0.840 do Jev.
• A aritmética de datas é a sua família mais fraca: 0.65 nas perguntas da política deadline contra 0.95 do Jev. O pré-processador KEV_DATE_FACTS=1 ajuda (no checkpoint anterior do qual este descende, 0.60 → 0.85); ele não foi re-medido neste checkpoint.
• A calibração é uma única temperatura dentro da distribuição. Ele é bem calibrado em conjuntos de dados reservados (breadth-v1 test ECE 0.029), menos nas famílias treinadas de habilidade e documento (ECE 0.084–0.101), e uma única temperatura não consegue reordenar confianças: a cobertura com ≤ 5% de erro fora do domínio é 0.620 no desenvolvimento contra 0.70 do Jev.
• Comprimentos não treinados. Os estados de treinamento tinham no máximo 7,552 tokens. Estados mais longos são servidos até 65,536 tokens; até onde a acurácia se mantém é o comprimento de contexto validado acima.
• A ordem das opções pode mudar uma resposta; o isolamento de pergunta não impede isso.

Viés, riscos e considerações éticas

• Probabilidades calibradas podem criar uma confiança infundada. A temperatura foi ajustada em linhas de desenvolvimento da distribuição de treinamento e não transfere para toda carga de trabalho; meça a acurácia e a calibração em uma amostra rotulada dos seus próprios dados, e reajuste a temperatura ali (python -m kev.calibrate), antes de definir limiares.
• A acurácia e a calibração mudam sob mudança de domínio. Monitore as taxas de erro em produção em vez de confiar nos números acima.
• Não o use para decisões automatizadas consequentes sobre pessoas sem revisão humana. Os vieses do modelo base e dos dados de treinamento (incluindo rótulos produzidos por outros modelos) não são medidos.
• Os estados podem conter dados pessoais ou confidenciais. A auto-hospedagem mantém as entradas no seu próprio hardware; o servidor é aberto a menos que KEV_API_KEY esteja definida, então aplique o seu próprio controle de acesso e política de tratamento de dados.

Computação

• Receita base: cerca de 56 minutos em uma NVIDIA H100 (pico 24.6 GB). Estágio de datas: 9 minutos em uma H100.
• Estágio de documentos: 43 minutos em uma NVIDIA H200. Estágio de habilidades: 1.4 horas em uma H200 (pico 47.7 GB).
• Avaliação e checagens de serviço: GPUs únicas H100 / H200 / L40S no Modal; medições MLX em um Apple M5.

Procedência e reprodutibilidade

• Código, suítes e relatórios de avaliação: github.com/jaredpalmer/kev. Números do release: runs/release/kev-4b-r10.json (scripts/release_numbers.py --release kev-4b-r10), a leitura bloqueada runs/locked/kev-4b-r10-ungated/, as leituras da família de 2026-09-30 runs/fam-4b-breadth/, runs/fam-4b-breadthtest/, runs/fam-4b-docs1test/ e runs/fam-breadth-test-report/, o reajuste de calibração runs/r28-readout/round28.json, serviço runs/serve-4b-l40s/, runs/grouping-4b-h100/, runs/long-state-4b-h100/, runs/mlx-long-states/, runs/mlx-full-4b/.
• Estágios: trial da base q35-4b-s23/00-trial-0 (tag v7-base); datas night2-4b-du/00-trial-0 (tag night2-du-release); documentos rodada 8 r8-small/00-trial-0 (tag r8-documents-release); habilidades rodada 10 r10-skills/00-trial-0 (experiments/round10/skills.json, regra experiments/rounds/r10.json). Reajuste de calibração: braço 4b-r10 da rodada 28 (experiments/rounds/r28.json).
• Pesos publicados: revisão do Hub 139fdd94; sha256 do adaptador 90e81735…, sha256 do head.pt dd633435… (T = 2.4061).
• Histórico de release: publicado em 2026-09-24 como o candidato confirmado da rodada 10; incluído sem alterações no Kev 1.0. O registro de como ele foi selecionado, incluindo suítes desde então aposentadas por insólidas (scienthoon, WANLI-v2, TypeSafe), é o README na revisão 139fdd94 do Hub e o PLAN.md na tag git research-archive-2026-09-24.

Citação

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

Contato

Perguntas e problemas: github.com/jaredpalmer/kev/issues.