Contrôle de version des prompts
Versionnage de type Git, gestion des versions sémantiques et des journaux de modifications pour les prompts.
Contrôle de version des prompts est une leçon AI Prompt Engineering gratuite sur CoddyKit. Ceci est la leçon 2 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage AI Prompt Engineering, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours AI Prompt Engineering comprend 4 leçons au total.
Pourquoi versionner les invites ?
Les invites évoluent en permanence : une petite modification de formulation peut modifier considérablement le comportement du modèle. Sans contrôle des versions, les équipes ne savent plus ce qui a changé, quand ni pourquoi. Traiter les invites comme du code permet de bénéficier de l’historique, du rollback, de la collaboration et de l’attribution.
Versionnage des invites avec Git
Stocker les fichiers d’invites dans Git est la stratégie de versionnage la plus simple. Chaque invite est un fichier en texte brut ; les validations Git enregistrent chaque modification. Les branches représentent les expérimentations ; les balises marquent les versions de production.
# Initialize a prompt repo
git init prompt-library
cd prompt-library
mkdir -p prompts/summarize-article
# First version
cat > prompts/summarize-article/prompt.txt << 'PROMPT'
Summarize the article in {num_sentences} sentences.
Article:
{article_text}
PROMPT
git add prompts/summarize-article/prompt.txt
git commit -m 'feat(summarize-article): initial prompt v1.0.0'
git tag v1.0.0
# Experiment on a branch
git checkout -b experiment/add-focus-area
# ... edit prompt ...
git commit -m 'feat(summarize-article): add focus_area variable'
git tag v1.1.0-rc1Versionnage sémantique des invites
Adoptez le versionnage sémantique (MAJOR.MINOR.PATCH) adapté à la sémantique des invites :
- PATCH (1.0.0 → 1.0.1) : correction d’une coquille, modification des espaces — sortie inchangée
- MINOR (1.0.0 → 1.1.0) : nouvelle variable facultative, formulation améliorée — rétrocompatible
- MAJOR (1.0.0 → 2.0.0) : nouvelle variable obligatoire, modification du format de sortie, changement de comportement incompatible
# semver.py — helper to validate version bumps
import re
def parse_semver(v):
m = re.match(r'^(\d+)\.(\d+)\.(\d+)$', v)
if not m:
raise ValueError(f'Invalid semver: {v}')
return tuple(int(x) for x in m.groups())
def classify_bump(old, new):
o = parse_semver(old)
n = parse_semver(new)
if n[0] > o[0]:
return 'MAJOR'
elif n[1] > o[1]:
return 'MINOR'
elif n[2] > o[2]:
return 'PATCH'
else:
raise ValueError('New version must be greater than old')
print(classify_bump('1.0.0', '1.1.0')) # MINOR
print(classify_bump('1.1.0', '2.0.0')) # MAJOR
print(classify_bump('2.0.0', '2.0.1')) # PATCHFormat du journal des modifications
Chaque version d’une invite doit disposer d’un journal des modifications structuré afin que les équipes comprennent ce qui a changé et pourquoi. Suivez un format de journal des modifications structuré adapté aux invites.
# CHANGELOG.md for prompts/summarize-article/
## [2.0.0] - 2024-08-10
### Breaking Changes
- Renamed variable 'text' to 'article_text' (update all call sites)
- Output now always includes a headline sentence before the summary
### Changed
- Improved instruction specificity to reduce hallucination rate by ~12%
## [1.1.0] - 2024-07-01
### Added
- New optional variable 'focus_area' to direct summary emphasis
- Fallback instruction when 'focus_area' is not provided
### Changed
- Reworded opening instruction for clarity
## [1.0.0] - 2024-06-01
### Added
- Initial prompt: basic summarization with 'num_sentences' controlÉtiquetage des versions de production
Les balises Git identifient la validation exacte déployée en production. Utilisez des balises annotées pour stocker les notes de version avec la balise. Il devient ainsi facile de reconstituer exactement quelle invite était active à n’importe quel moment.
# Annotated git tag with release notes
git tag -a v2.0.0 -m 'Release 2.0.0
Breaking: renamed variable text -> article_text
Improved: reduced hallucination rate by 12%
Author: alice@company.com
Reviewed-by: bob@company.com'
# Push tags to remote
git push origin --tags
# List all tags with dates
git tag -l --sort=version:refname -n9
# v1.0.0 Initial prompt
# v1.1.0 Add focus_area variable
# v2.0.0 Release 2.0.0 — Breaking: renamed variable ...
# View exact prompt at a tag
git show v1.1.0:prompts/summarize-article/prompt.txtProcédures de rollback
Lorsqu’une nouvelle version d’invite provoque une régression de qualité, le rollback doit être rapide. Deux stratégies sont possibles : rollback du code (redéployer l’ancien artefact) et rollback du registre (inverser l’indicateur is_active sans redéploiement).
# Strategy 1: Registry rollback (fastest — no redeploy needed)
def rollback_prompt(registry, prompt_id, target_version):
print(f'Rolling back {prompt_id} to {target_version}...')
registry.activate_version(prompt_id, target_version)
print(f'Rollback complete. {prompt_id} now serving {target_version}')
# Strategy 2: Git-based rollback with audit trail
# Create a revert commit (do NOT force-push, keep history clean)
git revert HEAD --no-commit # stage the revert
git commit -m 'revert(summarize-article): roll back to v1.1.0 due to quality regression'
git tag v2.0.1-hotfix
# Then trigger re-deployment of the reverted artifact
# This preserves full history — nobody loses track of what happenedOutils de comparaison des invites
L’examen des modifications d’une invite nécessite des outils de comparaison spécialisés. git diff convient au texte, mais les outils de comparaison sémantique mettent en évidence les changements structurels dans les variables et les instructions.
# prompt_diff.py — highlight variable changes between versions
import re
def extract_variables(template):
return set(re.findall(r'\{(\w+)\}', template))
def diff_prompts(old_template, new_template):
old_vars = extract_variables(old_template)
new_vars = extract_variables(new_template)
added = new_vars - old_vars
removed = old_vars - new_vars
kept = old_vars & new_vars
print('Variables added:', added or 'none')
print('Variables removed:', removed or 'none')
print('Variables kept:', kept)
old_lines = set(old_template.splitlines())
new_lines = set(new_template.splitlines())
print('New lines:', new_lines - old_lines)
print('Removed lines:', old_lines - new_lines)
old = 'Summarize in {num_sentences} sentences.\n\n{text}'
new = 'Summarize in {num_sentences} sentences focused on {focus_area}.\n\n{article_text}'
diff_prompts(old, new)Stratégie de branches pour les expériences sur les invites
Reprenez les conventions de branches logicielles pour le développement des invites :
main— uniquement des invites prêtes pour la productionexperiment/<name>— variantes A/B en cours de développementhotfix/<issue>— corrections urgentes en productionrelease/<version>— préparation d’une version candidate
Exigez une revue de code (demande d’intégration) avant de fusionner les modifications d’invites dans main — comme pour le code de l’application.
# Typical prompt development workflow
# 1. Create experiment branch
git checkout -b experiment/tone-formal
# 2. Edit and test prompt locally
python test_prompt.py --prompt prompts/summarize-article/prompt.txt \
--eval-set evals/summarize-100.jsonl
# 3. Open PR with eval results in description
gh pr create --title 'experiment: formal tone improves ROUGE by 8%' \
--body 'Eval results attached. ROUGE-L: 0.61 -> 0.66'
# 4. After approval, merge and tag
git checkout main && git merge experiment/tone-formal
git tag v1.2.0 && git push origin main --tagsValidation CI automatisée des versions
Une chaîne CI dédiée aux modifications d’invites doit vérifier automatiquement que : l’incrément de version sémantique est correct, le journal des modifications est à jour, toutes les variables du modèle sont documentées et le score d’eval ne régresse pas.
# .github/workflows/prompt-ci.yml
# name: Prompt Validation
# on: [pull_request]
# jobs:
# validate:
# runs-on: ubuntu-latest
# steps:
# - uses: actions/checkout@v4
# - name: Check semver bump
# run: python scripts/check_semver.py
# - name: Validate template syntax
# run: python scripts/validate_templates.py
# - name: Run eval suite
# run: python scripts/run_evals.py --threshold 0.95
# scripts/validate_templates.py
import glob, json, sys
errors = []
for f in glob.glob('prompts/**/*.yaml', recursive=True):
with open(f) as fh:
data = fh.read()
if '{' not in data:
errors.append(f'{f}: no variables found (may be intentional — double check)')
if errors:
print('Warnings:', errors)
print('Template validation complete')Immuabilité des versions étiquetées
Un principe fondamental : les versions étiquetées sont immuables. Une fois v2.0.0 étiquetée, son modèle ne doit plus jamais changer. Les corrections doivent être intégrées dans de nouvelles versions (v2.0.1). Cela garantit la reproductibilité : vous pouvez toujours recréer exactement l’état de la production à partir d’une balise.
# Enforce immutability in the registry
def register(self, prompt_id, version, template, ...):
with self.conn.cursor() as cur:
# Check if version already exists
cur.execute(
'SELECT id FROM prompt_versions '
'WHERE prompt_id=%s AND version=%s',
(prompt_id, version)
)
if cur.fetchone():
raise ValueError(
f'Version {version} of {prompt_id} already exists. '
'Versions are immutable. Create a new version instead.'
)
# Proceed with insertion
cur.execute(
'INSERT INTO prompt_versions '
'(prompt_id, version, template, author, tags, model) '
'VALUES (%s, %s, %s, %s, %s, %s)',
(prompt_id, version, template, author, tags, model)
)
self.conn.commit()Association des invites aux résultats d’eval
Chaque version d’une invite doit être associée à ses résultats d’eval afin que les équipes puissent comparer la qualité entre les versions. Stockez les métadonnées d’eval avec l’artefact d’invite.
# Attach eval results to a prompt version
ALTER TABLE prompt_versions ADD COLUMN eval_results JSONB;
# Python: record eval scores
def attach_eval_results(self, prompt_id, version, results):
with self.conn.cursor() as cur:
cur.execute(
'UPDATE prompt_versions SET eval_results=%s '
'WHERE prompt_id=%s AND version=%s',
(json.dumps(results), prompt_id, version)
)
self.conn.commit()
# Example eval results structure
eval_results = {
'dataset': 'cnn-dailymail-100',
'date_run': '2024-08-10',
'metrics': {
'rouge_l': 0.66,
'bertscore_f1': 0.89,
'human_quality_avg': 4.2
},
'sample_size': 100,
'runner': 'alice@company.com'
}
registry.attach_eval_results('summarize-article', '1.2.0', eval_results)Vérification rapide
Quand devez-vous augmenter la version MAJOR d’une invite ?
Synthèse du versionnage
Le contrôle des versions des invites reprend celui des logiciels, avec des adaptations propres aux invites :
- Versionnage sémantique : PATCH/MINOR/MAJOR indiquent l’impact de la modification
- Balisage Git : balises immuables et annotées pour les versions de production
- Journaux des modifications : historique structuré par version pour l’auditabilité
- Rollback : inversion rapide de l’indicateur du registre ou annulation Git avec audit
- Validation CI : vérifications automatisées du versionnage sémantique, validation du modèle et protection contre les régressions d’eval
- Immuabilité : les versions étiquetées ne changent jamais — les corrections créent toujours de nouvelles versions
Questions Fréquemment Posées
La leçon « Contrôle de version des prompts » est-elle gratuite ?
Oui — le texte complet de « Contrôle de version des prompts » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours AI Prompt Engineering, passe à CoddyKit PRO. Le cours AI Prompt Engineering comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Contrôle de version des prompts » ?
Versionnage de type Git, gestion des versions sémantiques et des journaux de modifications pour les prompts. Tu pratiques AI Prompt Engineering avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer AI Prompt Engineering ?
Aucune expérience préalable n'est requise. AI Prompt Engineering sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 2 sur 4.
Combien de temps prend la leçon « Contrôle de version des prompts » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon AI Prompt Engineering ?
Oui. Chaque leçon AI Prompt Engineering inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Architecture d’un registre de prompts
- Contrôle de version des prompts
- Stratégies de déploiement et de restauration
- Surveiller les performances des prompts en production