A GitHub szerint így csökkenthető a Copilot költsége minőségromlás nélkül

A GitHub a teljes feladat költségét méri

A GitHub bejegyzése szerint az AI-kódolóügynököknél félrevezető lehet, ha a hatékonyságot csak az egyes interakciók tokenszámával mérik. Egy túl rövid eszközválasz később újabb hívásokat vagy ismételt parancsfuttatást tehet szükségessé, ha kimarad belőle olyan információ, amelyre a modellnek szüksége van.

A vállalat ezért a teljes kódolási feladatot vizsgálta, a felhasználói kéréstől a végső eredményig. A GitHub négy változtatást emel ki: a hasznos kontextus megőrzését ismétlődő kimenetek rövidítése mellett, a feladat szempontjából értéktelen formázás eltávolítását, az utasítások rövidítését a hasznos viselkedés megtartásával, valamint a háttérben elvégzett munka átadását külön visszakeresési lépés nélkül.

A lehetséges módosításokat először offline, ügynökalapú kódolási benchmarkokon értékelték, majd a legígéretesebb változatokat kontrollált online kísérletekben validálták. A példák a GitHub Copilot CLI-ből származnak, de a GitHub szerint több más Copilot-termék, köztük a GitHub Copilot app és a Copilot code review is ugyanazt az alapvető tesztkörnyezetet használja, így ezek is hatékonyabbá válnak az ilyen fejlesztésektől.

Miért nem elég a rövidebb eszközválasz

A GitHub külön kitér az RTK, vagyis Rust Token Killer nevű segédeszközre, amely a parancssori kimeneteket rövidíti, mielőtt az ügynök elolvasná őket. A vállalat saját tesztkörnyezetében és benchmark-beállításaiban az RTK valóban lerövidített egyes válaszokat, de amikor a kihagyott szöveg fontos volt, a modell néha újra megnyitotta az eredeti kimenetet, vagy újrafuttatta a parancsot.

Ez a GitHub szerint több körhöz, több továbbvitt kontextushoz, végső soron pedig átlagosan több tokenhez és hosszabb feladatteljesítéshez vezetett. A vállalat megfogalmazása szerint helyben tokeneket takarítottak meg, globálisan viszont többet költöttek. A GitHub hangsúlyozza, hogy ez az eredmény az általuk tesztelt integrációra és munkaterhelésekre vonatkozik, nem minden RTK-konfigurációra vagy általában a kimenettömörítésre.

A tapasztalat alapján a GitHub szelektív kimenettömörítőt alakított ki. Az elemzés szerint a telepítési, build, teszt és lint kimenetek gyakran tartalmaznak ismétlődő zajt, míg a forráskód-szerű kimenetek és tetszőleges parancseredmények nagyobb eséllyel hordozzák azt az információt, amelyre az ügynöknek szüksége van.

A tömörítő a kódot védi, a zajt rövidíti

A GitHub korai tömörítőváltozatai túl agresszívnek bizonyultak: a modell ismételt munkára vagy a teljes mentett kimenet elolvasására kényszerült, ami növelte a teljes költséget és rontotta a feladatsikert. Példaként a vállalat a git diff tömörítését említi, amelyet eltávolítottak, miután a benchmark-feladatokban az ügynökök az eredeti kimenetet nyitották meg a hiányzó információ visszaszerzéséhez.

A szállított megoldás három szabályra épül. A forráskód-szerű és tetszőleges kimeneteket, például a cat, git diff, git show parancsok és tetszőleges szkriptek eredményét változatlanul adják vissza. A keresési eredményeket, például a grep találatait és fájllistáit hatékonyabban csoportosítják, de minden találat megmarad. Az ismétlődő zajt, például a telepítési, build, teszt és előrehaladási kimenetet csak akkor tömörítik, ha a megtakarítás jelentős.

