Nace.AI: Drex v1.5

Drex 1.5 ist das Text-Entscheidungsmodell von Nace.AI. Es bewertet bereitgestellte Fakten anhand geschlossener Fragen und gibt numerische, typisierte Antworten statt einer offenen schriftlichen Antwort zurück. Eine Anfrage kombiniert einen Zustand mit benannten Fragen, und das Ergebnis kennzeichnet jede Antwort mit demselben Fragenamen. So erhält ein Workflow eine konkrete Kategorie, Wahrscheinlichkeit oder Position im Bewertungsraster zur Weiterverarbeitung, während die auf dieses Ergebnis folgende Aktion bei der Anwendung bleibt.

Den Zustand vorbereiten

Der Zustand ist die Information, auf die sich jede Frage bezieht. Drex akzeptiert einen JSON-String, ein Objekt, ein Array, eine Zahl, einen booleschen Wert oder null, wobei das Feld state erforderlich ist. Liefern Sie aussagekräftige Belege, auch wenn null die Validierung des Herstellers besteht. Ein String eignet sich für eine Nachricht, ein Dokument oder ein Transkript; ein Objekt eignet sich für Fakten, die bereits in Felder gegliedert sind. Behalten Sie die Informationen, die die Entscheidung beeinflussen, und lassen Sie bei umfangreichem Material nicht zugehörige Felder weg. Behalten Sie ein stabiles Eingabeformat bei, wenn Sie Wahrscheinlichkeitsschwellen interpretieren, denn eine geänderte Darstellung kann die Antwort ändern.

Drex 1.5 liest ausschließlich Text. Die dokumentierte Schnittstelle weist Bilder, Audio, Video und PDF-Inhalte sowohl im Zustand als auch in den Fragen zurück, einschließlich kodierter Medien und Medieninhaltsobjekte. Erstellen Sie eine Bildbeschreibung, erkannten Dokumenttext oder ein Transkript, bevor Sie dieses Material als Beleg verwenden. Eine Textadresse ist kein abgerufenes Dokument oder Bild: Das Modell kann sie nicht öffnen. Bei einer Support-Anfrage ist der nützliche Zustand die tatsächliche Nachricht samt relevantem Kontext, nicht ein Verweis auf Material, das das Modell nicht erhalten hat.

Ja/Nein-Wahrscheinlichkeit, Auswahl oder Bewertung

Eine Frage vom Typ noul fragt, ob eine Bedingung zutrifft, und gibt eine Zahl von 0 bis 1 zurück, die die geschätzte Wahrscheinlichkeit für Ja darstellt. Definieren Sie die Frage über nicht leere Anweisungen oder mindestens ein nicht leeres Wahr/Falsch-Kriterium. Fragen Sie beispielsweise, ob eine Nachricht eine defekte Funktion meldet, und legen Sie fest, ob langsames Verhalten als defekt gilt. Drex gibt keinen eingebauten Ja/Nein-Schwellenwert vor; der nachgelagerte Workflow entscheidet, wie die Wahrscheinlichkeit zu interpretieren ist.

Eine Frage vom Typ choice wählt ein bereitgestelltes Label aus einer ungeordneten Menge und gibt für jedes Label eine Wahrscheinlichkeit zurück. Die Kriterien sind ein Objekt, dessen Schlüssel die zurückgegebenen Labels sind, wobei jede Beschreibung ein String oder null ist. Verwenden Sie kurze, stabile Schlüssel und beschreiben Sie die Kategoriegrenzen klar. Eine beispielhafte Routing-Aufgabe kann zwischen einem Zugriffsproblem, einem Produktfehler und einer allgemeinen Frage unterscheiden, ergänzt um eine Kategorie „Sonstiges“ für Nachrichten, die nicht passen. Das gewählte Label ist für das Routing nützlich; die Verteilung hilft, Fälle zu erkennen, in denen sich zwei Optionen nur schwer trennen lassen.

