État pour Jev
Structurez les données que Jev doit évaluer : chaîne, objet ou tableau de textes.
L’état est le contenu que vous demandez à un modèle System One d’évaluer. Il peut s’agir d’un message au support, d’un passage ou de l’instantané actuel d’une application. Vous le transmettez dans le champ state, à côté des questions. Chaque requête évalue un état selon une ou plusieurs questions. Toutes voient le même état et s’exécutent indépendamment. Vous pouvez mélanger Choice, Score et Noul dans cette table. Ne placez pas les questions dans l’état et retirez tout élément inutile au jugement.
Structures autorisées
La forme d’état la plus simple est une chaîne brute : « Ma carte a été débitée deux fois. » Utilisez une chaîne si le cas se résume à un texte. Employez un objet JSON pour des champs nommés, des enregistrements associés ou l’état d’une application, par exemple un message accompagné d’un identifiant de commande. Utilisez un tableau de textes pour une suite de messages ou d’enregistrements. Dans Python, transmettez la chaîne, le dict ou la liste correspondante à client.system_one(state=...).
La page de TypeSafe consacrée à l’état recommande un objet pour la plupart des requêtes, afin que chaque partie porte un nom descriptif. Une conversation avec le support, une commande comportant deux débits capturés et une politique de remboursement peuvent tenir dans un seul objet. Cela reste un état unique. Regroupez les informations liées lorsque la décision exige de les comparer. Ne dissimulez pas une seconde question dans le nom d’un champ.
Jev n’accepte que du texte. L’état doit être une chaîne, un objet JSON ou un tableau de valeurs textuelles. Les images, l’audio et la vidéo ne sont pas pris en charge. L’anglais est la principale langue d’entraînement ; les autres langues, notamment les écritures CJK, sont acceptées avec une précision moindre. Consultez la fiche du modèle pour cette remarque linguistique et excluez les pixels de la requête en les convertissant d’abord en champs.
Séparer le contenu des questions
L’état contient les données et les faits justificatifs. Les questions définissent les jugements. Placez la demande de remboursement et la politique dans l’état, puis demandez si le client a sollicité un remboursement et si la politique l’autorise. Si vous collez la question dans le bloc d’état, Jev répond quand même au champ d’instructions : vous aurez dupliqué le prompt dans un emplacement qui consomme la limite de 32k partagée entre l’état et la question la plus longue.
Un état volumineux rempli de détails inutiles constitue un mode d’échec documenté pour jev-1.13. La précision baisse lorsque du contenu sans rapport détourne le modèle, et un bloc surchargé complique l’identification du champ à l’origine d’une mauvaise réponse. Filtrez d’abord dans le code. N’envoyez que les champs nécessaires à la question. Si le filtrage est impossible, un Noul peut évaluer la pertinence des passages avant le jugement principal, comme dans le guide de TypeSafe consacré au classement des passages RAG.
La longueur du contexte est limitée. Jev 1.13 autorise 64k tokens pour la requête entière et 32k pour l'état plus la question la plus longue. Le fan-out spéculatif regroupe de nombreuses questions courtes autour d'un état restreint. Cette méthode coûte moins cher et gagne en précision par rapport à l'ajout de l'historique complet d'un ticket lorsque seuls le dernier message du client et deux lignes de facturation sont nécessaires.
Une fiche d’assistance comme état
Un objet conforme à la documentation utilise ticket.subject, ticket.messages sous forme de paires from/text, order.id, order.charges avec amount et status, ainsi que refund_policy sous forme de phrase. Le cas du double débit devient alors un ensemble de Nouls et de Choices portant sur cet objet, plutôt qu’une conversation qui doit répéter la politique. Votre code connaît déjà les montants ; Jev détermine si le texte demande un remboursement et si la politique décrite s’applique.
Dans une boucle de jeu comme Doom, l'état est une représentation textuelle structurée du monde, pas une suite d'images. La démo de TypeSafe transmet ce texte à environ 10 requêtes par seconde. Pour Wikiracing, l'état comprend la page et les liens candidats. Pour l'assistant domotique, il comprend la demande de l'utilisateur et la liste des appareils déjà en mémoire. Aucune de ces démos n'envoie de pixels à Jev.
Lorsqu’un champ de votre base de données est numérique, envoyez une catégorie nommée ou une valeur calculée si l’évaluation est sémantique (« cette couleur évoque-t-elle un avertissement ? »), et laissez le calcul hexadécimal au code. jev-1.13 interprète moins bien les triplets RGB et les valeurs hexadécimales que les noms de couleurs en anglais. Le même conseil vaut pour les dates : extrayez leurs composantes avec Choice, puis comparez-les dans le code.
Limites et langues
La fenêtre de requête de 64k couvre l’état et toutes les questions. Celle de 32k couvre l’état et la question la plus longue. Placer dans l’état un PDF de politique de 20k laisse peu de place à l’ensemble des questions et déclenche aussi le mode d’échec dû aux détails inutiles. Effectuez d’abord une recherche, puis envoyez les deux paragraphes nécessaires à l’évaluation.
C’est actuellement en anglais que la précision est la meilleure. Si vos tickets sont en japonais ou en coréen, testez un échantillon, tracez les distributions de confiance de Noul et Choice, puis maintenez une validation humaine jusqu’à ce que ces histogrammes ressemblent à ceux obtenus en anglais. Le modèle acceptera tout de même le texte ; il ne refusera pas silencieusement les écritures CJK.
Les tableaux de texte servent aux séquences, pas à dissimuler un second schéma. Si vous avez besoin de parties nommées, utilisez un objet. Pour un seul bloc, utilisez une chaîne. Insérer l’URL d’une image dans une chaîne ne donne pas de vision à Jev ; cela fournit à Jev un jeton d’URL qu’il risque de mal interpréter. Récupérez et décrivez l’image dans vos processus de traitement, puis envoyez sa description.
Si un champ ne sert qu’à vos journaux, ne l’incluez pas dans l’état. Les identifiants de question fournissent déjà les clés de jointure. L’état doit contenir les éléments qu’examinerait un groupe d’évaluateurs humains. Cette rigueur permet aussi de respecter la limite de 32k pour l’état plus la question la plus longue lorsque le fil du ticket est volumineux.
Des champs nommés valent mieux que des encodages astucieux. order_id, charges[].status et refund_policy sont lisibles par vous comme par Jev. Une chaîne unique concaténant les mêmes informations est autorisée, mais moins efficace. L’objet de ticket d’assistance documenté sert de modèle : ticket, order, policy, puis des questions qui font référence à ces noms.
Supprimez les données personnelles inutiles à la décision. Jev n'est pas entraîné sur les requêtes des clients, mais vos propres journaux les conservent malgré tout. Réduire l'état corrige à la fois un problème de jaggedness et favorise la confidentialité.
Un tableau de texte est une séquence, pas un ensemble d’emplacements nommés. Si vous avez besoin de noms, utilisez un objet.
Sources