Jev, o modelo que não escreve uma palavra: decisão tipada, confiança calibrada e o que medimos em 4 estudos

Um modelo que não escreve uma única palavra leu um contrato de 22 cláusulas, julgou cada uma delas em seis dimensões e devolveu tudo em 2,7 segundos, por US$ 0,0015. A mesma revisão, feita pelo Claude Opus 5, levou 298 segundos e US$ 1,21. Não é erro de digitação: cento e três vezes mais rápido, seiscentas e quarenta vezes mais barato.

Esse número é a parte fácil de contar e a menos interessante. O que interessa é a pergunta que vem depois dele: isso substitui o LLM ou soma com ele? A resposta curta é que a pergunta está mal feita, e vale muito a pena entender por quê, porque no meio dela mora uma conta que provavelmente está aberta no seu cartão de crédito agora: a quantidade de chamadas de IA que você faz em produção que nunca precisaram de um LLM.

Este post é o relato didático dos estudos que fizemos aqui na Steply com o Jev, o modelo System One da TypeSafe, dentro de uma série de quatro projetos de aprendizado que terminaram num revisor de contratos funcionando. Tem código, tem medição com data e ressalva, e tem a parte que raramente aparece em post de IA: o que deu errado e o que ainda não está bom.

Aviso que vale para o texto inteiro: o projeto é material de estudo, não é software jurídico. Ele não dá parecer, não conhece jurisprudência e não substitui advogado. O que vale é o que ele ensina sobre decisão tipada e confiança calibrada.

1. Sistema 1 e sistema 2, e por que sua fatura de IA é feita de sistema 1 pago a preço de sistema 2

Daniel Kahneman dividiu o pensamento humano em dois modos. O sistema 1 é rápido, automático e não usa palavras: você não delibera se a chaleira está quente, você tira a mão. O sistema 2 é lento, deliberado e verbal: é ele que escreve o relatório, monta o argumento, explica a decisão para o chefe.

Os dois não competem dentro da sua cabeça. Eles se revezam, e é o sistema 1 que decide, milhares de vezes por dia, quando vale a pena acordar o sistema 2.

O LLM que você usa hoje é sistema 2 puro. Ele pensa escrevendo. É excelente nisso, e é exatamente isso que você paga. O problema é que a maior parte do que você pede a ele em produção não é sistema 2 coisa nenhuma. É "esse ticket é de cobrança ou de suporte?", "esse texto tem dado pessoal?", "de 0 a 3, quão grave é isso?". São reflexos. E você está pagando um redator premiado para apertar um botão.

Um System One Model é uma classe de modelo feita para o outro lado dessa divisão: tomar decisões rápidas e estruturadas que o software consegue consumir direto, devolvendo respostas tipadas e probabilidades em vez de texto gerado.

2. O que muda no seu código: você para de mandar prompt e passa a mandar pergunta tipada

A diferença aparece em cinco linhas. De um lado, o que todo mundo faz hoje com um LLM:

# o jeito LLM
resposta = llm.chat("Classifique o ticket. Responda APENAS com JSON: ...")
dados = json.loads(limpar_crases(resposta))   # e reza

Do outro, o mesmo pedido num System One:

# o jeito System One
resposta = client.system_one(
    state={"document": "Fui cobrado duas vezes. Resolvam isso já."},
    questions={"categoria": Choice(
        instructions="Do que trata este ticket?",
        criteria={"cobranca": ..., "tecnico": ..., "outro": ...},
    )},
)
resposta.choices["categoria"].choice         # "cobranca"
resposta.choices["categoria"].confidence     # 0.93

Repare no que desapareceu: o responda apenas com JSON, o json.loads dentro do try, a limpeza de crase, o retry de quando o modelo resolveu explicar antes de responder, o temperature=0 que você colocou torcendo, e a categoria inventada que não estava na sua lista.

