Nevěřte skóre AI bez účtenky. Britové začínají odkrývat zákulisí testů

U 96,5 % z více než 50 tisíc hodnocených záznamů chyběl alespoň jeden údaj potřebný k opětovnému spuštění testu. Tak dopadla analýza dokumentace benchmarků projektu EvalEval zveřejněná v červnu 2026. Neznamená to, že všechny výsledky jsou špatně. Znamená to, že jejich ověření může připomínat vaření podle receptu, ze kterého někdo vystřihl teplotu trouby. Výsledky analýzy EvalEval

Pro majitele fotovoltaiky nebo firmu vybírající AI asistenta je to docela praktický problém. Model může zazářit v tabulce a potom zaměnit výkon střídače za kapacitu baterie. Britský institut UK AISI a koalice EvalEval proto dávají výsledkům něco podstatnějšího než další barevný graf: dohledatelný původ a popis podmínek měření.

Nevěřte skóre AI bez účtenky. Britové začínají odkrývat zákulisí testů

UK AISI, britský institut pro bezpečnost umělé inteligence, začal používat infrastrukturu EvalEval k otevřenému sdílení výsledků. Spolupráci popisuje oznámení z 22. září 2026. Základem je společné datové schéma Every Eval Ever, zkráceně EEE, a platforma Evaluation Cards. První sjednocuje záznamy. Druhá pomáhá lidem pochopit, co čísla skutečně znamenají.

Zveřejněná sada zahrnuje výsledky hlavního experimentu na pěti benchmarcích: HealthBench, FrontierMath, Humanity’s Last Exam, SWE-Bench Pro a Terminal-Bench 2.0. Pokrývá modely Claude Opus 4, 4.5 a 4.6 a GPT-5, GPT-5.2 a GPT-5.4. Doplněny jsou dvě kyberbezpečnostní evaluace s částečně odlišnou sestavou modelů. Vedle skóre přicházejí informace o konfiguraci a kontextu měření. Oznámení spolupráce AISI a EvalEval

Podstatná je změna otázky. Místo „Kdo vyhrál?“ se můžeme ptát: „S jakým zadáním, rozpočtem a pomocnými nástroji vyhrál?“ To je rozdíl mezi reklamním tvrzením a podkladem pro technické rozhodnutí.

Ani tato iniciativa nezaručuje, že každý experiment zopakujete na domácím počítači. Proprietární model může zmizet z nabídky. Některá data mohou mít omezený přístup. Dobře popsaný výsledek ale alespoň ukáže, kde přesně překážka leží.

Stejný model, jiný rozpočet, jiné pořadí

Výsledky doprovázejí studii týmu Jessicy McFadyen, Oleho Jorgensena, Harryho Coppocka, Kevina Weie a Cozmina Ududece. Autoři zkoumali až dvanáct špičkových modelů na sedmi náročných benchmarcích. Měnili rozpočet tokenů, zkracování průběžného kontextu a možnost opakovaného odevzdání odpovědi.

Jejich závěr je nepříjemný pro jednoduché žebříčky: skóre závisí na testovacím postupu. Větší výpočetní rozpočet v řadě oblastí zvyšoval úspěšnost. Pomáhat mohly také další pokusy nebo zpětná vazba o správnosti odpovědi. Účinek se ovšem lišil podle benchmarku. Studie o vlivu výpočetního rozpočtu

Představte si dva asistenty pro servis fotovoltaiky. První dostane jeden pokus a krátkou odpověď. Druhý může prohledat manuály, spustit výpočet a po upozornění na chybu odpověď opravit. Jejich výsledky popisují dvě odlišné služby. Samotné procento správných odpovědí tuto odlišnost schová.

Pro nákup proto porovnávejte několik režimů: stejnou cenu za úlohu, stejný časový limit a stejná oprávnění. Počet tokenů je užitečný technický údaj, ale mezi různými modely není dokonalou náhradou ceny ani skutečného výpočetního výkonu.

Zvlášť opatrně čtěte výsledky s automatickou informací „správně, nebo špatně“. Při diagnostice skutečné závady takového vševědoucího rozhodčího obvykle nemáte. Kdybyste ho měli, možná nepotřebujete asistenta.

Chcete ušetřit na energiích?

Zjistěte, kolik můžete ušetřit sdílením elektřiny z FVE nebo optimalizací bateriového úložiště.

Spočítat úsporu →

Co vám karta výsledku prozradí a co nezaručí

Evaluation Cards sledují čtyři oblasti: reprodukovatelnost, úplnost dokumentace, původ výsledků a srovnatelnost. Prakticky jde o kontrolu, zda víte, kdo měřil, co měřil a za jakých podmínek lze výsledek postavit vedle jiného. Průvodce kartami výsledků

