Azure OpenAI Decisions API: Praktische Klassifizierung

Nutze Ausgaben der Azure OpenAI Decisions API für eine begrenzte Klassifizierung. Mit einem sicheren Routing-Beispiel sowie aktuellen Hinweisen zu Verfügbarkeit, Datenschutz und Preisen.

Harllens George de la Cruz | Published: 2026-11-11 | Updated: 2026-11-11

Redaktionelles Cover zur Azure OpenAI Decisions API: Eine typisierte /openai/v1/decisions-Antwort verzweigt sich in die Ausgaben Predicate, Choice und Score.
Cover zur Azure OpenAI Decisions API: typisierte Entscheidungsausgaben für begrenzte Klassifizierung mit einem unveränderten offiziellen Azure-OpenAI-Symbol. Originale deterministische redaktionelle Komposition mit dem unveränderten offiziellen Azure-OpenAI-Symbol aus den Azure-Architecture-Symbolen von Microsoft; kein Produktscreenshot und keine Empfehlung.

Die Azure OpenAI Decisions API ist ein dedizierter Endpunkt, mit dem ein Modell Belege bewertet und typisierte Antworten zurückgibt, statt einen Absatz mit generiertem Text zu schreiben. Sie kann ein Prädikat prüfen, aus von dir definierten Optionen auswählen oder eine Eingabe anhand einer geordneten Bewertungsrubrik einstufen. Dieser Leitfaden zeigt, wie du diese Ausgaben als begrenzte Anwendungssignale nutzt, mit einem synthetischen Beispiel für Support-Triage sowie den aktuellen Vorbehalten zu Verfügbarkeit, Datenschutz und Preisen.

Was die Decisions API tut

Der Endpunkt lautet /openai/v1/decisions. Eine Anfrage enthält ein Modelldeployment, eine gemeinsame Eingabe und eine oder mehrere benannte Fragen. Die Antwort enthält ein answers-Array und die Token-Nutzung. Die dokumentierten Fragetypen sind:

Typ Ausgabe Geeignet für
predicate Eine Wahrscheinlichkeit zwischen 0 und 1 dafür, dass eine Bedingung wahr ist Fragt ein Kunde nach einer Rückerstattung? Zeigt dieses Bild einen sichtbaren Schaden?
choice Ein Wert aus deinen festen Optionen mit Wahrscheinlichkeiten und Konfidenz Welche Support-Warteschlange soll diese Anfrage erhalten?
score Ein wahrscheinlichkeitsgewichteter Durchschnitt über geordnete Level-Indizes sowie Level-Wahrscheinlichkeiten und Konfidenz Wie dringend ist dieses Problem auf einer definierten Skala?

Verwende choice für eine Kategorie und score für eine geordnete Skala. Ein Score kann zwischen den Leveln liegen: Wenn das Modell Wahrscheinlichkeiten auf benachbarte Level verteilt, ist die zurückgegebene Zahl deren gewichteter Durchschnitt und nicht zwingend eines der Labels. Microsoft dokumentiert die Anfragestruktur, Antworttypen und diese Unterschiede in Azure OpenAI Decisions API verwenden.

Die API unterscheidet sich von einem Endpunkt, der eine frei formulierte Erklärung schreiben oder ein Objekt nach einem beliebigen JSON-Schema erzeugen soll. Microsofts Leitfaden verweist für schema-konforme Objekte auf strukturierte Ausgaben mit der Responses API und auf Function Calling, wenn ein Modell einen Tool-Aufruf mit Argumenten anfordern soll. Wähle den Endpunkt danach aus, was deine Anwendung verarbeiten muss.

Verfügbarkeit und Voraussetzungen

Microsofts Foundry-Ankündigung beschreibt GPT-6 Luna als allgemein in Microsoft Foundry verfügbar. Das bedeutet jedoch nicht, dass dieser Endpunkt in jeder Modellregion verfügbar ist. Die aktuelle Seite zur Decisions API nennt gpt-6-luna als einzig unterstütztes Modell, beschreibt einen Rollout in Regionen, in denen es verfügbar ist, und schließt East US 2 ausdrücklich aus. Als Voraussetzungen nennt sie ein Azure-Abonnement, eine Azure-OpenAI-Ressource und ein gpt-6-luna-Deployment. Außerdem dokumentiert sie die Authentifizierung per API-Key und Microsoft Entra ID. Prüfe die Endpunkt- und Deployment-Optionen für deine Ressource, bevor du sie zu einer festen Abhängigkeit machst. Behandle die Endpunktdokumentation als maßgebliche Quelle für diese API.

Der Parameter model ist der Name des Deployments, nicht zwingend der kanonische Name des zugrunde liegenden Modells. In Microsofts Beispielen heißt das Deployment gpt-6-luna. Wenn dein Deployment anders heißt, sende diesen Deployment-Namen. Für die dokumentierten JavaScript-Beispiele nennt Microsoft Node.js und openai ab Version 7.30.0.

Praktisches Integrationsmuster

