Como um LLM funciona, explicado para quem programa

Quem programa está acostumado com sistemas que fazem exatamente o que o código manda. Uma consulta ao banco devolve as mesmas linhas toda vez; uma função pura devolve o mesmo resultado para a mesma entrada. Um modelo de linguagem não funciona assim, e a maior parte da frustração de quem começa a usar IA no trabalho vem de tratar o modelo como se fosse um banco de dados que fala.

Este é o primeiro artigo da trilha Aprenda IA construindo software. A ideia não é explicar a matemática, e sim os quatro ou cinco conceitos que mudam decisões de código: o que é um token, o que cabe na janela de contexto, o que a temperatura controla, por que a API não lembra de nada e por que o modelo inventa. Os exemplos vêm do Porto, o assistente deste site, que está em produção.

O modelo prevê o próximo pedaço de texto

Um LLM (large language model) é treinado com uma quantidade enorme de texto para uma tarefa simples de descrever: dado um trecho, prever qual pedaço vem a seguir. Na hora de responder, ele repete isso em loop. Prevê um pedaço, acrescenta ao texto, prevê o próximo, até chegar a um ponto de parada ou ao limite de tamanho que você definiu.

Daí sai a primeira consequência prática: a resposta é a continuação mais plausível, não a mais verdadeira. Na maior parte do tempo as duas coincidem, porque o texto de treino tem muita informação correta. Quando não coincidem, o modelo produz uma frase com a mesma fluência e a mesma confiança de uma resposta certa. Não há um campo de erro, não há exceção lançada.

Token: a unidade que você paga e que ocupa espaço

O modelo não lê letras nem palavras inteiras. Ele lê tokens, pedaços de texto que podem ser uma palavra curta, parte de uma palavra longa, um sinal de pontuação ou um espaço. Palavras comuns em inglês costumam virar um token só; em português, com acentos e flexões, a mesma ideia tende a gastar mais tokens. Código também é quebrado em tokens, e identificadores longos e indentação contam.

Token importa por três motivos, todos de engenharia:

• Custo: a cobrança das APIs é por token de entrada e por token de saída, com preços diferentes para cada um. Tudo o que você manda conta, inclusive o prompt de sistema e o histórico da conversa.
• Espaço: a janela de contexto é medida em tokens, não em caracteres nem em mensagens.
• Tempo: a resposta é gerada token a token. Uma resposta longa demora mais, e por isso as APIs oferecem streaming.

Janela de contexto: tudo o que o modelo vê de uma vez

A janela de contexto é o tamanho máximo, em tokens, de tudo o que entra numa chamada: instruções, histórico, documentos colados e a própria resposta. Os modelos atuais têm janelas grandes, na casa das centenas de milhares de tokens, mas grande não é infinito, e encher a janela tem preço e piora a atenção do modelo ao que importa.

O ponto que mais surpreende quem integra a API pela primeira vez: a API não guarda conversa. Cada chamada é independente. Se o usuário fez cinco perguntas, a sexta chamada precisa reenviar as cinco perguntas e as cinco respostas, senão o modelo não sabe do que se está falando. A sensação de memória num chat é o seu código mandando tudo de novo a cada vez.

Isso tem efeito direto no custo: numa conversa longa, cada mensagem nova é mais cara que a anterior, porque carrega todas as anteriores. É por isso que um assistente em produção precisa de um limite de histórico.

Temperatura: quanto o modelo arrisca na escolha

A cada passo o modelo calcula uma probabilidade para cada token possível. A temperatura controla quanto ele se afasta da opção mais provável. Temperatura baixa deixa a saída mais previsível e repetitiva; temperatura alta deixa mais variada. Na API da Anthropic o valor vai de 0 a 1 e o padrão é 1.

Duas ressalvas que evitam decisões erradas:

• Temperatura 0 reduz a variação, mas não transforma o modelo numa função determinística garantida, e não torna a resposta mais correta. Um fato inventado com temperatura baixa continua inventado, só que de forma mais consistente.
• Para extração de dados, classificação e respostas com formato fixo, temperatura baixa ajuda. Para redação e ideias, o padrão costuma ser melhor.

