Compute em tempo de teste (Test-Time Compute)

O que é Computação em Tempo de Teste?

Computação em tempo de teste (test-time compute, TTC) refere-se a gastar computação adicional no momento da inferência para melhorar a qualidade da saída de um modelo de IA — especialmente em tarefas que exigem raciocínio em múltiplas etapas, planejamento ou verificação. Às vezes, isso é chamado de escalonamento em tempo de inferência (inference-time scaling) ou pensamento estendido (extended thinking).

Para modelos de linguagem grandes (large language models, LLMs), computação em tempo de teste normalmente significa um (ou mais) dos itens abaixo:

  • Gerar mais tokens (rastros de raciocínio mais longos, deliberação ou autoexplicações)
  • Gerar mais respostas candidatas (amostrar múltiplas soluções e selecionar a melhor)
  • Executar busca (search) sobre etapas intermediárias (ramificação, retrocesso, exploração de árvore/grafo)
  • Usar verificadores, críticos ou modelos de recompensa para avaliar candidatos
  • Chamar ferramentas externas (recuperação, execução de código, calculadoras, planejadores) e integrar os resultados
  • Alocar computação de forma adaptativa (gastar mais computação apenas quando a tarefa parecer difícil ou a incerteza for alta)

A computação em tempo de teste é uma resposta prática a uma realidade comum: talvez você não consiga (ou não queira) treinar um modelo maior ou retreinar com frequência, mas muitas vezes consegue arcar com um pouco mais de computação por consulta para obter maior acurácia.

Este tema se conecta fortemente a:

Por que mais computação na inferência pode melhorar a qualidade

Saídas de LLMs são amostras, não uma única “melhor” resposta

Um LLM produz uma distribuição de probabilidade sobre os próximos tokens. Para tarefas não triviais, pode haver:

  • Muitas continuações plausíveis
  • Um pequeno subconjunto que é correto ou de alta qualidade

Ao gastar mais computação — amostrando múltiplas saídas, buscando e verificando — você aumenta a chance de encontrar e selecionar uma boa solução.

“Raciocínio” muitas vezes requer refinamento iterativo

Mesmo que um modelo tenha a capacidade de resolver uma tarefa, ele pode falhar sob uma única passagem gulosa. Etapas extras podem ajudar a:

  • Manter estado intermediário (variáveis, restrições)
  • Detectar erros
  • Explorar abordagens alternativas
  • Integrar evidências (documentos recuperados, saídas de ferramentas)

A computação em tempo de teste complementa o escalonamento em tempo de treinamento

O escalonamento em tempo de treinamento (modelos maiores, mais dados, mais computação) geralmente melhora a capacidade, como descrito em Pré-treinamento e Leis de Escalonamento. A computação em tempo de teste é diferente: ela tenta extrair mais desempenho de um modelo fixo mudando o procedimento de inferência em vez dos pesos.

Na prática, os melhores sistemas combinam ambos:

  • Treinar um modelo capaz
  • Usar computação em tempo de teste para reduzir taxas de erro nas consultas mais difíceis

Dimensões da computação em tempo de teste

1) “Pensar” por mais tempo (mais tokens)

Você instrui ou permite que o modelo produza mais etapas intermediárias de raciocínio ou um plano mais longo antes de responder. Isso está intimamente relacionado a métodos de prompting em Técnicas de Cadeia de Pensamento e Raciocínio.

Prós

  • Barato e simples (não exige modelos adicionais)
  • Funciona bem para matemática, lógica, instruções em múltiplas etapas e planejamento de código

Contras

  • Não há garantia de correção (LLMs podem produzir raciocínios fluentes, porém errados)
  • Mais tokens aumentam latência e custo
  • Algumas configurações ocultam o texto de raciocínio; o modelo ainda pode “pensar”, mas você não verá isso

2) Múltiplas amostras + seleção (melhor-de-N)

Gere N soluções candidatas independentes (via amostragem por temperatura/top-p) e escolha a melhor usando:

  • Uma heurística (por exemplo, o programa válido mais curto que passa nos testes)
  • Um pontuador/verificador aprendido
  • Votação por maioria (autoconsistência)

Isso depende de Estratégias de Decodificação e costuma ser uma das técnicas de computação em tempo de teste com maior ROI.

3) Busca sobre etapas intermediárias (métodos de árvore/grafo)

Em vez de gerar uma única cadeia longa, você ramifica:

  • Explora múltiplas soluções parciais
  • Avalia e poda
  • Potencialmente faz retrocesso

Exemplos incluem métodos no estilo “tree-of-thought” e outras abordagens de raciocínio estruturado (veja Técnicas de Cadeia de Pensamento e Raciocínio).

