En savoir plus sur les fonctionnalités de reconnaissance vocale

Speech-to-Text est l'une des trois API pré-entraînées Vertex AI sur Google Distributed Cloud (GDC) air-gapped. Le service Speech-to-Text reconnaît la parole dans les fichiers audio et la transcrit en texte. Speech-to-Text répond aux exigences de résidence et de conformité des données.

Le tableau suivant décrit les principales fonctionnalités de Speech-to-Text :

Encodages audio compatibles avec Speech-to-Text

L'API Speech-to-Text est compatible avec de nombreux encodages différents. Le tableau suivant répertorie les codecs audio compatibles :

FLAC est à la fois un codec audio et un format de fichier audio. Pour transcrire des fichiers audio à l'aide de l'encodage FLAC, vous devez les fournir au format de fichier .FLAC, qui inclut un en-tête comportant des métadonnées.

Speech-to-Text accepte les fichiers WAV avec du contenu audio encodé au format LINEAR16 ou MULAW.

Pour en savoir plus sur les codecs audio Speech-to-Text, consultez la documentation de référence sur AudioEncoding.

Si vous avez le choix entre plusieurs types d'encodage pour votre contenu source, utilisez un encodage sans perte tel que FLAC ou LINEAR16 afin d'optimiser la reconnaissance vocale.

Fonctionnalités Speech-to-Text

Speech-to-Text sur Distributed Cloud propose les trois méthodes suivantes pour effectuer la reconnaissance vocale :

• Reconnaissance synchrone : envoie des données audio à l'API Speech-to-Text, procède à la reconnaissance de ces données et renvoie les résultats après le traitement audio. Les requêtes de reconnaissance synchrone sont limitées à une minute ou moins de données audio.

• Reconnaissance asynchrone : 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.

• Reconnaissance en streaming : effectue la reconnaissance des données audio fournies dans un flux 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, permettant ainsi à des résultats d'apparaître à mesure qu'un utilisateur parle, par exemple.

Les requêtes contiennent des paramètres de configuration et des données audio. Les sections suivantes décrivent plus en détail ces requêtes de reconnaissance, les réponses qu'elles génèrent et la manière de gérer ces réponses.

Requêtes et réponses synchrones

Une requête de reconnaissance synchrone Speech-to-Text 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.

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 prendre beaucoup plus de temps.

Requêtes de reconnaissance vocale

Une requête API Speech-to-Text synchrone comprend une configuration de reconnaissance vocale et des données audio. Voici un exemple de requête :

{
    "config": {
        "encoding": "LINEAR16",
        "sample_rate_hertz": 16000,
        "language_code": "en-US",
    },
    "audio": {
        "content": "ZkxhQwAAACIQABAAAAUJABtAA+gA8AB+W8FZndQvQAyjv..."
    }
}

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

• encoding : spécifie le schéma d'encodage du contenu audio fourni. Ce champ est 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 obtenir la liste des formats d'encodage audio acceptés, consultez Encodages audio compatibles avec Speech-to-Text. Le champ encoding est facultatif pour les fichiers FLAC et WAV, qui incluent l'encodage dans leur en-tête.
• sample_rate_hertz : spécifie le taux d'échantillonnage du contenu audio fourni en hertz. Pour en savoir plus sur les taux d'échantillonnage, consultez Taux d'échantillonnage. Le champ sample_rate_hertz est facultatif pour les fichiers FLAC et WAV, qui incluent le taux d'échantillonnage dans leur en-tête.
• language_code : contient la langue et la région à utiliser pour la reconnaissance vocale du contenu audio fourni. Le code de langue doit être un identifiant BCP-47. Les codes de langue se composent d'un tag principal indiquant la langue et d'un sous-tag désignant le dialecte régional. Dans l'exemple, en correspond à l'anglais et US aux États-Unis. Pour obtenir la liste des langues disponibles, consultez Langues acceptées.

Pour en savoir plus et obtenir une description des sous-champs facultatifs que vous pouvez inclure dans le champ config, consultez RecognitionConfig.

Fournissez le contenu audio à Speech-to-Text via le paramètre audio de type RecognitionAudio. Le champ audio contient le sous-champ suivant :

• content : inclut le contenu audio à évaluer, intégré à la requête. Les octets de données audio sont encodés à l'aide d'une représentation binaire pure. Les représentations JSON utilisent Base64. Pour en savoir plus, consultez Contenu audio intégré. Le contenu audio transmis directement dans ce champ est limité à une minute.

Taux d'échantillonnage

Vous spécifiez le taux d'échantillonnage de votre contenu audio dans le champ sample_rate_hertz de la configuration de la requête. Il doit correspondre au taux d'échantillonnage du contenu audio associé. Speech-to-Text est compatible avec les taux d'échantillonnage compris entre 8 000 Hz et 48 000 Hz. 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 sample_rate_hertz. Toutefois, le champ sample_rate_hertz est obligatoire pour tous les autres formats audio.

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 vous avez enregistré vos données audio à 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-to-Text à son taux d'échantillonnage d'origine.

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 language_code de la configuration de la requête à l'aide d'un identifiant BCP-47.

La page Langues acceptées contient la liste complète des langues disponibles pour chaque fonctionnalité.

Sélection du modèle

Lorsque vous envoyez une requête de transcription audio à Speech-to-Text, vous pouvez 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.

Speech-to-Text sur Distributed Cloud est compatible avec les deux modèles suivants :

