Jeden model píše, druhý hledá chyby. Copilot zkouší HydraFusion
GitHubův HydraFusion vybírá model podle úkolu. Když první řešení nestačí, může práci předat silnějšímu modelu nebo přizvat kritika, který hledá chyby.
Nálepky:
Projekt HydraFusion je experimentální systém GitHubu, který v Copilotu vybírá jazykové modely a rozděluje mezi ně práci. Někdy úlohu svěří jedinému modelu, jindy přizve silnější model nebo nezávislého kritika. Modely dostupné v Copilotu se liší cenou, rychlostí i tím, jak si poradí s různými úlohami. Vývojář tak vedle samotného zadání vybírá i to, kterému modelu je svěří. Silnější model může ušetřit neúspěšné pokusy, u jednoduché úpravy ale může stejně dobře posloužit levnější varianta. Copilot část tohoto rozhodování přebírá funkcí Auto, která vybírá model podle úlohy. Project HydraFusion, představený na začátku září jako výzkumné preview, jde dál. Oproti Auto umí do jedné úlohy zapojit několik modelů od různých poskytovatelů.
Jeden píše, druhý hledá chyby
HydraFusion nejprve odhaduje, jaké schopnosti úloha potřebuje: uvažování, generování kódu, hledání chyb a práci s nástroji. Podle toho volí co nejjednodušší postup, od kterého očekává dostatečně dobrý výsledek. U snadné úpravy tak může zůstat u jediného modelu. GitHub této variantě říká Single. U postupu Cascade dostane první pokus úspornější model a jeho řešení projde kontrolou kvality. Když kontrola návrh přijme, silnější model už úlohu nepřebírá. Jinak úloha přejde ke schopnějšímu modelu. Dražší model se tak zapojí jen v některých případech, do ceny se ovšem započítá i případný neúspěšný první pokus.

Třetí postup, Critique, dělí práci jinak. Jeden model vytvoří řešení, kritik z jiné modelové rodiny je posoudí a původní model provede jednu revizi. Kritik dostane návrh k hodnocení, sám do repozitáře nezasahuje. Jiná modelová rodina má zvýšit šanci, že kontrola zachytí i chybu, kterou autor návrhu přehlédl. U opravy přihlašování by kritik mohl například upozornit, že návrh neřeší vypršení platnosti tokenu. Původní model pak dostane konkrétní připomínku k zapracování. Vývojáři má HydraFusion předat výsledné změny jako celek, bez ručního přenášení odpovědí mezi chaty. Tyto tři postupy popisuje GitHub v návrhu HydraFusion. Právě automatické přizvání kritika se zdá užitečnější než další rozšíření nabídky modelů. Výběr podle značky totiž sám neřeší, kdy práci prospěje kontrola.
V testech levnější než samotný Opus
V offline testech GitHubu na TerminalBench 2.1, který prověřuje vícekrokové úlohy v terminálu, byla nejlépe vyladěná konfigurace HydraFusion úspěšnější než Claude Opus 5. Podíl správně vyřešených úloh byl o 4,9 procentního bodu vyšší, odhadované náklady na modelová volání přitom klesly o 67 %. Na náročných úpravách repozitářů v DeepSWE už HydraFusion za Opusem zaostal o 1,5 procentního bodu, při úspoře 36 %. Na interním CheckpointBench byla úspěšnost o 0,1 procentního bodu nižší a náklady klesly o 65 %. Výsledky GitHubu tak ukazují především možnost přiblížit se kvalitě drahého modelu za podstatně méně peněz. Do nákladů se počítaly i kontroly, revize, opakované pokusy a přechody na další model.
Samostatný příplatek za HydraFusion není. Uživatel platí spotřebu jednotlivých zapojených modelů podle jejich běžných sazeb a cena se sčítá za všechny fáze. Oficiální FAQ zároveň uvádí, že v preview nelze jednotlivé modely ručně vybírat ani vylučovat; jejich sestava se může měnit. Uživatel tak systému svěřuje i rozhodování, za které modely při řešení úkolu zaplatí.
Levnější model může práci prodražit
Když práce pokračuje dalšími dotazy a úpravami, cenu ovlivňuje i to, co už model zpracoval. Služba může mít velkou část předchozího kontextu uloženou v cache a znovu ji využít. Při přechodu na jiný model ale může být nutné stejný kontext zpracovat znovu. Přepnutí na levnější model pak může pokračování práce prodražit. Auto proto při routování v Copilotu bere ohled na okamžiky, kdy lze model změnit bez zbytečné ztráty cache. Také u HydraFusion bude záležet na nákladech celé konverzace. Úsporu na jedné odpovědi může převážit opakované zpracování kontextu při dalším dotazu. První preview ostatně GitHub doporučuje hlavně pro ucelené, dobře vymezené programátorské úlohy zadané jedním promptem, například konkrétní opravu s jasným cílem. Zlepšení delších konverzací s postupným upřesňováním úkolu má následovat.
Navazující volání více modelů mohou prodloužit čekání a přidávají místa, kde se může něco pokazit. HydraFusion proto omezuje dobu jednotlivých kroků, odděluje kontrolu od úprav repozitáře a interně zaznamenává jejich cenu, trvání a výsledek. Člověku ale průběžné návrhy zatím neukazuje, protože se ještě mohou změnit nebo zahodit. Vidí fáze práce a čeká na výslednou odpověď. Omezený přehled o průběhu práce je podstatnější výhrada než samotné přepínání mezi modely. Vývojář může čekat na opravu návrhu nebo na jeho kontrolu, ale také na odpověď modelu, který se zasekl. Právě v takové chvíli by podrobnější průběžné informace pomohly rozhodnout, jestli ještě čekat, nebo úlohu přerušit.
Co lze vyzkoušet a co je zatím plán
GitHub chce postupně automatizovat jak výběr mezi lokálními a cloudovými modely, tak rozhodování, kdy jich do úlohy zapojit víc. HydraFusion je součástí tohoto plánu. Pro vývojáře by bylo lákavé, kdyby drobná úprava zůstala na notebooku a náročnější problém dostal cloudovou posilu. Zářijové preview se ovšem soustředí především na výběr a skládání pracovních postupů. Lokální běh patří do širšího plánu GitHubu; HydraFusion zatím nelze považovat za režim, který udrží veškeré zpracování na vlastním zařízení. To je podstatné zejména tam, kde pravidla zakazují odesílat zdrojový kód externím poskytovatelům.
Vyzkoušet jej lze v Copilot CLI napříč tarify Copilotu. Po aktualizaci příkazem /update se experimenty zapnou přes /experimental on a v nabídce /model se vybere HydraFusion (Research Preview).
Přenechat výběr Copilotu přitom nemusí znamenat vzdát se vlivu na cenu a kvalitu. U běžného Auto GitHub zavádí tři preference: Efficiency upřednostňuje nízké náklady, Balance vyvažuje cenu, kvalitu a rychlost odpovědi a Intelligence dává přednost kvalitě. S HydraFusion se tak může proměnit i to, co vlastně od výběru modelu čekáme. Vývojář by mohl zvolit rychlé a levné řešení, nebo dát přednost důkladnější kontrole i za cenu delšího čekání a vyšších nákladů. Výběr modelů a rozdělení práce mezi ně by pak nechal na Copilotu.
… reposted this!