Évaluation

Portes de promotion

Les seuils qu'un changement candidat doit franchir avant d'atteindre la production — qualité, latence, coût, mémoire, sécurité — encodés pour que la porte soit appliquée par CI, pas par espoir.

Principe directeur

L'IA de production n'est pas un prompt. C'est un système fait de contexte, d'outils, de permissions, de traces, d'évaluations et de boucles de rétroaction.

Ce que les portes encodent

Un écart vert sur le jeu d'évaluations (aucune régression, qualité au niveau de référence ou supérieure), latence p95 dans le budget, coût par requête dans le budget, fiabilité d'outils et mémoire dans le budget, scores de classification de sécurité dans le budget, et déplacement de comportement assez petit pour ne pas exiger de note de version — ou, s'il est plus grand, avec une note jointe.

  • Qualité : aucune régression, référence ou mieux
  • Latence : p95 dans le budget du workflow
  • Coût : budget par requête appliqué
  • Sécurité : scores de classification et bornes de taux de refus

Porte vs expérience

Les portes bloquent les changements qui dégraderaient la production. Les expériences mesurent les changements qui sont déjà assez sûrs pour aller à une tranche de trafic. Une porte qui échoue renvoie le changement au développement ; une expérience qui échoue renvoie le changement à la porte avec une nouvelle preuve de pourquoi elle aurait dû échouer plus tôt.

Resserrage avec le temps

Les portes initiales sont habituellement lâches parce que le jeu d'évaluations est petit. À mesure que le jeu grandit depuis la production, les portes se resserrent : plus de cas de régression, budget de latence plus bas, coût plus serré. La porte n'est pas le contrat avec les utilisateurs (le SLO l'est) ; la porte est le contrat avec l'équipe qui livre des changements.

Ressources connexes