Perguntas paralelas: 13 numa chamada

Um time de conformidade recebe um documento regulatório e tem treze coisas a verificar: prazo de notificação, alcance territorial, obrigação de encarregado, validade de consentimento, direitos do titular, teto de multa. O documento é um só. As perguntas são treze.

A pergunta de arquitetura é simples: uma chamada com treze perguntas, ou treze chamadas com uma pergunta cada? A resposta tem consequência direta na fatura, e o cookbook oficial mediu exatamente isso.

Por que a solução ingênua custa caro

O reflexo de quem vem de LLM é um laço: para cada pergunta, monte o prompt, mande o documento, receba a resposta. Funciona — e paga o documento treze vezes.

É aqui que a conta aparece. Numa chamada ao Jev, o que domina o custo não é a pergunta: é o state. Um documento de dezenas de milhares de caracteres ocupa quase todos os tokens de entrada da requisição. Treze chamadas avulsas reenviam esse documento treze vezes, em treze idas e voltas de rede. A chamada em lote paga o documento uma vez.

O segundo custo é mais sutil e é o que mais assusta quem está decidindo: será que agrupar perguntas piora a qualidade? Com um LLM, essa desconfiança é justificada — perguntas empilhadas no mesmo prompt interferem umas nas outras. No Jev, a documentação afirma que cada pergunta é avaliada de forma independente contra o mesmo state. O cookbook existe para testar essa afirmação.

O desenho das perguntas

O experimento usa o artigo da Wikipédia sobre o GDPR, em inglês, numa revisão fixada de 53.777 caracteres, e treze perguntas divididas em 8 Noul, 2 Choice e 3 Score — a mistura que um briefing regulatório real teria.

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

PERGUNTAS = {
    "prazo_72h": Noul(
        instructions="Um vazamento de dados pessoais deve ser comunicado à autoridade em até 72 horas?"
    ),
    "alcance_fora_da_ue": Noul(
        instructions="A regra vale para organizações fora da UE que oferecem serviços a pessoas na UE?"
    ),
    "tipo_de_instrumento": Choice(
        instructions="Que tipo de instrumento jurídico é este texto?",
        criteria={
            "regulamento": "Lei diretamente aplicável, sem transposição nacional.",
            "diretiva": "Define objetivos que cada país implementa em lei própria.",
            "tratado": "Acordo internacional entre estados.",
        },
    ),
    "peso_da_conformidade": Score(
        instructions="Quão pesada é a carga de conformidade imposta às organizações?",
        criteria=[
            "Irrelevante: sem obrigações materiais.",
            "Leve: alguns avisos e divulgações.",
            "Moderada: processos documentados e papéis dedicados nos maiores.",
            "Alta: registros, avaliações de impacto, encarregado e procedimentos de incidente.",
        ],
    ),
}

with TypeSafeClient() as client:
    resposta = client.system_one(state={"artigo": DOCUMENTO}, questions=PERGUNTAS)

O documento entra uma vez, no state. As perguntas entram juntas, no mesmo mapa. O código lê cada resposta pelo identificador que escolheu. Nada de parsing, nada de laço de chamadas.

O que o experimento oficial mediu

O cookbook rodou as duas estratégias cinco vezes cada, para poder comparar média e desvio padrão de cada resposta. Os números abaixo são os publicados pela TypeSafe, medidos com o modelo jev-1.12:

Daí saem os dois números de manchete: 12,2 vezes mais barato e 10,0 vezes mais rápido.

Sobre a qualidade, o resultado é o que interessa mais: a maioria das treze respostas voltou idêntica nas cinco execuções, com desvio padrão exatamente 0,0, tanto em lote quanto avulsa. Duas perguntas — o prazo de 72 horas e a de penalidades criminais — carregaram um ruído pequeno de execução para execução, e esse ruído teve o mesmo tamanho nas duas estratégias. Ou seja: agrupar não deslocou a média nem adicionou variância.

Duas ressalvas honestas, ambas do próprio cookbook. A primeira: o tempo das chamadas avulsas soma as treze em sequência; disparadas em paralelo, a diferença de tempo encolhe, mas o custo de reenviar o documento treze vezes permanece. A segunda: o experimento declara rodar no jev-1.12, enquanto a versão atual do modelo é a jev-1.13.0.

O que muda em português

Nada na mecânica: o orçamento de tokens, a independência das perguntas e a economia do state valem igual em qualquer idioma. O que muda é a expectativa de acurácia, porque a TypeSafe declara que o inglês é a língua principal de treino e que outras línguas são atendidas, mas não igualmente bem.

Do nosso lado, o efeito do agrupamento apareceu na prática: nas cinco chamadas que fizemos em 18 de setembro de 2026 contra a API oficial, seis perguntas sobre textos brasileiros couberam em 955 tokens de entrada médios, com latências de 270 ms, 538 ms de mediana e 802 ms. Seis decisões por uma chamada, em menos de um segundo. A conta em reais está em preço.

Onde isso quebra

O fan-out não é gratuito em todo cenário, e vale saber onde ele encosta nos limites declarados do jev-1.13:

• State grande com detalhe irrelevante. Juntar perguntas incentiva mandar um documento grande e perguntar tudo. Mas a documentação lista state inflado como modo de falha: material sem relação com a decisão funciona como distrator e derruba acurácia. Agrupar perguntas, sim; inflar o state, não. Como montar a entrada está em state.
• Orçamento compartilhado. As perguntas dividem o mesmo orçamento com o state. Muitas perguntas longas competem com o documento pelo espaço.
• Perguntas dependentes. Se a segunda pergunta só existe depois da resposta da primeira, o agrupamento não se aplica — é caso de segunda requisição, e a documentação trata isso como exceção, não regra.
• Contagem. Agrupar não conserta o que o modelo não faz bem: pedir “quantas cláusulas existem” continua sendo conta, e conta pertence ao código.

O hábito que fica

Depois de ler esta receita, a pergunta certa em revisão de código muda. Não é mais “essa pergunta é necessária?”, e sim “essa pergunta pode ir junto com as outras?”. O padrão tem nome — fan-out especulativo — e está descrito com os outros três em padrões. O índice das receitas está em receitas.