Wikiracing com o Jev: o que a demo de navegação ensina sobre escolher entre opções?

Você está na página da Wikipédia sobre baseball e precisa chegar na página sobre o sol

Sem barra de busca, sem URL na mão, sem chutar

Só os links que aparecem no caminho, um clique de cada vez

Essa é a demo de Wikiracing que a TypeSafe AI colocou no post de lançamento do Jev, em 15/09/2026. Parece brincadeira de fim de semana, e é. Mas ela é uma vitrine muito boa de uma coisa que teu sistema já faz umas cinquenta vezes por dia sem você chamar assim: escolher a melhor alternativa dentro de uma lista fechada de opções

Cada passo do jogo pode envolver escolher entre centenas a milhares de links

Roteamento de chamado é isso, seleção de ferramenta é isso, ranquear resultado é isso… e é justamente aí que o post fica interessante pra quem escreve software =)

O que é o Jev e por que a TypeSafe escolheu o Wikiracing como demo

Primeiro o contexto, porque sem ele o resto não faz sentido

A TypeSafe AI saiu de anos de stealth com esse lançamento. Segundo o TechCrunch, a empresa foi criada por Diogo Almeida, que passou pela OpenAI trabalhando com RLHF e InstructGPT, e levantou uma rodada de US$ 40 milhões liderada pela DCVC

O Jev é o primeiro modelo System One deles, o primeiro modelo público da casa, e está em early access com acesso liberado por waitlist

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O que muda na saída

Aqui é o pulo do gato

Um LLM devolve texto e você reza pro parser aguentar

O Jev devolve decisão tipada com probabilidade calibrada. Você manda um estado e faz perguntas sobre ele, e cada pergunta é avaliada de forma independente e em paralelo contra o mesmo estado

Se você conhece a sensação de pedir JSON pro modelo e receber JSON quase válido, é mais ou menos o oposto disso: o formato da resposta não é uma promessa do prompt, é o tipo da pergunta

Por que Wikiracing e não outra coisa

Porque o jogo tem as três propriedades que uma vitrine precisa ter

• Decisão repetida: não é uma escolha, são dezenas em sequência
• Lista fechada por passo: os links daquela página, nem mais nem menos
• Resultado verificável: ou chegou no sun, ou não chegou

Não dá pra maquiar. Ou o loop converge, ou ele fica girando em círculo entre página de esporte e página de cidade americana

O mesmo post traz a demo de Doom, onde o engenheiro rodava cerca de 10 consultas por segundo com custo estimado em torno de US$ 7 por hora. São dois regimes bem diferentes de decisão: Doom mostra decisão contínua em tempo real, Wikiracing mostra decisão discreta com lista grande

E tem o claim da casa: a TypeSafe afirma que o Jev atinge nível de inteligência similar ao de LLMs em tarefas System One sendo duas ordens de grandeza mais rápido e eficiente

Vale a ressalva: isso é afirmação do fornecedor, não medição independente

O que você precisa para reproduzir o padrão de escolha

Lista curta e honesta, sem enrolação

1. Acesso ao early access, que hoje é por waitlist
2. A chave na variável de ambiente TYPESAFE_API_KEY, que é de onde o cliente lê
3. O SDK Python, que expõe TypeSafeClient e as perguntas Choice, Score e Noul
4. Um modelo: o padrão é jev-latest

Sobre versão: a documentação lista jev-1.13, e os aliases jev-latest e jev-preview apontam pro mesmo modelo. IDs versionados como jev-1.13.0 também são aceitos no campo do modelo

Explicando o orçamento de contexto:

Esse é o número que mais gente esquece antes de montar o loop

São 64k pro estado somado a todas as perguntas

E um limite separado de 32k pro estado somado à pergunta mais longa

Repara que são duas contas diferentes. Dá pra passar folgado na primeira e estourar na segunda se uma pergunta sozinha ficar gorda demais. Tome cuidado com isso quando a lista de opções crescer

Como funciona o loop de escolha, passo a passo

A anatomia é sempre a mesma, muda só o que você chama de opção

1. Monta o estado

No Wikiracing o estado é curtinho: qual é a página atual e qual é o destino. Nada de despejar o artigo inteiro ali

O erro comum deste passo: inchar o estado com contexto que não muda a decisão. Lembra dos 32k por pergunta mais longa

2. Coleta as opções daquele passo