Behandle die API-Antwort als Eingang für eine deterministische Anwendungsrichtlinie und nicht als Richtlinie selbst. Benenne jede Frage eindeutig, formuliere enge Anweisungen und unterscheidbare Optionen, füge eine Fallback-Auswahl wie other hinzu und lege im Anwendungscode fest, was bei geringer Konfidenz oder einer Ablehnung passiert.

Konzeptioneller Ablauf von den Anwendungsbelegen über benannte Decisions-API-Fragen zu typisierten Ausgaben, Validierung und einer kontrollierten Anwendungsroute.

Synthetisches Arbeitsbeispiel: Support-Queue-Triage

Das folgende Beispiel klassifiziert ein synthetisches Ticket. Es fragt nach einer Problemkategorie und einem Signal für eine Rückerstattungsanfrage. Die Bezeichner, Optionen, Schwellenwerte und Beispielausgaben sind illustrativ. Sie stellen keinen echten Kundendatensatz und kein gemessenes Modellergebnis dar.

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: process.env.AZURE_OPENAI_BASE_URL,
  apiKey: process.env.AZURE_OPENAI_API_KEY,
});

const decision = await client.decisions.create({
  // Setze dies auf den Namen deines gpt-6-luna-Deployments.
  model: process.env.AZURE_OPENAI_DEPLOYMENT,
  input: "Synthetic ticket: The glass jar arrived cracked. Please replace it.",
  questions: [
    {
      type: "choice",
      name: "issue_type",
      instructions: "Choose the main support category supported by the message.",
      choices: [
        { value: "item_damage", description: "The delivered item is broken or damaged." },
        { value: "delivery", description: "The request is about shipping or arrival." },
        { value: "billing", description: "The request is about a charge or payment." },
        { value: "other", description: "The message does not fit another option." },
      ],
    },
    {
      type: "predicate",
      name: "replacement_requested",
      instructions: "Does the customer explicitly ask for a replacement?",
    },
  ],
});

const issue = decision.answers.find((answer) => answer.name === "issue_type");
const replacement = decision.answers.find((answer) => answer.name === "replacement_requested");

// Nur Beispielrichtlinie: Mehrdeutige Ergebnisse gehen an eine Person; das Modell löst nie eine Ersatzlieferung aus.
const queue = issue?.type === "choice"
  && issue.choice !== "other"
  && issue.confidence >= 0.75
  ? issue.choice
  : "human_review";

const replacementSignal = replacement?.type === "predicate"
  ? replacement.probability
  : null;

console.log({ queue, replacementSignal, usage: decision.usage });

Für dieses synthetische Ticket könnte eine illustrative Antwort issue_type = item_damage mit einer Konfidenz über dem Beispielschwellenwert und replacement_requested = true mit hoher Prädikatswahrscheinlichkeit enthalten. Diese Ausgabe kann die Schadenswarteschlange vorschlagen und einer Person bei der Priorisierung der Prüfung helfen. Sie beweist nicht, dass das Glas beschädigt wurde, begründet keinen Anspruch und autorisiert keinen Ersatz. Deine Anwendung sollte Bestellung und Richtlinie mit vertrauenswürdigen Systemen validieren, fehlende oder abgelehnte Antworten behandeln und vor einer folgenreichen Aktion die passende Bestätigung und menschliche Freigabe verlangen.

Der Schwellenwert 0.75 ist ein Platzhalter und keine Empfehlung von Microsoft. Kalibriere Schwellenwerte anhand repräsentativer, geprüfter Beispiele und miss sowohl falsch positive als auch falsch negative Ergebnisse. Teste außerdem eine Nachricht außerhalb des Geltungsbereichs, gemischte Absichten, fehlende Belege, einen nicht erkannten Antworttyp, eine Ablehnung und einen API-Fehler. Leite Unsicherheit an einen sicheren Fallback weiter, statt stillschweigend die erste Option auszuwählen.

Setze für das Codebeispiel AZURE_OPENAI_BASE_URL auf https://<resource-name>.openai.azure.com/openai/v1/, AZURE_OPENAI_DEPLOYMENT auf den Namen deines gpt-6-luna-Deployments und AZURE_OPENAI_API_KEY in einer serverseitigen Geheimnisablage. Lege einen Azure-OpenAI-Key niemals in Browsercode offen. Wenn es besser zu deinem Identitäts- und Geheimnismanagement passt, wird auch die Authentifizierung mit Entra ID unterstützt.

Eingaben, Bilder und Antwortverarbeitung

Text kann als String oder als User Message gesendet werden. Eine Nachricht kann außerdem input_text- und input_image-Teile kombinieren. Die aktuelle Learn-Seite nennt Unterstützung für PNG, JPG, WebP und GIF, bis zu 128 Bilder pro Anfrage und eine maximale kombinierte Bildgröße von 32 MB. Beziehe die Bildverarbeitung nur ein, wenn visuelle Belege tatsächlich erforderlich sind, und teste sie mit Beispielen, die Beleuchtung, Perspektiven und Bildqualität deines realen Ablaufs abbilden.

