Chronometrica ou Topaz Sharingan : comment gérer les transcriptions YouTube manquantes

Choisissez le résultat que votre application doit expliquer

Un Actor est un programme hébergé de collecte de données. Votre application lui fournit des données d’entrée, l’exécute et lit ses résultats. Le contrat de résultat définit ce que votre application peut s’attendre à recevoir.

Pour l’extraction de transcriptions, un résultat réussi ne constitue qu’une partie de ce contrat. Votre application a aussi besoin d’une règle pour les entrées qui ne produisent aucune transcription. Cette règle détermine le message présenté à l’utilisateur et l’action suivante de votre application.

Une question publique posée par un développeur décrit un fonctionnement réussi en local, suivi d’échecs en production, de requêtes bloquées, de résultats vides et d’un comportement de nouvelle tentative peu clair. La question concerne une autre bibliothèque Python de transcription. Elle montre pourquoi il est important de comprendre les résultats. Elle ne fournit aucune donnée de test sur les Actors comparés ici.

Commencez par la décision qui concerne l’utilisateur :

Sources : contrat de résultat de Chronometrica, contrat de résultat de Topaz Sharingan.

Choisissez le contrat le plus simple lorsqu’il répond à l’ensemble du besoin. Choisissez le contrat détaillé lorsque l’application doit distinguer les résultats et agir en conséquence. Le choix repose ainsi sur le comportement de l’application, plutôt que sur une affirmation non étayée concernant le service qui échouerait le moins souvent.

Lisez ensemble les enregistrements réussis et les détails d’échec de Chronometrica

Chronometrica place chaque vidéo YouTube unique traitée avec succès dans une ligne du jeu de données par défaut. Un jeu de données est l’ensemble de ces enregistrements de résultat. Les entrées en échec ne deviennent pas des lignes de réussite dans le jeu de données. Elles ne sont pas non plus des lignes de transcription facturables. Le récapitulatif distinct `OUTPUT` fournit des informations sur l’exécution et peut comprendre `failedInputDetails`. Contrat de Chronometrica.

Cette séparation est importante lorsque vous lisez un jeu de données qui contient peu de lignes. Un jeu de données contenant moins d’enregistrements que votre liste d’entrées ne prouve pas que toutes les entrées ont été traitées avec succès. Il indique quels enregistrements de transcription réussis sont présents. Vous devez aussi examiner les résultats signalés pour les entrées qui n’ont pas produit d’enregistrement.

Gardez `includeFailedInputDetails` défini sur `true`. Les détails d’échec documentés comprennent une identification sûre de l’entrée, `errorCategory`, `errorCode` et `isRetryable`. La catégorie regroupe les échecs par type. Le code fournit une valeur plus précise, lisible par un programme. L’indicateur de nouvelle tentative précise si l’échec signalé permet de réessayer. Schéma d’entrée de Chronometrica, contrat de résultat.

Votre application peut utiliser ces détails pour créer sa propre vue de toutes les entrées soumises. Associez chaque transcription réussie ou détail d’entrée en échec à l’identité de l’entrée concernée. Ne faites pas cette association selon la position des enregistrements dans une liste. Si une ligne de réussite manque, la position n’est plus un moyen sûr de relier une entrée à un résultat.

Gardez le résultat source distinct du message affiché par votre application. Le résultat consigne ce que la recherche a signalé. Le message affiché explique ce résultat à l’utilisateur. Vous pouvez ainsi modifier la formulation sans changer l’observation enregistrée.

Traitez la disponibilité de la langue comme une décision distincte

Avant d’exécuter l’un ou l’autre processus, déterminez si votre application exige une langue particulière pour les sous-titres. Pour être utilisable, une transcription doit répondre à cette exigence en plus de contenir du texte.

Le paramètre `preferredLanguages` de Chronometrica impose un choix strict lorsqu’il est renseigné. Si la langue demandée est indisponible, l’Actor renvoie `LANGUAGE_UNAVAILABLE` au lieu de sélectionner une autre langue sans le signaler. Ce paramètre ne traduit pas les sous-titres. Chronometrica lit les sous-titres publics présents sur la plateforme et ne propose aucun recours à la reconnaissance vocale. Contrat de Chronometrica, schéma d’entrée.

Ce comportement convient à une application dont les utilisateurs doivent recevoir des sous-titres dans la langue demandée. Il fixe aussi une limite claire : une vidéo avec des sous-titres dans une autre langue peut tout de même ne pas répondre à l’exigence de l’application.