4) Verificação e crítica (gerar–checar–refinar)

Use computação adicional para checar uma resposta:

  • Peça ao mesmo modelo para criticar o próprio trabalho
  • Use um modelo verificador separado
  • Use ferramentas (testes unitários, resolvedores simbólicos, checagem factual via recuperação)

Esta é uma ideia central de computação em tempo de teste para reduzir Alucinações: não apenas gere — valide.

5) Uso de ferramentas e recuperação (computação gasta fora do LLM)

Chamar ferramentas adiciona latência e custo, mas pode melhorar enormemente a correção:

  • Geração aumentada por recuperação para embasamento factual
  • Execução de código para correção em matemática/programação
  • Ferramentas de planejamento para fluxos de trabalho

Veja LLMs que Usam Ferramentas.

6) Computação adaptativa (gastar mais apenas quando necessário)

Em vez de aplicar computação em tempo de teste cara a toda consulta, você:

  • Estima dificuldade/incerteza
  • Usa saída antecipada quando estiver confiante
  • Escala para mais amostragem/busca/verificação em casos difíceis

Isso geralmente é a diferença entre uma demonstração impressionante e um sistema de produção custo-efetivo.

Estratégias centrais de computação em tempo de teste (com exemplos)

Estratégia A: Autoconsistência (votação por maioria sobre raciocínio amostrado)

Ideia: amostrar múltiplos caminhos de raciocínio e então escolher a resposta final mais comum.

Isso é especialmente eficaz quando:

  • Há muitas maneiras de raciocinar corretamente
  • Soluções incorretas são diversas, enquanto soluções corretas convergem

Exemplo prático (problema textual de matemática):

  1. Amostrar 20 soluções com temperatura 0.7
  2. Extrair a resposta numérica final de cada uma
  3. Escolher o modo (mais frequente)
from collections import Counter

def self_consistency(llm, prompt, n=20, temperature=0.7):
    answers = []
    for _ in range(n):
        out = llm.generate(prompt, temperature=temperature)
        answers.append(extract_final_answer(out))  # task-specific parsing
    return Counter(answers).most_common(1)[0][0]

Notas

  • Este é um “ponto doce” de computação em tempo de teste: fácil de implementar e frequentemente aumenta a acurácia.
  • Combina naturalmente com Estratégias de Decodificação: você quer diversidade entre as amostras.

Estratégia B: Melhor-de-N com um verificador (reranking)

Ideia: amostrar N candidatos e então pontuá-los com um verificador que se correlaciona com correção.

Verificadores comuns:

  • Outro LLM atuando como juiz (cuidado: juízes podem ser enviesados)
  • Um modelo de recompensa (relacionado a alinhamento; veja Alinhamento)
  • Uma checagem baseada em ferramentas (testes unitários, validação simbólica)
  • Uma heurística específica do domínio (por exemplo, “contém as citações exigidas”)

Exemplo (tarefa de programação):

  • Gerar 10 funções candidatas
  • Rodar testes unitários
  • Escolher o candidato que passa no maior número de testes
def best_of_n_with_tests(llm, spec, tests, n=10):
    candidates = [llm.generate(spec, temperature=0.6) for _ in range(n)]
    scored = []
    for code in candidates:
        passed = run_unit_tests(code, tests)  # returns number passed
        scored.append((passed, code))
    scored.sort(reverse=True, key=lambda x: x[0])
    return scored[0][1]

Isso frequentemente traz grandes ganhos porque a execução é um verificador de alta precisão.

Estratégia C: Gerar → Criticar → Revisar (refinamento iterativo)

Ideia: usar passagens adicionais para identificar falhas e corrigi-las.

Um padrão simples:

  1. Rascunhar solução
  2. Criticar por erros / requisitos ausentes
  3. Revisar
  4. Opcionalmente repetir com uma condição de parada

Padrão de prompt de exemplo

  • Rascunho: “Resolva o problema.”
  • Crítica: “Liste potenciais erros, casos de borda ou afirmações sem suporte.”
  • Revisão: “Produza uma resposta final corrigida.”

Isso pode melhorar a qualidade, mas tenha cautela:

  • A crítica pode introduzir novos erros
  • Se o modelo não tiver a capacidade, iterações não corrigirão os fundamentos

Estratégia D: Busca em árvore sobre raciocínio (ramificação + poda)

Ideia: explorar múltiplos caminhos parciais de solução, pontuar estados parciais e expandir os promissores.

Loop em alto nível:

  1. Manter uma fila de prioridade de pensamentos parciais
  2. Expandir os k melhores nós (pedir ao modelo opções para a próxima etapa)
  3. Pontuar nós (heurística ou verificador)
  4. Continuar até o orçamento se esgotar ou uma solução ser encontrada

