Un protocole reproductible pour tester la qualité des transcriptions portables

Statut et objectif

Il s’agit d’une méthodologie pré-enregistrée, pas d’un résultat produit. Elle fixe le test avant l’acceptation d’échantillons physiques enregistrés afin que la méthode ne puisse pas être réécrite autour d’un résultat favorable.

La question reste volontairement étroite : une parole capturée par un objet portable peut-elle devenir une transcription fidèle et attribuable ? Le protocole ne note ni résumés, ni tâches, ni mémoires, ni recommandations, car BEFORE.Band ne produit pas ces objets.

1. Figer les scénarios avant le test

Utiliser uniquement des paroles et identités fictives. Publier la version du jeu de données, les transcriptions de référence et le code de notation avant la première mesure. L’anglais, le français et les extraits mixtes doivent rester des strates séparées, sans être fondus dans une moyenne avantageuse.

• Parole d’un seul locuteur en anglais et en français, à débit normal et rapide.
• Échange consenti à deux locuteurs, avec interruptions et tours courts.
• Marche, bruit intérieur et bruit de rue contrôlé.
• Enregistrement long traversant des raccords de transfert ou de traitement.
• Silence et sons non vocaux pour détecter les mots inventés.
• Transfert interrompu, nouvelle tentative et reprise sans texte dupliqué.

2. Mesurer la fidélité, pas le vernis

Comparer la transcription propre actuelle à la référence figée, tout en conservant la version verbatim comme preuve. Une modification de lisibilité compte comme erreur si elle change le sens, l’attribution, l’incertitude, un nombre, un nom ou une négation.

Chaque métrique doit publier son numérateur, son dénominateur et les exécutions manquantes ou échouées. Un score composite unique ne suffit pas à montrer où la transcription a échoué.

• Taux d’erreur de mots et de caractères, par langue et par scénario.
• Cohérence des étiquettes anonymes et erreur d’attribution des locuteurs.
• Couverture des horodatages et erreur temporelle absolue.
• Mots dupliqués ou omis aux raccords et lors des reprises.
• Mots hallucinés pendant le silence ou les sons non vocaux.
• Modifications de sens introduites par le nettoyage prudent.
• Latence totale, échecs de traitement et réussite de la reprise.

3. Conserver un dossier complet de chaque exécution

Relier chaque résultat à l’appareil enregistré, au micrologiciel, aux réglages de capture, aux versions du téléphone et de l’app, au fournisseur et à la version du modèle de transcription, au jeu de test et à la révision du code de notation. Conserver la configuration acoustique et l’historique des échecs.

L’audio fictif brut reste dans l’environnement d’évaluation contrôlé et n’est jamais exposé via MCP, les journaux ou l’analytique. Les preuves publiques comprennent le texte de référence, la sortie transcrite, les mesures agrégées et les métadonnées diagnostiques expurgées nécessaires à la reproduction du score.

4. Séparer les contrôles matériel et fournisseur

Les jeux logiciels peuvent valider la notation et le versionnement des transcriptions, mais pas les performances du microphone, du stockage, du transfert ou de la reprise. Aucun résultat physique n’est valable s’il ne provient pas d’un échantillon enregistré dans la configuration publiée.

Une fiche fournisseur, une démonstration ou un benchmark du prestataire de transcription ne constitue pas une preuve BEFORE.Band. Si le matériel ou le fournisseur change, publier un nouveau résultat au lieu de reporter silencieusement l’ancien score.

5. Publier les échecs avec le score

Le rapport public doit contenir un tableau par scénario, les métriques agrégées et détaillées, des intervalles de confiance lorsque les répétitions le permettent, chaque exécution manquante ou échouée, les limites connues et un journal daté des modifications.

Toute affirmation doit renvoyer directement à la version correspondante du rapport. Les transcriptions corrigées apparaissent comme de nouvelles versions au lieu d’écraser la preuve utilisée pour un résultat antérieur.

• Identifiants de l’appareil, du micrologiciel, du pipeline et des données de test.
• Résultats de chaque scénario pré-enregistré, échecs compris.
• Versions de référence et de sortie pour les données fictives.
• Limites, écarts au protocole et modes d’échec non résolus.
• Date, version du protocole et lien vers tout rapport remplacé.