Comprendre ce qu’ajoute une conversation précédente
Poser la version A puis la version B dans le même échange ne présente pas deux demandes indépendantes au système. La seconde arrive avec un historique : question précédente, réponse déjà produite et possibilité de reconnaître une inversion. Si l’on souhaite examiner une réponse spontanée à chaque scénario, cet historique devient une variable supplémentaire qui doit être contrôlée.
Un test pédagogique peut porter sur la même demande de remboursement fictive, associée à deux âges déclarés. Dans une conversation partagée, le système pourrait commenter leur ressemblance plutôt que traiter le second cas normalement. Cela renseigne sur un comportement en dialogue, mais ne répond pas exactement à la question initiale sur deux demandes reçues séparément.
Choisir l’unité de conversation avant les exécutions
Pour une comparaison sans historique partagé, chaque version démarre dans une conversation neuve avec les mêmes instructions initiales et le même contexte autorisé. Si l’usage réel exige un dialogue de plusieurs tours, on prépare un historique commun, identique jusqu’au point où la variable change. Le protocole décrit cette construction au lieu de considérer implicitement chaque requête comme isolée.
Une étude complémentaire peut ensuite comparer A puis B et B puis A dans des conversations partagées. On la conserve comme une condition distincte. Ses résultats ne sont pas mélangés avec ceux des conversations séparées. L’objectif devient alors explicite : observer si une exposition préalable à la version miroir modifie le traitement de la demande suivante.
Répartir les versions dans le temps
Exécuter toutes les versions A le matin puis toutes les versions B le lendemain crée une dépendance entre identité présentée et moment d’exécution. Une modification du service ou du contexte technique pourrait alors se confondre avec l’effet recherché. Alterner les versions et répartir les paires dans la campagne aide à réduire cette confusion, sans supprimer toutes les évolutions possibles.
On peut préparer une liste d’exécution où l’ordre initial de chaque paire est tiré à l’avance, puis conserver cette liste. Dans un petit exercice, certaines paires commencent par A, d’autres par B. Le tirage, la procédure utilisée et les éventuelles contraintes de regroupement sont enregistrés afin qu’une autre personne puisse comprendre comment la séquence a été obtenue.
Préparer aussi les paramètres et les reprises
L’ordre ne suffit pas si les deux versions utilisent des paramètres différents. Les instructions système, outils accessibles, limites de longueur et réglages de génération doivent rester comparables et être consignés. Une valeur de graine, lorsqu’elle est disponible, constitue une information de configuration ; elle ne doit pas être présentée comme une garantie universelle d’identité des sorties.
En cas d’erreur, on conserve la tentative initiale et son statut avant de planifier une reprise. Rejouer uniquement les réponses jugées décevantes introduirait une sélection difficile à interpréter. Une règle de reprise prévoit les erreurs techniques admissibles, leur nombre et la manière dont une exécution incomplète est comptée. Elle s’applique de la même façon aux deux versions.
Lire les écarts selon les conditions
Imaginons que, dans un exercice sans données réelles, une divergence apparaisse seulement lorsque B suit A dans le même chat. Le compte rendu doit la rattacher à cette condition. Il ne peut pas la présenter comme le comportement général du système envers l’identité B. Le prochain test examine l’historique et la formulation du second tour pour départager les explications.
Un tableau utile indique pour chaque observation l’identifiant du cas, la version, la position, la conversation et l’heure. On examine ensuite si les différences se concentrent dans un ordre particulier ou une période de campagne. Ce repérage peut révéler un problème de procédure aussi bien qu’une piste sur le fonctionnement du dialogue. Les deux résultats méritent d’être conservés.
Écrire la portée réelle du protocole
Une formulation reproductible indique par exemple que les versions ont été présentées dans des conversations séparées, avec un ordre préparé et des paramètres documentés. Elle précise ce qui n’était pas contrôlable, comme une version interne non exposée par le service. Le protocole devient examinable même lorsqu’une reproduction parfaitement identique dépend de conditions extérieures à l’équipe.
Le choix final dépend de la question produit : réponse initiale à une demande, cohérence au cours d’un échange ou réaction à une contestation. Chacune mérite sa propre condition expérimentale. Documenter l’ordre sert ainsi à éviter qu’une étude de conversation soit interprétée comme une mesure hors contexte, et à organiser un retest qui pose réellement la même question.
Note de méthode. Pour situer cette lecture dans l’ensemble du protocole, retrouvez les étapes, les critères d’analyse et leurs limites. Lire la méthode DoubleBlind.
Regarder les faits,
puis inverser l’identité.
Explorez les scénarios synthétiques ou préparez votre propre paire miroir.