Architecte système Jev

Jev System Architect

Objectif

Utilisez cette compétence pour déterminer :

1. Si Jev a sa place dans un système
2. Exactement où placer la frontière Jev
3. Quels jugements doivent devenir des questions de type Choice, Score ou Noul
4. Quel état chaque jugement doit voir
5. Quelles questions doivent être exécutées ensemble
6. Comment le code ordinaire doit composer les résultats
7. Comment l'incertitude doit modifier le comportement du système
8. Comment évaluer l'intégration avant la mise en production

Il s'agit avant tout d'une compétence d'architecture et de décomposition.

Pour la syntaxe exacte du SDK, les champs de requête/réponse, les modèles, les limites ou le comportement spécifique à une version de l'API, lisez la documentation TypeSafe actuelle et, lorsqu'elle est disponible, utilisez la compétence d'agent officielle de TypeSafe.

N'inventez pas de champs d'API.

---

Modèle Mental Fondamental

Jev n'est pas l'application.

Jev n'est pas le moteur de workflow.

Jev n'est pas un agent autonome.

L'architecture préférée est :

ÉTAT DE L'APPLICATION
      ↓
questions sémantiques bornées
      ↓
     JEV
      ↓
jugements typés + probabilités
      ↓
CODE D'APPLICATION DÉTERMINISTE
      ↓
acheminer / classer / vérifier / demander / escalader / exécuter

Le modèle fournit un jugement programmable.

Le code possède :

• le flux de contrôle
• les permissions
• les calculs
• les règles déterministes
• la persistance
• les transactions
• les effets de bord
• l'exécution d'outils
• l'autorisation
• l'application des politiques

Utilisez Jev uniquement là où un logiciel standard a besoin d'une compréhension sémantique d'informations non structurées ou ambiguës.

---

Conditions de Déclenchement

Envisagez Jev lorsque le système contient une frontière de la forme :

informations non structurées ou contextuelles
                ↓
     un jugement borné est requis
                ↓
 le logiciel a besoin d'une valeur typée pour continuer

Les candidats solides incluent :

• classification d'intention
• routage sémantique
• décisions de modération
• classification de documents
• vérification de preuves
• vérification de citations
• barrières de sécurité sémantiques
• signaux de risque
• interprétation de messages
• sélection de candidats
• dimensions de classement
• jugements de pertinence
• sentiment ou urgence
• interprétation de demandes utilisateur
• sélection d'outils/fonctions
• extraction à partir d'un ensemble de candidats connu
• filtrage de passages RAG
• tri de workflow
• jugements de qualité
• comparaison politique-cas
• correspondance floue
• alignement d'entités
• décisions d'escalade

Inspectez également le code pour des symptômes tels que :

LLM → prose → analyseur → JSON → validation → nouvelle tentative

ou :

grand arbre d'expressions régulières
très grand classifieur sémantique if/else
classifieur basé sur une invite retournant du JSON arbitraire
boucle d'agent utilisée uniquement pour prendre une décision bornée
modèle de raisonnement coûteux utilisé pour une classification triviale

Ce sont des points d'insertion Jev potentiels.

---

N'utilisez Pas Jev Par Défaut

Privilégiez le code ordinaire pour :

• l'arithmétique
• les dates exactes déjà représentées structurellement
• les recherches en base de données
• les correspondances exactes de chaînes
• les permissions
• l'autorisation
• la validation de schéma
• les règles métier déterministes
• les transformations connues
• le tri de nombres connus
• les opérations cryptographiques
• les analyseurs exacts qui résolvent déjà le problème de manière fiable

Privilégiez un modèle génératif lorsque la sortie requise est fondamentalement ouverte :

• écriture
• résumé
• explication
• remue-méninges
• génération de code
• synthèse longue
• recherche ouverte
• raisonnement multi-étapes

Jev peut soutenir ces systèmes en prenant des décisions bornées autour d'eux, mais il ne doit pas être forcé dans un rôle génératif.

---

Étape 1 — Trouver les Frontières de Jugement

Inspectez le workflow de l'entrée au résultat.

Marquez chaque point où le logiciel demande effectivement :

