Construction de requête Speech-to-Text

Ce document est un guide présentant les principes de base de l'utilisation de Speech-to-Text. Dans ce guide conceptuel, vous découvrirez les types de requêtes que vous pouvez envoyer à Speech-to-Text. Vous apprendrez également à construire de telles requêtes et à gérer leurs réponses. Nous recommandons à tous les utilisateurs de Speech-to-Text de lire à la fois ce guide et l'un des tutoriels associés avant de se plonger dans l'API elle-même.

Faites l'essai

Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de Speech-to-Text en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.

Profiter d'un essai gratuit de Speech-to-Text

Requêtes vocales

Speech-to-Text a recours à trois grandes méthodes de reconnaissance vocale :

  • La reconnaissance synchrone (REST et gRPC) envoie des données audio à l'API Speech-to-Text, procède à la reconnaissance de ces données et renvoie les résultats une fois que tout le contenu audio a été traité. Les requêtes de reconnaissance synchrone sont limitées aux données audio d'une durée maximale d'une minute.

  • La reconnaissance asynchrone (REST et gRPC) envoie des données audio à l'API Speech-to-Text et lance une opération de longue durée. Cette opération vous permet d'interroger périodiquement les résultats de reconnaissance. Servez-vous des requêtes asynchrones pour les données audio d'une durée allant jusqu'à 480 minutes.

  • La reconnaissance en streaming (gRPC uniquement) effectue la reconnaissance des données audio fournies dans un flux gRPC bidirectionnel. Les requêtes en streaming sont conçues à des fins de reconnaissance en temps réel, par exemple pour l'enregistrement de contenu audio en direct à partir d'un micro. La reconnaissance en streaming fournit des résultats intermédiaires pendant l'enregistrement audio, ce qui permet par exemple d'afficher des résultats au fur et à mesure qu'un utilisateur parle.

Les requêtes contiennent des paramètres de configuration ainsi que des données audio. Dans les sections suivantes, vous trouverez la description plus détaillée de chaque type de requêtes de reconnaissance, des réponses qu'elles génèrent et de la manière de gérer ces réponses.

Reconnaissance API Speech-to-Text

Une requête API Speech-to-Text de reconnaissance synchrone est la méthode la plus simple pour effectuer une reconnaissance sur des données audio de texte parlé. Speech-to-Text peut traiter jusqu'à une minute de données audio de texte parlé envoyées dans une requête synchrone. Une fois que Speech-to-Text a traité et reconnu l'ensemble du contenu audio, une réponse est envoyée.

Une requête synchrone est bloquante, ce qui signifie que Speech-to-Text doit renvoyer une réponse avant de pouvoir traiter la requête suivante. Speech-to-Text permet généralement de traiter le contenu audio de façon plus rapide qu'en temps réel, à raison de 30 secondes de contenu audio en 15 secondes en moyenne. En cas de mauvaise qualité audio, votre requête de reconnaissance peut néanmoins prendre beaucoup plus de temps.

Speech-to-Text a recours à des méthodes REST et gRPC pour appeler les requêtes API Speech-to-Text synchrones et asynchrones. Cet article contient des exemples issus de l'API REST, car il est plus simple de démontrer et d'expliquer une utilisation basique de cette API. Cependant, la constitution de base d'une requête REST ou gRPC est assez similaire. En revanche, les requêtes de reconnaissance en streaming ne sont compatibles qu'avec gRPC.

Requêtes de reconnaissance vocale synchrone

Une requête API Speech-to-Text synchrone se constitue d'une configuration de reconnaissance vocale et de données audio. Un exemple de requête est présenté ci-dessous :

{
    "config": {
        "encoding": "LINEAR16",
        "sampleRateHertz": 16000,
        "languageCode": "en-US",
    },
    "audio": {
        "uri": "gs://bucket-name/path_to_audio_file"
    }
}

