Une voix synthétique a lu un roman en 1 h 58 min : c'est l'outillage autour du modèle qui a cassé
L'auteur d'une série d'articles sur Habr raconte ce qui a cassé lorsqu'une voix synthétique a lu un livre entier : le roman « Merdiven » (« L'Escalier ») de Chamil Aliadine, 16 chapitres, 15 444 mots, 1 h 58 min d'audio. La voix est restée stable pendant les deux heures. Les problèmes se trouvaient dans l'outillage périphérique : découpage en phrases, collage des phrases courtes, rognage des respirations, extraction du texte depuis le fichier, balisage temporel. Le jeu de test de 14 phrases ne les a pas détectés et, dans un cas, n'a pas su distinguer une modification utile d'une modification nuisible. • Le livre : 15 444 mots, 16 chapitres, 1 h 58 min. • Le modèle a tenu la distance ; c'est l'outillage autour qui a flanché. • Le jeu de test court est aveugle aux problèmes du texte long.
Traité par IA depuis Habr AI ; édité par Hamidun News
Une voix synthétique a lu un roman en entier : 16 chapitres, 15 444 mots, 1 h 58 min d'audio. Selon l'auteur de la série d'articles sur Habr, la voix est restée stable pendant les deux heures. Presque toutes les pannes se trouvaient non pas dans le modèle lui-même, mais dans le code qui l'entoure. Le jeu de test de 14 phrases, qui servait à comparer les versions du modèle, n'en a révélé aucune.
Le texte choisi pour l'expérience est le roman de Chamil Aliadine « Merdiven » (« L'Escalier »). C'est le troisième article de la série : le premier contenait un tableau des résultats de la lecture du livre, dans le deuxième l'auteur promettait d'analyser à part ce qui avait cassé sur la longue distance. Il ne divulgue ni les noms des modèles, ni les sources de données, ni les scripts internes, ni les paramètres d'entraînement et de décodage. Le texte se concentre sur les métriques, la méthode de vérification et les erreurs qu'il a commises.
Où ça a réellement cassé
L'auteur recense cinq zones problématiques. Toutes relèvent de l'outillage périphérique, c'est-à-dire de ce qui se passe avant et après la génération du son :
- le découpage du texte en phrases ;
- le collage des phrases courtes ;
- le rognage des respirations ;
- l'extraction du texte depuis le fichier du livre ;
- le balisage temporel.
Pour les ingénieurs qui ont travaillé sur le TTS, la liste est familière. Le modèle reçoit un morceau de texte propre et produit un morceau d'audio propre. Si le texte est coupé à l'encontre du sens, si une réplique courte (« — Non. ») est collée au mauvais voisin ou si une respiration est rognée d'une demi-syllabe, l'auditeur entendra le défaut, alors que les métriques du modèle n'ont pas bougé. Une erreur d'extraction du texte depuis le fichier du livre survient même avant la synthèse : le modèle lira fidèlement ce qu'on lui a fourni.
Pourquoi 14 phrases n'ont rien détecté
La deuxième conclusion de l'auteur est sans doute plus intéressante que la première. Le jeu de 14 phrases de test servait à comparer les versions du modèle et, selon toute apparence, remplissait cette tâche. Mais il ne voyait pas les problèmes de la longue distance. C'est logique : une phrase isolée ne comporte aucune jointure entre phrases, n'exige pas de découper un chapitre et ne vérifie pas comment le balisage temporel s'accumule sur deux heures d'audio.
Il existe aussi un cas plus gênant. Dans un épisode, le jeu de test n'a pas su distinguer une bonne modification d'une modification nuisible. Pour une équipe qui prend des décisions sur la base de tels tests, c'est un signal inquiétant : une métrique qui ne distingue pas l'amélioration de la dégradation se réduit à du bruit.
Les chiffres aident à mesurer l'échelle. 15 444 mots en 118 minutes donnent environ 131 mots par minute, et un chapitre représente en moyenne près de 965 mots et 7 minutes d'audio. Sur une telle distance, les jointures entre fragments sont bien plus nombreuses que dans n'importe quel jeu de test court, et chaque jointure est un point de défaillance potentiel.
Que vérifier dans son pipeline
Le texte suggère des conclusions pratiques, qui ne dépendent d'aucun modèle en particulier.
- Gardez à côté du jeu court au moins une exécution longue : un chapitre ou un livre entier. Le jeu court convient pour comparer des versions du modèle, mais pas pour valider l'ensemble du pipeline.
- Testez l'outillage séparément du modèle : segmentation, collage, rognage des pauses, extraction du texte et balisage temporel. Chaque maillon nécessite ses propres vérifications.
- Commencez l'analyse des défauts par le texte envoyé à la synthèse. S'il contient une erreur, incriminer le modèle n'a aucun sens.
- Vérifiez le test lui-même : s'il ne distingue pas une modification utile d'une modification nuisible, il est trop tôt pour prendre des décisions sur la base de ses résultats.
L'auteur promet de détailler la méthode de vérification dans l'article lui-même, et c'est elle qui constituera la principale valeur du texte. Pour l'instant, l'annonce permet de retenir une chose simple : quand une voix reste stable pendant deux heures d'affilée, la qualité du pipeline dépend du soin apporté à l'assemblage des jointures.
Questions clés sur cet article
Que sait-on sur Où ça a réellement cassé ?
L'auteur recense cinq zones problématiques. Toutes relèvent de l'outillage périphérique, c'est-à-dire de ce qui se passe avant et après la génération du son : le découpage du texte en phrases ; le collage des phrases courtes ; le rognage des respirations ; l'extraction du texte depuis le fichier du livre ; le balisage temporel. Pour les ingénieurs qui ont travaillé sur le TTS, la liste est familière. Le modèle reçoit un morceau de texte propre et produit un morceau d'audio propre. Si le texte est coupé à l'encontre du sens, si une réplique courte (« — Non. ») est collée au
Pourquoi 14 phrases n'ont rien détecté?
La deuxième conclusion de l'auteur est sans doute plus intéressante que la première. Le jeu de 14 phrases de test servait à comparer les versions du modèle et, selon toute apparence, remplissait cette tâche. Mais il ne voyait pas les problèmes de la longue distance. C'est logique : une phrase isolée ne comporte aucune jointure entre phrases, n'exige pas de découper un chapitre et ne vérifie pas comment le balisage temporel s'accumule sur deux heures d'audio. Il existe aussi un cas plus gênant. Dans un épisode, le jeu de test n'a pas su distinguer une bonne modification d'un
Que sait-on sur Que vérifier dans son pipeline ?
Le texte suggère des conclusions pratiques, qui ne dépendent d'aucun modèle en particulier. Gardez à côté du jeu court au moins une exécution longue : un chapitre ou un livre entier. Le jeu court convient pour comparer des versions du modèle, mais pas pour valider l'ensemble du pipeline. Testez l'outillage séparément du modèle : segmentation, collage, rognage des pauses, extraction du texte et balisage temporel. Chaque maillon nécessite ses propres vérifications. Commencez l'analyse des défauts par le texte envoyé à la synthèse. S'il contient une erreur, incriminer le modèl
Access Frontier LLMs & Multimodal AI in One Workspace
Discover NomadNet AI (nomadnet.ai) — unified access to frontier language models, research synthesis, and multimodal workflows.
L'essentiel de l'IA — une fois par semaine
Sept actus qui ont vraiment compté, choisies à la main. Sans bruit ni communiqués.
C'est fait ! Vérifiez votre boîte mail pour la confirmation.