Ko patiesībā pierāda AI benchmarka rezultāts?

Labs benchmarks dara ļoti noderīgu darbu: tas padara noteiktu spēju salīdzināmu noteiktos apstākļos.

Tas var palīdzēt salīdzināt modeļu versijas, atkārtot testu pēc izmaiņām, identificēt regresiju, saprast stiprās un vājās vietas un samazināt izvēli, kas balstīta tikai uz demonstrācijām vai mārketingu.

NIST 2026. gada materiāli par automatizētiem benchmarku novērtējumiem tieši uzsver to kā svarīgu mērīšanas instrumentu, vienlaikus norādot, ka ne visus AI novērtēšanas mērķus iespējams sasniegt ar automatizētu benchmarku.2

Tātad problēma nav skaitlī.

Problēma ir apgalvojuma tvērumā, kuru no šī skaitļa mēģinām izdarīt.

Ja modelis pareizi atrisina 940 no 1000 konkrēta benchmarka uzdevumiem, mēs varam aprakstīt tā rezultātu šajā testā.

Lai pateiktu kaut ko vairāk, vajag vairāk priekšnoteikumu.

Vai 1000 uzdevumi ir reprezentatīvi tiem uzdevumiem, kurus sagaidām produkcijā?

Vai tie aptver visas būtiskās apakškategorijas?

Vai testa vienības ir pietiekami grūtas?

Vai modelis tās iepriekš nav redzējis?

Vai prompta un rīku konfigurācija atbilst tam, kā sistēmu izmantos praksē?

Vai rezultāts attiecas uz konkrēto modeļa versiju, kas tiešām tiks izvietota?

Vai 94% rezultāts ir stabils atkārtotos mēģinājumos?

Ja šīs lietas nav zināmas, skaitlis joprojām var būt patiess. Vienkārši mēs nezinām, cik plašu apgalvojumu tas drīkst pamatot.

NIST AI 800-3 šeit ievieš ļoti noderīgu nošķīrumu.1

Benchmark accuracy jautā: kā modelis darbojas uz konkrēto benchmarka vienību kopu?

Generalized accuracy jautā: kā mēs sagaidām, ka modelis darbotos plašākā līdzīgu iespējamo uzdevumu populācijā?

Otrais jautājums ir daudz tuvāks tam, ko iepirkuma vai produkta lēmumā cilvēki bieži domā, redzot vienu benchmarka procentu.

Taču tas prasa papildu statistiskus pieņēmumus.

NIST parāda arī citu svarīgu lietu: diviem modeļiem var būt statistiski atšķirīgs rezultāts uz konkrētā benchmarka, bet šī atšķirība vairs nebūt pārliecinoša, mēģinot secināt par plašāku līdzīgu uzdevumu populāciju.1

Tāpēc leaderboardā redzama viena vai divu punktu starpība pati par sevi nav pietiekams pamats secinājumam, ka viens modelis konkrētajā organizācijas lietojumā ir “labāks”.

Praktiskā novērtēšanā es sāktu nevis ar benchmarka nosaukumu, bet ar vienu teikumu:

Ko mēs ar šo testu cenšamies noskaidrot?

Piemēram:

• vai modelis spēj klasificēt Latvijas iestāžu dokumentus noteiktās kategorijās;
• vai asistents spēj atbildēt uz jautājumiem, izmantojot tikai organizācijas zināšanu bāzi;
• vai modelis uzticami atpazīst personas datus noteiktā dokumentu tipā;
• vai aģents spēj izpildīt konkrētu darbplūsmu bez neatļautām darbībām;
• vai jaunā modeļa versija nepasliktina jau pieņemto produkta kvalitāti.

Tie ir atšķirīgi novērtēšanas mērķi.

“General reasoning benchmark” var būt interesants salīdzinājumam. Tas vēl ne obligāti ir labs tests nevienam no iepriekš minētajiem lēmumiem.

NIST AI 800-2 projekta materiāls iesaka dokumentēt tieši saikni starp benchmarku un evaluation objective, tostarp vērtēt, vai testa vienības pietiekami aptver interesējošo uzdevumu telpu.2

Tas ir viens no svarīgākajiem jautājumiem visā procesā.

Latvijā šī problēma kļūst īpaši praktiska.

VARAM 2025. gada monitoringā piedalījās vairāk nekā 150 valsts institūciju, un 65% aptaujāto iestāžu norādīja, ka ikdienā izmanto AI risinājumus.3 Tas nozīmē, ka jautājumi par modeļu kvalitāti latviešu valodā vairs nav tikai pētnieciska interese.

