Comparativos

Pydantic AI ou DSPy: tipos na aplicação, métricas no programa

Publicado em 10 de setembro de 2026

Editor responsável pelo Bastidores da IA. Conteúdo pesquisado, revisado e atualizado com fontes identificadas. Veja o método editorial.

Pydantic AI e DSPy podem aparecer na mesma lista de frameworks Python para sistemas com modelos de linguagem, mas a semelhança para cedo. Pydantic AI organiza a execução de uma aplicação tipada, com agentes, ferramentas, dependências e saídas validadas. DSPy organiza o comportamento do modelo como um programa que pode ser medido e otimizado contra exemplos. A escolha, portanto, não começa pelo nome do framework. Começa pelo gargalo que você precisa remover.

Este comparativo foi revisado em 10 de setembro de 2026 com documentação e repositórios oficiais. Ele não usa benchmark próprio, não declara vencedor universal e não confunde licença do framework com o custo dos modelos, da infraestrutura ou de serviços opcionais.

Veredito rápido

Escolha Pydantic AI quando o centro do trabalho for entregar uma aplicação ou agente Python com contratos de entrada e saída, ferramentas, injeção de dependências, histórico, limites de uso e integração com o restante do sistema. O ganho mais visível aparece na engenharia do produto: tipos, validação, testes e uma API construída para conviver com código de produção.

Escolha DSPy quando o centro do trabalho for melhorar um programa de IA a partir de uma tarefa declarada, exemplos e uma métrica. Em vez de editar manualmente cada prompt, você combina assinaturas e módulos, avalia o resultado e, se houver dados suficientes, usa um otimizador para procurar instruções ou demonstrações melhores.

Se você ainda não tem uma métrica confiável nem exemplos representativos, a principal vantagem de otimização do DSPy fica limitada. Se o seu problema é um pipeline experimental e não uma aplicação com ferramentas e dependências, começar por toda a superfície operacional do Pydantic AI pode ser mais do que você precisa.

Comparação direta

Critério	Pydantic AI	DSPy
Ponto de partida	Aplicação ou agente Python tipado	Programa de IA descrito por assinaturas e módulos
Unidade central	Agent, ferramentas, dependências e tipo de saída	Signature, Module, métrica e conjunto de exemplos
Saída estruturada	Validação explícita por tipos, modelos Pydantic e esquemas	Campos de saída tipados dentro da assinatura
Ferramentas	Funções registradas no agente, com esquema derivado de assinatura e docstring	Funções fornecidas a módulos como ReAct
Avaliação	Testes de unidade e pacote Pydantic Evals	Métricas fazem parte do ciclo de avaliação e otimização
Otimização automática	Não é a proposta central do loop de agente	É um diferencial central quando há dados e métrica adequados
Licença do código	MIT	MIT
Custo do framework	Sem taxa de licença do framework	Sem taxa de licença do framework
Custos externos	Modelos, armazenamento, observabilidade e infraestrutura	Modelos, execuções de avaliação, otimização e infraestrutura

Eles não começam no mesmo lugar

É possível construir agentes com ambos. Também é possível obter dados estruturados, chamar ferramentas, trocar o modelo e avaliar resultados nos dois ecossistemas. Isso não os torna equivalentes. A arquitetura que cada um incentiva revela a diferença.

No Pydantic AI, você tende a começar com um Agent, declarar o modelo, o tipo de saída, dependências e ferramentas. No DSPy, você tende a começar com uma Signature que descreve entradas e saídas, escolher um Module para executar essa tarefa e definir uma métrica quando chega a hora de avaliar ou otimizar.

Essa distinção evita uma pergunta ruim, “qual framework é melhor?”, e produz uma pergunta útil: “preciso controlar melhor a aplicação que executa o modelo ou preciso melhorar sistematicamente o comportamento do programa?”

Pydantic AI começa pela aplicação tipada

A documentação atual apresenta o Pydantic AI como um SDK Python tipado para sistemas de IA. O tipo de saída atravessa a execução até o resultado, enquanto ferramentas e dependências também podem ser descritas por tipos. Para uma equipe que já usa Pydantic, FastAPI, verificadores estáticos ou testes Python, esse desenho reduz a distância entre a chamada ao modelo e o restante da aplicação.

Isso não elimina erros do modelo. Um esquema válido pode conter uma conclusão errada, um campo preenchido com uma inferência frágil ou uma ação tecnicamente permitida, mas inadequada ao contexto. Tipagem protege a forma e ajuda a localizar falhas. Ela não prova a verdade nem substitui regras de autorização.

DSPy começa pelo programa otimizável

O DSPy propõe “programar, não escrever prompts” como disciplina. A assinatura descreve a tarefa por campos de entrada e saída. O módulo define uma estratégia de execução, como previsão direta, raciocínio ou uso de ferramentas. O mesmo contrato pode ser executado por estratégias diferentes sem reescrever toda a tarefa em texto solto.

O passo que realmente diferencia o DSPy aparece quando você conecta esse programa a exemplos e a uma função de pontuação. Um otimizador pode então compilar uma versão ajustada do programa, procurando instruções ou demonstrações que melhorem a métrica definida. A palavra importante é métrica. Se ela premia a coisa errada, o processo melhora o número errado com eficiência.

