Autor: Matúš Mikčo

Nová verzia modelu môže zlepšiť priemer a pokaziť konkrétnu odpoveď

Nová verzia jazykového modelu sa zvyčajne uvádza cez vyššie skóre v benchmarkoch. To je pochopiteľné. Jedno číslo sa dobre zmestí do prezentácie aj do tabuľky pre vedenie. Menej dobre však ukáže, čo sa stalo s konkrétnymi úlohami, ktoré model rieši vo firme.

Práca No Universal Signal Predicts Sample-Level LLM Regression under Version Updates, publikovaná na arXive, skúmala takzvanú sample-level regression (zhoršenie na úrovni jednotlivých vzoriek). Ide o situáciu, keď bola odpoveď starej verzie správna, no nová verzia odpovie nesprávne. Celkový priemer pritom môže naďalej rásť.

Autori porovnali šesť benchmarkov, tri typy úloh a šesť dvojíc aktualizovaných modelov. Sledovali otázky s výberom odpovede, matematické uvažovanie a generovanie kódu. Skúmali viacero signálov, napríklad confidence (miera istoty modelu), rozdiel pravdepodobností medzi verziami, token-level KL divergenciu a posun reprezentácie.

Výsledok nie je návod na jeden univerzálny detektor chýb. Najlepšie fungujúci signál závisel od úlohy. Miera istoty bola užitočnejšia pri otázkach s výberom odpovede a pri jednoduchšej matematike. Signály založené na pravdepodobnosti a KL divergencii prinášali častejšie zlepšenie pri náročnejšej matematike a pri kóde.

Autori zároveň ukázali proof-of-concept (overenie princípu), pri ktorom sa rizikové prípady poslali späť starej verzii modelu. To nie je hotový firemný produkt. Je to však praktický smer, ako aktualizovať model bez predstierania, že všetky odpovede sa zlepšili naraz.

Treba dodať aj obmedzenie. Ide o preprint, nie o výsledok publikovaný po štandardnom recenznom procese. Výskum navyše pracuje so šiestimi benchmarkmi a šiestimi dvojicami aktualizácií, takže z neho nemožno vyvodiť pravidlo pre každý model, každú firmu a každý typ dát.

Čo si z toho zobrať? Pri výmene modelu si nepozerajte iba nové celkové skóre. Vytvorte si vlastný testovací súbor reálnych otázok, porovnajte starú a novú verziu po jednotlivých prípadoch a najhoršie regresie si odložte na ručnú kontrolu.

Lepšie poradie operácií dokázalo využiť rovnaký GPU klaster naplno

Druhá technická správa dňa sa týka prevádzky modelov. Správne poradie operácií zvýšilo využitie rovnakého GPU klastra o 33 percentuálnych bodov. Nešlo teda o nákup nového hardvéru, ale o zmenu v tom, ako sa úlohy plánovali a vykonávali.

Rozdiel medzi vyšším výkonom a vyššou kapacitou sa vo firmách často stráca. Keď systém spracuje viac požiadaviek na rovnakom hardvéri, firma nekupuje ďalšie GPU a nemusí okamžite zvyšovať cloudový rozpočet. Najprv však musí vedieť, kde čas GPU reálne mizne.

Pri tejto správe v zadaní chýba odkaz na pôvodnú štúdiu, preto 33 percentuálnych bodov beriem ako oznámený výsledok, nie ako číslo, ktoré možno bez ďalšieho preniesť na každú infraštruktúru. Výsledok môže závisieť od veľkosti modelu, dĺžky vstupov, dávkovania aj typu operácií.

Čo si z toho zobrať? Pred objednaním ďalšej kapacity zmerajte využitie GPU po krokoch pipeline. Ak je problém v poradí operácií alebo v dávkovaní, optimalizácia procesu môže byť lacnejšia než nový server.

Čo ešte stojí za prečítanie?

  • Netflix podľa dostupných údajov používa AI v 300 z približne 1 000 titulov, hoci to nekomunikuje ako jednu veľkú technologickú kampaň, The Decoder.
  • AI sa objavuje ako téma v takmer 40 % amerických volebných kampaní a v politickej debate predbehla napríklad kryptomeny, The Decoder.
  • Gemini má v Google Workspace predvolene prístup k firemným dátam z Gmailu, Dokumentov, Kalendára a Chatu, pokiaľ administrátor nastavenie nevypne, ZDNET AI.
  • Osem rokov vývoja posunulo jazykové modely od BERT-u k systémom, ktoré riešia komplexnú matematiku a píšu softvér, no zmenil sa aj pomer schopností a nákladov, arXiv cs.LG.
  • Lepšie skóre na niekoľkých programátorských benchmarkoch samo osebe nedokazuje všeobecné zlepšenie schopnosti modelu písať kód, arXiv cs.LG.

Čo si o tom myslím a čo z toho plynie pre firmy

Názor

Pri aktualizácii AI modelu sa príliš často správame ako pri aktualizácii kancelárskeho softvéru. Klikneme na novú verziu, pozrieme sa na marketingové čísla a predpokladáme, že všetko bude fungovať aspoň rovnako dobre. Výskum z arXivu ukazuje, prečo je to nesprávny postup. Model nie je kalkulačka, pri ktorej sa zlepší iba rýchlosť. Je to systém, ktorý môže byť lepší pri jednej úlohe a horší pri druhej.

