Ինչ սովորեցինք ChatGPT Apps SDK-ով պրոդուկտ թողարկելիս

• Apps SDK-ն գործնական տարբերակ է, եթե շուտով ChatGPT-ում աշխատանքային հոսք է պետք, կամ եթե ցանկանում եք այնտեղ փորձարկել ձեր գործիքները՝ նախքան անհատական ագենտային տեխնոլոգիական փաթեթում ներդրում անելը։ Սակայն եթե պետք է լիովին վերահսկեք ագենտի վարքի յուրաքանչյուր քայլը, այն սովորաբար հարմար չէ։

• Ընտրեք Apps SDK-ն, երբ ChatGPT-ն պետք է լինի հիմնական միջավայրը, իսկ ձեզ պետք են գործիքներ և միջերեսի փոքր տարրեր՝ առանց զրույցի լիարժեք պրոդուկտ ստեղծելու։ Ընտրեք ձեր սեփական ագենտային տեխնոլոգիական փաթեթը, երբ անհրաժեշտ է խիստ վերահսկել հոսքը, հիշողությունը, հարցումները և գրառումները։

• Apps SDK-ն հարմար է այն պրոդուկտների համար, որոնք զրույցը համատեղում են միջերեսում կատարվող մի քանի կարճ քայլերի հետ։ Դուք ավելի արագ եք թողարկում պրոդուկտը, բայց որոշ չափով զիջում եք վերահսկողությունը։

• Մեզ համար արդյունավետ էին հստակ գործիքները, վիջեթի հստակ վարքը և հստակ հաջորդ քայլերը։ Հոսքը կառուցելիս մենք հիմնվեցինք դրանց, ոչ թե LLM-ի վրա։ Մոդելն առավել օգտակար էր, երբ բացատրում էր համակարգի արդեն իսկ ընտրած արդյունքները։

• Ստորև կքննարկենք՝ ինչպես ընտրել, ապա՝ ինչն աշխատեց, իսկ ինչը՝ ոչ։

Թիմերի մեծ մասը դեռ փորձարկում է ԱԲ-ն կամ կիրառում այն երկրորդական, ցածր ռիսկով և օգուտով խնդիրների համար։ Քչերն են թողարկում բիզնեսի համար առանցքային պրոդուկտ, որից օգտատերերն օգտվում են ամեն շաբաթ։ ChatGPT Apps SDK-ն այդ բացը լրացնելու տարբերակներից մեկն է, եթե ցանկանում եք աշխատել ChatGPT-ի ներսում, ոչ թե ինքնուրույն ստեղծել ամբողջ օգնականը։

Մեր փորձը ձևավորվել է հաճախորդի նախագծից, որի պահանջները մատնանշում էին ChatGPT-ն՝ որպես հիմնական միջավայր, և արագ լուծում, որը չէր պահանջի ֆինանսավորել զրույցի ամբողջությամբ անհատական պրոդուկտի ստեղծումը։

Այս պահանջներին Apps SDK-ն համապատասխանում էր, քանի որ հաճախորդին անհրաժեշտ էր՝

• Չստեղծել և չհոսթավորել առանձին զրույցի պրոդուկտ․ նրանց պետք էր հասանելիություն ChatGPT-ի ներսում, ոչ թե ևս մեկ ինքնուրույն օգնականի միջավայր։

• Զրույց և կոնկրետ խնդիրների համար նախատեսված փոքր միջերես․ վիջեթում մի քանի հստակ քայլ, ոչ թե աշխատանքային հոսքի ներսում երկրորդ լիարժեք պրոդուկտ։

• MCP գործիքներով հասանելի սերվերային վարք․ գործիքների ստանդարտ կանչեր, ոչ թե ամբողջությամբ սեփական անհատական ագենտային գործարկման միջավայր։

• Հայտնաբերում ChatGPT-ի ներսում․ օգտատերերը պետք է հանդիպեն աշխատանքային հոսքին այնտեղ, որտեղ արդեն աշխատում են։

Մշակման ընթացքում այդ ընտրությունները հաստատում էինք հաճախորդի հետ։ Փոխզիջումը մնում է նույնը․ երբ աշխատաշրջանը հոսթավորում է ChatGPT-ն, արտաքին գործարկման միջավայրը ձեզ չի պատկանում։ Դուք ուղղորդում եք այն, բայց լիովին չեք վերահսկում։