Saídas tipadas existem nos dois, mas não significam a mesma coisa

O Pydantic AI permite declarar output_type com tipos escalares, listas, dicionários tipados, classes de dados ou modelos Pydantic. A biblioteca constrói o esquema e valida a resposta recebida. O resultado preserva informação de tipo para a aplicação consumidora.

O DSPy também aceita campos tipados nas assinaturas e pode usar modelos Pydantic, TypedDict e outras estruturas. Porém, no desenho do DSPy, o tipo é parte da declaração da tarefa que o programa e os módulos executam. Ele participa da modularidade e pode entrar no ciclo de otimização. Portanto, “ambos têm tipos” não é critério suficiente para escolher.

Ferramentas e agentes

No Pydantic AI, funções podem ser registradas como ferramentas do agente. A assinatura e a documentação da função ajudam a formar o esquema enviado ao modelo, e um RunContext pode entregar dependências do ambiente. Isso favorece aplicações em que banco de dados, cliente HTTP, identidade do usuário e serviços internos precisam chegar ao agente sem serem misturados ao texto do pedido.

No DSPy, ferramentas podem ser passadas a módulos como ReAct. A biblioteca também oferece composição de módulos, controle em Python e suporte a MCP. O foco, no entanto, continua sendo descrever e melhorar o programa. Em ambos os casos, a ferramenta executa código real. Nenhum framework transforma automaticamente uma função perigosa em uma função segura.

Métricas: teste de software e qualidade do comportamento

O Pydantic AI documenta testes de unidade, modelos de teste e o pacote Pydantic Evals. Isso permite verificar contratos, caminhos do agente e comportamento em conjuntos de casos. O DSPy coloca métricas no centro da avaliação e também as usa como objetivo para otimização.

Na prática, uma boa suíte separa pelo menos quatro camadas: validade do esquema, correção factual, aderência à política e utilidade para a tarefa. Uma única nota agregada pode esconder regressões. Antes de otimizar, registre resultados por caso, preserve exemplos difíceis e mantenha uma amostra de validação que o otimizador não veja.

Se sua dúvida principal é como estruturar avaliações recorrentes, o comparativo entre Promptfoo e DeepEval detalha outra camada do problema, independente da escolha do framework de aplicação.

Otimização exige exemplos representativos

O DSPy não torna desnecessário o trabalho de curadoria. Otimizadores como GEPA precisam de um programa, um conjunto de exemplos e uma métrica capaz de distinguir melhoria real de uma adaptação superficial. Poucos exemplos homogêneos podem produzir uma solução ótima apenas para aquele recorte.

Comece com casos reais anonimizados ou sintéticos claramente marcados, inclua entradas incompletas, ambiguidades e recusas esperadas. Separe treino de validação. Registre modelo, configuração, versão do programa e custo de cada rodada. Sem essa trilha, uma melhora aparente pode ser apenas mudança de modelo, cache ou amostra.

Custos: licença gratuita não significa execução gratuita

Os dois projetos usam licença MIT e podem ser instalados sem taxa de licença do framework. Essa constatação não cobre as chamadas aos modelos, armazenamento, filas, telemetria, bancos vetoriais, ambientes de execução nem trabalho de operação.

No Pydantic AI, uma execução de agente pode fazer várias chamadas de modelo e ferramentas, e integrações opcionais podem adicionar serviços próprios. No DSPy, avaliação e otimização podem multiplicar execuções sobre muitos exemplos e candidatos. Antes de comparar custo, registre solicitações, tokens, latência, falhas e repetições sob a mesma tarefa. Este artigo não publica uma tabela de preços porque esses valores pertencem aos provedores escolhidos e mudam separadamente dos frameworks.

Observabilidade e depuração

Pydantic AI oferece instrumentação baseada em OpenTelemetry e integração com Logfire, além de histórico e dados de uso no resultado. DSPy possui inspeção de histórico, callbacks, cache e orientações de rastreamento para programas e otimizadores.

O que deve ser observado é parecido: entrada efetivamente enviada, resposta do modelo, chamada e retorno de ferramenta, duração, consumo, tentativa, erro e decisão final. O que não deve ser registrado indiscriminadamente também é parecido: segredos, documentos integrais, dados pessoais e credenciais. Observabilidade útil precisa de minimização, retenção e controle de acesso.

Segurança, permissões e dados

Tipos não são permissões. Métricas não são políticas. Uma ferramenta tipada ainda pode apagar dados se receber autoridade excessiva. Um programa otimizado ainda pode aprender a explorar uma métrica imperfeita. Em qualquer uma das opções, mantenha credenciais fora de prompts, aplique privilégios mínimos e coloque aprovação humana antes de ações irreversíveis ou externas.

Use ambientes separados para desenvolvimento e produção. Limite rede, arquivos e comandos. Valide argumentos no código, não apenas na descrição da ferramenta. Para agentes com várias etapas, trate cada transição como uma fronteira de confiança. O comparativo entre LangGraph e CrewAI aprofunda essa discussão no contexto de estado, fluxos e equipes de agentes.

