Když vyjde nový jazykový model, firmy se ho obvykle nemohou hned dotknout. Musí ho připojit, otestovat a teprve pak zjistí, jestli se vyplatí. Podle případové studie, kterou zveřejnil OpenRouter, to u softwarové firmy Descript dřív trvalo týden i déle. Dnes prý vyhodnocení nového modelu zabere jednu až dvě hodiny. Descript vyvíjí platformu pro úpravu videa a zvuku s podporou umělé inteligence. Za změnou stojí jedno propojení s modely přes OpenRouter a automatizovaný postup, který se spouští ze Slacku. Text je ale marketingový materiál zprostředkovatele, takže čísla je třeba číst s rezervou. Stojí přesto za podrobnější pohled, protože ukazuje, kde se při zavádění nových modelů ztrácí čas a co se dá zautomatizovat.
Od tří integrací k jedné
Editační agent Underlord dnes podle studie běží v produkci na třinácti modelech od čtyř vývojářů: Anthropicu, Googlu, OpenAI a xAI. Před zavedením OpenRouteru byl v provozu jediný model. Firma tehdy udržovala tři přímé integrace, dnes jí stačí jedno připojení přes OpenRouter.
Rozdíl je praktický. Každá přímá integrace znamená samostatné napojení na jednoho poskytovatele, které je třeba vytvořit a udržovat. Jedno připojení přes zprostředkovatele tuto práci sjednocuje. Studie uvádí také tři až čtyři automatické záložní varianty (anglicky fallbacks) nastavené pro každý model. Záložní varianta je obecně náhradní možnost, kterou lze použít, když ta první nefunguje. Studie ale nepopisuje, jak přesně se u Descriptu spouštějí. Šéf AI produktu Aleks Mistratov to shrnuje tak, že po spuštění druhého modelu si firma uvědomila, jak málo práce stojí přidání dalších deseti. Jde o jeho vlastní hodnocení, ne o nezávislé měření.
Brzdou nebyla technika, ale fronta
Zajímavé je, kde se čas podle studie ztrácel. Samotné zkoušení modelu nebylo hlavním problémem. Člověk, který chtěl nový model vyzkoušet, ho většinou nemohl sám přidat do systému. Musel proto hledat místo v kalendáři inženýra. Úkol, který by si vyžádal několik hodin práce, se tak dostal do fronty a z otázky „stojí tenhle model za pozornost?“ se stalo týdenní čekání na odpověď.
Případová studie tím naznačuje, že úspora nevznikla jen rychlejším připojením. Hlavní změnou bylo, že první ověření už nemusí čekat na vývojáře, který má plné ruce jiné práce. Jde o typický organizační problém: ten, kdo ví, jaký model by mohl být zajímavý, a ten, kdo ho umí zapojit, jsou dvě různé role. Každé předání mezi nimi přidává prodlevu. Jakmile se první krok zjednoduší natolik, že ho zvládne i někdo bez zásahu do kódu, zmizí nejen práce, ale hlavně čekání.
Vyhodnocení ze Slacku
Nový postup vypadá podle Mistratova popisu takto. Jde na procházku, uvidí oznámení o vydání modelu a napíše do Slacku žádost o vyhodnocení s odkazem na model na OpenRouteru. O hodinu nebo dvě později jsou testy hotové v Descriptově vlastním testovacím rámci. Mistratov říká, že se kvůli tomu ani nedotkl klávesnice. Jeho slova ukazují, jak málo úsilí první krok vyžaduje. Zároveň jde o scénář, který popisuje jeden člověk. Studie neuvádí, kolik modelů se takto prověřilo ani kolik z nich pak skončilo v produkci.
Co dělá Claude Tag
Celý proces obstarává Claude Tag, slackovská integrace společnosti Anthropic. Descript ji nastavil v jednom kanálu spolu se sadou dovedností určených pro tuto smyčku. Nástroj spustí testy, otevře pull request, tedy návrh změny kódu, který přidá model do Descriptova testovacího rámce, a druhý pull request, který model ukryje za přepínač funkce, takzvaný feature flag.
Oba kroky stojí za vysvětlení. Testovací rámec je prostředí, v němž firma své testy pouští, a model do něj musí být nejprve přidán, aby se dal vůbec změřit. Feature flag je obecně přepínač, který umožňuje řídit, zda se určitá funkce uživatelům zapne. Že nástroj připraví oba návrhy zvlášť, znamená, že přidání modelu k měření a jeho případné zpřístupnění jsou dvě oddělené změny. Rozhodnutí přitom zůstává na lidech: změny kontroluje a schvaluje člověk. Automatizace tedy nenahrazuje úsudek, jen odstraňuje ruční přípravu. Inženýr se do věci zapojí, až když už existují výsledky a hotové návrhy změn.
Co zůstává na Descriptu
Připojení modelu přes zprostředkovatele je jen část cesty. Podle studie musí Descript sám provést interní evaluace, rozhodnout, zda nový model překonává stávající, nastavit nabídku modelů, zapnout feature flag a nasadit změnu. Tyto kroky tedy zůstávají na firmě, i když je první otestování zautomatizované. Údaj o jedné až dvou hodinách se navíc týká vyhodnocení nového modelu, nikoli celého nasazení do ostrého provozu.
Pro čtenáře je to důležité rozlišení. Evaluace je v tomto kontextu měření, jak si nový model vede na sadě testovacích případů, a rozhodnutí, zda překonává ten stávající, je teprve jejím výsledkem. Hodiny mohou stačit na orientační odpověď, zda se model vyplatí zkoumat dál. Plné nasazení, tedy úprava nabídky modelů, zapnutí přepínače a vlastní release, je podle dostupných informací širší úkol. Rychlost prvního kroku proto neznamená, že se každý nový model objeví v produktu během jednoho odpoledne.
Překážkou je i vlastní kód
Samotná firma přitom vidí prostor pro zlepšení. David Dodero, který na agentním týmu pracuje na testovacím rámci a evaluacích, upozornil, že většina zbývající práce vyplývá ze způsobu, jakým je strukturovaný Descriptův kód. S připojením k modelu to podle něj nesouvisí. Dodal, že by to bylo jednodušší, kdyby to měl Descript na své straně uspořádané jinak.
Je to užitečná připomínka: nástroj od externího dodavatele nevyřeší překážky, které vznikají v architektuře vlastního produktu. Zprostředkovatel modelů zjednoduší přístup k nim, ale pořádek v kódu a v procesech musí zajistit firma sama. Dodero přitom nemluví o selhání, spíš o další etapě zrychlení. Pokud by se zbývající ruční kroky podařilo zjednodušit úpravou struktury kódu, mohlo by se zkrátit i to, co dnes po automatickém testu následuje.
Co je tvrzení a co měření
Studie uvádí i ekonomický přínos. Technický vedoucí Keith Simmons odhaduje, že celkové výdaje Descriptu na modely jsou méně než poloviční oproti dřívějšku, částečně díky tomuto procesu. Kvalita podle něj obstála v Descriptových vlastních testovacích případech. Jde ale o výpověď z firemní případové studie, nikoli o nezávislé měření. Text nezveřejňuje metodiku, konkrétní náklady ani to, jak přesně se kvalita posuzovala. Nelze tedy ověřit, jakou část úspory přinesl samotný OpenRouter a jakou třeba výběr levnějších modelů.
Důležité je i slovo „vlastní“. Kvalita se podle Simmonse udržela na testovacích případech, které si sestavil Descript sám. Pro firmu je to rozumné měřítko, protože ukazuje, jak model funguje na jejích úlohách. Čtenář zvenčí ale nemá možnost zkontrolovat, jak náročné ty případy jsou ani zda pokrývají všechno, co uživatelé od editačního agenta čekají. Úspora spojená s častějším testováním je navíc logická, ale studie ji doložit nezávislými čísly nedokládá.
Otevřené otázky
Zůstává i několik nezodpovězených otázek. Studie nesrovnává Descriptův postup s jinými zprostředkovateli ani s vlastním propojením, které by bylo lépe organizované. Neříká, kolik času zabere nastavení Claude Tagu ani kolik testů se zamítne po lidské kontrole. Spolehlivě tedy víme jen to, co firma popisuje: z týdenní fronty na inženýra se stala jednoduchá žádost ve Slacku, první výsledky přicházejí za hodinu nebo dvě a rozhodnutí o nasazení zůstává na lidech. Jak dobře se to osvědčí u jiných firem, z této jedné případové studie vyvodit nelze.
Zdroje
- Descript: New Models Off the Engineering Queue — OpenRouter Blog
Článek vznikl s pomocí AI; podklady a odkazy jsou uvedeny výše.