Kaj smo se naučili ob uvedbi ChatGPT Apps SDK

• Apps SDK je praktična izbira, če kmalu potrebujete potek dela v ChatGPT ali želite tam preizkusiti svoja orodja, preden vložite v lastno tehnološko ogrodje za agente. Če morate v celoti obvladovati vsak korak vedenja agenta, pa običajno ni prava izbira.

• Apps SDK izberite, ko naj bo ChatGPT glavni uporabniški vmesnik, vi pa želite orodja in manjše elemente uporabniškega vmesnika, ne da bi razvili celoten izdelek za klepet. Lastno tehnološko ogrodje za agente izberite, ko potrebujete strog nadzor nad potekom, pomnilnikom, pozivi in zapisovanjem podatkov.

• Apps SDK je primeren za izdelke, ki klepet združujejo z nekaj kratkimi koraki v uporabniškem vmesniku. Izdelek uvedete hitreje, vendar se odrečete delu nadzora.

• Pri nas so se obnesli jasno opredeljena orodja, jasno vedenje gradnikov in jasni naslednji koraki. Potek smo določali na podlagi teh elementov, ne velikega jezikovnega modela. Model je bil najuporabnejši pri pojasnjevanju rezultatov, ki jih je sistem že izbral.

• V nadaljevanju pojasnjujemo, kako izbrati ter kaj se je obneslo in kaj ne.

Večina ekip še vedno izvaja pilotne projekte umetne inteligence ali jo uporablja za obrobne namene z majhnim tveganjem in donosom. Le redke uvedejo poslovno kritičen izdelek, ki ga uporabniki uporabljajo vsak teden. ChatGPT Apps SDK je eden od načinov za premostitev te vrzeli, če želite rešitev vključiti v ChatGPT, namesto da bi celotnega pomočnika razvili sami.

Naše ugotovitve izhajajo iz projekta za naročnika, pri katerem so zahteve kot glavni uporabniški vmesnik narekovale ChatGPT in hitro izvedbo brez financiranja povsem prilagojenega izdelka za klepet.

Apps SDK je ustrezal tem zahtevam, saj je naročnik potreboval naslednje:

• Brez razvoja in gostovanja namenskega izdelka za klepet – želeli so doseg znotraj ChatGPT, ne še enega samostojnega ogrodja za pomočnika.

• Klepet in majhen, nalogam prilagojen uporabniški vmesnik – nekaj osredotočenih korakov v gradnikih, ne drugega celovitega izdelka znotraj poteka dela.

• Zaledne funkcije, izpostavljene prek orodij MCP – standardno klicanje orodij, ne lastnega izvajalnega okolja agenta, ki bi ga v celoti upravljali sami.

• Odkrivanje znotraj ChatGPT – uporabniki naj potek dela najdejo tam, kjer že delajo.

Te odločitve smo med razvojem preverjali skupaj z naročnikom. Kompromis ostaja: ko se seja izvaja v ChatGPT, zunanje izvajalno okolje ni pod vašim nadzorom. Lahko ga usmerjate, ne morete pa ga povsem nadzorovati.

Aplikacija, izdelana z Apps SDK, povezuje tri elemente:

1. izvajalno okolje agenta v ChatGPT

2. vaša orodja MCP

3. uporabniški vmesnik vašega gradnika

Potek v praksi:

1. Uporabnik nekaj zahteva od ChatGPT.

2. ChatGPT lahko pokliče eno od vaših orodij MCP.

3. Vaš strežnik vrne strukturiran rezultat orodja.

4. ChatGPT prebere rezultat in določi naslednji korak: dodatne klice orodij, odgovor uporabniku ali oboje. Če ste temu orodju dodali gradnik, se lahko prikaže v tem koraku pogovora.

5. Uporabnik nadaljuje v klepetu ali gradniku z dodatnim besedilom, izbiro ali klicem orodja, ki ga sproži gradnik. S tem se nit posodobi – ChatGPT izvede nov korak, koraki od 2 do 4 pa se ponavljajo, dokler naloga ni končana.

Bistvo je prav v tej kombinaciji klepeta, zalednih dejanj in kratkih korakov v uporabniškem vmesniku. To tudi pomeni, da so najobčutljivejši deli prehodi med klepetom, orodji in uporabniškim vmesnikom.

Uporabniškega vmesnika za klepet, povezovanja orodij, vzorcev preverjanja pristnosti in ogrodja gradnikov vam ni treba razvijati od začetka. Pri številnih izdelkih to močno skrajša razvoj, zato se lahko osredotočite na področno logiko in varovala.