Toutes les requêtes API Speech-to-Text de reconnaissance synchrone doivent inclure un champ config de reconnaissance vocale (de type RecognitionConfig). RecognitionConfig contient les sous-champs suivants :

  • encoding (obligatoire) : spécifie le schéma d'encodage du contenu audio fourni (de type AudioEncoding). Si vous avez le choix entre plusieurs codecs, préférez un encodage sans perte tel que FLAC ou LINEAR16, de façon à obtenir des performances optimales. (Pour en savoir plus, consultez la section Encodages audio.) Le champ encoding est facultatif pour les fichiers FLAC et WAV, où l'encodage est inclus dans l'en-tête du fichier.
  • sampleRateHertz (obligatoire) : spécifie le taux d'échantillonnage (en Hertz) du contenu audio fourni. (Pour en savoir plus sur les taux d'échantillonnage, consultez la section Taux d'échantillonnage ci-dessous.) Le champ sampleRateHertz est facultatif pour les fichiers FLAC et WAV, où le taux d'échantillonnage est inclus dans l'en-tête du fichier.
  • languageCode (obligatoire) : contient la langue et les paramètres régionaux à utiliser pour la reconnaissance vocale du contenu audio fourni. Le code de langue doit être un identifiant BCP-47. Notez que les codes de langue se composent généralement d'un tag principal indiquant la langue et d'un sous-tag désignant le dialecte régional (dans l'exemple ci-dessus : "en" pour l'anglais et "US" pour les États-Unis). (Consultez la page intitulée Langues disponibles pour accéder à la liste.)
  • maxAlternatives (facultatif, valeur par défaut : 1) : indique le nombre de transcriptions alternatives à fournir dans la réponse. Par défaut, l'API Speech-to-Text ne fournit qu'une transcription principale. Si vous souhaitez évaluer différentes alternatives, définissez maxAlternatives sur une valeur supérieure. Sachez que Speech-to-Text ne renvoie des alternatives que si le programme de reconnaissance estime que leur qualité est satisfaisante. Les alternatives sont généralement plus appropriées pour les requêtes en temps réel nécessitant des commentaires des utilisateurs (par exemple, des commandes vocales) et sont donc mieux adaptées aux requêtes de reconnaissance en streaming.
  • profanityFilter (facultatif) : indique s'il faut filtrer les expressions ou mots grossiers. Les mots filtrés conservent leur lettre initiale, et des astérisques remplacent les caractères restants (par exemple, p*****). Le filtre de grossièreté n'agit que sur les mots simples. Il ne détecte pas les expressions ou combinaisons de mots constituant des propos injurieux ou choquants.
  • speechContext (facultatif) : inclut des informations contextuelles supplémentaires destinées au traitement du contenu audio considéré. Un contexte contient le sous-champ suivant :
    • boost : contient une valeur qui attribue une pondération pour reconnaître un mot ou une expression donnée.
    • phrases : se compose d'une liste de mots et d'expressions qui fournissent des indications sur la tâche de reconnaissance vocale. Pour plus d'informations, consultez les détails de l'adaptation vocale.

