Entscheidungsprimitive

Wählen Sie das Primitive nach der Antwort, die Ihr Code braucht: Choice wählt aus benannten Optionen, Score bewertet gegen geordnete Stufen, und Noul schätzt die Wahrscheinlichkeit für Ja. Bei einer Support-Anfrage stellen Sie vielleicht die Frage, welches Team sie prüfen soll, wie vollständig eine Antwortentwurf sie beantwortet und ob sie eine Doppelbelastung meldet. Das sind drei verschiedene Urteile, keine austauschbaren Wege, Konfidenz zu messen.

Die Beispiele unten verwenden @system-one-ai/core@0.8.0. Siehe TypeScript SDK installieren und konfigurieren und den gehosteten Schnellstart mit einem ausdrücklich gewählten Modell, oder probieren Sie dieselben Konzepte im Entscheidungs-Playground. Für typisierte Extraktion siehe Clairic-Extraktion.

Bereit für Fragen

Q: Was sind die Entscheidungsprimitive von System One?
A: System One bietet drei Primitive: Choice (eine Option), Score (geordnetes Scoring) und Noul/yes-no (Wahrscheinlichkeit, dass eine Aussage wahr ist).

Q: Was ist Noul?
A: Noul ist das yes-no-Primitiv: Es liefert die Wahrscheinlichkeit, dass eine Bedingung gilt — für Abschlusschecks und binäre Gates.

Nach der benötigten Entscheidung wählen

Beginnen Sie mit der Ausgabe, die Ihre Anwendung verbraucht, nicht mit einem bevorzugten Zahlenformat.

Verwenden Sie Choice, wenn der wichtige Unterschied welche Option ist, Score, wenn es wie viel nach dieser Rubrik ist, und Noul, wenn es wie wahrscheinlich ist, dass genau diese Aussage wahr ist. Ein ja/nein-Choice kann ein Label auswählen, nutzen Sie aber Noul, wenn die nachgelagerte Richtlinie die Wahrscheinlichkeit der positiven Bedingung braucht. Ein niedriger Noul-Wert bedeutet, dass die Bedingung als unwahrscheinlich eingeschätzt wird, nicht dass dem Modell die Konfidenz fehlt.

Wenn mehrere Labels gleichzeitig zutreffen können, definieren Sie für jede Bedingung eine eigene Noul-Frage, statt eine Choice zu erzwingen. Diese Wahrscheinlichkeiten beschreiben getrennte Aussagen; sie sind keine Verteilung über sich ausschließende Kategorien und müssen sich nicht zu eins addieren. Für eine bereits aus autoritativen Anwendungsdaten bekannte Tatsache verwenden Sie diese Daten direkt, statt ein Modell die Tatsache ableiten zu lassen.

Ein Support-Ticket, drei nützliche Urteile

Verwenden Sie diesen gemeinsamen Kontext für die Builder und die kombinierte Anfrage unten:

Customer message: „I was charged twice for the same order.“

Draft reply: „Please send your order number so we can review both charges.“

Diese Tabelle beschreibt die Aufgabe, keine aufgezeichneten Modellergebnisse. Die Frage quality bewertet den bereits in state enthaltenen Entwurf; sie schreibt keine Antwort und bewertet keine von einer anderen Frage erzeugte Antwort. Die Frage duplicate betrifft das, was der Kunde meldet. Ob zwei tatsächlich abgerechnete Belastungen existieren, erfordert Zahlungsdaten, und die Erstattungsfähigkeit erfordert die geltende Richtlinie. Keine dieser Antworten stellt diese Tatsachen fest oder autorisiert eine Aktion.

Sie brauchen nicht für jedes Ticket alle drei Primitive. Fragen Sie nur ab, was der Workflow benötigt. Wechselt die Aufgabe von Antwortqualität zu Ticketdringlichkeit, definieren Sie eine eigene geordnete Dringlichkeitsrubrik; die Wiederverwendung des Qualitätswerts würde die Bedeutung ändern, ohne die Zahl zu ändern.

Gemeinsamer State, unabhängige Fragen

state ist der Kontext für jede benannte Frage einer Anfrage. Ein String, ein JSON-Objekt oder ein Array ist ein gemeinsamer State, kein Stapel unabhängiger Auswertungen. Senden Sie getrennte Aufrufe für unabhängige States. Geben Sie nur die Informationen an, die für die Entscheidung nötig und erlaubt sind.

Jede Frage bewertet diesen gemeinsamen Kontext unabhängig. Eine Antwort wird nicht zur Evidenz für eine andere Frage im selben Aufruf. Hängt ein späteres Urteil von einer früheren Antwort ab, prüfen Sie diese Antwort und senden Sie sie als Kontext in einem weiteren Aufruf mit. „Unabhängig“ beschreibt hier die Frage-Schnittstelle, nicht die Garantie, dass Modellfehler statistisch unabhängig sind.