Razvoj znotraj ChatGPT ni enak uporabi lastnega agenta. Najtežji del projekta niso bili triki s pozivi. Orodja, gradnike in naslednje korake je bilo treba opredeliti dovolj jasno, da sta model in uporabniški vmesnik ostala usklajena.

Apps SDK omogoča drugačno zasnovo izdelka kot običajen sprednji del, zato je treba vedeti, za katere primere je najprimernejši.

Apps SDK uporabite, ko želite:

• hitro uvesti potek dela v ChatGPT,

• pogovor gostiti v ChatGPT,

• naravni jezik združiti z nekaj osredotočenimi koraki v uporabniškem vmesniku,

• se izogniti razvoju lastnega vmesnika za klepet, vsebnika za agenta in mehanizma odkrivanja.

Zadnja točka je pomembna, če vaši uporabniki že delajo v ChatGPT.

Lastnega agenta razvijte, ko potrebujete:

• nespremenljiv potek po korakih, ki ga lahko uveljavite s kodo,

• prilagojen uporabniški vmesnik in potrditveni postopek, ki ju v celoti upravljate sami,

• lasten model pomnilnika in stanja,

• vedenje, ki mora biti predvidljivo ob vsakem izvajanju,

• sledi, dnevnike in metrike za agenta.

Če so načrtovalnik, sistemski pozivi in celoten potek dela vaš izdelek, je lastno tehnološko ogrodje običajno primernejše.

Pri našem projektu se je vedno znova pojavljala beseda nadzor: na eni strani hitrost in znano gostiteljsko okolje, na drugi pa le delno lastništvo izvajalnega okolja. Naročnik je ta kompromis sprejel, ko je srečanje z uporabniki v ChatGPT postavil pred lastništvo celotnega tehnološkega sklada.

Idealen potek zveni preprosto: uporabnik poda zahtevo, orodje se zažene, podatki se vrnejo, gradnik pa se prikaže, ko je potrebna izbira.

V praksi so težave povzročali prehodi. Gradnik ni okras. Ko se prikaže na zaslonu, spremeni, kaj model vidi in naredi v naslednjem koraku. Dejanja gradnika obravnavajte kot poimenovane dogodke, ne kot nedoločen klepet.

Tehnološki sklad pri projektu je bil preprost: FastMCP, Pydantic, React in TypeScript. Njihova integracija ni bila težavna. Pravi izziv je bil uskladiti model, orodja in uporabniški vmesnik glede naslednjega koraka.

Vsak prehod naj bo nedvoumen

Rezultate orodij smo prenehali obravnavati kot neobdelane podatke zalednega sistema. Vsak vrnjeni rezultat je postal prehod.

Dober rezultat orodja:

• Gradniku zagotovi vse, kar potrebuje za prikaz.

• ChatGPT zagotovi strukturirana dejstva, na katerih lahko temelji odgovor.

• Ko potek to zahteva, navede naslednji korak, da modelu ni treba ugibati.

Dejanja gradnika v nit ne smejo pošiljati nejasnega prostega besedila. Navesti morajo, kaj je uporabnik storil in kaj naj sledi.

Ko so prehodi postali jasni, se je zanesljivost izboljšala.

Model upošteva kratka in jasna navodila, kadar so vključena v rezultat orodja in dejanja gradnika.

Spodaj je manjša struktura Pydantic, ki smo jo uporabljali. Polje output vsebuje strukturirane podatke, ki jih gradnik potrebuje za prikaz, in dejstva, ki naj jih ChatGPT uporabi v seji. Polje agent_directions vsebuje kratko navodilo, kaj naj pomočnik stori v naslednjem koraku. Polje Reason ni obvezno.

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

Gradniki naj bodo majhni

Gradniki, ki so se obnesli, so omogočili eno odločitev in nato vrnili nadzor. Kratki seznami, potrditve ali zgoščen pregledni zaslon so delovali bolje kot spreminjanje gradnika v manjšo aplikacijo. Nekaj logike v gradniku, denimo preprosto preverjanje veljavnosti ali vnaprej določen naslednji korak, je pomagalo, ko smo želeli bolj determinističen potek.

Tretja oseba v sporočilih gradnika

Nadaljnjih sporočil gradnika nismo več pisali kot uporabnikov klepet (»I selected…«, »I confirmed…«). Zapisali smo jih kot kratka poročila o uporabnikovem dejanju (»The user selected…«, »The user confirmed…«). Ta pristop smo preizkusili, ker je ChatGPT sporočila gradnika dodajal kot sporočila orodja in ne uporabnika.

