Como corrigir respostas abertas de um quiz usando o Jev?

Corrigir resposta aberta em escala é o ponto onde quase todo projeto de quiz trava

A pergunta de múltipla escolha você corrige com um if, a dissertativa você corrige lendo, uma por uma, e a fila não anda

O que muda quando o julgamento deixa de ser um parágrafo bonito e passa a ser uma nota tipada? Você ganha um número dentro de uma escala que VOCÊ definiu antes, com a probabilidade de cada nível e um indicador de confiança. Aí dá pra automatizar o que é claro e mandar o duvidoso pro professor

É exatamente aí que entra o Jev, o primeiro modelo público da classe System One da TypeSafe AI, anunciado em 15 de setembro de 2026. Ele não escreve texto livre: recebe um state mais perguntas tipadas e devolve resposta estruturada com distribuição de probabilidade e confiança

Se você conhece validação de schema (tipo Zod ou Pydantic), a analogia é boa: o Jev é um julgador que só fala no formato que você declarou

Bora montar o corretor?

O que você precisa antes de começar

A lista é curta, e a boa notícia é que não tem fila de espera: o acesso ao Jev está aberto ao público, qualquer pessoa cria a chave em console.typesafe.ai

• Chave de API criada no console, exposta na variável de ambiente TYPESAFE_API_KEY (o cliente lê ela sozinho)
• SDK Python: pip install typesafe-sdk, com Python 3.10 ou superior
• ou SDK JavaScript: npm install @typesafe-ai/sdk, chamando client.systemOne({...})
• ou HTTP na mão: um POST para https://api.typesafe.ai/v1/systemone

O modelo padrão do cliente é o jev-latest, o alias que aponta sempre pra versão atual do Jev

Sobre custo: o Jev está listado a US$ 0,042 por milhão de tokens de input e US$ 0,00 de output. Faz sentido, já que não tem geração de string livre pra cobrar na saída

A TypeSafe afirma que o Jev atinge um nível de inteligência comparável ao de LLMs em tarefas System One sendo cerca de duas ordens de grandeza mais rápido e mais eficiente. É claim da própria empresa, então trate como o que é: um argumento pra você testar no seu lote, não um número de benchmark independente

Passo a passo: montando o corretor automático

1. Instale o SDK e configure a chave

pip install typesafe-sdk
export TYPESAFE_API_KEY="sua-chave-do-console"

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()  # usa TYPESAFE_API_KEY e jev-latest

O erro comum deste passo: deixar a chave hardcoded no arquivo que vai pro Git. O cliente lê TYPESAFE_API_KEY do ambiente justamente pra você não precisar fazer isso

2. Monte o state com enunciado, gabarito e resposta do aluno

O state é o contexto que o Jev lê pra julgar. Correção sem gabarito é chute, então os três pedaços entram juntos

enunciado = "Explique a diferença entre autenticação e autorização"

gabarito = ("Autenticação verifica QUEM é o usuário (identidade). "
            "Autorização define O QUE esse usuário pode fazer (permissões). "
            "Autenticação vem antes; autorização depende dela")

resposta_aluno = ("Autenticação é quando o sistema confere o login e a senha "
                  "pra saber se é você mesmo. Autorização é o que você pode "
                  "acessar depois disso")

state = f\"\"\"ENUNCIADO DA QUESTÃO:
{enunciado}

GABARITO (resposta esperada):
{gabarito}

RESPOSTA DO ALUNO:
{resposta_aluno}\"\"\"

O erro comum deste passo: mandar só a resposta do aluno e esperar que o modelo adivinhe o critério da sua prova. State incompleto é a causa número um de nota instável, do mesmo jeito que acontece com respostas fracas por contexto ruim em ferramentas de pesquisa

3. Desenhe a escala de nota com Score

O System One tem três primitivos de pergunta: Noul (probabilidade de sim/não), Choice (uma opção de um conjunto) e Score (posição numa escala). Correção de dissertativa é Score

O Score recebe um array ordenado de descrições de nível no campo criteria, do nível mais baixo para o mais alto

nota_conteudo = Score(criteria=[
    "Resposta em branco, fora do tema ou totalmente incorreta",
    "Cita os dois termos mas troca os significados ou erra a definicao central",
    "Define corretamente apenas um dos dois conceitos",
    "Define corretamente os dois conceitos, sem explicar a relacao entre eles",
    "Define os dois conceitos e explica que autorizacao depende da autenticacao",
])

