Drex 1.5 ist das Text-Entscheidungsmodell von Nace.AI. Es bewertet bereitgestellte Fakten anhand geschlossener Fragen und gibt numerische, typisierte Antworten statt einer offenen schriftlichen Antwort zurück. Eine Anfrage kombiniert einen Zustand mit benannten Fragen, und das Ergebnis kennzeichnet jede Antwort mit demselben Fragenamen. So erhält ein Workflow eine konkrete Kategorie, Wahrscheinlichkeit oder Position im Bewertungsraster zur Weiterverarbeitung, während die auf dieses Ergebnis folgende Aktion bei der Anwendung bleibt.
Der Zustand ist die Information, auf die sich jede Frage bezieht. Drex akzeptiert einen JSON-String, ein Objekt, ein Array, eine Zahl, einen booleschen Wert oder null, wobei das Feld state erforderlich ist. Liefern Sie aussagekräftige Belege, auch wenn null die Validierung des Herstellers besteht. Ein String eignet sich für eine Nachricht, ein Dokument oder ein Transkript; ein Objekt eignet sich für Fakten, die bereits in Felder gegliedert sind. Behalten Sie die Informationen, die die Entscheidung beeinflussen, und lassen Sie bei umfangreichem Material nicht zugehörige Felder weg. Behalten Sie ein stabiles Eingabeformat bei, wenn Sie Wahrscheinlichkeitsschwellen interpretieren, denn eine geänderte Darstellung kann die Antwort ändern.
Drex 1.5 liest ausschließlich Text. Die dokumentierte Schnittstelle weist Bilder, Audio, Video und PDF-Inhalte sowohl im Zustand als auch in den Fragen zurück, einschließlich kodierter Medien und Medieninhaltsobjekte. Erstellen Sie eine Bildbeschreibung, erkannten Dokumenttext oder ein Transkript, bevor Sie dieses Material als Beleg verwenden. Eine Textadresse ist kein abgerufenes Dokument oder Bild: Das Modell kann sie nicht öffnen. Bei einer Support-Anfrage ist der nützliche Zustand die tatsächliche Nachricht samt relevantem Kontext, nicht ein Verweis auf Material, das das Modell nicht erhalten hat.
Eine Frage vom Typ noul fragt, ob eine Bedingung zutrifft, und gibt eine Zahl von 0 bis 1 zurück, die die geschätzte Wahrscheinlichkeit für Ja darstellt. Definieren Sie die Frage über nicht leere Anweisungen oder mindestens ein nicht leeres Wahr/Falsch-Kriterium. Fragen Sie beispielsweise, ob eine Nachricht eine defekte Funktion meldet, und legen Sie fest, ob langsames Verhalten als defekt gilt. Drex gibt keinen eingebauten Ja/Nein-Schwellenwert vor; der nachgelagerte Workflow entscheidet, wie die Wahrscheinlichkeit zu interpretieren ist.
Eine Frage vom Typ choice wählt ein bereitgestelltes Label aus einer ungeordneten Menge und gibt für jedes Label eine Wahrscheinlichkeit zurück. Die Kriterien sind ein Objekt, dessen Schlüssel die zurückgegebenen Labels sind, wobei jede Beschreibung ein String oder null ist. Verwenden Sie kurze, stabile Schlüssel und beschreiben Sie die Kategoriegrenzen klar. Eine beispielhafte Routing-Aufgabe kann zwischen einem Zugriffsproblem, einem Produktfehler und einer allgemeinen Frage unterscheiden, ergänzt um eine Kategorie „Sonstiges“ für Nachrichten, die nicht passen. Das gewählte Label ist für das Routing nützlich; die Verteilung hilft, Fälle zu erkennen, in denen sich zwei Optionen nur schwer trennen lassen.
Eine Frage vom Typ score verwendet ein geordnetes Array von Stufenbezeichnungen. Die Indizes beginnen bei 0, und der zurückgegebene Score ist die Summe aus jedem Stufenindex multipliziert mit seiner Wahrscheinlichkeit. Er kann daher zwischen benannten Stufen liegen. Legen Sie bei einer Schweregradskala fest, was ein kosmetisches Problem, ein Problem mit Workaround und eine vollständig blockierte Aufgabe voneinander trennt. Das Ergebnis enthält neben dem erwarteten Score auch die Legende der Stufen und die Wahrscheinlichkeiten. Behalten Sie den Score mit Nachkommastellen für Mittelwerte oder Trends; die Auswahl der wahrscheinlichsten Stufe und das Runden des erwarteten Scores beantworten unterschiedliche Fragen.
Der Hersteller erlaubt eine bis 512 Fragen zum selben Zustand. Geben Sie jeder einen nicht leeren, aussagekräftigen Bezeichner wie category oder severity, damit die zugehörige Antwort verständlich ist, ohne eine nummerierte Frage nachschlagen zu müssen. Trennen Sie unabhängige Anliegen in eigene Fragen, statt mehrere Anforderungen in einem unklaren Kriterium zu bündeln. Eine einzige Nachricht kann eine Kategorieauswahl, einen Schweregrad-Score und eine Bedingungsprüfung stützen, die jeweils ihre eigene Bedeutung behalten.
Antworten vom Typ choice und score enthalten die Konfidenz getrennt von ihren Wahrscheinlichkeitsverteilungen. Der Hersteller unterscheidet ausdrücklich zwischen Konfidenz und der höchsten Optionswahrscheinlichkeit; berechnen Sie das eine nicht aus dem anderen. Behalten Sie bei einer Ja/Nein-Entscheidung die rohe Wahrscheinlichkeit zusammen mit dem gewählten Ergebnis. Prüfen Sie bei einer unsicheren Auswahl die konkurrierenden Wahrscheinlichkeiten, statt das gewinnende Label allein als Beleg für Sicherheit zu werten. Legen Sie Prüfschwellen anhand der Folgen eines falsch positiven oder falsch negativen Ergebnisses fest und bewerten Sie sie anhand repräsentativer gelabelter Fälle.
Drex 1.5 dokumentiert ein Budget von 131.072 Tokens für den Zustand und von 139.264 Tokens pro Zeile. Das Zeilenbudget betrifft den Zustand plus die längste einzelne Frage einschließlich ihrer Anweisungen und Optionen; es ist nicht die Summe aller Fragen der Anfrage. Serialisierter Zustand und Fragen müssen zusammen außerdem in 1.048.576 UTF-8-Bytes passen. Eine Anfrage kann die Byte-Grenze einhalten und dennoch eine Token-Grenze überschreiten. Die ältere Edition 1.0 nennt gesondert 32.768 Tokens sowohl für den Zustand als auch für die Zeile; ihre Grenzen sind daher nicht auf 1.5 zu übertragen.
Nace dokumentiert drex-v1.5 als versionierten Bezeichner des Herstellers, während drex-latest ein beweglicher Alias ist. Halten Sie die vorgesehene Edition explizit fest, wenn ein Workflow von ihren Grenzen abhängt. Eine fehlerhafte Frage, ein fehlender Zustand oder eine zu große Eingabe ist ein Validierungsproblem, das eine korrigierte Eingabe erfordert, keine geänderte Kategorie oder geratene Antwort. Bereiten Sie die Kriterien anhand beobachtbarer Belege vor und bewahren Sie das typisierte Ergebnis, die ursprünglichen Fakten und die Fragedefinition gemeinsam auf. So wird die Entscheidung für Routing, Priorisierung oder Prüfung nutzbar, ohne eine Wahrscheinlichkeit mit einem garantierten Urteil zu verwechseln.
", "aboutText": "Drex 1.5 ist das Text-Entscheidungsmodell von Nace.AI. Es bewertet bereitgestellte Fakten anhand geschlossener Fragen und gibt numerische, typisierte Antworten statt einer offenen schriftlichen Antwort zurück. Eine Anfrage kombiniert einen Zustand mit benannten Fragen, und das Ergebnis kennzeichnet jede Antwort mit demselben Fragenamen. So erhält ein Workflow eine konkrete Kategorie, Wahrscheinlichkeit oder Position im Bewertungsraster zur Weiterverarbeitung, während die auf dieses Ergebnis folgende Aktion bei der Anwendung bleibt.\n\n### Den Zustand vorbereiten\n\nDer Zustand ist die Information, auf die sich jede Frage bezieht. Drex akzeptiert einen JSON-String, ein Objekt, ein Array, eine Zahl, einen booleschen Wert oder null, wobei das Feld state erforderlich ist. Liefern Sie aussagekräftige Belege, auch wenn null die Validierung des Herstellers besteht. Ein String eignet sich für eine Nachricht, ein Dokument oder ein Transkript; ein Objekt eignet sich für Fakten, die bereits in Felder gegliedert sind. Behalten Sie die Informationen, die die Entscheidung beeinflussen, und lassen Sie bei umfangreichem Material nicht zugehörige Felder weg. Behalten Sie ein stabiles Eingabeformat bei, wenn Sie Wahrscheinlichkeitsschwellen interpretieren, denn eine geänderte Darstellung kann die Antwort ändern.\n\nDrex 1.5 liest ausschließlich Text. Die dokumentierte Schnittstelle weist Bilder, Audio, Video und PDF-Inhalte sowohl im Zustand als auch in den Fragen zurück, einschließlich kodierter Medien und Medieninhaltsobjekte. Erstellen Sie eine Bildbeschreibung, erkannten Dokumenttext oder ein Transkript, bevor Sie dieses Material als Beleg verwenden. Eine Textadresse ist kein abgerufenes Dokument oder Bild: Das Modell kann sie nicht öffnen. Bei einer Support-Anfrage ist der nützliche Zustand die tatsächliche Nachricht samt relevantem Kontext, nicht ein Verweis auf Material, das das Modell nicht erhalten hat.\n\n### Ja/Nein-Wahrscheinlichkeit, Auswahl oder Bewertung\n\nEine Frage vom Typ noul fragt, ob eine Bedingung zutrifft, und gibt eine Zahl von 0 bis 1 zurück, die die geschätzte Wahrscheinlichkeit für Ja darstellt. Definieren Sie die Frage über nicht leere Anweisungen oder mindestens ein nicht leeres Wahr/Falsch-Kriterium. Fragen Sie beispielsweise, ob eine Nachricht eine defekte Funktion meldet, und legen Sie fest, ob langsames Verhalten als defekt gilt. Drex gibt keinen eingebauten Ja/Nein-Schwellenwert vor; der nachgelagerte Workflow entscheidet, wie die Wahrscheinlichkeit zu interpretieren ist.\n\nEine Frage vom Typ choice wählt ein bereitgestelltes Label aus einer ungeordneten Menge und gibt für jedes Label eine Wahrscheinlichkeit zurück. Die Kriterien sind ein Objekt, dessen Schlüssel die zurückgegebenen Labels sind, wobei jede Beschreibung ein String oder null ist. Verwenden Sie kurze, stabile Schlüssel und beschreiben Sie die Kategoriegrenzen klar. Eine beispielhafte Routing-Aufgabe kann zwischen einem Zugriffsproblem, einem Produktfehler und einer allgemeinen Frage unterscheiden, ergänzt um eine Kategorie „Sonstiges“ für Nachrichten, die nicht passen. Das gewählte Label ist für das Routing nützlich; die Verteilung hilft, Fälle zu erkennen, in denen sich zwei Optionen nur schwer trennen lassen.\n\nEine Frage vom Typ score verwendet ein geordnetes Array von Stufenbezeichnungen. Die Indizes beginnen bei 0, und der zurückgegebene Score ist die Summe aus jedem Stufenindex multipliziert mit seiner Wahrscheinlichkeit. Er kann daher zwischen benannten Stufen liegen. Legen Sie bei einer Schweregradskala fest, was ein kosmetisches Problem, ein Problem mit Workaround und eine vollständig blockierte Aufgabe voneinander trennt. Das Ergebnis enthält neben dem erwarteten Score auch die Legende der Stufen und die Wahrscheinlichkeiten. Behalten Sie den Score mit Nachkommastellen für Mittelwerte oder Trends; die Auswahl der wahrscheinlichsten Stufe und das Runden des erwarteten Scores beantworten unterschiedliche Fragen.\n\n### Gemeinsame Belege und Lesen des Ergebnisses\n\nDer Hersteller erlaubt eine bis 512 Fragen zum selben Zustand. Geben Sie jeder einen nicht leeren, aussagekräftigen Bezeichner wie category oder severity, damit die zugehörige Antwort verständlich ist, ohne eine nummerierte Frage nachschlagen zu müssen. Trennen Sie unabhängige Anliegen in eigene Fragen, statt mehrere Anforderungen in einem unklaren Kriterium zu bündeln. Eine einzige Nachricht kann eine Kategorieauswahl, einen Schweregrad-Score und eine Bedingungsprüfung stützen, die jeweils ihre eigene Bedeutung behalten.\n\nAntworten vom Typ choice und score enthalten die Konfidenz getrennt von ihren Wahrscheinlichkeitsverteilungen. Der Hersteller unterscheidet ausdrücklich zwischen Konfidenz und der höchsten Optionswahrscheinlichkeit; berechnen Sie das eine nicht aus dem anderen. Behalten Sie bei einer Ja/Nein-Entscheidung die rohe Wahrscheinlichkeit zusammen mit dem gewählten Ergebnis. Prüfen Sie bei einer unsicheren Auswahl die konkurrierenden Wahrscheinlichkeiten, statt das gewinnende Label allein als Beleg für Sicherheit zu werten. Legen Sie Prüfschwellen anhand der Folgen eines falsch positiven oder falsch negativen Ergebnisses fest und bewerten Sie sie anhand repräsentativer gelabelter Fälle.\n\n### Versions- und Größengrenzen\n\nDrex 1.5 dokumentiert ein Budget von 131.072 Tokens für den Zustand und von 139.264 Tokens pro Zeile. Das Zeilenbudget betrifft den Zustand plus die längste einzelne Frage einschließlich ihrer Anweisungen und Optionen; es ist nicht die Summe aller Fragen der Anfrage. Serialisierter Zustand und Fragen müssen zusammen außerdem in 1.048.576 UTF-8-Bytes passen. Eine Anfrage kann die Byte-Grenze einhalten und dennoch eine Token-Grenze überschreiten. Die ältere Edition 1.0 nennt gesondert 32.768 Tokens sowohl für den Zustand als auch für die Zeile; ihre Grenzen sind daher nicht auf 1.5 zu übertragen.\n\nNace dokumentiert drex-v1.5 als versionierten Bezeichner des Herstellers, während drex-latest ein beweglicher Alias ist. Halten Sie die vorgesehene Edition explizit fest, wenn ein Workflow von ihren Grenzen abhängt. Eine fehlerhafte Frage, ein fehlender Zustand oder eine zu große Eingabe ist ein Validierungsproblem, das eine korrigierte Eingabe erfordert, keine geänderte Kategorie oder geratene Antwort. Bereiten Sie die Kriterien anhand beobachtbarer Belege vor und bewahren Sie das typisierte Ergebnis, die ursprünglichen Fakten und die Fragedefinition gemeinsam auf. So wird die Entscheidung für Routing, Priorisierung oder Prüfung nutzbar, ohne eine Wahrscheinlichkeit mit einem garantierten Urteil zu verwechseln.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "f972ca9ad00ae90d621aeb594b01478dd6e92f82f2027e1099700e848af49329", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "de", "methods": [ { "html": "nace-ai/drex-v1.5Drex 1.5 bewertet bereitgestellten Text oder JSON anhand typisierter Fragen und gibt Wahrscheinlichkeiten, ein gewähltes Label oder einen Bewertungsraster-Score mit Nachkommastellen zurück. Nace.AI dokumentiert reine Textentscheidungen für Klassifikation, Routing und Priorisierung, mit versionsspezifischen Grenzen für Zustand und Anfrage.
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.
Drex 1.5 ist das Text-Entscheidungsmodell von Nace.AI. Es bewertet bereitgestellte Fakten anhand geschlossener Fragen und gibt numerische, typisierte Antworten statt einer offenen schriftlichen Antwort zurück. Eine Anfrage kombiniert einen Zustand mit benannten Fragen, und das Ergebnis kennzeichnet jede Antwort mit demselben Fragenamen. So erhält ein Workflow eine konkrete Kategorie, Wahrscheinlichkeit oder Position im Bewertungsraster zur Weiterverarbeitung, während die auf dieses Ergebnis folgende Aktion bei der Anwendung bleibt.
Der Zustand ist die Information, auf die sich jede Frage bezieht. Drex akzeptiert einen JSON-String, ein Objekt, ein Array, eine Zahl, einen booleschen Wert oder null, wobei das Feld state erforderlich ist. Liefern Sie aussagekräftige Belege, auch wenn null die Validierung des Herstellers besteht. Ein String eignet sich für eine Nachricht, ein Dokument oder ein Transkript; ein Objekt eignet sich für Fakten, die bereits in Felder gegliedert sind. Behalten Sie die Informationen, die die Entscheidung beeinflussen, und lassen Sie bei umfangreichem Material nicht zugehörige Felder weg. Behalten Sie ein stabiles Eingabeformat bei, wenn Sie Wahrscheinlichkeitsschwellen interpretieren, denn eine geänderte Darstellung kann die Antwort ändern.
Drex 1.5 liest ausschließlich Text. Die dokumentierte Schnittstelle weist Bilder, Audio, Video und PDF-Inhalte sowohl im Zustand als auch in den Fragen zurück, einschließlich kodierter Medien und Medieninhaltsobjekte. Erstellen Sie eine Bildbeschreibung, erkannten Dokumenttext oder ein Transkript, bevor Sie dieses Material als Beleg verwenden. Eine Textadresse ist kein abgerufenes Dokument oder Bild: Das Modell kann sie nicht öffnen. Bei einer Support-Anfrage ist der nützliche Zustand die tatsächliche Nachricht samt relevantem Kontext, nicht ein Verweis auf Material, das das Modell nicht erhalten hat.
Eine Frage vom Typ noul fragt, ob eine Bedingung zutrifft, und gibt eine Zahl von 0 bis 1 zurück, die die geschätzte Wahrscheinlichkeit für Ja darstellt. Definieren Sie die Frage über nicht leere Anweisungen oder mindestens ein nicht leeres Wahr/Falsch-Kriterium. Fragen Sie beispielsweise, ob eine Nachricht eine defekte Funktion meldet, und legen Sie fest, ob langsames Verhalten als defekt gilt. Drex gibt keinen eingebauten Ja/Nein-Schwellenwert vor; der nachgelagerte Workflow entscheidet, wie die Wahrscheinlichkeit zu interpretieren ist.
Eine Frage vom Typ choice wählt ein bereitgestelltes Label aus einer ungeordneten Menge und gibt für jedes Label eine Wahrscheinlichkeit zurück. Die Kriterien sind ein Objekt, dessen Schlüssel die zurückgegebenen Labels sind, wobei jede Beschreibung ein String oder null ist. Verwenden Sie kurze, stabile Schlüssel und beschreiben Sie die Kategoriegrenzen klar. Eine beispielhafte Routing-Aufgabe kann zwischen einem Zugriffsproblem, einem Produktfehler und einer allgemeinen Frage unterscheiden, ergänzt um eine Kategorie „Sonstiges“ für Nachrichten, die nicht passen. Das gewählte Label ist für das Routing nützlich; die Verteilung hilft, Fälle zu erkennen, in denen sich zwei Optionen nur schwer trennen lassen.
Eine Frage vom Typ score verwendet ein geordnetes Array von Stufenbezeichnungen. Die Indizes beginnen bei 0, und der zurückgegebene Score ist die Summe aus jedem Stufenindex multipliziert mit seiner Wahrscheinlichkeit. Er kann daher zwischen benannten Stufen liegen. Legen Sie bei einer Schweregradskala fest, was ein kosmetisches Problem, ein Problem mit Workaround und eine vollständig blockierte Aufgabe voneinander trennt. Das Ergebnis enthält neben dem erwarteten Score auch die Legende der Stufen und die Wahrscheinlichkeiten. Behalten Sie den Score mit Nachkommastellen für Mittelwerte oder Trends; die Auswahl der wahrscheinlichsten Stufe und das Runden des erwarteten Scores beantworten unterschiedliche Fragen.
Der Hersteller erlaubt eine bis 512 Fragen zum selben Zustand. Geben Sie jeder einen nicht leeren, aussagekräftigen Bezeichner wie category oder severity, damit die zugehörige Antwort verständlich ist, ohne eine nummerierte Frage nachschlagen zu müssen. Trennen Sie unabhängige Anliegen in eigene Fragen, statt mehrere Anforderungen in einem unklaren Kriterium zu bündeln. Eine einzige Nachricht kann eine Kategorieauswahl, einen Schweregrad-Score und eine Bedingungsprüfung stützen, die jeweils ihre eigene Bedeutung behalten.
Antworten vom Typ choice und score enthalten die Konfidenz getrennt von ihren Wahrscheinlichkeitsverteilungen. Der Hersteller unterscheidet ausdrücklich zwischen Konfidenz und der höchsten Optionswahrscheinlichkeit; berechnen Sie das eine nicht aus dem anderen. Behalten Sie bei einer Ja/Nein-Entscheidung die rohe Wahrscheinlichkeit zusammen mit dem gewählten Ergebnis. Prüfen Sie bei einer unsicheren Auswahl die konkurrierenden Wahrscheinlichkeiten, statt das gewinnende Label allein als Beleg für Sicherheit zu werten. Legen Sie Prüfschwellen anhand der Folgen eines falsch positiven oder falsch negativen Ergebnisses fest und bewerten Sie sie anhand repräsentativer gelabelter Fälle.
Drex 1.5 dokumentiert ein Budget von 131.072 Tokens für den Zustand und von 139.264 Tokens pro Zeile. Das Zeilenbudget betrifft den Zustand plus die längste einzelne Frage einschließlich ihrer Anweisungen und Optionen; es ist nicht die Summe aller Fragen der Anfrage. Serialisierter Zustand und Fragen müssen zusammen außerdem in 1.048.576 UTF-8-Bytes passen. Eine Anfrage kann die Byte-Grenze einhalten und dennoch eine Token-Grenze überschreiten. Die ältere Edition 1.0 nennt gesondert 32.768 Tokens sowohl für den Zustand als auch für die Zeile; ihre Grenzen sind daher nicht auf 1.5 zu übertragen.
Nace dokumentiert drex-v1.5 als versionierten Bezeichner des Herstellers, während drex-latest ein beweglicher Alias ist. Halten Sie die vorgesehene Edition explizit fest, wenn ein Workflow von ihren Grenzen abhängt. Eine fehlerhafte Frage, ein fehlender Zustand oder eine zu große Eingabe ist ein Validierungsproblem, das eine korrigierte Eingabe erfordert, keine geänderte Kategorie oder geratene Antwort. Bereiten Sie die Kriterien anhand beobachtbarer Belege vor und bewahren Sie das typisierte Ergebnis, die ursprünglichen Fakten und die Fragedefinition gemeinsam auf. So wird die Entscheidung für Routing, Priorisierung oder Prüfung nutzbar, ohne eine Wahrscheinlichkeit mit einem garantierten Urteil zu verwechseln.
POST /v1/systemonetextdecisions| Feld | Typ | Anforderung | Werte und Limits | Standard |
|---|---|---|---|---|
Feldmodel | Typstring | AnforderungErforderlich | Werte und Limits nace-ai/drex-v1.5 | 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.00008 / 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.00008 / 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": "nace-ai/drex-v1.5",\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']='nace-ai/drex-v1.5'\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 nace-ai/drex-v1.5
Verwenden Sie die oben angezeigten Methodenpfade.