PydanticAI թե LangGraph․ պարզ Python-ը բախվում է վերականգնվող գրաֆին

Գործիք կանչող և կառուցվածքային պատասխան վերադարձնող գործակալի համար PydanticAI-ն սովորաբար ավելի ուղիղ մեկնարկ է։ Երբ աշխատանքը պետք է անցնի հստակ փուլերով, սպասի մարդու որոշմանը և շարունակի պահպանված վիճակից, LangGraph-ի գրաֆային կառուցվածքն ավելի նպատակային է։ PydanticAI-ի պաշտոնական համեմատությունը նկարագրում է տիպավորված Agent-ը՝ սովորական Python-ի կառավարման հոսքով, և pydantic-graph-ը՝ բացահայտ գրաֆ պահանջող դեպքերի համար։

Ընտրության առանցքը աշխատանքի վիճակն է։ LangGraph-ում checkpointer-ի միջոցով պահպանվում է առանձին thread-ի գրաֆային վիճակը, որպեսզի հնարավոր լինի շարունակել ընդհատված աշխատանքը կամ վերականգնվել խափանումից։ Կարճ հարցում–գործիք–պատասխան հոսքի համար այդ կառուցվածքը լրացուցիչ կարգավորում է, իսկ երկարատև աշխատանքի համար՝ հաճախ հենց անհրաժեշտ մեխանիզմը։

Նույն գործակալը՝ երկու կառուցվածքով

Պատկերացնենք պայմանական գործակալ, որը ստանում է հարցը, որոնում է տվյալներ, կազմում պատասխան և, անհրաժեշտության դեպքում, սպասում է հաստատման՝ արտաքին համակարգում գործողություն կատարելուց առաջ։ Սա կառուցվածքները համեմատելու օրինակ է, ոչ թե կատարված փորձարկում։ Մոդելը, որոնման գործիքը և սպասվող արդյունքը երկու իրականացումներում նույնն են. փոխվում է քայլերն ու դրանց վիճակը ներկայացնելու եղանակը։

PydanticAI-ի տարբերակում մշակողը սահմանում է Agent-ը, գործիքի Python ֆունկցիան, անհրաժեշտ կախվածությունները և պատասխանի տիպը։ Որոնումից հետո պայմանական ստուգումը կարող է մնալ սովորական Python կոդում։ Մշակողը կարող է առաջադրանքի տրամաբանությունը կարդալ որպես ֆունկցիաների և պայմանների հաջորդականություն՝ առանց յուրաքանչյուր անցման համար առանձին գրաֆային հանգույց սահմանելու։

LangGraph-ի տարբերակում պետք է որոշել, թե ինչ տվյալներ են կազմում վիճակը, որ հանգույցն է որոնում, որը՝ կազմում պատասխանը, և ինչ պայմանով է աշխատանքն անցնում հաստատման փուլ։ Այդ կառուցվածքը պահանջում է ավելի շատ նախնական որոշումներ, բայց նաև տեսանելի է դարձնում քայլերի սահմանները։ Եթե յուրաքանչյուր փուլից հետո պետք է պահպանել վիճակը կամ կառավարել հաջորդ անցումը, այդ հավելյալ կոդը կատարում է կոնկրետ գործառույթ։ Հրապարակված համադրելի տողաքանակ այս պայմանական գործակալի համար չկա, հետևաբար կոդի ծավալը ճիշտ է գնահատել ըստ անհրաժեշտ կառուցվածքների, ոչ թե հորինված թվային առավելության։

Ինչ է իրականում վերականգնվում

LangGraph-ի checkpoint-ը պահում է thread-ի գրաֆային վիճակի պատկերը։ Եթե որոնման փուլն ավարտվել է, իսկ հետագա աշխատանքը դադարել է, պահպանված վիճակը կարող է ծառայել շարունակության համար։ Սակայն հիշողության մեջ աշխատող InMemorySaver-ը գործընթացի վերամեկնարկից հետո կորցնում է checkpoint-ները. խափանումից վերականգնման համար անհրաժեշտ է մշտական պահեստով checkpointer կամ այդ գործառույթը տրամադրող սերվեր։ Պահեստավորումը նաև պահանջում է որոշել checkpoint-ների պահպանման ժամկետն ու մաքրման կարգը։

PydanticAI-ի պարզ Agent-ը երկարատև աշխատանքի միակ տարբերակը չէ։ Նրա երկարատև կատարման փաստաթղթերը նկարագրում են արտաքին կատարման շարժիչների ինտեգրումներ, որոնցում մոդելի յուրաքանչյուր հարցում և գործիքի յուրաքանչյուր կանչ առանձին վերականգնվող միավոր է։ Այստեղ նախագծային ընտրությունը փոխվում է. կարելի է պահպանել Agent-ի շուրջ գրված Python հոսքը և միացնել կատարման շարժիչ, կամ աշխատանքի անցումները ներկայացնել բացահայտ գրաֆով։ PydanticAI-ի pydantic-graph-ը ևս առաջարկում է գրաֆային ճանապարհ, եթե այդպիսի վերահսկում պետք է հենց այդ էկոհամակարգում։

Վերականգնումը չի վերացնում արտաքին գործողության կրկնության վտանգը։ Եթե պայմանական գործակալը որոնում է միայն ընթերցման համար, նույն կանչի կրկնումը սովորաբար կառավարելի է։ Եթե այն վճարում է կատարում կամ գրառում փոխում, մշակողը պետք է որոշի՝ ինչպես ճանաչել արդեն ավարտված գործողությունը և որտեղ պահել դրա արդյունքը։ Պահպանված ներքին վիճակը դեռ չի երաշխավորում, որ արտաքին համակարգը նույն հարցումը երկու անգամ չի կատարի։