Os links da página atual. É a lista finita do momento

O erro comum deste passo: coletar link que não leva a lugar nenhum (âncora interna, rodapé, navegação) e poluir o conjunto

3. Envia um Choice com a lista completa

Um Choice aceita até 255 opções, e a documentação recomenda mandar a lista completa em vez de um recorte, já que cada opção custa poucos tokens

O erro comum deste passo: filtrar antes da hora. Você faz um pré-corte heurístico "pra ajudar" e corta justamente o link que era o atalho pro destino

4. Lê a resposta

O retorno de um Choice traz três coisas: a opção selecionada, uma probabilidade para cada opção e um valor de confiança

É aqui que você decide se segue direto, se confirma, ou se para

O erro comum deste passo: usar só a opção escolhida e jogar fora a confiança. Aí você transformou um modelo calibrado num chute com cara de certeza

5. Repete até chegar no destino

Nova página, nova lista de links, novo Choice

O erro comum deste passo: não guardar histórico de páginas visitadas e ficar em loop entre duas páginas irmãs

O esqueleto em Python fica mais ou menos assim (o formato exato da chamada está no quickstart da TypeSafe):

from typesafe import TypeSafeClient, Choice

# o cliente lê a chave de TYPESAFE_API_KEY e usa jev-latest por padrão
client = TypeSafeClient()

pagina_atual = "baseball"
destino = "sun"
visitadas = {pagina_atual}

while pagina_atual != destino:
    links = coletar_links(pagina_atual)
    opcoes = limitar(filtrar_nao_visitados(links, visitadas), 255)

    estado = f"Página atual: {pagina_atual}\nDestino: {destino}"
    pergunta = Choice(options=opcoes)

    # a resposta traz: opção escolhida, probabilidade por opção e confiança
    resultado = perguntar(client, estado, pergunta)

    if resultado.confidence < LIMIAR:
        parar_ou_escalar(resultado)
        break

    pagina_atual = resultado.choice
    visitadas.add(pagina_atual)

Repara que o loop inteiro cabe numa tela

A inteligência não está na arquitetura do código, está no formato da pergunta

Choice, Score e Noul: qual pergunta usar em cada situação

A TypeSafe expõe três primitivas de pergunta, e escolher a errada é o jeito mais rápido de achar que o modelo é ruim

O Wikiracing é Choice puro. Uma pergunta, uma lista, uma escolha, repete

Mas na vida real as três costumam andar juntas: um Noul pra decidir se vale agir, um Score pra graduar, um Choice pra escolher o destino

Quando a lista não cabe: limites e contornos do padrão

Agora a parte que ninguém coloca no post de lançamento

Sintoma: sua lista tem mais de 255 opções

Causa: o limite de cardinalidade de um Choice é 255 opções, e uma página grande da Wikipédia passa disso com folga

Solução: existem dois caminhos documentados

A TypeSafe descreve um fluxo de 2 estágios pra cardinalidade acima do limite: pontuar as opções de forma independente e depois fazer uma escolha explícita. Funciona, com a ressalva de que pode ficar mais lento

O Sean Goedecke, que reimplementou a demo, descreve outro caminho que ele chama de tournament sampling: manda cem links por vez em cada escolha e depois faz uma segunda passada com as vencedoras. É chave de torneio mesmo

Como prevenir: saiba a cardinalidade máxima do seu domínio ANTES de escrever o loop. Se 255 não cobre, já nasce com o fluxo de dois estágios

Sintoma: o modelo escolhe mal e você não entende por quê

Causa: pode ser como as opções estão identificadas

Solução: o Goedecke relata que usar labels (um token associado a cada opção) funcionou bem melhor que índices no Wikiracing

E aqui está a parte honesta do relato dele: no Doom, não. A mesma técnica que ajudou num caso não ajudou no outro

Como prevenir: não trate representação de opção como detalhe. Teste as duas formas no seu problema em vez de copiar a receita de outro domínio

Sintoma: erro de contexto quando a lista cresce

Causa: você tem 64k pro estado somado a todas as perguntas, e 32k pro estado somado à pergunta mais longa

Quando a lista de opções entra dentro de uma pergunta só, é essa segunda conta que aperta

Solução: enxuga o estado primeiro. Pergunta pra si mesmo o que naquele texto realmente muda a decisão

Como prevenir: meça o tamanho do par estado + maior pergunta em produção, não no exemplo de brinquedo

