0Pricing
AI Prompt Engineering · Lezione

Controllo versione dei prompt

Versioning in stile Git, semantic versioning e gestione del changelog per i prompt

Controllo versione dei prompt è una lezione AI Prompt Engineering gratuita su CoddyKit. Questa è la lezione 2 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento AI Prompt Engineering, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso AI Prompt Engineering include 4 lezioni in totale.

Perché sottoporre i prompt al controllo versione?

I prompt evolvono continuamente: una piccola modifica al testo può alterare drasticamente il comportamento del modello. Senza il controllo versione, i team perdono traccia di cosa è cambiato, quando e perché. Trattare i prompt come codice consente di ottenere cronologia, rollback, collaborazione e attribuzione delle modifiche.

Versionamento dei prompt basato su Git

Memorizzare i file dei prompt in Git è la strategia di versionamento più semplice. Ogni prompt è un file di testo normale; i commit Git registrano ogni modifica. I branch rappresentano gli esperimenti, mentre i tag contrassegnano le release di produzione.

# 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-rc1

Versionamento semantico dei prompt

Adotti il versionamento semantico (MAJOR.MINOR.PATCH) adattato alla semantica dei prompt:

  • PATCH (1.0.0 → 1.0.1): correzione di un refuso o modifica degli spazi bianchi — output invariato
  • MINOR (1.0.0 → 1.1.0): nuova variabile opzionale o formulazione migliorata — compatibile con le versioni precedenti
  • MAJOR (1.0.0 → 2.0.0): nuova variabile obbligatoria, formato dell'output modificato o modifica incompatibile del comportamento
# 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'))  # PATCH

Formato del changelog

Ogni versione di un prompt dovrebbe avere un changelog strutturato, così che i team comprendano cosa è cambiato e perché. Segua il formato Keep a Changelog adattato ai prompt.

# 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

Contrassegnare le release di produzione

I tag Git identificano il commit esatto distribuito in produzione. Utilizzi tag annotati per memorizzare le note di rilascio insieme al tag. In questo modo è facile ricostruire esattamente quale prompt era attivo in un determinato 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.txt

Procedure di rollback

Quando una nuova versione del prompt causa una regressione della qualità, il rollback deve essere rapido. Esistono due strategie: rollback del codice (ridistribuire il vecchio artefatto) e rollback nel registro (invertire il flag is_active senza una nuova distribuzione).

# 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 happened

Strumenti per il diff dei prompt

La revisione delle modifiche ai prompt richiede strumenti di diff specializzati. Il semplice git diff funziona per il testo, ma gli strumenti di diff semantico evidenziano le modifiche strutturali nelle variabili e nelle istruzioni.

# 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)

Strategia di branching per gli esperimenti sui prompt

Replichi le convenzioni di branching del software nello sviluppo dei prompt:

  • main — solo prompt pronti per la produzione
  • experiment/<name> — varianti A/B in fase di sviluppo
  • hotfix/<issue> — correzioni urgenti per la produzione
  • release/<version> — preparazione della release candidate

Richieda una revisione del codice (Pull Request) prima di unire le modifiche ai prompt in main, proprio come avviene per il codice dell'applicazione.

# 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 --tags

Validazione automatizzata delle versioni in CI

Una pipeline CI per le modifiche ai prompt dovrebbe verificare automaticamente che l'incremento semver sia corretto, che il changelog sia aggiornato, che tutte le variabili del template siano documentate e che il punteggio di valutazione non subisca regressioni.

# .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')

Immutabilità delle versioni contrassegnate

Un principio fondamentale: le versioni contrassegnate sono immutabili. Una volta contrassegnata v2.0.0, il relativo template non deve mai cambiare. Le correzioni devono confluire in nuove versioni (v2.0.1). Questo garantisce la riproducibilità: è sempre possibile ricreare lo stato esatto della produzione a partire da un tag.

# 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()

Collegare i prompt ai risultati della valutazione

Ogni versione di un prompt dovrebbe essere collegata ai relativi risultati di valutazione, così che i team possano confrontare la qualità tra le versioni. Memorizzi i metadati della valutazione insieme all'artefatto 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)

Verifica rapida

Quando è necessario incrementare la versione MAJOR di un prompt?

Riepilogo del controllo versione

Il controllo versione dei prompt ricalca quello del software, con adattamenti specifici per i prompt:

  • Versionamento semantico: PATCH/MINOR/MAJOR indicano l'impatto della modifica
  • Tag Git: tag annotati e immutabili per le release di produzione
  • Changelog: cronologia strutturata per versione, utile per l'audit
  • Rollback: inversione del flag nel registro (rapida) oppure git revert (tracciato tramite audit)
  • Validazione CI: controlli semver automatizzati, validazione dei template e protezioni contro le regressioni nelle valutazioni
  • Immutabilità: le versioni contrassegnate non cambiano mai; le correzioni creano sempre nuove versioni

Domande Frequenti

La lezione «Controllo versione dei prompt» è gratuita?

Sì — il testo completo di «Controllo versione dei prompt» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso AI Prompt Engineering, passa a CoddyKit PRO. Il corso AI Prompt Engineering include 4 lezioni in totale.

Cosa imparerò in «Controllo versione dei prompt»?

Versioning in stile Git, semantic versioning e gestione del changelog per i prompt Eserciti AI Prompt Engineering con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare AI Prompt Engineering?

Non è richiesta alcuna esperienza precedente. AI Prompt Engineering su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 2 di 4.

Quanto tempo richiede la lezione «Controllo versione dei prompt»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione AI Prompt Engineering?

Sì. Ogni lezione AI Prompt Engineering include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Architettura di un prompt registry
  2. Controllo versione dei prompt
  3. Strategie di deployment e rollback
  4. Monitoraggio delle prestazioni dei prompt in produzione
← Torna a AI Prompt Engineering