Jak GitHub Copilot snižuje náklady na AI programování bez zhoršení kvality

Kvalita výstupu je při práci s AI agenty pro programování důležitá. Skutečná efektivita ale závisí také na tom, zda agent dokončí práci rychle, úsporně a se správným kontextem.

Samotný počet tokenů v jednotlivých interakcích proto není smysluplným měřítkem efektivity. Cílem nemá být co nejnižší spotřeba tokenů, ale využití takového množství kontextu, které pomůže posunout úkol k dokončení. Stručná odpověď nástroje může vyvolat další volání nebo práci navíc, pokud v ní chybějí informace, které agent potřebuje. Celý úkol pak nakonec trvá déle a stojí více.

GitHub proto optimalizuje výsledek celého úkolu, nikoli jednotlivá volání nástrojů. Článek popisuje čtyři změny v GitHub Copilot, které tento princip uplatňují:

• Zachování užitečného kontextu při omezení opakujícího se výstupu.
• Odstranění formátování, které úkolu nepřináší žádnou hodnotu.
• Zkrácení instrukcí bez změny užitečného chování.
• Předání výsledků dokončené práce na pozadí bez dalšího kroku pro jejich načtení.

Možné úpravy GitHub nejprve vyhodnocoval offline pomocí benchmarků agentního programování. Nejslibnější změny následně před nasazením ověřil v řízených online experimentech. Příklady v článku pocházejí z GitHub Copilot CLI. Stejné základní prostředí pro běh agentů využívají i další produkty, například aplikace GitHub Copilot a Copilot code review, takže z těchto zlepšení těží také.

Obrázek 1: Čtyři nezávislé A/B experimenty využívající stejnou metriku spotřeby AI Credits. Jednotlivé části jsou zobrazeny společně pro porovnání; jejich účinky se však nemusejí jednoduše sčítat.

Past dílčích metrik

Běžným způsobem snižování nákladů na agenty je zkracování výstupu každého volání nástroje. Utilita RTK (Rust Token Killer) zkracuje výstup shellu ještě předtím, než jej agent přečte. GitHub její dopad na GitHub Copilot vyhodnotil pomocí benchmarků agentního programování.

V testované konfiguraci prostředí a benchmarků RTK některé odpovědi zkrátil. Pokud ale vynechaný text obsahoval důležité informace, model někdy znovu otevřel původní výstup nebo opakoval příkaz, aby je získal.

Tyto dodatečné kroky přidávaly další kola interakce a přenášely do nich více kontextu. Jednotlivá odpověď nástroje byla kratší, ale celý úkol v průměru spotřeboval více tokenů a trval déle. Dílčí úspora tak vedla k vyšší celkové spotřebě.

Obrázek 2: Kratší odpověď nástroje může prodražit dokončení celého úkolu, pokud chybějící podrobnosti nutí agenta znovu číst výstup, opakovat příkazy a přenášet více kontextu.

Tento výsledek platí pro testovanou integraci a úlohy, nikoli pro každou konfiguraci RTK nebo pro kompresi výstupu obecně. Ukázal však, že počet tokenů na jedno volání nástroje není správným cílem optimalizace. Změnu efektivity je nutné hodnotit napříč celým úkolem – od požadavku uživatele až po konečný výsledek.

Užitečnější otázkou bylo, co lze odstranit, aniž by model musel opakovat práci.

Omezit šum, zachovat užitečné informace

Cílem bylo zkrátit opakující se výstup a současně zachovat kontext, který agent potřebuje k dokončení úkolu bez návratů k předchozím krokům.

Analýza běhů benchmarků ukázala, že výstupy instalací, sestavení, testů a lintování často obsahují opakující se šum. Naproti tomu výstupy se zdrojovým kódem a výsledky libovolných příkazů s větší pravděpodobností obsahují informace, které agent potřebuje. Na základě této analýzy vznikl selektivní kompresor výstupu, částečně inspirovaný RTK a podobnými přístupy.

GitHub prototyp vyhodnotil na benchmarcích agentního programování a na řadě open source repozitářů, v nichž spouštěl sestavení, testy a lintování.

První verze komprimovaly příliš agresivně. Nutily model opakovat práci nebo číst celý uložený výstup, čímž zvyšovaly celkové náklady a snižovaly úspěšnost úkolů. Komprese například původně zahrnovala i git diff. GitHub však tento filtr odstranil poté, co benchmarkové úlohy ukázaly, že agenti znovu otevírají původní výstup, aby získali chybějící informace.

Z těchto počátečních neúspěchů vyplynula tři pravidla:

