Automatizando prompts: LangChain, DSPy e pipelines

Você tem uma biblioteca de prompts que funciona. Sabe avaliar. Mas tem um problema: toda vez que você quer testar uma variação de prompt, é manual. Toda vez que o modelo base muda (Claude 4 → Claude 4.5, GPT-4 → GPT-4o), é manual. Toda vez que você quer rodar 50 variantes com few-shot diferente, é manual.

Frameworks de prompt engineering automatizam isso. Vamos ver o que existe, o que cada um resolve, e quando usar.

O mapa dos frameworks em 2026

Carregando diagrama...

DSPy: o estado da arte em 2026

DSPy é o framework que compila programas de prompt. Você define a tarefa em código, dá exemplos, e o DSPy encontra o prompt + few-shot + modelo que maximiza a métrica que você definiu.

A analogia: lembra quando a gente passou de "escrever CSS na mão" pra "usar Tailwind e um framework de componentes"? DSPy faz a mesma coisa com prompts. Você não escreve "instrução + few-shot" - declara a função que quer e os exemplos, e o framework otimiza.

Quando usar:

• Você tem golden set decente (30+ exemplos).
• Você quer maximizar uma métrica, não "ficar bom o suficiente".
• O prompt atual já está funcionando e você quer escalar.

Quando não usar:

• Prototipagem rápida de 1 fluxo. Overhead não compensa.
• Tarefa com 2-3 prompts simples. YAGNI.
• Sem golden set. Você precisa de sinal de qualidade pra otimizar.

LangChain: o ecossistema mais largo

LangChain é a plataforma mais usada pra protótipos. Integra com centenas de providers, vector stores, document loaders, tools. Se você quer fazer "RAG + agent + memória + API + ..." rápido, é o caminho.

Pontos fortes:

• Ecossistema enorme. Quase todo tutorial/integração tem exemplo LangChain.
• LangSmith (debugging e tracing de prompts) - útil pra ver o que o modelo está gerando em cada etapa.
• LangGraph (orquestração de agentes) - vira o padrão pra multi-agent.

Pontos fracos:

• Opinativo, abstrai demais. Debugging fica difícil.
• Performance sub-ótima pra alta escala (overhead de abstração).
• Mudança rápida de API. Versão 0.x muda breaking changes com frequência.

Regra prática: use LangChain pra protótipo, avalie se vira produção. Se for, considere reescrever em código mais explícito (ou migrar pra DSPy).

Guidance / Outlines: controle fino

Guidance e Outlines permitem controlar a geração no nível de token - regex, gramática, JSON schema, escolha múltipla. Úteis quando structured output não basta e você precisa garantir um formato exato.

Quando usar:

• Saída precisa seguir gramática complexa (DSL, SQL, expressão regular custom).
• Você quer forçar o modelo a escolher entre opções discretas em vez de "tende a".

dotprompt: o simples

dotprompt é o template engine da Google. Arquivo .prompt com frontmatter YAML, variáveis, e o prompt em si. Integra com Firebase/Gemini mas também roda standalone.

Quando usar:

• Você quer uma forma simples de versionar prompts sem framework pesado.
• Time pequeno, 5-20 prompts, quer compartilhar.

• Frameworks não são concorrentes, são complementares. Cada um resolve um problema diferente.
• DSPy é o estado da arte pra otimizar prompts com golden set. Curva de aprendizado maior, retorno maior.
• LangChain é o melhor pra prototipar rápido. Em produção, reescreva ou migre.
• Guidance/Outlines dão controle no nível de token - regex, gramáticas, escolha forçada.
• dotprompt é o simples - templates versionados, sem mágica.
• Regra de ouro: não pegue framework antes de ter o problema que ele resolve.

Dica: o erro mais comum de quem começa com framework é usar LangChain pra "1 chamada + 1 tool". Aí o overhead de abstração custa mais que a chamada pura. Framework entra quando o problema tem pelo menos 3-5 componentes encadeados, ou múltiplos prompts com lógica compartilhada.

No próximo nó, vamos ver o destino natural de pipelines complexos: agentes - quando o modelo decide sozinho o que fazer.