Como LLMs raciocinam de verdade (e por que não são bancos de dados)
A maioria dos projetos de IA que fracassa em produção falha por um motivo simples: o time trata o LLM como banco de dados. Espera respostas determinísticas, exatas, sempre iguais para a mesma pergunta. Essa expectativa errada gera decisões de arquitetura erradas. Entender como LLMs de fato funcionam — probabilisticamente, token a token — muda tudo: como você escreve prompts, como projeta fallbacks, como mede qualidade.
O que é um token (e por que importa)
LLM não lê palavras — lê tokens. Token é uma unidade de texto que pode ser uma palavra, parte de palavra, pontuação ou espaço. Em PT-BR, regra prática: 1 palavra ≈ 1,3 tokens.
Por que isso importa para decisões de produto?
- Custo é cobrado por token (entrada + saída).
- Janela de contexto é limitada em tokens, não em palavras.
- Velocidade depende do número de tokens gerados por segundo.
Geração probabilística: o mecanismo real
A cada passo, o modelo recebe todos os tokens anteriores e produz uma distribuição de probabilidade sobre o vocabulário inteiro (~100 mil tokens). O próximo token é amostrado dessa distribuição.
Exemplo simplificado para a frase "A capital do Brasil é":
| Candidato | P aproximada |
|---|---|
| Brasília | 94% |
| São Paulo | 3% |
| Rio | 2% |
| outros | 1% |
Na maioria das vezes, o modelo acerta. Mas quando o contexto é ambíguo, o corpus de treino é escasso no domínio, ou a pergunta é nova — a distribuição se achata e o modelo pode amostrar um token plausível mas errado. Isso é alucinação pelo ângulo técnico.
Temperature: o controle da aleatoriedade
Antes de amostrar, o modelo pode ajustar a distribuição via temperature:
- Temperature 0 → sempre escolhe o token de maior probabilidade (greedy). Determinístico, previsível.
- Temperature 0.3–0.7 → levemente aleatório. Bom para código, SQL, extração.
- Temperature 1.0+ → distribuição achatada, mais surpresas. Bom para criação, brainstorming.
Por que não é banco de dados
Banco de dados: dado de entrada → busca exata → resultado determinístico.
LLM: prompt de entrada → geração probabilística → resultado estocástico que parece uma busca mas não é.
Consequências práticas que vejo em projetos:
| Expectativa (banco de dados) | Realidade (LLM) |
|---|---|
| Mesma pergunta → mesma resposta | Pode variar com temperature > 0 |
| Data/hora atual é conhecida | Não — data de treino é o limite |
| Não inventa dados | Pode inventar com aparência de verdade |
| Resultado auditável por chave | Não há "onde" está a resposta |
| Preciso sobre números exatos | Erra cálculos sem ferramenta |
O que isso muda na arquitetura
- Precisão factual? → Use RAG com fontes verificáveis. Não confie no LLM isolado.
- Cálculo/lógica determinística? → Dê uma ferramenta (MCP / tool calling). Calculadora, SQL, Python.
- Saída deve ser sempre igual? → Temperature 0 + validação de schema (JSON Schema, Pydantic).
- Domínio específico e raro? → Base RAG curada no domínio + contexto de sistema rico. Fine-tuning só se RAG não resolver.
- Ação irreversível? → Human-in-the-loop obrigatório. LLM decide; humano confirma.
Checklist: você está tratando o LLM como BD?
- [ ] Você espera que o LLM "lembre" dados específicos sem passar no prompt?
- [ ] Você usa o LLM para cálculos matemáticos sem ferramenta de cálculo?
- [ ] Você não valida schema da saída antes de usar como JSON/SQL?
- [ ] Você não tem fallback quando a resposta é incoerente?
- [ ] Você executa ações críticas com base na saída do LLM sem revisão?
Cada "sim" é uma bomba-relógio em produção.
Erros comuns
- "Vou perguntar ao LLM o preço atual do dólar." — Não há dados em tempo real no modelo. Use API de câmbio + ferramenta.
- "O modelo errou porque é ruim." — Geralmente o contexto era insuficiente ou o domínio estava fora do treino.
- "Mais prompt = mais inteligência." — Mais tokens no contexto aumenta custo e pode acionar "lost in the middle". Contexto cirúrgico é melhor.
Conclusão
LLMs não "sabem" — eles "preveem com alta fidelidade estatística". Essa distinção sutil tem consequências arquiteturais enormes. Times que internalizam isso projetam sistemas resilientes. Times que não internalizam descobrem tarde — geralmente num incidente em produção.
Se quiser revisar a arquitetura do seu projeto à luz desses princípios, o diagnóstico inicial é gratuito.