Ja sistēmai būs jāstrādā latviski, benchmarka valodu pārklājums ir daļa no pierādījuma.

Angļu valodas tests pats par sevi nepierāda:

• latviešu gramatikas un sintakses kvalitāti;
• juridisko vai administratīvo terminu izpratni latviešu valodā;
• darbu ar diakritiskajām zīmēm, saīsinājumiem un lokāliem nosaukumiem;
• konkrētu Latvijas dokumentu struktūru;
• vienādu kvalitāti starp latviešu un angļu valodas plūsmām.

Tas nenozīmē, ka angļu benchmarks ir nederīgs. Tas nozīmē, ka no angļu benchmarka nedrīkst klusām izsecināt latviešu produkcijas kvalitāti.

ISO/IEC DIS 23282, kas 2026. gada septembrī vēl ir izstrādes stadijā, tieši nodarbojas ar NLP sistēmu novērtēšanas metožu izvēli, īstenošanu un interpretāciju.4 Pats standarta projekts vēl nav galīgs, taču virziens ir svarīgs: testa metodei jābūt atbilstošai tam, ko patiesībā gribam novērtēt.

Publisks benchmarks rada vienu neērtu jautājumu: vai modelis testa vienības ir redzējis apmācības vai modeļa uzlabošanas laikā?

Ja atbilde nav zināma, rezultāts var atspoguļot gan spēju vispārināt, gan iepriekšēju saskari ar testa materiālu.

Tas nenozīmē, ka visi publiskie benchmarki ir nederīgi. Taču contamination risk ir pietiekami būtisks, lai NIST 2026. gadā palaistu AITE — AI Technology Evaluation — ar slēgtu testēšanas vidi un nepubliskiem/blind datiem tieši nolūkā mazināt train/test contamination risku.5

Praktiskā iepirkumā mums parasti nebūs NIST līmeņa sequestered testbed.

Bet var darīt daudz vienkāršāk:

• daļu testa datu nepublicēt;
• izveidot organizācijas pašu holdout kopu;
• izmantot jaunus piemērus pēc modeļa knowledge cutoff;
• uzturēt skaidru datu izcelsmes reģistru;
• nošķirt benchmarku, ar kuru modelis tika izvēlēts, no akcepttesta, ar kuru pieņemam konkrēto sistēmu.

Pēdējais punkts ir īpaši svarīgs.

Piegādātāja publiskais benchmarks nav tas pats, kas pasūtītāja acceptance evidence.

LLM un aģentu sistēmās modeļa nosaukums vien bieži nav pietiekams identifikators.

Lai atkārtotu rezultātu, var būt svarīgi:

• modeļa piegādātājs;
• precīza modeļa versija vai snapshot;
• datums;
• system prompt;
• user prompt template;
• temperature un citi sampling parametri;
• tool access;
• retrieval konfigurācija;
• context window izmantošana;
• few-shot piemēri;
• evaluator/grader modelis un tā versija;
• benchmarka versija;
• scoring kods;
• atkārtojumu skaits.

Ja benchmarkā izmantots aģents ar web search, code execution vai retrieval, rezultāts jau raksturo ne tikai bāzes modeli.

Tas raksturo konkrētu sistēmas konfigurāciju.

NIST AI 800-2 sākotnējā projekta mērķis ir tieši uzlabot automatizētu benchmarku validitāti, caurskatāmību un reproducējamību un aicina publicēt pietiekamas novērtējuma detaļas, lai citi varētu saprast, ko rezultāts nozīmē un, kur iespējams, to atkārtot.2

Dažreiz salīdzina divus modeļus ar atšķirīgiem promptiem un pēc tam rezultātu pasniedz kā tīru modeļu salīdzinājumu.

Tas var būt pilnīgi pamatoti, ja novērtējam divus gatavus produktus un katram ļaujam izmantot tā optimālo konfigurāciju.

Tas nav tas pats, kas izolēts bāzes modeļu salīdzinājums.

Tāpēc benchmarka aprakstā jāpasaka, kas ir novērtējuma objekts:

modelis vai modelis + prompt vai modelis + retrieval vai pilna aģenta sistēma.

Citādi rezultāts ir tehniski precīzs, bet semantiski neskaidrs.

Daudzos generative-AI benchmarkos nav vienkāršas atbildes correct/incorrect.