Le contenu audio est acheminé vers Speech-to-Text via le paramètre audio de type RecognitionAudio. Le champ audio contient l'un au choix des deux sous-champs suivants :

  • content inclut le contenu audio à évaluer, intégré à la requête. Reportez-vous à la section Intégrer du contenu audio ci-dessous pour en savoir plus. Le contenu audio transmis directement dans ce champ est limité à une minute.
  • uri contient un URI pointant vers le contenu audio. Le fichier ne doit pas être compressé (par exemple, au format gzip). Actuellement, ce champ doit contenir un URI Google Cloud Storage (au format gs://bucket-name/path_to_audio_file). Reportez-vous à la section Transmettre du contenu audio référencé via un URI ci-dessous.)

Des informations complémentaires sur ces paramètres de requête et de réponse sont présentées ci-dessous.

Taux d'échantillonnage

Vous spécifiez le taux d'échantillonnage de votre contenu audio dans le champ sampleRateHertz de la configuration de la requête. Il doit correspondre au taux d'échantillonnage du contenu audio ou flux associé. Les taux d'échantillonnage compris entre 8 000 Hz et 48 000 Hz sont compatibles avec Speech-to-Text. Vous pouvez spécifier le taux d'échantillonnage d'un fichier FLAC ou WAV dans l'en-tête du fichier au lieu d'utiliser le champ sampleRateHertz. Un fichier FLAC doit contenir le taux d'échantillonnage dans l'en-tête FLAC afin d'être envoyé à l'API Speech-to-Text.

Si vous avez le choix entre plusieurs types d'encodage pour votre fichier source, enregistrez le contenu audio en utilisant un taux d'échantillonnage de 16 000 Hz. En effet, des valeurs inférieures pourraient compromettre la précision de la reconnaissance vocale, tandis que des niveaux plus élevés n'auraient pas d'effet notable sur la qualité de la reconnaissance vocale.

Toutefois, si vos données audio ont déjà été enregistrées à un taux d'échantillonnage autre que 16 000 Hz, ne ré-échantillonnez pas le contenu audio à 16 000 Hz. La plupart des anciens systèmes audio de téléphonie, par exemple, utilisent des taux d'échantillonnage de 8 000 Hz, ce qui peut donner des résultats moins précis. Si vous devez utiliser ce type de contenu audio, fournissez-le à l'API Speech à son taux d'échantillonnage natif.

Langues

Le moteur de reconnaissance de Speech-to-Text est compatible avec un grand nombre de langues et de dialectes. Vous spécifiez la langue (et le dialecte national ou régional) de votre contenu audio dans le champ languageCode de la configuration de la requête, à l'aide d'un identifiant BCP-47.

La liste complète des langues compatibles pour chaque fonctionnalité est disponible sur la page Langues acceptées.

Décalages temporels (horodatages)

Speech-to-Text peut inclure des valeurs de décalage temporel (horodatage) pour le début et la fin de chaque mot prononcé qui est reconnu dans le contenu audio fourni. Une valeur de décalage temporel représente la durée écoulée depuis le début du contenu audio, par incréments de 100 ms.

Les décalages temporels sont particulièrement utiles pour analyser des fichiers audio plus longs, dans lesquels vous pourriez avoir besoin de rechercher un mot précis dans le texte reconnu et de le localiser (chercher) dans le contenu audio d'origine. Les décalages temporels sont compatibles avec toutes nos méthodes de reconnaissance : recognize, streamingrecognize et longrunningrecognize.

Les valeurs de décalage temporel ne sont incluses que pour la première alternative fournie dans la réponse de reconnaissance.

Pour inclure des décalages temporels dans les résultats de votre requête, définissez le paramètre enableWordTimeOffsets sur "true" dans la configuration de votre requête. Pour des exemples d'utilisation de l'API REST ou des bibliothèques clientes, consultez la page Obtenir des horodatages au niveau du mot. Par exemple, vous pouvez inclure le paramètre enableWordTimeOffsets dans la configuration de la requête, comme indiqué ici :

{
"config": {
  "languageCode": "en-US",
  "enableWordTimeOffsets": true
  },
"audio":{
  "uri":"gs://gcs-test-data/gettysburg.flac"
  }
}

Le résultat renvoyé par l'API Speech-to-Text contient des valeurs de décalage temporel pour chaque mot reconnu, comme indiqué ci-dessous :

{
  "name": "6212202767953098955",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.speech.v1.LongRunningRecognizeMetadata",
    "progressPercent": 100,
    "startTime": "2017-07-24T10:21:22.013650Z",
    "lastUpdateTime": "2017-07-24T10:21:45.278630Z"
  },
  "done": true,
  "response": {
    "@type": "type.googleapis.com/google.cloud.speech.v1.LongRunningRecognizeResponse",
    "results": [
      {
        "alternatives": [
          {
            "transcript": "Four score and twenty...(etc)...",
            "confidence": 0.97186122,
            "words": [
              {
                "startTime": "1.300s",
                "endTime": "1.400s",
                "word": "Four"
              },
              {
                "startTime": "1.400s",
                "endTime": "1.600s",
                "word": "score"
              },
              {
                "startTime": "1.600s",
                "endTime": "1.600s",
                "word": "and"
              },
              {
                "startTime": "1.600s",
                "endTime": "1.900s",
                "word": "twenty"
              },
              ...
            ]
          }
        ]
      },
      {
        "alternatives": [
          {
            "transcript": "for score and plenty...(etc)...",
            "confidence": 0.9041967,
          }
        ]
      }
    ]
  }
}

Sélection du modèle

Speech-to-Text peut s'appuyer sur différents modèles de machine learning pour transcrire votre fichier audio. Google a entraîné ces modèles de reconnaissance vocale pour des types de contenu audio et des sources audio spécifiques.

Lors de l'envoi d'une requête de transcription audio à Speech-to-Text, vous pouvez améliorer la qualité des résultats obtenus en spécifiant la source du contenu audio d'origine. Speech-to-Text peut ainsi traiter vos fichiers audio à l'aide d'un modèle de machine learning entraîné à reconnaître les données vocales de ce type de source en particulier.