Pozor na význam slova reprodukovatelnost. Automatická kontrola dokumentace není nezávislé zopakování experimentu. Popsaný minimální kontrolní mechanismus hledá zejména hodnoty `temperature` a `max_tokens`. U agentních testů přidává informace o testovacím prostředí, plánu a limitech. Vyplněná políčka odstraňují překážky, sama správnost měření nedokazují. Metodika výpočtu ukazatelů

Pro vlastní projekt si proto ukládejte ještě přesnou verzi modelu, úplné zadání, verzi testovacích dat a hodnoticího programu. U lokálního modelu přidejte kontrolní součet souboru s vahami, kvantizaci a podobu šablony konverzace. U vzdálené služby zaznamenejte datum, identifikátor modelu a parametry požadavku.

Nastavení náhodného semínka pomůže, pokud ho dané prostředí podporuje. Nečekejte ale automaticky totožný text na jiném hardwaru. Smysluplnější bývá sledovat rozptyl úspěšnosti při opakování.

Do balíčku patří také jednotlivé odpovědi a chyby. Průměrná úspěšnost 90 % může schovat deset neškodných stylistických přešlapů i deset nebezpečných záměn jednotek. Pro servisního technika jsou to dost odlišné pondělky.

Vlastní test spustíte přes Inspect a Ollamu

Praktickým nástrojem je otevřený framework Inspect AI. Test skládá z datové sady, postupu řešení a hodnoticí funkce. Hotové implementace nabízí balík Inspect Evals. Pro lokální modely má Inspect podporu Ollamy, která musí před spuštěním testu běžet. Dokumentace Inspect, připojení Ollamy

Na Linuxu nebo macOS s Pythonem a již nainstalovanou Ollamou může úvodní zkouška vypadat takto:

```bash python3 -m venv .venv source .venv/bin/activate python -m pip install inspect-ai inspect-evals openai ollama pull llama3.1:8b inspect eval inspect_evals/arc \ --model ollama/llama3.1:8b \ --limit 20 inspect view ```

ARC je obecný znalostní test. Dvacet úloh zde slouží k ověření instalace, propojení a zápisu výsledků. Na základě tak malého vzorku nevybírejte firemní systém. Postup využívá oficiální způsob spouštění benchmarků přes Inspect Evals. Přehled frameworku AISI

Po úspěšném spuštění zachyťte prostředí:

```bash python -m pip freeze > requirements-lock.txt ollama --version ollama show llama3.1:8b ```

Výpisy posledních dvou příkazů přiložte k protokolu. Samotný seznam balíků neuchová model ani operační systém. Archivujte také konfiguraci, data a protokoly ze složky `logs`.

Jako výchozí sestavu pro malý kvantovaný model bych volil počítač s 16 GB operační paměti a SSD. Je to orientační doporučení, nikoli záruka rychlosti. Nároky rostou s délkou kontextu i počtem souběžných požadavků. Pro první ověření obvykle dává větší smysl využít stávající počítač než rovnou objednávat grafickou kartu.

Transformers umí kvantované modely z llama.cpp. Má to háček

Novinka Hugging Face z 22. září 2026 přibližuje knihovnu Transformers lokálním modelům ve formátu GGUF. Nová efektivní cesta využívá výpočetní jádra ggml. Při oznámení se zaměřovala na Apple Silicon a podporované architektury rodiny Qwen3.5, včetně kompatibilních variant Qwen3.8. Nejde tedy o příslib stejného provozu libovolného GGUF na každém počítači.

Rozdíl ve velikosti souboru je konkrétní. U zveřejněného příkladu Qwen3.5-4B má varianta BF16 velikost 8,42 GB, zatímco Q4_K_M má 2,74 GB. To nejsou celkové paměťové nároky programu. K vahám přibývá kontext a provozní paměť. Bez kompatibilního jádra navíc může nastat převod vah do vyšší přesnosti a spotřeba paměti naroste. Technické oznámení Hugging Face

Pro reprodukovatelné měření z toho plyne jednoduché pravidlo: označení modelu nestačí. Zaznamenejte konkrétní soubor, kvantizaci, knihovny i hardware. Porovnávejte rovněž správnost odpovědí, ne pouze tokeny za sekundu.

Další proměnnou je LoRA, úsporný způsob přizpůsobení modelu pomocí trénovatelných adaptérů. Adaptér naučený na servisních protokolech může změnit výsledky. Musí proto dostat vlastní verzi a testovací záznam. Trénovací příklady oddělte od závěrečného testu, jinak měříte také zapamatování. Dokumentace LoRA

Benchmark pro FVE musí poznat chybnou jednotku i podvržený návod

Pro energetickou firmu bych začal sadou 120 vlastních úloh: čtyřicet výpočtů, čtyřicet případů práce s dokumentací a čtyřicet provozních či bezpečnostních scénářů. Jde o návrh pilotního testu, nikoli univerzální normu. Každá úloha potřebuje očekávaný výsledek a pravidlo hodnocení.

