Quantas vezes rodar o mesmo prompt no GPT-6 Astra antes de confiar no resultado?

Rodou o prompt uma vez, viu funcionar, e já saiu por aí dizendo que o modelo "sabe fazer" aquilo

Esse é o erro mais barato de cometer e o mais caro de descobrir depois…

O GPT-6 Astra é o modelo de fronteira mais recente da OpenAI, anunciado em 3 de setembro de 2026, e nem por isso ele devolve exatamente a mesma coisa toda vez que você aperta enter

Mesmo prompt, duas rodadas, dois resultados que não batem

Então a pergunta do título é bem prática mesmo: quantas vezes rodar antes de confiar? O que eu quero te entregar aqui é um método de repetição pra separar sorte de comportamento real, com registro do que muda de uma rodada pra outra

Bora ver na prática? 🙂

Por que uma única rodada engana em modelo generativo

A cabeça de quem vem de software tradicional é assim: rodou a função, deu o resultado certo, a função está certa

Com modelo generativo essa lógica quebra

O experimento mais didático disso está no blog do Thinking Machines Lab: 1.000 completions do Qwen3-235B-A22B-Instruct a temperatura 0 produziram 80 saídas distintas, e a divergência começava lá no token 103

Se liga no detalhe: temperatura ZERO, ou seja, o cenário em que "não deveria" variar

E a causa apontada não é só o arredondamento de ponto flutuante, que é a explicação que todo mundo repete

A causa principal é a falta de "batch invariance" nos kernels de redução da inferência: matmul, RMSNorm e atenção mudam o resultado numérico conforme o tamanho do batch dinâmico em que a sua requisição cai no servidor

Formação Recomendada

Formação Claude Code

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

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

Que batch é esse?

É o pacote de requisições que o servidor processa junto, no mesmo momento

Você não controla isso, nem enxerga

Se o servidor estiver vazio, sua requisição cai num batch pequeno, se estiver cheio de gente, cai num batch grande, e a conta interna sai numericamente diferente

Mesma pergunta, ambiente de execução diferente

Dá pra eliminar essa variação? Dá, com kernels invariantes a batch: no mesmo trabalho, 1.000 rodadas do Qwen3-8B saíram idênticas bit a bit

O preço foi de aproximadamente 61,5% de throughput na implementação de referência

Ou seja, determinismo total custa desempenho, e caro

E não é só o pessoal de pesquisa dizendo isso: a própria OpenAI descreve o determinismo da API como um esforço de melhor tentativa (best effort), não como garantia, e recomenda monitorar o campo system_fingerprint, que muda quando pesos, infraestrutura ou configuração do backend mudam

Tome cuidado com uma leitura apressada aqui: o experimento acima foi feito com modelos Qwen, e eu não tenho como afirmar que a mesma análise de batch se aplica à infraestrutura da OpenAI

O ponto que interessa pra você é outro, e esse vale sempre: variação entre rodadas iguais é o comportamento esperado, não uma exceção esquisita

O que você precisa antes de começar a repetir o teste

A lista é curta, e nenhum item é opcional:

• Acesso ao GPT-6 Astra: ele está no ChatGPT nos planos Plus, Pro, Business e Enterprise, em liberação gradual, e também pela API da OpenAI, pela Microsoft Azure e pela AWS Bedrock
• Um prompt congelado: o texto tem que ser IDÊNTICO em todas as rodadas, sem "ah, melhorei uma palavrinha no meio"
• Um critério de acerto escrito antes de rodar: o que conta como certo e o que conta como errado, no papel, antes de ver qualquer saída
• Uma planilha ou um arquivo de log: uma linha por rodada, sem exceção

Aviso operacional que quebra o teste de muita gente:

No gpt-6-astra os parâmetros temperature, top_p e logprobs/top_logprobs não são suportados e precisam ser removidos da chamada

E atenção nisso: o modelo REJEITA a requisição em vez de ignorar o parâmetro

Se o seu script de teste é herdado de um modelo antigo, ele provavelmente ainda manda temperature=0 e vai estourar na sua cara

Vale a mesma disciplina de um checklist antes de trocar o modelo em produção: revisar os parâmetros da chamada primeiro, testar depois

