Jaggedness de Jev 1.13

Jev n’est pas parfait. Voici quelques aspérités que nous connaissons avec jev-1.13. Beaucoup seront corrigées dans des versions ultérieures.

jev-1.13 est rapide, calibré et doué pour le jugement de bon sens, mais il n’est pas parfait. jev-1.13 donne le meilleur sur les tâches System One. Il peut peiner sur les tâches qui demandent des niveaux d’indirection supplémentaires. Il peut se montrer assez littéral dans sa compréhension. Il peine sur les tâches qui demandent de la précision numérique.

Les modes de défaillance en détail

Lecture littérale

jev-1.13 répond à la question que tu as écrite, pas à celle que tu voulais poser. Les mots de portée, les négations et les conditions implicites sont pris au pied de la lettre. Une question reçoit une réponse fondée sur les mots écrits dans l’instruction, alors qu’une personne aurait peut-être lu l’intention derrière les instructions.

À la place : énonce la condition exacte dans les instructions. Sois précis. Mets les cas limites dans les criteria. Quand tu regardes une réponse fausse et que tu te surprends à expliquer ce que tu voulais vraiment dire, cette explication est la moitié manquante de l’instruction. Là où l’interprétation est inévitable, sépare-la en deux questions littérales et combine-les en code.

Mathématiques et nombres

Jev n’est pas une calculatrice. Nous recommandons vivement d’implémenter toute logique mathématique dans le code. Jev sera meilleur sur les questions sémantiques que sur les questions mathématiques.

Compter

jev-1.13 ne compte pas de façon fiable. Cela couvre les caractères d’un mot, les occurrences d’un terme dans un passage, et les éléments d’une longue liste. Le modèle reconnaît la forme d’une réponse plutôt que de compter, et l’erreur grandit avec la taille de ce qui est compté.

Avant de poser une question de comptage, demande-toi pourquoi le comptage a besoin d’un modèle. Si l’unité est quelque chose qu’une expression régulière ou un parser peut trouver, le comptage appartient au code et le modèle n’a rien à ajouter.

À la place : compte en code. Quand tu veux compter les éléments qui correspondent à certains criteria, itère en code sur les candidats et pose une question pour chacun, puis additionne les réponses toi-même.

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)))

Représentations numériques

jev-1.13 sera meilleur sur les représentations sémantiques que numériques. Par exemple, les questions sur des couleurs utilisant des valeurs hexadécimales seront moins bonnes que celles utilisant les noms anglais. Face à des triplets RGB ou des valeurs hexadécimales, il ne peut pas juger de façon fiable si deux valeurs sont proches.

De même, les questions sur des langages de haut niveau seront meilleures que les questions sur l’assembleur bas niveau, ou sur des instructions encodées en binaire.

À la place : fais la conversion en code et passe soit le nombre calculé, soit un bucket nommé. Garde le modèle pour la partie qui est vraiment un jugement, comme si une couleur se lit comme un avertissement.

Mathématiques avec score

N’utilise pas les sorties de score (par exemple l’espérance et la probabilité) pour calculer la magnitude exacte d’un nombre entre deux niveaux d’un criterion. Tu peux utiliser l’espérance pour vérifier s’il dépasse un seuil donné, mais les niveaux de score de jev-1.13 sont faibles en calibration numérique. Il ne pourra pas t’aider à reconstruire le nombre exact en interpolant entre les deux niveaux les plus proches.

Comparaison de dates et d’heures

jev-1.13 lit les dates comme du texte, pas comme des quantités ordonnées. Demander laquelle de deux dates vient en premier, à quelle distance elles sont, ou si l’une tombe dans une fenêtre n’est pas fiable. Cela empire avec les formats mixtes, les références relatives et les frontières de domaine comme les trimestres, les fenêtres de règlement et les périodes d’acquisition.

À la place : répartis le travail. L’extraction est un jugement, alors donne-la au modèle. L’arithmétique ne l’est pas, alors garde-la dans le code.

Chaque partie d’une date est un petit ensemble fermé : douze mois, trente et un jours possibles, une plage d’années bornée. Cela transforme l’extraction en un Choice sur des options énumérées plutôt qu’un parsing libre, et te donne un endroit où mettre une option explicite « non indiqué » pour qu’une partie manquante soit signalée plutôt que devinée. Le code assemble les parties en une vraie date et prend en charge tout ce qui suit, y compris l’ordre, la durée, le décalage et le jour de la semaine.

Le cookbook Extraction de dates a la version complète, y compris les dates relatives et le gating par confiance.

Indirection

Les instructions qui portent des doubles négations ou une indirection complexe reçoivent des réponses moins fiables. Une question sur une propriété d’une propriété, ou quelque chose qui demande plusieurs sauts de raisonnement, coûte de la précision.

À la place : écris tes instructions aussi directement que possible. Quand c’est possible, identifie par leur nom les parties pertinentes de l’état.

État volumineux chargé de détails non pertinents

La précision baisse quand l’état grossit avec du contenu sans rapport avec la décision. Les détails sans rapport agissent comme un distracteur, et un état volumineux rend plus difficile de dire quelle partie de l’entrée a produit une réponse fausse.

À la place : récupère et filtre d’abord en code, et n’envoie que les champs dont la question a besoin. Quand il n’est pas possible de filtrer dans l’état, tu peux utiliser un Noul pour filtrer par pertinence. Le cookbook Classification de passages RAG a un exemple complet.

Contenu adversarial

L’état est une donnée, et jev-1.13 ne le traite pas comme hostile par défaut. Un contenu écrit pour orienter le modèle de façon adverse, que ce soit une instruction injectée, un cadrage délibérément trompeur, ou un texte qui plaide pour sa propre classification, peut déplacer la réponse. Nous comptons nous améliorer sur ce point à l’avenir.

À la place : sois explicite dans les criteria. Teste ton intégration à fond avant de la déployer auprès de nombreux utilisateurs.

Instructions et criteria contradictoires

Quand les instructions et les criteria demandent des choses différentes, jev-1.13 peut se tromper. La meilleure performance vient d’une formulation claire. Par exemple, un Noul où true correspond à non et false correspond à oui sera moins bon. Vise des instructions qu’une personne moyenne peut lire et comprendre facilement.

À la place : traite les criteria comme un prolongement de l’instruction. Aligne les deux avec un langage clair et précis.

Ordre des options d’un Choice

Dans certains cas, nous avons observé que l’ordre des options d’un Choice peut influencer la réponse, et jev-1.13 penche vers l’option qui vient en premier.

À la place : réordonne les options pour vérifier que la réponse reste cohérente.

Génération

jev-1.13 n’est pas entraîné à générer du texte. Tu peux l’y forcer en enchaînant des questions Choice, mais cela ne marchera pas bien et sera très lent. Pour l’extraction de données, il vaut mieux extraire les options possibles avec une regex ou un modèle génératif et laisser jev-1.13 choisir la bonne extraction.

À la place : quand l’espace des réponses est borné, transforme l’extraction en un Choice sur les options plutôt que de demander la valeur elle-même. Si tu as vraiment besoin de générer du texte… il y a d’autres modèles pour ça.