Portabilidade de modelos não elimina diferenças

Os dois projetos trabalham com vários provedores e modelos. Trocar o identificador ou adaptador, porém, não garante resultado idêntico. Modelos variam em ferramentas, saídas estruturadas, limites, raciocínio, streaming e formato de erro.

No Pydantic AI, valide novamente o esquema, o histórico e as chamadas de ferramenta. No DSPy, execute de novo a avaliação e considere recompilar o programa, porque instruções e demonstrações ajustadas para um modelo podem não ser a melhor configuração para outro. Portabilidade é capacidade de integração, não equivalência comportamental.

Combinar os dois é possível, mas aumenta a superfície

Uma arquitetura pode usar DSPy para desenvolver ou otimizar um componente e Pydantic AI para integrá-lo a uma aplicação tipada. Também pode chamar um programa DSPy de dentro de uma ferramenta ou serviço consumido por um agente.

Essa combinação só vale quando há uma fronteira clara. Defina quem controla o histórico, quem faz novas tentativas, quem contabiliza custo, onde ocorre a validação e qual camada pode chamar ferramentas externas. Sem essa divisão, você ganha dois sistemas de configuração, telemetria e erro para depurar.

Teste comparável em dez passos

Escolha uma tarefa pequena, real e repetível, como classificar solicitações de suporte.
Defina um esquema de saída idêntico para as duas implementações.
Use o mesmo modelo, configuração e limite de tentativas.
Prepare exemplos representativos e separe um conjunto de validação.
Implemente primeiro o caminho mínimo, sem otimização e sem ferramentas externas.
Adicione a mesma ferramenta de leitura, com dados fictícios e permissão limitada.
Meça validade do esquema, acerto da tarefa, latência, uso e falhas.
No DSPy, rode a otimização apenas sobre o conjunto de treino e registre o custo.
No Pydantic AI, teste dependências, erros de ferramenta e saídas inválidas.
Compare manutenção, clareza e segurança, não apenas a pontuação final.

O resultado esperado não é provar superioridade universal. É descobrir qual abstração deixa a sua equipe explicar, testar e operar melhor aquele fluxo específico.

Quando escolher Pydantic AI

Prefira Pydantic AI quando você já tem uma aplicação Python, precisa integrar serviços e quer que contratos tipados façam parte do desenho. Ele também tende a ser uma escolha direta quando ferramentas, dependências, resultados estruturados, testes e execução durável formam o centro do produto.

É uma opção menos convincente se a sua principal pergunta ainda é qual estratégia de prompting, raciocínio ou demonstrações produz melhor qualidade em um conjunto de tarefas. Nesse caso, você pode construir uma aplicação sólida e continuar ajustando o comportamento manualmente.

Quando escolher DSPy

Prefira DSPy quando você consegue expressar a tarefa por entradas e saídas, possui exemplos avaliáveis e quer experimentar módulos ou otimizar o programa contra uma métrica. Ele é especialmente útil quando prompts manuais cresceram, ficaram frágeis e já existe uma forma objetiva de medir melhoria.

É uma opção menos convincente quando não há dados, a qualidade depende de julgamento raro e subjetivo ou a prioridade imediata é integrar permissões, serviços, filas e interfaces de uma aplicação. O framework não cria sozinho a métrica nem a governança necessárias.

Checklist de decisão

Você precisa entregar uma aplicação tipada com ferramentas e dependências? Comece por Pydantic AI.
Você precisa melhorar um programa contra exemplos e uma métrica? Comece por DSPy.
Você não tem conjunto de validação? Construa-o antes de prometer otimização.
Você executará ações externas? Modele permissões e aprovação fora do prompt.
Você pretende trocar de modelo? Reavalie comportamento e custo depois da troca.
Você quer combinar os dois? Defina uma fronteira operacional e um único dono para cada responsabilidade.

Disponibilidade, licença e manutenção

Na consulta de 10 de setembro de 2026, Pydantic AI e DSPy estavam disponíveis como projetos Python de código aberto sob licença MIT, com instalação documentada e repositórios públicos ativos. As páginas oficiais indicavam Python 3.10 ou superior. Consulte a política de versões e fixe dependências antes de levar uma prova de conceito à produção.

A licença permite uso amplo do código, mas não oferece garantia. Ela também não altera termos dos provedores de modelos ou dos dados usados em treino e avaliação. Faça revisão de dependências, acompanhe notas de versão e teste migrações em ambiente isolado.

Limites deste comparativo

Não executamos um benchmark entre os frameworks, porque um resultado útil exigiria tarefa, modelo, métrica, conjunto de dados, hardware e orçamento definidos. Também não avaliamos todos os módulos, provedores ou integrações opcionais.

A superfície dos dois projetos muda rapidamente. Recursos citados refletem a documentação consultada na data indicada. Antes de adotar, monte uma prova pequena com seus dados autorizados, valide os caminhos de falha e registre o custo total do fluxo.

Fontes oficiais consultadas

RADAR BASTIDORES

IA muda rápido. Critério não.

Estamos preparando uma seleção editorial de novidades, ferramentas e guias que realmente merecem atenção.