• default : transcrire du contenu audio qui n'est pas un modèle audio spécifique, comme du contenu audio long.
• chirp : transcrire des contenus audio multilingues lorsque vous avez besoin d'une précision accrue. Chirp effectue la reconnaissance vocale automatique dans de nombreuses langues, même s'il s'agit de langues à faibles ressources pour lesquelles peu de données annotées sont disponibles pour l'entraînement.

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 REST doit être compatible avec la sérialisation JSON.

Vous pouvez envoyer des données directement dans le champ content pour la reconnaissance synchrone uniquement si vos données audio ne dépassent pas 60 secondes et 10 Mo. Toutes les données audio du champ content doivent être au format Base64.

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

La plupart des environnements de développement sont fournis avec un utilitaire base64 permettant d'encoder un fichier binaire en données texte ASCII. Vous disposez ainsi des outils et de l'assistance nécessaires. De plus, Python dispose de mécanismes intégrés pour l'encodage de contenu en base64. Les exemples suivants montrent comment encoder un fichier :

base64 INPUT_FILE -w 0 > OUTPUT_FILE

# Import the base64 encoding library.
import base64

# Pass the audio data to an encoding function.
def encode_audio(audio):
  audio_content = audio.read()
  return base64.b64encode(audio_content)

Réponses de reconnaissance vocale

Le temps nécessaire à la réponse synchrone de l'API Speech-to-Text pour renvoyer des résultats peut être plus ou moins long. Une fois le traitement effectué, l'API renvoie une réponse semblable à celle présentée ici :

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

Toutes les réponses de reconnaissance synchrone de l'API Speech-to-Text incluent des résultats de reconnaissance vocale de type RecognizeResponse. Un objet RecognizeResponse contient les champs suivants :

• results : contient la liste des résultats de type SpeechRecognitionResult, où chaque résultat correspond à un segment audio. Chaque résultat comporte un ou plusieurs des sous-champs suivants :

  • alternatives : contient la liste des transcriptions possibles de type SpeechRecognitionAlternative. La première alternative de la réponse est toujours la plus probable. Chaque alternative se compose des sous-champs suivants :

    • transcript : contient le texte transcrit. Lorsque des alternatives séquentielles vous sont fournies, vous pouvez concaténer ces transcriptions.
    • words : contient une liste d'informations spécifiques à chaque mot reconnu.

Pour en savoir plus, consultez la page RecognizeResponse.

Requêtes et réponses asynchrones

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

Voici un exemple de réponse d'opération :

{
  "name": "OPERATION_NAME",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.speech_v1p1beta1.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.

Voici un exemple de réponse complète une fois la requête traitée :

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

Notez que done est 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 de reconnaissance synchrone.

Requêtes et réponses en flux continu

Un appel de reconnaissance en streaming de l'API Speech-to-Text 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 des données audio sur le flux de requêtes et recevoir des résultats de reconnaissance intermédiaires et finaux en temps réel sur le flux de réponses. 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 de reconnaissance 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-to-Text en streaming nécessite l'envoi de plusieurs requêtes. La première StreamingRecognizeRequest doit contenir une configuration de type StreamingRecognitionConfig.

Un StreamingRecognitionConfig se compose du champ config, qui contient des informations de configuration pour le contenu audio de type RecognitionConfig et est identique à celui indiqué dans les requêtes synchrones et asynchrones.

Réponses de reconnaissance en streaming

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

• speech_event_type : contient des événements de type SpeechEventType. La valeur de ces événements indique à quel moment 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 results inclut les sous-champs suivants :
  • alternatives : contient une liste de transcriptions alternatives.
  • is_final : indique si les résultats obtenus dans l'entrée de liste considérée sont intermédiaires ou finaux.
  • result_end_time : indique le horodatage de la fin de ce résultat par rapport au début de l'audio.

Chirp : modèle de reconnaissance vocale universel

Chirp est la nouvelle génération de modèles Speech-to-Text sur Google Distributed Cloud (GDC) air-gapped. Chirp est une version d'un modèle de reconnaissance vocale universel qui comporte plus de deux milliards de paramètres et peut transcrire de nombreuses langues dans un seul modèle.

Vous pouvez transcrire des fichiers audio dans d'autres langues acceptées en activant le composant Chirp.

Chirp atteint un taux d'erreur de mot (WER, Word Error Rate) de pointe sur différents ensembles de tests et langues publics, et offre une prise en charge multilingue sur Distributed Cloud. Il utilise un encodeur universel qui entraîne des modèles avec une architecture différente de celle des modèles vocaux actuels, en utilisant des données dans de nombreuses autres langues. Le modèle est ensuite affiné pour proposer la transcription dans des langues spécifiques. Un seul modèle unifie les données de nombreuses langues. Les utilisateurs doivent néanmoins toujours spécifier la langue dans laquelle le modèle doit reconnaître la voix.

Chirp traite la reconnaissance vocale en fragments beaucoup plus importants que les autres modèles. Les résultats ne sont disponibles qu'une fois l'énoncé terminé, ce qui signifie que Chirp n'est pas forcément adapté à une utilisation en temps réel.

L'identifiant du modèle Chirp est chirp. Vous pouvez donc définir la valeur chirp dans le champ model de l'objet RecognitionConfig de la requête.

Méthodes d'API disponibles

Chirp est compatible avec les méthodes d'API Speech-to-Text Recognize et StreamingRecognize.

Les deux méthodes diffèrent, car StreamingRecognize ne renvoie des résultats qu'après chaque énoncé. Pour cette raison, cette méthode présente une latence de l'ordre de quelques secondes plutôt que de quelques millisecondes après le début de la parole, contrairement à la méthode Recognize. Toutefois, StreamingRecognize présente une latence très faible après la fin d'un énoncé, par exemple dans une phrase suivie d'une pause.