PokeGPT: todiste siitä että GPT osaa kutsua oikeaa rajapintaa
Custom GPT joka on kytketty PokeAPIin Actionsin kautta. Henkilökohtainen Pokédex ja tekosyy selvittää mitä tapahtuu kun kielimallin on toteltava REST-skeemaa.

- 21
- myytyä kappaletta
Taustaa
PokeGPT on custom GPT joka on kytketty PokeAPIin. Kysy siltä Pokémonista ja se hakee oikean tietueen: tyypit, perustilastot, kyvyt, kehitysketjun, liikevalikoiman, luvut sellaisina kuin ne ovat peleissä eivätkä sellaisina kuin malli ne puoliksi muistaa.
Rakensin sen marraskuussa 2023, päiviä sen jälkeen kun OpenAI julkaisi Actionsin, koska halusin tietää toimiiko ominaisuus vai demoaako se vain.
Ongelma
Custom GPT:t julkaistiin suuren metelin saattelemana, ja lähes kaikki siitä oli kehotekääreitä. Persoonallisuus, sävy, järjestelmäviesti, ja alla sama malli joka vastaa samasta opetusdatasta. Ei uutta.
Actions oli se uusi osa: GPT:lle saattoi antaa OpenAPI-skeeman ja se saattoi kutsua oikeaa HTTP-palvelua. Se on ero sen välillä että chatbot on lukenut datastasi ja sen että sillä on datasi. Kukaan ei kirjoittanut siitä millaista sellaista oli rakentaa, vain siitä mitä julkistus lupasi.
PokeAPI oli ihanteellinen koekaniini. Se on julkinen, hyvin dokumentoitu, ilmainen, kohteliaasti pyyntörajoitettu, ja siinä on ominaisuus jota en olisi saanut muualta: aihepiiri jossa malli tietää jo valtavasti, väärin. Jokainen malli on imenyt itseensä vuosikausien foorumikiistat perustilastoista. Saatoin siis kysyä kysymyksen, katsoa mitä se vastasi muistista ja verrata sitä siihen mitä rajapinta palautti. Väärä vastaus näkyy välittömästi, toisin kuin useimmissa rajapintaintegraatioissa.
Oma roolini
Kaikki, omalla ajallani, ilman asiakasta. Skeema, ohjeet, testaus, myyntisivu.
Lähestymistapa
Kohtelin sitä kokeena jolla on hypoteesi enkä tuotteena jolla on tiekartta. Kysymys oli kapea: pystyykö GPT luotettavasti päättämään milloin päätepistettä kutsutaan, valitsemaan oikean ja käyttämään sitä mitä sieltä tulee sen sijaan mitä se jo uskoo.
Se kehystys asetti laajuuden. Pokédex sopii, koska kysymykset ovat riittävän vaihtelevia rasittaakseen reititystä ja oikean vastauksen voi tarkistaa sekunneissa. Rakensin pienimmän asian joka pystyi vastaamaan kysymykseen rehellisesti, ja kirjasin sitten ylös missä se epäonnistui.
Toteutus
Koko tuote on OpenAPI-skeema ja ohjelohko. Ei koodia jota ylläpidän, ei backendiä. Actions tarkoittaa että pyynnön tekee OpenAI:n ajoympäristö.
Suurin osa työstä meni skeemaan, ja se oli se löydös joka kannatti. GPT ei lue PokeAPIn dokumentaatiota, se lukee operaatioiden kuvaukset siitä skeemasta jonka annan, ja ne ovat ainoa asia joka kertoo sille milloin mitäkin päätepistettä kutsutaan. Ensimmäinen versioni kuvasi päätepisteet tarkasti ja malli kutsui silti vääriä, koska ”hae Pokémon” ja ”hae Pokémon-laji” ovat kaksi resurssia joilla on kummallakin tarkka kuvaus eikä mitään vihjettä siitä kumpi vastaa kehitystä koskevaan kysymykseen. Kuvausten kirjoittaminen uusiksi niin että ne kertovat milloin operaatiota käytetään eikä mitä se palauttaa korjasi lähes jokaisen reititysvirheen. Se on prompt engineering -ongelma API-skeeman puvussa.
Toinen ongelma oli hyötykuorman koko. Yksi PokeAPIn vastaus voi kantaa satoja liikkeitä, joista jokaisella on sisäkkäinen lista niistä peliversioista joissa se on esiintynyt. Sen pudottaminen kontekstiin polttaa tokeneita dataan jota kukaan ei pyytänyt ja työntää vastauksen ulos. Ohjeet rajaavat mihin kenttiin kysymystyypeittäin kiinnitetään huomiota ja käskevät mallia tekemään toisen kapeamman kutsun yhden valtavan sijaan. Kaksi pientä pyyntöä voittaa yhden ison, mikä on päinvastoin kuin se vaisto jonka tavallisten rajapinta-asiakkaiden kirjoittamisesta tuo mukanaan.
Kolmas oli se kiinnostava: malli vastasi muistista kutsumatta mitään. Kysy tunnetusta Pokémonista, niin se on varma asiastaan, ohittaa työkalun ja antaa uskottavan luvun jostain vanhasta wikimuokkauksesta. Korjaus oli ohjelohko jonka mukaan mikä tahansa tilastoja, tyyppejä, kykyjä tai kehityksiä koskeva faktaväite vaatii kutsun, eikä vastaaminen ilman sitä ole sallittua. Opittu tieto kilpailemassa elävän työkalun kanssa on työkaluja käyttävien mallien yleinen vikatila, ja tässä tapasin sen ensimmäisen kerran.
Ketjutetut kutsut olivat se kohta jossa se kaatui. Kehitysketju tarkoittaa lajin selvittämistä, sitten ketjun osoitetta, sitten ketjun kävelemistä läpi. Monivaiheiset sarjat olivat tuossa ensimmäisessä versiossa epäluotettavia, ja dokumentoin sen sen sijaan että olisin väittänyt muuta.
Lopputulos
21 myytyä kappaletta. Se on luku, enkä koristele sitä: se on kuriositeetti-Pokédex verkkokaupassa, ja 21 ihmistä halusi sen.
Lopputulos josta välitin oli vastaus kysymykseen. Actions toimi. GPT pystyi aidosti kutsumaan elävää REST-palvelua ja käyttämään vastausta, ja vikatilat koskivat skeeman kuvausten laatua, hyötykuorman kokoa ja opitun tiedon jyräämistä työkalukutsujen yli eivätkä putkitusta. Jokainen oppi noilta illoilta meni siihen miten rakennan nykyään työkaluja käyttäviä järjestelmiä, SignalScoutin tutkimusputki mukaan lukien, joka on sama ongelma paljon korkeammilla panoksilla.
Mitä tekisin toisin
Julkaisin skeeman joka kattoi enemmän päätepisteitä kuin tuote tarvitsi, sillä teorialla että enemmän kyvykkyyttä on parempi. Ei ole. Pienempi pinta reitittyy tarkemmin, koska jokainen ylimääräinen operaatio on yksi asia lisää jonka malli voi valita väärin.
Olisin myös laittanut kehitysketjun rajoituksen myyntisivulle sen sijaan että jätin ihmiset löytämään sen itse. Sen kertominen mihin asia ei pysty maksaa yhden lauseen ja ostaa uskottavuutta koko lopulle sivulle.




