Mercury Decide ist Inceptions Modell für strukturierte Entscheidungen anhand bereitgestellter Belege. Es kombiniert einen gemeinsamen Zustand mit benannten Fragen und gibt typisierte Antworten mit Wahrscheinlichkeiten zurück. Das Ergebnis kann eine gewählte Kategorie, eine geschätzte Ja/Nein-Wahrscheinlichkeit oder eine Position auf einer definierten Skala sein. Dieses Profil liefert eine begrenzte Entscheidung, die Software interpretieren kann; seine dokumentierte Schnittstelle erzeugt keine freie Chatantwort.
Die Anfrage des Anbieters enthält ein Modell, einen Zustand und eine nicht leere Zuordnung von Fragen. Die Fragennamen bleiben in der Antwortzuordnung erhalten. Stellen Sie die zur Beurteilung jeder Frage nötigen Informationen bereit und benennen Sie Fragen nach den Ergebnissen, die der Workflow verwendet, etwa category, priority oder needs_follow_up. Mehrere Fragen bewerten dieselben Belege unabhängig voneinander. Ihre gemeinsame Platzierung in einer Anfrage macht eine spätere Frage nicht von einer früheren Antwort abhängig.
Inceptions Beispiel verwendet ein JSON-Objekt für den Zustand. Der Leitfaden erlaubt außerdem Zeichenfolgen, Objekte oder Arrays im Zustand, in Anweisungen und in Kriterienbeschreibungen, wobei Anweisungen optional oder null sein können. Bewahren Sie nützliche Struktur, wenn die Belege bereits aus Feldern bestehen, und halten Sie bei Texteingaben Dokument oder Nachricht identifizierbar. Nehmen Sie für einen Support-Fall die tatsächliche Anfrage und relevante Fakten auf, statt fehlenden Kontext erschließen zu lassen.
Eine noul-Frage repräsentiert eine Ja/Nein-Bedingung. Ihre Ausgabe ist eine Wahrscheinlichkeit von 0 bis 1 dafür, dass die positive Antwort zutrifft. Optionale true- und false-Beschreibungen können festlegen, was auf jeder Seite der Frage zählt. Fragen Sie beispielsweise, ob eine Nachricht ausdrücklich Ersatz verlangt, und unterscheiden Sie dies von einer allgemeinen Beschwerde über den Artikel. Die Wahrscheinlichkeit liefert ein numerisches Urteil; die Anwendung wählt den Schwellenwert und die daraus folgende Workflow-Aktion.
Halten Sie die Bedingung eng genug, damit 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 bei der Fragendefinition, damit spätere Prüfer erkennen können, was die Zahl tatsächlich misst.
Eine Choice-Frage verwendet eine Zuordnung von 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 und Konfidenz. Definieren Sie unterscheidbare Bedeutungen für Kategorien und nehmen Sie eine Auffangkategorie auf, wenn manche Eingaben außerhalb der konkreten Optionen liegen werden. Kurze Ausgabeschlüssel können Kategorien identifizieren, während ausführlichere Beschreibungen die Grenzen zwischen ihnen festlegen.
Eine Weiterleitungsbeschreibung könnte ein Zugangsproblem, eine Produktfrage und einen gemeldeten Defekt unterscheiden. Formulieren Sie die Bedeutung jeder Option und stellen Sie die weiterzuleitende Nachricht bereit. Die Ausgabe ist eine ausgewählte Kategorie mit einer Verteilung, keine Anweisung, die bereits eine Warteschlange verändert oder ein anderes System kontaktiert hat. Prüfen Sie bei einem mehrdeutigen Fall konkurrierende Wahrscheinlichkeiten, statt die führende Bezeichnung als Beweis für Gewissheit zu interpretieren.
Eine Score-Frage verwendet ein geordnetes Array mit 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 Legende, Wahrscheinlichkeiten je Stufe und Konfidenz. Definieren Sie die Reihenfolge und die Kriterien jeder Stufe, etwa keine unmittelbaren Auswirkungen, ein Problem mit praktikabler Alternative und eine vollständig blockierte Aufgabe.
Ein Erwartungswert mit Nachkommastellen ist für Priorisierung oder Aggregation nützlich. Er unterscheidet sich von der Auswahl der einzelnen wahrscheinlichsten Stufe. Bewahren Sie die Legende bei der Zahl, damit ein Score nicht auf einer sachfremden Skala interpretiert wird. Die Konfidenz für Choice und Score wird separat zwischen 0 und 1 ausgegeben; der relevante Leitfaden definiert sie weder als identisch mit der höchsten Optionswahrscheinlichkeit noch liefert er eine universelle Formel zur Rekonstruktion.
Ein Beleg kann unabhängige Kategorie-, Dringlichkeits- und Bedingungsfragen unterstützen. Eine Dokumentenprüfaufgabe kann fragen, ob ein erforderliches Thema vorhanden ist, seine Kategorie wählen und seine Relevanz anhand beschriebener Stufen bewerten. Verwenden Sie nur Quellmaterial, das im Zustand verfügbar ist, mit Kriterien für die Entscheidung, die der Workflow als Nächstes benötigt. Erfordert eine Aktion ein früheres Ergebnis, machen Sie dieses Ergebnis in den Belegen des nächsten Schritts ausdrücklich, statt anzunehmen, dass die Fragen eine verborgene Sequenz bilden.
Die Antwort gibt den Modellnamen und eine answers-Zuordnung mit den bereitgestellten Fragennamen als Schlüsseln zurück. Choice-Wahrscheinlichkeiten verwenden die Optionsnamen; Score-Wahrscheinlichkeiten verwenden Zeichenfolgenindizes mit einer Legende, die diese Indizes erklärt. Halten Sie Zustandskennung, Fragendefinitionen und typisierte Antworten miteinander verknüpft. Dadurch entsteht ein interpretierbares Klassifikations- oder Bewertungsartefakt statt einer von ihren zugrunde liegenden Fakten losgelösten Zahl.
Inception dokumentiert Mercury Decide über seine eigene Entscheidungsschnittstelle. Sie unterstützt weder die Chat-Completion- noch die Streaming- oder Werkzeugaufrufschnittstellen des Herstellers; Fähigkeiten von Mercurys Reasoning-, Sprach- und Codegenerierungsprofilen sollten daher nicht auf dieses Modell übertragen werden. Der Entscheidungsleitfaden legt die Anzahl der Optionen und Stufen fest, nennt aber keine numerische Zustandstokengrenze oder Höchstzahl von Fragen; fokussieren Sie gemeinsame Belege auf die bewerteten Fragen.
Bewerten Sie Wahrscheinlichkeiten und Kategoriegrenzen anhand repräsentativen gekennzeichneten Materials aus der vorgesehenen Aufgabe. Prüfen Sie Grenzfallantworten anhand des Zustands und bewahren Sie fehlende Informationen als solche, statt sie durch erfundene Fakten zu ersetzen. Ein nützliches Mercury-Decide-Ergebnis liefert eine geschlossene Entscheidung, ihre Wahrscheinlichkeiten und die zum Verständnis nötigen Definitionen; die umgebende Anwendung bestimmt, wie daraus Weiterleitung, Priorisierung oder ein Prüfergebnis wird.
", "aboutText": "Mercury Decide ist Inceptions Modell für strukturierte Entscheidungen anhand bereitgestellter Belege. Es kombiniert einen gemeinsamen Zustand mit benannten Fragen und gibt typisierte Antworten mit Wahrscheinlichkeiten zurück. Das Ergebnis kann eine gewählte Kategorie, eine geschätzte Ja/Nein-Wahrscheinlichkeit oder eine Position auf einer definierten Skala sein. Dieses Profil liefert eine begrenzte Entscheidung, die Software interpretieren kann; seine dokumentierte Schnittstelle erzeugt keine freie Chatantwort.\n\n### Gemeinsamer Zustand und aussagekräftige Fragennamen\n\nDie Anfrage des Anbieters enthält ein Modell, einen Zustand und eine nicht leere Zuordnung von Fragen. Die Fragennamen bleiben in der Antwortzuordnung erhalten. Stellen Sie die zur Beurteilung jeder Frage nötigen Informationen bereit und benennen Sie Fragen nach den Ergebnissen, die der Workflow verwendet, etwa category, priority oder needs_follow_up. Mehrere Fragen bewerten dieselben Belege unabhängig voneinander. Ihre gemeinsame Platzierung in einer Anfrage macht eine spätere Frage nicht von einer früheren Antwort abhängig.\n\nInceptions Beispiel verwendet ein JSON-Objekt für den Zustand. Der Leitfaden erlaubt außerdem Zeichenfolgen, Objekte oder Arrays im Zustand, in Anweisungen und in Kriterienbeschreibungen, wobei Anweisungen optional oder null sein können. Bewahren Sie nützliche Struktur, wenn die Belege bereits aus Feldern bestehen, und halten Sie bei Texteingaben Dokument oder Nachricht identifizierbar. Nehmen Sie für einen Support-Fall die tatsächliche Anfrage und relevante Fakten auf, statt fehlenden Kontext erschließen zu lassen.\n\n### Noul: eine geschätzte positive Antwort\n\nEine noul-Frage repräsentiert eine Ja/Nein-Bedingung. Ihre Ausgabe ist eine Wahrscheinlichkeit von 0 bis 1 dafür, dass die positive Antwort zutrifft. Optionale true- und false-Beschreibungen können festlegen, was auf jeder Seite der Frage zählt. Fragen Sie beispielsweise, ob eine Nachricht ausdrücklich Ersatz verlangt, und unterscheiden Sie dies von einer allgemeinen Beschwerde über den Artikel. Die Wahrscheinlichkeit liefert ein numerisches Urteil; die Anwendung wählt den Schwellenwert und die daraus folgende Workflow-Aktion.\n\nHalten Sie die Bedingung eng genug, damit 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 bei der Fragendefinition, damit spätere Prüfer erkennen können, was die Zahl tatsächlich misst.\n\n### Choice: eine benannte Option auswählen\n\nEine Choice-Frage verwendet eine Zuordnung von 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 und Konfidenz. Definieren Sie unterscheidbare Bedeutungen für Kategorien und nehmen Sie eine Auffangkategorie auf, wenn manche Eingaben außerhalb der konkreten Optionen liegen werden. Kurze Ausgabeschlüssel können Kategorien identifizieren, während ausführlichere Beschreibungen die Grenzen zwischen ihnen festlegen.\n\nEine Weiterleitungsbeschreibung könnte ein Zugangsproblem, eine Produktfrage und einen gemeldeten Defekt unterscheiden. Formulieren Sie die Bedeutung jeder Option und stellen Sie die weiterzuleitende Nachricht bereit. Die Ausgabe ist eine ausgewählte Kategorie mit einer Verteilung, keine Anweisung, die bereits eine Warteschlange verändert oder ein anderes System kontaktiert hat. Prüfen Sie bei einem mehrdeutigen Fall konkurrierende Wahrscheinlichkeiten, statt die führende Bezeichnung als Beweis für Gewissheit zu interpretieren.\n\n### Score: eine erwartete Position auf einer Rubrik\n\nEine Score-Frage verwendet ein geordnetes Array mit 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 Legende, Wahrscheinlichkeiten je Stufe und Konfidenz. Definieren Sie die Reihenfolge und die Kriterien jeder Stufe, etwa keine unmittelbaren Auswirkungen, ein Problem mit praktikabler Alternative und eine vollständig blockierte Aufgabe.\n\nEin Erwartungswert mit Nachkommastellen ist für Priorisierung oder Aggregation nützlich. Er unterscheidet sich von der Auswahl der einzelnen wahrscheinlichsten Stufe. Bewahren Sie die Legende bei der Zahl, damit ein Score nicht auf einer sachfremden Skala interpretiert wird. Die Konfidenz für Choice und Score wird separat zwischen 0 und 1 ausgegeben; der relevante Leitfaden definiert sie weder als identisch mit der höchsten Optionswahrscheinlichkeit noch liefert er eine universelle Formel zur Rekonstruktion.\n\n### Ein nützliches Entscheidungsergebnis vorbereiten\n\nEin Beleg kann unabhängige Kategorie-, Dringlichkeits- und Bedingungsfragen unterstützen. Eine Dokumentenprüfaufgabe kann fragen, ob ein erforderliches Thema vorhanden ist, seine Kategorie wählen und seine Relevanz anhand beschriebener Stufen bewerten. Verwenden Sie nur Quellmaterial, das im Zustand verfügbar ist, mit Kriterien für die Entscheidung, die der Workflow als Nächstes benötigt. Erfordert eine Aktion ein früheres Ergebnis, machen Sie dieses Ergebnis in den Belegen des nächsten Schritts ausdrücklich, statt anzunehmen, dass die Fragen eine verborgene Sequenz bilden.\n\nDie Antwort gibt den Modellnamen und eine answers-Zuordnung mit den bereitgestellten Fragennamen als Schlüsseln zurück. Choice-Wahrscheinlichkeiten verwenden die Optionsnamen; Score-Wahrscheinlichkeiten verwenden Zeichenfolgenindizes mit einer Legende, die diese Indizes erklärt. Halten Sie Zustandskennung, Fragendefinitionen und typisierte Antworten miteinander verknüpft. Dadurch entsteht ein interpretierbares Klassifikations- oder Bewertungsartefakt statt einer von ihren zugrunde liegenden Fakten losgelösten Zahl.\n\n### Schnittstellenumfang und Grenzen\n\nInception dokumentiert Mercury Decide über seine eigene Entscheidungsschnittstelle. Sie unterstützt weder die Chat-Completion- noch die Streaming- oder Werkzeugaufrufschnittstellen des Herstellers; Fähigkeiten von Mercurys Reasoning-, Sprach- und Codegenerierungsprofilen sollten daher nicht auf dieses Modell übertragen werden. Der Entscheidungsleitfaden legt die Anzahl der Optionen und Stufen fest, nennt aber keine numerische Zustandstokengrenze oder Höchstzahl von Fragen; fokussieren Sie gemeinsame Belege auf die bewerteten Fragen.\n\nBewerten Sie Wahrscheinlichkeiten und Kategoriegrenzen anhand repräsentativen gekennzeichneten Materials aus der vorgesehenen Aufgabe. Prüfen Sie Grenzfallantworten anhand des Zustands und bewahren Sie fehlende Informationen als solche, statt sie durch erfundene Fakten zu ersetzen. Ein nützliches Mercury-Decide-Ergebnis liefert eine geschlossene Entscheidung, ihre Wahrscheinlichkeiten und die zum Verständnis nötigen Definitionen; die umgebende Anwendung bestimmt, wie daraus Weiterleitung, Priorisierung oder ein Prüfergebnis wird.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "fd1c23156d6ea2d35be6d0066718f1ef2f893a30591819a8430c1c92ca032a83", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "de-at", "methods": [ { "html": "inception/mercury-decide:freeMercury Decide bewertet gemeinsame Text- oder JSON-Belege anhand benannter Fragen und gibt typisierte Auswahlentscheidungen, Ja/Nein-Wahrscheinlichkeiten oder Rubrik-Scores mit Nachkommastellen zurück. Inception dokumentiert einen eigenen Entscheidungsablauf 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 Inceptions Modell für strukturierte Entscheidungen anhand bereitgestellter Belege. Es kombiniert einen gemeinsamen Zustand mit benannten Fragen und gibt typisierte Antworten mit Wahrscheinlichkeiten zurück. Das Ergebnis kann eine gewählte Kategorie, eine geschätzte Ja/Nein-Wahrscheinlichkeit oder eine Position auf einer definierten Skala sein. Dieses Profil liefert eine begrenzte Entscheidung, die Software interpretieren kann; seine dokumentierte Schnittstelle erzeugt keine freie Chatantwort.
Die Anfrage des Anbieters enthält ein Modell, einen Zustand und eine nicht leere Zuordnung von Fragen. Die Fragennamen bleiben in der Antwortzuordnung erhalten. Stellen Sie die zur Beurteilung jeder Frage nötigen Informationen bereit und benennen Sie Fragen nach den Ergebnissen, die der Workflow verwendet, etwa category, priority oder needs_follow_up. Mehrere Fragen bewerten dieselben Belege unabhängig voneinander. Ihre gemeinsame Platzierung in einer Anfrage macht eine spätere Frage nicht von einer früheren Antwort abhängig.
Inceptions Beispiel verwendet ein JSON-Objekt für den Zustand. Der Leitfaden erlaubt außerdem Zeichenfolgen, Objekte oder Arrays im Zustand, in Anweisungen und in Kriterienbeschreibungen, wobei Anweisungen optional oder null sein können. Bewahren Sie nützliche Struktur, wenn die Belege bereits aus Feldern bestehen, und halten Sie bei Texteingaben Dokument oder Nachricht identifizierbar. Nehmen Sie für einen Support-Fall die tatsächliche Anfrage und relevante Fakten auf, statt fehlenden Kontext erschließen zu lassen.
Eine noul-Frage repräsentiert eine Ja/Nein-Bedingung. Ihre Ausgabe ist eine Wahrscheinlichkeit von 0 bis 1 dafür, dass die positive Antwort zutrifft. Optionale true- und false-Beschreibungen können festlegen, was auf jeder Seite der Frage zählt. Fragen Sie beispielsweise, ob eine Nachricht ausdrücklich Ersatz verlangt, und unterscheiden Sie dies von einer allgemeinen Beschwerde über den Artikel. Die Wahrscheinlichkeit liefert ein numerisches Urteil; die Anwendung wählt den Schwellenwert und die daraus folgende Workflow-Aktion.
Halten Sie die Bedingung eng genug, damit 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 bei der Fragendefinition, damit spätere Prüfer erkennen können, was die Zahl tatsächlich misst.
Eine Choice-Frage verwendet eine Zuordnung von 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 und Konfidenz. Definieren Sie unterscheidbare Bedeutungen für Kategorien und nehmen Sie eine Auffangkategorie auf, wenn manche Eingaben außerhalb der konkreten Optionen liegen werden. Kurze Ausgabeschlüssel können Kategorien identifizieren, während ausführlichere Beschreibungen die Grenzen zwischen ihnen festlegen.
Eine Weiterleitungsbeschreibung könnte ein Zugangsproblem, eine Produktfrage und einen gemeldeten Defekt unterscheiden. Formulieren Sie die Bedeutung jeder Option und stellen Sie die weiterzuleitende Nachricht bereit. Die Ausgabe ist eine ausgewählte Kategorie mit einer Verteilung, keine Anweisung, die bereits eine Warteschlange verändert oder ein anderes System kontaktiert hat. Prüfen Sie bei einem mehrdeutigen Fall konkurrierende Wahrscheinlichkeiten, statt die führende Bezeichnung als Beweis für Gewissheit zu interpretieren.
Eine Score-Frage verwendet ein geordnetes Array mit 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 Legende, Wahrscheinlichkeiten je Stufe und Konfidenz. Definieren Sie die Reihenfolge und die Kriterien jeder Stufe, etwa keine unmittelbaren Auswirkungen, ein Problem mit praktikabler Alternative und eine vollständig blockierte Aufgabe.
Ein Erwartungswert mit Nachkommastellen ist für Priorisierung oder Aggregation nützlich. Er unterscheidet sich von der Auswahl der einzelnen wahrscheinlichsten Stufe. Bewahren Sie die Legende bei der Zahl, damit ein Score nicht auf einer sachfremden Skala interpretiert wird. Die Konfidenz für Choice und Score wird separat zwischen 0 und 1 ausgegeben; der relevante Leitfaden definiert sie weder als identisch mit der höchsten Optionswahrscheinlichkeit noch liefert er eine universelle Formel zur Rekonstruktion.
Ein Beleg kann unabhängige Kategorie-, Dringlichkeits- und Bedingungsfragen unterstützen. Eine Dokumentenprüfaufgabe kann fragen, ob ein erforderliches Thema vorhanden ist, seine Kategorie wählen und seine Relevanz anhand beschriebener Stufen bewerten. Verwenden Sie nur Quellmaterial, das im Zustand verfügbar ist, mit Kriterien für die Entscheidung, die der Workflow als Nächstes benötigt. Erfordert eine Aktion ein früheres Ergebnis, machen Sie dieses Ergebnis in den Belegen des nächsten Schritts ausdrücklich, statt anzunehmen, dass die Fragen eine verborgene Sequenz bilden.
Die Antwort gibt den Modellnamen und eine answers-Zuordnung mit den bereitgestellten Fragennamen als Schlüsseln zurück. Choice-Wahrscheinlichkeiten verwenden die Optionsnamen; Score-Wahrscheinlichkeiten verwenden Zeichenfolgenindizes mit einer Legende, die diese Indizes erklärt. Halten Sie Zustandskennung, Fragendefinitionen und typisierte Antworten miteinander verknüpft. Dadurch entsteht ein interpretierbares Klassifikations- oder Bewertungsartefakt statt einer von ihren zugrunde liegenden Fakten losgelösten Zahl.
Inception dokumentiert Mercury Decide über seine eigene Entscheidungsschnittstelle. Sie unterstützt weder die Chat-Completion- noch die Streaming- oder Werkzeugaufrufschnittstellen des Herstellers; Fähigkeiten von Mercurys Reasoning-, Sprach- und Codegenerierungsprofilen sollten daher nicht auf dieses Modell übertragen werden. Der Entscheidungsleitfaden legt die Anzahl der Optionen und Stufen fest, nennt aber keine numerische Zustandstokengrenze oder Höchstzahl von Fragen; fokussieren Sie gemeinsame Belege auf die bewerteten Fragen.
Bewerten Sie Wahrscheinlichkeiten und Kategoriegrenzen anhand repräsentativen gekennzeichneten Materials aus der vorgesehenen Aufgabe. Prüfen Sie Grenzfallantworten anhand des Zustands und bewahren Sie fehlende Informationen als solche, statt sie durch erfundene Fakten zu ersetzen. Ein nützliches Mercury-Decide-Ergebnis liefert eine geschlossene Entscheidung, ihre Wahrscheinlichkeiten und die zum Verständnis nötigen Definitionen; die umgebende Anwendung bestimmt, wie daraus Weiterleitung, 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. criteria bei choice ist ein Objekt; score ist ein Array mit minItems1. | 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 exakte 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 Tokens Ausgabe · Ausgabetoken $0 / 1K Tokens Eingabe · Cache lesen — / 1K Tokens Eingabe · In Cache schreiben — / 1K Tokens Eingabe · In Cache schreiben, 1 Stunde — / 1K Tokens |
| KonfigurationAnfragelängenstufe 1 | Tarifstaffel— | Kontexttoken, mehr als0 | Kontexttoken, bis einschließlichKeine Obergrenze | Gebühr Eingabe · Eingabetoken $0 / 1K Tokens Ausgabe · Ausgabetoken $0 / 1K Tokens Eingabe · Cache lesen — / 1K Tokens Eingabe · In Cache schreiben — / 1K Tokens Eingabe · In Cache schreiben, 1 Stunde — / 1K Tokens |
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 gelieferte Antwort mit Frage-ID bleibt mit ihrem genauen Typ, dem noul/choice/score-Wert, der Konfidenz, den Wahrscheinlichkeiten und der Legende erhalten. Das gesamte ursprüngliche JSON wird gespeichert und erst nach der Abrechnung zurückgegeben.
Bewahren Sie den ursprünglichen Vorgang und 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.