Rezultātu var vērtēt cilvēks, noteikumu kopa vai cits modelis.

Ja tiek izmantots LLM-as-a-judge, arī vērtētājs kļūst par mērīšanas ķēdes sastāvdaļu.

Tad jāzina vismaz:

• kura vērtētāja versija izmantota;
• kāds bija grader prompt;
• vai bija kalibrācija pret cilvēku vērtējumiem;
• kā apstrādāti strīdīgi rezultāti;
• vai vērtētājs var būt sistemātiski labvēlīgs noteiktam atbilžu stilam vai modeļu saimei.

Tas nav arguments pret automatizētu grading.

Tas ir arguments par to, ka evaluation pipeline pati ir sistēma, kuru vajag dokumentēt.

Benchmarka rezultāts bieži tiek publicēts kā punkts: 81,4.

Taču katrs novērtējums balstās uz konkrētām testa vienībām, modeļa izpildes variāciju un scoring noteikumiem.

NIST AI 800-3 īpaši pievēršas tam, kā pareizi aprakstīt šādu nenoteiktību, un brīdina, ka ierasti analīzes paņēmieni var balstīties uz neizteiktiem pieņēmumiem vai radīt nederīgus uncertainty estimates.1

Praktiski tas nozīmē vienkāršu lietu:

ja divu modeļu rezultāti ir ļoti tuvi, mums jāzina, vai starpība vispār ir informatīva.

Pirms rakstīt “A pārspēj B”, būtu jāredz:

• atkārtojumu skaits;
• confidence interval vai cits atbilstošs uncertainty measure;
• efekta lielums;
• vai salīdzinājums ir veikts uz tiem pašiem testa piemēriem;
• vai atšķirība saglabājas svarīgajās apakškategorijās.

Leaderboardam patīk viena decimālzīme.

Iepirkuma lēmumam vajag vairāk.

AI pakalpojumu sniedzēji var atjaunināt modeli, routing, safety layer vai sistēmas konfigurāciju.

Ja organizācija pirms trim mēnešiem validēja model-X-2026-06, bet produkcijā tagad tiek izmantots rolling alias model-X-latest, nav automātiski skaidrs, ka vecais rezultāts joprojām attiecas uz jauno stāvokli.

Šeit benchmarkam vajag derīguma nosacījumu.

Piemēram:

Rezultāts ir spēkā tikai konkrētajam model snapshot, promptu kopai un retrieval konfigurācijai. Būtiska izmaiņa prasa atkārtotu novērtējumu.

Tas nav birokrātisks formulējums. Tas ir veids, kā nepiešķirt vecam pierādījumam jaunu nozīmi.

Pat ļoti labs akcepttests nenovērtē visu, kas notiks reālajā vidē.

Produkcijā mainās lietotāju ievades, datu sadalījums, konteksts, rīku pieejamība, piegādātāja versijas un cilvēku uzvedība.

NIST AI 800-4 2026. gadā šo robežu formulē tieši: pre-deployment novērtējumi ir vērtīgi, bet pārsvarā notiek kontrolētā vidē, kas nevar pilnībā aptvert reālās darbības dinamiku; tāpēc vajadzīga arī post-deployment monitoring pieeja.6

Tas nozīmē, ka sistēmas pierādījumu ķēdei nevajadzētu beigties ar “benchmark passed”.

Tai jāturpinās:

benchmark → acceptance test → deployment → monitoring → incidents/errors → re-evaluation

Ja sistēma mainās, mainās arī pierādījuma stāvoklis.

AI Act nepadara katru benchmarku par juridisku prasību.

Taču augsta riska AI sistēmām tā tvērumā regulas loģika ir svarīga. 13. pants prasa lietošanas instrukcijās norādīt sistēmas īpašības, spējas un veiktspējas ierobežojumus, tostarp attiecīgos precizitātes rādītājus un paredzamus apstākļus, kas var ietekmēt sagaidāmo sniegumu.7

15. pants paredz, ka augsta riska AI sistēmām jāpanāk atbilstošs precizitātes, robustuma un kiberdrošības līmenis, ņemot vērā to paredzēto lietojumu, un ka attiecīgie precizitātes rādītāji jādeklarē.8

Regulas 9. pantā testēšana ir sasaistīta ar iepriekš noteiktiem rādītājiem un varbūtības sliekšņiem, kas ir atbilstoši sistēmas paredzētajam lietojumam.9

Te ir būtisks princips:

