Upstage Solar Decide ist ein strukturiertes Entscheidungsmodell auf Basis von Solar Mini 4. Es liest einen bereitgestellten Zustand und typisierte Fragen und gibt für jede Frage eine Entscheidung mit kalibrierten Wahrscheinlichkeitsinformationen zurück. Der Hersteller beschreibt einen Entscheidungsprozess in einem einzigen Vorwärtsdurchlauf, der keine Prosa erzeugt. Zu den vorgesehenen Anwendungen gehören Weiterleitung, Klassifikation und Richtlinienprüfungen; das Koreanischverständnis des Modells wird als Bestandteil seiner Solar-Mini-4-Grundlage hervorgehoben.
Bereiten Sie den Zustand als Zeichenfolge oder strukturiertes JSON vor, das die zu bewertenden Fakten beschreibt. Die Herstellerschnittstelle serialisiert JSON-Werte in den Prompt. Ein Fragenschema definiert separat, was entschieden werden soll, welche Optionen zulässig sind und wie eine geordnete Bewertung zu interpretieren ist. Verwenden Sie stabile Namen für die Fragen: Ihre Antworten werden unter denselben Namen zurückgegeben, sodass das Ergebnis leicht der ursprünglichen Workflow-Bedingung zugeordnet werden kann. Halten Sie den faktischen Zustand von den Anweisungen und Kriterien getrennt, die die Entscheidung definieren.
Die drei Fragetypen haben unterschiedliche Ausgaben. Eine choice-Frage gibt die ausgewählte Option, Wahrscheinlichkeiten für die benannten Alternativen und einen Konfidenzwert zurück. Eine noul-Frage gibt für eine Ja/Nein-Bedingung die Wahrscheinlichkeit von wahr zurück. Eine score-Frage gibt einen wahrscheinlichkeitsgewichteten Score, eine indizierte Legende, Wahrscheinlichkeiten und Konfidenz zurück. Ein geordneter Score kann Nachkommastellen enthalten, weil er die Verteilung über die Kriterien widerspiegelt. Bewahren Sie diese Felder, statt jedes Ergebnis auf eine bloße Bezeichnung zu reduzieren oder Konfidenz als erklärenden Satz zu behandeln.
Stellen Sie für die Support-Weiterleitung die tatsächliche Nachricht und die relevante Vorgeschichte bereit und stellen Sie dann separate Fragen zu Absicht, Dringlichkeit und einer definierten Bedingung, etwa ob die Nachricht Unzufriedenheit ausdrückt. Beschreiben Sie Kategorien anhand ihrer Bedeutung und geben Sie der Dringlichkeitsskala eine bewusst gewählte Reihenfolge. Ein Beispielschema kann eine Anfrage zum Lieferstatus, ein Kontozugangsproblem und ein sachfremdes Anliegen unterscheiden, während die Dringlichkeitskriterien von keinem unmittelbaren Handlungsbedarf bis zur sofortigen Prüfung reichen. Das beobachtbare Ergebnis ist eine typisierte Bewertung dieser Optionen, keine formulierte Antwort an den Kunden.
Nehmen Sie für Richtlinienprüfungen die relevante Regel und die Fakten des Datensatzes gemeinsam in den Zustand auf. Definieren Sie jede Bedingung eng genug, damit ihre Antwort überprüft werden kann. Ein Dokumenten-Workflow könnte fragen, ob erforderliche Informationen vorhanden sind, welche Prüfungskategorie zutrifft und wie stark der Datensatz einen geordneten Vollständigkeitsstandard erfüllt. Ein Score oder eine Wahrscheinlichkeit verifiziert die Fakten im Datensatz nicht unabhängig. Fehlen entscheidende Informationen, benötigt die Anwendung einen bewusst festgelegten Umgang mit dieser Unsicherheit, statt eine ausgewählte Option als abschließenden Beweis zu interpretieren.
Der Hersteller gibt für Solar Decide ein Kontextfenster von 512K Tokens an. Bereiten Sie große Dokumente als den Text oder strukturierten Zustand vor, den die Entscheidung benötigt; ein großer Kontext bedeutet nicht, dass eine beliebige Datei automatisch geparst wird. Bewahren Sie Quellgrenzen und die für die Kriterien relevanten Passagen. Verwenden Sie fokussierte Fragen, statt eine offene Zusammenfassung des Dokuments zu erwarten. Die Ausgabe des Modells bleibt durch Fragetypen und Optionen begrenzt, unabhängig davon, wie viel Material der Zustand enthält.
Eine choice-Frage akzeptiert in der dokumentierten Herstellerschnittstelle zwei bis 26 Optionen. Der Hersteller erklärt, dass dieser Weg Entscheidungen aus den Ein-Token-Bezeichnungen A bis Z ausliest; mehr als 26 Kandidaten müssen deshalb eingegrenzt oder auf mehrere Fragen verteilt werden. Diese Grenze gilt für choice-Optionen; sie ist weder eine allgemeine Grenze für die Dokumentlänge noch eine aus einer anderen Entscheidungsmodellfamilie übernommene Grenze. Definieren Sie Kandidatenbeschreibungen so, dass ihre Bedeutungen unterscheidbar sind, und verwenden Sie eine hierarchische Entscheidung nur dann, wenn diese Hierarchie dem tatsächlichen Workflow entspricht.
Bewahren Sie bei koreanischsprachigen Datensätzen die Bedeutung der Quelle, Namen und Kennungen und beschreiben Sie die Entscheidungskriterien klar. Das typisierte Ergebnis kann stabile Anwendungsbezeichnungen verwenden und zugleich natürlichsprachliche Belege bewerten. Enthält ein Datensatz mehrere Sprachen oder Fachterminologie, erhalten Sie die relevanten Definitionen im Zustand. Eine flüssige Interpretation eines Begriffs genügt nicht als Nachweis, dass die Klassifikationskriterien zur Geschäftsregel passen; prüfen Sie daher repräsentative mehrdeutige Fälle ebenso wie eindeutige.
Verwenden Sie die zurückgegebenen Wahrscheinlichkeiten und die Konfidenz entsprechend der Entscheidungsrichtlinie des Workflows. Bewahren Sie die Verteilung und die geordnete Legende, wenn eine Bewertung zwischen Kategorien liegt. Legen Sie den Umgang mit unsicheren Ergebnissen anhand geprüfter Aufgabenbeispiele fest, statt einen universellen Wahrscheinlichkeitsschwellenwert zu erfinden. Die Anwendung führt jede daraus folgende Weiterleitung, Eskalation oder Prüfung aus und protokolliert deren Ergebnis. Solar Decide liefert die begrenzte Modellbewertung, anhand derer diese Aktion erwogen wird; die Auswahl einer Route belegt nicht, dass eine spätere Aktion ausgeführt wurde.
Das nützliche abschließende Artefakt ist das answers-Objekt zusammen mit dem Zustand und den Fragendefinitionen, die es erzeugt haben. Diese Datensätze ermöglichen es, eine überraschende Klassifikation zu untersuchen, fehlende Belege von mehrdeutigen Kriterien zu unterscheiden und die Bewertung mit einem geprüften Fall zu vergleichen. Wenn Nutzer eine schriftliche Erklärung oder eine Gesprächsantwort benötigen, können die Entscheidung und das Quellmaterial einem separaten Schreibschritt zugeführt werden. Die konkrete Rolle von Solar Decide besteht darin, aus bereitgestelltem Text typisierte, durch Wahrscheinlichkeiten gestützte Entscheidungen zu erzeugen, statt diese Erklärung selbst zu verfassen.
", "aboutText": "Upstage Solar Decide ist ein strukturiertes Entscheidungsmodell auf Basis von Solar Mini 4. Es liest einen bereitgestellten Zustand und typisierte Fragen und gibt für jede Frage eine Entscheidung mit kalibrierten Wahrscheinlichkeitsinformationen zurück. Der Hersteller beschreibt einen Entscheidungsprozess in einem einzigen Vorwärtsdurchlauf, der keine Prosa erzeugt. Zu den vorgesehenen Anwendungen gehören Weiterleitung, Klassifikation und Richtlinienprüfungen; das Koreanischverständnis des Modells wird als Bestandteil seiner Solar-Mini-4-Grundlage hervorgehoben.\n\nBereiten Sie den Zustand als Zeichenfolge oder strukturiertes JSON vor, das die zu bewertenden Fakten beschreibt. Die Herstellerschnittstelle serialisiert JSON-Werte in den Prompt. Ein Fragenschema definiert separat, was entschieden werden soll, welche Optionen zulässig sind und wie eine geordnete Bewertung zu interpretieren ist. Verwenden Sie stabile Namen für die Fragen: Ihre Antworten werden unter denselben Namen zurückgegeben, sodass das Ergebnis leicht der ursprünglichen Workflow-Bedingung zugeordnet werden kann. Halten Sie den faktischen Zustand von den Anweisungen und Kriterien getrennt, die die Entscheidung definieren.\n\nDie drei Fragetypen haben unterschiedliche Ausgaben. Eine choice-Frage gibt die ausgewählte Option, Wahrscheinlichkeiten für die benannten Alternativen und einen Konfidenzwert zurück. Eine noul-Frage gibt für eine Ja/Nein-Bedingung die Wahrscheinlichkeit von wahr zurück. Eine score-Frage gibt einen wahrscheinlichkeitsgewichteten Score, eine indizierte Legende, Wahrscheinlichkeiten und Konfidenz zurück. Ein geordneter Score kann Nachkommastellen enthalten, weil er die Verteilung über die Kriterien widerspiegelt. Bewahren Sie diese Felder, statt jedes Ergebnis auf eine bloße Bezeichnung zu reduzieren oder Konfidenz als erklärenden Satz zu behandeln.\n\nStellen Sie für die Support-Weiterleitung die tatsächliche Nachricht und die relevante Vorgeschichte bereit und stellen Sie dann separate Fragen zu Absicht, Dringlichkeit und einer definierten Bedingung, etwa ob die Nachricht Unzufriedenheit ausdrückt. Beschreiben Sie Kategorien anhand ihrer Bedeutung und geben Sie der Dringlichkeitsskala eine bewusst gewählte Reihenfolge. Ein Beispielschema kann eine Anfrage zum Lieferstatus, ein Kontozugangsproblem und ein sachfremdes Anliegen unterscheiden, während die Dringlichkeitskriterien von keinem unmittelbaren Handlungsbedarf bis zur sofortigen Prüfung reichen. Das beobachtbare Ergebnis ist eine typisierte Bewertung dieser Optionen, keine formulierte Antwort an den Kunden.\n\nNehmen Sie für Richtlinienprüfungen die relevante Regel und die Fakten des Datensatzes gemeinsam in den Zustand auf. Definieren Sie jede Bedingung eng genug, damit ihre Antwort überprüft werden kann. Ein Dokumenten-Workflow könnte fragen, ob erforderliche Informationen vorhanden sind, welche Prüfungskategorie zutrifft und wie stark der Datensatz einen geordneten Vollständigkeitsstandard erfüllt. Ein Score oder eine Wahrscheinlichkeit verifiziert die Fakten im Datensatz nicht unabhängig. Fehlen entscheidende Informationen, benötigt die Anwendung einen bewusst festgelegten Umgang mit dieser Unsicherheit, statt eine ausgewählte Option als abschließenden Beweis zu interpretieren.\n\nDer Hersteller gibt für Solar Decide ein Kontextfenster von 512K Tokens an. Bereiten Sie große Dokumente als den Text oder strukturierten Zustand vor, den die Entscheidung benötigt; ein großer Kontext bedeutet nicht, dass eine beliebige Datei automatisch geparst wird. Bewahren Sie Quellgrenzen und die für die Kriterien relevanten Passagen. Verwenden Sie fokussierte Fragen, statt eine offene Zusammenfassung des Dokuments zu erwarten. Die Ausgabe des Modells bleibt durch Fragetypen und Optionen begrenzt, unabhängig davon, wie viel Material der Zustand enthält.\n\nEine choice-Frage akzeptiert in der dokumentierten Herstellerschnittstelle zwei bis 26 Optionen. Der Hersteller erklärt, dass dieser Weg Entscheidungen aus den Ein-Token-Bezeichnungen A bis Z ausliest; mehr als 26 Kandidaten müssen deshalb eingegrenzt oder auf mehrere Fragen verteilt werden. Diese Grenze gilt für choice-Optionen; sie ist weder eine allgemeine Grenze für die Dokumentlänge noch eine aus einer anderen Entscheidungsmodellfamilie übernommene Grenze. Definieren Sie Kandidatenbeschreibungen so, dass ihre Bedeutungen unterscheidbar sind, und verwenden Sie eine hierarchische Entscheidung nur dann, wenn diese Hierarchie dem tatsächlichen Workflow entspricht.\n\nBewahren Sie bei koreanischsprachigen Datensätzen die Bedeutung der Quelle, Namen und Kennungen und beschreiben Sie die Entscheidungskriterien klar. Das typisierte Ergebnis kann stabile Anwendungsbezeichnungen verwenden und zugleich natürlichsprachliche Belege bewerten. Enthält ein Datensatz mehrere Sprachen oder Fachterminologie, erhalten Sie die relevanten Definitionen im Zustand. Eine flüssige Interpretation eines Begriffs genügt nicht als Nachweis, dass die Klassifikationskriterien zur Geschäftsregel passen; prüfen Sie daher repräsentative mehrdeutige Fälle ebenso wie eindeutige.\n\nVerwenden Sie die zurückgegebenen Wahrscheinlichkeiten und die Konfidenz entsprechend der Entscheidungsrichtlinie des Workflows. Bewahren Sie die Verteilung und die geordnete Legende, wenn eine Bewertung zwischen Kategorien liegt. Legen Sie den Umgang mit unsicheren Ergebnissen anhand geprüfter Aufgabenbeispiele fest, statt einen universellen Wahrscheinlichkeitsschwellenwert zu erfinden. Die Anwendung führt jede daraus folgende Weiterleitung, Eskalation oder Prüfung aus und protokolliert deren Ergebnis. Solar Decide liefert die begrenzte Modellbewertung, anhand derer diese Aktion erwogen wird; die Auswahl einer Route belegt nicht, dass eine spätere Aktion ausgeführt wurde.\n\nDas nützliche abschließende Artefakt ist das answers-Objekt zusammen mit dem Zustand und den Fragendefinitionen, die es erzeugt haben. Diese Datensätze ermöglichen es, eine überraschende Klassifikation zu untersuchen, fehlende Belege von mehrdeutigen Kriterien zu unterscheiden und die Bewertung mit einem geprüften Fall zu vergleichen. Wenn Nutzer eine schriftliche Erklärung oder eine Gesprächsantwort benötigen, können die Entscheidung und das Quellmaterial einem separaten Schreibschritt zugeführt werden. Die konkrete Rolle von Solar Decide besteht darin, aus bereitgestelltem Text typisierte, durch Wahrscheinlichkeiten gestützte Entscheidungen zu erzeugen, statt diese Erklärung selbst zu verfassen.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "72c59ccce0f0fb492b9b36c2b8313ab34939b4bebc3f5cafa622812285646aee", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "de", "methods": [ { "html": "upstage/solar-decideUpstage Solar Decide ist ein Text-Entscheidungsmodell auf Basis von Solar Mini 4. Es bewertet einen bereitgestellten Zustand und typisierte Fragen und gibt benannte Auswahlentscheidungen, Wahr-Wahrscheinlichkeiten oder gewichtete Scores mit Wahrscheinlichkeitsinformationen zurück. Seine begrenzte Ausgabe unterstützt Klassifikation, Weiterleitung und Richtlinienprüfungen statt generierter Prosa.
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.
Upstage Solar Decide ist ein strukturiertes Entscheidungsmodell auf Basis von Solar Mini 4. Es liest einen bereitgestellten Zustand und typisierte Fragen und gibt für jede Frage eine Entscheidung mit kalibrierten Wahrscheinlichkeitsinformationen zurück. Der Hersteller beschreibt einen Entscheidungsprozess in einem einzigen Vorwärtsdurchlauf, der keine Prosa erzeugt. Zu den vorgesehenen Anwendungen gehören Weiterleitung, Klassifikation und Richtlinienprüfungen; das Koreanischverständnis des Modells wird als Bestandteil seiner Solar-Mini-4-Grundlage hervorgehoben.
Bereiten Sie den Zustand als Zeichenfolge oder strukturiertes JSON vor, das die zu bewertenden Fakten beschreibt. Die Herstellerschnittstelle serialisiert JSON-Werte in den Prompt. Ein Fragenschema definiert separat, was entschieden werden soll, welche Optionen zulässig sind und wie eine geordnete Bewertung zu interpretieren ist. Verwenden Sie stabile Namen für die Fragen: Ihre Antworten werden unter denselben Namen zurückgegeben, sodass das Ergebnis leicht der ursprünglichen Workflow-Bedingung zugeordnet werden kann. Halten Sie den faktischen Zustand von den Anweisungen und Kriterien getrennt, die die Entscheidung definieren.
Die drei Fragetypen haben unterschiedliche Ausgaben. Eine choice-Frage gibt die ausgewählte Option, Wahrscheinlichkeiten für die benannten Alternativen und einen Konfidenzwert zurück. Eine noul-Frage gibt für eine Ja/Nein-Bedingung die Wahrscheinlichkeit von wahr zurück. Eine score-Frage gibt einen wahrscheinlichkeitsgewichteten Score, eine indizierte Legende, Wahrscheinlichkeiten und Konfidenz zurück. Ein geordneter Score kann Nachkommastellen enthalten, weil er die Verteilung über die Kriterien widerspiegelt. Bewahren Sie diese Felder, statt jedes Ergebnis auf eine bloße Bezeichnung zu reduzieren oder Konfidenz als erklärenden Satz zu behandeln.
Stellen Sie für die Support-Weiterleitung die tatsächliche Nachricht und die relevante Vorgeschichte bereit und stellen Sie dann separate Fragen zu Absicht, Dringlichkeit und einer definierten Bedingung, etwa ob die Nachricht Unzufriedenheit ausdrückt. Beschreiben Sie Kategorien anhand ihrer Bedeutung und geben Sie der Dringlichkeitsskala eine bewusst gewählte Reihenfolge. Ein Beispielschema kann eine Anfrage zum Lieferstatus, ein Kontozugangsproblem und ein sachfremdes Anliegen unterscheiden, während die Dringlichkeitskriterien von keinem unmittelbaren Handlungsbedarf bis zur sofortigen Prüfung reichen. Das beobachtbare Ergebnis ist eine typisierte Bewertung dieser Optionen, keine formulierte Antwort an den Kunden.
Nehmen Sie für Richtlinienprüfungen die relevante Regel und die Fakten des Datensatzes gemeinsam in den Zustand auf. Definieren Sie jede Bedingung eng genug, damit ihre Antwort überprüft werden kann. Ein Dokumenten-Workflow könnte fragen, ob erforderliche Informationen vorhanden sind, welche Prüfungskategorie zutrifft und wie stark der Datensatz einen geordneten Vollständigkeitsstandard erfüllt. Ein Score oder eine Wahrscheinlichkeit verifiziert die Fakten im Datensatz nicht unabhängig. Fehlen entscheidende Informationen, benötigt die Anwendung einen bewusst festgelegten Umgang mit dieser Unsicherheit, statt eine ausgewählte Option als abschließenden Beweis zu interpretieren.
Der Hersteller gibt für Solar Decide ein Kontextfenster von 512K Tokens an. Bereiten Sie große Dokumente als den Text oder strukturierten Zustand vor, den die Entscheidung benötigt; ein großer Kontext bedeutet nicht, dass eine beliebige Datei automatisch geparst wird. Bewahren Sie Quellgrenzen und die für die Kriterien relevanten Passagen. Verwenden Sie fokussierte Fragen, statt eine offene Zusammenfassung des Dokuments zu erwarten. Die Ausgabe des Modells bleibt durch Fragetypen und Optionen begrenzt, unabhängig davon, wie viel Material der Zustand enthält.
Eine choice-Frage akzeptiert in der dokumentierten Herstellerschnittstelle zwei bis 26 Optionen. Der Hersteller erklärt, dass dieser Weg Entscheidungen aus den Ein-Token-Bezeichnungen A bis Z ausliest; mehr als 26 Kandidaten müssen deshalb eingegrenzt oder auf mehrere Fragen verteilt werden. Diese Grenze gilt für choice-Optionen; sie ist weder eine allgemeine Grenze für die Dokumentlänge noch eine aus einer anderen Entscheidungsmodellfamilie übernommene Grenze. Definieren Sie Kandidatenbeschreibungen so, dass ihre Bedeutungen unterscheidbar sind, und verwenden Sie eine hierarchische Entscheidung nur dann, wenn diese Hierarchie dem tatsächlichen Workflow entspricht.
Bewahren Sie bei koreanischsprachigen Datensätzen die Bedeutung der Quelle, Namen und Kennungen und beschreiben Sie die Entscheidungskriterien klar. Das typisierte Ergebnis kann stabile Anwendungsbezeichnungen verwenden und zugleich natürlichsprachliche Belege bewerten. Enthält ein Datensatz mehrere Sprachen oder Fachterminologie, erhalten Sie die relevanten Definitionen im Zustand. Eine flüssige Interpretation eines Begriffs genügt nicht als Nachweis, dass die Klassifikationskriterien zur Geschäftsregel passen; prüfen Sie daher repräsentative mehrdeutige Fälle ebenso wie eindeutige.
Verwenden Sie die zurückgegebenen Wahrscheinlichkeiten und die Konfidenz entsprechend der Entscheidungsrichtlinie des Workflows. Bewahren Sie die Verteilung und die geordnete Legende, wenn eine Bewertung zwischen Kategorien liegt. Legen Sie den Umgang mit unsicheren Ergebnissen anhand geprüfter Aufgabenbeispiele fest, statt einen universellen Wahrscheinlichkeitsschwellenwert zu erfinden. Die Anwendung führt jede daraus folgende Weiterleitung, Eskalation oder Prüfung aus und protokolliert deren Ergebnis. Solar Decide liefert die begrenzte Modellbewertung, anhand derer diese Aktion erwogen wird; die Auswahl einer Route belegt nicht, dass eine spätere Aktion ausgeführt wurde.
Das nützliche abschließende Artefakt ist das answers-Objekt zusammen mit dem Zustand und den Fragendefinitionen, die es erzeugt haben. Diese Datensätze ermöglichen es, eine überraschende Klassifikation zu untersuchen, fehlende Belege von mehrdeutigen Kriterien zu unterscheiden und die Bewertung mit einem geprüften Fall zu vergleichen. Wenn Nutzer eine schriftliche Erklärung oder eine Gesprächsantwort benötigen, können die Entscheidung und das Quellmaterial einem separaten Schreibschritt zugeführt werden. Die konkrete Rolle von Solar Decide besteht darin, aus bereitgestelltem Text typisierte, durch Wahrscheinlichkeiten gestützte Entscheidungen zu erzeugen, statt diese Erklärung selbst zu verfassen.
POST /v1/systemonetextdecisions| Feld | Typ | Anforderung | Werte und Limits | Standard |
|---|---|---|---|---|
Feldmodel | Typstring | AnforderungErforderlich | Werte und Limits upstage/solar-decide | 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.0002 / 1K Token Ausgabe · Ausgabetoken $0 / 1K Token Eingabe · Cache-Lesen $0.0002 / 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.0002 / 1K Token Ausgabe · Ausgabetoken $0 / 1K Token Eingabe · Cache-Lesen $0.0002 / 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": "upstage/solar-decide",\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']='upstage/solar-decide'\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 upstage/solar-decide
Verwenden Sie die oben angezeigten Methodenpfade.