Ne présentez pas ce résultat comme une transcription réussie simplement parce que du texte de sous-titres existe. Conservez la langue demandée avec l’enregistrement de l’entrée. L’application pourra alors expliquer qu’elle n’a pas trouvé de sous-titres répondant à la demande.

Si les utilisateurs peuvent accepter une autre langue, définissez ce choix dans votre application avant d’élargir le processus. Modifier l’exigence de langue revient à modifier la demande. Distinguez ce changement d’une nouvelle tentative de la demande initiale. Pour en savoir plus sur la disponibilité des sous-titres, consultez le guide d’extraction des sous-titres YouTube.

Étudiez un ensemble fictif d’enregistrements manquants

L’exemple suivant est fictif. Il ne s’agit ni d’une exécution réelle, ni d’un test comparatif, ni d’un résultat client.

Une application soumet 8 identifiants de vidéo uniques avec une langue demandée pour les sous-titres. 5 vidéos ont des sous-titres utilisables. 1 vidéo n’a pas de sous-titres publics. Pour 1 autre, la langue demandée manque. La dernière rencontre un échec d’accès pour lequel l’indicateur renvoyé autorise une nouvelle tentative.

Pour cet ensemble d’entrées inventé, la proportion de vidéos avec des sous-titres disponibles est :

`5 / 8 × 100 = 62.5%`

Ce calcul décrit uniquement cet ensemble fictif. Il n’estime le taux de réussite réel d’aucun des Actors.

Selon la structure de résultat documentée de Chronometrica, l’application lirait 5 lignes de transcription réussies et 3 détails d’entrées en échec. Elle n’ajouterait pas 3 lignes d’échec inventées au jeu de données des transcriptions réussies. L’application pourrait ensuite présenter 5 enregistrements de transcription et 3 résultats non résolus. Contrat de résultat de Chronometrica.

Ces résultats non résolus nécessitent des messages différents. L’application peut expliquer qu’une recherche n’a trouvé aucun sous-titre public. Elle peut expliquer qu’une autre n’a pas trouvé la langue demandée. Pour l’échec d’accès, elle peut indiquer qu’une nouvelle tentative est prévue, dans la limite fixée, car l’indicateur renvoyé permet cette décision.

Seul le cas signalé par l’indicateur entre dans la file de nouvelles tentatives. L’application ne relance pas chaque entrée dépourvue de ligne de réussite dans le jeu de données. Un indicateur autorisant une nouvelle tentative justifie un nouvel essai. Il ne garantit pas sa réussite.

Si l’application réessaie ensuite cette entrée, elle enregistre un nouveau résultat. Elle conserve la première observation afin que l’historique montre toujours ce qui s’est passé à chaque tentative.

Cet exemple permet de mettre la règle de décision à l’épreuve en pratique. Si votre application a besoin de ces messages distincts et de la file de nouvelles tentatives, choisissez le contrat détaillé. Si son besoin complet se limite à une valeur de transcription pouvant être null, le contrat le plus simple peut suffire.

Utilisez un nombre limité d’entrées pour vérifier le contrat de résultat

Une vérification à petite échelle permet de confirmer que votre application peut lire les enregistrements documentés avant d’ajouter des entrées. Elle n’établit pas la fiabilité en production.

Le JSON suivant utilise des champs d’entrée publics documentés. L’URL illustre le format d’entrée. Elle ne garantit ni la présence actuelle de sous-titres ni un résultat particulier. Remplacez-la par une source publique adaptée.

{
  "startUrls": [
    "https://www.youtube.com/watch?v=dQw4w9WgXcQ"
  ],
  "includeFailedInputDetails": true
}

Les champs sont documentés dans le schéma d’entrée de Chronometrica. Un exemple public de Task fournit un point de départ connexe. Une Task est une configuration d’entrée enregistrée. Ni l’exemple du schéma ni le lien vers la Task ne prouvent qu’une exécution a été réalisée pour ce guide.

Utilisez cette méthode courte pour vérifier le processus :