Isso é computação em tempo de teste como busca, similar em espírito ao planejamento clássico de IA, mas usando um LLM como mecanismo de proposição.

Estratégia E: Recuperação + verificação (resposta fundamentada)

Para consultas factuais, a computação em tempo de teste frequentemente é melhor investida em:

  • Recuperar fontes relevantes
  • Checar afirmações contra as fontes
  • Gerar uma resposta com citações

Isso reduz alucinações ao deslocar o problema de “lembrar a partir dos parâmetros” para “sintetizar a partir de evidências”. Veja também Aprendizado em Contexto e Janelas de Contexto para as restrições práticas de encaixar evidências no prompt.

Estratégia F: Políticas de computação adaptativa (inferência a qualquer momento)

Ideia: não gastar sempre o orçamento máximo. Escalar apenas se necessário.

Uma política adaptativa simples:

  • Primeira tentativa: decodificação gulosa barata
  • Se a confiança for baixa (por exemplo, incerteza do modelo, violações de restrições, testes falhando), então:
    • amostrar mais candidatos
    • rodar crítica
    • usar ferramentas / recuperação
    • fazer uma busca limitada

Isso pode reduzir dramaticamente o custo médio, preservando alta acurácia em entradas difíceis.

Raciocínio compute-ótimo: como gastar o orçamento de inferência com sabedoria

“Mais computação” não é um único controle; você pode gastá-la de maneiras diferentes. A computação em tempo de teste compute-ótima pergunta:

Dado um orçamento fixo de inferência (latência, tokens, chamadas de ferramenta), qual estratégia produz a maior acurácia esperada?

Principais trade-offs

Tokens vs amostras

  • Um rastro de raciocínio único mais longo (mais tokens) pode ajudar a manter coerência e lidar com lógica em múltiplas etapas.
  • Mais amostras podem ajudar a escapar de erros locais e explorar aleatoriedade para encontrar caminhos corretos.

Frequentemente, raciocínio moderado + múltiplas amostras supera uma cadeia extremamente longa, especialmente quando há verificação disponível.

Profundidade vs amplitude da busca

  • Profundidade: seguir um plano profundamente (risco: comprometer cedo com uma abordagem errada)
  • Amplitude: explorar abordagens diversas (risco: gastar orçamento em ramificações de baixa qualidade)

Um padrão compute-ótimo comum é amplitude primeiro no início, profundidade depois:

  • Gerar algumas abordagens diferentes
  • Escolher a mais promissora
  • Então expandir e verificar

Verificação é alavancagem

Se você consegue verificar a correção de forma barata (testes, restrições, evidência via recuperação), frequentemente é compute-ótimo:

  • Gerar vários candidatos
  • Verificá-los
  • Selecionar o melhor

Isso transforma o modelo em um gerador de propostas e o verificador no tomador de decisão.

Um template prático de “computação em tempo de teste com orçamento”

  1. Tentativa 1 (barata): decodificação gulosa / baixa temperatura
  2. Checagem: validação de restrições (formato, esquema, testes unitários, embasamento factual)
  3. Escalar se falhar:
    • amostrar N candidatos
    • reordenar usando verificador
  4. Escalar novamente se ainda falhar:
    • adicionar busca (ramificação) ou uso mais profundo de ferramentas
    • adicionar loop de crítica–revisão
  5. Parar quando: sucesso verificado ou orçamento esgotado

Este é um dos padrões de computação em tempo de teste mais comuns no mundo real porque é amigável para engenharia e consciente de custos.

Aplicações práticas

1) Assistentes de programação: testes como verificadores

A computação em tempo de teste é extremamente eficaz para geração de código porque você consegue verificar saídas concretamente:

  • Rodar testes unitários
  • Verificação de tipos
  • Lint
  • Executar entradas de exemplo

Um padrão forte de produção é:

  • gerar múltiplos patches candidatos
  • rodar checagens no estilo CI
  • escolher o melhor patch
  • se todos falharem, pedir ao modelo para analisar falhas e tentar novamente

Isso se conecta a Modelos de Código.

2) Matemática e lógica: autoconsistência e checagem estruturada

Melhorias comuns com computação em tempo de teste:

  • votação por autoconsistência para respostas finais
  • checagens baseadas em ferramentas (calculadora, matemática simbólica)
  • impor representações intermediárias estruturadas (equações, restrições)

3) QA empresarial: recuperar + citar + checar cruzado

Para QA com muito conhecimento:

  • recuperar top-k documentos
  • responder com citações
  • checar cruzado se cada afirmação-chave é suportada por um trecho citado
  • opcionalmente pedir a um modelo verificador: “Há afirmações sem suporte?”