Ha a kimenetet tömörítik, az ügynök közvetlen úton elérheti a teljes eredetit. Ez egyszerre biztonsági mechanizmus és mérési jel: a GitHub figyelte, hogy az ügynök megnyitja-e a mentett eredetit, újrafuttat-e parancsokat, ismétli-e a feltárást, szűkíti-e a kereséseit, vagy további körökre van-e szüksége. Az offline feladatoknál, ahol a kimenettömörítés aktiválódott, nem észleltek statisztikailag szignifikáns visszaesést a feladatsikerben, és az ügynökök rendkívül ritkán nyitották meg a mentett eredetiket. Az online kísérletben az átlagos költség enyhén csökkent, miközben a követett minőségi mutatókban nem észleltek érdemi romlást.

Sorok számozása és rövidebb promptok

A GitHub egyik tisztább tokenoptimalizálása a view eszközt érintette, amellyel az ügynökök fájltartalmakat olvasnak be a kontextusba. Korábban a view minden sor elé sorszámot tett. A régebbi fájlszerkesztő eszközök ezeket a számokat használták a módosítások célzására, a jelenlegi eszközök viszont a környező kódra illesztenek, és nem használják a sorszámokat.

A GitHub ezért eltávolította ezeket az előtagokat. A fájltartalom változatlanul jutott el a modellhez, de a minden beolvasott fájl minden sorában ismétlődő formázás eltűnt. Az offline ügynökalapú kódolási benchmarkokon ez nagyjából 5%-kal csökkentette a modellkövetkeztetési költséget. A sikerességi arányok a várt futásról futásra jelentkező szóráson belül maradtak, és a szerkesztési hibák nem nőttek. Copilot CLI-felhasználókkal végzett online kísérletben az átlagos napi, felhasználónkénti modellkövetkeztetési költség körülbelül 3%-kal csökkent, a követett minőségi vagy elégedettségi mutatókban észlelt érdemi romlás nélkül.

A promptoknál a GitHub azt vizsgálta, hogyan rövidíthetők az utasítások úgy, hogy az ügynök megtartsa a fejlesztők által elvárt viselkedést. A Copilot task eszköze specializált ügynököket indít párhuzamos munkára, iránymutatása pedig több helyen, köztük eszközleírásokban, sémákban, ügynökdefiníciókban, rendszerutasításokban és kísérőeszközökben gyűlt össze. Egy meta-prompting ciklus nagyjából a felére csökkentette ezt a promptot, de az első online kísérlet olyan regressziót talált, amelyet az offline értékelések nem vettek észre: az óvatos párhuzamosítási útmutatás kemény ütemezési szabállyá alakult, ami miatt független egyedi ügynökök sorban futottak. A GitHub leállította a kísérletet, majd regressziós értékelést írt erre a viselkedésre.

Mit jelent ez a fejlesztőknek és a Copilot-piacnak

A GitHub által leírt változtatások közös tanulsága, hogy az AI-kódolás költsége nem csak azon múlik, mennyire rövid egyetlen válasz. Ha a modell kevesebb kontextust kap, de emiatt ismételten keresnie, futtatnia vagy olvasnia kell, a teljes feladat drágábbá és lassabbá válhat.

A felhasználók számára a sorszám-előtagok eltávolítása a GitHub szerint azt jelenti, hogy a kontextusablak nagyobb része marad magára a munkára, a modell által nem használt formázás helyett. A kimenettömörítőnél a cég óvatos megközelítése azt célozza, hogy az ismétlődő zaj kevesebb helyet foglaljon, miközben a forráskód-szerű vagy egyedi információk ne vesszenek el.

A prompttömörítés példája arra mutat rá, hogy a rövidebb rendszerutasítás önmagában kockázatos lehet. A GitHub szerint a promptviselkedéshez tesztek kellenek, mert ha egy viselkedés nincs tesztelve, egy rövidebb prompt észrevétlenül eltávolíthatja. A szállított prompt körönként körülbelül 1 300 task-tool prompt tokent távolít el, ami munkamenetenként körülbelül 1,8%-kal kevesebb teljes prompt tokent jelent, a forrásban szereplő további költségadat azonban nem teljes mondatban maradt meg.