Eine Frage vom Typ score verwendet ein geordnetes Array von Stufenbezeichnungen. Die Indizes beginnen bei 0, und der zurückgegebene Score ist die Summe aus jedem Stufenindex multipliziert mit seiner Wahrscheinlichkeit. Er kann daher zwischen benannten Stufen liegen. Legen Sie bei einer Schweregradskala fest, was ein kosmetisches Problem, ein Problem mit Workaround und eine vollständig blockierte Aufgabe voneinander trennt. Das Ergebnis enthält neben dem erwarteten Score auch die Legende der Stufen und die Wahrscheinlichkeiten. Behalten Sie den Score mit Nachkommastellen für Mittelwerte oder Trends; die Auswahl der wahrscheinlichsten Stufe und das Runden des erwarteten Scores beantworten unterschiedliche Fragen.

Gemeinsame Belege und Lesen des Ergebnisses

Der Hersteller erlaubt eine bis 512 Fragen zum selben Zustand. Geben Sie jeder einen nicht leeren, aussagekräftigen Bezeichner wie category oder severity, damit die zugehörige Antwort verständlich ist, ohne eine nummerierte Frage nachschlagen zu müssen. Trennen Sie unabhängige Anliegen in eigene Fragen, statt mehrere Anforderungen in einem unklaren Kriterium zu bündeln. Eine einzige Nachricht kann eine Kategorieauswahl, einen Schweregrad-Score und eine Bedingungsprüfung stützen, die jeweils ihre eigene Bedeutung behalten.

Antworten vom Typ choice und score enthalten die Konfidenz getrennt von ihren Wahrscheinlichkeitsverteilungen. Der Hersteller unterscheidet ausdrücklich zwischen Konfidenz und der höchsten Optionswahrscheinlichkeit; berechnen Sie das eine nicht aus dem anderen. Behalten Sie bei einer Ja/Nein-Entscheidung die rohe Wahrscheinlichkeit zusammen mit dem gewählten Ergebnis. Prüfen Sie bei einer unsicheren Auswahl die konkurrierenden Wahrscheinlichkeiten, statt das gewinnende Label allein als Beleg für Sicherheit zu werten. Legen Sie Prüfschwellen anhand der Folgen eines falsch positiven oder falsch negativen Ergebnisses fest und bewerten Sie sie anhand repräsentativer gelabelter Fälle.

Versions- und Größengrenzen

Drex 1.5 dokumentiert ein Budget von 131.072 Tokens für den Zustand und von 139.264 Tokens pro Zeile. Das Zeilenbudget betrifft den Zustand plus die längste einzelne Frage einschließlich ihrer Anweisungen und Optionen; es ist nicht die Summe aller Fragen der Anfrage. Serialisierter Zustand und Fragen müssen zusammen außerdem in 1.048.576 UTF-8-Bytes passen. Eine Anfrage kann die Byte-Grenze einhalten und dennoch eine Token-Grenze überschreiten. Die ältere Edition 1.0 nennt gesondert 32.768 Tokens sowohl für den Zustand als auch für die Zeile; ihre Grenzen sind daher nicht auf 1.5 zu übertragen.

Nace dokumentiert drex-v1.5 als versionierten Bezeichner des Herstellers, während drex-latest ein beweglicher Alias ist. Halten Sie die vorgesehene Edition explizit fest, wenn ein Workflow von ihren Grenzen abhängt. Eine fehlerhafte Frage, ein fehlender Zustand oder eine zu große Eingabe ist ein Validierungsproblem, das eine korrigierte Eingabe erfordert, keine geänderte Kategorie oder geratene Antwort. Bereiten Sie die Kriterien anhand beobachtbarer Belege vor und bewahren Sie das typisierte Ergebnis, die ursprünglichen Fakten und die Fragedefinition gemeinsam auf. So wird die Entscheidung für Routing, Priorisierung oder Prüfung nutzbar, ohne eine Wahrscheinlichkeit mit einem garantierten Urteil zu verwechseln.