Výpočet může chtít převést výkon 5 kW po dobu dvou hodin na energii 10 kWh. Dokumentační úloha ověří, zda asistent rozliší dva podobné typy střídače. Provozní scénář mu předloží chybějící měření nebo dokument s podvrženým pokynem k odeslání přístupových údajů.

Právě tady má smysl zmínit zprávu o zranitelnosti asistenta Muse od Mety. Samotný titulek o závažné chybě nelze použít jako měřítko schopností modelu. Ukazuje však, proč vedle odpovědí řešit také zabezpečení aplikace a rozsah oprávnění. Tvrzení o aktuálním stavu opravy vyžaduje samostatné ověření.

Záznamy z IoT monitoringu SmartEnergyShare mohou být tematickým východiskem pro návrh provozních scénářů. To není tvrzení, že služba používá popisovaný framework.

U plánování baterie ukládejte konkrétní cenová data, časové pásmo a předpověď dostupnou v okamžiku rozhodnutí. Přehled spotových cen pomůže s orientací; primární výsledky trhu zveřejňuje OTE. Zpětný test s dokonalou znalostí budoucí výroby je pěkné divadlo, ale mizerná zkouška reálného řízení.

Kolik stojí ověření a kdy se lokální AI prodraží

Inspect ani Ollama nepřidávají fakturu za každý lokální dotaz. Platíte však elektřinu, hardware a práci. U konkrétního modelu navíc zkontrolujte licenci. Otevřený nástroj automaticky neznamená neomezené komerční použití všech dostupných vah.

Vezměme výslovně modelový výpočet. Počítač odebírá při testu průměrně 120 W, měření běží osm hodin a elektřinu oceňujeme částkou 6 Kč/kWh. Spotřeba činí 0,96 kWh, náklad 5,76 Kč. To není naměřená cena uvedeného benchmarku ani aktuální nabídka dodavatele.

Při nepřetržitém provozu stejného příkonu po třicet dnů už vychází 86,4 kWh, tedy 518,40 Kč. Jestli počítač pořídíte výhradně pro AI, musíte přičíst jeho amortizaci. Elektřina bývá jen část účtu.

Pro vzdálené rozhraní počítejte zvlášť vstupní a výstupní tokeny, opakované pokusy i případného hodnoticího asistenta. Nejprve změřte malý vzorek a podle něj odhadněte celý běh. U dlouhých agentních úloh nastavte pevný rozpočtový limit.

Energetický rozměr není drobnost. IEA ve výhledu z roku 2026 uvádí přibližně 485 TWh spotřeby datových center za rok 2025 a očekává kolem 950 TWh v roce 2030. Jde o datová centra celkem, nejen AI. Výhled IEA

U projektu spojeného s obchodováním flexibility proto sledujte také čistý přínos po odečtení nákladů na výpočty a provoz.

Než AI svěříte baterii, chtějte opakovatelný důkaz

Nejužitečnějším výstupem pilotu nebude vítězný model. Bude jím balíček, který kolega otevře za měsíc a pochopí, co jste měřili. Má obsahovat data, konfiguraci, odpovědi, hodnoticí pravidla, náklady a seznam známých omezení.

Vyhodnocujte stejné úlohy napříč modely. Oddělte chybnou odpověď od výpadku služby a nevybírejte pouze nejpovedenější běh. Vedle průměru sledujte kritické chyby, dobu odezvy a četnost situací, kdy systém přizná nedostatek informací. Právě takové přiznání může mít v diagnostice větší cenu než sebevědomý odstavec.

Pro vlastní energetický projekt můžete navázat tématy na smartenergyshare.com. Další související čtení nabízí [ElectricShare.cz](https://electricshare.cz) a bateriový [BESS Global Blog](https://bess-global-blog.vercel.app). Samotné propojení s energetikou ovšem potřebuje vlastní měření; univerzitní matematický benchmark ho nevyřeší.

Začněte jedním modelem, malou sadou skutečných problémů a provozem pouze pro čtení. Teprve po vyhodnocení přidávejte složitější úlohy a případné zásahy do zařízení.

AISI a EvalEval posouvají debatu správným směrem: od osamoceného skóre k ověřitelnému záznamu. Moje předpověď? U seriózních dodávek AI se takový protokol stane stejně samozřejmým jako technický list střídače. Dodavatel, který nabízí jen vítězný graf, bude muset vysvětlovat stále víc.

Zdroje

Obchodujete s batteriovými úložišti nebo hledáte partnera pro flexibilitu a day trading elektřiny? SmartEnergyShare nabízí kompletní řešení pro BESS projekty od 50 do 250 kW — obchodování flexibility, SVR služby a IoT monitoring. Zjistěte víc →

Další články na toto téma najdete na: SmartEnergyShare.info Co je LFM2.5-2.6B a proč to není další ChatGPT klon Vice o emo: pretraining