Nada disso sumiu porque alguém validou melhor. Sumiu porque não existe texto para dar errado. A resposta só pode ser um dos valores que você declarou.

No nosso projeto, isso apareceu como um erro que acontece antes de sair qualquer chamada. Tente declarar um campo de texto na saída e o programa nem chega na rede:

class Veredito(BaseModel):
    risco: str  # este campo é o erro

UserError: Output field 'risco' is not supported by this model. Use `bool`,
a `Literal` or `Enum` of two or more strings, a `float` bounded with `ge=0`
and `le=1`, a `list` of a `Literal` or `Enum`, a rubric of whole numbers
from 0 with a description per level in its schema, or a model of these.

Pedir prosa para esse modelo não gera resposta ruim. Gera erro de programação, na sua máquina, de graça, antes do deploy. Esse é o tipo de falha que a gente gosta: barata e cedo.

3. Por que é rápido, e não é "porque o modelo é menor"

Essa é a parte que explica todo o resto, e ela é mais simples do que parece.

Um LLM responde escrevendo. Mesmo quando a resposta final é "sim", ele produz essa resposta pedacinho por pedacinho: {, ", nu, la, ":, true, e assim por diante. Cada pedacinho é uma passada inteira pelo modelo, e a próxima só começa quando a anterior terminou. É fila indiana. Se o veredito tem 300 tokens entre raciocínio e JSON, são 300 passadas em sequência. (Se você quiser ver esse mecanismo por dentro, escrevemos sobre ele em como um LLM funciona por baixo dos panos.)

A consequência prática é contraintuitiva e vale guardar: a latência de um LLM cresce com o tamanho da resposta, não com a dificuldade da pergunta. Um "sim" bem fundamentado demora mais que um "sim" seco, e o fundamento você joga fora no json.loads da linha seguinte.

O Jev não escreve. O espaço de respostas foi fechado antes da chamada: você declarou que a resposta é true ou false, ou uma entre treze opções, ou um degrau de 0 a 3. Não há o que produzir em fila, há o que distribuir probabilidade sobre. A resposta sai inteira, de uma vez, e o tamanho dela não depende de quantas palavras a explicação teria.

E tem a segunda metade, que está escrita com todas as letras na documentação deles: as perguntas são avaliadas em paralelo e isoladas umas das outras, e acrescentar perguntas quase não muda o tempo de resposta. Seis decisões por cláusula custam o mesmo relógio que uma.

A arquitetura exata a TypeSafe não publica. O comportamento, sim, e comportamento se mede. Foi o que fizemos.

4. Por que é barato: são três razões empilhadas, e a terceira ninguém coloca na planilha

Primeira: saída não é cobrada. Abra qualquer tabela de preço de LLM e você vai ver a saída custando de três a cinco vezes a entrada. É o lado caro da fatura, e é justamente o lado que você joga fora quando só queria a categoria. O Jev não tem saída para cobrar. Ele até reporta tokens de saída, 4.829 na nossa rodada dos três contratos, e cobra zero por eles.

Segunda: a entrada é de outra ordem de grandeza. US$ 0,042 por milhão de tokens de entrada. Quarenta e dois dólares por bilhão de tokens.

Terceira: o custo não varia. Os tokens de entrada são os mesmos toda vez, então a mesma revisão custa o mesmo centavo na segunda e na sexta. Fatura de LLM oscila com o humor da resposta, com o tamanho do raciocínio, com o dia. Essa não oscila. Quem já tentou fazer previsão de custo de IA para um orçamento anual sabe o tamanho dessa diferença. (Falamos desse problema em o custo invisível dos tokens.)

Empurrando para uma escala que dói, mil contratos, com a mesma sequência de chamadas que medimos:

Mil contratos	Claude Opus 5	Jev
tempo	cerca de 88,6 horas	cerca de 51 minutos
custo	US$ 1.308	US$ 2,04

O ponto aqui não é o desconto. É que a 88 horas e US$ 1.300 aquele produto não existe, e a 51 minutos e US$ 2 ele existe. Preço não é só preço. Preço é a lista de coisas que dá para fazer.

5. Toda a API cabe em três perguntas, e essa pobreza é o recurso

• bool, a pergunta de sim ou não. Volta a probabilidade do sim, de 0 a 1.
• choice, a escolha de uma entre várias opções. Volta a opção escolhida e a probabilidade de cada uma.
• score, a nota numa rubrica. Volta o degrau e a probabilidade de cada degrau.

Duas regras que mudam a qualidade e que quase todo mundo ignora no primeiro dia:

Opção sem descrição é palavra solta. "foro" é uma palavra. O que ela significa dentro deste contrato é o que decide a escolha. Descreva cada opção, uma por uma.

Nota sem régua não é nota, é número inventado. O Jev exige um texto por degrau da rubrica. No nosso projeto, essa rubrica é a única prosa do sistema inteiro, escrita por uma pessoa, versionada no código, e apenas selecionada pelo modelo:

0  Equilibrada: usual no mercado e nao onera nenhuma das partes alem do normal.
1  Desfavoravel: pende para um lado, mas dentro do que se pratica e se aceita.
2  Desequilibrada: transfere risco ou custo relevante para uma parte so;
   deve ser renegociada.
3  Grave: retira direito indisponivel ou impoe onus que dificilmente se
   sustenta em juizo.

Essa é a diferença entre um comentário que você audita de antemão, em revisão de código, e um comentário que aparece pela primeira vez na tela do cliente. Para quem precisa responder a auditoria, a distância entre as duas coisas é o projeto inteiro.

A quarta forma, que é a mais subestimada: fan-out

Uma lista de opções vira uma pergunta sim ou não por opção, todas no mesmo pedido. A TypeSafe chama isso de fan-out, e foi como detectamos omissão no contrato.

Omissão é um problema diferente de todos os outros. As outras perguntas varrem cláusula por cláusula procurando alguma coisa. Essa não pode: a ausência de uma previsão não está escrita em parágrafo nenhum para ser achada. Então a lista do que se espera vem do código, e o modelo responde uma por uma, numa chamada só:

previstas: list[Literal[
    "prazo_de_suporte", "disponibilidade", "exportacao_de_dados",
    "rescisao_simetrica", "limite_de_reajuste", "aviso_de_alteracao",
    "protecao_de_dados", "responsabilidade_por_dolo",
]]

O que falta é a diferença entre a lista esperada e a lista devolvida. No contrato de adesão que usamos, faltavam as oito. No contrato negociado, nenhuma. Mesmo preço de relógio que uma pergunta só.

6. A confiança calibrada é o produto. O resto é consequência

Se você tirar uma coisa só deste post, tire esta.

Um LLM "confiante" está escrevendo sobre si mesmo. Você pede uma nota de 0 a 10 de certeza e ele gera um número, do mesmo jeito que geraria um adjetivo. Não existe medição ali, existe redação.

A confiança do Jev não é escrita. Ela sai da forma da distribuição de probabilidade entre as opções. Distribuição concentrada, confiança alta. Distribuição espalhada, confiança baixa. Não tem introspecção no meio. E ela é calibrada contra resultado: quando o modelo diz 0,7, a intenção é que ele acerte perto de 70% das vezes.

No nosso contrato de adesão assimétrico, isso apareceu de um jeito que ninguém teria programado:

regime = empresarial      confianca 0,39
adesao = True             confianca 0,86

Menos de 0,5 num campo que muda 14 cláusulas de veredito. E o modelo está certo em hesitar: o contrato diz que o aderente é "pessoa física ou jurídica identificada no ato do aceite eletrônico". Não dá para saber, e ele não finge que dá. Rodamos o mesmo arquivo várias vezes e medimos 0,36, 0,39 e 0,45. A oscilação em si já é a resposta: não existe um regime certo ali para ele encontrar.

No contrato negociado, o mesmo campo sai com confiança 1,00 e a classificação é óbvia.

A confiança não mede o quanto o modelo é bom. Mede o quanto o documento é claro. É exatamente por isso que ela é útil.

Daí sai a única arquitetura que interessa, e ela é velha conhecida de qualquer pronto-socorro: três faixas. Confiança alta, o sistema decide sozinho. Confiança média, decide e pede confirmação. Confiança baixa, chama quem sabe.

7. A série de estudos: quatro projetos, quatro defesas contra alucinação

O revisor de contratos não nasceu do nada. Ele é o quarto de uma série de projetos de aprendizado que a gente fez em sequência, e cada um deles trocou a defesa contra alucinação do anterior. Vale ver a escada inteira, porque ela é a história resumida de como a indústria foi aprendendo a não confiar em texto gerado.

Estudo	Entrada	Saída	Defesa contra alucinação
1. RAG de política interna	PDF com texto	texto	nenhuma
2. OCR de documento escaneado	imagem	campos tipados	schema
3. Assistente jurídico com citação	texto de lei	campos e citação	conferir a citação depois
4. Revisor de contrato com Jev	contrato PDF, DOCX ou TXT	só decisão tipada	não há texto para alucinar

No terceiro estudo, a defesa era conferir a citação depois do fato: o modelo escrevia "Art. 49 do CDC" e o código ia ver se aquele artigo estava mesmo nos trechos entregues. Funciona, e é o que a gente recomenda para qualquer RAG em produção. Mas é uma defesa que corre atrás do erro.

No quarto, essa classe inteira de erro deixa de existir, porque a resposta só pode ser um dos valores declarados. Cláusula inventada não tem por onde entrar. O que sobra para validar é outra coisa, e é melhor: se a decisão foi tomada com confiança suficiente para valer sem um humano olhar.

8. O achado que deu nome ao projeto: a ordem das perguntas muda o veredito

Esta é a medição que mais nos surpreendeu, e ela não tem nada a ver com velocidade.

As mesmas 22 cláusulas, o mesmo modelo, o mesmo texto, nenhuma vírgula alterada. Muda só o regime jurídico informado na instrução:

	julgado como consumo	julgado como empresarial
cláusulas nulas	14 de 22	2 de 22
foro de eleição (7.4)	nula, gravidade 3	válida, gravidade 1
rescisão só no fim do prazo (5.3)	nula	válida

"Renúncia prévia a indenização" é nula numa relação de consumo e é negociação legítima entre duas empresas do mesmo porte. Julgar a cláusula sem saber o regime é chutar qual das duas situações é a sua.

Por isso o sistema faz a classificação da relação primeiro, sozinha, e só depois monta o julgamento das cláusulas com o regime dentro da instrução. E por isso aquela confiança de 0,39 é uma informação cara: ela diz que a esteira inteira está apoiada num campo que o documento não deixa claro. O sistema para e pergunta, em vez de decidir sozinho e errado.

A lição generaliza muito além de contrato: quando uma decisão barata muda o resultado de cem decisões seguintes, ela merece ser uma pergunta própria, feita antes, e com a confiança dela na mão.

9. A triagem: o produto é a fila, não o veredito

Cada cláusula sai com uma confiança por campo. O piso é o menor valor entre os campos que de fato movem alguma coisa, no nosso caso nula e gravidade, e é ele que separa o que vale sozinho do que vai para a mesa do advogado.

O campo especie, que classifica a cláusula em treze tipos, fica de fora de propósito. Escolha entre treze opções tem confiança naturalmente mais baixa que um sim ou não, e hesitar entre chamar a cláusula de "rescisão" ou de "vigência" não muda uma linha do que fazer com ela. Exigir certeza ali mandaria para revisão humana cláusulas cujo veredito não tem dúvida nenhuma.

Com o corte em 0,60, e os dois contratos julgados como empresarial:

	contrato assimétrico	contrato equilibrado
cláusulas julgadas	22	21
gravidade média	1,41	0,14
cláusulas unilaterais	17	7
decididas sem humano	4 a 7 de 22	16 a 17 de 21
previsões faltando	8 de 8	0 de 8

Os intervalos são de propósito: rodamos os dois arquivos várias vezes e o número exato de cláusulas que passam do corte oscila. A distância entre as duas colunas, não.

E repare no que ninguém programou: o contrato ruim consome revisor humano e o contrato bom passa quase todo sozinho. Essa diferença cai fora da calibração, de graça, sem nenhuma regra escrita para produzi-la.

Seja honesto com esses números, porque é aqui que a maioria dos posts mente. Mesmo no contrato equilibrado, 4 ou 5 de 21 cláusulas vão para revisão humana. No assimétrico, 15 ou mais. Julgar nulidade é difícil, e um modelo que devolve 0,5 no campo nula está sendo honesto em vez de confiantemente errado. O valor da ferramenta é a fila, não o veredito.

10. A parte sem IA nenhuma, que decide tudo

Antes de qualquer chamada, o documento precisa ser recortado em cláusulas. Isso é expressão regular pura, roda em 10 milissegundos e não tem uma linha de IA. E é o pedaço mais importante do sistema inteiro: se a cláusula 6.1 estiver partida em duas, todo veredito sobre ela está errado, e nenhum modelo fica sabendo disso.

Três defeitos que só apareceram quando soltamos arquivo de verdade na ferramenta:

O PDF virava um contrato de uma cláusula só. A biblioteca que lê PDF entrega fragmentos de texto, não linhas, e o extrator juntava tudo com espaço: a página inteira virava uma linha. Como o segmentador procura numeração no começo da linha, 22 cláusulas viravam 1. Cada fragmento trazia uma marca de fim de linha que ninguém estava usando.

O primeiro item de cada seção sumia. Com as linhas de volta, eram 15 cláusulas em vez de 22: o PDF não tem linha em branco, e a regra de "item precisa abrir bloco" rejeitava o 1.1 que vinha logo abaixo de CLÁUSULA PRIMEIRA, DO OBJETO. Título de seção passou a contar como abertura de bloco.

E o "10 (dez) anos" partia a cláusula ao meio. Uma cláusula dizia "pelo prazo de 10 (dez) anos", e aquele 10 no começo da linha virava uma cláusula nova. A primeira correção olhava layout, linha em branco antes, e funcionava no TXT mas falhava no DOCX. A correção boa olha o texto: contrato brasileiro escreve quantidade como 10 (dez) anos e 5 (cinco) dias, e cláusula nenhuma abre com parêntese.

A moral vale para qualquer projeto de IA documental: o modelo é a parte fácil. A ingestão é onde o projeto morre, e ela não aparece em nenhuma demo.

11. O que o Jev não faz: escrever. E o que fizemos com isso

O cartão da margem dizia "responsabilidade, gravidade 3, nula 0,82". Verdadeiro, auditável e insuficiente para quem vai ligar para o outro lado e negociar. Faltava uma frase dizendo o que aquela cláusula faz com quem assinou.

A solução é exatamente o que um modelo de decisão existe para permitir: triar barato e gastar caro só onde importa.

Escrever sobre as 22 gastaria todo o tempo que o Jev economizou. Escrever sobre as 6 que ele apontou custa 7 segundos.

E aí, com a prosa de volta, volta o erro que ela traz junto: o modelo cita trecho que não existe, ou cita trecho que existe com o número de cláusula errado. Nada sai dali sem passar por uma conferência que compara string, em duas passadas: literal primeiro, depois achatada, com caixa, acento, pontuação e quebra de linha fora, e um mapa de volta para os offsets originais.

• citação igual ao documento: confirmada
• sem acento ou pontuação trocada: confirmada pela passada achatada
• uma palavra trocada: descartada
• citação inventada: descartada
• texto certo com número de cláusula errado: aceita, e o cartão avisa que a numeração foi corrigida

Não se pergunta ao modelo se ele tem certeza. Autoavaliação custa outra chamada e erra junto. E achado descartado sumindo sem deixar rastro é o pior defeito possível numa defesa, então cada descarte é impresso no log. É o mesmo princípio que defendemos em guardrails não bastam: verificação programática vence verificação por modelo, sempre que a verificação programática for possível.

Três voltas que custaram tempo, e que você vai dar também

A cota da API conta o que você reserva, não o que você usa. O tier gratuito de um provedor recusou um briefing de 900 tokens com erro de limite, porque o pedido reservava cerca de 9.000 tokens de saída. Limitar a saída resolveu.

Campo opcional deixou o modelo inventar o próprio schema. Tornamos os campos do achado opcionais para poder receber o objeto pela metade e encher a tela aos poucos. Funcionou, e escondeu o resto: o modelo passou a devolver só dois dos quatro campos, o validador aceitou calado, porque campo ausente vira o padrão, e a tela recebeu seis cartões em branco. Campo obrigatório faz dois trabalhos: obriga o modelo a preencher e, quando ele não preenche, falha a validação e a biblioteca repete a chamada com o erro em mãos. Perder o segundo é perder a rede de proteção.

Um enfeite nosso vazava para a citação. Colocávamos o nome da seção antes do texto da cláusula no briefing, e o modelo copiava isso junto na citação. A citação então não existia no documento e a conferência reprovava um achado bom por causa de um detalhe de formatação que nós mesmos tínhamos inserido.

12. A medição completa, e as três ressalvas que fazem ela valer

Contrato	Claude Opus 5 (gravado)	Jev (medido)
representação, 4.016 caracteres	298,3 s, US$ 1,2131	2,72 s, US$ 0,001535
SaaS de adesão, 4.736 caracteres	320,4 s, US$ 1,3363	3,06 s, US$ 0,001978
serviço B2B, 7.366 caracteres	338,8 s, US$ 1,3751	3,65 s, US$ 0,002617
total	957,4 s (16 minutos), US$ 3,9245	9,23 s, US$ 0,00613

103,8 vezes mais rápido. 640,2 vezes mais barato. Mediana de 3 rodadas, medida em 19 de setembro de 2026. Por chamada: 360 ms na mediana, 766 ms no percentil 95, com concorrência 8.

Agora as ressalvas, porque sem elas o número mente:

Os dois não fazem o mesmo trabalho. O Opus escreve 31 comentários com fundamento legal, tese de defesa e redação sugerida. O Jev devolve seis decisões por cláusula e não escreve absolutamente nada. O que a medição compara é o preço, em segundo e em dólar, do trabalho que o Jev faz. Não é um empate de qualidade decidido no cronômetro.

A baseline já era paralela. Somando o tempo das cinco chamadas do primeiro contrato dá 576 s, mas o relógio de parede foi 298 s, porque quatro passadas rodaram concorrentes. A comparação não é paralelo contra serial.

O preço do Jev é anotado, não medido. US$ 0,042 por milhão de tokens de entrada, saída não cobrada, colhido à mão em 19/09/2026. A biblioteca de preços que usamos ainda nem conhece o provedor, então esse número não sai de nenhuma API. Confira antes de citar.

13. Então ele substitui o LLM? Não. Ele substitui o seu campo fechado

O Jev não escreve, não explica, não redige cláusula, não gera código, não chama ferramenta, não olha imagem. Um LLM faz tudo isso. Não existe substituição possível.

O que ele substitui é outra coisa, e é onde o dinheiro está: ele substitui a chamada de LLM que você fez só para preencher um campo fechado. Aquela que tinha uma lista de valores possíveis no schema e um "responda apenas com JSON" no prompt. Nessa chamada específica, tudo que o LLM tem de melhor, a prosa, a criatividade, o raciocínio aberto, era desperdício que você pagou e descartou.

E ele melhora o LLM que fica, de três maneiras:

1. Na frente, como porteiro. Só o que passa da triagem chega ao modelo caro. Em várias bibliotecas isso é literalmente uma linha de configuração: o modelo barato responde o que consegue expressar e entrega ao LLM, com ferramentas e tudo, só o que ele não consegue.
2. Atrás, como guarda. O LLM escreveu, e o modelo de decisão avalia em 300 ms se aquilo vaza dado pessoal, se responde a pergunta, se pode ir ao cliente. Guardrail que custa três décimos de centavo não é debate de orçamento, é linha de código.
3. Ao lado, como juiz. Avaliar 100 mil saídas com LLM como juiz é caro e lento o bastante para você simplesmente não fazer. Com um System One você faz, e ainda ganha a confiança calibrada em cima de cada nota.

As oito funções onde ele entra hoje

Todas têm a mesma assinatura: o espaço de respostas é fechado e o valor está na decisão, não na prosa.

• Roteamento de intenção. Ticket, mensagem, e-mail, ligação: para qual fila, qual handler, qual agente.
• Triagem e prioridade. Nota numa rubrica que você escreveu. Ordena a fila, não escreve o laudo.
• Guardrail de entrada e saída. Isso é injeção de prompt? Isso vaza dado pessoal? Isso é irreversível?
• Filtro antes do caro. Vale rodar o RAG, o modelo grande, a busca de 40 mil tokens nesse documento?
• Extração de campo fechado. Categoria, sentimento, regime, idioma, país, produto.
• Detecção de omissão. O que deveria estar aqui e não está, via fan-out.
• Juiz de avaliação em escala. Comparar, pontuar e rotular saída de modelo, com confiança por item.
• Decisão dentro do loop do agente. Antes de rodar o comando: destrói dado? precisa de confirmação? é o que o usuário pediu? (O loop está explicado em como um agente funciona por baixo dos panos.)

Um jeito rápido de achar os seus: procure no código todo prompt que termina em "responda apenas com JSON". Cada ocorrência é um candidato. Normalmente eles são a maioria das chamadas e a minoria do valor.

14. Jev ou LLM? A decisão cabe em três perguntas

1. A resposta cabe num conjunto fechado que você consegue escrever hoje? Se não cabe, é LLM. E se você não consegue escrever o conjunto, talvez o problema ainda não esteja definido.
2. Alguém vai ler a resposta, ou só o software? Se um humano vai ler prosa, é LLM. Se é o if da linha seguinte que vai ler, é System One.
3. Você sabe o que fazer quando o modelo não tiver certeza? Se não sabe, comece por aí. É a pergunta mais importante das três e a única que a confiança calibrada responde de graça.

15. O que fazer na segunda-feira

• Procure "responda apenas com JSON" no seu código. Cada ocorrência é provavelmente sistema 1 disfarçado de sistema 2 e pago como sistema 2.
• Separe a fatura em duas. Quanto você gasta gerando texto que alguém lê, e quanto gasta decidindo coisa que só o código lê. A segunda pilha é a que muda de modelo.
• Escreva o espaço de respostas antes do prompt. As opções com descrição, e a rubrica com um texto por degrau, escritos por gente, versionados, auditáveis antes de chegarem à tela do cliente.
• Não invente o corte de confiança. Meça em exemplos rotulados e saiba o que acontece abaixo dele antes de subir para produção.
• Deixe o LLM atrás, não fora. O barato responde o que consegue, o caro responde o resto, e a fatura passa a ter forma previsível.
• Publique a ressalva junto com o número. "640 vezes mais barato" sem a nota de que os dois não fazem o mesmo trabalho é marketing, não medição.

16. Onde isso ainda não está bom

Para fechar sem vender milagre, a lista do que sabemos que quebra:

• PDF digitalizado não passa. Sem camada de texto, a extração devolve quase nada, e o sistema para pedindo OCR em vez de mandar o vazio para o modelo julgar.
• A lista de omissões é de um tipo de contrato só. Ela foi escrita para prestação de serviço continuada. Rodar num contrato de compra e venda vai acusar oito ausências que não fazem sentido ali.
• Uma chamada por cláusula. São 22 no exemplo, com concorrência 8. Num contrato de cem cláusulas são cem chamadas, e o gargalo passa a ser a API.
• O grifo cobre a cláusula inteira, porque a unidade julgada é a cláusula. Num contrato denso isso deixa quase todo o documento marcado. É honesto e é feio.
• O escritor de comentários é a peça frágil, e é opcional de propósito: depende de outro provedor, outra chave e outra cota. Se ele falhar, a revisão continua mostrando o que o Jev achou.

Perguntas frequentes

O que é um System One Model?

É uma classe de modelo de IA feita para decidir, não para escrever. Em vez de devolver texto, devolve um valor tipado, verdadeiro ou falso, uma opção de uma lista ou uma nota numa rubrica, junto com a probabilidade calibrada daquela resposta. O nome vem da divisão de Kahneman entre pensamento rápido e automático, sistema 1, e pensamento lento e verbal, sistema 2.

O Jev substitui o ChatGPT, o Claude ou o Gemini?

Não. Ele não escreve, não explica, não gera código e não chama ferramenta. Ele substitui as chamadas de LLM que existem só para preencher um campo fechado, como classificar, pontuar ou filtrar. Nessas, o LLM é caro e lento sem entregar nada a mais.

Por que ele é tão mais rápido?

Porque um LLM produz a resposta token a token, em sequência, e a latência dele cresce com o tamanho da resposta. Um System One tem o espaço de respostas fechado antes da chamada, então responde num passe só, e as perguntas correm em paralelo. Acrescentar perguntas quase não muda o tempo.

O que é confiança calibrada e por que ela importa mais que a velocidade?

É a probabilidade que sai da forma da distribuição entre as opções possíveis, e não de o modelo escrever sobre si mesmo. Quando ele diz 0,7, a intenção é acertar perto de 70% das vezes. Isso permite montar três faixas: decidir sozinho, decidir e confirmar, ou chamar um humano. É a arquitetura que quase nenhum sistema de IA em produção tem e quase todos precisam.

Dá para usar isso na minha empresa hoje?

Dá, desde que o problema tenha resposta fechada e alguém saiba escrever as opções. Os candidatos típicos são triagem de ticket, roteamento de atendimento, classificação de documento, guardrail de conteúdo e avaliação de qualidade em escala. O caminho que a gente recomenda é medir antes: separar a fatura de IA entre "texto que alguém lê" e "decisão que só o código lê".

Esses números valem para qualquer caso?

Não. Eles são de três contratos, medidos na nossa máquina em 19/09/2026, com mediana de três rodadas, comparando um modelo que escreve 31 comentários contra um que devolve seis decisões por cláusula e não escreve nada. A ordem de grandeza se sustenta, o número exato não é promessa.

O que a gente tira disso

Rápido e barato já é motivo suficiente para olhar. Mas o que realmente muda o desenho de um sistema é o modelo conseguir dizer "nessa aqui eu não tenho certeza", e o seu código ter para onde mandar esse caso.

É o mesmo princípio que a gente aplica em projeto de cliente, sem IA nenhuma envolvida: antes de automatizar um processo, medir onde ele trava e quanto isso custa por ano. A fila é o produto. Quem sabe o que não sabe, decide melhor onde gastar.

Se você quer descobrir quais das suas chamadas de IA são sistema 1 pagas a preço de sistema 2, ou onde a sua operação está perdendo hora por semana sem ninguém ter medido, esse é exatamente o trabalho do diagnóstico abaixo.