Autor: Matúš Mikčo

Nová verze modelu může zlepšit průměr a pokazit konkrétní odpověď

Nová verze jazykového modelu se obvykle uvádí prostřednictvím vyššího skóre v benchmarcích. Je to pochopitelné. Jedno číslo se dobře vejde do prezentace i do tabulky pro vedení. Hůř však ukáže, co se stalo s konkrétními úkoly, které model ve firmě řeší.

Práce No Universal Signal Predicts Sample-Level LLM Regression under Version Updates, publikovaná na arXivu, zkoumala takzvanou sample-level regression (zhoršení na úrovni jednotlivých vzorků). Jde o situaci, kdy byla odpověď staré verze správná, ale nová verze odpoví nesprávně. Celkový průměr přitom může dál růst.

Autoři porovnali šest benchmarků, tři typy úloh a šest dvojic aktualizovaných modelů. Sledovali otázky s výběrem odpovědi, matematické uvažování a generování kódu. Zkoumali několik signálů, například confidence (míra jistoty modelu), rozdíl pravděpodobností mezi verzemi, token-level KL divergenci a posun reprezentace.

Výsledek není návodem na jeden univerzální detektor chyb. Nejlépe fungující signál závisel na úloze. Míra jistoty byla užitečnější u otázek s výběrem odpovědi a u jednodušší matematiky. Signály založené na pravděpodobnosti a KL divergenci přinášely častější zlepšení u náročnější matematiky a kódu.

Autoři zároveň ukázali proof-of-concept (ověření principu), při kterém se rizikové případy poslaly zpět staré verzi modelu. Není to hotový firemní produkt. Jde však o praktický směr, jak aktualizovat model bez předstírání, že se všechny odpovědi zlepšily najednou.

Je třeba dodat i omezení. Jde o preprint, nikoli o výsledek publikovaný po standardním recenzním řízení. Výzkum navíc pracuje se šesti benchmarky a šesti dvojicemi aktualizací, takže z něj nelze odvodit pravidlo pro každý model, každou firmu a každý typ dat.

Co si z toho odnést? Při výměně modelu se nedívejte pouze na nové celkové skóre. Vytvořte si vlastní testovací soubor reálných otázek, porovnejte starou a novou verzi případ po případu a nejhorší regrese odložte k ruční kontrole.

Lepší pořadí operací dokázalo naplno využít stejný GPU cluster

Druhá technická zpráva dne se týká provozu modelů. Správné pořadí operací zvýšilo využití stejného GPU clusteru o 33 procentních bodů. Nešlo tedy o nákup nového hardwaru, ale o změnu v tom, jak se úlohy plánovaly a prováděly.

Rozdíl mezi vyšším výkonem a vyšší kapacitou se ve firmách často ztrácí. Když systém zpracuje více požadavků na stejném hardwaru, firma nekupuje další GPU a nemusí okamžitě zvyšovat cloudový rozpočet. Nejdřív však musí vědět, kde čas GPU skutečně mizí.

U této zprávy v zadání chybí odkaz na původní studii, proto 33 procentních bodů beru jako oznámený výsledek, nikoli jako číslo, které lze bez dalšího přenést na každou infrastrukturu. Výsledek může záviset na velikosti modelu, délce vstupů, dávkování i typu operací.

Co si z toho odnést? Před objednáním další kapacity změřte využití GPU po jednotlivých krocích pipeline. Pokud je problém v pořadí operací nebo v dávkování, optimalizace procesu může být levnější než nový server.

Co ještě stojí za přečtení?

  • Netflix podle dostupných údajů používá AI ve 300 z přibližně 1 000 titulů, ačkoli to nekomunikuje jako jednu velkou technologickou kampaň, The Decoder.
  • AI se objevuje jako téma v téměř 40 % amerických volebních kampaní a v politické debatě předstihla například kryptoměny, The Decoder.
  • Gemini má v Google Workspace ve výchozím nastavení přístup k firemním datům z Gmailu, Dokumentů, Kalendáře a Chatu, pokud administrátor toto nastavení nevypne, ZDNET AI.
  • Osm let vývoje posunulo jazykové modely od BERT-u k systémům, které řeší komplexní matematiku a píšou software, změnil se však i poměr schopností a nákladů, arXiv cs.LG.
  • Lepší skóre v několika programátorských benchmarcích samo o sobě nedokazuje obecné zlepšení schopnosti modelu psát kód, arXiv cs.LG.

Co si o tom myslím a co z toho plyne pro firmy

Názor

Při aktualizaci AI modelu se příliš často chováme jako při aktualizaci kancelářského softwaru. Klikneme na novou verzi, podíváme se na marketingová čísla a předpokládáme, že všechno bude fungovat alespoň stejně dobře. Výzkum z arXivu ukazuje, proč je to nesprávný postup. Model není kalkulačka, u které se zlepší pouze rychlost. Je to systém, který může být lepší u jednoho úkolu a horší u jiného.