« J'ai des informations, mais je dois comprendre ce qu'elles signifient avant de savoir quelle voie déterministe emprunter. »

Pour chaque frontière candidate, écrivez :

ÉTAT D'ENTRÉE : Quelles informations existent ?

JUGEMENT : Quelle détermination sémantique est nécessaire ?

SORTIE : Quelle valeur bornée permettrait au code de continuer ?

ACTION : Que fera le code avec la réponse ?

ENJEUX : Que se passe-t-il si le jugement est erroné ?

Ne mettez pas immédiatement en œuvre Jev.

Déterminez d'abord si le code déterministe peut résoudre le problème de manière plus fiable.

---

Étape 2 — Appliquer le Test d'Aptitude Jev

Un jugement est un bon candidat Jev lorsque la plupart de ces conditions sont vraies :

• L'entrée contient du langage naturel ou des données contextuelles.
• La sortie requise peut être bornée.
• Le logiciel a besoin de la réponse par programmation.
• Un humain compétent pourrait porter le jugement rapidement.
• Le jugement peut être décrit explicitement.
• L'incertitude est une information utile.
• Le résultat peut être testé par rapport à des exemples ou des étiquettes.
• Le code peut s'approprier l'action après le jugement.

Soyez sceptique lorsque la tâche nécessite :

• une délibération approfondie
• de longues chaînes de raisonnement
• de nombreuses conclusions intermédiaires dépendantes
• une génération ouverte
• une planification autonome

Décomposez d'abord.

---

Étape 3 — Rendre les Questions Atomiques

Une question Jev doit représenter un jugement cohérent.

MAUVAIS :

Analysez ce client et déterminez si nous devons le rembourser, à quel point il est en colère, si une fraude est probable et quel service doit traiter le dossier.

MEILLEUR :

• topic → Choice
• refund_requested → Noul
• fraud_signal → Noul
• frustration → Score

Composez ensuite ces réponses dans le code.

L'objectif est :

comportement complexe = nombreux petits jugements + composition déterministe

Ne cachez pas la politique de l'application dans une question sémantique géante alors que le code pourrait exprimer cette politique explicitement.

---

Étape 4 — Sélectionner la Primitive Correcte

Choice

À utiliser lorsqu'une seule réponse doit être sélectionnée dans un ensemble défini.

Forme : Lequel ?

Exemples :

• facturation | technique | ventes | compte
• remboursement | rebook | information
• python | javascript | rust | autre

Ajoutez un résultat « autre », « inconnu » ou « aucun » lorsque les options fournies peuvent ne pas couvrir l'entrée.

Noul

À utiliser pour une proposition dont la probabilité d'être vraie est utile.

Forme : Est-ce vrai ?

Exemples :

• Le client demande-t-il un remboursement ?
• Ce passage répond-il à la question de l'utilisateur ?
• Ce message demande-t-il un identifiant ?
• Le CV mentionne-t-il une expérience professionnelle en Python ?

Interprétez la sortie comme la probabilité d'un oui.

N'interprétez pas ~0,5 comme une « intensité moyenne ».

Cela signifie que oui/non sont à peu près également plausibles.

Score

À utiliser lorsque le jugement existe sur une dimension ordonnée.

Forme : Où sur ce spectre défini l'état se situe-t-il ?

Exemples :

• calme / préoccupé / très frustré
• non pertinent / partiellement pertinent / fortement pertinent / réponse directe

Chaque niveau doit décrire une condition sémantique concrète.

Évitez les étiquettes non définies comme mauvais / acceptable / bon / excellent à moins que leur signification ne soit explicitement définie.

---

Étape 5 — Concevoir l'État Délibérément

Envoyez l'état le plus petit qui contient les preuves nécessaires aux questions.

Privilégiez un état structuré :

{
  "ticket": {
    "message": "...",
    "sender": {}
  },
  "customer": {
    "plan": "...",
    "orders": []
  },
  "policy": {
    "refund_policy": "..."
  }
}

plutôt qu'un seul gros bloc de prose.

Principes :

