LangGraph против Pydantic AI: почему именно модель, а не фреймворк, определила точность
Контролируемое сравнение производительности LangGraph и Pydantic AI при задании цели в 160 очков показывает одинаковую точность вызова инструментов, а также выявляет, что выбор модели и способ оценки имеют гораздо большее значение.
Выбор между фреймворками агентов — одна из самых острых дискуссий в инженерии искусственного интеллекта, однако тщательно контролируемый тест показывает, что это, возможно, одно из наименее влияющих на корректность решений. Когда LangGraph и Pydantic AI выполнялись над одинаковыми задачами, с использованием одинаковых инструментов и настроек модели, они давали совершенно одинаковые результаты, тогда как изменение модели приводило к смене результата в четверти случаев. В этой статье рассматривается данный эксперимент, что показывают и чего не показывают его цифры, а также как направить собственные усилия по оценке там, где это действительно влияет на результаты.
Как тест выделил фреймворк
В ходе сравнения модели LangGraph 1.2.9 и Pydantic AI 2.13.0 тестировались на четырех задачах, причем для каждой задачи и каждой модели выполнялось по 20 запусков: в общей сложности 160 запусков, одна модель, параметр temperature равен 0. Общая стоимость исследования составила 0,3767 доллара за использование API. Методология задокументирована, а инструменты тестирования являются открытым исходным кодом, поэтому их можно проверить и запустить снова.
Все четыре задачи имеют детерминистичный характер и оцениваются по принципу точного совпадения; каждая из них проверяет разную способность агента:
inventory-reorder: один вызов инструмента с последующими арифметическими операциями над результатомdependent-shipping-quote: второй вызов инструмента, входные данные которого зависят от результата первого вызоваrecover-stale-revision: агент должен понять, что его данные устарели, и снова их получитьrefund-policy-minimal-tools: арифметические операции с датами в рамках окна, установленного политикой возврата средств, при ограниченном количестве доступных инструментов
Все факторы, окружающие библиотеку, оставались неизменными: каждая платформа получала одинаковые запросы для выполнения любых задач, имела в своем распоряжении инструменты, описанные одинаковыми JSON-схемами, и опиралась на одну общую реализацию; кроме того, оценку проводил один и тот же эксперт. Модель была закреплена за gpt-4o при температуре 0, при этом параллельные вызовы инструментов были отключены. Единственным элементом, который допускалось изменять, была библиотека оркестрации.
Именно такой контроль и является сутью эксперимента. Во многих опубликованных сравнениях платформ одновременно меняются запросы, инструменты и библиотека, после чего любые различия приписываются библиотеке. Если вы хотите получить надежное собственное сравнение, первым требованием является фиксация всех остальных параметров.
Полное равенство в точности
Обе платформы правильно выполнили все 80 тестов. Краткое резюме:
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
Это не случай «приблизительно сопоставимых» результатов или различий, находящихся в пределах шума. При использовании одинаковых задач, схем, моделей и данных входа оценки были идентичны. Интервал Уилсона от 0,954 до 1,0 соответствует идеальному результату в 80 из 80 баллов: он указывает на то, что при таком объеме выборки реальная степень успеха с высокой вероятностью превышает 95 процентов в обоих случаях. Если бы одна из библиотек способствовала тому, что агенты чаще находили правильный ответ в этих задачах, у эксперимента было бы достаточно повторений, чтобы обнаружить значительный эффект, однако такого эффекта не было обнаружено. Однако она всё еще может упускать очень незначительные различия, что является обычным ограничением любой выборки такого размера.
Самым убедительным доказательством справедливости сравнения являются входные токены. Они полностью совпадали в обеих фреймворках при каждом запуске: 311 для inventory-reorder, 791 для dependent-shipping-quote, 615 для recover-stale-revision и 926 для refund-policy-minimal-tools. Другими словами, обе библиотеки преобразовывали одну и ту же схему в одинаковый API-запрос, байт за байтом с точки зрения токенов. Выходные токены отличались на несколько единиц лишь в небольшом числе запусков, что является обычной вариацией модели даже при температуре 0, и это объясняет разницу в половине цента в общей стоимости. Накладные расходы фреймворка на это не влияют.
Равенство результатов даёт не особо интересный заголовок, но оно отвечает на практический вопрос: с точки зрения корректности вызова инструментов, при таком масштабе и с использованием данной модели фреймворк не был решающим фактором.
Задержка: постоянная разница с простым объяснением
Эти фреймворки действительно отличались по одному показателю, причем это было стабильно. В приведённом ниже списке указано для каждой задачи, на сколько секунд меньше было среднее время выполнения в LangGraph по сравнению с Pydantic AI, а также диапазон доверия 95% для этой разницы:
inventory-reorder: LangGraph опережает на 1,669 секунды (диапазон от 1,481 до 1,918 секунд)dependent-shipping-quote: опережает на 1,430 секунды (диапазон от 1,241 до 1,686 секунд)recover-stale-revision: опережает на 1,842 секунды (диапазон от 1,658 до 2,101 секунд)refund-policy-minimal-tools: опережает на 1,645 секунды (диапазон от 1,427 до 1,911 секунд)
По всем четырём задачам весь диапазон значений значительно отличается от нуля. LangGraph завершал каждую задачу примерно на 1,4–1,8 секунды раньше, то есть в среднем примерно в 1,4 раза быстрее.
Не превращайте это в рекомендацию, не прочитав объяснение. Разница возникает из-за преобразования асинхронного кода в синхронный: сам инструментарий является синхронным, и Pydantic AI обрабатывался по этому синхронному пути. Это не означает, что цикл агента Pydantic AI по своей природе медленный. Это число реально и воспроизводимо для данного конкретного стиля интеграции, но в то же время это наименее переносимый результат всего исследования. В приложении, уже работающем полностью асинхронно, ожидайте, что разница сократится или исчезнет.
Один экстремальный случай противоречит медиане
Есть деталь, заслуживающая внимания, которая противоречит результатам по задержке обработки. Самый медленный результат в исследовании был получен с использованием LangGraph: 16,196 секунды на задаче dependent-shipping-quote, тогда как худший результат для Pydantic AI составил 10,228 секунды. Следующий по медленности результат LangGraph на этой же задаче занял 5,232 секунды, поэтому это скорее изолированный отклонение, чем явление, характерное для всей группы данных. Однако при всего 20 запусках на каждую задачу различить эти два варианта невозможно, и одна точка данных не может считаться распределением.
Практический вывод: в данном случае медианы склоняются в пользу LangGraph, но если вы устанавливаете показатели задержки, важна поведенческая характеристика данных на краях диапазона, и её необходимо измерять для собственных нагрузок, а не полагаться на медианы других.
Замена модели изменила четверть результатов
В отдельном запуске на том же инструментальном комплексе четыре задачи выполнялись с использованием двух моделей, причем по 40 запусков для каждой из них:
gpt-4o-mini gpt-4o
Completed 30 / 40 40 / 40
Cost (40 runs) $0.0057177 $0.094275
Фреймворки, задачи и инструменты остались без изменений. Изменился только модель, и 25 процентов результатов изменились.
Способ сбоя модели gpt-4o-mini является наиболее показательным. Её вызовы инструментов работали нормально: с любым фреймворком она правильно решала все задачи, кроме одной. Исключением стала задача refund-policy-minimal-tools — во всех 10 попытках решения этой задачи она терпела неудачу, по пять раз с каждым фреймворком, причем всегда одинаково. Она вычисляла days_since_delivery = 19, учитывая как дату начала, так и дату окончания, тогда как правильное значение без учета начальной даты составляет 18, после чего делала вывод о том, что клиент находится вне срока возврата средств.
Это не сбой фреймворка и не проблема с использованием инструментов. Речь идет о модели, которая неправильно определяет инклюзивный или эксклюзивный способ подсчета дат внутри агента, действующего на основе неверного числа. Ни одна библиотека оркестрации не может самостоятельно обнаружить подобную ошибку. Ее можно выявить с помощью детерминистической проверки: вычисления разницы в датах с использованием инструмента вместо того, чтобы просить модель выполнять арифметические операции, или проверка результата перед его использованием.
Таким образом, сравнение, о котором спорит индустрия, закончилось вничью, тогда как сравнение, по которому практически никто не спорит, привело к разнице в 25 баллов. Для получения более высокого рейтинга потребовалось примерно в 16,5 раз больше усилий.
Что можно взять из этого для собственной технологической стек-структуры
Выбирайте фреймворк с учетом эргономики
Принимайте решение, исходя из факторов, с которыми вам придется работать ежедневно: безопасность типов, подходит ли модель графа для вашей задачи, удобство отладки и степень читаемости кода для вашей команды во время возникновения проблем. Эти различия реальны. Исходя из этого, корректность не входит в их число. Чтобы ознакомиться с более полным сравнением вариантов по этим критериям, прочитайте выбор фреймворка для Python AI-агента.
Инвестируйте ресурсы оценки в модель
Здесь выбор модели повлиял на 25 процентов результатов и изменил стоимость в 16,5 раза. Если у вас ограничено время для тестирования одного аспекта, протестируйте модель на собственных задачах. Также обратите внимание, что обе модели, рассматриваемые в исследовании, являются конкретными, более старыми моделями OpenAI; новые модели могут вести себя иначе, поэтому повторите сравнение с моделями, которые вы действительно планируете использовать.
Затем изучайте способы сбоев, а не общий процент успеха
Самой информативной частью этого тестирования была не таблица с результатами, а refund-policy-minimal-tools — задание, созданное специально для того, чтобы оказаться сложным. Все модели и фреймворки справились с остальными тремя заданиями, поэтому они ничего не раскрыли. Набор инструментов для оценки приносит пользу только тогда, когда что-то ломается. Разрабатывайте задания, направленные на конкретные слабые места, которых вы боитесь, такие как логика обработки дат с ошибкой «off-by-one», устаревшие данные или последовательные вызовы инструментов, и расширяйте набор на основе реальных сбоев в производственной среде.
Не доверяйте тестам, которые выбирают победителя
Относитесь с подозрением ко всем тестам производительности фреймворков, которые объявляют победителя, включая этот. То, что делает это исследование проверяемым, — это публикация необработанных результатов в формате JSONL, списка версий с соответствующими хэшами, а также инструментов для проведения тестов вместе с полными данными за все 160 запусков. Применяйте к любым тестам производительности, на которые вы полагаетесь, тот же стандарт.
Ограничения доказательств
Область применения ограничена: одна семья моделей, четыре задачи, один набор инструментов и фиксированная дата. Испытания проводились 24 и 25 июля 2026 года с использованием моделей gpt-4o и gpt-4o-mini, а также версий библиотек LangGraph 1.2.9 и pydantic-ai-slim[openai] 2.13.0; результаты могут измениться при использовании более новых версий. Правильность вызова инструментов — это лишь один из аспектов фреймворка агентов, и, возможно, не самый важный; управление состоянием, сохранение данных, потоковая обработка и возможности отслеживания здесь не оцениваются.
Следовательно, то, что подтверждают данные, менее значимо, чем кажется на первый взгляд: при этих задачах и в таком масштабе фреймворк не смог предсказать, достиг ли агент правильного ответа, в то время как модель смогла.
Основные выводы
- Именно контроль над всем, кроме библиотеки, делает сравнение фреймворков значимым; одинаковое количество токенов входных данных — хороший показатель справедливости.
- LangGraph и Pydantic AI набрали по 80 из 80 баллов за точность вызова инструментов с использованием
gpt-4o. - Разница в задержке была связана с переходом от синхронного к асинхронному режиму в инструментальной среде, а не с медленным циклом агента; наличие одного отклонения объясняет необходимость отдельной оценки задержек в конце обработки.
- Изменение модели привело к изменению 25 процентов результатов из-за постоянной ошибки в арифметике дат, которую ни один фреймворк не смог выявить.
- Сосредоточьте усилия по оценке на выборе модели и на задачах, требующих поиска ошибок, а детерминистическую логику, такую как вычисления с датами, перенесите во внешние модули.
Связанные материалы
- Выбор фреймворка для AI-агентов на Python в 2026 году: практическое сравнение — Сравниваются пять фреймворков для AI-агентов на Python с точки зрения способа обработки сбоев и сложности, что помогает читателям подобрать подходящий инструмент для их рабочего процесса.
- От сырого текста к пайплайнам: парсеры, LCEL, Runnables и работа с памятью в LangChain — Как LangChain преобразует сырой текст модели в структурированные данные, объединяет шаги с помощью LCEL и интерфейса Runnable, а также обрабатывает информацию из разговоров в настоящее время.