LangGraph kontra Pydantic AI: Dlaczego to model, a nie framework, decydował o dokładności
Kontrolowane badanie porównawcze LangGraph i Pydantic AI, obejmujące 160 punktów oceny, pokazuje identyczną dokładność wywoływania narzędzi i ujawnia, że wybór modelu oraz projekt oceny mają o wiele większe znaczenie.
Wybór między ramami agentowymi to jeden z najgorętszych sporów w inżynierii sztucznej inteligencji, jednak starannie kontrolowany test porównawczy wskazuje, że może to być jedna z decyzji o najmniejszym wpływie na poprawność. Gdy LangGraph i Pydantic AI były wykorzystywane do identycznych zadań, przy użyciu tych samych narzędzi i ustawień modelu, dawały dokładnie takie same wyniki, natomiast zmiana modelu powodowała odwrócenie się wyniku w jednej czwartej przypadków. Ten artykuł omawia ten eksperyment, co pokazują i czego nie pokazują jego liczby, oraz jak skierować własne wysiłki oceniające tam, gdzie faktycznie wpływa to na wyniki.
Jak test porównawczy izolował ramy
Porównanie przeprowadzono pomiędzy LangGraph 1.2.9 a Pydantic AI 2.13.0 w czterech zadaniach, przy 20 próbach na zadanie i framework – łącznie 160 prób, jeden model, temperatura 0. Całe badanie kosztowało 0,3767 dolarów w ramach wydatków na API. Metodologia jest udokumentowana, a narzędzie testowe ma otwarty kod źródłowy, więc jego konfigurację można sprawdzić i ponownie uruchomić.
Wszystkie cztery zadania są deterministyczne i oceniane według dokładnego dopasowania, a każde z nich sprawdza inną umiejętność agenta:
inventory-reorder: jedna wywołanie narzędzia, po którym następuje obliczenie na jego wynikudependent-shipping-quote: drugie wywołanie narzędzia, którego dane wejściowe zależą od wyniku pierwszegorecover-stale-revision: agent musi zdać sobie sprawę, że jego dane są przestarzałe, i pobrać je ponownierefund-policy-minimal-tools: obliczenia datowe w kontekście okna czasowego dotyczącego polityki zwrotów, przy intencjonalnie ograniczonej liczbie dostępnych narzędzi
Wszystko wokół biblioteki było utrzymywane w stałej formie: każda platforma otrzymywała identyczne instrukcje do wykonywania zadań, dostęp do narzędzi opisanych za pomocą identycznych schematów JSON oraz wspólną implementację, a ocenę przeprowadzał jeden osoba. Model został ustalony na gpt-4o przy temperaturze 0, przy czym wywołania narzędzi równolegle zostały wyłączone. Jedyną rzeczą, której można było zmieniać, była biblioteka orkiestracji.
To właśnie ta dyscyplina stanowi sedno eksperymentu. Wiele opublikowanych porównań platform zmienia jednocześnie instrukcje, narzędzia i bibliotekę, a następnie przypisuje wszelkie różnice bibliotece. Jeśli chcesz uzyskać wiarygodne porównanie we własnym zakresie, kluczowym wymogiem jest utrzymanie wszystkich innych elementów w niezmienionej formie.
Dokładna remisowa ocena pod względem poprawności
Oba frameworki prawidłowo przeprowadziły wszystkie 80 testów. Streszczenie:
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
To nie jest przypadek „mniej więcej porównywalnych” wyników ani tych „w granicach błędu”. Przy takich samych zadaniach, schematach, modelu i danych wejściowych wyniki były identyczne. Przedział Wilsona od 0,954 do 1,0 odpowiada doskonałym wynikom 80 na 80: wskazuje on, że przy tym próbkowaniu rzeczywisty wskaźnik skuteczności jest z dużym prawdopodobieństwem powyżej około 95 procent w obu przypadkach. Gdyby jedna z bibliotek sprawiła, że agenci częściej znajdowaliby właściwą odpowiedź w tych zadaniach, eksperyment miałby wystarczająco dużo powtórzeń, by wykryć znaczący efekt, lecz żadnego takiego efektu nie zaobserwowano. Może on jednak przeoczyć bardzo małe różnice, co jest normalnym ograniczeniem każdej próbki tego rozmiaru.
Najważniejszym dowodem na to, że porównanie było uczciwe, są tokeny wejściowe. W obu frameworkach dla każdego przeprowadzonego testu odpowiadały one dokładnie sobie: 311 dla inventory-reorder, 791 dla dependent-shipping-quote, 615 dla recover-stale-revision oraz 926 dla refund-policy-minimal-tools. Innymi słowy, obie biblioteki przekształciły to samo schemat w tę samą żądanie API, bit po bicie pod względem liczby tokenów. Tokeny wyjściowe różniły się o kilka wartości w niewielkiej liczbie przypadków, co jest normalną zmiennością modelu nawet przy temperaturze 0, i to tłumaczy różnicę w koszcie o pół centa. Nakład pracy frameworka nie ma na to wpływu.
Równowaga wyników daje mniej interesujący tytuł, ale odpowiada na praktyczne pytanie: jeśli chodzi o poprawność wywoływania narzędzi, w takim skali i przy tym modelu framework nie był decydującym czynnikiem.
Czas reakcji: stała różnica z prostym wyjaśnieniem
Ramy robocze różniły się pod względem jednej osi, i to konsekwentnie. Poniższa lista pokazuje dla każdego z zadań, o ile niższy był medianowy czas wykonywania zadań przez LangGraph w porównaniu z Pydantic AI, a następnie przedstawia 95% przedział ufności dla tej oszczędności:
inventory-reorder: LangGraph wyprzedza o 1,669 s (przedział od 1,481 do 1,918 s)dependent-shipping-quote: wyprzedza o 1,430 s (przedział od 1,241 do 1,686 s)recover-stale-revision: wyprzedza o 1,842 s (przedział od 1,658 do 2,101 s)refund-policy-minimal-tools: wyprzedza o 1,645 s (przedział od 1,427 do 1,911 s)
We wszystkich czterech zadań cały przedział pozostaje daleko od zera. LangGraph kończył każde zadanie średnio o 1,4 do 1,8 sekundy szybciej, czyli około 1,4 raza szybciej, według wartości medianowych.
Nie zamieniaj tego na rekomendację, nie przeczytawszy wyjaśnienia. Różnica wynika z łączenia kodu asynchronicznego z kodem synchronicznym: narzędzie jest synchroniczne, a Pydantic AI zostało uruchomione przez tę ścieżkę synchroniczną. Nie pokazuje to, że pętla agenta w Pydantic AI jest z natury wolna. Liczba ta jest rzeczywista i powtarzalna dla tego konkretnego stylu integracji, ale jest również najmniej przenośnym wynikiem w badaniu. W aplikacji, która jest już całkowicie asynchroniczna od początku do końca, można oczekiwać, że różnica się zmniejszy lub zniknie.
Jeden wyjątek przeciwstawia się medianie
Detal wart uwagi stoi w sprzeczności z wynikami dotyczącymi opóźnienia. Najwolniejszy wynik w badaniu uzyskał LangGraph: 16,196 sekundy przy zadaniu dependent-shipping-quote, podczas gdy najgorszy wynik dla Pydantic AI wyniósł 10,228 sekundy. Następny po LangGraph najwolniejszy wynik w tym zadaniu trwał 5,232 sekundy, więc wydaje się to pojedynczym odstępstwem, a nie objawem silnego ogona rozkładu. Jednak przy zaledwie 20 próbach na zadanie nie można odróżnić tych dwóch możliwości, a jeden punkt danych nie stanowi rozkładu.
Praktyczna lekcja: mediana faworyzuje tutaj LangGraph, ale jeśli ustalasz standardy opóźnienia, kluczowe jest zachowanie ogona rozkładu, które musisz zmierzyć w swoim własnym obciążeniu pracy, zamiast polegać na medianie kogoś innego.
Zmiana modelu zmieniła ćwierć wyników
W oddzielnej serii prób na tym samym narzędziu cztery zadania zostały wykonywane z użyciem dwóch modeli, po 40 prób każdy:
gpt-4o-mini gpt-4o
Completed 30 / 40 40 / 40
Cost (40 runs) $0.0057177 $0.094275
Ramy, zadania i narzędzia pozostały niezmienione. Różnił się tylko model, a 25 procent wyników uległo zmianie.
Sposób, w jaki zawiodł gpt-4o-mini, jest najbardziej pouczający. Jego wywoływanie narzędzi przebiegało prawidłowo: przy każdej z ram roboczych udawało mu się poprawnie wykonać wszystkie zadania z wyjątkiem jednego. Wyjątkiem był refund-policy-minimal-tools – w wszystkich 10 próbach wykonywania tego zadania zawodził, po pięć razy przy każdej ramie roboczej, i zawsze w ten sam sposób. Obliczył days_since_delivery = 19, licząc zarówno datę rozpoczęcia, jak i zakończenia, podczas gdy poprawna liczba to 18, a następnie stwierdził, że klient znajduje się poza oknem zwrotu pieniędzy.
To nie jest ani błąd frameworka, ani błąd w używaniu narzędzia. Chodzi o model, który błędnie traktuje liczenie dat jako inkluzywne lub ekskluzywne, w ramach agenta, który wiernie działał na podstawie niewłaściwej liczby. Żadna biblioteka orkiestracji sama w sobie nie może wykryć takiego błędu. To, co go wykrywa, to sprawdzenie deterministyczne: obliczanie różnic dat za pomocą narzędzia zamiast proszenia modelu o wykonywanie obliczeń lub weryfikacja wyniku przed podjęciem działań na jego podstawie.
Zatem porównanie, o którym dyskutuje branża, zakończyło się remisem, podczas gdy porównanie, o którym prawie nikt nie debatuje, przyniosło różnicę 25 punktów. Uzyskanie wyższej oceny kosztowało około 16,5 raza więcej.
Co można z tego wyciągnąć dla własnego stacka
Wybierz framework ze względu na ergonomię
Podjąć decyzję należy na podstawie elementów, z którymi będziesz miał do czynienia każdego dnia: bezpieczeństwa typów, tego, czy model grafowy pasuje do Twojego problemu, doświadczenia przy debugowaniu oraz tego, na jak łatwo zrozumiały będzie kod dla Twojego zespołu w trakcie incydentu. Te różnice są rzeczywiste. Na podstawie tych dowodów poprawność nie należy do nich. Aby uzyskać szersze porównanie opcji w tym kontekście, zapoznaj się z wyborem frameworka dla agentów AI w Pythonie.
Zainwestuj swój budżet oceny w model
Tutaj wybór modelu wpłynął na 25 procent wyników i zmienił koszty aż 16,5 raza. Jeśli masz ograniczony czas na przetestowanie jednej rzeczy, sprawdź model w swoich własnych zadaniach. Należy również pamiętać, że oba modele w tym badaniu to konkretne, starsze modele OpenAI; nowsze modele mogą zachowywać się inaczej, dlatego przeprowadź ponownie porównanie z modelami, które faktycznie planujesz użyć.
Następnie badaj tryby awarii, a nie ogólny wskaźnik sukcesu
Najbardziej pouczającą częścią tego testu nie była tabela wyników, lecz refund-policy-minimal-tools – zadanie zaprojektowane tak, by było trudne. Każdy model i framework przejdł pozostałe trzy zadania, więc nie ujawniły one żadnych informacji. zestaw ocenowy ma sens tylko wtedy, gdy coś się nie udaje. Projektuj zadania skierowane na konkretne słabości, których się obawiasz, takie jak błędy w logice dat, przestarzałe dane czy łańcuchowe wywołania narzędzi, i rozwijaj ten zestaw na podstawie rzeczywistych awarii w produkcji.
Nie ufaj testom, które wybierają zwycięzcę
Traktuj z podejrzliwością każde porównanie frameworków, które wskazuje zwycięzcę, włączając w to to. To, co sprawia, że ta praca może być zweryfikowana, to fakt, iż surowe wyniki w formacie JSONL, manifest z wersjami i hashami oraz narzędzie do ich przetwarzania są wszystkie opublikowane, wraz z pełnymi danymi z każdego z 160 testów. Stosuj ten sam standard do wszystkich benchmarków, na których polegasz.
Ograniczenia dostępnych dowodów
Zakres jest wąski: jedna rodzina modeli, cztery zadania, jeden zestaw narzędzi oraz ustalona data. Testy przeprowadzono 24 i 25 lipca 2026 roku, przy użyciu modeli gpt-4o i gpt-4o-mini, wersji biblioteki LangGraph 1.2.9 oraz pydantic-ai-slim[openai] 2.13.0; wyniki mogą się różnić przy użyciu nowszych wersji. Poprawność wywoływania narzędzi to również tylko jedna z cech ram roboczych agenta, i być może nie ta, która jest dla Ciebie najważniejsza – zarządzanie stanem, trwałość danych, transmisja strumieniowa oraz możliwości obserwacji nie są tu mierzone.
Dlatego dane dostarczają informacji skromniejszych niż te przedstawione w nagłówkach: przy tych zadaniach i takiej skali ramy robocze nie potrafiły przewidzieć, czy agent doszedł do prawidłowej odpowiedzi, podczas gdy model tak potrafił.
Główne wnioski
- Kontrola wszystkiego z wyjątkiem biblioteki sprawia, że porównanie frameworków ma sens; identyczna liczba tokenów wejściowych jest dobrym wskaźnikiem sprawiedliwości.
- LangGraph i Pydantic AI uzyskały po 80 punktów na 80 w kategorii poprawności wywoływania narzędzi z
gpt-4o. - Różnica w opóźnieniach wynikała z przejścia od synchronicznego do asynchronicznego trybu w narzędziu, a nie z wolnego cyklu agenta; pojedynczy wyjątek pokazuje, dlaczego opóźnienia końcowe muszą być mierzone oddzielnie.
- Zmiana modelu zmieniła 25 procent wyników, co było spowodowane jednym stałym błędem w arytmetyce dat, którego żaden framework nie był w stanie wykryć.
- Inwestujcie wysiłki w ocenę przy wyborze modelu oraz w trudne zadania wymagające wykrywania błędów, a logikę deterministyczną, taką jak obliczenia datowe, przenieście poza model.
Literatura pokrewna
- Wybór frameworku agenta AI w Pythonie w 2026 roku: Praktyczne porównanie — Porównuje pięć frameworków agentów AI w Pythonie pod kątem sposobu radzenia sobie z awariami i złożonością, pomagając czytelnikom dobrać odpowiedni narzędzie do swojego procesu pracy.
- Od surowego tekstu do pipeline’ów: parserzy, LCEL, runnable’y i pamięć w LangChain — Jak LangChain przekształca surowy tekst modelu w dane strukturyzowane, łączy kroki za pomocą LCEL i interfejsu Runnable oraz obsługuje pamięć konwersacyjną obecnie.