Prezentácia o vyššom benchmarku nie je výsledok. Výsledkom je systém, ktorý každý deň spoľahlivo vybavuje firemné prípady. Ak nová verzia zlepší matematiku, ale pokazí klasifikáciu reklamácií alebo extrakciu údajov z objednávok, firma nemá automaticky lepší nástroj. Má inú kombináciu vlastností.

Preto by som modely neaktualizoval plošne. Najprv by som porovnal starú a novú verziu na vlastných prípadoch, zoradil rozdiely podľa dopadu a až potom rozhodol, či sa nová verzia nasadí všade. Tam, kde je riziko vysoké, dáva zmysel fallback (záložný návrat) na starý model. Nie ako večné riešenie, ale ako poistka počas prechodu.

Zároveň by som neveril predstave, že existuje jeden univerzálny signál, ktorý vždy odhalí zhoršenú odpoveď. Samotná istota modelu môže byť užitočná pri jednej skupine úloh a slabá pri inej. To je menej pohodlné než jeden dashboard, ale prevádzka sa, žiaľ, nepýta, čo je pohodlné pre dashboard.

Dôsledok pre slovenskú a českú firmu

Pre bežnú slovenskú a českú firmu to znamená zmenu v procese nákupu aj nasadzovania modelov. Produktový tím, zákaznícka podpora, IT a človek zodpovedný za kvalitu by mali pred zmenou verzie spoločne vybrať 50 až 200 anonymizovaných prípadov z reálnej prevádzky. Nie náhodné otázky z internetu. Prípady, pri ktorých firma vie povedať, čo je správna odpoveď.

Každý prípad treba porovnať v starej a novej verzii. Výsledok nemusí byť iba správne alebo nesprávne. Pri zákazníckej podpore môžete sledovať aj úplnosť, dodržanie firemnej politiky, odovzdanie človeku a riziko nesprávneho prísľubu. Pri spracovaní dokumentov sledujte chýbajúce polia a zámenu hodnôt. Tak vznikne regresný test, teda opakovateľná kontrola, či zmena niečo nepokazila.

V krátkom horizonte, približne do jedného týždňa, to zníži riziko tichého zhoršenia po aktualizácii. V horizonte jedného až troch mesiacov firma získa vlastnú históriu kvality. Tá je pri výbere dodávateľa cennejšia než všeobecné poradie modelu, pretože ukáže cenu chyby vo vašom procese.

Pre slovenskú a českú firmu bez tímu dátových vedcov to nemusí znamenať vlastný výskumný projekt. Stačí tabuľka s testovacími prípadmi, jednoduchý skript alebo workflow v nástroji na automatizáciu a pravidlo, kto schvaľuje zmenu. Dôležité je, aby niekto vlastnil výsledok. Ak test spustí systém, ale nikto nekontroluje jeho výstup, máte meranie bez riadenia.

Pri citlivých údajoch treba navyše rozlíšiť, čo posielate do externého rozhrania. To platí na Slovensku aj v Česku. Konkrétne právne posúdenie sa môže líšiť podľa zmlúv a typu dát, no technická zásada je rovnaká: pred testovaním odstráňte osobné a obchodne citlivé údaje alebo použite schválené prostredie.

Najväčšia zmena teda nie je v tom, ktorý model vyberiete. Je v tom, že aktualizácia sa stane zmenou v produkčnom procese, nie kliknutím na novú verziu. A každá produkčná zmena potrebuje test, vlastníka, záznam a možnosť návratu.

Čo si z toho zobrať? Zaveďte pred každou zmenou modelu krátky release test na vlastných prípadoch. Ak nová verzia zlyhá pri kritickej úlohe, ponechajte starý model ako zálohu a rozhodujte podľa dopadu, nie podľa priemerného skóre.

Na záver

Článok MIT Technology Review o robotovi Moxie pripomína inú stránku technologických produktov. Desaťročný Xander používal Moxie ako spoločníčku, s ktorou sa rozprával, hoci vedel, že nie je človek. Keď služba prestane fungovať, nezmizne iba zariadenie. Zmizne aj vzťah, ktorý si používateľ vytvoril.

To je užitočná pripomienka pre každú AI službu. Technická aktualizácia má obchodný dopad aj vtedy, keď sa neobjaví v cenníku. Niekto si na ňu zvykol.

Výzva na AI implementáciu dňa

Do týždňa si nasaďte jednoduchý regresný test pre hlavný AI proces vo firme. Vezmite 50 reálnych, anonymizovaných prípadov z podpory, predaja alebo spracovania dokumentov. Uložte správne odpovede, pošlite rovnaké vstupy starej a novej verzii modelu a výsledky nechajte skontrolovať vlastníkovi procesu.

Príprava zaberie približne 2 až 4 hodiny. Každá ďalšia kontrola môže trvať 15 až 30 minút. Produktovému alebo IT tímu to zoberie ručné porovnávanie po aktualizácii a zníži riziko, že chybu objaví až zákazník. Najčastejšie to padne na tom, že nikto neurčí, čo presne znamená správna odpoveď.

Vyberte dnes testovacích 50 prípadov a prvé porovnanie spustite ešte pred ďalšou aktualizáciou.