O controle que existe no lugar é o esforço de raciocínio: reasoning.effort na Responses ou reasoning_effort na Chat Completions, com os valores low, medium, high, xhigh e max

O valor none não é aceito e retorna HTTP 400, e a orientação é começar por low

E o custo de rodar tudo isso várias vezes?

Preço de API padrão do GPT-6 Astra: US$ 10 por milhão de tokens de entrada e US$ 50 por milhão de tokens de saída

Batch e Flex custam 50% do padrão, e o modo Fast custa 2x

Faz a conta antes de disparar 10 rodadas de um prompt gordo, beleza? Bateria de teste é investimento, mas investimento também aparece na fatura 😀

Como repetir o mesmo prompt e ler o resultado (passo a passo)

1. Escreva o critério de acerto ANTES da primeira rodada

Define no texto o que é acerto: o JSON tem os 4 campos obrigatórios, o cálculo bate com o valor esperado, o resumo cita as 3 seções pedidas

O erro comum deste passo: julgar depois de ver a saída. Aí você lê uma resposta bonita e o seu cérebro inventa o critério que aquela resposta atende

2. Congele as variáveis

Mesmo prompt, mesmo esforço de raciocínio, mesmo caminho de acesso (ou tudo na API, ou tudo no ChatGPT, não meio a meio)

Muda uma coisa por vez, sempre

O erro comum deste passo: ajustar o prompt no meio da bateria e comparar rodadas que não são comparáveis

3. Rode a bateria e guarde TUDO

Regra prática: 3 rodadas pra triagem rápida, de 5 a 10 rodadas quando a decisão importa

Cada saída vai pro arquivo com o identificador da rodada

O erro comum deste passo: salvar só a rodada que deu certo, que é exatamente a que menos informação carrega

4. Registre o system_fingerprint junto de cada rodada, quando ele vier na resposta

Esse campo muda quando pesos, infraestrutura ou configuração do backend mudam, então rodadas com fingerprint diferente simplesmente não são o mesmo ambiente

O erro comum deste passo: juntar resultado de terça com resultado de sexta e chamar isso de "a mesma bateria"

# Responses API: sem temperature, sem top_p, sem logprobs
# o controle disponivel e o esforco de raciocinio

PROMPT = "...seu prompt congelado, identico em todas as rodadas..."

for rodada in range(1, 11):
    r = client.responses.create(
        model="gpt-6-astra",
        input=PROMPT,
        reasoning={"effort": "low"},  # low, medium, high, xhigh, max
    )
    registrar(rodada, r)  # salva a saida bruta, nao so o seu "achei que foi bem"

Na Chat Completions o nome do campo é reasoning_effort, com os mesmos valores

E repetindo, porque é o tropeço mais comum: nada de temperature ou top_p na chamada

5. Conte acertos em vez de olhar impressão geral

7/10 é um número

"Foi bem" não é número nenhum

O erro comum deste passo: transformar taxa de acerto em nota subjetiva na hora de contar pro time

6. Compare pareado quando testar uma versão alternativa do prompt

Rodou a bateria da versão A? Roda a MESMA bateria pra versão B e compara tarefa a tarefa, não média contra média

Essa ideia de tratar avaliação como experimento estatístico está no artigo "Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations", de Evan Miller (Anthropic), publicado em 04/11/2024 (arXiv 2411.00640), que recomenda erro-padrão, intervalos por bootstrap, testes pareados pra comparar modelos e erros-padrão agrupados quando existem múltiplas rodadas da mesma questão

O erro comum deste passo: comparar duas médias tiradas de conjuntos de tarefas diferentes, que é o jeito mais rápido de se enganar com aparência de rigor

O que anotar em cada rodada: a planilha mínima de variação

Agora a parte chata que ninguém faz e que é justamente a que resolve o problema

Só "funcionou / não funcionou" é pouco, porque isso apaga a informação mais valiosa: COMO cada rodada diferiu da outra

A planilha mínima:

A coluna de divergência é o coração da coisa

Mudar a ordem de dois itens de uma lista é ruído cosmético, e ruído cosmético você resolve com formato mais explícito no prompt