Neposredna dejanja, ko je naslednji korak očiten

Če je gumb jasno nakazoval naslednji klic orodja, se je neposredno proženje iz gradnika obneslo bolje kot vsiljevanje še enega koraka klepeta. To velja le, če naslednji klic orodja ne potrebuje vhodnih podatkov iz ChatGPT.

Tako smo lažje uveljavili deterministične poteke in zmanjšali zakasnitev, saj smo se izognili dodatnemu koraku klepeta.

Obravnavanje napak

Ko klic orodja ni uspel, smo iz orodja vrnili ustrezne kode napak MCP ter kratka in jasna sporočila. ChatGPT je tako ob neuspelem klicu prejel dejanske informacije, na podlagi katerih je lahko uporabniku pojasnil težavo oziroma izbral smiseln naslednji korak.

Upravljanje konteksta orodij

Stanje seje smo hranili na svojem strežniku. ChatGPT s klici orodij pošilja kontekst posamezne seje; v FastMCP smo vsakemu orodju dodali parameter Context, da je obdelovalnik lahko bral in posodabljal to stanje.

• Stabilne identifikatorje in prejšnje rezultate smo hranili v seji, namesto da bi moral ChatGPT ob vsakem klicu znova posredovati te podatke kot argumente orodja.

• Ko so se pojavile zanke klicev orodij, smo lahko zaznali podvojene klice in prek rezultata orodja vrnili jasno napako.

• Dnevnike sej smo zaradi razhroščevanja in podpore hranili pri sebi.

Sprva smo prikazali gradnik, domnevali, da je model »razumel«, in čakali na pravi naslednji klic orodja. Včasih se je to zgodilo. Pogosto pa ne.

Brez jasnega prehoda je ChatGPT lahko povzel vsebino, ko smo želeli dejanje, uporabnika pozval, naj ponovi izbiro, ali nadaljeval načrtovanje, ko bi se moral ustaviti.

Rešitev je bila, da smo naslednji korak izrecno navedli v strukturiranih izhodih in podatkih gradnika, namesto da bi upali, da ga bo model razbral sam.

V skladu z dokumentacijo za Apps SDK smo poskusili odgovore domiselno razdeliti med rezultat orodja, skrite metapodatke in besedilo klepeta. Vendar v gradnikih nismo mogli brati skritih metapodatkov. Zato tega pristopa nismo mogli uporabiti.

Dokumentacija za Apps SDK opisuje orodja, ki jih lahko izločite s seznama orodij agenta, da jih ta ne izbere, še vedno pa jih kličete iz gradnika. Ko smo vidnost nastavili na app-only, ta orodja niso bila več na voljo niti gradniku, ne le agentu. Ni nam uspelo vzpostaviti konfiguracije, v kateri agent orodja ne bi videl, gradnik pa bi ga še vedno lahko uporabljal.

Tišina ali splošno sporočilo »uspešno«, ko se ni zgodilo nič koristnega, sta bila slabša od neposredne napake. Napake orodij in gradnikov smo zato obravnavali kot polnopravne izhode: če koraka ni bilo mogoče nadaljevati, smo to jasno povedali in vrnili izrecno napako, namesto da bi uporabnika pustili pred prikazanim gradnikom, ki ga ni pripeljal naprej. S tem smo izboljšali uporabnost in povečali zanesljivost vedenja modela.

Če želite potek dela v ChatGPT z manj razvoja lastne platforme, je Apps SDK praktična pot do tega cilja. Del nadzora zamenjate za hitrost in možnost, da uporabnike dosežete tam, kjer že delajo.

Če morate nadzorovati vsako vejo poteka, uporabniški vmesnik in odločanje o vsakem koraku, že od začetka načrtujte lastno tehnološko ogrodje za agente. Razvoj izključno znotraj ChatGPT boste verjetno sčasoma prerasli.

Z Apps SDK lahko svoj strežnik MCP najprej izvajate znotraj ChatGPT, preden sami razvijete klepet, preverjanje pristnosti in povezave z agentom, nato pa preidete na lastno tehnološko ogrodje, ko to zahteva izdelek.

Naslednji korak za ekipe v podobnem položaju: izberite en potek dela z jasnim rezultatom, zapišite prehode med klepetom, orodji in gradniki ter pred obsežnejšim prilagajanjem pozivov temeljito preizkusite ponovne poskuse in napake.