• pertinent > exhaustif
• structuré > aplati
• faits observés > connaissance du modèle supposée
• informations actuelles > connaissances intégrées obsolètes

Gardez les faits observés distinguables des jugements inférés.

Lorsque les questions concernent des champs d'état spécifiques, pointez explicitement vers ces champs.

---

Étape 6 — Diffuser les Questions Indépendantes

Si plusieurs questions peuvent être répondues à partir du même état existant, privilégiez de les poser ensemble.

                    ┌── topic
                    ├── urgency
ÉTAT ── JEV ───────┼── refund_requested
                    ├── frustration
                    └── fraud_signal

Ne créez pas d'appels séquentiels inutiles comme :

Jev → réponse → Jev → réponse → Jev → réponse

quand les trois questions auraient pu être évaluées à partir de l'état d'origine.

Posez des questions spéculatives lorsqu'elles sont peu coûteuses et pourraient être utiles plus tard.

Exemple : category, bug_severity, reproduction_quality, refund_requested, frustration\n Si category = billing, le code ignore simplement les réponses spécifiques aux bogues.

---

Étape 7 — Utiliser Plusieurs Étapes Jev Uniquement pour les Dépendances Réelles

Une deuxième requête Jev est justifiée lorsque la première réponse est nécessaire pour :

• récupérer de nouvelles preuves
• construire un nouvel état
• choisir le prochain ensemble de candidats
• déterminer quelles questions peuvent être posées de manière significative
• parcourir une hiérarchie
• récupérer les documents nécessaires au jugement suivant

Exemple :

ÉTAPE 1  Quelle famille de produits ?
   ↓
code récupère les produits de cette famille
   ↓
ÉTAPE 2  Quel produit exact correspond le mieux ?

Ne sérialisez pas les questions simplement parce que le workflow conceptuellement contient plusieurs étapes.

---

Étape 8 — Garder la Composition dans le Code

Jev produit des signaux sémantiques.

Le code décide ce que ces signaux signifient opérationnellement.

Exemple :

topic = billing
refund_requested = 0.94
frustration = high

Le code d'application peut décider :

if topic == billing:
    route_to_billing()

if refund_requested > REFUND_FLAG_THRESHOLD:
    add_refund_flag()

if frustration > PRIORITY_THRESHOLD:
    increase_priority()

La logique métier doit rester inspectable.

Ne demandez pas à Jev « Que devrait faire l'ensemble de notre application ? » alors que la réponse peut être construite à partir de jugements plus petits.

---

Étape 9 — Traiter l'Incertitude Comme un Signal de Première Classe

Ne traitez jamais la sortie typée comme équivalente à la vérité.

La sortie typée signifie que l'interface est contrainte.

Cela ne signifie pas que le jugement sémantique ne peut pas être erroné.

Pour Choice et Score, inspectez les probabilités et la confiance.

Pour Noul, inspectez directement la probabilité de oui.

Concevez un comportement tel que :

• CERTITUDE ÉLEVÉE → voie automatique
• CERTITUDE MOYENNE → demander confirmation / rassembler plus de preuves / modèle plus fort / signaler pour révision
• FAIBLE CERTITUDE → ne pas deviner / escalader

Les seuils relèvent de la politique de l'application.

Ils doivent refléter le coût des faux positifs/négatifs, la réversibilité, l'impact utilisateur/financier/sécuritaire/réglementaire.

Un seuil copié d'un exemple n'est pas une preuve qu'il est approprié pour ce système.

---

Étape 10 — Adapter les Seuils de Confiance au Risque

N'utilisez pas un seuil de confiance universel.

Exemple :

• show_help_article — faible conséquence
• route_support_ticket — conséquence modérée
• cancel_subscription — conséquence plus élevée
• move_money — conséquence très élevée

Le jugement sémantique peut être identique tandis que la certitude requise et le chemin de confirmation diffèrent.

Pour les actions lourdes de conséquences, Jev devrait généralement informer une frontière de décision contrôlée plutôt qu'autoriser indépendamment l'effet de bord.

---

Étape 11 — Concevoir l'Évaluation Avant l'Automatisation

Avant de mettre en production une frontière Jev, identifiez des cas représentatifs.

