Kan en KI-agent utarbeide en teknisk rapport når informasjonen den trenger er fordelt på en tegning, en tabell og en PDF? Det er spørsmålet den nye MKA-benchmarken undersøker: Den vurderer ikke bare et enkelt svar på et bilde, men en hel arbeidsflyt – fra lesing av visuelt komplekse filer til oppretting av et selvstendig dokument. Dette skillet er nyttig for dem som velger en agent til oppgaver med presentasjoner, diagrammer, kart eller skannede dokumenter.
Google DeepMind presenterte MKA 10. november 2026 sammen med Artificial Analysis. Den tekniske rapporten beskriver 200 oppgaver fra ti sektorer og 83 yrker. Et sentralt funn for evaluering av systemer er at når modellen ble fratatt verktøyet for å vise bilder, sank kvaliteten på arbeidet i MKA, samtidig som agenten brukte flere steg. I oppgaver med fotografier og medisinske bilder kompenserte ikke programvarebaserte omveier for tapet av synsevne.
Hvilket kunnskapshull fyller MKA?
Mange tester av kontorarbeid forutsetter at modellen kan hente ut tekst fra filer med et skript og løse oppgaven med nesten ingen visuell analyse. Separate bildetester ender derimot ofte med et kort svar og krever ikke at modellen kobler sammen flere kilder eller leverer resultatet som en arbeidsfil. MKA tar utgangspunkt i en sammenhengende arbeidsflyt: finne elementer i flere filer, kombinere dem, følge oppgavekravene og levere resultatet i riktig format.
Hver oppgave inneholder mellom to og 45 inndatafiler. Det kan dreie seg om bygningsplaner, elektriske skjemaer, radiologiske bilder, kart, diagrammer, tabeller og tekstdokumenter. I 88 % av oppgavene skal agenten lage eller endre en separat fil – for eksempel en PDF-rapport, en presentasjon, et regneark eller en nettapplikasjon. Ifølge forfatterne kan konvertering av materialet til enkel tekst føre til at viktig informasjon går tapt, som målestokk, romlig plassering, linjer og forbindelser mellom elementer.
Hvordan foregår evalueringen?
Fagspesialister utarbeidet oppgavene, referanseresultatene og vurderingskriteriene. Hver oppgave har i gjennomsnitt rundt 71 kriterier. Forfatterne opplyser at kriteriene i oppgaver med en separat resultatfil vektes med 75 % for faktanøyaktighet og 25 % for visuell utforming. Sluttresultatet tar hensyn til vektingen av de enkelte kriteriene, slik at det er det konkrete materialsettet som vurderes, ikke bare hvor troverdig teksten virker.


Alle modellene ble kjørt i det samme agentmiljøet, Stirrup, med identiske verktøy og budsjetter. Agenten kunne åpne filer, kjøre kode og søke på nettet. Den tekniske rapporten beskriver grenser på opptil 250 steg og åtte timer per oppgave. Ferdige dokumenter ble kontrollert av en separat evalueringsagent, som viste filene visuelt og kunne undersøke for eksempel regnearkformler programmatisk.
Forfatterne sammenlignet poengene fra den automatiske evaluatoren med fagfolks vurderinger på et delutvalg på 50 oppgaver. Vurderingene var enige i 96,2 % av kriteriene; studien oppgir også en Cohens kappa-koeffisient på 0,91. Dette viser hvor godt evaluatoren samsvarte med ekspertene i dette delutvalget.
Hva viste det å slå av synsevnen?
Forfatterne gjennomførte en kontrollert test med Gemini 4 Carbon, der de fjernet verktøyet for å vise bilder og sammenlignet prestasjonene i MKA. Climb-WSR-poengsummen sank med omtrent 5,9 prosentpoeng, antallet steg økte 1,28 ganger, og mengden genererte tokener økte 1,40 ganger. Modellen brukte oftere programvarebaserte omveier i et forsøk på å rekonstruere visuell informasjon ved å behandle filene.
Effekten varierte med typen inndata. For rene tegninger gjenopprettet omveiene noe av kvaliteten, mens de ifølge artikkelen ikke fungerte for fotografier og medisinske bilder. Det forklarer hvorfor «modellen kan lese PDF-er» er et altfor grovt kriterium for en arbeidsagent: Tekst som hentes ut, kan miste geometri, objektenes plassering i forhold til hverandre og visuelle kjennetegn.
Hvordan ble modellene sammenlignet?
Studien omfattet Gemini 4 Carbon, Claude Fable 5.2, Claude Opus 5.5 og GPT-6 Astra. Claude Fable 5.2 fikk den høyeste kvalitetspoengsummen på Climb-WSR, med 56,6 %; Gemini 4 Carbon fikk 54,3 %. På den samlede WSR-skalaen var resultatene henholdsvis 73,3 % og 71,9 %. Forfatterne oppgir at Carbon brukte 5,7 ganger færre tokener enn Fable. Den tekniske rapporten oppgir også at API-kostnaden for Carbon var 6,3 ganger lavere, mens kvaliteten på resultatene lå innenfor det statistiske støynivået. Disse sammenligningene gjelder de konkrete oppgavene og betingelsene i MKA.
Forfatterne definerer Climb-WSR som en måling basert på krevende kriterier der forrige generasjons modeller ikke nådde taket. De beste systemene fikk under 57 % på denne skalaen. Det tyder på at det fortsatt er rom for forbedring i multimodalt kunnskapsarbeid. Tallene kan ikke uten videre overføres til alle yrker eller produktoppgaver: Resultatene avhenger av filene, kravene og verktøyene som er tilgjengelige.
Hva kan utviklere og innkjøpere ta med seg?
MKA gir en praktisk mal for egen evaluering. I stedet for å spørre «hvilken modell er best til å jobbe med PDF-er?» kan man sette sammen realistiske oppgaver med inndatafiler, et påkrevd sluttdokument og kontrollerbare kriterier. Ta med tilfeller der plasseringen av elementer i et diagram er viktig, der tabellinformasjon må stemme med tekst, og der den opprettede filen må være korrekt. Sammenlign deretter systemene i det samme miljøet.
Det er nyttig å holde innholdets korrekthet og kvaliteten på resultatfilen som to separate vurderinger. Et regneark kan inneholde riktige tall, men feil formler; en rapport kan ha et ryddig design, men mangle en viktig forbindelse mellom tegningen og spesifikasjonen. MKA-rubrikken viser hvordan krav kan formaliseres på forhånd og resultatene gjøres kontrollerbare, i stedet for å basere seg på et generelt inntrykk av svaret.
Det fullstendige settet med 200 oppgaver er ment for evaluering på en uavhengig plattform. For å bli kjent med formatet er et eget sett med ti demonstrasjonsoppgaver publisert. Denne inndelingen gjør det mulig å holde hovedtesten lukket, samtidig som forskere får materiale til å undersøke formatet. For team som velger en agent, er hovedpoenget praktisk: Test ikke bare tekstuttrekk, men også hvordan systemet bruker visuell informasjon når det lager et ferdig arbeidsresultat.