AI Internals - Essenciais
Introdução
Construir com LLMs é fácil de começar e fácil de entender pela metade. Você cola um prompt numa API, recebe texto e publica um demo. Depois a recuperação falha, o custo sobe, um agent entra em loop, ou ninguém consegue dizer se o prompt novo é de fato melhor.
Este artigo é Essenciais: um mapa do terreno. Cada artigo seguinte faz um mergulho profundo em uma camada — como LLMs funcionam, prompts e contexto, embeddings e retrieval, RAG, tools e agents, orquestração, observabilidade e evals. O objetivo é o mesmo da série Go Internals: ligar comportamentos que você já vê no app à maquinaria por baixo, numa ordem que nivela o conhecimento antes das partes mais difíceis.
O que "AI internals" cobre de verdade
Quando alguém fala em "internals de AI" no sentido de aplicação, em geral são duas stacks que se encontram na fronteira da API:
- A stack do modelo — tokens, treino vs inferência, janelas de contexto, sampling. É o que transforma um prompt numa completion.
- A stack do app — prompts, retrieval, tools, frameworks de orquestração, tracing e evals. É o que transforma uma completion num produto.
Seu handler HTTP não é o sistema inteiro. O provedor roda a inferência; o seu código é dono de tudo ao redor: o que entra no contexto, o que é recuperado, quais tools podem disparar e como você mede se as respostas prestam.
A maior parte da série fica no lado do app desse diagrama, mas começamos com mecânica de modelo o bastante para os artigos seguintes não parecerem mágica. How LLMs Work é o primeiro mergulho profundo; Evals fecha o ciclo quando já existe algo que valha medir.
Roteiro da série
Um app com LLM não é um bloco só de "código de AI." São camadas que dependem umas das outras. Artigos posteriores assumem os anteriores; por isso a série é vertical, e não um único post gigante.
| Artigo | Camada | No que vamos aprofundar |
|---|---|---|
| Essenciais (este artigo) | Visão geral | Stack modelo vs app, caminho do request, como acompanhar |
| How LLMs Work | Modelo | Tokens, treino vs inferência, contexto, sampling |
| Prompts & Context | Superfície de controle | Messages, system prompts, structured output |
| Embeddings & Retrieval | Busca | Vetores, índices, similaridade antes do RAG |
| RAG | Grounding | Chunking, retrieval, grounding, modos de falha |
| Tools & Agents | Ações | Tool calling, loops de agent, quando não usar agent |
| Orchestration | Composição | LangChain / pipelines em grafo |
| Harness | Runtime de sessão | Transcript durável, compactação, retomada, sandbox |
| Observability | Produção | Traces no estilo Langfuse, custo, debugging |
| Evals | Qualidade | Medir se mudanças realmente ajudam |
Os exemplos desta série aparecem em Go, Python e TypeScript quando código ajuda. Use as abas de linguagem nesses blocos; a ideia é a mesma em cada idioma.
De um prompt a uma completion
Um request mínimo basta para ancorar o resto da série. Você envia messages (e depois tools ou docs recuperados); o provedor tokeniza a entrada, roda a inferência, amostra os próximos tokens e devolve texto.
Conceitualmente:
A mesma ideia como uma chamada mínima de cliente — não é código de produção, só o formato da fronteira a que vamos voltar:
package main
import (
"bytes"
"encoding/json"
"fmt"
"net/http"
"os"
)
func main() {
body, _ := json.Marshal(map[string]any{
"model": "gpt-4.1-mini",
"messages": []map[string]string{
{"role": "user", "content": "Say hello in one sentence."},
},
})
req, _ := http.NewRequest(
"POST",
"https://api.openai.com/v1/chat/completions",
bytes.NewReader(body),
)
req.Header.Set("Authorization", "Bearer "+os.Getenv("OPENAI_API_KEY"))
req.Header.Set("Content-Type", "application/json")
res, err := http.DefaultClient.Do(req)
if err != nil {
panic(err)
}
defer res.Body.Close()
fmt.Println(res.Status)
}Tudo o que vem depois na série — contexto de RAG, resultados de tools, passos de agent — ainda é esse loop: montar messages, chamar o modelo, ler a completion. A parte difícil é o que você coloca nas messages e como julga a saída.
Como acompanhar
Você não precisa treinar um modelo. Precisa de uma API key de provedor (ou um modelo local depois) e do hábito de rodar experimentos pequenos.
Hábitos úteis para os mergulhos:
- Prompts pequenos — um comportamento por experimento (temperature, tool choice, hit/miss de retrieval).
- Logar o request cru — messages, tool calls, chunks recuperados. Chutar pela UI perde tempo.
- Medir alguma coisa — até um checklist tosco bate feeling quando os prompts começam a multiplicar (Evals).
- Preferir uma linguagem nos drills — troque a aba quando quiser outro ecossistema; não reescreva cada exemplo três vezes na mão.
Não vamos tratar "pegar o framework da moda" como objetivo. Frameworks aparecem quando esclarecem composição (Orchestration) ou debugging em produção (Observability).
O que você já deve saber
Esta série é sobre sistemas ao redor de LLMs, não um tutorial de linguagem. Leitura confortável de:
- APIs HTTP e JSON
- padrões básicos de request async ou concorrente em pelo menos uma entre Go, Python ou TypeScript
- a ideia de que prompts são dados que você controla, não strings mágicas
basta. Se você já publicou qualquer backend que chama uma API de terceiro, está no lugar certo.
Conclusão
Essenciais define a rota: o modelo transforma tokens em texto; o seu app é dono de contexto, retrieval, tools e medição. Cada artigo seguinte isola uma camada.
O próximo é How LLMs Work — tokens, treino versus inferência, janelas de contexto e sampling, antes de subir para prompts e retrieval.