Cloudflare: Clef Omni

Cloudflare Clef Omni ist das multimodale Mixture-of-Experts-Modell der Clef-Entscheidungsfamilie. Es ist per Post-Training aus dem Verständnis-Backbone Qwen3-Omni-30B-A3B-Instruct hervorgegangen und hat insgesamt 30B Parameter, davon 3B aktiv. Cloudflare ergänzt einen gemeinsamen Schema-Kopf, der die Belege den angefragten Fragen zuordnet und deren zulässige Optionen gemeinsam bewertet. Das Ergebnis ist eine typisierte Entscheidung mit Wahrscheinlichkeiten statt einer generierten Erklärung, eines Transkripts oder einer Sprachausgabe.

Bereiten Sie zwei Hauptbestandteile vor: einen Zustand, der die Situation beschreibt, und eine Zuordnung benannter Fragen. Der Zustand kann Text oder strukturiertes JSON sein, und zu den nativen Eingaben des Modells gehören außerdem Bilder, Audio und Video. Jede Frage legt fest, was entschieden werden soll und welche Antworten zulässig sind. Halten Sie die Bezeichner stabil, damit eine Anwendung jede zurückgegebene Antwort der ursprünglichen Frage zuordnen kann. Klare Optionsbeschreibungen machen eine Kategorie aussagekräftig; eine kurze, mehrdeutige Bezeichnung kann sonst genau die Unterscheidung verdecken, die der Workflow tatsächlich benötigt.

Das Datensatzformat kennt drei Fragetypen. Eine „noul“-Frage bezieht sich auf eine Wahr/Falsch-Bedingung und liefert die Wahrscheinlichkeit für „wahr“. Eine „choice“-Frage definiert benannte Optionen und liefert eine ausgewählte Option, Wahrscheinlichkeiten pro Option und einen separaten Konfidenzwert. Eine „score“-Frage definiert geordnete Kriterien mit einem Index ab null und liefert einen wahrscheinlichkeitsgewichteten Score, eine Legende und Wahrscheinlichkeiten. Der Score kann ein Bruchwert sein, weil er eine Verteilung über die Stufen widerspiegelt. Eine Entscheidung ist damit reichhaltiger als ein einzelnes Label und bleibt dennoch durch das bereitgestellte Schema begrenzt.

Für die visuelle Prüfung stellen Sie ein klares Bild und die zu bewertende Bedingung bereit. Ein Beispiel ist ein Installationsdatensatz mit Fragen danach, ob das Kennzeichnungsetikett sichtbar ist, welche der definierten Zustandskategorien zutrifft und ob die Belege für eine Prüfung ausreichen. Halten Sie Beobachtungen getrennt: Ob ein Etikett sichtbar ist, ist eine andere Frage als die, ob eine Installation vollständig wirkt. Die Ausgabe kann einer Anwendung helfen, den Datensatz weiterzuleiten oder eine Prüfbedingung zu markieren; sie führt selbst keine Inspektion durch, ändert keinen Datensatz und erstellt keinen schriftlichen Bericht.

Richten Sie bei Audio und Video die Fragen auf Belege aus, die der bereitgestellte Clip liefern kann. Eine praxisnahe Geräteprüfung kann ein Foto, eine Aufnahme und ein kurzes Video umfassen und fragen, ob ein bestimmtes Geräusch vorhanden ist oder ob sich ein Bauteil sichtbar bewegt. Der Hersteller beschreibt, dass die Tonspur eines Videos zusammen mit seinen Einzelbildern verarbeitet wird, wenn jedes Video im Datensatz Ton hat. Bewahren Sie den Zusammenhang zwischen den Medien und dem schriftlichen Zustand, und bitten Sie das Modell nicht, ein Ereignis zu klassifizieren, das außerhalb des angehängten Zeitabschnitts liegt.

Das vom Hersteller gehostete Profil nennt einen Kontext von 64.000 Token und ein bis 64 Fragen. Es akzeptiert bis zu vier Bilder, vier Audioclips und zwei Videos, wobei Audioclips auf jeweils 300 Sekunden und Videos auf jeweils 60 Sekunden begrenzt sind. Dies sind Grenzen der dokumentierten Herstellerschnittstelle. Medien und Fragen belegen Kontext; zu viele Medien können die Anfrage scheitern lassen, während ein langer Textzustand gekürzt werden kann, damit er passt. Legen Sie entscheidende Belege in einen fokussierten Datensatz und bereiten Sie die Fragen vor, bevor Sie das Kontextfenster mit themenfremdem Verlauf füllen.

Die gehostete Schnittstelle des Herstellers nimmt eingebettete Medien statt Remote-Links an. PNG-, JPEG- oder WebP-Bilder sind auf jeweils 4 MiB und 16 Megapixel begrenzt, bei einem Gesamtbudget von 8 MiB für dekodierte Bilder. Jeder Audioclip ist auf 8 MiB und 300 Sekunden begrenzt, jedes Video auf 16 MiB und 60 Sekunden. Audio und Video zusammen dürfen dekodiert höchstens 16 MiB umfassen, und Videos werden mit zwei Bildern pro Sekunde abgetastet. Diese Grenzen gehören zu dieser Herstellerschnittstelle; der Open-Weight-Encoder akzeptiert zusätzliche lokale Darstellungen. Die Audiofähigkeit des Verständnis-Backbones bedeutet nicht, dass dieses Entscheidungsmodell Audio erzeugt: Die Komponenten zur Sprachgenerierung werden für die Bewertung von Entscheidungen nicht verwendet.

Für Support- oder Workflow-Routing definieren Sie Kategorien und geordnete Kriterien anhand der tatsächlichen Betriebsregeln. Ein Ticket-Datensatz kann fragen, welches Team ihn bearbeiten soll, ob die Auswirkung dringend ist und welche Schweregradstufe am besten zu den Belegen passt. Die beobachtbare Ausgabe ist ein Satz typisierter Antworten unter diesen Fragenamen. Prüfen Sie die gesamte Wahrscheinlichkeitsverteilung, wenn Kategorien nah beieinanderliegen, und legen Sie ausdrücklich fest, wie die Anwendung mit unsicheren Fällen umgeht. Eine hohe Wahrscheinlichkeit ist eine Modelleinschätzung der bereitgestellten Belege, kein Nachweis, dass die Bedingung unabhängig überprüft wurde.

Bewahren Sie Zustand, Fragenschema und zurückgegebene Antworten zusammen auf, wenn Sie ein Ergebnis untersuchen. Prüfen Sie, ob die Optionen die tatsächliche Situation abdecken, ob sich ihre Beschreibungen überschneiden und ob wichtige Belege fehlten oder gekürzt wurden. Wenn ein nachgelagerter Schritt eine schriftliche Erklärung benötigt, kann er die Entscheidung und das Quellmaterial als Eingabe für einen separaten Schreibschritt verwenden. Die nützliche Rolle von Clef Omni besteht darin, definierte Alternativen anhand multimodaler Belege zu bewerten, sodass die nächste Aktion mit einer klaren, nachvollziehbaren Ein- und Ausgabe gewählt werden kann.