Incluez : positifs faciles, négatifs faciles, cas ambigus, cas sans preuve, cas limites, cas adverses, échecs rares mais coûteux.

Enregistrez : état, question, comportement attendu, réponse Jev, probabilités/confiance, action de l'application, résultat de vérité terrain lorsqu'il est disponible.

Évaluez le comportement du système, pas seulement si l'étiquette principale semblait raisonnable.

Pour les systèmes à seuil, mesurez le comportement à plusieurs seuils.

Mesurez particulièrement : couverture / taux d'automatisation, taux de faux positifs, taux de faux négatifs, taux de révision humaine, coût des erreurs, latence, coût.

Ajustez les seuils en utilisant des données réelles du domaine cible.

---

Étape 12 — Centraliser la Politique Jev

Gardez les questions Jev, les critères, les poids et les constantes de seuil faciles à trouver et à réviser.

Préférez une structure telle que :

ai/
  jev/
    questions.*
    thresholds.*
    evaluation/
    client.*

ou la structure équivalente appropriée au projet.

Ne dispersez pas la politique sémantique dans des dizaines de gestionnaires de route.

Les réviseurs humains doivent pouvoir inspecter :

• Que juge Jev ?
• Quelles définitions lui avons-nous données ?
• Quels seuils provoquent quelles actions ?
• Quelles actions sont réversibles ?
• Que se passe-t-il lorsque la confiance est faible ?

---

Étape 13 — Conserver les Jugements Bruts

Lorsque c'est pratique, conservez les sorties brutes utiles séparément de l'action qui en est dérivée.

Par exemple :

refund_probability = 0.91
frustration_score = 1.72
topic = billing
topic_confidence = 0.88

au lieu de stocker uniquement priority = high.

Cela permet de réévaluer les seuils, de changer les poids, d'auditer le comportement, de comparer les versions de modèles, d'enquêter sur les échecs et d'effectuer des analyses en aval.

Ne conservez pas de données sensibles au-delà des exigences légitimes de l'application.

---

Étape 14 — Rechercher Jev Autour de l'IA Générative

Jev est souvent précieux autour d'un LLM plutôt que de le remplacer.

Exemples :

ENTRÉE → barrière Jev → LLM → Jev vérification de citation/qualité → code décide s'il faut retourner

ou :

requête → récupération → Jev jugements de pertinence/injection → contexte sélectionné → modèle de raisonnement

ou :

requête utilisateur → Jev sélection d'intention/fonction → fonction typée déterministe → résultat

Cela peut réduire la quantité de contrôle applicatif confié à un modèle génératif ouvert.

---

Procédure de Révision d'Architecture

Lorsqu'on vous demande de réviser un système existant pour des opportunités Jev :

1. Cartographier le workflow

Identifiez : entrées, étapes déterministes, décisions sémantiques, appels de modèle, analyseurs, routeurs, appels d'outils, effets de bord, points de révision humaine.

2. Produire une carte des opportunités Jev

Pour chaque candidat :

• EMPLACEMENT : Code/module/workflow actuel
• MÉTHODE ACTUELLE : Comment le jugement est fait aujourd'hui
• CANDIDAT JEV : Oui / Non / Peut-être
• POURQUOI : Pourquoi une décision sémantique bornée est ou n'est pas appropriée
• ÉTAT : Preuves minimales requises
• PRIMITIVE : Choice / Score / Noul
• QUESTIONS : Jugements atomiques proposés
• COMPOSITION : Comment le code doit les utiliser
• INCERTITUDE : Que se passe-t-il lorsque la réponse n'est pas claire
• RISQUE : Conséquence d'un jugement erroné
• ÉVALUATION : Comment le valider

3. Prioriser par effet de levier

Privilégiez les opportunités où Jev pourrait remplacer un code sémantique fragile, une analyse LLM répétée, des appels de raisonnement triviaux coûteux, des boucles d'agent non bornées, des classifieurs dupliqués ou une révision manuelle de cas évidents — tout en gardant le comportement du système borné et testable.

4. Recommander le plus petit v

…

[tronqué pour la traduction]