Skip to main content
Les modèles de transcription acceptent une configuration supplémentaire via le paramètre json_config. Dans le SDK Python, il s’agit d’un dict qui associe chaque nom d’option à une valeur sérialisable en JSON. Avec l’endpoint REST, passez-le sous forme de chaîne JSON encodée pour URL dans le paramètre de requête json_config. Ces options s’appliquent aux deux transports, WebSocket et REST. Pour les réglages TTS, consultez Réglages de la voix.

​
Référence rapide

Les valeurs par défaut peuvent évoluer avec les nouvelles versions des modèles. Fixez explicitement les options si vous dépendez d’un comportement précis. Le serveur valide les clés connues selon les contraintes ci-dessus ; les clés inconnues sont ignorées sans avertissement, vérifiez donc leur orthographe à l’aide du tableau.

​
Langues

json_config avec language défini est obligatoire. Les requêtes qui ne le fournissent pas sont rejetées. Indiquez la langue de l’audio si vous la connaissez, ou "any" dans le cas contraire. Les requêtes qui définissent déjà une langue ou "any" ne sont pas concernées.
Pour les modèles de transcription sans traduction, language est la langue attendue de l’audio. Elle ancre le modèle sur une seule langue pour améliorer la qualité de la transcription : définissez-la donc dès que vous la connaissez. Pour un audio qui mélange plusieurs langues, indiquez la langue dominante. Lorsqu’aucune langue ne prédomine, ou que la langue n’est pas connue à l’avance, passez "any" et le modèle la détecte à partir de l’audio. target_language n’a aucun effet sur ces modèles. Pour les modèles de transcription avec traduction, language et target_language indiquent la langue dans laquelle la transcription doit être générée, et non la langue de l’audio. Les deux sont interchangeables ; définissez l’un ou l’autre.

​
Renforcement de mots-clés (keyword boosting)

Adaptez la transcription à votre propre vocabulaire : noms de joueurs, marques, produits et noms de chaînes. Passez un dictionnaire keywords et le décodeur donne la priorité à ces termes : le vocabulaire qui compte pour votre produit est transcrit exactement comme vous l’attendez, en temps réel et sans réentraînement.
  • words : les termes à renforcer. La correspondance se fait token par token, les mots-clés ne doivent donc pas contenir d’espaces. Découpez les noms composés de plusieurs mots : "Ferran Torres" devient "Ferran" et "Torres". La correspondance est aussi sensible à la casse et aux accents, incluez donc les variantes attendues ("Mbappé" et "Mbappe"). Vous pouvez renforcer jusqu’à 500 mots-clés, et chaque variante d’un mot (minuscules, majuscules, accents, etc.) compte dans cette limite.
  • boost : l’intensité du biais vers le dictionnaire, de -6 à 6. La valeur s’applique dans l’espace des log-probabilités, son effet est donc exponentiel : de petites valeurs modifient déjà sensiblement le décodage.
Choisir le boost. 3 est la valeur par défaut recommandée et convient à la plupart des cas ; montez à 4 pour un vocabulaire particulièrement rare ou étranger. Les valeurs plus élevées apportent des gains décroissants et peuvent faire boucler le décodeur, qui répète alors un mot renforcé au lieu de suivre l’audio : évitez donc de dépasser nettement 4 à 5. Les valeurs négatives pénalisent un terme. Ne les utilisez que pour supprimer un mot précis que vous ne voulez jamais voir dans la sortie, pas comme un réglage général de précision.
Le renforcement est surtout utile pour le vocabulaire rare et propre à un domaine, ainsi qu’en streaming à faible latence (delay_in_frames faible), où le modèle dispose de moins de contexte pour lever seul l’ambiguïté sur les noms. Consultez la recette Renforcement de mots-clés pour un exemple complet.

​
Passer json_config

Le même payload json_config est envoyé quelle que soit l’API du SDK utilisée ; seule la forme de l’appel change :
Si vous appelez directement les endpoints REST, passez json_config sous forme de chaîne JSON encodée pour URL dans les paramètres de requête ; voir le guide REST.

​
VAD sémantique et délai

delay_in_frames est surtout utile avec le flux de transcription WebSocket. Le serveur émet des messages step de VAD sémantique toutes les 80 ms ; chaque step contient des horizons futurs avec des valeurs inactivity_prob. Pour un agent vocal, un point de départ courant consiste à surveiller l’horizon le plus long et à faire un flush lorsque la probabilité d’inactivité reste au-dessus de votre seuil.
Utilisez des valeurs de delay_in_frames faibles pour les assistants conversationnels au rythme rapide, et des valeurs plus élevées pour privilégier la qualité de transcription lorsqu’un peu plus de latence est acceptable. Une valeur comme 16 constitue un bon compromis de départ ; essayez 8 si la réactivité compte davantage que le contexte.