regulatīvi nozīmīgs nav abstrakti augsts rezultāts; nozīmīga ir atbilstoši izmērīta veiktspēja paredzētajam lietojumam.

Tas nav viens un tas pats.

Ja man būtu jāpieņem AI sistēma organizācijā, es prasītu nevis benchmarka ekrānattēlu, bet nelielu pierādījumu kartīti.

Pēdējās divas rindas ir svarīgākas, nekā izskatās.

Tās piespiež organizāciju nošķirt mērījumu no interpretācijas.

Piegādātājam, kurš piedāvā sistēmu Latvijas organizācijai, es neprasītu “labāko benchmarka rezultātu”.

Es prasītu:

Parādiet novērtējumu mūsu paredzētajam lietojumam.

Ja sistēma strādās latviski, parādiet latviešu testus.

Ja tā apstrādās konkrētus dokumentus, parādiet reprezentatīvu dokumentu kopu.

Ja tā pieņems vai ietekmēs lēmumus, parādiet kļūdu sadalījumu, ne tikai vidējo accuracy.

Ja tiks lietots RAG, testējiet retrieval un atbildes ķēdi kopā.

Ja tiks lietoti tools, testējiet arī neatļautas darbības un kļūdainu tool selection.

Ja modelis tiek automātiski atjaunināts, pasakiet, kas izraisa re-evaluation.

Un pirms produkcijas — palaidiet klienta neatkarīgu acceptance testu ar datiem, kurus piegādātājs iepriekš nav redzējis.

Tas dod daudz vairāk informācijas nekā vēl viena leaderboarda vieta.

Mazākas valodas un lokālie administratīvie konteksti starptautiskos benchmarkos ne vienmēr būs pārstāvēti pietiekami, lai pamatotu lokālu ieviešanas lēmumu.

Tāpēc Latvijas organizācijai ir praktiska jēga uzturēt savu mazu, kvalitatīvu un kontrolētu acceptance kopu.

Tai nav jābūt milzīgai.

Daudz vērtīgāk ir, lai katrai vienībai būtu skaidrs:

• kāpēc tā iekļauta;
• ko tā pārbauda;
• kas ir pareizs vai pieņemams rezultāts;
• kāda kļūda būtu būtiska;
• vai piemērs pārstāv reālu produkcijas gadījumu;
• vai testa vienība nav nonākusi modeļa pielāgošanas procesā.

Šāda kopa nevar aizstāt vispārēju benchmarku. Tā dara citu darbu: pārbauda, vai izvēlētais AI risinājums spēj darīt mūsu konkrēto darbu.

Labs AI assurance process spēj atbildēt ne tikai uz “kāds bija rezultāts?”, bet arī:

Kas tieši tika testēts?

Ar kādu konfigurāciju?

Uz kādiem datiem?

Ar kādu scoring?

Kas šo rezultātu apstiprināja?

Vai šodien produkcijā vēl ir tā pati sistēma?

Ja pēc sešiem mēnešiem organizācija redz tikai PDF ar “94%”, benchmarks vairs nav labs pierādījums.

Tas ir vēsturisks skaitlis bez pietiekama konteksta.

AI benchmarka rezultāts var būt ļoti vērtīgs pierādījums.

Bet pierādījums vienmēr ir par kaut ko konkrētu.

Tas var pierādīt, kā konkrēta modeļa vai sistēmas versija, ar konkrētu konfigurāciju, darbojās uz konkrētu testa kopu un pēc konkrētas vērtēšanas metodes.

Lai no tā izdarītu plašāku secinājumu par reālu lietojumu, vajag pamatot reprezentativitāti, valodu un domēnu pārklājumu, datu izcelsmi, nenoteiktību, reproducējamību un saikni ar produkcijas vidi.

Tāpēc labs AI novērtējums nebeidzas ar procentu.

Tas beidzas ar skaidru robežu starp to, ko mēs izmērījām, to, ko drīkstam secināt, un to, kas vēl jāpārbauda pirms reāla lēmuma.

Avoti pārbaudīti 2026. gada 25. septembrī. NIST AI 800-2 šajā datumā ir Initial Public Draft, nevis galīgā NIST vadlīnija. ISO/IEC DIS 23282 ir Draft International Standard izstrādes stadijā. Šajā rakstā piedāvātais “Benchmark evidence record” ir autora praktisks pierādījumu modelis, ne normatīvi noteikta forma.

Šis raksts ir AI novērtēšanas, pārvaldības un pierādījumu prakses analīze, nevis individuāla juridiska konsultācija.