Lies Antworten über name aus und prüfe den type jeder Antwort, bevor du auf Felder wie choice, confidence oder probability zugreifst. Die API kann eine refusal zurückgeben. Behandle dies als eigenes Ergebnis. Protokolliere die für den Betrieb erforderliche Request-ID und Token-Nutzung, aber bewahre rohe Eingaben oder sensible Ausgaben nicht länger auf, als es deine Richtlinie erlaubt.

Datenschutz, Datenverarbeitung und Preise

Microsofts Leitfaden zu Daten, Datenschutz und Sicherheit für von Azure verkaufte Foundry-Modelle sagt, dass Prompts und Vervollständigungen von über Azure verkauften Modellen anderen Kunden nicht zur Verfügung stehen und von Modellanbietern ohne Erlaubnis oder Anweisung nicht zur Verbesserung von Modellen oder Diensten verwendet werden. Derselbe Leitfaden beschreibt die Verarbeitung durch den Dienst für Betrieb, Missbrauchsüberwachung und Inhaltssicherheit. Die Verarbeitungsregion hängt vom Deployment-Typ ab: Standard bleibt innerhalb der angegebenen Geografie, während Global- und Data-Zone-Deployments über die jeweils geltende Geografie oder Zone hinweg verarbeiten können. Stateful-Funktionen können abhängig von ihrer Konfiguration ebenfalls Daten speichern. Wende deine eigenen Anforderungen an Datenklassifizierung, Aufbewahrung, Zugriff und Region auf die ausgewählte Ressource und das Deployment an. Das ist keine pauschale Garantie, dass keine Verarbeitung oder Überwachung stattfindet.

Decisions-Antworten enthalten die Token-Nutzung, aber Token-Zahlen sind kein Preisangebot. Die Seite zur Decisions API verweist auf die Azure-OpenAI-Preisseite, statt einen endpunktspezifischen Tarif zu veröffentlichen. Microsofts Foundry-Preisankündigung vom 22. September nennt für GPT-6 Luna Standard im Kurzkontext Global-Preise von 0,10 USD pro Million Eingabetoken und 0,50 USD pro Million Ausgabetoken sowie 0,12 USD pro Million Eingabetoken und 0,60 USD pro Million Ausgabetoken für die EU Data Zone. Preise für langen Kontext, gecachte Token, andere Deployments, Regionen und Verträge unterscheiden sich. Das sind Modellpreise, kein endpunktspezifisches Angebot und keine vollständige Schätzung der Aufgabenkosten. Prüfe vor der Budgetierung die aktuelle Preisseite, das ausgewählte Deployment, die Region und deine Vereinbarung.

Häufige Fehler, die du vermeiden solltest

  • Eine Prädikatswahrscheinlichkeit oder Choice-Konfidenz als kalibrierte Garantie behandeln.
  • score verwenden, obwohl die Anwendung eine feste Kategorie braucht, oder einen gebrochenen Score als ausgewähltes Level interpretieren.
  • Keine Fallback-Option für Eingaben außerhalb der Kategorienliste vorsehen.
  • Das Modellergebnis als Autorisierungsentscheidung für Rückerstattungen, Berechtigung, Kontoänderungen oder andere folgenschwere Aktionen verwenden.
  • Einen Modellnamen senden, obwohl die API den Namen deines Deployments erwartet.
  • Annehmen, dass der Endpunkt in jeder Azure-OpenAI-Region verfügbar ist oder dass ein an anderer Stelle aufgeführtes Modell von diesem Endpunkt unterstützt wird.
  • Annehmen, dass die Beschreibung zur Datenverarbeitung des Modells deine eigenen Pflichten zu Aufbewahrung, Zugriffskontrolle und Compliance beseitigt.
  • Veröffentlichte Tokenpreise als Angebot für eine bestimmte Anfrage, ein bestimmtes Deployment oder den vollständigen Workflow behandeln.

Nächste Schritte

Prüfe die regionale Verfügbarkeit und deploye das unterstützte Modell, bevor du Anwendungscode schreibst. Beginne mit synthetischen Eingaben und einem Fragetyp, erfasse die typisierte Antwort und Nutzung und baue eine deterministische Behandlung für geringe Konfidenz, Ablehnung, unbekannte Antworten und Dienstfehler. Erweitere erst, wenn ein geprüftes Evaluationsset zeigt, dass deine Schwellenwerte und Fallback-Route angemessen sind.

Fazit

Die Azure OpenAI Decisions API eignet sich, wenn eine Anwendung ein Prädikat, eine Auswahl aus bekannten Werten oder einen Score über geordnete Level benötigt und keinen generierten Fließtext. Ihre typisierten Ausgaben können Routing und Priorisierung leichter integrierbar machen, bleiben aber Modellschätzungen. Prüfe die sich ändernde regionale Verfügbarkeit, sichere den gesamten Datenfluss, validiere Ausgaben in deterministischem Code und halte folgenschwere Entscheidungen hinter der Richtlinie deiner Anwendung und menschlicher Prüfung.

Quellen

Weiterführende Lektüre

Redaktioneller Hinweis: Dieser KI-unterstützte Leitfaden verwendet synthetische Beispiele. Es wurde weder auf eine Azure-Ressource noch auf einen Endpunkt oder Kundendaten zugegriffen, und es wurde kein Aufruf getestet.