Control de versiones para prompts
Versionado al estilo de Git, versionado semántico y gestión del registro de cambios de los prompts.
Control de versiones para prompts es una lección gratuita de AI Prompt Engineering en CoddyKit. Esta es la lección 2 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de AI Prompt Engineering, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de AI Prompt Engineering incluye 4 lecciones en total.
¿Por qué usar control de versiones para los prompts?
Los prompts evolucionan continuamente: un pequeño cambio en la redacción puede alterar drásticamente el comportamiento del modelo. Sin control de versiones, los equipos pierden la pista de qué cambió, cuándo y por qué. Tratar los prompts como código permite disponer de historial, rollback, colaboración y atribución de cambios.
Versionado de prompts basado en Git
Almacenar los archivos de prompts en Git es la estrategia de versionado más sencilla. Cada prompt es un archivo de texto plano y los commits de Git capturan cada cambio. Las ramas representan experimentos y las etiquetas marcan las versiones publicadas en producción.
# 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-rc1Versionado semántico de prompts
Adopte el versionado semántico (MAJOR.MINOR.PATCH) adaptado a la semántica de los prompts:
- PATCH (1.0.0 → 1.0.1): corrección de un error tipográfico o cambio de espacios en blanco; la salida no cambia
- MINOR (1.0.0 → 1.1.0): nueva variable opcional o redacción mejorada; compatible con versiones anteriores
- MAJOR (1.0.0 → 2.0.0): nueva variable obligatoria, cambio del formato de salida o cambio de comportamiento 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')) # PATCHFormato del registro de cambios
Cada versión de un prompt debe tener un registro de cambios estructurado para que los equipos entiendan qué cambió y por qué. Siga el formato de Keep a Changelog adaptado a los prompts.
# 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' controlEtiquetado de versiones de producción
Las etiquetas de Git marcan el commit exacto que se implementó en producción. Use etiquetas anotadas para almacenar las notas de la versión junto con la etiqueta. Así resulta fácil reconstruir exactamente qué prompt estaba activo en cualquier momento.
# 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.txtProcedimientos de rollback
Cuando una nueva versión de un prompt provoca una regresión de calidad, el rollback debe ser rápido. Hay dos estrategias: rollback del código (volver a implementar el artefacto anterior) y rollback del registro (cambiar el indicador is_active sin volver a implementar).
# 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 happenedHerramientas para comparar prompts
Revisar los cambios de los prompts requiere herramientas de diff especializadas. El comando git diff normal funciona con texto, pero las herramientas de diff semántico resaltan los cambios estructurales en las variables y las instrucciones.
# 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)Estrategia de ramificación para experimentos con prompts
Adopte las convenciones de ramificación del desarrollo de software para desarrollar prompts:
main— solo prompts listos para producciónexperiment/<name>— variantes de pruebas A/B en desarrollohotfix/<issue>— correcciones urgentes para producciónrelease/<version>— preparación de candidatos de lanzamiento
Exija una revisión de código (Pull Request) antes de fusionar cambios de prompts en main, igual que con el código de la aplicación.
# 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 --tagsValidación automatizada de versiones en CI
Un pipeline de CI para cambios en prompts debe validar automáticamente que el incremento de semver sea correcto, que el registro de cambios esté actualizado, que todas las variables de la plantilla estén documentadas y que la puntuación de evaluación no presente regresiones.
# .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')Inmutabilidad de las versiones etiquetadas
Un principio fundamental: las versiones etiquetadas son inmutables. Una vez etiquetada v2.0.0, su plantilla no debe cambiar nunca. Las correcciones deben incorporarse en versiones nuevas (v2.0.1). Esto garantiza la reproducibilidad: siempre se puede recrear el estado exacto de producción a partir de una etiqueta.
# 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()Vinculación de prompts con resultados de evaluación
Cada versión de un prompt debe estar vinculada a sus resultados de evaluación para que los equipos puedan comparar la calidad entre versiones. Almacene los metadatos de evaluación junto al artefacto de prompt.
# 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)Comprobación rápida
¿Cuándo debe incrementar la versión MAJOR de un prompt?
Resumen del control de versiones
El control de versiones de prompts refleja el control de versiones de software, con adaptaciones específicas para prompts:
- Versionado semántico: PATCH/MINOR/MAJOR indican el impacto del cambio
- Etiquetado de Git: etiquetas anotadas e inmutables para las versiones de producción
- Registros de cambios: historial estructurado por versión para facilitar la auditoría
- Rollback: cambio del indicador del registro (rápido) o git revert (auditable)
- Validación en CI: comprobaciones automatizadas de semver, validación de plantillas y protección contra regresiones en la evaluación
- Inmutabilidad: las versiones etiquetadas nunca cambian; las correcciones siempre crean versiones nuevas
Preguntas frecuentes
¿La lección «Control de versiones para prompts» es gratis?
Sí — el texto completo de «Control de versiones para prompts» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de AI Prompt Engineering, actualiza a CoddyKit PRO. El curso de AI Prompt Engineering incluye 4 lecciones en total.
¿Qué aprenderé en «Control de versiones para prompts»?
Versionado al estilo de Git, versionado semántico y gestión del registro de cambios de los prompts. Practicas AI Prompt Engineering con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar AI Prompt Engineering?
No se requiere experiencia previa. AI Prompt Engineering en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 2 de 4.
¿Cuánto tiempo toma la lección «Control de versiones para prompts»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de AI Prompt Engineering?
Sí. Cada lección de AI Prompt Engineering incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Arquitectura de un registro de prompts
- Control de versiones para prompts
- Estrategias de despliegue y reversión
- Monitorización del rendimiento de prompts en producción