01Capítulo 1: O que é um LLM, sem mistério

Todo assistente de IA que você usa para programar, seja no chat, no terminal ou dentro do editor, tem a mesma peça no meio: um LLM (large language model, modelo de linguagem grande). Antes de configurar qualquer coisa, vale entender o que essa peça faz e, principalmente, o que ela não faz.

Ele prevê o próximo pedaço de texto

Um LLM recebe um texto e calcula, para cada pedaço possível, a chance de ele vir em seguida. Escolhe um, junta ao texto e repete. Uma resposta inteira é esse passo feito centenas ou milhares de vezes.

Parece pouco. Mas para prever bem o próximo pedaço de um código ou de uma explicação técnica, o modelo precisou aprender, no treino, muita coisa sobre linguagens, bibliotecas, padrões e sobre como as pessoas descrevem problemas. É daí que vem a utilidade. E é daí também que vêm os erros.

O deploy falhou porque___

• faltou–
• o–
• a–
• alguém–
• ninguém–
• choveu–

Temperatura

1,0

Sortear a próxima palavra

Nenhum sorteio ainda

Mexa na temperatura e sorteie algumas vezes. Com temperatura zero sai sempre a opção mais provável. Quanto mais alta, mais as opções improváveis ganham chance. É por isso que a mesma pergunta, feita duas vezes, pode ter respostas diferentes.

Tokens: a unidade de tudo

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, um sinal de pontuação ou um espaço. Palavras longas, acentuadas ou pouco comuns costumam virar vários tokens. Na figura acima cada opção é uma palavra inteira só para facilitar a leitura.

Isso importa por três motivos práticos:

• Preço. APIs cobram por token que entra e por token que sai.
• Limite. Cada modelo tem um teto de tokens por chamada, a janela de contexto.
• Velocidade. A resposta sai token por token. Resposta longa demora mais.

Ele não lembra de você

Um LLM não tem memória entre uma chamada e outra. Quando um chat parece lembrar o que você disse dez mensagens atrás, é porque o aplicativo reenvia a conversa inteira a cada mensagem nova. A memória é do app, não do modelo.

Consequência direta: se uma informação não está no texto enviado naquela chamada, para o modelo ela não existe. Ele não viu o seu repositório, não sabe qual versão do framework você usa e não leu o erro que apareceu no seu terminal, a menos que alguém coloque isso no contexto.

Por que ele inventa

O modelo não consulta uma base de fatos antes de responder. Ele gera o texto mais provável para aquele contexto. Quando o conhecimento necessário não estava no treino nem está no contexto, o texto mais provável continua sendo um texto plausível: um nome de função que parece certo, um parâmetro que deveria existir, uma versão de biblioteca que nunca saiu.

Isso tem nome, alucinação, e não é um defeito ocasional. É consequência de como a peça funciona.

Tem mais um detalhe: o conhecimento do modelo para numa data, a data de corte do treino. O que saiu depois disso ele não conhece, a não ser que você (ou uma ferramenta de busca) traga para o contexto. Em IA, onde tudo muda todo mês, isso pesa. Perguntar a um modelo como configurar a versão mais nova de uma ferramenta de IA é pedir para ele adivinhar. Foi por isso que as receitas do capítulo 5 foram conferidas na documentação oficial, com data.

O que isso muda no seu dia a dia

Pense no modelo como um colega muito rápido, que leu muita coisa, mas que acabou de chegar e nunca viu o seu projeto. Na prática:

1. Dê contexto. O erro completo, o trecho de código, a versão das dependências, o que você já tentou.
2. Peça o que dá para verificar. “Escreva um teste que reproduz o bug” rende mais que “tem bug aqui?”.
3. Desconfie de detalhes específicos. Nome de flag, parâmetro de API e número de versão são onde ele mais inventa.
4. Deixe ele conferir o próprio trabalho. Um modelo que pode rodar os testes e ler o resultado erra menos, porque corrige o próprio erro. É isso que as ferramentas (capítulo 3) e os agentes (capítulo 6) resolvem.

Antes disso, falta entender o que exatamente o modelo recebe em cada chamada.