Inception: Mercury Decide

Mercury Decide ist das Modell von Inception für strukturierte Entscheidungen über bereitgestellte Belege. Es kombiniert einen gemeinsamen Zustand mit benannten Fragen und gibt typisierte Antworten mit Wahrscheinlichkeiten zurück. Das Ergebnis kann eine ausgewählte Kategorie, eine geschätzte Ja/Nein-Wahrscheinlichkeit oder eine Position auf einer definierten Skala sein. Dieses Profil dient einer begrenzten Entscheidung, die Software interpretieren kann; seine dokumentierte Schnittstelle generiert keine frei formulierte Chat-Antwort.

Gemeinsamer Zustand und aussagekräftige Fragenamen

Die Anfrage des Herstellers enthält ein Modell, einen Zustand und eine nicht leere Map von Fragen. Die Fragenamen bleiben in der Antwort-Map erhalten. Stellen Sie die Informationen bereit, die zur Beurteilung jeder Frage nötig sind, und benennen Sie die Fragen nach den Ergebnissen, die der Workflow verwendet, etwa category, priority oder needs_follow_up. Mehrere Fragen werten dieselben Belege unabhängig voneinander aus. Ihre Anordnung in einer Anfrage macht eine spätere Frage nicht von einer früheren Antwort abhängig.

Das Beispiel von Inception verwendet ein JSON-Objekt für den Zustand. Der Leitfaden erlaubt im Zustand, in den Anweisungen und in den Kriterienbeschreibungen außerdem Strings, Objekte oder Arrays, wobei Anweisungen optional oder null sein können. Bewahren Sie nützliche Strukturen, wenn die Belege bereits aus Feldern bestehen, und halten Sie ein Dokument oder eine Nachricht identifizierbar, wenn Sie Text bereitstellen. Nehmen Sie bei einem Support-Fall die tatsächliche Anfrage und die relevanten Fakten auf, statt fehlenden Kontext erschließen zu lassen.

Noul: eine geschätzte positive Antwort

Eine Frage vom Typ noul steht für eine Ja/Nein-Bedingung. Ihre Ausgabe ist eine Wahrscheinlichkeit von 0 bis 1, dass die positive Antwort zutrifft. Optionale Beschreibungen für true und false können festlegen, was auf jeder Seite der Frage zählt. Fragen Sie beispielsweise, ob eine Nachricht ausdrücklich einen Ersatz anfordert, und grenzen Sie das von einer allgemeinen Beschwerde über den Artikel ab. Die Wahrscheinlichkeit liefert ein numerisches Urteil; die Anwendung wählt den Schwellenwert und die daraus folgende Workflow-Aktion.

Fassen Sie die Bedingung so eng, dass die Belege sie klären können. Wenn eine Frage vermischt, ob der Nutzer Hilfe möchte, ob ein Artikel defekt ist und ob der Fall dringend ist, trennen Sie diese Bedingungen. Bewahren Sie die zurückgegebene Wahrscheinlichkeit zusammen mit der Fragedefinition auf, damit eine spätere Prüfung nachvollziehen kann, was die Zahl tatsächlich misst.

Choice: eine benannte Option auswählen

Eine Choice-Frage verwendet eine Map aus einem bis 255 Optionsnamen und Beschreibungen; Beschreibungen können null sein. Die zurückgegebene Auswahl ist die bereitgestellte Option mit der höchsten Wahrscheinlichkeit. Das Ergebnis enthält außerdem eine Wahrscheinlichkeit für jede Option sowie die Konfidenz. Definieren Sie eindeutige Bedeutungen für die Kategorien und nehmen Sie eine Ausweichkategorie auf, wenn manche Eingaben außerhalb der spezifischen Optionen liegen. Kurze Ausgabeschlüssel können Kategorien kennzeichnen, während ausführlichere Beschreibungen die Grenzen zwischen ihnen festlegen.

Ein Routing-Briefing könnte zwischen einem Zugriffsproblem, einer Produktfrage und einem gemeldeten Fehler unterscheiden. Legen Sie die Bedeutung jeder Option fest und stellen Sie die Nachricht bereit, die weitergeleitet werden soll. Die Ausgabe ist eine ausgewählte Kategorie mit Verteilung, keine Anweisung, die bereits eine Warteschlange geändert oder ein anderes System kontaktiert hat. Untersuchen Sie bei einem mehrdeutigen Fall die konkurrierenden Wahrscheinlichkeiten, statt das gewinnende Label als Beweis für Sicherheit zu deuten.