Pour spécifier un modèle de reconnaissance vocale, incluez le champ model dans l'objet RecognitionConfig de votre requête en indiquant le modèle que vous souhaitez utiliser.

Consultez la liste des modèles de transcription Speech-to-Text pour connaître les modèles de machine learning disponibles.

Contenu audio intégré

L'audio intégré est inclus dans la requête de reconnaissance vocale lorsqu'un paramètre content est transmis dans le champ audio de la requête. L'audio intégré fourni en tant que contenu dans une requête gRPC doit être compatible avec la sérialisation Proto3 et transmis sous forme de données binaires. L'audio intégré fourni en tant que contenu dans une requête REST doit être compatible avec la sérialisation JSON et doit d'abord être encodé en base64. Consultez la page intitulée Encoder du contenu audio en base64 pour en savoir plus.

Lorsque vous créez une requête à l'aide d'une bibliothèque cliente Google Cloud, vous écrivez généralement ces données binaires (ou encodées en base64) directement dans le champ content.

Transmettre du contenu audio référencé via un URI

De manière plus générale, vous transmettrez un paramètre uri dans le champ audio de la requête Speech et le ferez pointer vers un fichier audio (au format binaire, et non en base64) situé sur Google Cloud Storage sous cette forme :

gs://bucket-name/path_to_audio_file

Par exemple, la partie suivante d'une requête Speech fait référence à l'exemple de fichier audio utilisé dans la section Démarrage rapide :

...
    "audio": {
        "uri":"gs://cloud-samples-tests/speech/brooklyn.flac"
    }
...

Pour lire des fichiers Google Cloud Storage, vous devez disposer des autorisations d'accès appropriées, par exemple :

  • Lisible publiquement (comme nos exemples de fichiers audio)
  • Lisible par votre compte de service, si vous utilisez l'autorisation de compte de service
  • Lisible par un compte utilisateur, si vous utilisez l'authentification OAuth à trois acteurs pour l'autorisation de compte utilisateur

Pour en savoir plus sur la gestion des accès à Google Cloud Storage, consultez la page intitulée Créer et gérer des listes de contrôle d'accès dans la documentation de Google Cloud Storage.

Réponses de l'API Speech-to-Text

Comme indiqué précédemment, le temps nécessaire à la réponse d'API Speech-to-Text synchrone pour renvoyer des résultats est proportionnel à la durée du contenu audio fourni. Une fois le traitement effectué, l'API renvoie une réponse semblable à celle présentée ici :

{
  "results": [
    {
      "alternatives": [
        {
          "confidence": 0.98267895,
          "transcript": "how old is the Brooklyn Bridge"
        }
      ]
    }
  ]
}

Expliquons chacun de ces champs :

  • results contient la liste des résultats (de type SpeechRecognitionResult), dans laquelle chaque résultat correspond à un segment de contenu audio (les segments de contenu audio sont séparés par des pauses). Chaque résultat comporte un ou plusieurs des champs suivants :
    • alternatives contient la liste des transcriptions possibles, de type SpeechRecognitionAlternatives. Le nombre de solutions affiché peut différer selon que vous avez demandé plus d'une solution (en définissant maxAlternatives sur une valeur supérieure à 1) et que Speech-to-Text a produit des solutions de qualité suffisante. Chaque alternative comporte les champs suivants :
      • transcript contient le texte transcrit. Reportez-vous à la section Traiter les transcriptions ci-dessous.
      • confidence inclut une valeur comprise entre 0 et 1 indiquant le niveau de confiance de Speech-to-Text pour la transcription considérée. Reportez-vous à la section Interpréter les niveaux de confiance ci-dessous.

Si aucune reconnaissance vocale n'a pu être effectuée dans le contenu audio fourni, la liste des results (résultats) renvoyés ne comporte aucun élément. Cette non-reconnaissance résulte généralement d'un contenu audio de très mauvaise qualité ou de valeurs de code de langue, d'encodage ou de taux d'échantillonnage ne correspondant pas au contenu audio fourni.

Les composants de cette réponse sont expliqués dans les sections suivantes.

Chaque réponse synchrone de l'API Speech-to-Text renvoie une liste de résultats, plutôt qu'un résultat unique comportant tout le contenu audio reconnu. La liste des éléments audio reconnus (au sein des éléments transcript) s'affiche dans un ordre contigu.

Sélectionner des alternatives

