Cloudflare: Clef Omni

Cloudflare Clef Omni er den multimodale mixture-of-experts-modellen i Clef-familien av beslutningsmodeller. Den er ettertrent fra forståelsesgrunnmodellen Qwen3-Omni-30B-A3B-Instruct, med totalt 30B parametere og 3B aktive parametere. Cloudflare legger til et felles skjemahode som knytter evidens til de ønskede spørsmålene og skårer de tillatte alternativene samlet. Resultatet er en typet beslutning med sannsynligheter, fremfor en generert forklaring, transkripsjon eller tale.

Forbered to hoveddeler: en tilstand som beskriver situasjonen, og en tilordning av navngitte spørsmål. Tilstanden kan være tekst eller strukturert JSON, og modellens native inndata omfatter også bilder, lyd og video. Hvert spørsmål angir hva som skal avgjøres, og hvilke svar som er tillatt. Hold identifikatorene stabile, slik at en applikasjon kan knytte hvert returnerte svar til det opprinnelige spørsmålet. Tydelige beskrivelser av alternativene gir kategorien mening; en kort, tvetydig etikett kan ellers skjule skillet arbeidsflyten faktisk trenger.

Postformatet har tre spørsmålstyper. Et noul-spørsmål gjelder en sann/usann-betingelse og returnerer sannsynligheten for sann. Et choice-spørsmål definerer navngitte alternativer og returnerer et valgt alternativ, sannsynligheter for hvert alternativ og en separat konfidensverdi. Et score-spørsmål definerer ordnede kriterier med indekser fra null og returnerer en sannsynlighetsvektet skår, en tegnforklaring og sannsynligheter. Skåren kan ha desimaler fordi den gjenspeiler en fordeling over nivåer. En beslutning inneholder derfor mer informasjon enn en enkelt etikett, samtidig som den fortsatt er avgrenset av det innsendte skjemaet.

For visuell gjennomgang sender du inn et tydelig bilde og betingelsen som skal vurderes. Et eksempel er en installasjonspost med spørsmål om identifikasjonsetiketten er synlig, hvilken av de definerte tilstandskategoriene som passer, og om evidensen er tilstrekkelig for gjennomgang. Hold observasjonene atskilt: Om en etikett er synlig, er et annet spørsmål enn om en installasjon ser ferdig ut. Resultatet kan hjelpe en applikasjon med å rute posten eller markere et forhold for gjennomgang; det utfører ikke selv en inspeksjon, endrer en post eller genererer en skriftlig rapport.

For lyd og video bør spørsmålene dreie seg om evidens det innsendte klippet kan underbygge. En praktisk utstyrsvurdering kan omfatte et foto, et opptak og en kort video, med spørsmål om en bestemt lyd er til stede, eller om en komponent beveger seg synlig. Produsenten beskriver at videoens lydspor behandles sammen med bildene når alle videoer i posten har lyd. Bevar sammenhengen mellom mediene og den skriftlige tilstanden, og unngå å be modellen klassifisere en hendelse som ligger utenfor det vedlagte tidsintervallet.

Produsentens vertsbaserte profil oppgir en kontekst på 64 000 tokener og ett til 64 spørsmål. Den godtar opptil fire bilder, fire lydklipp og to videoer, med maksimalt 300 sekunder per lydklipp og 60 sekunder per video. Dette er grensene for det dokumenterte produsentgrensesnittet. Medier og spørsmål opptar kontekst; for mye medieinnhold kan få forespørselen til å feile, mens en lang teksttilstand kan bli avkortet for å få plass. Samle avgjørende evidens i en fokusert post, og forbered spørsmålene før vinduet brukes på uvedkommende historikk.

Produsentens vertsbaserte grensesnitt tar imot innebygde medier fremfor eksterne lenker. PNG-, JPEG- eller WebP-bilder er begrenset til 4 MiB og 16 megapiksler per bilde, med et samlet budsjett på 8 MiB dekodede bildedata. Hvert lydklipp er begrenset til 8 MiB og 300 sekunder; hver video til 16 MiB og 60 sekunder. Lyd og video kan til sammen utgjøre høyst 16 MiB dekodede data, og videoer samples med to bilder per sekund. Disse grensene gjelder dette produsentgrensesnittet; enkoderen med åpne modellvekter godtar flere lokale representasjoner. At forståelsesgrunnmodellen kan behandle lyd, betyr ikke at denne beslutningsmodellen produserer lyd: Komponentene for talegenerering brukes ikke til beslutningsskåring.

Ved ruting av support eller arbeidsflyt definerer du kategorier og ordnede kriterier ut fra de faktiske driftsreglene. En sakspost kan spørre hvilket team som skal håndtere den, om konsekvensen er akutt, og hvilket alvorlighetsnivå som passer best med evidensen. Det observerbare resultatet er et sett med typede svar under disse spørsmålsnavnene. Undersøk hele sannsynlighetsfordelingen når kategoriene ligger nær hverandre, og definer uttrykkelig hvordan applikasjonen behandler usikre tilfeller. En høy sannsynlighet er modellens vurdering av den innsendte evidensen, ikke bevis på at betingelsen er uavhengig bekreftet.

Oppbevar tilstanden, spørsmålsskjemaet og de returnerte svarene sammen når du undersøker et resultat. Kontroller om alternativene dekker den faktiske situasjonen, om beskrivelsene overlapper, og om viktig evidens er utelatt eller avkortet. Hvis et senere trinn trenger en skriftlig forklaring, kan beslutningen og kildematerialet brukes som inndata til et separat skrivetrinn. Clef Omnis nyttige rolle er å skåre definerte alternativer ut fra multimodal evidens, slik at neste handling kan velges med tydelige inndata og resultater som kan undersøkes.