Apps SDK-ով հավելվածը կապում է երեք բաղադրիչ՝

1. ChatGPT-ի ագենտային գործարկման միջավայրը

2. Ձեր MCP գործիքները

3. Ձեր վիջեթի միջերեսը

Հոսքը գործնականում՝

1. Օգտատերը ինչ-որ բան է խնդրում ChatGPT-ից։

2. ChatGPT-ն կարող է կանչել ձեր MCP գործիքներից մեկը։

3. Ձեր սերվերը վերադարձնում է գործիքի կառուցվածքային արդյունք։

4. ChatGPT-ն կարդում է այդ արդյունքը և որոշում հաջորդ քայլը՝ գործիքների լրացուցիչ կանչեր, պատասխան օգտատիրոջը կամ երկուսը միասին։ Եթե այդ գործիքին վիջեթ եք կցել, այն կարող է ցուցադրվել այս հերթում։

5. Օգտատերը շարունակում է զրույցում կամ վիջեթում՝ լրացուցիչ գրությամբ, ընտրությամբ կամ վիջեթի նախաձեռնած գործիքի կանչով։ Դա թարմացնում է շղթան, ChatGPT-ն կատարում է ևս մեկ հերթ, և 2–4-րդ քայլերը կրկնվում են մինչև առաջադրանքի ավարտը։

Հենց զրույցի, սերվերային գործողությունների և միջերեսի կարճ քայլերի այս համադրությունն է նպատակը։ Սա նաև նշանակում է, որ խոցելի մասերը զրույցի, գործիքների և միջերեսի միջև անցումներն են։

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

ChatGPT-ի ներսում ստեղծելը նույնը չէ, ինչ սեփական ագենտը գործարկելը։ Նախագծի բարդ մասը հարցումների հնարքները չէին։ Պետք էր գործիքները, վիջեթները և հաջորդ քայլերն այնքան հստակ դարձնել, որ մոդելն ու միջերեսը համաձայնեցված աշխատեին։

Apps SDK-ն առաջարկում է ձեր սովորական օգտատիրոջ միջերեսից տարբերվող պրոդուկտային ձևաչափ, ուստի կարևոր է իմանալ՝ որ դեպքերի համար է այն լավագույնը։

Օգտագործեք Apps SDK-ն, երբ ցանկանում եք՝

• Արագ թողարկել ChatGPT-ի աշխատանքային հոսք։

• Զրույցի հոսթավորումը վստահել ChatGPT-ին։

• Բնական լեզուն համատեղել միջերեսի մի քանի հստակ քայլերի հետ։

• Չստեղծել սեփական զրույցի միջերեսը, ագենտային կոնտեյները և հայտնաբերման մեխանիզմը։

Վերջին կետը կարևոր է, երբ ձեր օգտատերերն արդեն մշտապես աշխատում են ChatGPT-ում։

Ստեղծեք ձեր սեփական ագենտը, երբ անհրաժեշտ է՝

• Կոդով պարտադրվող, քայլ առ քայլ ֆիքսված հոսք։

• Լիովին ձեզ պատկանող անհատական միջերես և հաստատման գործընթաց։

• Հիշողության և վիճակի ձեր սեփական մոդելը։

• Յուրաքանչյուր գործարկման ժամանակ կանխատեսելի վարք։

• Ագենտի հետքերը, մատյանները և չափորոշիչները։

Եթե պլանավորողը, համակարգային հարցումները և ամբողջ աշխատանքային հոսքը ձեր պրոդուկտն են, սովորաբար անհատական տեխնոլոգիական փաթեթն ավելի հարմար է։

Մեր նախագծում կրկին ու կրկին հնչող բառը «վերահսկողությունն» էր․ մի կողմում՝ արագությունն ու ծանոթ հոսթը, մյուսում՝ գործարկման միջավայրի մասնակի սեփականությունը։ Հաճախորդն ընդունեց այդ փոխզիջումը, երբ ամբողջ տեխնոլոգիական փաթեթը տնօրինելու փոխարեն առաջնահերթ համարեց օգտատերերին ChatGPT-ում հասանելի լինելը։