Chaque résultat d'une réponse de reconnaissance synchrone réussie peut contenir une ou plusieurs solutions (alternatives) (si la valeur maxAlternatives de la requête est supérieure à 1). Si Speech-to-Text estime qu'une solution présente un niveau de confiance suffisant, cette solution est incluse dans la réponse. L'alternative figurant la première dans la réponse est toujours la meilleure (la plus probable).

Définir maxAlternatives sur une valeur supérieure à 1 ne signifie pas, ni ne garantit, que plusieurs alternatives seront renvoyées. De manière générale, il est plus approprié de fournir plusieurs alternatives afin que les utilisateurs puissent choisir des options en temps réel lorsqu'ils obtiennent des résultats via une requête de reconnaissance en streaming.

Traiter les transcriptions

Chaque alternative fournie dans la réponse contient un élément transcript (une transcription) comportant le texte reconnu. Lorsque des alternatives séquentielles vous sont fournies, vous devez concaténer ces transcriptions.

Le code Python suivant parcourt une liste de résultats et concatène les transcriptions. Sachez que nous prenons la première alternative (ordre zéro) dans tous les cas.

response = service_request.execute()
recognized_text = 'Transcribed Text: \n'
for i in range(len(response['results'])):
    recognized_text += response['results'][i]['alternatives'][0]['transcript']

Niveaux de confiance

La valeur confidence (le niveau de confiance) est une estimation comprise entre 0,0 et 1,0. Elle est calculée par agrégation des valeurs de "probabilité" attribuées à chaque mot du contenu audio. Plus le nombre est élevé, plus nous estimons probable que les mots individuels reconnus seront corrects. Ce champ n'est généralement fourni que pour la première hypothèse et seulement pour les résultats où is_final=true. Par exemple, la valeur confidence peut vous aider à décider si vous préférez présenter d'autres résultats à l'utilisateur ou lui demander confirmation.

Notez toutefois que le modèle détermine le "meilleur" résultat (le mieux classé) sur la base d'un ensemble de signaux allant au-delà du seul score confidence (tels que le contexte de la phrase). De ce fait, il arrive parfois que le meilleur résultat ne soit pas celui présentant le niveau de confiance le plus élevé. Si vous n'avez pas demandé plusieurs alternatives, le "meilleur" résultat renvoyé peut présenter un niveau de confiance inférieur à celui attendu. Cela peut se produire, par exemple, si des mots rares sont utilisés. Un mot rarement utilisé peut se voir attribuer une valeur de "probabilité" faible, même s'il est correctement reconnu. Si le modèle considère que ce mot rare est l'option la plus probable dans ce contexte, ce résultat est renvoyé en tant que meilleur résultat et ce, même si sa valeur confidence est inférieure à celle des autres résultats possibles.

Requêtes et réponses asynchrones

Une requête API Speech-to-Text asynchrone adressée à la méthode LongRunningRecognize est identique à une requête API synchrone Speech-to-Text. Toutefois, au lieu de renvoyer une réponse, la requête asynchrone lance une opération de longue durée (de type Operation) et renvoie immédiatement cette opération à l'appelé. Vous pouvez utiliser la reconnaissance vocale asynchrone avec un contenu audio d'une durée maximale de 480 minutes.

Vous trouverez ci-dessous une réponse typique d'opération :

{
  "name": "operation_name",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.speech.v1.LongRunningRecognizeMetadata"
    "progressPercent": 34,
    "startTime": "2016-08-30T23:26:29.579144Z",
    "lastUpdateTime": "2016-08-30T23:26:29.826903Z"
  }
}

Notez qu'aucun résultat n'est encore présent. Speech-to-Text continue de traiter le contenu audio et utilise cette opération pour stocker les résultats. Les résultats apparaissent dans le champ response de l'opération renvoyée une fois la requête LongRunningRecognize terminée.

Une fois la requête terminée, vous obtenez une réponse complète comme celle indiquée ci-dessous :

{
  "name": "1268386125834704889",
  "metadata": {
    "lastUpdateTime": "2016-08-31T00:16:32.169Z",
    "@type": "type.googleapis.com/google.cloud.speech.v1.LongrunningRecognizeMetadata",
    "startTime": "2016-08-31T00:16:29.539820Z",
    "progressPercent": 100
  }
  "response": {
    "@type": "type.googleapis.com/google.cloud.speech.v1.LongRunningRecognizeResponse",
    "results": [{
      "alternatives": [{
        "confidence": 0.98267895,
        "transcript": "how old is the Brooklyn Bridge"
      }]}]
  },
  "done": True,
}

