Gemini Decisions API vurderer faste svarmuligheder og returnerer sandsynligheder, som software kan bruge til at sortere henvendelser, vælge AI-modeller eller kontrollere indhold. Modellen Gemini Decision 1 skriver ikke frie svar og udfører ikke selv den valgte handling. En høj score er fortsat en modelvurdering, som kræver kontrol i den konkrete arbejdsgang.
Gemini Decisions API vurderer faste svarmuligheder og returnerer sandsynligheder til software, der sorterer indhold eller vælger næste trin. Modellen udfører ikke selv handlingerne. Svarenes usikkerhed, kategoriernes grænser og kontrol af hele arbejdsgangen afgør, hvordan vurderingerne kan bruges i praksis.
Hvad lancerede Google?
Google lancerede Gemini Decisions API den 11. november 2026 med modellen gemini-decision-1. Adgangen går gennem Gemini Developer API og Google AI Studio; dokumentationen bruger API-versionen v1beta. Understøttelse i Gemini på Google Cloud er annonceret som kommende.
Modellen kan vurdere tekst, billeder, lyd, video og PDF-dokumenter. Den behandler et fælles input sammen med op til 1.000 uafhængige spørgsmål. Den samlede kontekstgrænse er 262.144 tokens, inklusive input og spørgsmål. Tokens er de enheder, som modellen bruger til at behandle indhold.
Hvordan adskiller modellen sig fra en chatbot?
En chatbot formulerer typisk et svar løbende. Gemini Decision 1 beregner i stedet sandsynligheder for på forhånd definerede udfald i én gennemløbning af modellen. Den genererer nul teksttokens. Resultatet er beregnet til et program, der skal vælge mellem afgrænsede muligheder.
Det giver en anden opgavefordeling: Modellen vurderer indholdet, mens programmet håndhæver reglerne for næste trin. At klassificere en henvendelse som en betalingsfejl er eksempelvis adskilt fra at godkende en tilbagebetaling. Sidstnævnte kræver en særskilt handling og de nødvendige rettigheder.
Modelbeskrivelsen angiver hverken tekstgenerering, function calling, kodeafvikling eller computerbetjening som understøttede funktioner. API’et er dermed en afgrænset komponent i et større system.
Hvilke svar kan en forespørgsel give?
De tre svartyper dækker forskellige behov. Valget af type bestemmer, hvad resultatet betyder, og hvordan programmet kan bruge det.
| Svartype | Resultat | Illustrativ anvendelse |
|---|---|---|
| Ja eller nej | Sandsynlighed for ja samt confidence | Beskriver en henvendelse en defekt? |
| Valg | Bedste mulighed og sandsynligheder for mulighederne | Skal sagen til betaling, levering eller teknisk support? |
| Vurderingsskala | Vægtet score og sandsynligheder for niveauerne | Hvor alvorlig er en fejl efter en fast skala? |
Spørgsmålene ser samme input, men ikke hinandens svar. Et samlet kald er derfor ikke en kæde af afhængige beslutninger. Programmet skal kombinere resultaterne eller sende en ny forespørgsel, når næste spørgsmål afhænger af det første svar.
Hvad betyder en høj confidence?
Confidence udtrykker modellens estimerede sandsynlighed for, at dens bedste svar er korrekt. Ved et ja/nej-spørgsmål er confidence den største af sandsynlighederne for ja og nej.
En lav sandsynlighed for ja kan altså ledsages af høj confidence: Modellen vurderer da nej som det sandsynlige svar. Et program, der kun aflæser confidence, kan forveksle sikkerhed om svaret med svarets retning.
Som princip beskriver kalibrering, hvor godt sandsynligheder stemmer med observeret korrekthed på mange eksempler. Den giver ingen garanti for den enkelte sag. En tærskel får først praktisk betydning, når teamet har undersøgt, hvilke fejl der slipper igennem i dets eget materiale.
Hvorfor kræver faste svarmuligheder en afgrænsning?
Googles vejledning beskriver en konkret begrænsning: Et valgspørgsmål fordeler sandsynlighed mellem mulighederne, også når ingen af dem passer. Den højest placerede kategori kan derfor være forkert allerede på grund af kategorilisten.
Forestil dig en supportindbakke med kategorierne levering og betaling. En teknisk fejl hører ikke naturligt til nogen af dem. En ekstra mulighed for øvrige sager eller et særskilt spørgsmål om, hvorvidt sagen ligger inden for området, kan gøre denne grænse synlig.
Afgrænsningen handler om mere end at vælge en høj tærskel. Systemet skal også have et sted at sende sager, som dets kategorier ikke beskriver.
Hvordan kan en beslutningsmodel styre AI-agenter?
En mulig anvendelse er modelrouting, hvor software fordeler opgaver mellem forskellige modeller. En afgrænset vurdering kan eksempelvis pege på, om en forespørgsel kræver en hurtig model, en model med mere ræsonnement eller menneskelig behandling.
Google beskriver intern brug i Gemini Notebook, Stitch, CC og Search. Eksemplerne viser et anvendelsesprincip, men dokumenterer ikke en bestemt gevinst i andre organisationers systemer.
En router kan desuden vælge forkert. Hvis en vanskelig sag sendes til en utilstrækkelig model, kan den sparede ventetid blive opvejet af fejl og genbehandling. Kontrollen må derfor omfatte hele forløbets kvalitet. Systemets agentrettigheder og handlingsgrænser skal stadig fastlægges særskilt.
Hvor hurtig er modellen i praksis?
Google angiver 150–250 millisekunders samlet svartid og 50–100 millisekunders modelberegning som median i de beskrevne målinger. Hastighedsafsnittet afgrænser målingerne til kontekster på op til 16.000 tokens. Her er tiden næsten uændret fra ét til 100 spørgsmål.
Det er et andet måleområde end API’ets maksimum på 1.000 spørgsmål og den fulde kontekstgrænse. Tallene dokumenterer derfor ikke samme svartid ved maksimal belastning.
For et supportteam er tiden frem til korrekt placering mere relevant end ét isoleret modelkald. Et forsøg kan derfor måle både API-svartid, eventuelle genforsøg og den efterfølgende behandling af tvivlstilfælde.
Hvad koster den samlede arbejdsgang?
Prissiden angiver pr. 12. november 2026 en betalt takst på 0,10 amerikanske dollar pr. million inputtokens for tekst, billeder, video, lyd og PDF. Der faktureres ingen outputtokens. Der findes også et gratis niveau.
Det fælles input tæller én gang pr. forespørgsel, mens hvert spørgsmål tilføjer tokens til instruktioner, kriterier og formatering. Mange spørgsmål er dermed ikke helt uden ekstra forbrug. Kontekstcaching og Batch API er ikke understøttet.
Ved sammenligning af løsninger kan teamet medregne både klassifikation, efterfølgende modelkald og manuel behandling. Den relevante enhed er en korrekt afsluttet sag. En lav takst pr. token fortæller ikke alene, hvilken løsning der har den laveste samlede udgift.
Hvordan kan et supportteam teste den på dansk?
Et illustrativt forsøg på en arbejdsplads i Danmark kan begynde med fiktive supporthenvendelser på dansk. En medarbejder fastlægger de korrekte kategorier på forhånd. Derefter sammenholdes modellens valg og usikkerhed med disse referencer.
- Medtag både tydelige sager, tvetydige formuleringer og henvendelser uden for kategorierne.
- Undersøg især fejl, der sender en sag til en forkert proces med store konsekvenser.
- Registrér, hvor ofte sager går til menneskelig behandling, og hvor ofte modellen tager fejl trods høj confidence.
Forsøget er en foreslået kontrolform, ikke et rapporteret resultat. Originalkilden fremlægger ingen særskilt kvalitetsmåling for dansk. Forskelle i modeladfærd på tværs af sprog gør det relevant at teste det faktiske arbejdssprog frem for at overføre en generel benchmarkplacering direkte.
Hvilke data- og adgangsforhold skal afklares?
Prissiden skelner mellem gratis og betalt adgang: Den markerer brug til produktforbedring som ja på det gratis niveau og nej på det betalte, med henvisning til vilkårene. Denne forskel beskriver ikke hele behandlingen af organisationens data.
Datatilsynets cloudvejledning fastholder ansvar for passende sikkerhed og lovlige tredjelandsoverførsler hos både dataansvarlige og databehandlere. En organisation skal derfor afklare det konkrete dataflow og aftalegrundlag, hvis den sender personoplysninger til en cloudtjeneste.
- Hvilke oplysninger sendes til klassifikationen og videre til næste model?
- Hvilke aftaler, opbevaringsforhold og underdatabehandlere gælder?
- Hvem kan ændre kategorierne, tærsklerne og rettighederne til handlinger?
Disse kontrolpunkter forbinder beskyttelse af data i AI-applikationer med systemets faktiske opbygning. En sandsynlighedsscore er ingen dokumentation for databeskyttelse eller lovlig anvendelse.
Hvad kan teknologien ikke afgøre alene?
Tre niveauer skal vurderes hver for sig: om kategorierne beskriver opgaven, om modellen vælger korrekt, og om den efterfølgende handling er tilladt. En præcis klassifikation kan stadig føre til en forkert arbejdsgang, hvis programmet kobler den til en uhensigtsmæssig handling.
Google anbefaler at behandle input som utroværdigt og teste forsøg på at påvirke klassifikationen. En besked kan selv påstå, at den skal godkendes. Det er derfor en særskilt opgave at undersøge, om systemet følger kriterierne, når indholdet forsøger at styre vurderingen.
Beslutningsmodellen kan levere et signal til softwaren. Ansvaret for at afgrænse anvendelsen, håndtere fejl og godkende handlinger ligger i den samlede løsning.
Hvilke kilder ligger til grund?
Nyheden bygger på Googles lancering af Gemini Decisions API. Tekniske grænser og svarformater fremgår af modelbeskrivelsen og API-vejledningen. Pris- og adgangsforskelle er kontrolleret på den aktuelle prisside. Datavinklen bygger på Datatilsynets cloudvejledning.