Modes de défaillance de Jev 1.13 : lecture littérale, comptage, dates, indirection et dégradation du contexte

Ce que c'est

TypeSafe publie pour jev-1.13 une page intitulée "jaggedness" qui répertorie les faiblesses connues et propose un contournement pour chacune. Selon le résumé du fournisseur, le modèle est bon pour les jugements de bon sens, assez littéral et peu performant sur les tâches nécessitant une précision numérique ou plusieurs niveaux d’indirection. La liste comprend : la lecture littérale (les termes qui délimitent la portée, les négations et les conditions implicites sont pris au pied de la lettre) ; les mathématiques et les nombres (le comptage n’est pas fiable et l’erreur augmente avec la taille de ce qui est compté ; les couleurs hexadécimales et les représentations de code de bas niveau donnent de moins bons résultats que les noms et les langages de haut niveau ; les espérances de score ne doivent pas servir à reconstituer des grandeurs exactes) ; la comparaison de dates et d’heures (les dates sont lues comme du texte, ce qui rend peu fiables leur classement, le calcul des écarts et la vérification d’appartenance à un intervalle) ; l’indirection (les doubles négations et les questions nécessitant plusieurs étapes de raisonnement réduisent l’exactitude) ; les états volumineux remplis de détails sans pertinence (l’exactitude baisse à mesure que le contenu sans rapport augmente) ; le contenu adversarial (l’état n’est pas considéré comme hostile par défaut, si bien que des instructions injectées ou un texte argumentant pour sa propre classification peuvent infléchir la réponse) ; les instructions et critères contradictoires ; les invariants structurels de bon sens qui ne sont pas respectés ; et la génération, pour laquelle le modèle n’est pas entraîné.

Pourquoi c'est important

Un agent qui délègue un jugement doit savoir quels jugements conserver à sa charge. Le point sur les invariants est le moins évident : la page montre la même question de remboursement posée sous forme de Noul (0.22) et de Choice oui/non (oui 0.01, non 0.99, confiance 0.97), ainsi qu’une question et sa négation sous forme de deux Nouls dont la somme vaut 1.19. Un seuil ajusté pour un type de question ne se transpose pas à un autre, et les questions distinctes ne sont pas contraintes de respecter des identités arithmétiques.

Comment l'appliquer

• Écrire la condition exacte dans les instructions et inclure les cas limites dans les critères ; lorsqu’une mauvaise réponse oblige à expliquer l’intention, cette explication constitue la partie manquante de l’instruction.
• Compter, calculer et comparer les dates dans le code. Pour les dates, extraire les composantes sous forme de Choices parmi des valeurs énumérées (douze mois, trente et un jours, une plage d’années bornée, plus "not stated"), puis les assembler dans le code.
• Filtrer d’abord l’état et n’envoyer que les champs nécessaires à la question ; la limite de contexte est de 64k tokens par requête, mais l’exactitude diminue bien avant que la taille ne devienne le problème.
• Poser chaque décision d’une seule manière et faire respecter les identités dans le code (par exemple, deux indicateurs mutuellement exclusifs ne doivent pas être vrais simultanément).
• Traiter l’état comme des données. Tester des entrées qui argumentent pour leur propre classification avant d’exposer la décision à du contenu non fiable.
• Utiliser un modèle génératif lorsqu’il faut produire du texte ; utiliser le modèle de décision pour choisir parmi des candidats extraits par du code ou par un autre modèle.

Pièges

La page porte sur jev-1.13 et elle est datée ; une version ultérieure peut modifier cette liste, il faut donc la relire avant de supposer qu’un contournement reste nécessaire ou suffisant. Dans la formulation du fournisseur, "Extremely consistent" signifie que des entrées sémantiquement similaires produisent des sorties similaires, pas qu’un invariant particulier est respecté.