Score: eine erwartete Position auf einem Bewertungsraster

Eine Score-Frage verwendet ein geordnetes Array aus einer bis zehn Stufenbeschreibungen, beginnend bei Stufe 0. Ihr Score ist der wahrscheinlichkeitsgewichtete Mittelwert der Stufenindizes und kann zwischen Stufen liegen. Die Antwort enthält die Legende, die Wahrscheinlichkeiten je Stufe und die Konfidenz. Definieren Sie die Reihenfolge und die Kriterien für jede Stufe, etwa keine unmittelbare Auswirkung, ein Problem mit praktikabler Alternative und eine vollständig blockierte Aufgabe.

Ein erwarteter Score mit Nachkommastellen ist für Priorisierung oder Aggregation nützlich. Er unterscheidet sich von der Auswahl der einzelnen wahrscheinlichsten Stufe. Bewahren Sie die Legende zusammen mit der Zahl auf, damit ein Score nicht auf einer fremden Skala interpretiert wird. Die Konfidenz für Choice und Score wird separat zwischen 0 und 1 angegeben; der zugehörige Leitfaden definiert sie weder als identisch mit der größten Optionswahrscheinlichkeit noch liefert er eine allgemeingültige Formel, um sie zu rekonstruieren.

Ein nützliches Entscheidungsergebnis vorbereiten

Ein einzelner Beleg kann unabhängige Fragen zu Kategorie, Dringlichkeit und Bedingung stützen. Eine Aufgabe zur Dokumentprüfung kann fragen, ob ein erforderliches Thema vorhanden ist, seine Kategorie wählen und seine Relevanz auf beschriebenen Stufen einstufen. Verwenden Sie nur Quellmaterial, das im Zustand verfügbar ist, mit Kriterien, die an die Entscheidung gebunden sind, die der Workflow als Nächstes benötigt. Wenn eine Aktion ein früheres Ergebnis erfordert, machen Sie dieses Ergebnis in den Belegen für den nächsten Schritt explizit, statt anzunehmen, dass die Fragen eine verborgene Abfolge bilden.

Die Antwort gibt den Modellnamen und eine Antwort-Map zurück, deren Schlüssel die bereitgestellten Fragenamen sind. Choice-Wahrscheinlichkeiten verwenden die Optionsnamen; Score-Wahrscheinlichkeiten verwenden String-Indizes, deren Bedeutung die Legende erklärt. Halten Sie Zustandsbezeichner, Fragedefinitionen und typisierte Antworten miteinander verknüpft. So entsteht ein interpretierbares Klassifikations- oder Bewertungsartefakt statt einer Zahl, die von den Fakten losgelöst ist, aus denen sie entstanden ist.

Umfang und Grenzen der Schnittstelle

Inception dokumentiert Mercury Decide über seine eigene Entscheidungsschnittstelle. Es unterstützt nicht die Chat-Completion-, Streaming- oder Tool-Calling-Schnittstellen des Herstellers; Fähigkeiten aus den Reasoning-, Voice- und Codegenerierungsprofilen von Mercury sind daher nicht auf dieses Modell zu übertragen. Der Entscheidungsleitfaden legt die Anzahl der Optionen und Stufen fest, nennt aber keine numerische Token-Grenze für den Zustand und keine Obergrenze für die Anzahl der Fragen; halten Sie gemeinsame Belege auf die ausgewerteten Fragen fokussiert.

Bewerten Sie Wahrscheinlichkeiten und Kategoriegrenzen anhand repräsentativen gelabelten Materials aus der vorgesehenen Aufgabe. Prüfen Sie Grenzfälle anhand des Zustands und behalten Sie fehlende Informationen als Lücke bei, statt sie durch erfundene Fakten zu ersetzen. Ein nützliches Ergebnis von Mercury Decide liefert eine geschlossene Entscheidung, ihre Wahrscheinlichkeiten und die zu ihrem Verständnis nötigen Definitionen; die umgebende Anwendung bestimmt, wie daraus Routing, Priorisierung oder ein Prüfergebnis wird.