Իդեալական ընթացքը պարզ է թվում․ օգտատերը հարցնում է, գործիքը գործարկվում է, տվյալները վերադառնում են, իսկ ընտրության պահին հայտնվում է վիջեթը։

Գործնականում դժվարությունը անցումներն էին։ Վիջեթը զարդարանք չէ։ Էկրանին հայտնվելուն պես այն փոխում է, թե մոդելն ինչ է տեսնում և անում հաջորդիվ։ Վիջեթի գործողություններին վերաբերվեք որպես անվանված իրադարձությունների, ոչ թե ազատ զրույցի։

Նախագծի տեխնոլոգիական փաթեթը պարզ էր՝ FastMCP, Pydantic, React և TypeScript։ Դրանց ինտեգրումը խնդիր չէր։ Հիմնական աշխատանքը մոդելի, գործիքների և միջերեսի միջև հաջորդ քայլի շուրջ համաձայնություն ապահովելն էր։

Յուրաքանչյուր անցում ակնհայտ դարձրեք

Մենք դադարեցինք գործիքների արդյունքները դիտարկել որպես սերվերային չմշակված տվյալներ։ Յուրաքանչյուր վերադարձ դարձավ անցում։

Գործիքի լավ արդյունքը՝

• Վիջեթին տալիս է ցուցադրման համար անհրաժեշտ տվյալները։

• ChatGPT-ին տալիս է կառուցվածքային փաստեր, որոնց վրա այն կարող է հիմնել պատասխանը։

• Երբ հոսքը պահանջում է, նշում է հաջորդ քայլը, որպեսզի մոդելը ստիպված չլինի կռահել։

Վիջեթի գործողությունները չպետք է անորոշ տեքստ վերադարձնեն զրույցի շղթա։ Դրանք պետք է նշեն՝ ինչ է արել օգտատերը և ինչ պետք է տեղի ունենա հաջորդիվ։

Երբ անցումները հստակ դարձան, հուսալիությունն աճեց։

Մոդելը հետևում է կարճ ու հստակ հրահանգներին, երբ դրանք ներառված են գործիքի արդյունքում և վիջեթի գործողություններում։

Ստորև բերված է մեր օգտագործած Pydantic-ի փոքր սխեման։ output դաշտը պարունակում է ցուցադրվող վիջեթին անհրաժեշտ կառուցվածքային տվյալները և այն փաստերը, որոնք ChatGPT-ն պետք է օգտագործի աշխատաշրջանում։ agent_directions դաշտը պարունակում է կարճ տող, որը նշում է՝ ինչ պետք է անի օգնականը հաջորդիվ։ reason դաշտը պարտադիր չէ։

1from typing import Generic, TypeVar2
3from pydantic import BaseModel4
5T = TypeVar("T")6
7class AgentDirections(BaseModel):8 assistant_instruction: str9 reason: str | None = None10
11class ToolResults(BaseModel, Generic[T]):12 agent_directions: AgentDirections13 output: T

Վիջեթները փոքր պահեք

Արդյունավետ վիջեթներն ապահովում էին մեկ որոշման կայացումը, ապա վերադարձնում վերահսկողությունը։ Կարճ ցուցակները, հաստատումները կամ հակիրճ վերանայման էկրանն ավելի արդյունավետ էին, քան վիջեթը փոքր հավելվածի վերածելը։ Վիջեթի ներսում փոքր-ինչ տրամաբանությունը, օրինակ՝ պարզ վավերացումը կամ ֆիքսված հաջորդ քայլը, նույնպես օգտակար էր, երբ ցանկանում էինք հոսքն ավելի որոշակի դարձնել։

Երրորդ դեմք՝ վիջեթի հաղորդագրություններում

Մենք դադարեցինք վիջեթի հետագա հաղորդագրությունները գրել որպես օգտատիրոջ զրույցի խոսք («I selected…», «I confirmed…»)։ Փոխարենը դրանք գրում էինք որպես օգտատիրոջ գործողության մասին կարճ զեկույցներ («The user selected…», «The user confirmed…»)։ Այս մոտեցումը փորձեցինք, քանի որ ChatGPT-ն վիջեթի հաղորդագրություններն ավելացնում էր որպես գործիքի, ոչ թե օգտատիրոջ հաղորդագրություններ։