1. Définissez l’entrée et la règle d’acceptation. Créez une liste de vidéos sans doublons. Consignez toute langue exigée. Définissez ce qui constitue un texte de sous-titres utilisable et ce que l’application affichera lorsqu’aucune transcription utilisable n’est renvoyée.
2. Gardez les détails d’échec activés. Soumettez un petit nombre d’entrées provenant de sources publiques, avec `includeFailedInputDetails` défini sur `true`. Confirmez que votre application peut lire le jeu de données des réussites et le résultat distinct `OUTPUT`.
3. Associez les résultats aux entrées. Utilisez l’identité d’entrée documentée pour relier les résultats aux demandes. Comparez les enregistrements réussis aux détails d’entrées en échec. Ne considérez pas un jeu de données contenant peu de lignes comme un compte rendu complet de la liste soumise.
4. Vérifiez la décision prise en cas d’échec. Lisez les champs d’échec renvoyés. Distinguez les résultats liés à la disponibilité des cas explicitement signalés comme permettant une nouvelle tentative. Ne déduisez pas de la seule absence de transcription qu’une nouvelle tentative est autorisée.
5. Appliquez une politique de nouvelles tentatives avec une limite. Fixez un nombre maximal de tentatives dans votre application. Réessayez uniquement les cas admissibles. Conservez l’observation de chaque tentative et arrêtez lorsque la limite est atteinte.
6. Présentez fidèlement l’état final. Si les nouvelles tentatives se terminent sans transcription, laissez l’entrée à l’état non résolu. Ne transformez pas un texte manquant en enregistrement vide présenté comme réussi. Ne laissez pas entendre qu’une nouvelle tentative permettra de récupérer ce texte.

Si une entrée n’a ni enregistrement réussi associé ni détail d’échec associé dans les données lues par votre application, conservez cette incertitude. Vérifiez les informations d’exécution et votre code de lecture des résultats. N’inventez pas de résultat pour faire correspondre les nombres.

La vérification réussit lorsque votre application peut rendre compte des enregistrements reçus et prendre la décision prévue pour l’utilisateur. Elle n’a pas besoin de produire une transcription pour chaque vidéo soumise pour prouver que la méthode de lecture des résultats fonctionne.

Fixez les limites de nouvelles tentatives avant d’ajouter des entrées

Une file de nouvelles tentatives est une liste d’entrées que votre application prévoit de soumettre à nouveau. Son objectif est ici précis : donner une nouvelle chance limitée aux entrées en échec admissibles, tout en conservant un historique clair.

Choisissez la limite de tentatives avant d’allonger la liste. Sans limite, un échec permettant de réessayer peut rester dans une boucle même si aucune nouvelle tentative ne réussit. Une règle d’arrêt claire permet aussi à l’application de signaler à l’utilisateur la fin des tentatives automatiques.

Conservez dans les enregistrements de votre application l’entrée soumise, son exigence de langue, le résultat observé et l’ordre des tentatives. Ce sont des choix de suivi propres à l’application. Il ne s’agit pas de champs de sortie supplémentaires attribués à l’Actor. Ces informations permettent de distinguer la demande initiale des tentatives suivantes ou des demandes modifiées.

Préservez les valeurs manquantes. Une valeur inconnue doit rester inconnue. Ne remplacez pas une valeur manquante par 0 et n’utilisez pas une transcription vide comme preuve de réussite. Votre application doit pouvoir distinguer le texte reçu, un échec signalé et un résultat qu’elle n’a pas encore établi.

Traitez les échecs de disponibilité comme des observations sur la demande à ce moment précis. Il n’est pas nécessaire de les relancer automatiquement pour conserver un historique exact. Si l’utilisateur change ensuite la langue demandée ou demande une nouvelle vérification, enregistrez cela comme une nouvelle demande ou observation.

Ces règles rendent le comportement de l’application compréhensible. Elles ne reposent pas sur l’affirmation qu’une nouvelle tentative permettra de récupérer les sous-titres.

Choisissez l’Actor selon les exigences de l’application

Chronometrica convient bien lorsqu’une transcription manquante doit donner lieu à un résultat expliqué. Ses champs d’échec vérifiés permettent d’associer les entrées aux résultats, de présenter des messages distincts aux utilisateurs et de décider d’une nouvelle tentative dans une limite fixée. C’est la raison précise de le recommander pour une application qui doit rendre compte des recherches infructueuses. Contrat de Chronometrica.

La principale limite est la disponibilité des sous-titres. Les relevés d’échec détaillés expliquent pourquoi une recherche n’a pas fourni de texte utilisable. Ils ne créent pas de sous-titres, ne les traduisent pas et ne fournissent aucun recours à la reconnaissance vocale.

Choisissez Topaz Sharingan lorsque son résultat documenté de type transcription ou null répond aux exigences de votre application. Son schéma d’entrée comprend `startUrls` et `timestamps`. Un résultat null fait partie de son contrat déclaré. Ce n’est pas une preuve de défaut. Contrat de Topaz Sharingan, schéma d’entrée.

Si la stabilité relative est le facteur décisif, cette comparaison ne permet pas de trancher. Les éléments vérifiés ne contiennent aucun test de performance effectué dans des conditions comparables. Intégrez cette incertitude à la décision au lieu de considérer un relevé d’erreur plus détaillé comme la preuve d’un meilleur taux de réussite.