Mudar o valor de um cálculo, inventar um campo que não existe ou trocar um nome próprio é falha de conteúdo, e falha de conteúdo é assunto sério

São problemas de natureza diferente, com soluções diferentes

Se tudo entra na planilha como "deu ruim", você perde essa distinção e fica girando em círculo

O erro comum deste passo: anotar só "funcionou" e jogar fora a saída bruta. Sem a saída salva, não dá pra reler a bateria depois e entender o padrão

O modelo acertou numa rodada e errou na seguinte: o que fazer

Sintoma: a taxa de acerto ficou no meio do caminho, tipo 6 acertos em 10

Não é aquele fracasso limpo que te faz jogar o prompt fora, e também não é confiável o suficiente pra ir pra produção

Causa: variação entre rodadas é característica da inferência, como o experimento lá em cima mostra

Ou seja, não assume de cara que é bug do seu prompt

Pode ser, mas pode ser só o comportamento normal do sistema aparecendo pra você pela primeira vez porque agora você está OLHANDO

Soluções, nessa ordem:

1. Aumente o número de rodadas. 6/10 pode não ser 6/10 de verdade, pode ser ruído de amostra pequena. Antes de mexer no prompt, descubra se o número é estável
2. Endureça o critério de saída dentro do prompt. Formato explícito, campos obrigatórios nomeados, checklist de verificação que o modelo tem que percorrer antes de responder
3. Suba o esforço de raciocínio. Começou em low, testa medium, depois high, xhigh ou max, e refaz a bateria inteira a cada mudança
4. Quebre a tarefa em passos menores. Tarefa grande acumula chance de errar em algum ponto do caminho
5. Adicione verificação no seu código. Valida o JSON, confere o cálculo, checa se os campos existem, em vez de confiar na saída bruta. É a mesma disciplina de validar a resposta antes de usar no código, só que aplicada de forma automática

Como prevenir: nunca promova um prompt pra produção com base em uma rodada

E guarda a bateria, ela vira seu teste de regressão

Quando o system_fingerprint mudar, roda a bateria de novo antes de descobrir na reclamação do usuário que alguma coisa mudou embaixo do seu pé 😛

Quantas rodadas para cada tipo de tarefa

Não faz sentido gastar o mesmo esforço pra tudo

Texto criativo é um bicho, extração de dado é outro completamente diferente:

E tem um número no próprio anúncio do GPT-6 Astra que serve de vacina contra empolgação: 72,6% no OSWorld 2.0, contra 65,7% do GPT-5.6 Sol

É um salto real no benchmark de uso de computador que a OpenAI destacou

Mas repara: mesmo no benchmark escolhido pra brilhar, o modelo falha em parte das tarefas

Então sua rodada única de sucesso pode muito bem ter caído na fatia que dá certo, e você concluiu o mundo inteiro a partir dela

E as tarefas de contexto longo?

A janela é de 1.050.000 tokens, com até 128.000 tokens de saída, o que abre espaço pra jogar base de código e documentação inteira lá dentro

Só que requisições acima de 272 mil tokens de entrada são cobradas a 2x na entrada e no cache, e 1,5x na saída

Multiplica isso por 10 rodadas e você entende por que bateria com prompt gigante precisa de planejamento, não de impulso

Uma saída razoável aqui é testar a lógica com uma versão reduzida do contexto e só depois confirmar com o contexto cheio, em menos rodadas

Conclusão

A mudança de mentalidade cabe numa frase: para de dizer "funcionou" e começa a dizer "funcionou X vezes em N"

É isso que separa sorte de comportamento real

Uma rodada isolada não é evidência, é anedota, e anedota não sustenta decisão de produção

O próximo passo é bem concreto: pega um prompt que você já usa hoje, escreve o critério de acerto antes de rodar, dispara de 5 a 10 rodadas, preenche a planilha mínima e olha a taxa real antes de decidir qualquer coisa

Provavelmente vai doer um pouquinho

E guarda esse detalhe: o corte de conhecimento do GPT-6 Astra é 30 de abril de 2026

Qualquer coisa posterior a isso precisa vir no contexto que VOCÊ fornece, não da memória do modelo, e isso também entra no seu critério de acerto

Até o próximo post!