• Zachovat výstupy se zdrojovým kódem a výstupy libovolných příkazů. Výsledky příkazů jako cat, git diff, git show a libovolných skriptů se vracejí beze změny.
• Uspořádat výsledky hledání úsporněji, ale nic nevynechat. Nalezené shody a seznamy souborů z nástrojů, jako je grep, lze seskupit efektivněji při zachování všech výsledků.
• Opakující se šum komprimovat selektivně. Výstupy instalací, sestavení, testů a průběžných hlášení se komprimují pouze tehdy, když je úspora výrazná.

Nasazená verze vznikla opakovaným vyhodnocováním a úpravami. Je konzervativní nikoli proto, že by to byl původní cíl, ale proto, že právě tento přístup podpořily výsledky testů.

Pokud je výstup zkomprimován, agent má stále k dispozici přímou cestu k načtení úplného originálu.

Obrázek 3: Nasazený kompresor zachovává výstupy se zdrojovým kódem, bezeztrátově přeuspořádává výsledky hledání a komprimuje pouze předvídatelný opakující se šum. Úplný originál zůstává dostupný.

Možnost načíst originál slouží jako pojistka i jako signál při vyhodnocování. GitHub sledoval, zda agent otevírá uložený originál, opakuje příkazy, znovu prochází stejné informace, zužuje hledání nebo přidává další kola interakce. Časté dohledávání původních informací by znamenalo, že kompresor odstranil něco hodnotného.

U offline úloh, v nichž se komprese aktivovala, nebylo zjištěno statisticky významné zhoršení úspěšnosti. Agenti otevírali uložené originály jen zcela výjimečně. V online experimentu průměrné náklady mírně klesly a ve sledovaných ukazatelích kvality nebylo zjištěno podstatné zhoršení.

Než ubírat informace, odstranit zbytečné formátování

Jednu z přímočarých úspor tokenů přinesl nástroj view, kterým agenti načítají obsah souborů do kontextu.

Dříve view před zobrazením obsahu modelu přidával na začátek každého řádku jeho číslo. Starší nástroje pro úpravu souborů tato čísla používaly k určení místa změny. Současné nástroje však místo toho vyhledávají shodu v okolním kódu a čísla řádků nevyužívají. Číslování přesto ve výstupu zůstalo, i když pro běžný pracovní postup už nebylo potřeba.

Každý takový prefix byl malý. Při opakování na každém řádku každého načteného souboru se ale zbytečné formátování v průběhu relace nasčítalo. GitHub jej proto odstranil.

Obrázek 4: Odstranění čísel na začátku řádků zachovává přesné znění zdrojového kódu a odstraňuje formátování, které se opakovalo při každém čtení souboru.

Čísla řádků zůstávají užitečná v rozdílových výstupech a krátkých ukázkách. Zde však představovala zbytečnou režii, protože se přidávala ke každému čtení souboru, aniž by sloužila současnému postupu úprav.

Jejich odstranění snížilo náklady na inferenci modelu v offline benchmarcích agentního programování přibližně o 5 %. Úspěšnost zůstala v mezích očekávaného kolísání mezi běhy a počet selhání při úpravách se nezvýšil.

GitHub následně změnu otestoval u uživatelů Copilot CLI. Online experiment snížil průměrné denní náklady na inferenci modelu na uživatele přibližně o 3 %. Ve sledovaných ukazatelích kvality ani spokojenosti nebylo zjištěno podstatné zhoršení.

Pro vývojáře to znamená, že větší část kontextového okna zůstává k dispozici pro samotnou práci místo formátování, které agent nevyužívá.

Šlo o ideální typ změny: žádné nové instrukce pro model, žádné chybějící informace k dohledání a žádné další rozhodování. Obsah souborů se k modelu dostal beze změny.

Zkrátit prompty, ale zachovat jejich záměr

Prompty obsahují instrukce, které určují způsob práce agenta, a model je dostává v každém kole interakce. Jejich zkrácení zvyšuje efektivitu pouze tehdy, pokud agent zachová chování, na které se vývojáři spoléhají.

V GitHub Copilot spouští nástroj task specializované agenty pro paralelní práci. Pokyny pro něj se postupně nahromadily v popisech nástrojů, schématech, definicích agentů, systémových instrukcích i souvisejících nástrojích.

Pomocí iterativního metapromptování, při němž Copilot opakovaně přepisoval vlastní prompt, se podařilo jeho délku zkrátit přibližně na polovinu. Copilot vytvářel a upravoval kratší varianty a cílené testy chování ověřovaly požadavky, které měly zůstat zachovány.