Sachez que done a été défini sur True et que le champ response de l'opération contient un ensemble de résultats du type SpeechRecognitionResult, qui correspond au type renvoyé par une requête API Speech-to-Text de reconnaissance synchrone.

Par défaut, une réponse REST asynchrone définit done sur False, sa valeur par défaut. Toutefois, comme JSON ne nécessite pas que des valeurs par défaut soient présentes dans un champ, vous devez vous assurer que le champ done est présent et qu'il est défini sur True lorsque vous vérifiez qu'une opération est terminée.

Requêtes API Speech-to-Text de reconnaissance en streaming

Un appel de reconnaissance API Speech-to-Text en streaming est conçu pour enregistrer et reconnaître du contenu audio en temps réel, au sein d'un flux bidirectionnel. Votre application peut envoyer du contenu audio sur le flux de requêtes et recevoir des résultats de reconnaissance intermédiaires et finaux sur le flux de réponses en temps réel. Les résultats intermédiaires constituent le résultat de reconnaissance actuel pour une section de contenu audio, tandis que le résultat de reconnaissance final représente la dernière et meilleure estimation pour cette section.

Requêtes en streaming

Contrairement aux appels synchrones et asynchrones, dans lesquels vous envoyez à la fois la configuration et le contenu audio au sein d'une seule requête, l'appel de l'API Speech en streaming nécessite l'envoi de plusieurs requêtes. La première requête StreamingRecognizeRequest doit contenir une configuration de type StreamingRecognitionConfig non accompagnée de contenu audio. Les requêtes StreamingRecognizeRequest suivantes envoyées sur le même flux seront alors composées de plusieurs trames consécutives d'octets audio bruts.

Une configuration StreamingRecognitionConfig comprend les champs suivants :

  • config (obligatoire) : contient les informations de configuration relatives au contenu audio, de type RecognitionConfig, identiques à celles indiquées dans les requêtes synchrones et asynchrones.
  • single_utterance (facultatif, valeur par défaut : false) : indique si cette requête doit se terminer automatiquement lorsqu'aucune parole n'est plus détectée. Si ce champ est défini, Speech-to-Text détecte les pauses, le silence ou le contenu audio non vocal afin de déterminer quand mettre fin à la reconnaissance. Si ce champ n'est pas défini, l'écoute et le traitement du contenu audio continuent jusqu'à ce que le flux soit fermé explicitement ou que sa durée limite soit atteinte. Il est préférable de définir single_utterance sur true pour le traitement de commandes vocales.
  • interim_results (facultatif, valeur par défaut : false) : indique que la requête en streaming considérée doit renvoyer des résultats temporaires pouvant être affinés par la suite (après le traitement de données audio supplémentaires). Pour que les résultats intermédiaires soient notés dans les réponses, is_final doit être défini sur false.

Réponses en streaming

Les résultats de la reconnaissance vocale en streaming sont renvoyés dans une série de réponses de type StreamingRecognitionResponse. Une telle réponse comprend les champs suivants :

  • speechEventType contient des événements de type SpeechEventType. La valeur de ces événements indique à quel moment il a été déterminé qu'un énoncé unique a été prononcé. Les événements vocaux servent de marqueurs dans la réponse de votre flux.
  • results contient la liste des résultats, qui peuvent être intermédiaires ou finaux et qui sont de type StreamingRecognitionResult. La liste des results (résultats) contient les sous-champs suivants :
    • alternatives contient une liste de transcriptions alternatives.
    • isFinal indique si les résultats obtenus dans l'entrée de liste considérée sont intermédiaires ou finaux. Google peut renvoyer plusieurs résultats isFinal=true dans un même flux, mais le résultat isFinal=true n'est garanti qu'après la fermeture du flux d'écriture (fermeture partielle).
    • stability qualifie la stabilité des résultats obtenus jusqu'à présent (0.0 correspond à une instabilité totale, tandis que 1.0 équivaut à une stabilité parfaite). À la différence du niveau de confiance, qui évalue l'exactitude d'une transcription, le champ stability indique dans quelle mesure le résultat partiel concerné est susceptible d'évoluer. Si isFinal est défini sur true, le champ stability n'est pas défini.