Core, natives HTTP und Typen des offiziellen Clients

Ein Typ, der null akzeptiert, bedeutet nicht, dass jeder Dienst oder jedes Modell ihn akzeptiert. Ein gewähltes Modell kann nicht leere Instruktionen verlangen, Fragenamen einschränken, null-Beschreibungen ablehnen, mehrere Choice-Optionen verlangen oder Erweiterungen untersagen. Nutzen Sie das aktuelle Modellverzeichnis und den API-Vertrag, nicht den breitesten SDK-Typ, um zu entscheiden, was Sie senden. Die Beispiele verwenden expliziten Text und nicht null Beschreibungen.

Choice: eine benannte Option auswählen

import { choice } from '@system-one-ai/core';

const team = choice('Choose the team that should review this message.', {
  billing: 'Payments and invoices',
  support: 'Technical help',
  review: 'Needs human review or more information',
});

Die Factory erhält 'billing' | 'support' | 'review' als Choice-Typ der Antwort. Halten Sie die Beschreibungen eindeutig, und nehmen Sie eine Review-Option auf, wenn eine erzwungene Kategorie irreführend wäre.

Das folgende ist ein illustratives natives HTTP-Antwortobjekt, kein aufgezeichnetes Ergebnis und nicht der ganze Antwortumschlag:

{
  "type": "choice",
  "choice": "review",
  "probabilities": { "billing": 0.1, "support": 0.2, "review": 0.7 },
  "confidence": 0.5
}

choice benennt eine deklarierte Option. Die native Verteilung nutzt diese Optionsnamen als Schlüssel. confidence ist eine separat gemeldete Statistik, nicht notwendigerweise die Wahrscheinlichkeit der gewählten Option. Beides sind keine universellen Aktionsschwellen. Die gehostete API erlaubt höchstens 255 Choice-Optionen; prüfen Sie das Minimum des gewählten Modells und weitere Limits.

Score: eine geordnete Rubrik verwenden

import { score } from '@system-one-ai/core';

const quality = score('Evaluate how completely this answer addresses the question.', [
  'Does not address the question',
  'Partially addresses the question',
  'Fully addresses the question',
]);

Rubrikpositionen laufen von 0 bis levels - 1. Die gehostete API verlangt 2–10 geordnete Stufen. Eine native Score-Antwort enthält type, score, probabilities, confidence und legend. Die Wahrscheinlichkeits- und Legendekarten verwenden Rubrikindizes als Schlüssel.

Der Score ist das gewichtete Rubrikergebnis, nicht notwendigerweise die wahrscheinlichste ganzzahlige Stufe:

score = sum(levelIndex * probabilityAtThatLevel)
      = (0 * 0.1) + (1 * 0.3) + (2 * 0.6)
      = 1.5

Dieses Rechenbeispiel entspricht der folgenden illustrativen nativen HTTP-Antwort:

{
  "type": "score",
  "score": 1.5,
  "probabilities": { "0": 0.1, "1": 0.3, "2": 0.6 },
  "confidence": 0.3,
  "legend": {
    "0": "Does not address the question",
    "1": "Partially addresses the question",
    "2": "Fully addresses the question"
  }
}

Ein Score von 1,5 ist hier nicht automatisch 75 % richtig und kein Score von 10. Bewahren Sie die Rubrik zusammen mit dem Ergebnis auf. Eine Änderung der Beschreibungen oder ihrer Reihenfolge ändert die Bedeutung und die für Idempotenz verwendete Anfrage.

Elemente mit einer konsistenten Rubrik ordnen

Score liefert eine Bewertung, keine sortierte Liste. Um Kandidatenantworten nach Vollständigkeit zu ordnen, bewerten Sie jeden Entwurf als eigenen State mit derselben Kundennachricht, Frage, geordneten Stufen und demselben gewählten Modell. Sortieren Sie die zurückgegebenen Scores dann im Anwendungscode mit einer expliziten Richtlinie für Gleichstände sowie fehlende oder fehlgeschlagene Ergebnisse. Ein State-Array bleibt ein gemeinsamer Kontext; es ist kein Weg, unabhängige Kandidaten zu stapeln.

Vergleichen Sie Ergebnisse nur innerhalb des definierten Kriteriums. Eine Vollständigkeitsrubrik misst nicht zugleich sachliche Richtigkeit, Tonfall oder Erstattungsfähigkeit. Verwenden Sie dafür eigene Fragen und behandeln Sie eine kleine Score-Differenz nicht als garantierte Reihenfolge. Validieren Sie die Ordnung an repräsentativen Beispielen, bevor Sie sich darauf verlassen. Getrennte Kandidatenauswertungen sind getrennte Aufrufe; berücksichtigen Sie sie in Ihren Credit-Schätzungen.