První online experiment ale odhalil zhoršení, které úvodní offline testy nezachytily. Metapromptování změnilo opatrně formulované doporučení k paralelnímu běhu na pevné pravidlo plánování. Nezávislí vlastní agenti pak běželi postupně místo souběžně.

GitHub experiment zastavil. Než prompt znovu upravil, vytvořil regresní test pro chování, na které upozornil provoz u uživatelů. Výsledná oprava nahradila explicitní seznam povolených a zakázaných případů jedinou větou:

Nezávislí agenti mohou běžet paralelně; zvažte vedlejší účinky.

Věta byla kratší a méně omezující. Oproti předchozím výslovným pokynům ponechávala rozhodnutí o paralelním spuštění dílčích agentů na modelu. Nový test chování s ní prošel a žádný ze stávajících testů nezačal selhávat.

Chování řízené promptem potřebuje testy. Pokud určité chování není otestováno, může ho kratší prompt nepozorovaně odstranit.

Obrázek 5: Komprese promptu byla bezpečná až poté, co regresní test zachytil postupné spouštění agentů a jednovětá oprava obnovila paralelní běh. Výsledná úspora tokenů se opakuje při každém kole interakce s modelem.

Nasazený prompt odstraňuje přibližně 1 300 tokenů instrukcí nástroje task v každém kole. To odpovídá přibližně o 1,8 % nižšímu celkovému počtu vstupních tokenů za relaci a o 2,9 % nižším normalizovaným nákladům na aktivní hodinu. V provedených vyhodnoceních nebylo zjištěno zhoršení kvality.

Předat dokončenou práci na pozadí bez dalšího načítání

Agenti často spouštějí nezávislou práci na pozadí – například dlouho běžící příkaz shellu souběžně s analýzou prováděnou dílčím agentem. Oznámení umožňují agentovi pokračovat v jiné práci, dokud nejsou výsledky připravené, aniž by musel čekání řešit voláním nástroje.

Pokud agent výslovně nečeká na dokončení některé z úloh, běhové prostředí po dokončení příkazu shellu nebo dílčího agenta aktivuje model a upozorní jej.

Dříve toto oznámení neobsahovalo hotový výsledek. Agent proto musel v dalším kole načíst výstup, který už Copilot obdržel. Pokud několik úloh skončilo krátce po sobě, mohl se tento mezikrok opakovat. Copilot nyní slučuje oznámení o dokončení, která lze zpracovat společně, a předává hotové výsledky přímo ve stávajícím formátu výsledků nástrojů. Agent tak může pokračovat s potřebnými informacemi bez dalšího kola, v němž by o ně znovu žádal. Explicitní načítání výstupu dosud běžících úloh funguje stejně jako dříve.

Obrázek 6: Dříve mohlo každé dokončení práce na pozadí vyvolat kolo interakce s modelem sloužící pouze k vyžádání výsledku. Nyní běhové prostředí slučuje vhodná oznámení o dokončení a předává hotové výsledky ve stávajícím formátu výsledků nástrojů.

Před změnou vyžadovala každá dokončená úloha jedno volání modelu k vyžádání výsledku a další k jeho zpracování. U uvedeného příkladu s příkazem shellu a dílčím agentem to znamenalo čtyři volání modelu, než mohla práce pokračovat.

Nyní běhové prostředí spojí obě oznámení o dokončení a dodá výsledky společně, takže je obě zpracuje jediné volání modelu. Odstranění těchto mezikroků také omezuje zbytečné přenášení celého kontextu relace do dalších volání.

Přímé předávání dokončených výsledků – bez komprese, shrnování nebo zadržování informací – snížilo průměrnou spotřebu související s tokeny, měřenou v AI Credits, přibližně o 2,3 %.

Změny je nutné měřit v konkrétním kontextu

Úprava, která v jednom pracovním postupu služby Copilot šetří tokeny, může v jiném náklady zvýšit.

Například stručnější sada instrukcí pro nástroje pracující se soubory vycházela z pozitivních výsledků v Copilot code review. V online experimentu s Copilot CLI ale náklady zvýšila, a proto ji GitHub nenasadil.

Naopak odstranění čísel na začátku řádků i selektivní komprese výstupu snížily každá samostatně průměrný počet vstupních tokenů na jednu kontrolu kódu přibližně o 5 %. Ukázala to nezávislá vyhodnocení na rozsáhlé sadě úloh Copilot code review s produkčním modelem. Ve sledovaných ukazatelích kvality kontrol nebyla zjištěna podstatná změna.