Parâmetros de LLMs: temperatura, max_tokens e top_p explicados

Já tem mais de cinco anos que trabalho integrando LLMs em sistemas reais — chatbots, geradores de copy, pipelines de RAG, classificadores de intenção. E se tem uma coisa que vejo time após time: devs achando que o modelo “não presta”, quando o problema nunca foi o modelo. Eram dois parâmetros esquecidos, escondidos atrás do botão “Enviar”.

Segundo o Xataka.com.br, existem duas configurações invisíveis que determinam se a sua IA acerta ou sai dos trilhos: temperatura e extensão da resposta. A reportagem está certa — mas fica curta. Vou mostrar como esses controles realmente funcionam por baixo do capô, o que mais existe escondido na API, e como simular tudo isso direto no prompt quando você não tem acesso à API.

O que acontece quando você aperta “Enter”

Antes de ajustar qualquer parâmetro, precisa entender o que o modelo faz quando você envia uma mensagem. LLMs não “sabem” respostas. Eles calculam, token por token, a próxima opção mais provável dado o contexto anterior. Cada token sai de uma distribuição de probabilidade — e essa distribuição pode ser moldada.

É aqui que entram os parâmetros. Eles não mudam o “conhecimento” do modelo. Mudam o comportamento da amostragem — ou seja, como o motor escolhe, dentro daquela distribuição, qual token vai virar texto.

Temperatura: o termômetro da criatividade

A temperatura é um escalar (geralmente entre 0 e 2) que reescala as probabilidades antes da amostragem. Em valores baixos (próximo de 0), a distribuição fica “pontiaguda” — o token de maior probabilidade domina. Em valores altos, a distribuição fica “achatada” — tokens improváveis ganham chance.

Na prática:

• Temperatura 0.0 a 0.3 → respostas determinísticas, conservadoras. Bom para extração de dados, classificação, tradução técnica, geração de SQL.
• Temperatura 0.4 a 0.7 → equilíbrio. Bom para conversação geral, resumos, explicações.
• Temperatura 0.8 a 1.2 → criatividade, variações, brainstorming, copy.
• Temperatura > 1.2 → caos. Pode até ser útil em poesia ou jogos de RPG narrativos, mas em produção quase sempre é tiro no pé.

Um detalhe que pouca gente comenta: muitos provedores (incluindo a OpenAI, a partir de versões mais recentes) já implementaram caching automático de prompts. Quando você define temperature=0, o sistema pode cachear a resposta — mesma pergunta, mesma resposta, latência menor e custo zero em reuso. Isso muda completamente a conta de ROI em produção.

Extensão da resposta: quanto falar?

O segundo parâmetro, max_tokens (ou max_output_tokens), limita o tamanho da saída. Não é a mesma coisa que “tamanho da resposta” — é o número máximo de tokens que o modelo pode emitir antes de ser forçado a parar.

Por que isso importa? Três razões reais que vejo no dia a dia:

1. Custo. Você paga por token gerado. Cortar a verbosidade desnecessária é a forma mais rápida de reduzir a fatura.
2. Latência. Respostas longas demoram mais. Em chatbots de atendimento, isso é UX pura.
3. Foco. Um teto baixo força o modelo a ser conciso. Às vezes, pedir 500 tokens gera mais qualidade do que pedir 2000.

Outros parâmetros que quase ninguém ajusta

A Xataka cita apenas dois, mas a API expõe mais controles importantes que devs deixam de lado:

top_p (nucleus sampling): em vez de olhar todos os tokens possíveis, o modelo considera apenas o menor conjunto cuja soma de probabilidades atinge p. top_p=0.9 é um valor comum — descarta os 10% mais improváveis. Pode ser combinado com a temperatura.

frequency_penalty e presence_penalty: ambos penalizam repetição. frequency_penalty reduz a chance de tokens que já apareceram proporcionalmente à frequência. presence_penalty só incentiva novos tópicos depois que um token apareceu. Em copywriting, presence_penalty entre 0.3 e 0.6 costuma gerar textos menos repetitivos.

stop sequences: strings que, quando geradas, fazem o modelo parar. Use para impedir que o chatbot invente um “Usuário:” logo depois da resposta — clássico bug que vejo em produção pelo menos uma vez por mês.

Na Prática: controlando via prompt

A reportagem menciona que esses parâmetros não são acessíveis na interface padrão. Verdade. Mas dá para simular com prompt. Testei isso em produção e funciona surpreendentemente bem:

Você é um assistente técnico.
Responda em no máximo 3 frases curtas.
Seja literal e objetivo, sem floreios ou cumprimentos.
Use apenas termos técnicos. Sem analogias.
Se não souber, diga "não sei" em vez de inventar.

Esse prompt sozinho simula temperatura baixa + extensão curta. Para o oposto:

Você é um redator criativo sênior.
Gere 5 variações diferentes de headline.
Seja ousado, use metáforas inesperadas e jogos de palavras.
Mantenha cada variação entre 8 e 14 palavras.