Prezentace o vyšším benchmarku není výsledek. Výsledkem je systém, který každý den spolehlivě vyřizuje firemní případy. Pokud nová verze zlepší matematiku, ale pokazí klasifikaci reklamací nebo extrakci údajů z objednávek, firma automaticky nemá lepší nástroj. Má jinou kombinaci vlastností.

Proto bych modely neaktualizoval plošně. Nejdřív bych porovnal starou a novou verzi na vlastních případech, seřadil rozdíly podle dopadu a teprve potom rozhodl, zda se nová verze nasadí všude. Tam, kde je riziko vysoké, dává smysl fallback (záložní návrat) ke starému modelu. Ne jako trvalé řešení, ale jako pojistka během přechodu.

Zároveň bych nevěřil představě, že existuje jeden univerzální signál, který vždy odhalí zhoršenou odpověď. Samotná jistota modelu může být užitečná u jedné skupiny úloh a slabá u jiné. Je to méně pohodlné než jeden dashboard, ale provoz se bohužel neptá, co je pohodlné pro dashboard.

Důsledek pro slovenskou a českou firmu

Pro běžnou slovenskou a českou firmu to znamená změnu v procesu nákupu i nasazování modelů. Produktový tým, zákaznická podpora, IT a člověk odpovědný za kvalitu by měli před změnou verze společně vybrat 50 až 200 anonymizovaných případů z reálného provozu. Ne náhodné otázky z internetu. Případy, u kterých firma dokáže říct, jaká je správná odpověď.

Každý případ je třeba porovnat ve staré a nové verzi. Výsledek nemusí být pouze správně, nebo nesprávně. U zákaznické podpory můžete sledovat i úplnost, dodržení firemní politiky, předání člověku a riziko nesprávného příslibu. Při zpracování dokumentů sledujte chybějící pole a záměnu hodnot. Tak vznikne regresní test, tedy opakovatelná kontrola, zda změna něco nepokazila.

V krátkodobém horizontu, přibližně do jednoho týdne, to sníží riziko tichého zhoršení po aktualizaci. V horizontu jednoho až tří měsíců firma získá vlastní historii kvality. Ta je při výběru dodavatele cennější než obecné pořadí modelu, protože ukáže cenu chyby ve vašem procesu.

Pro slovenskou a českou firmu bez týmu datových vědců to nemusí znamenat vlastní výzkumný projekt. Stačí tabulka s testovacími případy, jednoduchý skript nebo workflow v nástroji pro automatizaci a pravidlo, kdo schvaluje změnu. Důležité je, aby někdo za výsledek odpovídal. Pokud test spustí systém, ale nikdo nekontroluje jeho výstup, máte měření bez řízení.

U citlivých údajů je navíc třeba rozlišit, co posíláte do externího rozhraní. To platí na Slovensku i v Česku. Konkrétní právní posouzení se může lišit podle smluv a typu dat, technická zásada je však stejná: před testováním odstraňte osobní a obchodně citlivé údaje nebo použijte schválené prostředí.

Největší změna tedy není v tom, který model vyberete. Je v tom, že aktualizace se stane změnou v produkčním procesu, nikoli kliknutím na novou verzi. A každá produkční změna potřebuje test, vlastníka, záznam a možnost návratu.

Co si z toho odnést? Zaveďte před každou změnou modelu krátký release test na vlastních případech. Pokud nová verze selže u kritického úkolu, ponechte starý model jako zálohu a rozhodujte podle dopadu, nikoli podle průměrného skóre.

Na závěr

Článek MIT Technology Review o robotovi Moxie připomíná jinou stránku technologických produktů. Desetiletý Xander používal Moxie jako společnici, se kterou si povídal, ačkoli věděl, že není člověk. Když služba přestane fungovat, nezmizí pouze zařízení. Zmizí i vztah, který si uživatel vytvořil.

Je to užitečná připomínka pro každou AI službu. Technická aktualizace má obchodní dopad i tehdy, když se neobjeví v ceníku. Někdo si na ni zvykl.

Výzva k AI implementaci dne

Do týdne nasaďte jednoduchý regresní test pro hlavní AI proces ve firmě. Vezměte 50 reálných, anonymizovaných případů z podpory, prodeje nebo zpracování dokumentů. Uložte správné odpovědi, pošlete stejné vstupy staré a nové verzi modelu a výsledky nechte zkontrolovat vlastníkovi procesu.

Příprava zabere přibližně 2 až 4 hodiny. Každá další kontrola může trvat 15 až 30 minut. Produktovému nebo IT týmu to ušetří ruční porovnávání po aktualizaci a sníží riziko, že chybu objeví až zákazník. Nejčastěji to selže na tom, že nikdo neurčí, co přesně znamená správná odpověď.

Vyberte dnes 50 testovacích případů a první porovnání spusťte ještě před další aktualizací.