Հաստատման պահին որտեղ է կանգնում աշխատանքը

Մարդու հաստատում սպասող հոսքում LangGraph-ի ընդհատումը դառնում է գրաֆի կատարման մաս։ LangGraph-ի ընդհատումների ուղեցույցը նկարագրում է հանգույցի ներսում interrupt() կանչը, վիճակի պահպանումը և նույն thread_id-ով Command(resume=...) միջոցով շարունակությունը։ Այս եղանակով սպասող որոշումը կապված է կոնկրետ աշխատանքի պահպանված վիճակին։ Արտադրական միջավայրում դրա համար պետք է մշտական checkpointer։

Շարունակության ժամանակ ընդհատված հանգույցը կատարվում է սկզբից. interrupt()-ից առաջ եղած կոդը կրկին աշխատում է։ Ուստի արտաքին փոփոխություն կատարող կանչը նույն հանգույցում հաստատման սպասումից առաջ տեղադրելը կարող է կրկնակի գործողության պատճառ դառնալ։ Պայմանական օրինակում հաստատումը պետք է նախորդի այդպիսի կանչին, իսկ արդեն կատարված գործողությունները պետք է ունենան կրկնումը ճանաչելու հստակ եղանակ։

PydanticAI-ով հաստատումը նույնպես հնարավոր է կազմակերպել հավելվածի հոսքում կամ երկարատև կատարման շարժիչով։ Այդ ընտրության դեպքում պետք է հստակ սահմանել՝ որտեղ է պահվում սպասող որոշումը, ինչպես է այն կապվում գործակալի կոնկրետ գործարկմանը և որ քայլից է շարունակվում աշխատանքը։ LangGraph-ը նույն հարցերին պատասխանում է գրաֆի վիճակի ու ընդհատման կառուցվածքով. դրա գինն այդ կառուցվածքը նախագծելն ու պահպանելն է։

Զուգահեռ կանչերը և հրապարակված չափումները

Գրաֆ ունենալը ինքնին չի արագացնում գործիքների կանչերը։ Եթե երկու որոնում իրարից անկախ են, դրանք կարելի է նախատեսել զուգահեռ կատարման համար. եթե երկու քայլ փոխում են նույն արտաքին գրառումը, պետք է սահմանել դրանց հերթականությունը կամ համաժամեցումը։ Գործնական տարբերությունն այն է, թե որտեղ են երևում այդ կախվածությունները՝ Python-ի կառավարման հոսքո՞ւմ, թե՞ գրաֆի ճյուղերի և միացման կետերի մեջ։ Սա առանձին որոշում է checkpoint-ներով վերականգնումից։

Հրապարակված թվերը ցույց են տալիս, թե ինչու framework-ի անունից միայն արագություն եզրակացնել չի կարելի։ AgentRace-ի GAIA աղյուսակում ճիշտ ավարտված դեպքերի միջինը PydanticAI-ի համար մոտ 14 780 token և 26,24 վայրկյան է, իսկ LangChain-ի համար՝ մոտ 9 996 token և 32,49 վայրկյան. այդ փորձերում լռելյայն մոդելը GPT-4o-ն էր։ Այս կոնֆիգուրացիայում պակաս token-ը չէր ուղեկցվում պակաս ընդհանուր ժամանակով. աղյուսակը նաև առանձնացնում է մոդելի և գործիքների վրա ծախսված ժամանակը։

Այդ թվերը LangGraph-ի չափումներ չեն. համեմատվող մյուս իրականացումը LangChain-ն է։ Դրանք չեն չափում նաև խափանումից վերականգնման հուսալիությունը կամ մեր պայմանական գործակալի սկզբնական կոդի ծավալը։ Token-ների, ուշացման և գործիքների կատարման ժամանակի մասին եզրակացությունը պետք է պահել հենց տվյալ առաջադրանքի, մոդելի, գործիքների և ավարտված դեպքերի սահմաններում։

Ընտրությունը՝ ըստ աշխատանքի բնույթի

• Կարճ, տիպավորված գործակալ։ Երբ աշխատանքը հիմնականում գործիքի կանչ է և կառուցվածքային պատասխան, PydanticAI Agent-ը թույլ է տալիս տրամաբանությունը պահել սովորական Python հոսքում։ Վիճակի առանձին գրաֆը քիչ արժեք է ավելացնում, եթե շարունակության սահմաններ չկան։
• Երկարատև հոսք՝ մարդու որոշմամբ։ Երբ հաստատման սպասումը և դրանից հետո նույն աշխատանքին վերադառնալը հիմնական պահանջներ են, LangGraph-ի վիճակն ու interrupt()-ը տալիս են այդ անցումների բացահայտ կառուցվածքը։ Պետք է նախատեսել մշտական checkpointer և հանգույցի կրկնվող կատարման անվտանգ վարք։
• Խափանումից շարունակվող բազմաքայլ աշխատանք։ Այստեղ երկու ճանապարհն էլ արժե դիտարկել. LangGraph-ը՝ երբ կարևոր է կառավարել գրաֆի վիճակն ու անցումները, PydanticAI-ն երկարատև կատարման շարժիչով՝ երբ ցանկալի է պահպանել Agent-ի շուրջ կառուցված Python հոսքը։ Երկու դեպքում էլ արտաքին գործողությունների կրկնության կանոնները պետք է նախագծել առանձին։

Կարդացեք նաև:

• OpenAI Agents SDK թե LangGraph․ արագ մեկնարկը բախվում է վերականգնվող վիճակին
• LangGraph թե CrewAI․ գրաֆային վերահսկո՞ւմ, թե դերային թիմ
• Buffer թե Hootsuite․ երեք ալիքի պարզությունը բախվում է սոցիալական լսմանը