Fiche pratique / 04 / L’exécution

Garder la mémoire d’une campagne

Un journal pour relier chaque réponse à une configuration, une paire, un ordre et un incident éventuel.

À quoi sert cette fiche

Une capture d’écran conserve rarement tout ce qui a produit la réponse. Le journal de campagne rassemble les versions, paramètres exposés, conversations et erreurs. Il évite de rapprocher des sorties qui proviennent en réalité de conditions différentes.

Notez ce que vous connaissez, mais aussi ce que l’interface ne permet pas de connaître. Une version non communiquée reste « non communiquée ». Inventer une précision pour compléter une fiche rend la reproduction moins honnête, même si le tableau paraît plus propre.

Comment l’utiliser

1. Figer la fiche de configuration

Décrivez le modèle, la version disponible, les paramètres exposés, le prompt système et les outils. Si une mise à jour intervient, créez une nouvelle entrée de configuration.

2. Conserver chaque exécution

Attribuez des identifiants distincts aux paires et aux réponses. Enregistrez les échecs techniques et les refus sans les remplacer silencieusement par une nouvelle tentative.

3. Relier les écarts aux événements

Lors de l’analyse, vérifiez si un changement coïncide avec une évolution de version, un ordre différent ou un incident. Le journal n’explique pas tout, mais rend ces vérifications possibles.

Le canevas réutilisable

Le texte ci-dessous est un outil de préparation. Les champs à renseigner vous aident à conserver la trace de vos propres choix ; ils ne constituent pas un audit réalisé.

# Journal de campagne

## Fiche de configuration
- ID de configuration :
- Service ou système :
- Version publiée ou identifiant disponible :
- Date et moyen d’accès :
- Prompt système et consignes :
- Paramètres exposés : température, top-p, seed, longueur maximale.
- Outils et contexte disponibles :
- Paramètres inconnus ou non contrôlables :

## Plan fixé avant exécution
- Hypothèses et corpus versionnés :
- Ordres A/B et B/A :
- Conversations séparées :
- Répétitions prévues et justification :
- Règle de traitement des erreurs :

## Une ligne par réponse
| ID exécution | Paire | Version A/B | Répétition | Configuration | Horodatage | Statut |
| --- | --- | --- | --- | --- | --- | --- |
| | | | | | | réponse / refus / erreur |

## Réponse brute
Conserver le texte exact et sa référence dans le stockage prévu. Le journal public ne contient aucun secret ou texte client confidentiel.

## Incident
- Nature et moment de l’incident :
- Tentative conservée :
- Reprise éventuelle et son identifiant :
- Effet sur la comparabilité :

## Changements pendant la campagne
Version, consigne, outil, contexte, paramètres, équipe d’annotation.

## Clôture
Nombre prévu, exécuté, échoué, exclu et analysé. Explication de chaque différence entre ces nombres.
Télécharger la fiche complète en Markdown

Pour approfondir

Changer l’ordre pour savoir ce que l’on compare.

Séparer mémoire de conversation, ordre des versions et évolution du service dans une campagne de paires miroir.

Remonter du constat à la réponse qui le soutient.

Relier cas, configuration, exécution, annotation et conclusion pour permettre une reprise ou une contestation du résultat.

Tout le laboratoire

Une question en tête ?

Articles, cas, outils et parcours. Échap pour fermer.