O erro comum deste passo: inverter a ordem do criteria, colocando o melhor nível primeiro. A escala é lida de baixo pra cima, então a inversão entrega nota alta pra resposta ruim e você só descobre depois de lançar o boletim 😅

4. Faça a chamada

resultado = client.system_one(
    state=state,
    questions={"nota_conteudo": nota_conteudo},
)

O erro comum deste passo: esperar um parágrafo de volta. O Jev não gera texto livre, ponto. Se o seu código tenta ler uma string de explicação, ele vai quebrar

5. Leia score, probabilities e confidence

A resposta de um Score traz três coisas: o campo score (a média ponderada pelas probabilidades dos números dos níveis, ou seja, pode cair entre dois níveis), probabilities com a probabilidade de cada nível e confidence

É isso que você grava no banco: a nota, a distribuição e a confiança. Os três, não só a nota

O erro comum deste passo: abrir bug porque o score veio fracionário. Não é bug, é feature: valor entre dois níveis significa que o modelo está dividido entre eles, e essa é justamente a informação que decide se a nota entra automática ou passa pelo professor antes

6. Avalie vários critérios na mesma chamada

O Jev avalia várias perguntas independentes numa única requisição, em paralelo. Então rubrica com três dimensões não é três chamadas

resultado = client.system_one(
    state=state,
    questions={
        "nota_conteudo": nota_conteudo,
        "nota_clareza": Score(criteria=[
            "Texto confuso, sem estrutura, dificil de entender",
            "Ideia compreensivel mas mal organizada",
            "Texto claro e direto",
        ]),
    },
)

O erro comum deste passo: enfiar dois julgamentos diferentes dentro do mesmo Score ("conteúdo correto E bem escrito"). Critério misturado achata a distribuição, porque o modelo não sabe qual dos dois pesar. Uma pergunta, um julgamento

Como definir a escala de notas com Score e criteria

A rubrica é onde o projeto se decide. O modelo não inventa o seu critério, ele posiciona a resposta dentro do critério que você escreveu

Regras de tamanho: a escala precisa de pelo menos 2 níveis, e a API aceita até 10

E por que isso importa na prática? Porque escala gigante com descrição vaga vira loteria. Se os níveis 6 e 7 se diferenciam por "um pouco melhor", o modelo não tem onde se apoiar, a probabilidade se espalha entre eles e a confiança cai

Descrição vaga achata a distribuição

Descrição observável concentra a distribuição

A diferença é escrever o que dá pra VER na resposta do aluno, não um adjetivo:

Exemplo de escala de 5 níveis pra dissertativa, no formato que costuma funcionar melhor: nível 1 pro caso degenerado (branco, fora do tema), nível 2 pro erro conceitual, nível 3 pra resposta parcial, nível 4 pra resposta completa e nível 5 pra resposta completa com a relação entre os conceitos explicada

E aquele score fracionário que assusta no começo? Ele é a média ponderada pelas probabilidades dos números dos níveis. Um 3.5 quer dizer "está entre o parcial e o completo", que é o tipo de resposta que qualquer professor também leria duas vezes. Mais detalhe do primitivo está na documentação do Score

Quando mandar a correção para um humano

Aqui entra o confidence. Respostas de Choice e Score carregam confiança entre 0 e 1, derivada do formato da distribuição de probabilidade: distribuição concentrada num nível dá confiança alta, distribuição espalhada dá confiança baixa

A documentação recomenda o padrão de roteamento por confiança em três faixas:

O limiar de cada faixa não vem de fábrica: ele depende do risco da ação. Quiz de treino, onde errar a nota custa pouco, aceita limiar frouxo. Prova valendo nota final, onde errar custa recurso e conversa com a coordenação, pede limiar apertado e faixa média larga

Sintoma: você soltou o corretor e chegaram reclamações de nota injusta

Causa provável: o limiar foi definido por chute, então respostas que o modelo julgou em cima do muro entraram como nota definitiva

Solução: roteamento em três faixas de verdade, com fila de confirmação do professor pra faixa média e nada de nota automática na faixa baixa

Como prevenir: calibre antes. Pegue um lote que já foi corrigido à mão, rode o corretor nele e compare. Você vai ver em qual valor de confiança o modelo começa a divergir do professor, e é aí que o seu limiar mora. O padrão completo está descrito no guia de confidence routing

Separando o julgamento do feedback escrito

Essa separação é o pulo do gato do projeto, e ela não é opcional: o Jev não gera texto livre, então ele não pode ser a fonte do feedback

A arquitetura fica em duas camadas:

1. Camada de julgamento (Jev). Decide a nota com Score, o tipo de erro com Choice e os critérios objetivos com Noul. Saída tipada, com probabilidade e confiança
2. Camada de texto. Recebe a nota JÁ DECIDIDA e só verbaliza: template por faixa de nota, ou um LLM que lê o resultado estruturado como entrada e escreve o comentário pro aluno

Por que isso é melhor que pedir nota e comentário pro mesmo modelo de texto? Porque quando um LLM escreve os dois juntos, ele às vezes escreve um elogio e crava nota baixa, ou aponta três erros e dá nota máxima

Nota e feedback se contradizendo na frente do aluno é o pior bug possível nesse tipo de produto

Com as camadas separadas, o texto é DERIVADO da nota, então contradição não tem por onde entrar. E tem um bônus: template por faixa é determinístico, versionável e revisável pela coordenação antes de ir pro ar

Outros usos dessa mesma estrutura em quizzes e formulários

O padrão é sempre o mesmo (state + perguntas tipadas), só muda o primitivo:

• Triagem de formulário de inscrição: Score pra aderência do candidato ao perfil descrito, e a faixa de confiança decide quem vai pra leitura humana
• Checagem de critério objetivo: Noul pra perguntas de sim/não do tipo "o aluno citou a fonte?", "a resposta menciona o prazo?". É o primitivo mais barato de auditar, porque a resposta é binária
• Classificação do tipo de erro: Choice entre opções como erro conceitual, erro de cálculo, resposta incompleta, fora do tema. Isso alimenta relatório de turma, não só a nota individual
• Pré-triagem de redação: o Jev separa o lote em blocos por nível antes da leitura humana, e o professor lê na ordem que quiser
• Avaliação de resposta de suporte: mesma rubrica, aplicada em atendimento em vez de prova, útil quando você já tem um fluxo pra automatizar respostas com n8n e quer medir a qualidade do que sai

Repare que em todos os casos a decisão continua tipada. É isso que permite gravar em coluna de banco, filtrar, somar e auditar depois

Como checar se a correção é estável

Antes de soltar em turma inteira, a pergunta certa é: se eu rodar de novo, dá a mesma coisa?

A documentação traz cookbooks de self-consistency: você roda as mesmas perguntas tipadas mais de uma vez sobre o mesmo state e observa se a resposta se mantém. Existem receitas com Noul e com Choice na seção de cookbooks

Sintoma: a mesma resposta do aluno recebe notas diferentes entre rodadas, ou a confiança vive baixa mesmo em resposta que pra você é obviamente boa

Causa provável: duas, quase sempre. criteria ambíguo, com níveis vizinhos que se diferenciam por adjetivo em vez de fato observável. Ou state incompleto, geralmente sem o gabarito, o que obriga o modelo a inventar o padrão de comparação

Solução: reescreva os níveis vizinhos que estão colando, transformando adjetivo em critério verificável, e garanta que enunciado e gabarito estão no state. Depois rode o self-consistency de novo no mesmo lote e compare

Pra rodar isso em lote grande sem ficar esperando requisição por requisição, o SDK Python também oferece cliente assíncrono (AsyncTypeSafeClient) além do TypeSafeClient síncrono. Turma inteira em paralelo resolve o tempo de espera

Tome cuidado com um detalhe: rodar várias vezes multiplica o consumo de input. Com output a US$ 0,00 a conta continua camarada, mas vale medir antes de transformar self-consistency em rotina de produção

Vídeo complementar

Pra começar do zero no assunto de economizar em ferramentas de IA, este vídeo do canal mostra o caminho:

Conclusão

O fluxo pra corrigir respostas abertas com o Jev cabe em três decisões, e nenhuma delas é sobre prompt mágico:

1. state tipado com enunciado, gabarito e resposta do aluno juntos
2. Escala definida ANTES, com criteria ordenado do nível baixo pro alto, entre 2 e 10 níveis, descrito em fato observável
3. Roteamento por confiança em três faixas, com o limiar puxado pelo risco da ação

O texto do feedback fica em outra camada, alimentada pela nota já decidida. Assim nota e comentário nunca se contradizem

Próximo passo bem concreto: cria a chave em console.typesafe.ai, escolhe UM quiz real que você já corrigiu à mão, escreve a rubrica dele e compara resultado por resultado com a sua correção. Só depois que a comparação fechar você automatiza o resto

Rubrica boa é a maior parte do trabalho, o modelo é o resto 🙂

até o próximo post!