LangGraph проти Pydantic AI: чому саме модель, а не фреймворк, визначила точність
Контрольоване порівняння з результатом 160 очок для LangGraph та Pydantic AI показує однакову точність виклику інструментів та демонструє, що вибір моделі та спосіб оцінки мають набагато більше значення.
Вибір між фреймворками агентів є однією з найбільш запеклих дискусій у інженерії ШІ, проте ретельно контрольоване тестування свідчить про те, що це може бути одним із найменш впливових факторів на коректність роботи. Коли 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, але якщо ви встановлюєте показники SLO щодо затримки, важливою є поведінка крайніх значень, і її потрібно вимірювати на власному навантаженні, а не покладатися на медіани інших систем.
Заміна моделі змінила чверть результатів
У окремому тестуванні на тій самій платформі чотири завдання виконувалися з використанням двох моделей, по 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 — завдання, створене для того, щоб бути складним. Кожна модель та фреймворк пройшли інші три завдання, тож вони нічого не розкрили. Набір засобів оцінки має сенс лише тоді, коли щось зазнає невдачі. Розробляйте завдання, спрямовані на конкретні слабкості, яких ви боїтесь — наприклад, логіку дат з помилкою «одиниця», застарілі дані чи послідовні виклики інструментів, — та розширюйте цей набір на основі реальних збоїв у продакшені.
Не довіряйте тестам, які визначають переможця
Ставіться з підозрою до будь-яких тестів фреймворків, які оголошують переможця, включаючи цей. Те, що робить це дослідження перевірним, — це те, що оприлюднені первинні результати у форматі 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, а також керує пам’яттю під час діалогу.