Jev 1.13: Unebenheiten

Jev ist nicht perfekt. Hier sind einige raue Kanten, die wir bei jev-1.13 kennen. Viele davon werden in späteren Versionen behoben.

jev-1.13 ist schnell, kalibriert und gut im Urteil nach gesundem Menschenverstand, aber nicht perfekt. jev-1.13 ist am besten bei System One-Aufgaben. Bei Aufgaben, die zusätzliche Ebenen der Indirektion erfordern, kann es Schwierigkeiten haben. Es kann in seinem Verständnis recht wörtlich sein. Aufgaben, die numerische Präzision erfordern, bereiten ihm Schwierigkeiten.

Die Fehlermodi im Detail

Wörtliches Lesen

jev-1.13 beantwortet die Frage, die du geschrieben hast, nicht die, die du gemeint hast. Abgrenzende Wörter, Verneinungen und implizite Bedingungen werden wörtlich genommen. Eine Frage wird anhand der Wörter in der Anweisung beantwortet, während ein Mensch vielleicht die Absicht hinter der Anweisung gelesen hätte.

Stattdessen: Formuliere die exakte Bedingung in den instructions. Sei konkret. Lege Grenzfälle in die criteria. Wenn du eine falsche Antwort siehst und anfängst zu erklären, was du eigentlich gemeint hast, ist diese Erklärung die fehlende Hälfte der Anweisung. Wo Interpretation unvermeidbar ist, teile sie in zwei wörtliche Fragen auf und kombiniere sie im Code.

Mathematik und Zahlen

Jev ist kein Taschenrechner. Wir empfehlen dringend, jede mathematische Logik im Code umzusetzen. Jev schneidet bei semantischen Fragen besser ab als bei mathematischen.

Zählen

jev-1.13 zählt nicht zuverlässig. Das betrifft Zeichen in einem Wort, Vorkommen eines Begriffs in einem Abschnitt und Elemente in einer langen Liste. Das Modell erkennt die Form einer Antwort, statt zu zählen, und der Fehler wächst mit der Größe des Gezählten.

Bevor du eine Zählfrage stellst, frage, warum die Zählung überhaupt ein Modell braucht. Wenn die Einheit etwas ist, das ein regulärer Ausdruck oder ein Parser finden kann, gehört die Zählung in den Code, und das Modell hat nichts beizutragen.

Stattdessen: Zähle im Code. Wenn du Elemente zählen willst, die bestimmte criteria erfüllen, iteriere im Code über die Kandidaten und stelle eine Frage pro Element, dann summiere die Antworten selbst.

from typesafe_sdk import Noul, TypeSafeClient

client = TypeSafeClient(model="jev-1.13")
YES = 0.5  # up to you on what you want the threshold to be, depends on your usecase.

items = ["typesafe", "apple", "california", "banana", "likes", "calibration", "orange", "vertex"]

result = client.system_one(
    {"items": items},
    {
        f"item_{i}": Noul(instructions=f"Is `items[{i}]` the name of a fruit?")
        for i in range(len(items))
    },
)

count = sum(result.nouls[f"item_{i}"].noul > YES for i in range(len(items)))

Numerische Darstellungen

jev-1.13 schneidet bei semantischen Darstellungen besser ab als bei numerischen. Zum Beispiel schnitten Fragen über Farben anhand von Hex-Werten schlechter ab als solche mit den englischen Namen. Angesichts von RGB-Tripeln oder Hex-Werten kann es nicht zuverlässig beurteilen, ob zwei Werte nahe beieinanderliegen.

Ebenso schneiden Fragen über höhere Programmiersprachen besser ab als Fragen über niedrige Assemblersprache oder binär codierte Instruktionen.

Stattdessen: Führe die Umrechnung im Code durch und übergib entweder die berechnete Zahl oder einen benannten Wertebereich. Behalte das Modell für den Teil, der wirklich ein Urteil ist, etwa ob eine Farbe als Warnung gelesen wird.

Mathematik mit score

Bitte verwende score-Ausgaben (z. B. Erwartungswert und Wahrscheinlichkeit) nicht, um die exakte Größenordnung einer Zahl zwischen zwei Stufen eines Kriteriums zu berechnen. Du kannst den Erwartungswert verwenden, um zu prüfen, ob er einen bestimmten Schwellenwert überschreitet, aber die Score-Stufen von jev-1.13 sind in der numerischen Kalibrierung schwach. Es wird dir nicht helfen, die exakte Zahl durch Interpolation zwischen den beiden nächstgelegenen Stufen zu rekonstruieren.

Datums- und Zeitvergleich