Boolean / Noul: P(true) schätzen

import { booleanQuestion } from '@system-one-ai/core';

const duplicate = booleanQuestion('Does this message report a duplicate charge?', {
  true: 'The same order was charged more than once',
  false: 'No duplicate charge is reported',
});

Mit dem HTTP-Adapter wandelt das SDK diese Frage von boolean in natives noul um. Eine illustrative HTTP-Antwort lautet:

{ "type": "noul", "noul": 0.8 }

Die entsprechende normalisierte Core-Antwort lautet:

import type { BooleanAnswer } from '@system-one-ai/core';

const answer: BooleanAnswer = { type: 'boolean', probability: 0.8 };

Beide stehen für P(true) zwischen 0 und 1. Ein Wert von 0,8 ist eine geschätzte 80-prozentige Chance, dass die Antwort Ja ist, keine bestätigte Tatsache, kein automatischer Boolean-Wert und keine Konfidenz in einen der beiden Ausgänge. Noul hat kein separates Konfidenzfeld. Ihre Anwendung entscheidet über Schwellen, Nicht-Entscheidung und menschliche Prüfung.

Halten Sie verschiedene Prüfungen getrennt: Das Erkennen einer Erstattungsanfrage stellt die Erstattungsfähigkeit nicht fest. Dafür braucht es Richtlinie und Bestelldaten, nicht nur die Formulierung des Kunden.

Benannte Fragen mit typisierten Antworten kombinieren

In der folgenden Fortsetzung sind team, quality und duplicate die oben definierten Builder; client ist ein konfigurierter SystemOne-Client aus dem SDK-Leitfaden. Dies führt eine echte Auswertung mit dem ausgewählten Dienst und Modell dieses Clients durch:

import { defineQuestions } from '@system-one-ai/core';
import type { Answers } from '@system-one-ai/core';

const questions = defineQuestions({ team, quality, duplicate });
const result = await client.evaluate({
  state: {
    message: 'I was charged twice for the same order.',
    answer: 'Please send your order number so we can review both charges.',
  },
  questions,
});
const answers: Answers<typeof questions> = result.answers;
console.log({
  team: answers.team.choice,
  quality: answers.quality.score,
  duplicateProbability: answers.duplicate.probability,
});

Natives HTTP legt jede Antwort unter den passenden answers-Schlüssel. Core bildet jede Frage ebenfalls auf ihren Antworttyp ab, aber das Ergebnis ist normalisiert, nicht das ursprüngliche HTTP-JSON. Fehlende optionale Verteilungen, Konfidenz oder Tokenzahlen bleiben unbekannt. Nutzen Sie Antwort-Header für gehostete Abbuchungen und Request-IDs, nicht Body-Felder mit ähnlichen Namen.

Limits und Anwendungsrichtlinie

Gehostete Anfragen erlauben bis zu 32 Fragen, bis zu 255 Choice-Optionen und 2–10 Score-Stufen. Die vollständigen UTF-8-Anfragelimits sind modellspezifisch: Jev und HTTP-Modi behalten 64KB (65.536 Bytes); migrierte Clef/Clef-Flash-Einträge erlauben bis zu 13MB (13.631.488 Bytes), einschließlich Bildern. Ein gewähltes Modell kann strengere Limits vorschreiben. Bilder begleiten den gemeinsamen State als separates Top-Level-Array images; siehe Bildeingaben. Das sind Grenzen der gehosteten API, keine Zusagen für jeden direkten SDK-Dienst.

Testen Sie routinemäßige, mehrdeutige, unvollständige und folgenreiche Fälle, bevor Sie automatisieren. Bewerten Sie jede Schwelle an repräsentativen Beispielen und an den Kosten der Fehler, nicht an einer einzigen überzeugenden Antwort. Behandeln Sie fehlende Antworten oder fehlgeschlagene Anfragen als ungeklärt, nicht als Standardzustimmung oder niedrigsten Score.

Eine Wahrscheinlichkeit ist eine Vorhersage, keine Erlaubnis, eine Rückerstattung auszuzahlen, Zugriff zu ändern oder eine Nachricht zu senden. Ihre Anwendung verantwortet Autorisierung, Aktions-Allowlists und erforderliche Bestätigungen. Siehe Entscheidungsschritt in einen Agenten integrieren für den Workflow-Entwurf.

Für den Integrationspfad vergleichen Sie das Open-Source-TypeScript-Entscheidungs-SDK mit der gehosteten Entscheidungs-API und dem aktuellen Modellkatalog. Das SDK kann sich mit Diensten verbinden, die eigene Zugangsdaten und Abrechnung haben; die gehostete API nutzt einen Plattformschlüssel und vorausbezahlte Credits. Für die Kombination beider folgen Sie dem gehosteten SDK-Schnellstart für Zugangsdaten, Modellauswahl und die erste Anfrage.