Por que o modelo inventa, e por que isso não é bug

A resposta inventada, chamada de alucinação, é consequência direta de prever texto plausível. Se você pergunta por uma função de uma biblioteca e o modelo não tem essa informação, a continuação mais plausível de uma pergunta técnica é uma resposta técnica com cara de certa. Ele não consulta uma lista do que existe; ele gera o que costuma aparecer depois de perguntas parecidas.

Três situações aumentam muito a chance de invenção: perguntas sobre coisas depois da data de corte do treino, detalhes muito específicos (número de versão, nome exato de parâmetro, URL) e perguntas sobre o seu sistema, que o modelo nunca viu. A defesa não é pedir para o modelo não inventar; é dar a informação certa dentro do contexto, o que se chama de grounding, e conferir o que importa. O artigo Fontes confiáveis para IA corporativa trata desse cuidado do lado do processo.

Como fizemos aqui: os números do Porto

O Porto, assistente do canto da tela deste site, é uma integração direta com a API da Anthropic em Java e Spring Boot, detalhada no artigo Chamando a API de um LLM em Java e Spring Boot. Cada conceito acima virou uma decisão concreta no código:

private static final String MODEL = "claude-haiku-4-5-20251001";
private static final int MAX_TOKENS = 1024;

public record PortoChatRequest(
        @NotEmpty @Size(max = 20) List<@Valid PortoChatMessageDto> messages
) {}

public record PortoChatMessageDto(
        @NotBlank @Pattern(regexp = "user|assistant") String role,
        @NotBlank @Size(max = 2000) String content
) {}

• Histórico limitado: como a API não guarda conversa, o navegador manda o histórico a cada pergunta. O backend aceita no máximo 20 mensagens de até 2.000 caracteres. Sem esse limite, uma conversa longa encareceria cada resposta e alguém poderia colar um livro inteiro no chat.
• Saída limitada: max_tokens em 1.024. O prompt de sistema também pede respostas de três ou quatro parágrafos curtos. O limite técnico corta; a instrução evita que precise cortar.
• Temperatura no padrão: o Porto não define temperatura, então usa 1. É uma conversa de orientação, não extração de dados, e variedade de redação não atrapalha.
• Modelo pequeno: a tarefa é indicar conteúdo do site e explicar termos. Um modelo menor responde mais rápido e custa menos, e para esse uso a diferença de qualidade não justificava o maior.

E há uma limitação que o próprio Porto ilustra. O prompt de sistema diz: nunca invente artigo, hub, material, preço ou funcionalidade que você não tem certeza que existe. Essa regra reduz o problema, mas não o elimina, porque o Porto não recebe a lista de artigos do site. Ele conhece o portal pela descrição no prompt. A solução de verdade é dar a ele uma ferramenta de busca nos artigos publicados, o assunto do artigo Tool use e MCP desta trilha.

O que muda no seu código

1. Trate a resposta como entrada de usuário. Valide formato, tamanho e conteúdo antes de usar. Se pediu JSON, faça o parse com tratamento de erro.
2. Limite o que entra. Histórico, tamanho de mensagem e documentos colados precisam de teto, por custo e por qualidade.
3. Coloque a informação no contexto em vez de esperar que o modelo saiba. Dados do seu sistema, versão da biblioteca, regra de negócio: mande junto.
4. Escolha a temperatura pela tarefa. Baixa para extrair e classificar, padrão para redigir.
5. Meça tokens. As respostas da API informam quantos tokens entraram e saíram. Registre isso em log desde o primeiro dia.

Checklist

• Sei que a API não guarda conversa e que o histórico é reenviado a cada chamada.
• Defini limite de histórico, de tamanho de mensagem e de max_tokens.
• Escolhi a temperatura pela tarefa, sem esperar que ela corrija fatos.
• Dados específicos do meu sistema vão no contexto, não ficam por conta do modelo.
• A saída é validada antes de ser usada ou exibida.
• Registro tokens de entrada e saída para acompanhar custo.

Próximo passo da trilha: Prompt para desenvolvedores: do pedido solto à instrução com critério.