Sintoma: confiança baixa e o sistema agindo assim mesmo

Causa: você tratou o retorno como resposta final e ignorou a calibragem

Solução: a documentação de confiança recomenda três faixas

• Confiança alta: age sozinha
• Confiança média: pede confirmação ou revisão
• Confiança baixa: vai pra humano, pra clarificação ou pra outro sistema

E a própria documentação avisa que o limiar não é um número único: ele depende das consequências de errar e precisa ser testado com dados seus

Como prevenir: define as faixas antes de ligar em produção, não depois do primeiro incidente 🙂

Onde esse mesmo padrão aparece fora do jogo

Ok, mas ninguém vai pagar você pra jogar Wikiracing

Então vamos aos três lugares onde a mesma forma de decisão aparece, todos ancorados em material da própria TypeSafe

Roteamento de chamados

Um chamado chega, e existe uma lista finita de filas possíveis

É Choice com as faixas de confiança em cima. A TypeSafe documenta isso como um padrão próprio, o confidence-gated routing: o roteamento acontece condicionado ao nível de confiança da decisão

Na prática: alta manda direto pra fila, média manda com revisão, baixa vai pro humano triar

Seleção de ferramenta ou skill

Esse é o caso mais próximo de quem monta agente

O cookbook de sugestão de skill escolhe no máximo uma skill por turno do agente dentro do catálogo Hermes da Nous Research, que tem 182 skills

E o desenho são duas requisições: a primeira ranqueia todas e pergunta se alguma é necessária, a segunda lê as três melhores e pode rejeitar todas

Repara no detalhe que mais importa: existe a saída "nenhuma serve". Agente que sempre escolhe uma ferramenta é agente que vai usar ferramenta errada quando nenhuma cabia

Ranqueamento e re-ranking

O cookbook de re-ranking usa uma pergunta por par consulta/candidato sobre shortlists de 30 passagens geradas por BM25, em 40 consultas do CLERC

Os resultados reportados: top-1 sobe de 5% para 18%, e top-10 sobe de 38% para 62%

Deixo registrado que esses números são dos materiais da TypeSafe, não de avaliação independente

Vale usar esse padrão hoje? Leitura honesta

Vamos separar o que a demo prova do que ela não prova

O que ela prova de fato: o formato da decisão funciona. Você troca "gerar texto e torcer" por "opção escolhida, probabilidade por opção e confiança", e isso é auditável de um jeito que string não é

E tem a conta: o Jev é cobrado apenas por token de entrada, a US$ 0,042 por 1 milhão de tokens, com saída em US$ 0,00. Isso muda a matemática de quem precisa chamar o modelo em loop, várias vezes pela mesma tarefa

O que ela não prova:

• O claim de duas ordens de grandeza é afirmação do fornecedor
• O acesso é early access por waitlist, então planejamento de produção tem uma variável a mais
• O limite de 255 opções por Choice é real e obriga contorno em domínio de cardinalidade alta
• O resultado depende de calibragem de limiar que só você consegue fazer, com seus dados

E tem um contraponto que eu acho o mais saudável da história toda

O Sean Goedecke montou a própria camada System One em cerca de 150 linhas de Python sobre um LLM com acesso a logits e prefill, não sobre o SDK da TypeSafe. Ele descreve as duas técnicas dele nesse post sobre modelos System One

Ou seja: o padrão não depende de um fornecedor único

Isso é ótimo pra você, porque significa que o aprendizado aqui não vira lixo se o produto mudar de rumo. O que você aprende é a MODELAR a decisão, e isso é portável

Conclusão

O Wikiracing com o Jev é uma demo divertida com uma lição chata (no bom sentido) embaixo

Quando você consegue reescrever um problema como "escolher uma opção de uma lista finita", ele fica barato, verificável e auditável

Barato porque a cobrança é por entrada e a decisão é curta

Verificável porque tem resposta certa ou errada, não parágrafo bonito

Auditável porque volta probabilidade e confiança, não só o veredito

Próximo passo prático, se quiser sair do papo e ir pro código: pega UMA decisão repetida do teu sistema, aquela que hoje é um if gigante ou um prompt pedindo JSON, escreve ela como Choice com a lista completa de opções, e define as três faixas de confiança antes de ligar qualquer coisa em produção

Essa ordem importa. Primeiro as faixas, depois o deploy 😀

Até o próximo post!