O que entender sobre como LLMs funcionam muda na hora de construir com eles

Você não precisa implementar um transformer do zero para construir sistemas com LLMs. Mas existe um nível de compreensão dos fundamentos que muda o que você espera dos modelos, como você interpreta os erros, e o que você otimiza quando o sistema não está funcionando como deveria.

O Karpathy tem um vídeo de introdução a LLMs para audiência geral que cobre o pipeline completo de como esses modelos são construídos. O que me interessa aqui não é resumir o conteúdo técnico, mas extrair o que muda na prática quando você internaliza esses conceitos.

Predição de tokens é a operação fundamental

O modelo não "entende" texto. Ele prediz o próximo token com base nos tokens anteriores. Isso é tudo que acontece, em cada chamada, para cada geração. A aparência de compreensão, raciocínio, e instrução seguida é um emergente de fazer essa operação bem sobre enormes quantidades de texto.

O que isso muda na prática: quando você passa um contexto rico e específico para o modelo, você está dando a ele um histórico de tokens que torna a continuação natural mais próxima do que você quer. Quando o modelo "entende" a sua instrução, ele está na verdade encontrando o padrão de continuação mais plausível dado tudo que está no contexto.

Isso explica por que exemplos concretos no contexto funcionam tão bem (few-shot prompting). Você não está ensinando o modelo. Você está estabelecendo um padrão que ele vai continuar.

O pretraining comprime o internet nas weights

A primeira fase do treinamento é pretraining: o modelo é exposto a trilhões de tokens de texto, e os pesos são ajustados para minimizar a perda de predição ao longo de todo esse texto. O resultado é um modelo que "conhece" uma quantidade enorme de informação no sentido de que pode recuperar e combinar padrões que apareceram no texto de treinamento.

O problema é que esse conhecimento não tem estrutura de banco de dados. Você não pode perguntar "qual é o valor exato do campo X na tabela Y". O modelo vai gerar o que parece certo com base nos padrões que viu, mesmo quando não sabe. É a raiz de onde as alucinações vêm: o modelo não tem um mecanismo para dizer "não sei", então gera a continuação mais plausível, que pode estar errada.

Para sistemas em produção, isso tem uma implicação direta: você não pode confiar no modelo para recuperar fatos específicos da memória. Você precisa fornecer esses fatos no contexto e pedir ao modelo que raciocine sobre eles, não que os recupere da memória.

É exatamente o que o Athena faz: em vez de depender do modelo para "saber" a estrutura das tabelas do Protheus, injeto a estrutura relevante no contexto antes de cada geração. O modelo raciocina sobre o que recebeu, não sobre o que "sabe".

Instruction tuning e RLHF: o que transforma o modelo numa assistente

O modelo pré-treinado não é assistente. É um completador de texto sofisticado. A transformação para o comportamento de assistente acontece numa segunda fase: instruction tuning e RLHF (Reinforcement Learning from Human Feedback).

Nessa fase, o modelo aprende a responder instruções de uma forma que humanos avaliam como útil, inofensiva, e correta. O resultado é o modelo com o qual você interage quando usa o Claude ou o ChatGPT.

O que isso significa para quem constrói: o modelo foi treinado para ser cooperativo e prestativo. Ele vai tentar fazer o que você pede mesmo quando a instrução é ambígua. Isso é útil, mas também é onde ele pode ir na direção errada se o contexto não for suficientemente específico sobre o que você quer. O modelo vai preencher ambiguidade com o que parecer mais plausível, não necessariamente com o que você queria.

O que determina a qualidade de uma resposta

Quando uma resposta está ruim, há quatro lugares para procurar o problema:

O modelo base: capacidade de raciocínio, conhecimento de domínio geral, seguimento de instrução. Isso você não controla diretamente.

O contexto: o que você forneceu para o modelo trabalhar. Esse é o seu principal lever.

A instrução: como você formulou o que quer. Isso tem efeito, mas menor do que a maioria pensa.

As expectativas: você pode estar pedindo algo que o modelo não consegue fazer bem. Entender os limites reais economiza tempo de debugging em coisas que não têm solução dentro do modelo.

Quando o Athena gera uma query errada, a investigação começa sempre pelo contexto: o schema que foi injetado estava completo? As regras de negócio relevantes estavam presentes? Os exemplos de queries similares foram incluídos? Quase sempre o problema está no contexto, não no modelo.

Por que alucinações são sistemáticas, não aleatórias

Alucinações não são erros aleatórios. Elas aparecem em padrões previsíveis: quando o modelo foi treinado com pouca informação sobre um tópico específico, quando a pergunta exige recuperar fatos precisos sem que esses fatos estejam no contexto, quando a resposta esperada contraria padrões comuns no texto de treinamento.

Saber isso permite projetar sistemas que não dependem do modelo para coisas onde ele alucinará sistematicamente. Fatos específicos ficam no contexto. Valores precisos são validados depois da geração. Decisões críticas que dependem de informação específica têm verificação externa.

O que muda quando você entende os fundamentos não é que você passa a construir modelos. É que você para de atribuir os problemas ao lugar errado e começa a otimizar o que realmente importa.

Qual erro recorrente no seu sistema de LLM você atribuiu ao modelo antes de investigar o contexto?