En tant que partie de l’inventaire des outils AI, j’ai commencé à jouer avec Amazon Q Developer. C’est accédé en tant qu’extension dans Visual Studio Code, et il est semble-t-il gratuit. Il fournit à la fois une fenêtre de chat et un commandement d’édition en ligne.
Je me suis lancé dans une expérience simple : générer des images d’héroïne pour les articles. Bien que je fusse un peu sceptique que les images générées par l’IA puissent sentir trop “faites par l’IA”, j’ai adopté l’esprit de “stop faisant des choses manuellement, utilisez l’IA”. Avec ce mindset, j’ai demandé à Amazon Q de créer un script qui prend un slug d’article et produit une image d’héroïne. Il l’a réussie au premier essai. J’ai copié le code généré, exécuté le script et—réussite ! Le script a appelé DALL·E 3, a généralement une image basée sur le contenu de l’article et l’a enregistrée dans le système de fichiers. J’étais impressionné—et de plus, j’ai trouvé que je n’avais plus rien à accomplir !
Alors, je pense : “Qu’est-ce si j’avais un bouton ‘écoute de l’article’ en haut des articles utilisant la reconnaissance vocale - TTS ?”. Je tape ma requête.
Juste comme avec le auto-hero.ts script généré par Amazon Q, il a créé un script auto-tts.ts fonctionnel d’abord tir, puisqu’il a tenté d’utiliser les produits AWS d’Amazon pour l’instant. J’ai demandé de rester avec la reconnaissance vocale d’OpenAI pour l’instant.
La transcription brute était, compte tenu des cinq minutes que j’avais passes pour arriver à ce point, plutôt bonne.
Le premier problème est qu’utiliser le fichier mdx comme source signifie que le code comme import X from package Y était lu. J’ordonne à Amazon Q d’ignorer l’article page servie par le serveur Astro au lieu de cela. Cela résulte en une solution à 80% bonne, mais quelques éléments dans les 20% m’étaient un peu perturbants. Il serait agréable si mes mots italiques et gras avaient un énoncé vocal. De plus, les listes étaient un peu difficiles à suivre.
Demandant à ChatGPT, il m’explique qu’il existe quelque chose appelé le langage de synthèse vocale (SSML). Cette syntaxe est XML comme :
<speak>
<emphasis level="strong">Ce qui suit est mis en évidence.</emphasis>
<break time="500ms"/> <!-- Ajoute une pause de 500 millisecondes -->
Vous pouvez <prosody pitch="high" rate="slow">changer le pitch et la vitesse de parole</prosody> pour un effet dramatique.
Ou <prosody volume="x-loud">augmenter le volume</prosody> pour souligner un point.
</speak>Malheureusement, ChatGPT hallucine que OpenAI “évidemment” supporte SSML, ce qui nous mène dans une fausse piste. Pour supporter SSML, il faut préserver certains balises HTML lors de l’agrégation du contenu de l’article et les convertir en SSML. J’ai un peu perdu dans les bruyines là-bas. Amazon Q semblait déterminé à rester avec des mécanismes de traversal d’abreuve complète, et j’ai dû le lui demander de se calmer et d’utiliser un épurateur HTML. Enfin, je suis parvenu à obtenir une SSML qui ressemble à quelque chose.
Cet audio est un peu bizarre. Il y a des petits passages, ce que j’écoute en réalisant qu’ils sont de certaines décisions aléatoires de la reconnaissance vocale pour attacher attention aux tags SSML et d’autres fois juste les lire verbatim. Ce n’est pas du tout supporter SSML ! Effectivement, les documents de reconnaissance vocale d’OpenAI que j’ai lus par moi-même, humainement, disent clairement qu’il accepte uniquement le texte. Dommage.
Peut-être que je ne vais pas abandonner encore. Je vais essayer la suggestion d’Amazon Q d’utiliser la reconnaissance vocale AWS appelée Polly, qui supporte SSML après tout. Amazon Q génère un fichier auto-tts-aws.ts fonctionnel en deux temps, ciblant Polly, et il s’avère que j’ai des clés API AWS en réserve, nous sommes prêts…
…sauf que Polly, utilisant la voix standard, sonne comme si elle venait de l’âge sombre comparativement à la voix alloy d’OpenAI. Le bon côté est qu’elle prend en compte les tags SSML. Le mauvais côté est qu’il est même pire que la voix alloy, sonnant ironiquement plus métallique et mécanique. Je décide de retourner à OpenAI pour l’instant, avec le plein savoir que le texte brut est tout ce que nous pouvons fournir.
Le texte brut peut ne pas être complètement sans expression, toutefois. J’pose qu’il s’il y a quelque chose écrit en majuscules alors peut-être que la reconnaissance vocale d’OpenAI fera some emphasis. Rapportez-vous à l’éthos derrière ces modèles, si le modèle était parfait il ferait ce que tout humain ferait en lisant le même texte. C’est pourquoi, même avec ces tags SSML précédemment, elle n’a pas officiellement compris parfois qu’elle s’arrêterait lorsque voit un tag de pause. Je procède à convertir les balises em et strong en majuscules. Le résultat : oui effectivement l’audio a réagi très bien, au moins à la première écoute ! Un risque à considérer : il pourrait penser qu’il lit une abréviation dans certains cas. Le temps dira.
Nous avons des fichiers audio mais nous devons avoir un bouton en haut des articles pour dire “écoute de cet article”. J’ai demandé à Amazon Q de me livrer ce widget de lecture audio. Une fois encore, il l’a fait avec succès. Les visuals se sentent un peu insuffisants, car j’ai en tête les boutons de lecture audio que j’ai vus autour avec l’onde d’audio derrière eux, un peu comme les morceaux vocaux sur Apple Messages ou WhatsApp.
Cela devient un point d’achoppement. Je ne suis pas encore entraîné pour utiliser l’IA pour générer des UI de qualité, et de plus il semble que ce que j’avais en tête n’est pas courant ou facilement recherché, et je ne me rappelle pas les sites où j’ai vu cela.
Je prends un pas en arrière et réfléchis : en tant que développeur, j’ai souvent eu le sentiment de justifier prendre son temps pour perfectionner des choses, mais dans l’ère de l’IA et d’être plus missionnellement orienté, peut-être que parfois je vais juste avoir à accepter les choses comme “bonnes enough”. Nous pouvons toujours les améliorer plus tard, mais la rapidité est importante. Avec cette perspective fraîche, Amazon Q a basically réussi si j’en suis honnête. Nous avons un widget de lecture audio parfaitement suffisant.
Nous avançons bien, mais un point évident non traité est les choses comme les images commentées et les blocs de code. Au niveau des images, il semble que ce soit tout à fait acceptable d’ignorer leur existence pour l’instant, mais pour les blocs de code, ils ne se traduisent pas naturellement en audio. Il serait idéal d’avoir quelque chose comme un texte alternatif pour eux dans la version audio, spécifié dans le fichier mdx.
Je me suis perdu dans les bruyines là-bas encore une fois. Car nous générons le texte de reconnaissance vocale à partir de la page Astro rendue, nous avons besoin d’une façon de ajouter le texte alternatif à l’élément HTML tel que cela ne modifiera pas visuellement l’article, mais qu’on puisse le pick up dans le script auto-tts.ts. Comment résoudre cela ?
Au début, j’ai pensé que les commentaires HTML était la solution idéale, mais il est difficile de générer des commentaires HTML à partir de MDX qui est effectivement JSX ou dynamiquement à partir de composants Astro. Enfin, je me suis décidé pour un élément HTML custom <tts alt="TTS" /> avec une propriété “alt”. Le navigateur ignorera la balise lorsque rendra le document, mais elle sera toujours là pour notre script. Parfait.
J’ai également conçu un syntaxe pour ajouter facilement des textes alternatifs à des blocs de code multiline où tout triple backtick suivi d’un point-virgule et d’un texte string sera automatiquement converti en élément <tts alt="TTS" />. De plus, n’importe quel élément <tts alt="TTS" /> directement précédant un bloc de code retirera le bloc de code.
{/* syntaxe de blocs de code multiline */}
```tsx : ceci est une alternative pour l'audio
<div>
code jamais à être entendu
</div>
```
{/* syntaxe inline */}
<tts alt="texte alternatif audio" />`code jamais à être entendu`J’ai travaillé avec l’ajout de ces annotations audio au article “In Search of a True Hero” (recherche d’un vrai héros). Cela va vraiment loin pour transformer la version audio en un flux naturel. Malgré ces améliorations, convertir d’une médium à l’autre naturellement semble difficile. Surtout lorsque le premier medium, dans ce cas l’article écrit, n’a pas été conçu avec l’audio en tête originellement.
Le “bouton ‘écoute de l’article’” n’est pas le seul format audio cible non plus. Depuis le début de ce projet, j’ai eu l’idée de convertir ces articles en un format podcast. Cela semblerait une barre encore plus élevée que juste un bouton “écoute de l’article”, car les podcasts ont généralement un ton bien produit qui met la bonne ambiance pour le contenu sous-jacent à être livré. J’ai demandé à ChatGPT d’essayer de convertir un article en un ton podcast, mais cela est tout à fait une demande trop haute. Probablement quelque chose à aborder plus tard lorsqu’on regardera directement les podcasts.
Un aperçu de réflexion est que garder en tête tous ces moyens d’expression prévus lorsque l’on écrit le contenu pourrait aider à améliorer la sortie. L’idéal serait d’écrire une fois et de livrer partout, mais cela sera un exploration continue sur comment c’est possible.
Voilà pour cette exploration initiale de la reconnaissance vocale. Nous terminons avec un nouveau “bouton ‘écoute de l’article’” en haut des pages d’articles. Peut-être que vous écoutez cet article via le widget en ce moment !