PokeGPT: att bevisa att en GPT kunde anropa ett riktigt API

Bakgrund

PokeGPT är en egen GPT kopplad till PokeAPI. Fråga den om en Pokémon och den hämtar den faktiska posten: typer, basstatistik, förmågor, utvecklingskedja, attackurval, siffrorna som de finns i spelen i stället för som modellen halvt minns dem.

Jag byggde den i november 2023, dagar efter att OpenAI släppt Actions, eftersom jag ville veta om funktionen fungerade eller bara demonstrerade.

Problemet

Egna GPT:er lanserades med mycket oväsen, nästan allt av det promptomslag. En personlighet, en ton, ett systemmeddelande, och därunder samma modell som svarar utifrån samma träningsdata. Inte nytt.

Actions var det nya. En GPT kunde få ett OpenAPI-schema och anropa en riktig HTTP-tjänst. Det är skillnaden mellan en chattbot som har läst om din data och en som har din data. Ingen skrev om hur det var att bygga, till skillnad från vad lanseringen påstod.

PokeAPI var det perfekta testobjektet. Det är öppet, väldokumenterat, gratis, artigt hastighetsbegränsat, och det har en egenskap jag inte kunde få någon annanstans: en domän där modellen redan vet väldigt mycket, felaktigt. Varje modell har sugit i sig år av forumgräl om basstatistik. Så jag kunde ställa en fråga, se vad den svarade ur minnet, och jämföra det med vad API:et returnerade. Ett felaktigt svar syns direkt, till skillnad från i de flesta API-integrationer.

Min roll

Allt, på min egen tid, utan kund. Schemat, instruktionerna, testningen, butiksannonsen.

Angreppssätt

Jag behandlade det som ett experiment med en hypotes snarare än en produkt med en roadmap. Frågan var smal: kan en GPT tillförlitligt avgöra när den ska anropa en ändpunkt, välja rätt ändpunkt och använda det som kommer tillbaka i stället för det den redan tror.

Den inramningen satte omfattningen. En Pokedex passar eftersom frågorna är varierade nog att pröva ruttvalet och rätt svar går att kolla på några sekunder. Jag byggde det minsta som kunde besvara frågan ärligt, och skrev sedan ner var det gick fel.

Så byggde jag det

Hela produkten är ett OpenAPI-schema plus ett instruktionsblock. Ingen kod jag hostar, ingen backend. Actions innebär att OpenAI:s körtid gör anropet.

Det mesta arbetet gick in i schemat, och det var där insikten fanns. GPT:n läser inte PokeAPI:s dokumentation, den läser operationsbeskrivningarna i schemat jag levererar, och de är det enda som talar om för den när den ska anropa vilken ändpunkt. Min första version beskrev ändpunkterna korrekt och modellen anropade ändå fel, eftersom ”hämta en Pokémon” och ”hämta en Pokémon-art” är två resurser med varsin korrekt beskrivning och ingen antydan om vilken som besvarar en fråga om utveckling. Att skriva om beskrivningarna så att de säger när en operation ska användas i stället för vad den returnerar löste nästan alla ruttfel. Det är ett prompt engineering-problem utklätt till API-schema.

Det andra problemet var nyttolastens storlek. Ett enda PokeAPI-svar kan bära hundratals attacker, var och en med en nästlad lista över de spelversioner den förekom i. Att lägga det i ett kontextfönster bränner tokens på data ingen frågat efter och tränger ut svaret. Instruktionerna begränsar vilka fält som ska beaktas per frågetyp, och säger åt modellen att göra ett andra, smalare anrop i stället för ett enormt. Två små förfrågningar slår en stor, vilket är motsatsen till den instinkt du tar med dig från att skriva vanliga API-klienter.

Det tredje var det intressanta: modellen svarade ur minnet i stället för att anropa någonting. Fråga om en välkänd Pokémon och den är säker, så den hoppar över verktyget och ger dig en rimlig siffra från en gammal wikiändring. Lösningen var ett instruktionsblock som slår fast att varje faktapåstående om statistik, typer, förmågor eller utvecklingar kräver ett anrop, och att svara utan ett inte är tillåtet. Tränad kunskap som konkurrerar med ett levande verktyg är en generell felmod hos verktygsanvändande modeller, och det var här jag först mötte den.

Kedjade anrop var där den föll. En utvecklingskedja betyder att slå upp en art, sedan en kedje-URL, sedan gå genom kedjan. Sekvenser med flera hopp var opålitliga i den första releasen, och det dokumenterade jag i stället för att låtsas annat.

Resultat

21 sålda exemplar. Det är siffran, och jag klär inte upp den: det är en Pokedex-kuriositet i en nätbutik, och 21 personer ville ha den.

Resultatet jag brydde mig om var svaret på frågan. Actions fungerade. En GPT kunde faktiskt anropa en levande REST-tjänst och använda svaret, och felmoderna handlade om kvaliteten på schemabeskrivningar, nyttolastens storlek och tränad kunskap som körde över verktygsanrop snarare än om rördragning. Varje lärdom från de kvällarna gick in i hur jag nu bygger verktygsanvändande system, inklusive researchpipelinen i SignalScout, som är samma problem med mycket högre insats.

Vad jag skulle göra annorlunda

Jag levererade ett schema som täckte fler ändpunkter än produkten behövde, på teorin att mer förmåga är bättre. Det är det inte. En mindre yta ruttar mer träffsäkert, eftersom varje extra operation är ännu en sak modellen kan välja fel.

Jag skulle också ha lagt begränsningen kring utvecklingskedjor i butiksannonsen i stället för att låta folk upptäcka den själva. Att säga vad en sak inte klarar kostar en mening och köper trovärdighet åt resten av sidan.