Kev-4B ist ein kompaktes Entscheidungsmodell zur Beantwortung typisierter Fragen über einen bereitgestellten Zustand. Der Zustand ist das zu bewertende Dokument oder der zu bewertende Datensatz, und jede Frage definiert die Optionen, die das Modell bewerten kann. Sein Ergebnis ist eine Wahrscheinlichkeitsverteilung und ein typisierter Entscheidungsdatensatz; das macht es nützlich für Dokumentklassifikation, Routing, Triage, Extraktionsentscheidungen und Prüfungen anhand festgelegter Kriterien.
Das Modell kombiniert ein eingefrorenes Qwen3.5-4B-Base-Backbone mit einem LoRA-Adapter und einem Pointer-Head. Das Backbone hat 32 Schichten, davon 24 Gated-DeltaNet-Schichten und acht Full-Attention-Schichten. Der Adapter zielt auf Attention-, MLP- und DeltaNet-Projektionen; der Pointer-Head bewertet die bereitgestellten Optionen und wandelt diese Scores in Wahrscheinlichkeiten um. Es handelt sich um einen reinen Prefill-Entscheidungsworkflow, bei dem die Optionen den Antwortraum bilden.
Drei Fragetypen können in derselben Anfrage vorkommen. Eine Auswahlfrage 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 Wahrscheinlichkeit für Ja zurück. Definieren Sie die Bedeutung von Ja in der Frage, statt anzunehmen, dass eine hohe Zahl für die Anwendung immer ein positives Ergebnis bedeutet.
Eine geordnete Score-Frage akzeptiert 1–255 Stufen und gibt Wahrscheinlichkeiten für die Stufen sowie deren erwarteten Index zurück. Die Stufenindizes beginnen bei null. Das Ergebnisformat des Herstellers enthält außerdem die Legende der Stufen und einen separaten Konfidenzwert. Ein erwarteter Index kann Nachkommastellen haben: Er fasst die Verteilung über Ihre geordneten Stufen zusammen, statt eine neue Textbezeichnung auszuwählen. Bewahren Sie Reihenfolge und Legende der Stufen zusammen mit dem Ergebnis auf, damit eine Bewertung konsistent interpretiert werden kann.
Fragen teilen sich denselben Zustand, werden aber unabhängig voneinander ausgewertet. Eine Frage kann die Antwort einer anderen nicht lesen, und der Zustand wird einmal berechnet und wiederverwendet. Hängt eine spätere Entscheidung vom Ergebnis einer früheren ab, machen Sie diese Abhängigkeit in einem nachfolgenden Zustand explizit, statt zu erwarten, dass die Fragen einer Anfrage eine Kette bilden. Dadurch eignet sich der Workflow 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 sein oder ein JSON-Objekt bzw. -Array, das als beschrifteter Text dargestellt wird. Halten Sie Feldnamen, Einheiten, Richtlinienbedingungen und die relevanten Quellpassagen klar. Formulieren Sie für jede Frage eine konkrete Anweisung und geben Sie ihren Optionen Bedeutungen, die sich anhand des Datensatzes unterscheiden lassen. Bei einer eigens konzipierten Aufgabe zum Support-Routing kann der Zustand die Anfrage und ihren Kontext enthalten, während die Auswahlmöglichkeiten die Kategorien Lieferung, Zugriff und Produktsupport mit kurzen Beschreibungen definieren.
Eine zweite Frage kann die Dringlichkeit bewerten, und eine geordnete Frage kann einstufen, wie viel Nachbearbeitung die Anfrage benötigt. Diese beantworten unterschiedliche betriebliche Fragen; definieren Sie daher jede separat. Nehmen Sie eine geeignete Option für Prüfung oder fehlende Belege auf, wenn die Auswahlaufgabe eine benötigt, und bewahren Sie die vollständige Verteilung auf, wenn mehrere Kategorien plausibel sind. Die Anwendung entscheidet, wie ein Ergebnis weitergeleitet oder geprüft wird; das Modell liefert den bewerteten Datensatz.
Kev-4B ist für typisierte Entscheidungen über Dokumente mit einigen tausend Tokens vorgesehen. Das Serving-Profil des Herstellers akzeptiert Zustände mit bis zu 65.536 Tokens und reserviert zusätzlichen Platz für jede Frage, während die validierte Kontextlänge für diesen Checkpoint 8192 Tokens beträgt. Das sind unterschiedliche Grenzen: Dass ein längerer Zustand akzeptiert wird, belegt nicht, dass Entscheidungen bei jeder Länge gleich zuverlässig sind. Halten Sie entscheidende Passagen kompakt und bewahren Sie ihre Beschriftungen, wenn Sie einen langen Datensatz für die Klassifikation vorbereiten.
Das veröffentlichte Profil ist englischsprachig. Seine nützlichen Aufgaben hängen von den Belegen im bereitgestellten Zustand und von den definierten Optionen ab, nicht von offenem Chat, Zusammenfassung oder breiter wissensbasierter Beantwortung. Datumsberechnungen auf Tagesebene sind eine besondere Einschränkung: Der Hersteller stellt einen separaten Präprozessor für Datumsfakten bereit, der berechnete Intervalle liefert. Nehmen Sie bei einer Fristprüfung die relevanten Daten und die 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 der Dokumentdomäne und dem Fragendesign ändern. Der Hersteller dokumentiert außerdem das Fine-Tuning des offenen Checkpoints auf aufgabenspezifische Labels und die Anpassung seiner Wahrscheinlichkeitskalibrierung an diesen Workload; das ist ein vom Bewerten eines bereitgestellten Zustands getrennter Anpassungsworkflow. Wählen Sie Entscheidungsschwellen anhand gelabelter Beispiele des tatsächlichen Workloads und halten Sie unsichere Fälle für die Prüfung sichtbar. Der Hersteller schließt vollständig automatisierte folgenreiche Entscheidungen über Personen ohne menschliche Prüfung aus. Auch die Reihenfolge der Optionen kann eine Antwort beeinflussen; behalten Sie daher eine stabile Reihenfolge bei, wenn Sie Ergebnisse vergleichen. Bewerten Sie das gewählte Label, das separate Konfidenzfeld und die Wahrscheinlichkeitsverteilung entsprechend der Rolle, die jedes davon in Ihrem Workflow spielt.
Das aktuelle, vom Hersteller beschriebene Kev-4B-Release gehört zu Kev 1.0 und verwendet die Qwen3.5-Basis. Frühere Qwen3-basierte Releases und Releases, die nur die Dokumentstufe umfassen, bleiben eigenständige Versionen. Halten Sie die gewählte Edition und die Fragedefinitionen mit den Ausgaben verknüpft, wenn Sie einen aufgabenspezifischen Workflow entwickeln, statt Ergebnisse verschiedener Profile zu vermischen.
Ein nützliches Endartefakt ist ein benannter Satz von Entscheidungsdatensätzen mit den ursprünglichen Fragen, Optionsdefinitionen, Verteilungen und allen Legenden geordneter Stufen. Bei einer Prüfung der Antwortqualität sollte der Zustand die vorgeschlagene Antwort, die Belege und das geprüfte Kriterium enthalten. Bei einer Richtlinien-Triage sollte er die anwendbare Regel und die relevanten Fakten enthalten. Bewahren Sie diese Eingabe neben dem Ergebnis auf, damit eine Prüfung feststellen kann, warum eine Entscheidung angemessen war oder welche fehlende Tatsache noch geliefert werden muss.
", "aboutText": "Kev-4B ist ein kompaktes Entscheidungsmodell zur Beantwortung typisierter Fragen über einen bereitgestellten Zustand. Der Zustand ist das zu bewertende Dokument oder der zu bewertende Datensatz, und jede Frage definiert die Optionen, die das Modell bewerten kann. Sein Ergebnis ist eine Wahrscheinlichkeitsverteilung und ein typisierter Entscheidungsdatensatz; das macht es nützlich für Dokumentklassifikation, Routing, Triage, Extraktionsentscheidungen und Prüfungen anhand festgelegter Kriterien.\n\nDas Modell kombiniert ein eingefrorenes Qwen3.5-4B-Base-Backbone mit einem LoRA-Adapter und einem Pointer-Head. Das Backbone hat 32 Schichten, davon 24 Gated-DeltaNet-Schichten und acht Full-Attention-Schichten. Der Adapter zielt auf Attention-, MLP- und DeltaNet-Projektionen; der Pointer-Head bewertet die bereitgestellten Optionen und wandelt diese Scores in Wahrscheinlichkeiten um. Es handelt sich um einen reinen Prefill-Entscheidungsworkflow, bei dem die Optionen den Antwortraum bilden.\n\nDrei Fragetypen können in derselben Anfrage vorkommen. Eine Auswahlfrage 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 Wahrscheinlichkeit für Ja zurück. Definieren Sie die Bedeutung von Ja in der Frage, statt anzunehmen, dass eine hohe Zahl für die Anwendung immer ein positives Ergebnis bedeutet.\n\nEine geordnete Score-Frage akzeptiert 1–255 Stufen und gibt Wahrscheinlichkeiten für die Stufen sowie deren erwarteten Index zurück. Die Stufenindizes beginnen bei null. Das Ergebnisformat des Herstellers enthält außerdem die Legende der Stufen und einen separaten Konfidenzwert. Ein erwarteter Index kann Nachkommastellen haben: Er fasst die Verteilung über Ihre geordneten Stufen zusammen, statt eine neue Textbezeichnung auszuwählen. Bewahren Sie Reihenfolge und Legende der Stufen zusammen mit dem Ergebnis auf, damit eine Bewertung konsistent interpretiert werden kann.\n\nFragen teilen sich denselben Zustand, werden aber unabhängig voneinander ausgewertet. Eine Frage kann die Antwort einer anderen nicht lesen, und der Zustand wird einmal berechnet und wiederverwendet. Hängt eine spätere Entscheidung vom Ergebnis einer früheren ab, machen Sie diese Abhängigkeit in einem nachfolgenden Zustand explizit, statt zu erwarten, dass die Fragen einer Anfrage eine Kette bilden. Dadurch eignet sich der Workflow 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 sein oder ein JSON-Objekt bzw. -Array, das als beschrifteter Text dargestellt wird. Halten Sie Feldnamen, Einheiten, Richtlinienbedingungen und die relevanten Quellpassagen klar. Formulieren Sie für jede Frage eine konkrete Anweisung und geben Sie ihren Optionen Bedeutungen, die sich anhand des Datensatzes unterscheiden lassen. Bei einer eigens konzipierten Aufgabe zum Support-Routing kann der Zustand die Anfrage und ihren Kontext enthalten, während die Auswahlmöglichkeiten die Kategorien Lieferung, Zugriff und Produktsupport mit kurzen Beschreibungen definieren.\n\nEine zweite Frage kann die Dringlichkeit bewerten, und eine geordnete Frage kann einstufen, wie viel Nachbearbeitung die Anfrage benötigt. Diese beantworten unterschiedliche betriebliche Fragen; definieren Sie daher jede separat. Nehmen Sie eine geeignete Option für Prüfung oder fehlende Belege auf, wenn die Auswahlaufgabe eine benötigt, und bewahren Sie die vollständige Verteilung auf, wenn mehrere Kategorien plausibel sind. Die Anwendung entscheidet, wie ein Ergebnis weitergeleitet oder geprüft wird; das Modell liefert den bewerteten Datensatz.\n\nKev-4B ist für typisierte Entscheidungen über Dokumente mit einigen tausend Tokens vorgesehen. Das Serving-Profil des Herstellers akzeptiert Zustände mit bis zu 65.536 Tokens und reserviert zusätzlichen Platz für jede Frage, während die validierte Kontextlänge für diesen Checkpoint 8192 Tokens beträgt. Das sind unterschiedliche Grenzen: Dass ein längerer Zustand akzeptiert wird, belegt nicht, dass Entscheidungen bei jeder Länge gleich zuverlässig sind. Halten Sie entscheidende Passagen kompakt und bewahren Sie ihre Beschriftungen, wenn Sie einen langen Datensatz für die Klassifikation vorbereiten.\n\nDas veröffentlichte Profil ist englischsprachig. Seine nützlichen Aufgaben hängen von den Belegen im bereitgestellten Zustand und von den definierten Optionen ab, nicht von offenem Chat, Zusammenfassung oder breiter wissensbasierter Beantwortung. Datumsberechnungen auf Tagesebene sind eine besondere Einschränkung: Der Hersteller stellt einen separaten Präprozessor für Datumsfakten bereit, der berechnete Intervalle liefert. Nehmen Sie bei einer Fristprüfung die relevanten Daten und die 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 der Dokumentdomäne und dem Fragendesign ändern. Der Hersteller dokumentiert außerdem das Fine-Tuning des offenen Checkpoints auf aufgabenspezifische Labels und die Anpassung seiner Wahrscheinlichkeitskalibrierung an diesen Workload; das ist ein vom Bewerten eines bereitgestellten Zustands getrennter Anpassungsworkflow. Wählen Sie Entscheidungsschwellen anhand gelabelter Beispiele des tatsächlichen Workloads und halten Sie unsichere Fälle für die Prüfung sichtbar. Der Hersteller schließt vollständig automatisierte folgenreiche Entscheidungen über Personen ohne menschliche Prüfung aus. Auch die Reihenfolge der Optionen kann eine Antwort beeinflussen; behalten Sie daher eine stabile Reihenfolge bei, wenn Sie Ergebnisse vergleichen. Bewerten Sie das gewählte Label, das separate Konfidenzfeld und die Wahrscheinlichkeitsverteilung entsprechend der Rolle, die jedes davon in Ihrem Workflow spielt.\n\nDas aktuelle, vom Hersteller beschriebene Kev-4B-Release gehört zu Kev 1.0 und verwendet die Qwen3.5-Basis. Frühere Qwen3-basierte Releases und Releases, die nur die Dokumentstufe umfassen, bleiben eigenständige Versionen. Halten Sie die gewählte Edition und die Fragedefinitionen mit den Ausgaben verknüpft, wenn Sie einen aufgabenspezifischen Workflow entwickeln, statt Ergebnisse verschiedener Profile zu vermischen.\n\nEin nützliches Endartefakt ist ein benannter Satz von Entscheidungsdatensätzen mit den ursprünglichen Fragen, Optionsdefinitionen, Verteilungen und allen Legenden geordneter Stufen. Bei einer Prüfung der Antwortqualität sollte der Zustand die vorgeschlagene Antwort, die Belege und das geprüfte Kriterium enthalten. Bei einer Richtlinien-Triage sollte er die anwendbare Regel und die relevanten Fakten enthalten. Bewahren Sie diese Eingabe neben dem Ergebnis auf, damit eine Prüfung feststellen kann, warum eine Entscheidung angemessen war oder welche fehlende Tatsache noch geliefert werden muss.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "f3d7380f7acb3860da5b894dd87579505882d29b5a383209055706db61a1bfd6", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "de", "methods": [ { "html": "jaredpalmer/kev-4bKev-4B bewertet typisierte Fragen zu einem bereitgestellten englischsprachigen Dokument und gibt kalibrierte Wahrscheinlichkeiten über die von Ihnen definierten Optionen zurück. Nutzen Sie Ja/Nein-Fragen, Auswahlfragen und geordnete Score-Fragen für Klassifikation, Routing, Triage und Prüfungen, die eine strukturierte Entscheidung statt generierter Prosa erfordern.
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 zu bewertende Dokument oder der zu bewertende Datensatz, und jede Frage definiert die Optionen, die das Modell bewerten kann. Sein Ergebnis ist eine Wahrscheinlichkeitsverteilung und ein typisierter Entscheidungsdatensatz; das macht es nützlich für Dokumentklassifikation, Routing, Triage, Extraktionsentscheidungen und Prüfungen anhand festgelegter Kriterien.
Das Modell kombiniert ein eingefrorenes Qwen3.5-4B-Base-Backbone mit einem LoRA-Adapter und einem Pointer-Head. Das Backbone hat 32 Schichten, davon 24 Gated-DeltaNet-Schichten und acht Full-Attention-Schichten. Der Adapter zielt auf Attention-, MLP- und DeltaNet-Projektionen; der Pointer-Head bewertet die bereitgestellten Optionen und wandelt diese Scores in Wahrscheinlichkeiten um. Es handelt sich um einen reinen Prefill-Entscheidungsworkflow, bei dem die Optionen den Antwortraum bilden.
Drei Fragetypen können in derselben Anfrage vorkommen. Eine Auswahlfrage 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 Wahrscheinlichkeit für Ja zurück. Definieren Sie die Bedeutung von Ja in der Frage, statt anzunehmen, dass eine hohe Zahl für die Anwendung immer ein positives Ergebnis bedeutet.
Eine geordnete Score-Frage akzeptiert 1–255 Stufen und gibt Wahrscheinlichkeiten für die Stufen sowie deren erwarteten Index zurück. Die Stufenindizes beginnen bei null. Das Ergebnisformat des Herstellers enthält außerdem die Legende der Stufen und einen separaten Konfidenzwert. Ein erwarteter Index kann Nachkommastellen haben: Er fasst die Verteilung über Ihre geordneten Stufen zusammen, statt eine neue Textbezeichnung auszuwählen. Bewahren Sie Reihenfolge und Legende der Stufen zusammen mit dem Ergebnis auf, damit eine Bewertung konsistent interpretiert werden kann.
Fragen teilen sich denselben Zustand, werden aber unabhängig voneinander ausgewertet. Eine Frage kann die Antwort einer anderen nicht lesen, und der Zustand wird einmal berechnet und wiederverwendet. Hängt eine spätere Entscheidung vom Ergebnis einer früheren ab, machen Sie diese Abhängigkeit in einem nachfolgenden Zustand explizit, statt zu erwarten, dass die Fragen einer Anfrage eine Kette bilden. Dadurch eignet sich der Workflow 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 sein oder ein JSON-Objekt bzw. -Array, das als beschrifteter Text dargestellt wird. Halten Sie Feldnamen, Einheiten, Richtlinienbedingungen und die relevanten Quellpassagen klar. Formulieren Sie für jede Frage eine konkrete Anweisung und geben Sie ihren Optionen Bedeutungen, die sich anhand des Datensatzes unterscheiden lassen. Bei einer eigens konzipierten Aufgabe zum Support-Routing kann der Zustand die Anfrage und ihren Kontext enthalten, während die Auswahlmöglichkeiten die Kategorien Lieferung, Zugriff und Produktsupport mit kurzen Beschreibungen definieren.
Eine zweite Frage kann die Dringlichkeit bewerten, und eine geordnete Frage kann einstufen, wie viel Nachbearbeitung die Anfrage benötigt. Diese beantworten unterschiedliche betriebliche Fragen; definieren Sie daher jede separat. Nehmen Sie eine geeignete Option für Prüfung oder fehlende Belege auf, wenn die Auswahlaufgabe eine benötigt, und bewahren Sie die vollständige Verteilung auf, wenn mehrere Kategorien plausibel sind. Die Anwendung entscheidet, wie ein Ergebnis weitergeleitet oder geprüft wird; das Modell liefert den bewerteten Datensatz.
Kev-4B ist für typisierte Entscheidungen über Dokumente mit einigen tausend Tokens vorgesehen. Das Serving-Profil des Herstellers akzeptiert Zustände mit bis zu 65.536 Tokens und reserviert zusätzlichen Platz für jede Frage, während die validierte Kontextlänge für diesen Checkpoint 8192 Tokens beträgt. Das sind unterschiedliche Grenzen: Dass ein längerer Zustand akzeptiert wird, belegt nicht, dass Entscheidungen bei jeder Länge gleich zuverlässig sind. Halten Sie entscheidende Passagen kompakt und bewahren Sie ihre Beschriftungen, wenn Sie einen langen Datensatz für die Klassifikation vorbereiten.
Das veröffentlichte Profil ist englischsprachig. Seine nützlichen Aufgaben hängen von den Belegen im bereitgestellten Zustand und von den definierten Optionen ab, nicht von offenem Chat, Zusammenfassung oder breiter wissensbasierter Beantwortung. Datumsberechnungen auf Tagesebene sind eine besondere Einschränkung: Der Hersteller stellt einen separaten Präprozessor für Datumsfakten bereit, der berechnete Intervalle liefert. Nehmen Sie bei einer Fristprüfung die relevanten Daten und die 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 der Dokumentdomäne und dem Fragendesign ändern. Der Hersteller dokumentiert außerdem das Fine-Tuning des offenen Checkpoints auf aufgabenspezifische Labels und die Anpassung seiner Wahrscheinlichkeitskalibrierung an diesen Workload; das ist ein vom Bewerten eines bereitgestellten Zustands getrennter Anpassungsworkflow. Wählen Sie Entscheidungsschwellen anhand gelabelter Beispiele des tatsächlichen Workloads und halten Sie unsichere Fälle für die Prüfung sichtbar. Der Hersteller schließt vollständig automatisierte folgenreiche Entscheidungen über Personen ohne menschliche Prüfung aus. Auch die Reihenfolge der Optionen kann eine Antwort beeinflussen; behalten Sie daher eine stabile Reihenfolge bei, wenn Sie Ergebnisse vergleichen. Bewerten Sie das gewählte Label, das separate Konfidenzfeld und die Wahrscheinlichkeitsverteilung entsprechend der Rolle, die jedes davon in Ihrem Workflow spielt.
Das aktuelle, vom Hersteller beschriebene Kev-4B-Release gehört zu Kev 1.0 und verwendet die Qwen3.5-Basis. Frühere Qwen3-basierte Releases und Releases, die nur die Dokumentstufe umfassen, bleiben eigenständige Versionen. Halten Sie die gewählte Edition und die Fragedefinitionen mit den Ausgaben verknüpft, wenn Sie einen aufgabenspezifischen Workflow entwickeln, statt Ergebnisse verschiedener Profile zu vermischen.
Ein nützliches Endartefakt ist ein benannter Satz von Entscheidungsdatensätzen mit den ursprünglichen Fragen, Optionsdefinitionen, Verteilungen und allen Legenden geordneter Stufen. Bei einer Prüfung der Antwortqualität sollte der Zustand die vorgeschlagene Antwort, die Belege und das geprüfte Kriterium enthalten. Bei einer Richtlinien-Triage sollte er die anwendbare Regel und die relevanten Fakten enthalten. Bewahren Sie diese Eingabe neben dem Ergebnis auf, damit eine Prüfung feststellen kann, warum eine Entscheidung angemessen war oder welche fehlende Tatsache noch geliefert 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. 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.000084 / 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.000084 / 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": "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 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 jaredpalmer/kev-4b
Verwenden Sie die oben angezeigten Methodenpfade.