Kev-4B ist ein kompaktes Entscheidungsmodell zur Beantwortung typisierter Fragen über einen bereitgestellten Zustand. Der Zustand ist das bewertete Dokument oder der Datensatz, und jede Frage definiert die Optionen, die das Modell bewerten kann. Sein Ergebnis ist eine Wahrscheinlichkeitsverteilung und ein typisierter Entscheidungsdatensatz, wodurch es für Dokumentklassifikation, Weiterleitung, Triage, Extraktionsauswahl und Prüfungen anhand angegebener Kriterien nützlich ist.
Das Modell kombiniert eine eingefrorene Qwen3.5-4B-Base-Grundarchitektur mit einem LoRA-Adapter und einem Pointer-Kopf. Die Grundarchitektur hat 32 Schichten, bestehend aus 24 Gated-DeltaNet-Schichten und acht Full-Attention-Schichten. Der Adapter setzt an Attention-, MLP- und DeltaNet-Projektionen an; der Pointer-Kopf bewertet die bereitgestellten Optionen und wandelt diese Werte in Wahrscheinlichkeiten um. Dies ist ein reiner Prefill-Entscheidungsablauf, bei dem die Optionen den Antwortraum bilden.
Drei Fragetypen können in derselben Anfrage vorkommen. Eine choice-Frage akzeptiert 1–255 benannte Optionen, optional mit Beschreibungen, und gibt die wahrscheinlichste Option, einen separaten Konfidenzwert und Wahrscheinlichkeiten für die Optionen zurück. Eine Ja/Nein-Frage, im Format des Herstellers noul genannt, gibt die Ja-Wahrscheinlichkeit zurück. Definieren Sie die Bedeutung von Ja in der Frage, statt anzunehmen, dass eine hohe Zahl immer ein positives Ergebnis für die Anwendung bedeutet.
Eine Frage nach einem geordneten Score akzeptiert 1–255 Stufen und gibt Wahrscheinlichkeiten für die Stufen und deren erwarteten Index zurück. Stufenindizes beginnen bei null. Das Ergebnisformat des Herstellers enthält ausserdem die Stufenlegende und einen separaten Konfidenzwert. Ein erwarteter Index kann Nachkommastellen enthalten: Er fasst die Verteilung über Ihre geordneten Stufen zusammen, statt eine neue Textbezeichnung auszuwählen. Bewahren Sie Stufenreihenfolge und Legende beim Ergebnis, damit eine Bewertung einheitlich interpretiert werden kann.
Fragen teilen denselben Zustand, werden aber unabhängig bewertet. Eine Frage kann die Antwort einer anderen nicht lesen, und der Zustand wird einmal berechnet und wiederverwendet. Wenn eine spätere Entscheidung von einem Ergebnis einer früheren abhängt, machen Sie diese Abhängigkeit in einem nachfolgenden Zustand ausdrücklich, statt von den Fragen einer Anfrage eine Kette zu erwarten. Dadurch eignet sich der Ablauf mit gemeinsamem Zustand für mehrere unabhängige Prüfungen desselben Dokuments.
Bereiten Sie den Zustand mit den Belegen vor, die die Fragen tatsächlich benötigen. Er kann Klartext oder ein als beschrifteter Text dargestelltes JSON-Objekt oder -Array sein. Halten Sie Feldnamen, Einheiten, Richtlinienbedingungen und relevante Quellpassagen klar. Schreiben Sie für jede Frage eine konkrete Anweisung und geben Sie ihren Optionen Bedeutungen, die anhand des Datensatzes unterscheidbar sind. Bei einer ursprünglichen Support-Weiterleitungsaufgabe kann der Zustand die Anfrage und ihren Kontext enthalten, während die Auswahlmöglichkeiten Liefer-, Zugangs- und Produktsupport-Kategorien mit kurzen Beschreibungen definieren.
Eine zweite Frage kann die Dringlichkeit bewerten, und eine geordnete Frage kann einschätzen, wie viel Nachverfolgung die Anfrage benötigt. Dies beantwortet unterschiedliche operative Fragen; definieren Sie daher jede separat. Nehmen Sie eine passende Prüf- oder Fehlende-Belege-Option auf, wenn die Auswahlaufgabe sie benötigt, und bewahren Sie die vollständige Verteilung, wenn mehrere Kategorien plausibel sind. Die Anwendung entscheidet über Weiterleitung oder Prüfung eines Ergebnisses; das Modell liefert den bewerteten Datensatz.
Kev-4B ist für typisierte Entscheidungen über Dokumente mit einigen Tausend Tokens vorgesehen. Das Bereitstellungsprofil des Herstellers akzeptiert Zustände bis zu 65’536 Tokens und reserviert zusätzlichen Platz für jede Frage, während die validierte Kontextlänge dieses Checkpoints 8192 Tokens beträgt. Dies sind unterschiedliche Grenzen: Die Annahme eines längeren Zustands belegt keine gleich zuverlässigen Entscheidungen bei jeder Länge. Halten Sie entscheidende Passagen kompakt und bewahren Sie ihre Bezeichnungen, wenn Sie einen langen Datensatz zur Klassifikation vorbereiten.
Das veröffentlichte Profil ist englischsprachig. Seine nützlichen Aufgaben hängen von Belegen im bereitgestellten Zustand und den definierten Optionen ab, statt von offenem Chat, Zusammenfassung oder umfassender wissensbasierter Beantwortung. Datumsarithmetik auf Tagesebene ist eine besondere Einschränkung: Der Hersteller liefert einen separaten Vorprozessor für Datumsfakten, der berechnete Intervalle bereitstellt. Nehmen Sie für eine Fristprüfung die relevanten Datumsangaben und berechneten Tagesintervalle zusammen mit der Regel, die sie verwendet, in den Zustand auf.
Der Checkpoint wird mit angepasster Wahrscheinlichkeitskalibrierung ausgeliefert, doch die Konfidenz kann sich mit Dokumentdomäne und Fragengestaltung ändern. Der Hersteller dokumentiert ausserdem das Fine-Tuning des offenen Checkpoints auf aufgabenspezifische Bezeichnungen und die Anpassung seiner Wahrscheinlichkeitskalibrierung an diese Arbeitslast; dies ist ein separater Anpassungsworkflow gegenüber der Bewertung eines bereitgestellten Zustands. Wählen Sie Entscheidungsschwellen anhand gekennzeichneter Beispiele der tatsächlichen Arbeitslast und halten Sie unsichere Fälle für die Prüfung sichtbar. Der Hersteller schliesst vollständig automatisierte folgenreiche Entscheidungen über Menschen ohne menschliche Prüfung aus. Auch die Optionsreihenfolge kann eine Antwort beeinflussen; bewahren Sie daher bei Ergebnisvergleichen eine stabile Reihenfolge. Bewerten Sie die gewählte Bezeichnung, das separate confidence-Feld und die Wahrscheinlichkeitsverteilung entsprechend ihrer jeweiligen Rolle in Ihrem Workflow.
Die vom Hersteller beschriebene aktuelle Kev-4B-Veröffentlichung gehört zu Kev 1.0 und verwendet die Qwen3.5-Basis. Frühere Qwen3-basierte und nur auf die Dokumentstufe beschränkte Veröffentlichungen bleiben eigene Versionen. Halten Sie beim Entwickeln eines aufgabenspezifischen Workflows die gewählte Ausgabe und die Fragendefinitionen mit den Ausgaben verknüpft, statt Ergebnisse unterschiedlicher Profile zu vermischen.
Ein nützliches abschliessendes Artefakt ist eine benannte Menge von Entscheidungsdatensätzen mit den ursprünglichen Fragen, Optionsdefinitionen, Verteilungen und gegebenenfalls geordneten Stufenlegenden. Für eine Antwortqualitätsprüfung sollte der Zustand die vorgeschlagene Antwort, die Belege und das geprüfte Kriterium enthalten. Für Richtlinientriage sollte er die geltende Regel und relevante Fakten enthalten. Bewahren Sie diese Eingabe beim Ergebnis, damit eine Prüfung feststellen kann, warum eine Entscheidung angemessen war oder welcher fehlende Fakt ergänzt werden muss.
", "aboutText": "Kev-4B ist ein kompaktes Entscheidungsmodell zur Beantwortung typisierter Fragen über einen bereitgestellten Zustand. Der Zustand ist das bewertete Dokument oder der Datensatz, und jede Frage definiert die Optionen, die das Modell bewerten kann. Sein Ergebnis ist eine Wahrscheinlichkeitsverteilung und ein typisierter Entscheidungsdatensatz, wodurch es für Dokumentklassifikation, Weiterleitung, Triage, Extraktionsauswahl und Prüfungen anhand angegebener Kriterien nützlich ist.\n\nDas Modell kombiniert eine eingefrorene Qwen3.5-4B-Base-Grundarchitektur mit einem LoRA-Adapter und einem Pointer-Kopf. Die Grundarchitektur hat 32 Schichten, bestehend aus 24 Gated-DeltaNet-Schichten und acht Full-Attention-Schichten. Der Adapter setzt an Attention-, MLP- und DeltaNet-Projektionen an; der Pointer-Kopf bewertet die bereitgestellten Optionen und wandelt diese Werte in Wahrscheinlichkeiten um. Dies ist ein reiner Prefill-Entscheidungsablauf, bei dem die Optionen den Antwortraum bilden.\n\nDrei Fragetypen können in derselben Anfrage vorkommen. Eine choice-Frage akzeptiert 1–255 benannte Optionen, optional mit Beschreibungen, und gibt die wahrscheinlichste Option, einen separaten Konfidenzwert und Wahrscheinlichkeiten für die Optionen zurück. Eine Ja/Nein-Frage, im Format des Herstellers noul genannt, gibt die Ja-Wahrscheinlichkeit zurück. Definieren Sie die Bedeutung von Ja in der Frage, statt anzunehmen, dass eine hohe Zahl immer ein positives Ergebnis für die Anwendung bedeutet.\n\nEine Frage nach einem geordneten Score akzeptiert 1–255 Stufen und gibt Wahrscheinlichkeiten für die Stufen und deren erwarteten Index zurück. Stufenindizes beginnen bei null. Das Ergebnisformat des Herstellers enthält ausserdem die Stufenlegende und einen separaten Konfidenzwert. Ein erwarteter Index kann Nachkommastellen enthalten: Er fasst die Verteilung über Ihre geordneten Stufen zusammen, statt eine neue Textbezeichnung auszuwählen. Bewahren Sie Stufenreihenfolge und Legende beim Ergebnis, damit eine Bewertung einheitlich interpretiert werden kann.\n\nFragen teilen denselben Zustand, werden aber unabhängig bewertet. Eine Frage kann die Antwort einer anderen nicht lesen, und der Zustand wird einmal berechnet und wiederverwendet. Wenn eine spätere Entscheidung von einem Ergebnis einer früheren abhängt, machen Sie diese Abhängigkeit in einem nachfolgenden Zustand ausdrücklich, statt von den Fragen einer Anfrage eine Kette zu erwarten. Dadurch eignet sich der Ablauf mit gemeinsamem Zustand für mehrere unabhängige Prüfungen desselben Dokuments.\n\nBereiten Sie den Zustand mit den Belegen vor, die die Fragen tatsächlich benötigen. Er kann Klartext oder ein als beschrifteter Text dargestelltes JSON-Objekt oder -Array sein. Halten Sie Feldnamen, Einheiten, Richtlinienbedingungen und relevante Quellpassagen klar. Schreiben Sie für jede Frage eine konkrete Anweisung und geben Sie ihren Optionen Bedeutungen, die anhand des Datensatzes unterscheidbar sind. Bei einer ursprünglichen Support-Weiterleitungsaufgabe kann der Zustand die Anfrage und ihren Kontext enthalten, während die Auswahlmöglichkeiten Liefer-, Zugangs- und Produktsupport-Kategorien mit kurzen Beschreibungen definieren.\n\nEine zweite Frage kann die Dringlichkeit bewerten, und eine geordnete Frage kann einschätzen, wie viel Nachverfolgung die Anfrage benötigt. Dies beantwortet unterschiedliche operative Fragen; definieren Sie daher jede separat. Nehmen Sie eine passende Prüf- oder Fehlende-Belege-Option auf, wenn die Auswahlaufgabe sie benötigt, und bewahren Sie die vollständige Verteilung, wenn mehrere Kategorien plausibel sind. Die Anwendung entscheidet über Weiterleitung oder Prüfung eines Ergebnisses; das Modell liefert den bewerteten Datensatz.\n\nKev-4B ist für typisierte Entscheidungen über Dokumente mit einigen Tausend Tokens vorgesehen. Das Bereitstellungsprofil des Herstellers akzeptiert Zustände bis zu 65’536 Tokens und reserviert zusätzlichen Platz für jede Frage, während die validierte Kontextlänge dieses Checkpoints 8192 Tokens beträgt. Dies sind unterschiedliche Grenzen: Die Annahme eines längeren Zustands belegt keine gleich zuverlässigen Entscheidungen bei jeder Länge. Halten Sie entscheidende Passagen kompakt und bewahren Sie ihre Bezeichnungen, wenn Sie einen langen Datensatz zur Klassifikation vorbereiten.\n\nDas veröffentlichte Profil ist englischsprachig. Seine nützlichen Aufgaben hängen von Belegen im bereitgestellten Zustand und den definierten Optionen ab, statt von offenem Chat, Zusammenfassung oder umfassender wissensbasierter Beantwortung. Datumsarithmetik auf Tagesebene ist eine besondere Einschränkung: Der Hersteller liefert einen separaten Vorprozessor für Datumsfakten, der berechnete Intervalle bereitstellt. Nehmen Sie für eine Fristprüfung die relevanten Datumsangaben und berechneten Tagesintervalle zusammen mit der Regel, die sie verwendet, in den Zustand auf.\n\nDer Checkpoint wird mit angepasster Wahrscheinlichkeitskalibrierung ausgeliefert, doch die Konfidenz kann sich mit Dokumentdomäne und Fragengestaltung ändern. Der Hersteller dokumentiert ausserdem das Fine-Tuning des offenen Checkpoints auf aufgabenspezifische Bezeichnungen und die Anpassung seiner Wahrscheinlichkeitskalibrierung an diese Arbeitslast; dies ist ein separater Anpassungsworkflow gegenüber der Bewertung eines bereitgestellten Zustands. Wählen Sie Entscheidungsschwellen anhand gekennzeichneter Beispiele der tatsächlichen Arbeitslast und halten Sie unsichere Fälle für die Prüfung sichtbar. Der Hersteller schliesst vollständig automatisierte folgenreiche Entscheidungen über Menschen ohne menschliche Prüfung aus. Auch die Optionsreihenfolge kann eine Antwort beeinflussen; bewahren Sie daher bei Ergebnisvergleichen eine stabile Reihenfolge. Bewerten Sie die gewählte Bezeichnung, das separate confidence-Feld und die Wahrscheinlichkeitsverteilung entsprechend ihrer jeweiligen Rolle in Ihrem Workflow.\n\nDie vom Hersteller beschriebene aktuelle Kev-4B-Veröffentlichung gehört zu Kev 1.0 und verwendet die Qwen3.5-Basis. Frühere Qwen3-basierte und nur auf die Dokumentstufe beschränkte Veröffentlichungen bleiben eigene Versionen. Halten Sie beim Entwickeln eines aufgabenspezifischen Workflows die gewählte Ausgabe und die Fragendefinitionen mit den Ausgaben verknüpft, statt Ergebnisse unterschiedlicher Profile zu vermischen.\n\nEin nützliches abschliessendes Artefakt ist eine benannte Menge von Entscheidungsdatensätzen mit den ursprünglichen Fragen, Optionsdefinitionen, Verteilungen und gegebenenfalls geordneten Stufenlegenden. Für eine Antwortqualitätsprüfung sollte der Zustand die vorgeschlagene Antwort, die Belege und das geprüfte Kriterium enthalten. Für Richtlinientriage sollte er die geltende Regel und relevante Fakten enthalten. Bewahren Sie diese Eingabe beim Ergebnis, damit eine Prüfung feststellen kann, warum eine Entscheidung angemessen war oder welcher fehlende Fakt ergänzt werden muss.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "ba8db49ea768149daa1837396b66375b7f7520b702b9069fb4b5d971019985e9", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "de-ch", "methods": [ { "html": "jaredpalmer/kev-4bKev-4B bewertet typisierte Fragen zu einem bereitgestellten englischen Dokument und gibt kalibrierte Wahrscheinlichkeiten für die von Ihnen definierten Optionen zurück. Verwenden Sie Ja/Nein-, Auswahl- und geordnete Score-Fragen für Klassifikation, Weiterleitung, Triage und Prüfungen, die eine strukturierte Entscheidung statt generierter Prosa benötigen.
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.
Kev-4B ist ein kompaktes Entscheidungsmodell zur Beantwortung typisierter Fragen über einen bereitgestellten Zustand. Der Zustand ist das bewertete Dokument oder der Datensatz, und jede Frage definiert die Optionen, die das Modell bewerten kann. Sein Ergebnis ist eine Wahrscheinlichkeitsverteilung und ein typisierter Entscheidungsdatensatz, wodurch es für Dokumentklassifikation, Weiterleitung, Triage, Extraktionsauswahl und Prüfungen anhand angegebener Kriterien nützlich ist.
Das Modell kombiniert eine eingefrorene Qwen3.5-4B-Base-Grundarchitektur mit einem LoRA-Adapter und einem Pointer-Kopf. Die Grundarchitektur hat 32 Schichten, bestehend aus 24 Gated-DeltaNet-Schichten und acht Full-Attention-Schichten. Der Adapter setzt an Attention-, MLP- und DeltaNet-Projektionen an; der Pointer-Kopf bewertet die bereitgestellten Optionen und wandelt diese Werte in Wahrscheinlichkeiten um. Dies ist ein reiner Prefill-Entscheidungsablauf, bei dem die Optionen den Antwortraum bilden.
Drei Fragetypen können in derselben Anfrage vorkommen. Eine choice-Frage akzeptiert 1–255 benannte Optionen, optional mit Beschreibungen, und gibt die wahrscheinlichste Option, einen separaten Konfidenzwert und Wahrscheinlichkeiten für die Optionen zurück. Eine Ja/Nein-Frage, im Format des Herstellers noul genannt, gibt die Ja-Wahrscheinlichkeit zurück. Definieren Sie die Bedeutung von Ja in der Frage, statt anzunehmen, dass eine hohe Zahl immer ein positives Ergebnis für die Anwendung bedeutet.
Eine Frage nach einem geordneten Score akzeptiert 1–255 Stufen und gibt Wahrscheinlichkeiten für die Stufen und deren erwarteten Index zurück. Stufenindizes beginnen bei null. Das Ergebnisformat des Herstellers enthält ausserdem die Stufenlegende und einen separaten Konfidenzwert. Ein erwarteter Index kann Nachkommastellen enthalten: Er fasst die Verteilung über Ihre geordneten Stufen zusammen, statt eine neue Textbezeichnung auszuwählen. Bewahren Sie Stufenreihenfolge und Legende beim Ergebnis, damit eine Bewertung einheitlich interpretiert werden kann.
Fragen teilen denselben Zustand, werden aber unabhängig bewertet. Eine Frage kann die Antwort einer anderen nicht lesen, und der Zustand wird einmal berechnet und wiederverwendet. Wenn eine spätere Entscheidung von einem Ergebnis einer früheren abhängt, machen Sie diese Abhängigkeit in einem nachfolgenden Zustand ausdrücklich, statt von den Fragen einer Anfrage eine Kette zu erwarten. Dadurch eignet sich der Ablauf mit gemeinsamem Zustand für mehrere unabhängige Prüfungen desselben Dokuments.
Bereiten Sie den Zustand mit den Belegen vor, die die Fragen tatsächlich benötigen. Er kann Klartext oder ein als beschrifteter Text dargestelltes JSON-Objekt oder -Array sein. Halten Sie Feldnamen, Einheiten, Richtlinienbedingungen und relevante Quellpassagen klar. Schreiben Sie für jede Frage eine konkrete Anweisung und geben Sie ihren Optionen Bedeutungen, die anhand des Datensatzes unterscheidbar sind. Bei einer ursprünglichen Support-Weiterleitungsaufgabe kann der Zustand die Anfrage und ihren Kontext enthalten, während die Auswahlmöglichkeiten Liefer-, Zugangs- und Produktsupport-Kategorien mit kurzen Beschreibungen definieren.
Eine zweite Frage kann die Dringlichkeit bewerten, und eine geordnete Frage kann einschätzen, wie viel Nachverfolgung die Anfrage benötigt. Dies beantwortet unterschiedliche operative Fragen; definieren Sie daher jede separat. Nehmen Sie eine passende Prüf- oder Fehlende-Belege-Option auf, wenn die Auswahlaufgabe sie benötigt, und bewahren Sie die vollständige Verteilung, wenn mehrere Kategorien plausibel sind. Die Anwendung entscheidet über Weiterleitung oder Prüfung eines Ergebnisses; das Modell liefert den bewerteten Datensatz.
Kev-4B ist für typisierte Entscheidungen über Dokumente mit einigen Tausend Tokens vorgesehen. Das Bereitstellungsprofil des Herstellers akzeptiert Zustände bis zu 65’536 Tokens und reserviert zusätzlichen Platz für jede Frage, während die validierte Kontextlänge dieses Checkpoints 8192 Tokens beträgt. Dies sind unterschiedliche Grenzen: Die Annahme eines längeren Zustands belegt keine gleich zuverlässigen Entscheidungen bei jeder Länge. Halten Sie entscheidende Passagen kompakt und bewahren Sie ihre Bezeichnungen, wenn Sie einen langen Datensatz zur Klassifikation vorbereiten.
Das veröffentlichte Profil ist englischsprachig. Seine nützlichen Aufgaben hängen von Belegen im bereitgestellten Zustand und den definierten Optionen ab, statt von offenem Chat, Zusammenfassung oder umfassender wissensbasierter Beantwortung. Datumsarithmetik auf Tagesebene ist eine besondere Einschränkung: Der Hersteller liefert einen separaten Vorprozessor für Datumsfakten, der berechnete Intervalle bereitstellt. Nehmen Sie für eine Fristprüfung die relevanten Datumsangaben und berechneten Tagesintervalle zusammen mit der Regel, die sie verwendet, in den Zustand auf.
Der Checkpoint wird mit angepasster Wahrscheinlichkeitskalibrierung ausgeliefert, doch die Konfidenz kann sich mit Dokumentdomäne und Fragengestaltung ändern. Der Hersteller dokumentiert ausserdem das Fine-Tuning des offenen Checkpoints auf aufgabenspezifische Bezeichnungen und die Anpassung seiner Wahrscheinlichkeitskalibrierung an diese Arbeitslast; dies ist ein separater Anpassungsworkflow gegenüber der Bewertung eines bereitgestellten Zustands. Wählen Sie Entscheidungsschwellen anhand gekennzeichneter Beispiele der tatsächlichen Arbeitslast und halten Sie unsichere Fälle für die Prüfung sichtbar. Der Hersteller schliesst vollständig automatisierte folgenreiche Entscheidungen über Menschen ohne menschliche Prüfung aus. Auch die Optionsreihenfolge kann eine Antwort beeinflussen; bewahren Sie daher bei Ergebnisvergleichen eine stabile Reihenfolge. Bewerten Sie die gewählte Bezeichnung, das separate confidence-Feld und die Wahrscheinlichkeitsverteilung entsprechend ihrer jeweiligen Rolle in Ihrem Workflow.
Die vom Hersteller beschriebene aktuelle Kev-4B-Veröffentlichung gehört zu Kev 1.0 und verwendet die Qwen3.5-Basis. Frühere Qwen3-basierte und nur auf die Dokumentstufe beschränkte Veröffentlichungen bleiben eigene Versionen. Halten Sie beim Entwickeln eines aufgabenspezifischen Workflows die gewählte Ausgabe und die Fragendefinitionen mit den Ausgaben verknüpft, statt Ergebnisse unterschiedlicher Profile zu vermischen.
Ein nützliches abschliessendes Artefakt ist eine benannte Menge von Entscheidungsdatensätzen mit den ursprünglichen Fragen, Optionsdefinitionen, Verteilungen und gegebenenfalls geordneten Stufenlegenden. Für eine Antwortqualitätsprüfung sollte der Zustand die vorgeschlagene Antwort, die Belege und das geprüfte Kriterium enthalten. Für Richtlinientriage sollte er die geltende Regel und relevante Fakten enthalten. Bewahren Sie diese Eingabe beim Ergebnis, damit eine Prüfung feststellen kann, warum eine Entscheidung angemessen war oder welcher fehlende Fakt ergänzt werden muss.
POST /v1/systemonetextdecisions| Feld | Typ | Anforderung | Werte und Limits | Standard |
|---|---|---|---|---|
Feldmodel | Typstring | AnforderungErforderlich | Werte und Limits jaredpalmer/kev-4b | 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. Die Kriterien von choice sind 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 einschliesslich | Gebühr |
|---|---|---|---|---|
| KonfigurationBasistarife für Token | TarifstaffelGrundtarif | Kontexttoken, mehr als— | Kontexttoken, bis einschliesslichKeine Obergrenze | Gebühr Eingabe · Eingabetoken $0.000084 / 1K Tokens Ausgabe · Ausgabetoken $0 / 1K Tokens Eingabe · Cache lesen — / 1K Tokens Eingabe · Cache schreiben — / 1K Tokens Eingabe · Cache schreiben, 1 Stunde — / 1K Tokens |
| KonfigurationAnfragelängenstufe 1 | Tarifstaffel— | Kontexttoken, mehr als0 | Kontexttoken, bis einschliesslichKeine Obergrenze | Gebühr Eingabe · Eingabetoken $0.000084 / 1K Tokens Ausgabe · Ausgabetoken $0 / 1K Tokens Eingabe · Cache lesen — / 1K Tokens Eingabe · Cache schreiben — / 1K Tokens Eingabe · 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 abschliessenden Verbrauchsdatensatzes. So funktionieren Reservierung und Abrechnung →
{\n "model": "jaredpalmer/kev-4b",\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']='jaredpalmer/kev-4b'\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 zu einer Frage-ID bleibt mit ihrem exakten Typ, dem noul/choice/score-Wert, der Konfidenz, den Wahrscheinlichkeiten und der Legende erhalten. Das vollständige 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 jaredpalmer/kev-4b
Verwenden Sie die oben angezeigten Methodenpfade.