LangGraph vs Pydantic AI: Por qué el modelo, y no el framework, determinó la precisión
Una prueba controlada con 160 puntos de referencia entre LangGraph y Pydantic AI muestra una precisión idéntica en las llamadas a herramientas, y revela que la elección del modelo y el diseño de la evaluación son mucho más importantes.
Elegir entre los marcos de trabajo de agentes es uno de los debates más acalorados en la ingeniería de IA, pero un benchmark cuidadosamente controlado sugiere que podría tratarse de una de las decisiones menos relevantes en cuanto a la corrección. Cuando LangGraph y Pydantic AI se ejecutaron en tareas, herramientas y configuraciones de modelo idénticas, obtuvieron exactamente la misma puntuación, mientras que un cambio de modelo alteró una cuarta parte de los resultados. Este artículo explica ese experimento, qué muestran y no muestran sus cifras, y cómo dirigir los propios esfuerzos de evaluación hacia aquello que realmente afecta los resultados.
Cómo el benchmark aisló el marco de trabajo
La comparación enfrentó a LangGraph 1.2.9 contra Pydantic AI 2.13.0 en cuatro tareas, con 20 ejecuciones por tarea y por framework: un total de 160 ejecuciones, un solo modelo y una temperatura de 0. Todo el estudio costó 0.3767 dólares en gastos de API. La metodología está documentada y el conjunto de pruebas es de código abierto, por lo que se puede verificar y volver a ejecutar.
Todas las cuatro tareas son deterministas y se califican por coincidencia exacta; cada una evalúa una habilidad distinta del agente:
inventory-reorder: una única llamada a la herramienta seguida de operaciones aritméticas sobre su resultadodependent-shipping-quote: una segunda llamada a la herramienta cuya entrada depende de la salida de la primerarecover-stale-revision: el agente debe darse cuenta de que sus datos están desactualizados y recuperarlos nuevamenterefund-policy-minimal-tools: operaciones aritméticas con fechas relacionadas con un plazo de política de reembolso, utilizando intencionalmente pocas herramientas disponibles
Todo lo relacionado con la biblioteca se mantuvo constante: cada framework recibió instrucciones idénticas para cada tarea, contó con herramientas descritas mediante esquemas JSON idénticos y se basó en una misma implementación compartida, además de ser evaluado por un único calificador. El modelo se fijó en gpt-4o a una temperatura de 0, con las llamadas a herramientas en paralelo desactivadas. La única cosa permitida cambiar era la biblioteca de orquestación.
Esa disciplina es precisamente el objetivo del experimento. Muchas comparaciones de frameworks publicadas cambian al mismo tiempo las instrucciones, las herramientas y la biblioteca, y luego atribuyen cualquier diferencia a la biblioteca. Si deseas una comparación fiable por tu cuenta, mantener todo lo demás estable es el primer requisito.
Igualdad absoluta en precisión
Ambos frameworks completaron correctamente las 80 pruebas que se realizaron. El resumen:
LangGraph 1.2.9 Pydantic AI 2.13.0
Completed 80 / 80 80 / 80
Wilson 95% CI 0.954 - 1.0 0.954 - 1.0
Total cost $0.1881 $0.1886
Median wall time 3.863 s 5.526 s
Esto no es un caso de “casi comparable” ni “dentro del rango de variabilidad”. Con las mismas tareas, esquemas, modelos y cargas de trabajo, las puntuaciones fueron idénticas. El intervalo de Wilson de 0.954 a 1.0 corresponde a una puntuación perfecta de 80 sobre 80: indica que, con esta muestra, la tasa real de éxito es muy probablemente superior al 95 por ciento en ambos casos. Si alguna de las bibliotecas hubiera hecho que los agentes tuvieran más probabilidades de llegar a la respuesta correcta en estas tareas, el experimento habría tenido suficientes repeticiones como para detectar un efecto significativo, pero no se observó ninguno. Aún así, podría pasar por alto diferencias muy pequeñas, lo cual es un límite normal de cualquier muestra de este tamaño.
La señal más clara de que la comparación fue justa se encuentra en los tokens de entrada. Estos coincidieron exactamente en ambos frameworks en cada ejecución: 311 para inventory-reorder, 791 para dependent-shipping-quote, 615 para recover-stale-revision y 926 para refund-policy-minimal-tools. En otras palabras, ambas bibliotecas convirtieron el mismo esquema en la misma solicitud API, byte a byte en términos de tokens. Los tokens de salida difirieron ligeramente en unas pocas ejecuciones, lo cual es una variación normal del modelo incluso a una temperatura de 0, y eso explica la diferencia de medio centavo en el costo total. El sobrecargo del framework no lo hace.
Un empate da como resultado un titular poco interesante, pero responde a la pregunta práctica: en cuanto a la corrección al llamar a las herramientas, a esta escala y con este modelo, el framework no fue la variable decisiva.
Latencia: una diferencia constante con una explicación sencilla
Los frameworks sí diferían en un eje, y de manera consistente. La lista a continuación indica, para cada tarea, cuánto menor era el tiempo medio de ejecución de LangGraph en comparación con Pydantic AI, seguido del intervalo de confianza del 95% para esa diferencia:
inventory-reorder: LangGraph supera en 1.669 s (intervalo de 1.481 a 1.918 s)dependent-shipping-quote: supera en 1.430 s (intervalo de 1.241 a 1.686 s)recover-stale-revision: supera en 1.842 s (intervalo de 1.658 a 2.101 s)refund-policy-minimal-tools: supera en 1.645 s (intervalo de 1.427 a 1.911 s)
En las cuatro tareas, todo el intervalo se mantiene lejos de cero. LangGraph completó cada ejecución aproximadamente 1.4 a 1.8 segundos antes, es decir, unas 1.4 veces más rápido según los valores medios.
No convierta eso en una recomendación sin leer la explicación. La diferencia se debe a la integración de código asíncrono con código síncrono: el framework es síncrono, y Pydantic AI se ejecutó a través de esa vía síncrona. Esto no demuestra que el bucle de agentes de Pydantic AI sea inherentemente lento. La cifra es real y reproducible para ese estilo específico de integración, pero también es el resultado menos transferible en el estudio. En una aplicación que ya sea asíncrona de extremo a extremo, cabe esperar que la diferencia disminuya o desaparezca.
Un valor atípico contrarresta la mediana
Un detalle digno de mención va en contra del resultado relativo a la latencia. La ejecución más lenta de todo el estudio correspondió a LangGraph: 16,196 segundos en dependent-shipping-quote, frente a los 10,228 segundos registrados por la peor ejecución de Pydantic AI. La siguiente ejecución más lenta de LangGraph en esa tarea tardó 5,232 segundos, por lo que parece tratarse de un caso aislado y no de un comportamiento generalizado en el rango de valores extremos. Sin embargo, al contar solo con 20 ejecuciones por tarea, no es posible distinguir entre estas dos posibilidades, y un único punto de datos no constituye una distribución.
La lección práctica: las medias favorecen a LangGraph en este caso, pero si se está estableciendo un objetivo de rendimiento relacionado con la latencia, lo importante es el comportamiento en los valores extremos, y es necesario medirlo con la carga de trabajo propia en lugar de confiar en la media de otra persona.
Cambiar el modelo modificó una cuarta parte de los resultados
En otra ejecución realizada con el mismo entorno, las cuatro tareas se ejecutaron con dos modelos diferentes, realizando 40 ejecuciones para cada uno:
gpt-4o-mini gpt-4o
Completed 30 / 40 40 / 40
Cost (40 runs) $0.0057177 $0.094275
Los frameworks, tareas y herramientas no cambiaron. Solo el modelo difería, y el 25 por ciento de los resultados varió.
La forma en que falló gpt-4o-mini es la parte más instructiva. Su llamada a las herramientas estuvo bien: con cualquier framework logró acertar en todas las tareas excepto una. La excepción fue refund-policy-minimal-tools, en la que falló en las 10 pruebas realizadas para esa tarea, cinco por framework, y siempre de la misma manera. Calculó days_since_delivery = 19 al contar tanto la fecha de inicio como la de finalización, cuando el conteo exclusivo correcto debería ser 18, y luego concluyó que el cliente estaba fuera del plazo de reembolso.
Eso no es ni un fallo del framework ni un error en el uso de la herramienta. Se trata de un modelo que comete un error al calcular fechas de forma inclusiva frente a exclusiva, dentro de un agente que actuó fielmente con el número incorrecto. Ninguna biblioteca de orquestación puede detectar por sí sola un error de ese tipo. Lo que lo detecta es una verificación determinística: calcular las diferencias de fechas mediante una herramienta en lugar de pedirle al modelo que realice los cálculos, o validar el resultado antes de actuar sobre él.
Así que la comparación sobre la cual discute la industria terminó en empate, mientras que la comparación sobre la cual casi nadie debate arrojó una diferencia de 25 puntos. Obtener una puntuación más alta costó aproximadamente 16,5 veces más.
Qué tomar de esto para su propio stack
Elija el framework por razones de ergonomía
Basee la decisión en los aspectos con los que tendrá que lidiar a diario: la seguridad tipológica, si un modelo de gráficos se adapta a su problema, la experiencia de depuración y qué tan legible es el código para su equipo durante un incidente. Esas diferencias son reales. Según esta evidencia, la corrección no está entre ellas. Para una comparación más amplia de las opciones en estos aspectos, consulte cómo elegir un framework de agentes de IA en Python.
Invierta su presupuesto de evaluación en el modelo
Aquí, la elección del modelo influyó en el 25 por ciento de los resultados y modificó el costo en un factor de 16,5. Si tiene poco tiempo para probar algo, pruebe el modelo en sus propias tareas. Tenga también en cuenta que ambos modelos estudiados son versiones específicas y antiguas de OpenAI; los modelos más recientes pueden comportarse de manera diferente, por lo que vuelva a realizar la comparación con los modelos que realmente planea utilizar.
Luego estudie los modos de fallo, no la tasa general de éxito
La parte más informativa de esta prueba no fue la tabla de puntuaciones, sino refund-policy-minimal-tools, la tarea diseñada para ser difícil. Cada modelo y framework superó las otras tres tareas, por lo que estas no revelaron nada. Un conjunto de evaluación solo cobra sentido cuando algo falla. Diseñe tareas que aborden las debilidades específicas que teme, como lógica de fechas errónea, datos obsoletos o llamadas en cadena a herramientas, y desarrolle el conjunto a partir de fallos reales en producción.
No confíe en pruebas que eligen a un ganador
Trate con escepticismo cualquier prueba de rendimiento de un framework que declare a un ganador, incluida esta. Lo que hace verificable este estudio es que se publican los resultados brutos en formato JSONL, un archivo de manifestación con las versiones y hashes fijados, así como el entorno de pruebas, junto con todos los datos completos de las 160 ejecuciones. Aplique el mismo estándar a cualquier prueba de rendimiento en la que confíe.
Límites de las pruebas
El alcance es limitado: una familia de modelos, cuatro tareas, un conjunto de herramientas y una fecha fija. Las pruebas tuvieron lugar los días 24 y 25 de julio de 2026, utilizando los modelos gpt-4o y gpt-4o-mini, así como las versiones de la biblioteca LangGraph 1.2.9 y pydantic-ai-slim[openai] 2.13.0; los resultados podrían variar con versiones posteriores. La corrección en las llamadas a herramientas también es solo una dimensión de un marco de agentes, y posiblemente no la que más le interese; aquí no se miden el manejo de estados, la persistencia, el streaming ni la observabilidad.
Por lo tanto, lo que respaldan los datos es algo más modesto de lo que indicaría un titular: en estas tareas y a esta escala, el marco no pudo predecir si el agente llegaba a la respuesta correcta, mientras que el modelo sí lo hizo.
Conclusiones clave
- Controlar todo excepto la biblioteca es lo que da sentido a una comparación de frameworks; contar con números idénticos de tokens de entrada es una buena forma de verificar la equidad.
- LangGraph y Pydantic AI obtuvieron 80 de 80 puntos en cuanto a la corrección al llamar a herramientas con
gpt-4o. - La diferencia en latencia se debió a un puente de sincronización a asíncrono en el entorno, no a un bucle del agente lento; además, un único valor atípico explica por qué la latencia en los casos extremos debe medirse por separado.
- Cambiar el modelo alteró el 25 por ciento de los resultados, debido a un error consistente en el cálculo de fechas que ninguno de los frameworks pudo detectar.
- Invierta esfuerzos en la evaluación de modelos y en tareas difíciles que busquen errores, y saca la lógica determinista como los cálculos de fechas fuera del modelo.
Lecturas relacionadas
- Elegir un marco de trabajo para agentes de IA en Python en 2026: Un comparativo práctico — Compara cinco marcos de trabajo para agentes de IA en Python según su forma de manejar los fallos y la complejidad, ayudando a los lectores a elegir la herramienta adecuada para su flujo de trabajo.
- De texto bruto a tuberías:解析器、LCEL、可执行组件 y memoria en LangChain — Cómo LangChain convierte el texto bruto del modelo en datos estructurados, combina pasos mediante LCEL y la interfaz Runnable, y gestiona la memoria en las conversaciones actualmente.