Ուղիղ գործողություններ, երբ հաջորդ քայլն ակնհայտ է

Եթե կոճակն ակնհայտորեն ենթադրում էր գործիքի հաջորդ կանչը, ավելի արդյունավետ էր թույլ տալ, որ վիջեթն այն անմիջապես նախաձեռնի, քան պարտադրել զրույցի ևս մեկ հերթ։ Սա կիրառելի է միայն այն դեպքում, երբ գործիքի հաջորդ կանչը ChatGPT-ից մուտքային տվյալներ չի պահանջում։

Սա օգնեց ապահովել որոշակի հոսքեր և նվազեցրեց ուշացումը՝ խուսափելով զրույցի ևս մեկ հերթից։

Սխալների մշակում

Երբ գործիքի կանչը ձախողվում էր, գործիքից վերադարձնում էինք MCP-ի ճիշտ սխալի կոդերը և կարճ, պարզ հաղորդագրություններ։ Այդպես ChatGPT-ն ձախողված կանչերի դեպքում իրական տեղեկություն էր ստանում և կարող էր օգտատիրոջը բացատրել խնդիրը և/կամ ընտրել ողջամիտ հաջորդ քայլ։

Գործիքի համատեքստի կառավարում

Աշխատաշրջանի վիճակը պահում էինք մեր սերվերում։ ChatGPT-ն գործիքների կանչերի հետ ուղարկում է աշխատաշրջանի համատեքստը․ FastMCP-ում յուրաքանչյուր գործիքին Context պարամետր տվեցինք, որպեսզի մշակիչը կարողանա կարդալ և թարմացնել այդ վիճակը։

• Կայուն ID-ներն ու նախորդ արդյունքները պահվում էին աշխատաշրջանում, և ChatGPT-ից չէր պահանջվում յուրաքանչյուր կանչի ժամանակ դրանք կրկին փոխանցել որպես գործիքի արգումենտներ։

• Երբ գործիքի կանչերի շրջափուլեր էին առաջանում, կարողանում էինք հայտնաբերել կրկնվող կանչերը և գործիքի արդյունքով վերադարձնել հստակ սխալ։

• Վրիպազերծման և աջակցության համար աշխատաշրջանի մատյանները մնում էին մեր կողմում։

Սկզբում ցուցադրում էինք վիջեթը, ենթադրում, որ մոդելը «հասկացավ», և սպասում գործիքի ճիշտ հաջորդ կանչին։ Երբեմն դա տեղի էր ունենում։ Հաճախ՝ ոչ։

Առանց հստակ անցման ChatGPT-ն կարող էր ամփոփել, երբ մեզ գործողություն էր պետք, խնդրել օգտատիրոջը կրկնել ընտրությունը կամ շարունակել պլանավորել, երբ պետք էր կանգ առնել։

Լուծումը հաջորդ քայլը կառուցվածքային արդյունքներում և վիջեթի տվյալներում հստակ նշելն էր, ոչ թե հուսալը, որ մոդելն ինքնուրույն կհասկանա։

Apps SDK-ի փաստաթղթերին հետևելով՝ փորձեցինք հնարամտորեն բաժանել պատասխանները գործիքի արդյունքի, թաքնված մետատվյալների և զրույցի տեքստի միջև։ Սակայն վիջեթներում չէինք կարող կարդալ թաքնված մետատվյալները։ Ուստի չէինք կարող օգտագործել այս մոտեցումը։

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

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

Եթե ձեր նպատակը ChatGPT-ում աշխատանքային հոսք ստեղծելն է՝ հարթակի անհատական մշակման ավելի քիչ աշխատանքով, Apps SDK-ն գործնական լուծում է։ Արագության և օգտատերերին իրենց սովորական աշխատանքային միջավայրում հասանելի լինելու դիմաց դուք զիջում եք վերահսկողության մի մասը։

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

Կարող եք նաև Apps SDK-ով ձեր MCP սերվերը գործարկել ChatGPT-ի ներսում՝ նախքան ինքնուրույն զրույցը, նույնականացումը և ագենտային կապակցումները ստեղծելը, ապա պրոդուկտի պահանջներին զուգահեռ անցնել սեփական տեխնոլոգիական փաթեթին։

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