Capítulo 2 — Modelos de Fundação e Engenharia de Prompt

Segundo post do passeio capítulo a capítulo pelo LLM Primer V: Construindo Aplicações LLM Reais. O capítulo que trata engenharia de prompt como engenharia — templates versionados, delimitadores defensivos e saídas estruturadas — em vez de arte julgada por sensação.

Por que este capítulo existe

O Capítulo 1 sustentou que o modelo é um componente dentro de um wrapper determinístico. O Capítulo 2 olha com cuidado para esse componente. O catálogo de modelos em 2026 é uma taxonomia com distinções nítidas, não uma lista de equivalentes. Parâmetros de amostragem transformam os mesmos pesos num classificador determinístico ou num escritor criativo. Prompts são artefatos estruturados cuja anatomia é a diferença entre sobreviver a entradas adversariais e não sobreviver. Existem mecanismos para forçar a saída em um formato que o wrapper consegue validar, e escolher o errado para a tarefa custa mais em retries de validação do que o mecanismo economizou. Um time que trata "o modelo" como recurso anônimo único, usa os defaults em todo lugar, escreve prompts como strings descartáveis, e valida a saída na esperança — esse time deixou a maior parte do controle de engenharia disponível no chão.

2.1 Seleção de modelo como decisão de engenharia de primeira classe

O catálogo se divide em quatro famílias: modelos de linguagem pequenos (SLMs) sintonizados para velocidade e custo em tarefas delimitadas; modelos gerais de tier médio que dão conta da maioria das cargas de produção; modelos de fronteira para o raciocínio mais difícil e os contextos mais longos; e modelos de raciocínio que gastam compute adicional numa etapa oculta de deliberação. Multimodalidade atravessa os quatro. A seleção é uma decisão de roteamento por requisição, não um default global: consultas curtas para o SLM, tarefas não triviais mas bem delimitadas para o tier médio, o raciocínio mais difícil para o de fronteira, modelos de raciocínio onde a latência é aceitável e o ganho de acurácia é real. O roteador registra sua decisão junto com a resposta, para que uma regressão possa ser filtrada por tier. A seleção também não é uma decisão única no tempo — o cenário de modelos muda mais rápido do que qualquer outra infraestrutura da qual o time depende, e a disciplina é rodar o conjunto de avaliação trimestralmente e migrar quando as evidências apoiam.

2.2 Amostragem como perfil deliberado

Temperatura escala a distribuição de tokens antes da amostragem; top-p trunca no núcleo acima de um limiar de probabilidade; min-p filtra tokens muito abaixo do topo; o seed oferece repetibilidade em regime de melhor esforço. Os dois perfis que valem nomear explicitamente são o perfil determinístico — temperatura zero, top-p 1.0, seed fixado — para classificação, extração e roteamento, cujo contrato é "mesma entrada, mesma saída"; e o perfil criativo — temperatura por volta de 0.8, top-p 0.95 — para geração em que variação é o produto. Misturar os dois por descuido, usar o default temperatura 0.7 numa tarefa de classificação, produz a classe de testes intermitentes e falhas esporádicas que os times culpam o modelo quando a responsabilidade é a escolha do parâmetro. Streaming é ortogonal à amostragem: os mesmos parâmetros se aplicam, o transporte muda, e o tempo até o primeiro token substitui a latência total como métrica de velocidade percebida.

2.3 Prompts defensivos e saídas estruturadas

Um prompt de produção tem uma anatomia em cinco partes — papel, tarefa, restrições, exemplos, entrada delimitada — e a ordem importa porque a atenção do modelo a cada componente é influenciada pelo que vem antes. Entrada delimitada, ancorada dos dois lados com o lembrete de que o conteúdo entre os marcadores é dado e não instrução, é o piso abaixo do qual um prompt não deveria cair. Prompts são artefatos de código versionados; um nome como prompts/classify_support_v3, registrado em cada trace, é como uma regressão é rastreada até a mudança que a causou. Saídas estruturadas — Pydantic em Python, Zod em TypeScript, passadas ao provedor como schema de resposta — impõem o formato da saída em tempo de decodificação. A imposição de JSON Schema do lado do provedor remove uma classe inteira de falhas de validação. Onde JSON Schema não é expressivo o suficiente — SQL, formatos com regex, argumentos de ferramenta contra um catálogo fechado — a decodificação restrita por gramática via Outlines dá a mesma garantia no nível do token.

O que o Capítulo 2 prepara

O Capítulo 2 assumiu que o que quer que o prompt contenha é suficiente para a tarefa. Para muitas tarefas — classificação, extração, transformação — essa hipótese se sustenta. Para a maior parte dos sistemas de produção voltados ao usuário ela falha, porque o usuário está perguntando sobre fatos que o time possui e que o modelo nunca viu: documentos internos, a política desta semana, o histórico de pedidos do cliente. O movimento de engenharia que fecha essa lacuna é a geração aumentada por recuperação. O Capítulo 3 percorre o pipeline RAG de ponta a ponta — carregamento, chunking, embedding, recuperação, geração — e depois as técnicas que separam um pipeline de demo de um de produção: recuperação híbrida, chunking consciente de estrutura, e transformações de consulta como HyDE e step-back.

Próximo — Capítulo 3: Geração Aumentada por Recuperação. O pipeline que dá ao modelo o contexto que os dados de treinamento nunca cobriram — de ponta a ponta, do loader ao gerador.