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.
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.
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.
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.
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 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.
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.
", "aboutText": "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.\n\n### Gemeinsamer Zustand und aussagekräftige Fragenamen\n\nDie 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.\n\nDas 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.\n\n### Noul: eine geschätzte positive Antwort\n\nEine 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.\n\nFassen 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.\n\n### Choice: eine benannte Option auswählen\n\nEine 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.\n\nEin 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.\n\n### Score: eine erwartete Position auf einem Bewertungsraster\n\nEine 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.\n\nEin 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.\n\n### Ein nützliches Entscheidungsergebnis vorbereiten\n\nEin 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.\n\nDie 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.\n\n### Umfang und Grenzen der Schnittstelle\n\nInception 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.\n\nBewerten 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.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "7c286c421f1b5c77f9e416be1562444d1fb397b8198ba0f0cbccbb21434883f7", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "de", "methods": [ { "html": "inception/mercury-decide:freeMercury Decide bewertet gemeinsame Text- oder JSON-Belege anhand benannter Fragen und gibt typisierte Auswahlen, Ja/Nein-Wahrscheinlichkeiten oder Bewertungsraster-Scores mit Nachkommastellen zurück. Inception dokumentiert einen eigenen Entscheidungsworkflow mit bis zu 255 Choice-Optionen und zehn Score-Stufen.
Diese Beschreibung erläutert die Fähigkeiten des Modells. Die über Ailoot verfügbaren Eingaben, Ausgaben und Optionen sind unten für die ausgewählte Methode aufgeführt.
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.
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.
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.
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.
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 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.
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.
POST /v1/systemonetextdecisions| Feld | Typ | Anforderung | Werte und Limits | Standard |
|---|---|---|---|---|
Feldmodel | Typstring | AnforderungErforderlich | Werte und Limits inception/mercury-decide:free | Standard— |
Feldprovider | Typschema | AnforderungOptional | Werte und Limits | Standard— |
Feldquestions | Typobject | AnforderungErforderlich | Werte und Limits | Standard— |
Feldsession_id | Typstring | AnforderungOptional | Werte und Limits | Standard— |
Feldstate | Typschema | AnforderungErforderlich | Werte und Limits | Standard— |
Feldtrace | Typschema | AnforderungOptional | Werte und Limits | Standard— |
Felduser | Typstring | AnforderungOptional | Werte und Limits | Standard— |
Feldquestions.<id>.type | Typstring | AnforderungErforderlich | Werte und Limits noul, choice, score | Standard— |
Feldquestions.<id>.instructions | Typstring|object|array | AnforderungErforderlich | Werte und Limits | Standard— |
Feldquestions.<id>.criteria | Typobject|array | AnforderungOptional | Werte und Limits Bedingungen: choice/score: erforderlich; noul: optional. Bei choice ist criteria ein Objekt; bei score ist es ein Array mit minItems=1. | Standard— |
Feldquestions.<id>.criteria.true | Typstring|object|array | AnforderungErforderlich | Werte und Limits Gilt, wenn: Kriterienobjekt noul bereitgestellt | Standard— |
Feldquestions.<id>.criteria.false | Typstring|object|array | AnforderungErforderlich | Werte und Limits Gilt, wenn: Kriterienobjekt noul bereitgestellt | Standard— |
noul · Erforderlich: state, questions.<id>.type=noul, questions.<id>.instructions
choice · Erforderlich: state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Erforderlich: state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Parameter | Vertrag |
|---|---|
Parametercontent_type | Vertragapplication/json |
Parameterrequired | Vertragmodel, state, questions |
Parametermaterial_types | Vertragtext |
Parameteroptional_controls | Vertragprovider, session_id, trace, user |
Parametermultimodal_input_binding | Vertragnull |
Lebenszyklus: synchronous
Senden Sie die genaue Modell-ID und bewahren Sie die vollständige native Antwort auf.
Tarifangaben erweitern die Anfrageoptionen nicht. Unterstützte Parameter stehen bei der ausgewählten Methode.
Ordnen Sie jede Gebühr den angezeigten Bedingungen zu. Verwenden Sie für jede Gruppe alternativer Konfigurationen einen Tarif.
| Konfiguration | Tarifstaffel | Kontexttoken, mehr als | Kontexttoken, bis einschließlich | Gebühr |
|---|---|---|---|---|
| KonfigurationBasistarife für Token | TarifstaffelGrundtarif | Kontexttoken, mehr als— | Kontexttoken, bis einschließlichKeine Obergrenze | Gebühr Eingabe · Eingabetoken $0 / 1K Token Ausgabe · Ausgabetoken $0 / 1K Token Eingabe · Cache-Lesen — / 1K Token Eingabe · Cache-Schreiben — / 1K Token Eingabe · Cache-Schreiben, 1 Stunde — / 1K Token |
| KonfigurationAnfragelängenstufe 1 | Tarifstaffel— | Kontexttoken, mehr als0 | Kontexttoken, bis einschließlichKeine Obergrenze | Gebühr Eingabe · Eingabetoken $0 / 1K Token Ausgabe · Ausgabetoken $0 / 1K Token Eingabe · Cache-Lesen — / 1K Token Eingabe · Cache-Schreiben — / 1K Token Eingabe · Cache-Schreiben, 1 Stunde — / 1K Token |
Ailoot reserviert vor einer Anfrage einen geschätzten Betrag. Nach dem Ergebnis rechnet Ailoot die endgültige Gebühr anhand des gemessenen Verbrauchs ab. Bei Streaming erfolgt die Abrechnung anhand des abschließenden Verbrauchsdatensatzes. So funktionieren Reservierung und Abrechnung →
{\n "model": "inception/mercury-decide:free",\n "questions": {\n "is_bug": {\n "criteria": {\n "false": "The customer is asking a question or requesting a feature.",\n "true": "The customer describes broken or unexpected product behavior."\n },\n "instructions": "Is the customer reporting a software defect?",\n "type": "noul"\n },\n "team": {\n "criteria": {\n "account": "Login, permissions, or profile issues.",\n "frontend": "Rendering, layout, or browser compatibility issues.",\n "payments": "Checkout, billing, or payment processing issues."\n },\n "instructions": "Which team should own this ticket?",\n "type": "choice"\n },\n "urgency": {\n "criteria": [\n "Can wait for the next release",\n "Should be fixed this week",\n "Blocking revenue right now"\n ],\n "instructions": "How urgent is this ticket?",\n "type": "score"\n }\n },\n "state": {\n "customer_tier": "enterprise",\n "ticket": "My checkout page shows a blank screen after I click Pay. I have tried two browsers."\n }\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_REQUEST_FILE:?Set your actual JSON request file}"\nexport AILOOT_REQUEST_FILE\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads(Path(os.environ['AILOOT_REQUEST_FILE']).read_text(encoding='utf-8'))\nif not isinstance(p,dict): raise SystemExit('Request must be a JSON object')\np['model']='inception/mercury-decide:free'\nPath('request.json').write_text(json.dumps(p,ensure_ascii=False),encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/systemone \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nprint(json.dumps(json.loads(Path('result.json').read_text()),ensure_ascii=False,indent=2))\nPY_RESULT\njson
Bewahren Sie jede vollständig zurückgegebene Antwort, Datei und jeden Inhaltsteil auf.
Jede bereitgestellte Antwort mit Fragen-ID bleibt mit ihrem genauen Typ, ihrem noul/choice/score-Wert, ihrer Konfidenz, ihren Wahrscheinlichkeiten und ihrer Legende erhalten. Das gesamte ursprüngliche JSON wird gespeichert und erst nach der Abrechnung zurückgegeben.
Bewahren Sie den ursprünglichen Vorgang sowie die vollständige oder teilweise Antwort auf; wiederholen Sie POST nicht.
| Feld | Typ |
|---|---|
Feldmodel | Typstring |
Feldid | Typstring |
Feldprovider | Typstring |
Feldanswers.<id>.type | Typstring |
Feldanswers.<id>.noul | Typnumber |
Feldanswers.<id>.choice | Typstring |
Feldanswers.<id>.score | Typnumber |
Feldanswers.<id>.confidence | Typnumber |
Feldanswers.<id>.probabilities | Typobject |
Feldanswers.<id>.legend | Typobject |
Feldusage.input_tokens | Typinteger |
Feldusage.output_tokens | Typinteger |
Feldusage.cost | Typnumber |
| Antwort | Bedingung | Nächster Schritt |
|---|---|---|
Antwort400 · invalid_request_error | BedingungUngültiges Pflichtfeld, ungültige Darstellung oder ungültiger Wert | Nächster SchrittKorrigieren Sie das angegebene Anfragefeld. |
Ailoot Ultra inception/mercury-decide:free
Verwenden Sie die oben angezeigten Methodenpfade.