d1 ist das gehostete Entscheidungsmodell von Liquid AI für begrenzte Klassifikations-, Routing- und Scoring-Aufgaben. Dieses Profil beschreibt seinen Text-Entscheidungsworkflow: Sie stellen die Belege als Zustand bereit, definieren eine oder mehrere Fragen und erhalten typisierte numerische Antworten über bekannte Ergebnisse. Liquid beschreibt diese Entscheidungen als Auswertungen, die Wahrscheinlichkeiten direkt zurückgeben, mit null generierten Ausgabe-Tokens. Das nützliche Ergebnis ist eine definierte Entscheidung samt ihrer Unsicherheit, kein neu verfasster Textabschnitt.
Stellen Sie den Text bereit, der die Entscheidung ermöglicht, einschließlich des zu seiner Interpretation nötigen Kontexts. Halten Sie den Zustand getrennt von den Anweisungen, die beschreiben, was ausgewertet werden soll. Eine Support-Nachricht kann eine Produkt- oder Problembeschreibung benötigen; eine Dokumentpassage kann die Suchfrage des Nutzers benötigen. Legen Sie die Antwortmenge fest, bevor Sie die Frage stellen, und geben Sie jeder Option eine Bedeutung, die zum vorgesehenen Workflow passt. Kurze Labels können als stabile Ausgabeschlüssel dienen, während Beschreibungen die Grenzen zwischen ihnen erklären.
Verwenden Sie benannte Fragen über einen gemeinsamen Zustand. Ein klarer Name wie intent, urgency oder relevant hält die Ausgabe mit der Entscheidung verknüpft, die sie darstellt. Eine Nachricht, die meldet, dass eine Seite nicht funktioniert, kann beispielsweise eine Absichtsauswahl, ein Dringlichkeitsraster und eine Ja/Nein-Prüfung auf einen gemeldeten Fehler stützen. Jede Frage sollte ihr eigenes Kriterium behalten, statt alle drei Urteile in einem einzigen mehrdeutigen Label zu vereinen.
Eine Frage vom Typ choice wählt ein Label aus einer ungeordneten Menge und gibt die Verteilung über die benannten Optionen zurück. Definieren Sie die Optionen über Kriterienbeschreibungen; das Ergebnis enthält die gewählte Option, die Wahrscheinlichkeiten und die Konfidenz. Definieren Sie für die Dokumentenorganisation die möglichen Ordner oder Themen und legen Sie fest, welche Inhalte jeweils dazugehören. Beschreiben Sie für das Routing von Anfragen die tatsächlich vorhandenen Ziele. Eine Anwendung kann das resultierende Label nutzen, um ihren nächsten Schritt zu wählen, und die konkurrierenden Wahrscheinlichkeiten für die Prüfung aufbewahren.
Eine beispielhafte Ablageaufgabe kann eine Produktfrage, ein Integrationsproblem und ein Zugriffsproblem unterscheiden, ergänzt um eine Option „Sonstiges“ für Material außerhalb dieser Definitionen. Halten Sie die Grenzen konkret: Eine Nachricht über eine fehlschlagende Authentifizierung unterscheidet sich von einer, die fragt, wie eine Funktion konfiguriert wird. Das zurückgegebene Label wählt zwischen bereitgestellten Bedeutungen; es erzeugt kein fehlendes Ziel und führt keine Änderung in einem anderen System aus.
Eine Frage vom Typ noul gibt eine Wahrscheinlichkeit von 0 bis 1 zurück, dass die definierte Ja/Nein-Bedingung zutrifft. Liquid demonstriert binäre Prüfungen für die Inhaltsprüfung und die Relevanz von Passagen. Formulieren Sie die Bedingung präzise und legen Sie fest, wie die resultierende Wahrscheinlichkeit verwendet wird: einen wahrscheinlichen Treffer markieren, eine Passage filtern oder einen unsicheren Fall zur Prüfung weiterleiten. Der Schwellenwert gehört zur nachgelagerten Aufgabe, und eine Wahrscheinlichkeit ist nicht als garantiertes faktisches Urteil zu behandeln.
Stellen Sie für die Relevanzfilterung sowohl die Suchanfrage als auch die Kandidatenpassage bereit. Fragen Sie, ob diese Passage zur Beantwortung der Anfrage beiträgt, und bewahren Sie dann die ursprüngliche Passage mit ihrer Wahrscheinlichkeit auf. Das kann die Auswahl von Quellmaterial für eine spätere Antwort unterstützen, ohne d1 aufzufordern, diese Antwort selbst zu verfassen. Wenn Relevanz mehrere Abstufungen statt einer Ja/Nein-Bedingung benötigt, definieren Sie ein geordnetes Bewertungsraster und verwenden Sie eine Frage vom Typ score.
Eine Frage vom Typ score ordnet den Zustand in ein Bewertungsraster mit geordneten, beschriebenen Stufen ein. Die Stufenindizes beginnen bei 0, und der Score ist ihre wahrscheinlichkeitsgewichtete Position, die zwischen Stufen liegen kann. Das Ergebnis enthält außerdem die Stufenverteilung und die Konfidenz. Legen Sie für Dringlichkeit fest, was ein Problem ohne unmittelbare Auswirkung, eine spürbare Beeinträchtigung und eine blockierte Aufgabe voneinander trennt. Ein Raster mit vier Stufen hat daher die Indizes 0 bis 3; sein erwarteter Score ist nicht automatisch eine Kategorie mit den Nummern 1 bis 4.
Verwenden Sie den Score mit Nachkommastellen für Sortierung oder Aggregation, wenn das das beabsichtigte Ergebnis ist, und behalten Sie die vollständige Verteilung, wenn Mehrdeutigkeit eine Rolle spielt. Kategorien wie Abteilungen haben keine natürliche Reihenfolge und gehören in eine Frage vom Typ choice. Die Konfidenz fasst in der dokumentierten Schnittstelle zusammen, wie eindeutig die gemeldete Antwort ist; sie sollte vom gewünschten Score der Aufgabe und von einer angenommenen Garantie, dass die Entscheidung korrekt ist, getrennt bleiben.
Mehrere Fragen können denselben Zustand in einem Aufruf beim Hersteller auswerten, wobei jede ihren Typ und ihre Wahrscheinlichkeiten behält. Zu den Textbeispielen von Liquid gehören das Filtern von Support-Tickets, das Ablegen von Dokumenten in einer Ordnertaxonomie, die Auswahl von Pfaden für die Codesuche, die Wahl zwischen verfügbaren Agentenaktionen und die Entscheidung, welches Material aus Tool-Ausgaben behalten wird. Alle diese Workflows haben eine begrenzte nächste Entscheidung. Ein Codesuche-Schritt kann anhand der Beschreibungen einen vielversprechenden Ordner auswählen; ein Schritt zur Inhaltsauswahl kann für bereitgestelltes Material zwischen behalten, kürzen und verwerfen wählen. Die umgebende Anwendung beschafft weiterhin die Quelldaten und führt die gewählte Operation aus.
Die dokumentierten Grundbausteine eignen sich für bekannte Ergebnisse, Bewertungen nach einem Raster und Bedingungsprüfungen. Neue Prosa, Zusammenfassungen, Code und ein offenes Gespräch erfordern einen Generierungsworkflow und ergeben sich nicht aus dem Entscheidungsergebnis von d1. Formulieren Sie eine Frage anhand beobachtbarer Belege und bewahren Sie die Definitionen dieser Frage zusammen mit der Ausgabe auf, damit ein Label oder Score später interpretiert werden kann.
Richten Sie jeden Zustand auf die Belege aus, die seine definierten Fragen beantworten, und trennen Sie unabhängige Entscheidungsaufgaben, damit ihre Kriterien klar bleiben. Halten Sie das Quellmaterial relevant, definieren Sie Ausweichbedeutungen für eine unvollständige Abdeckung der Kategorien und bewerten Sie Wahrscheinlichkeitsschwellen anhand gelabelter Beispiele aus der Aufgabe. Ein nützliches Artefakt erfasst die gewählte Kategorie oder den erwarteten Score zusammen mit der Verteilung, der Identität der Frage und den ursprünglichen Belegen.
", "aboutText": "d1 ist das gehostete Entscheidungsmodell von Liquid AI für begrenzte Klassifikations-, Routing- und Scoring-Aufgaben. Dieses Profil beschreibt seinen Text-Entscheidungsworkflow: Sie stellen die Belege als Zustand bereit, definieren eine oder mehrere Fragen und erhalten typisierte numerische Antworten über bekannte Ergebnisse. Liquid beschreibt diese Entscheidungen als Auswertungen, die Wahrscheinlichkeiten direkt zurückgeben, mit null generierten Ausgabe-Tokens. Das nützliche Ergebnis ist eine definierte Entscheidung samt ihrer Unsicherheit, kein neu verfasster Textabschnitt.\n\n### Belege und Frage gemeinsam vorbereiten\n\nStellen Sie den Text bereit, der die Entscheidung ermöglicht, einschließlich des zu seiner Interpretation nötigen Kontexts. Halten Sie den Zustand getrennt von den Anweisungen, die beschreiben, was ausgewertet werden soll. Eine Support-Nachricht kann eine Produkt- oder Problembeschreibung benötigen; eine Dokumentpassage kann die Suchfrage des Nutzers benötigen. Legen Sie die Antwortmenge fest, bevor Sie die Frage stellen, und geben Sie jeder Option eine Bedeutung, die zum vorgesehenen Workflow passt. Kurze Labels können als stabile Ausgabeschlüssel dienen, während Beschreibungen die Grenzen zwischen ihnen erklären.\n\nVerwenden Sie benannte Fragen über einen gemeinsamen Zustand. Ein klarer Name wie intent, urgency oder relevant hält die Ausgabe mit der Entscheidung verknüpft, die sie darstellt. Eine Nachricht, die meldet, dass eine Seite nicht funktioniert, kann beispielsweise eine Absichtsauswahl, ein Dringlichkeitsraster und eine Ja/Nein-Prüfung auf einen gemeldeten Fehler stützen. Jede Frage sollte ihr eigenes Kriterium behalten, statt alle drei Urteile in einem einzigen mehrdeutigen Label zu vereinen.\n\n### Choice für Kategorien und Routing\n\nEine Frage vom Typ choice wählt ein Label aus einer ungeordneten Menge und gibt die Verteilung über die benannten Optionen zurück. Definieren Sie die Optionen über Kriterienbeschreibungen; das Ergebnis enthält die gewählte Option, die Wahrscheinlichkeiten und die Konfidenz. Definieren Sie für die Dokumentenorganisation die möglichen Ordner oder Themen und legen Sie fest, welche Inhalte jeweils dazugehören. Beschreiben Sie für das Routing von Anfragen die tatsächlich vorhandenen Ziele. Eine Anwendung kann das resultierende Label nutzen, um ihren nächsten Schritt zu wählen, und die konkurrierenden Wahrscheinlichkeiten für die Prüfung aufbewahren.\n\nEine beispielhafte Ablageaufgabe kann eine Produktfrage, ein Integrationsproblem und ein Zugriffsproblem unterscheiden, ergänzt um eine Option „Sonstiges“ für Material außerhalb dieser Definitionen. Halten Sie die Grenzen konkret: Eine Nachricht über eine fehlschlagende Authentifizierung unterscheidet sich von einer, die fragt, wie eine Funktion konfiguriert wird. Das zurückgegebene Label wählt zwischen bereitgestellten Bedeutungen; es erzeugt kein fehlendes Ziel und führt keine Änderung in einem anderen System aus.\n\n### Noul für Bedingungsprüfungen und Relevanz\n\nEine Frage vom Typ noul gibt eine Wahrscheinlichkeit von 0 bis 1 zurück, dass die definierte Ja/Nein-Bedingung zutrifft. Liquid demonstriert binäre Prüfungen für die Inhaltsprüfung und die Relevanz von Passagen. Formulieren Sie die Bedingung präzise und legen Sie fest, wie die resultierende Wahrscheinlichkeit verwendet wird: einen wahrscheinlichen Treffer markieren, eine Passage filtern oder einen unsicheren Fall zur Prüfung weiterleiten. Der Schwellenwert gehört zur nachgelagerten Aufgabe, und eine Wahrscheinlichkeit ist nicht als garantiertes faktisches Urteil zu behandeln.\n\nStellen Sie für die Relevanzfilterung sowohl die Suchanfrage als auch die Kandidatenpassage bereit. Fragen Sie, ob diese Passage zur Beantwortung der Anfrage beiträgt, und bewahren Sie dann die ursprüngliche Passage mit ihrer Wahrscheinlichkeit auf. Das kann die Auswahl von Quellmaterial für eine spätere Antwort unterstützen, ohne d1 aufzufordern, diese Antwort selbst zu verfassen. Wenn Relevanz mehrere Abstufungen statt einer Ja/Nein-Bedingung benötigt, definieren Sie ein geordnetes Bewertungsraster und verwenden Sie eine Frage vom Typ score.\n\n### Score für geordnete Stufen\n\nEine Frage vom Typ score ordnet den Zustand in ein Bewertungsraster mit geordneten, beschriebenen Stufen ein. Die Stufenindizes beginnen bei 0, und der Score ist ihre wahrscheinlichkeitsgewichtete Position, die zwischen Stufen liegen kann. Das Ergebnis enthält außerdem die Stufenverteilung und die Konfidenz. Legen Sie für Dringlichkeit fest, was ein Problem ohne unmittelbare Auswirkung, eine spürbare Beeinträchtigung und eine blockierte Aufgabe voneinander trennt. Ein Raster mit vier Stufen hat daher die Indizes 0 bis 3; sein erwarteter Score ist nicht automatisch eine Kategorie mit den Nummern 1 bis 4.\n\nVerwenden Sie den Score mit Nachkommastellen für Sortierung oder Aggregation, wenn das das beabsichtigte Ergebnis ist, und behalten Sie die vollständige Verteilung, wenn Mehrdeutigkeit eine Rolle spielt. Kategorien wie Abteilungen haben keine natürliche Reihenfolge und gehören in eine Frage vom Typ choice. Die Konfidenz fasst in der dokumentierten Schnittstelle zusammen, wie eindeutig die gemeldete Antwort ist; sie sollte vom gewünschten Score der Aufgabe und von einer angenommenen Garantie, dass die Entscheidung korrekt ist, getrennt bleiben.\n\n### Mehrere Fragen und Anwendungen des Herstellers\n\nMehrere Fragen können denselben Zustand in einem Aufruf beim Hersteller auswerten, wobei jede ihren Typ und ihre Wahrscheinlichkeiten behält. Zu den Textbeispielen von Liquid gehören das Filtern von Support-Tickets, das Ablegen von Dokumenten in einer Ordnertaxonomie, die Auswahl von Pfaden für die Codesuche, die Wahl zwischen verfügbaren Agentenaktionen und die Entscheidung, welches Material aus Tool-Ausgaben behalten wird. Alle diese Workflows haben eine begrenzte nächste Entscheidung. Ein Codesuche-Schritt kann anhand der Beschreibungen einen vielversprechenden Ordner auswählen; ein Schritt zur Inhaltsauswahl kann für bereitgestelltes Material zwischen behalten, kürzen und verwerfen wählen. Die umgebende Anwendung beschafft weiterhin die Quelldaten und führt die gewählte Operation aus.\n\n### Umfang und ein nützliches Entscheidungsartefakt\n\nDie dokumentierten Grundbausteine eignen sich für bekannte Ergebnisse, Bewertungen nach einem Raster und Bedingungsprüfungen. Neue Prosa, Zusammenfassungen, Code und ein offenes Gespräch erfordern einen Generierungsworkflow und ergeben sich nicht aus dem Entscheidungsergebnis von d1. Formulieren Sie eine Frage anhand beobachtbarer Belege und bewahren Sie die Definitionen dieser Frage zusammen mit der Ausgabe auf, damit ein Label oder Score später interpretiert werden kann.\n\nRichten Sie jeden Zustand auf die Belege aus, die seine definierten Fragen beantworten, und trennen Sie unabhängige Entscheidungsaufgaben, damit ihre Kriterien klar bleiben. Halten Sie das Quellmaterial relevant, definieren Sie Ausweichbedeutungen für eine unvollständige Abdeckung der Kategorien und bewerten Sie Wahrscheinlichkeitsschwellen anhand gelabelter Beispiele aus der Aufgabe. Ein nützliches Artefakt erfasst die gewählte Kategorie oder den erwarteten Score zusammen mit der Verteilung, der Identität der Frage und den ursprünglichen Belegen.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "5e43133145c208c891d51e257bbbc8660859be3b443c2c0c57aa425256eb0b48", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "de", "methods": [ { "html": "liquid/d1Der Text-Entscheidungsworkflow von Liquid AI d1 bewertet bereitgestellte Belege anhand fester Ergebnisse und gibt Wahrscheinlichkeiten, eine Kategorieauswahl oder einen Bewertungsraster-Score zurück. Er unterstützt Klassifikation, Routing, Relevanzfilterung und Priorisierung, ohne eine schriftliche Antwort zu generieren.
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.
d1 ist das gehostete Entscheidungsmodell von Liquid AI für begrenzte Klassifikations-, Routing- und Scoring-Aufgaben. Dieses Profil beschreibt seinen Text-Entscheidungsworkflow: Sie stellen die Belege als Zustand bereit, definieren eine oder mehrere Fragen und erhalten typisierte numerische Antworten über bekannte Ergebnisse. Liquid beschreibt diese Entscheidungen als Auswertungen, die Wahrscheinlichkeiten direkt zurückgeben, mit null generierten Ausgabe-Tokens. Das nützliche Ergebnis ist eine definierte Entscheidung samt ihrer Unsicherheit, kein neu verfasster Textabschnitt.
Stellen Sie den Text bereit, der die Entscheidung ermöglicht, einschließlich des zu seiner Interpretation nötigen Kontexts. Halten Sie den Zustand getrennt von den Anweisungen, die beschreiben, was ausgewertet werden soll. Eine Support-Nachricht kann eine Produkt- oder Problembeschreibung benötigen; eine Dokumentpassage kann die Suchfrage des Nutzers benötigen. Legen Sie die Antwortmenge fest, bevor Sie die Frage stellen, und geben Sie jeder Option eine Bedeutung, die zum vorgesehenen Workflow passt. Kurze Labels können als stabile Ausgabeschlüssel dienen, während Beschreibungen die Grenzen zwischen ihnen erklären.
Verwenden Sie benannte Fragen über einen gemeinsamen Zustand. Ein klarer Name wie intent, urgency oder relevant hält die Ausgabe mit der Entscheidung verknüpft, die sie darstellt. Eine Nachricht, die meldet, dass eine Seite nicht funktioniert, kann beispielsweise eine Absichtsauswahl, ein Dringlichkeitsraster und eine Ja/Nein-Prüfung auf einen gemeldeten Fehler stützen. Jede Frage sollte ihr eigenes Kriterium behalten, statt alle drei Urteile in einem einzigen mehrdeutigen Label zu vereinen.
Eine Frage vom Typ choice wählt ein Label aus einer ungeordneten Menge und gibt die Verteilung über die benannten Optionen zurück. Definieren Sie die Optionen über Kriterienbeschreibungen; das Ergebnis enthält die gewählte Option, die Wahrscheinlichkeiten und die Konfidenz. Definieren Sie für die Dokumentenorganisation die möglichen Ordner oder Themen und legen Sie fest, welche Inhalte jeweils dazugehören. Beschreiben Sie für das Routing von Anfragen die tatsächlich vorhandenen Ziele. Eine Anwendung kann das resultierende Label nutzen, um ihren nächsten Schritt zu wählen, und die konkurrierenden Wahrscheinlichkeiten für die Prüfung aufbewahren.
Eine beispielhafte Ablageaufgabe kann eine Produktfrage, ein Integrationsproblem und ein Zugriffsproblem unterscheiden, ergänzt um eine Option „Sonstiges“ für Material außerhalb dieser Definitionen. Halten Sie die Grenzen konkret: Eine Nachricht über eine fehlschlagende Authentifizierung unterscheidet sich von einer, die fragt, wie eine Funktion konfiguriert wird. Das zurückgegebene Label wählt zwischen bereitgestellten Bedeutungen; es erzeugt kein fehlendes Ziel und führt keine Änderung in einem anderen System aus.
Eine Frage vom Typ noul gibt eine Wahrscheinlichkeit von 0 bis 1 zurück, dass die definierte Ja/Nein-Bedingung zutrifft. Liquid demonstriert binäre Prüfungen für die Inhaltsprüfung und die Relevanz von Passagen. Formulieren Sie die Bedingung präzise und legen Sie fest, wie die resultierende Wahrscheinlichkeit verwendet wird: einen wahrscheinlichen Treffer markieren, eine Passage filtern oder einen unsicheren Fall zur Prüfung weiterleiten. Der Schwellenwert gehört zur nachgelagerten Aufgabe, und eine Wahrscheinlichkeit ist nicht als garantiertes faktisches Urteil zu behandeln.
Stellen Sie für die Relevanzfilterung sowohl die Suchanfrage als auch die Kandidatenpassage bereit. Fragen Sie, ob diese Passage zur Beantwortung der Anfrage beiträgt, und bewahren Sie dann die ursprüngliche Passage mit ihrer Wahrscheinlichkeit auf. Das kann die Auswahl von Quellmaterial für eine spätere Antwort unterstützen, ohne d1 aufzufordern, diese Antwort selbst zu verfassen. Wenn Relevanz mehrere Abstufungen statt einer Ja/Nein-Bedingung benötigt, definieren Sie ein geordnetes Bewertungsraster und verwenden Sie eine Frage vom Typ score.
Eine Frage vom Typ score ordnet den Zustand in ein Bewertungsraster mit geordneten, beschriebenen Stufen ein. Die Stufenindizes beginnen bei 0, und der Score ist ihre wahrscheinlichkeitsgewichtete Position, die zwischen Stufen liegen kann. Das Ergebnis enthält außerdem die Stufenverteilung und die Konfidenz. Legen Sie für Dringlichkeit fest, was ein Problem ohne unmittelbare Auswirkung, eine spürbare Beeinträchtigung und eine blockierte Aufgabe voneinander trennt. Ein Raster mit vier Stufen hat daher die Indizes 0 bis 3; sein erwarteter Score ist nicht automatisch eine Kategorie mit den Nummern 1 bis 4.
Verwenden Sie den Score mit Nachkommastellen für Sortierung oder Aggregation, wenn das das beabsichtigte Ergebnis ist, und behalten Sie die vollständige Verteilung, wenn Mehrdeutigkeit eine Rolle spielt. Kategorien wie Abteilungen haben keine natürliche Reihenfolge und gehören in eine Frage vom Typ choice. Die Konfidenz fasst in der dokumentierten Schnittstelle zusammen, wie eindeutig die gemeldete Antwort ist; sie sollte vom gewünschten Score der Aufgabe und von einer angenommenen Garantie, dass die Entscheidung korrekt ist, getrennt bleiben.
Mehrere Fragen können denselben Zustand in einem Aufruf beim Hersteller auswerten, wobei jede ihren Typ und ihre Wahrscheinlichkeiten behält. Zu den Textbeispielen von Liquid gehören das Filtern von Support-Tickets, das Ablegen von Dokumenten in einer Ordnertaxonomie, die Auswahl von Pfaden für die Codesuche, die Wahl zwischen verfügbaren Agentenaktionen und die Entscheidung, welches Material aus Tool-Ausgaben behalten wird. Alle diese Workflows haben eine begrenzte nächste Entscheidung. Ein Codesuche-Schritt kann anhand der Beschreibungen einen vielversprechenden Ordner auswählen; ein Schritt zur Inhaltsauswahl kann für bereitgestelltes Material zwischen behalten, kürzen und verwerfen wählen. Die umgebende Anwendung beschafft weiterhin die Quelldaten und führt die gewählte Operation aus.
Die dokumentierten Grundbausteine eignen sich für bekannte Ergebnisse, Bewertungen nach einem Raster und Bedingungsprüfungen. Neue Prosa, Zusammenfassungen, Code und ein offenes Gespräch erfordern einen Generierungsworkflow und ergeben sich nicht aus dem Entscheidungsergebnis von d1. Formulieren Sie eine Frage anhand beobachtbarer Belege und bewahren Sie die Definitionen dieser Frage zusammen mit der Ausgabe auf, damit ein Label oder Score später interpretiert werden kann.
Richten Sie jeden Zustand auf die Belege aus, die seine definierten Fragen beantworten, und trennen Sie unabhängige Entscheidungsaufgaben, damit ihre Kriterien klar bleiben. Halten Sie das Quellmaterial relevant, definieren Sie Ausweichbedeutungen für eine unvollständige Abdeckung der Kategorien und bewerten Sie Wahrscheinlichkeitsschwellen anhand gelabelter Beispiele aus der Aufgabe. Ein nützliches Artefakt erfasst die gewählte Kategorie oder den erwarteten Score zusammen mit der Verteilung, der Identität der Frage und den ursprünglichen Belegen.
POST /v1/systemonetextdecisions| Feld | Typ | Anforderung | Werte und Limits | Standard |
|---|---|---|---|---|
Feldmodel | Typstring | AnforderungErforderlich | Werte und Limits liquid/d1 | 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 $0.00008 / 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 $0.00008 / 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": "liquid/d1",\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']='liquid/d1'\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 liquid/d1
Verwenden Sie die oben angezeigten Methodenpfade.