Isso reduz alucinações (veja Alucinações) e melhora a auditabilidade.

4) Agentes e fluxos de trabalho: loops planejar–agir–observar

Sistemas agênticos (agentic systems) naturalmente consomem mais computação em tempo de teste:

  • criar um plano
  • chamar ferramentas (busca, banco de dados, APIs)
  • observar resultados
  • atualizar o plano
  • repetir até a tarefa estar concluída

Aqui, a computação é gasta não apenas em tokens, mas em chamadas de ferramentas e loops de controle. Veja LLMs que Usam Ferramentas.

5) Segurança e conformidade de políticas: deliberação + filtragem

Alguns sistemas alocam computação em tempo de teste extra para checagens de segurança:

  • gerar resposta candidata
  • rodar classificador de políticas / modelo de segurança
  • revisar para conformidade
  • recusar se necessário

Isso se cruza com Mitigações de Segurança e Alinhamento.

Considerações de engenharia (o que importa em produção)

Latência, taxa de processamento e custo

A computação em tempo de teste aumenta um ou mais dos itens:

  • contagem de tokens
  • número de chamadas ao modelo
  • chamadas de ferramentas
  • chamadas ao verificador

Para gerenciar isso:

  • implementar computação adaptativa (escalonamento)
  • cachear resultados de recuperação/ferramentas
  • limitar profundidade/iterações máximas
  • usar modelos mais baratos para crítica ou reordenação quando possível

Confiabilidade: restrições determinísticas vencem julgamento de “estilo”

Se você pode verificar a correção mecanicamente (testes, esquemas, parsers), faça isso. Julgamento via LLM pode ser útil, mas é:

  • vulnerável a viés e sensibilidade a prompts
  • às vezes inconsistente entre execuções

Interação com a decodificação

Escolhas de decodificação podem determinar o sucesso ou fracasso da computação em tempo de teste:

  • Autoconsistência precisa de diversidade (temperatura/top-p não muito baixos).
  • Melhor-de-N se beneficia de candidatos significativamente diferentes.
  • Busca em feixe (beam search) pode ajudar na geração com restrições, mas pode reduzir diversidade em tarefas abertas.

Veja Estratégias de Decodificação.

Limites da janela de contexto

A computação em tempo de teste frequentemente aumenta o tamanho do prompt (evidências recuperadas, scratchpads, múltiplos candidatos). Você precisa gerenciar:

  • estratégias de truncamento
  • sumarização do estado intermediário
  • memória seletiva

Veja Janelas de Contexto.

Limitações e modos de falha

  • Computação não cria capacidade do nada. A computação em tempo de teste ajuda quando o modelo às vezes consegue resolver a tarefa, mas é inconsistente.
  • Raciocínio mais longo pode aumentar a área de superfície para alucinações se não for verificado.
  • Autocrítica não é garantida para encontrar erros reais. Modelos podem racionalizar respostas incorretas.
  • A qualidade do verificador é crítica. Um verificador fraco pode selecionar saídas erradas com alta confiança.
  • Riscos de segurança: uso de ferramentas e raciocínio em múltiplas etapas aumentam a superfície de ataque (injeção de prompt em texto recuperado, chamadas inseguras de ferramentas).
  • Retornos decrescentes: além de certo ponto, mais amostras ou rastros mais longos geram ganhos menores; estratégias compute-ótimas focam onde os ganhos são mais acentuados.

Relação com treinamento e “modelos de raciocínio” emergentes

A computação em tempo de teste funciona melhor quando modelos são treinados de formas que tornam o raciocínio estendido efetivo, como:

  • treinamento em soluções multi-etapas
  • aprendizado por reforço (reinforcement learning) que recompensa correção em horizontes longos
  • sinais supervisionados por processo (recompensando etapas intermediárias corretas)

Mesmo com esse treinamento, a computação em tempo de teste continua importante porque tarefas do mundo real variam amplamente em dificuldade, e inferência adaptativa é uma forma prática de alocar recursos.

Resumo

Computação em tempo de teste é a prática de gastar computação adicional em tempo de inferência para melhorar a qualidade da saída, especialmente para tarefas com muito raciocínio. Ela inclui deliberação mais longa, amostragem de múltiplos candidatos, busca sobre etapas intermediárias, verificação, uso de ferramentas e — crucialmente — políticas adaptativas que alocam computação com base na dificuldade.

Em sistemas modernos de LLMs, a computação em tempo de teste frequentemente é uma das formas de maior alavancagem para melhorar acurácia e robustez sem retreinamento, e serve como a ponte entre modelagem de linguagem bruta e raciocínio confiável, em nível de produção.