Aqui, sem perceber, você está pedindo alta temperatura + extensão delimitada. Mas a simulação tem limite: você não consegue, via prompt, forçar determinismo absoluto nem controlar repetição com a mesma precisão da API. Para tarefas críticas, prompt sozinho não basta.

Código funcional: ajustando via API

Quando você controla a API, tem poder total. Exemplo em Python com a SDK oficial da OpenAI:

from openai import OpenAI

client = OpenAI()

# Caso 1: extração de dados estruturados (baixa temperatura)
def extrair_dados(texto: str) -> dict:
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        temperature=0.0,           # determinístico
        max_tokens=300,            # resposta curta
        response_format={"type": "json_object"},
        messages=[
            {"role": "system", "content": "Extraia nome, e-mail e telefone em JSON."},
            {"role": "user", "content": texto}
        ]
    )
    return response.choices[0].message.content

# Caso 2: copy criativo (alta temperatura + penalidade de repetição)
def gerar_copy(produto: str) -> str:
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        temperature=0.9,
        max_tokens=150,
        top_p=0.95,
        frequency_penalty=0.4,     # evita repetir palavras
        presence_penalty=0.3,      # incentiva novos tópicos
        stop=["\n\n"],             # para no primeiro parágrafo
        messages=[
            {"role": "user", "content": f"Crie uma headline curta para: {produto}"}
        ]
    )
    return response.choices[0].message.content

Repare nos detalhes: no caso 1, response_format força JSON — combinado com temperatura 0, dá parse previsível sem precisar de regex defensiva. No caso 2, stop=["\n\n"] impede o modelo de inventar cinco headlines em vez de uma. Pequenos detalhes assim são o que separa código de produção de código de demo.

Erros Comuns

1. Temperatura alta em extração de dados. Já vi sistema em produção extraindo CNPJ errado porque alguém deixou temperature=0.7 “porque o modelo parecia travado”. Para tarefas determinísticas, sempre abaixo de 0.2.

2. max_tokens generoso demais “por segurança”. Se você pede 4000 tokens em uma função que retorna um JSON de 200, está pagando 20x a mais e esperando 20x mais.

3. Achar que o prompt substitui tudo. Não substitui. Prompt engineering é um filtro semântico; controle de amostragem é matemático. Em produção séria, use os dois, em camadas.

4. Ignorar top_p ao mesmo tempo que ajusta temperatura. O comportamento fica imprevisível. A OpenAI recomenda ajustar um ou outro, não os dois ao mesmo tempo. Misturar sem entender é receita para inconsistência.

5. Não testar em escala. Uma resposta em 0.2 parece “boa”. Cem respostas em 0.2 expõem variação estatística. Rode sempre um batch de avaliação antes de colocar em produção.

6. Esquecer do cache. Chamadas idênticas com temperature=0 podem (e devem) ser cacheadas. Não configurar cache quando dá pra cachear é desperdiçar dinheiro todos os dias.

Tabela de referência rápida

FAQ

Qual a temperatura ideal para geração de código?
Para geração de código em produção, recomendo entre 0 e 0.2. Para autocomplete estilo Copilot, 0.1 a 0.3 funciona bem. Acima disso, o modelo começa a inventar sintaxe ou imports que não existem — e você vai descobrir isso só na hora do build.

Temperatura 0 garante 100% de determinismo?
Quase. Na prática, pode haver variação residual por questões de paralelismo interno do modelo e versões de hardware entre regiões. Para determinismo absoluto em sistemas críticos, valide em batch e considere rodar sempre no mesmo endpoint.

max_tokens maior deixa a IA “mais inteligente”?
Não. Limites maiores apenas dão espaço para a resposta ser maior. Inteligência está no modelo, no prompt e na qualidade dos dados de entrada. Aumentar max_tokens só aumenta custo.

Posso ajustar top_p junto com temperature?
Tecnicamente sim, mas não recomendo. A OpenAI e a Anthropic sugerem usar um OU outro. A combinação gera comportamentos difíceis de prever e mais difíceis ainda de debugar.

E em modelos locais como Ollama ou LM Studio?
Mesma lógica. Você tem acesso a temperature, top_p, top_k e repeat_penalty. Em modelos como Llama 3 e Mistral, repeat_penalty entre 1.05 e 1.1 faz o papel de frequency_penalty.

Veredicto

A Xataka tocou no ponto: temperatura e extensão são os dois parâmetros que mais importam para o resultado final. Mas eles não são os únicos. Em qualquer projeto real, você vai querer dominar pelo menos top_p, as penalidades e as stop sequences.

A diferença entre um sistema de IA “mais ou menos” e um sistema de IA confiável está, na maioria das vezes, nesses controles invisíveis. Não no modelo. Não no prompt. Não na marca do provedor.

Configure, meça, padronize. É isso que separa hobby de produção.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.