jev-1.13 liest Datumsangaben als Text, nicht als geordnete Größen. Zu fragen, welches von zwei Daten zuerst kommt, wie weit sie auseinanderliegen oder ob eines in ein Fenster fällt, ist unzuverlässig. Es wird schlimmer bei gemischten Formaten, relativen Bezügen und Domänengrenzen wie Quartalen, Abrechnungsfenstern und Abgrenzungszeiträumen.

Stattdessen: Teile die Arbeit auf. Extraktion ist ein Urteil, gib sie also dem Modell. Arithmetik ist keines, behalte sie also im Code.

Jeder Teil eines Datums ist eine kleine geschlossene Menge: zwölf Monate, einunddreißig mögliche Tage, ein begrenzter Bereich von Jahren. Das macht die Extraktion zu einem Choice über aufgezählte Optionen statt zu freier Analyse, und es gibt dir einen Platz für eine ausdrückliche Option „nicht genannt“, damit ein fehlender Teil gemeldet statt geraten wird. Der Code setzt die Teile zu einem echten Datum zusammen und verantwortet alles danach, einschließlich Reihenfolge, Dauer, Versatz und Wochentag.

Das Cookbook zur Datumsextraktion enthält die ausgearbeitete Version, einschließlich relativer Daten und Konfidenz-Gating.

Indirektion

Anweisungen mit doppelten Verneinungen oder komplexer Indirektion werden weniger zuverlässig beantwortet. Eine Frage über eine Eigenschaft einer Eigenschaft oder etwas, das mehrere Schlussfolgerungsschritte erfordert, kostet Genauigkeit.

Stattdessen: Schreibe deine Anweisungen so direkt wie möglich. Benenne, wenn möglich, die relevanten Teile des Zustands.

Großer Zustand voller irrelevanter Details

Die Genauigkeit sinkt, wenn der Zustand mit Inhalt wächst, der für die Entscheidung irrelevant ist. Irrelevantes Detail wirkt als Ablenkung, und ein großer Zustand macht es schwerer zu erkennen, welcher Teil der Eingabe eine falsche Antwort erzeugt hat.

Stattdessen: Filtere zuerst im Code und sende nur die Felder, die die Frage braucht. Wenn es nicht möglich ist, im Zustand zu filtern, kannst du einen Noul verwenden, um nach Relevanz zu filtern. Das Cookbook zur Klassifikation von RAG-Abschnitten hat ein ausgearbeitetes Beispiel.

Adversarialer Inhalt

Der Zustand sind Daten, und jev-1.13 behandelt ihn standardmäßig nicht als feindlich. Inhalt, der geschrieben wurde, um das Modell adversarisch zu steuern, sei es eine eingeschleuste Anweisung, eine bewusst irreführende Rahmung oder ein Text, der für seine eigene Klassifikation argumentiert, kann die Antwort verschieben. Wir erwarten, dies in Zukunft zu verbessern.

Stattdessen: Sei ausdrücklich in den criteria. Teste deine Integration gründlich, bevor du sie vielen Nutzern ausrollst.

Widersprüchliche Anweisungen und criteria

Wenn die instructions und die criteria Unterschiedliches verlangen, kann jev-1.13 verwirrt werden. Die beste Leistung kommt von klarer Formulierung. Zum Beispiel wird ein Noul, bei dem true auf Nein und false auf Ja abbildet, schlechter abschneiden. Strebe Anweisungen an, die ein Durchschnittsmensch leicht lesen und verstehen kann.

Stattdessen: Behandle die criteria als Erweiterung der Anweisung. Bringe beide mit klarer und präziser Sprache in Einklang.

Reihenfolge der Choice-Optionen

In manchen Fällen haben wir beobachtet, dass die Reihenfolge der Optionen eines Choice die Antwort beeinflussen kann, und jev-1.13 neigt zur Option, die zuerst kommt.

Stattdessen: Ordne die Optionen neu und prüfe, ob die Antwort konsistent bleibt.

Generierung

jev-1.13 ist nicht darauf trainiert, Text zu erzeugen. Du kannst es zwar durch Verketten von Choices dazu zwingen, aber das wird nicht gut funktionieren und sehr langsam sein. Für die Datenextraktion ist es besser, mögliche Optionen mit einem regulären Ausdruck oder einem generativen Modell zu extrahieren und jev-1.13 die korrekte Extraktion auswählen zu lassen.

Stattdessen: Wenn der Antwortraum begrenzt ist, verwandle die Extraktion in einen Choice über die Optionen, statt nach dem Wert selbst zu fragen. Wenn du wirklich Text erzeugen musst … dafür gibt es andere Modelle.