Stratégie de versionnage et de rollback des prompts
Les prompts sont du code. Traitez-les avec la même rigueur que les changements applicatifs.
Contrôle de version
- Stockez les prompts dans un data store versionné (par ex. config-profiles).
- Capturez les métadonnées : tenant_id, nom du profil de guidance, langue, auteur, horodatage, résumé du diff.
- Exigez des messages de commit expliquant le changement.
Flux de test
- Brouillon : Modifiez les prompts dans un environnement de staging en utilisant des transcriptions enregistrées pour les tests de régression.
- Revue par les pairs : Faites relire le ton et la conformité par un autre opérateur ou rédacteur.
- Canary : Déployez sur une petite cohorte de tenants ou un environnement interne.
- Surveillance : Suivez la contention, les motifs de fallback et les retours négatifs après le lancement.
- Annotation : Marquez le tableau de bord d’analytics avec l’ID de la nouvelle version du prompt.
Plan de rollback
- Conservez au moins deux versions par tenant : la version actuelle et la précédente.
- Proposez un rollback en un clic dans l’UI d’administration avec journalisation d’audit.
- Avertissez les ops et les tenants concernés lorsqu’un rollback se produit, en particulier dans les secteurs réglementés.
Conseils d’automatisation
- Intégrez les prompts au CI/CD : commitez sur Git, exécutez un linting automatisé et publiez vers config-profiles via des pipelines.
- Déclenchez des scripts Playwright ou de régression qui rejouent les requêtes courantes.
- Utilisez des alertes Google Chat chaque fois que prompt_version change, afin que les parties prenantes sachent qu’elles doivent surveiller les métriques.
Implémentation dans Threada
Threada relie les versions de prompts aux événements d’analytics, à l’historique de rafraîchissement des actifs de connaissance et aux tableaux de bord des motifs de fallback. Copiez cette approche pour garder les modifications de prompts traçables et réversibles.