Cloudflare: Clef Omni

Cloudflare Clef Omni er den multimodale mixture-of-experts-model i Clef-familien af beslutningsmodeller. Den er eftertrænet på forståelsesgrundmodellen Qwen3-Omni-30B-A3B-Instruct med 30B parametre i alt og 3B aktive parametre. Cloudflare tilføjer et fælles skemahoved, som knytter evidens til de ønskede spørgsmål og scorer deres tilladte svarmuligheder samlet. Resultatet er en typet beslutning med sandsynligheder frem for en genereret forklaring, transskription eller tale.

Forbered to hoveddele: en tilstand, der beskriver situationen, og en mapping af navngivne spørgsmål. Tilstanden kan være tekst eller struktureret JSON, og modellens native input omfatter også billeder, lyd og video. Hvert spørgsmål angiver, hvad der skal afgøres, og hvilke svar der er tilladt. Hold identifikatorerne stabile, så en applikation kan knytte hvert returneret svar til det oprindelige spørgsmål. Tydelige beskrivelser af svarmulighederne giver kategorien mening; en kort, tvetydig etiket kan ellers skjule den forskel, arbejdsgangen faktisk har brug for.

Postformatet har tre spørgsmålstyper. Et noul-spørgsmål vedrører en sand/falsk-betingelse og returnerer sandsynligheden for sand. Et choice-spørgsmål definerer navngivne svarmuligheder og returnerer en valgt mulighed, sandsynligheder for hver mulighed og en særskilt konfidensværdi. Et score-spørgsmål definerer ordnede kriterier med indeks fra nul og returnerer en sandsynlighedsvægtet score, en tegnforklaring og sandsynligheder. Scoren kan have decimaler, fordi den afspejler en fordeling over niveauer. En beslutning rummer dermed mere end en enkelt etiket, men er stadig afgrænset af det indsendte skema.

Ved visuel gennemgang skal du indsende et tydeligt billede og den betingelse, der skal vurderes. Et eksempel er en installationspost med spørgsmål om, hvorvidt identifikationsmærkaten er synlig, hvilken af de definerede tilstandskategorier der passer, og om evidensen er tilstrækkelig til en gennemgang. Hold observationerne adskilt: At en mærkat er synlig, er et andet spørgsmål end, om en installation ser færdig ud. Outputtet kan hjælpe en applikation med at sende posten videre eller markere et forhold til gennemgang; det udfører ikke selv en inspektion, ændrer en post eller genererer en skriftlig rapport.

Ved lyd og video skal spørgsmålene fokusere på evidens, som det indsendte klip kan understøtte. En praktisk udstyrsgennemgang kan omfatte et foto, en optagelse og en kort video med spørgsmål om, hvorvidt en bestemt lyd er til stede, eller om en komponent synligt bevæger sig. Producenten beskriver, at videoens lydspor behandles sammen med dens billeder, når alle videoer i posten har lyd. Bevar sammenhængen mellem medierne og den skriftlige tilstand, og undgå at bede modellen klassificere en hændelse uden for det vedhæftede tidsinterval.

Producentens hostede profil angiver en kontekst på 64.000 tokens og ét til 64 spørgsmål. Den accepterer op til fire billeder, fire lydklip og to videoer, med højst 300 sekunder pr. lydklip og 60 sekunder pr. video. Det er grænser for den dokumenterede producentgrænseflade. Medier og spørgsmål optager kontekst; for mange medier kan få anmodningen til at fejle, mens en lang teksttilstand kan blive afkortet for at passe. Saml den afgørende evidens i en fokuseret post, og forbered spørgsmålene, før kontekstvinduet bruges på uvedkommende historik.

Producentens hostede grænseflade modtager indlejrede medier frem for eksterne links. PNG-, JPEG- eller WebP-billeder er begrænset til 4 MiB og 16 megapixels pr. billede med et samlet budget på 8 MiB afkodede billeddata. Hvert lydklip er begrænset til 8 MiB og 300 sekunder; hver video til 16 MiB og 60 sekunder. Lyd og video må tilsammen højst udgøre 16 MiB afkodede data, og videoer samples med to billeder pr. sekund. Disse grænser gælder for denne producentgrænseflade; encoderen med åbne modelvægte accepterer yderligere lokale repræsentationer. At forståelsesgrundmodellen kan behandle lyd, betyder ikke, at denne beslutningsmodel producerer lyd: Dens komponenter til talegenerering bruges ikke til beslutningsscoring.

Ved support- eller arbejdsgangsrouting skal kategorier og ordnede kriterier defineres ud fra de faktiske driftsregler. En supportpost kan spørge, hvilket team der skal håndtere den, om påvirkningen er akut, og hvilket alvorlighedsniveau der passer bedst til evidensen. Det observerbare output er et sæt typede svar under disse spørgsmålsnavne. Gennemgå hele sandsynlighedsfordelingen, når kategorierne ligger tæt, og fastlæg udtrykkeligt, hvordan applikationen håndterer usikre tilfælde. En høj sandsynlighed er modellens vurdering af den indsendte evidens og ikke bevis for, at betingelsen er blevet verificeret uafhængigt.

Gem tilstanden, spørgsmålsskemaet og de returnerede svar sammen, når du undersøger et resultat. Kontrollér, om svarmulighederne dækker den faktiske situation, om deres beskrivelser overlapper, og om vigtig evidens er udeladt eller afkortet. Hvis et efterfølgende trin kræver en skriftlig forklaring, kan beslutningen og kildematerialet bruges som input til et særskilt skrivetrin. Clef Omnis nyttige rolle er at score definerede alternativer ud fra multimodal evidens, så næste handling kan vælges med tydelige input og output, der kan undersøges.