Capítulo 1 — A Disciplina da Engenharia de IA
Primeiro post do passeio capítulo a capítulo pelo LLM Primer V: Construindo Aplicações LLM Reais. O capítulo que sustenta que a razão de sua demo funcionar e seu sistema de produção não funcionar não é um problema de modelo — é um problema de engenharia, e a engenharia tem nome.
Por que este capítulo existe
Todo time que coloca uma funcionalidade LLM no ar descobre a mesma lacuna. A demo roda bem nas vinte entradas que o time escolheu; o sistema de produção roda mal nas vinte mil entradas que ele nunca viu. O modelo não piorou. O time saiu da região em que uma saída única plausível conta como sucesso e entrou na região de carga, drift, entradas adversariais e clientes pagantes cuja métrica de reclamação é implacável. O Capítulo 1 nomeia essa região e lhe dá uma disciplina. Engenharia de IA não é a ciência de treinar o modelo, e não é a prática de escrever um prompt engenhoso. É a engenharia de comportamento determinístico de sistema em torno de um núcleo probabilístico. O resto do livro é um passeio pelas superfícies onde essa disciplina vive; este capítulo é o enquadramento.
1.1 A lacuna de confiabilidade entre demo e produção
Uma demo e um sistema de produção parecem idênticos no diagrama de arquitetura. Diferem em carga, em distribuição de entrada de cauda, em orçamento de latência, em pressão de custo, e em modo de falha. A diferença dominante é estatística: uma demo roda algumas dezenas de entradas escolhidas a dedo, enquanto um sistema de produção roda milhões contra a cauda longa — as consultas com fraseado estranho, parcialmente em outra língua, sem contexto, ou intencionalmente adversariais. Confiabilidade é uma pergunta sobre caudas, não sobre médias. Somado a isso, o próprio modelo é não-determinístico — amostragem, balanceamento de carga do lado do provedor, e atualizações silenciosas de modelo se acumulam — e as falhas são silenciosas. Uma resposta errada faz parse limpo, satisfaz cada verificação de tipo que o time escreveu, e chega ao usuário sem alerta. A observabilidade clássica, que conta HTTP 200s, não consegue enxergar esse modo de falha. O primeiro movimento do time é reconhecer que repetibilidade, correção e custo são propriedades de engenharia a serem construídas, não hipóteses herdadas da pilha clássica.
1.2 O wrapper determinístico ao redor do núcleo probabilístico
A resposta arquitetural é deixar o modelo probabilístico e envolvê-lo em software clássico. O wrapper é dono de formato de entrada, formato de saída, validação, retries, fallbacks, cache, observabilidade e contabilidade de custo. De fora, apresenta uma função determinística — chega uma requisição, sai uma resposta validada. Por dentro, contém um componente probabilístico que é chamado com timeout, schema, e um plano de recuperação para o caso em que o modelo devolve lixo. O wrapper tem quatro faixas: validação de entrada, preparação de prompt, execução sob contrato, e recuperação e emissão. Só depois de passar pelas quatro a resposta se torna a saída oficial do wrapper. A tentação recorrente é empurrar lógica de volta para dentro do modelo — "deixa o modelo verificar a própria resposta" — e cada passo nessa direção é um passo para longe da testabilidade. A disciplina é manter o núcleo probabilístico pequeno, bem definido e contido, e manter o máximo possível do comportamento do sistema em código determinístico que o time pode versionar e sobre o qual pode raciocinar.
1.3 Os cinco pilares: confiabilidade, qualidade, performance, custo, evolução
O Capítulo 1 percorre cinco posturas de engenharia que se repetem em todo sistema de produção. Confiabilidade vem de redundância: retries com backoff exponencial, cadeias de fallback que vão de um primário barato para um secundário mais forte para um default baseado em regras, abstração multi-provedor, e circuit breakers que impedem um provedor em dificuldades de cascatear. Qualidade vem de validação, em duas camadas: validação de schema pega erros de formato, e validação de conteúdo — checagens de groundedness, pisos de confiança, checagens de guardrail — pega erros semânticos que passam pelo schema. Performance vem de cache, em três camadas: exact-match, semântico, e prefix de prompt. Controle de custo vem de medição e atribuição, de roteamento de tráfego para o menor modelo que basta, de orçamentos por usuário e por requisição que impedem um loop de agente de gastar mil dólares em silêncio, e de economia de prompt. Evolução vem dos cinco loops de feedback — logging, avaliação, tracing, feedback humano e rollout canário — conectados num circuito em que um trace de produção vira caso de eval, uma regressão de eval bloqueia um deploy, e o sistema melhora mês a mês.
O que o Capítulo 1 prepara
O resto do livro é o wrapper, uma camada de cada vez. O Capítulo 2 entra dentro da própria chamada de modelo — tier de modelo, parâmetros de amostragem, prompts defensivos e saídas estruturadas. O Capítulo 3 se expande para fora, para a recuperação, para que o modelo tenha o contexto certo sobre o qual raciocinar. O Capítulo 4 transforma o wrapper num agente que pode chamar ferramentas. Os Capítulos 5 e 6 acrescentam os trilhos de avaliação e observabilidade. Os Capítulos 7 e 8 fecham com segurança e economia de serving. O enquadramento do Capítulo 1 é o que torna cada capítulo seguinte legível: toda técnica é ou um jeito de apertar o wrapper ou um jeito de tornar o núcleo probabilístico dentro dele mais fácil de envolver.
Próximo — Capítulo 2: Modelos de Fundação e Engenharia de Prompt. A camada dentro do wrapper — seleção de modelo, amostragem, prompts e saídas estruturadas — tratada como superfície de engenharia, não como arte.
