For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Navigation principale
Theme

Suggestions

GPT-Live

Realtime API

Créer des applications vocales

Connexions

Traitement audio

Tableau de bord de l’API
Essayez ChatGPT

Concevoir des prompts pour les modèles Realtime

Concevez et testez des prompts pour les modèles vocaux Realtime.

Choisissez le modèle Realtime que vous utilisez pour votre application. Pour GPT-Live, consultez le guide Concevoir des prompts pour GPT-Live.

gpt-realtime-2 est notre modèle vocal de raisonnement le plus avancé pour les applications de parole à parole à faible latence. Il peut réfléchir avant de parler. Par rapport aux modèles Realtime précédents, il suit les instructions plus fidèlement, dispose d’une fenêtre de contexte plus grande et appelle les outils avec davantage de précision.

Pour tirer parti de ces améliorations, précisez le comportement attendu dans vos prompts. Définissez explicitement les responsabilités de l’assistant, les décisions qu’il doit prendre, les règles d’appel des outils et les garde-fous. Indiquez ce qu’il doit faire, à quel moment et ce qu’il doit éviter.

Commencez par un prompt minimal. Évaluez-le, puis ajoutez des instructions uniquement pour les comportements qui échouent lors des tests.

Choisissez un modèle

ModèleQuand l’utiliserPoints à préciser dans le prompt
gpt-realtime-2

Vous recherchez les meilleures performances en temps réel pour le raisonnement, l’utilisation des outils et le suivi des instructions.

Ajustez l’effort de raisonnement, les préambules, les règles d’utilisation des outils, la saisie exacte des entités et le suivi de l’état des sessions longues.

gpt-realtime-1.5Vous avez besoin d’un modèle de parole à parole rapide et fiable, sans raisonnement.

Suivez la structure de base des prompts Realtime et testez les comportements sensibles à la latence.

Guide de conception des prompts pour Realtime 2.0

Utilisez gpt-realtime-2 si votre agent vocal doit raisonner plus finement, mieux choisir ses outils, traiter des entités avec exactitude ou suivre l’état d’une session longue. Commencez avec reasoning.effort: “low”, testez les préambules par défaut et indiquez clairement quelles opérations d’écriture nécessitent une confirmation préalable.

Nouveautés de Realtime 2

Rédigez vos prompts en tenant compte des capacités de raisonnement de Realtime 2, qui vont au-delà de celles d’un simple bot vocal.

Changement Conséquences pour les prompts
Raisonnement Pour les tâches complexes, laissez le modèle raisonner en interne avant de parler ou d’appeler un outil. Utilisez des préambules pour éviter les silences gênants ou les paroles superflues.
La précision du prompt compte davantage Remplacez les consignes générales comme « rendez-vous utile » par des règles précises. Indiquez ce qui déclenche l’action, ce qu’il faut faire et dans quels cas il faut s’abstenir.
Les conflits entre instructions ont davantage de conséquences Éliminez les règles qui se recoupent et contiennent always, never, only ou must, sauf si elles sont indispensables. Précisez quelle règle prévaut en cas de conflit.
L’utilisation des outils se règle plus finement Précisez quand l’assistant doit agir immédiatement, demander une information manquante, confirmer un détail qui exige de la précision, réessayer après un échec ou passer le relais.
Les préambules se règlent indépendamment Le modèle peut annoncer brièvement ce qu’il fait avant un raisonnement prolongé ou une série d’appels d’outils. Indiquez quand il doit utiliser un préambule, quelle longueur respecter et quand s’en passer.
Fenêtre de contexte élargie gpt-realtime-2 fait passer la fenêtre de contexte en temps réel de 32 000 à 128 000 tokens. Le modèle convient ainsi mieux aux sessions longues et aux prompts système volumineux.

Les préambules ne révèlent pas le raisonnement détaillé (« chain-of-thought ») interne. Ce sont de brèves annonces orales, comme « Je vérifie cette commande. » Ne demandez pas au modèle de révéler son raisonnement privé.

Structure de prompt recommandée

Utilisez des sections courtes avec un titre. Le modèle doit pouvoir repérer rapidement les instructions pertinentes.

# Rôle et objectif

# Personnalité et ton

# Langue

# Raisonnement

# Canaux de message

# Préambules

# Niveau de détail

# Outils

# Propos indistincts

# Saisie des entités

# Gestion des contextes longs

# Transfert

Tous les cas d’usage ne nécessitent pas toutes ces sections. Ajoutez celles qui correspondent à votre produit.

Réglez l’effort de raisonnement

gpt-realtime-2 peut prendre plus de temps pour approfondir son raisonnement. Utilisez le niveau de raisonnement le plus bas qui permette à l’assistant de mener à bien le workflow.

Commencez avec low pour la plupart des agents vocaux en production. Augmentez ou réduisez ce niveau selon la complexité de la tâche, la latence acceptable et le coût d’un échec.

Effort Quand l’utiliser Exemple
minimal La tâche est simple et la priorité est de réduire la latence au minimum. Commandes domotiques, minuteurs, consultation rapide d’un agenda.
low Vous avez besoin de réactivité et d’un raisonnement élémentaire. Service client, recherche de commande, questions simples sur une politique.
medium L’assistant doit raisonner sur des tâches en plusieurs étapes. Assistance technique, diagnostic, orientation de demandes complexes.
high Un raisonnement approfondi augmente sensiblement les chances de réussite. Workflows exigeant une grande précision, décisions de transfert, tâches soumises à des contraintes.
xhigh Un effort de raisonnement maximal justifie la latence et le coût supplémentaires. Planification complexe, triage critique, coordination d’outils pour des opérations à fort enjeu.

En complément du réglage de l’API, indiquez au modèle quand raisonner et jusqu’où pousser le raisonnement.

## Raisonnement

- Pour une réponse directe, une recherche simple ou une brève confirmation, répondez rapidement, sans raisonner.
- Pour une tâche en plusieurs étapes, une décision sur l’utilisation d’un outil, un dépannage ou un transfert, raisonnez avant d’agir.
- Si les propos de l’utilisateur sont indistincts, demandez une précision au lieu d’entamer un raisonnement prolongé.

Choisissez quand utiliser un préambule

Les préambules sont de brèves annonces orales qui permettent à l’agent vocal de rester réactif pendant qu’il raisonne, recherche une information ou appelle un outil. Bien utilisés, ils indiquent à l’utilisateur que l’assistant traite sa demande. Mal utilisés, ils meublent la conversation et donnent l’impression d’attendre plus longtemps.

gpt-realtime-2 génère des préambules par défaut. Testez d’abord ce comportement. S’il ne correspond pas à l’expérience que vous souhaitez proposer, ajustez-le explicitement.

Chronologie de la génération et de la lecture d’un préambule

## Préambules

Utilisez un préambule court uniquement s’il aide l’utilisateur à comprendre que vous traitez sa demande.

### Quand utiliser un préambule

Utilisez un préambule dans les cas suivants :

- vous allez appeler un outil dont le délai de réponse risque d’être perceptible ;
- la demande exige un raisonnement en plusieurs étapes ;
- vous vérifiez des dossiers, des disponibilités, l’état d’un compte ou les détails d’une politique ;
- vous préparez un transfert ou un passage de relais ;
- un silence donnerait l’impression que vous ne réagissez plus.

Lorsqu’un préambule est nécessaire, prononcez-le juste avant d’entamer le raisonnement de fond ou d’utiliser l’outil.

### Quand omettre le préambule

N’utilisez pas de préambule dans les cas suivants :

- vous pouvez donner une réponse directe immédiatement ;
- l’utilisateur se contente de confirmer, de corriger ou de refuser quelque chose ;
- les propos sont indistincts et vous devez demander une précision ;
- vous n’entendez que du silence, du bruit de fond, de la musique d’attente, la télévision ou une conversation qui ne vous est pas adressée ;
- l’appel d’outil est rapide et une annonce n’apporterait rien à l’utilisateur.

### Style du préambule

Lorsque vous utilisez un préambule :

- gardez un ton naturel, calme et concis ;
- variez la formulation d’un tour de parole à l’autre ;
- décrivez l’action sans exposer votre raisonnement interne ;
- évitez les paroles superflues.

Évitez les formulations suivantes :

- « Laissez-moi réfléchir… »
- « Hum… »
- « Un instant, le temps que je traite votre demande… »
- « Je vais maintenant accéder à l’outil… »

### Longueur du préambule

Utilisez une phrase courte.

Ne dépassez pas deux phrases courtes, sauf si l’utilisateur a besoin d’une explication avant une action lourde de conséquences.

### À privilégier

- « Je vérifie cette commande. »
- « Je consulte les détails de votre rendez-vous. »
- « Je vais vérifier ce point avant toute modification. »
- « Je vérifie la règle applicable, puis je vous indique la marche à suivre. »
- « J’ouvre le dossier pour que nous puissions vérifier qu’il s’agit du bon compte. »

### À éviter

- « Laissez-moi y réfléchir un instant. »
- « Veuillez patienter pendant le traitement de votre demande. »
- « Je vais maintenant utiliser mes outils. »
- « Question intéressante. Je vais y réfléchir attentivement. »

Réglez la longueur des réponses

gpt-realtime-2 respecte mieux les consignes de longueur lorsque le prompt précise le niveau de détail attendu pour chaque type de tâche. Au lieu de demander au modèle d’« être concis », définissez ce que cela signifie dans chaque situation. Une réponse directe, un résultat d’outil, un dépannage, une comparaison ou un transfert peuvent nécessiter des réponses de longueurs différentes.

## Niveau de détail

- Réponse directe : utilisez une à deux phrases courtes.
- Demande de précision : posez une seule question à la fois.
- Résultat d’outil : résumez d’abord le résultat, puis indiquez uniquement la prochaine action utile.
- Comparaison de produits ou d’options : indiquez les différences importantes, les compromis et les besoins auxquels répond chaque option.
- Dépannage : donnez une seule étape à la fois, sauf si l’utilisateur demande la procédure complète.
- Transfert : expliquez brièvement pourquoi le transfert est nécessaire et ce qui va se passer ensuite.

Exemple :

Utilisateur : Quelle offre me conseillez-vous ?

Assistant : Si votre priorité est le prix, choisissez Basic. Si vous avez besoin de gérer les autorisations d’une équipe et de partager la facturation, choisissez Pro. Si vous devez effectuer des contrôles de conformité ou disposer de fonctions d’administration, choisissez Enterprise.

Définissez les règles d’utilisation des outils

gpt-realtime-2 appelle les outils avec davantage de fiabilité, mais son comportement dépend toujours du prompt et de la définition des outils. Si le prompt n’indique pas quand agir, poser une question, demander confirmation ou reprendre après un échec, l’assistant risque d’appeler un outil trop tôt, de poser des questions inutiles ou de répéter un appel qui a échoué.

Réglez la prise d’initiative pour les appels d’outils

L’assistant peut prendre davantage d’initiatives pour les actions en lecture seule à faible risque. Il vaut mieux limiter cette initiative quand les outils modifient des données, ont des effets externes ou exigent des identifiants exacts.

Type d’outil Comportement par défaut
Recherche en lecture seule à faible risque Appelez l’outil lorsque l’intention et les champs requis sont clairs.
Lecture seule avec identifiant exact Faites confirmer l’identifiant avant la recherche.
Communication visible par l’utilisateur Préparez un brouillon ou résumez le message avant l’envoi.
Modification de compte Demandez confirmation avant l’appel.
Achats, annulations, paiements Faites confirmer le montant, l’objet de l’opération et sa conséquence avant l’appel.
Actions irréversibles ou lourdes de conséquences Demandez une confirmation explicite et proposez un transfert si nécessaire.

Adoptez les règles suivantes comme point de départ si vous combinez des actions de lecture et d’écriture. Adaptez-les à votre cas d’usage.

## Outils

Utilisez uniquement les outils explicitement fournis dans la liste actuelle. N’inventez, ne simulez et ne renommez aucun outil. Ne supposez pas qu’un outil existe.

Pour les outils en lecture seule :

- Appelez l’outil lorsque l’intention de l’utilisateur est claire et que vous disposez de tous les champs requis.
- Ne demandez pas de confirmation, sauf si la recherche dépend d’un identifiant qui doit être exact ou si le risque de consulter le mauvais dossier est réel.
- Demandez une précision uniquement si un champ requis manque, est ambigu ou contredit une autre information.

Pour les outils d’écriture ou les actions externes :

- Résumez l’action prévue avant d’appeler l’outil.
- Précisez sa principale conséquence, par exemple ce qui sera modifié, envoyé, annulé, commandé ou débité.
- Demandez confirmation.
- N’appelez l’outil qu’après avoir obtenu une confirmation claire de l’utilisateur.

Pour les identifiants exacts :

- Les identifiants de commande, numéros de suivi, numéros de compte, codes de confirmation, numéros de téléphone et adresses e-mail doivent être exacts.
- Ne normalisez une valeur que si le type de champ est clair.
- Faites confirmer la valeur finale avant toute recherche propre à un compte, validation ou opération d’écriture.

Après un appel d’outil :

- Annoncez que l’action a été effectuée uniquement si l’appel a réussi.
- Si l’appel échoue, expliquez brièvement l’échec sans exposer l’erreur brute et indiquez clairement à l’utilisateur la prochaine étape.

Exemple d’action à haut risque :

Utilisateur : Débitez ma carte du solde restant.

À éviter :

Assistant : J’ai débité votre carte.

À privilégier :

Assistant : Vous souhaitez régler le solde restant de 248,16 $ avec la carte enregistrée. Puis-je effectuer le débit ?

Reprenez après un échec d’outil

Les échecs d’outils font partie de la conversation. Pour bien reprendre l’échange, expliquez ce qui s’est passé et indiquez clairement à l’utilisateur la prochaine étape.

Adaptez la réponse au type d’outil, à la nature de l’échec et à ses conséquences pour l’utilisateur. Dans certains cas, l’assistant doit réessayer sans interrompre l’échange. Dans d’autres, il doit demander à l’utilisateur de préciser sa demande, de corriger un identifiant, de confirmer une nouvelle action ou de choisir une autre solution.

## Échecs d’outils

Si un appel d’outil échoue :

1. Expliquez brièvement ce qui a échoué dans des termes accessibles à l’utilisateur.
2. Ne rejetez pas la faute sur l’utilisateur et n’exposez pas l’erreur brute de l’outil.
3. Si l’échec peut provenir d’un identifiant qui doit être exact, relisez la valeur utilisée et demandez à l’utilisateur de la corriger.
4. Si l’échec peut être temporaire, proposez de réessayer une fois.
5. Si le même échec se répète, proposez une autre solution ou un transfert.

Après un échec, n’appelez pas à répétition le même outil avec les mêmes arguments.

Avant de demander un autre identifiant, vérifiez que vous avez correctement saisi la valeur fournie.

À éviter :

Assistant : Un problème est survenu.

À privilégier :

Assistant : Je ne trouve aucun résultat pour O R D tiret 3 1 2 5 B 2 3. Ai-je mal compris l’un des caractères ?

Gardez le prompt en accord avec les outils disponibles

Les modèles Realtime cherchent spontanément à aider. Si le prompt mentionne un outil indisponible ou si la liste des outils ne correspond pas au prompt, le modèle risque d’inventer un nom d’outil ou de prétendre avoir exécuté l’action.

Par exemple, si le prompt mentionne lookup_order mais que l’outil fourni s’appelle search_orders, le modèle risque d’utiliser le mauvais nom ou de simuler l’action.

## Disponibilité des outils

Utilisez uniquement les outils explicitement fournis dans la liste actuelle.

N’inventez ni ne simulez d’outil et ne supposez pas qu’un outil existe. Si les instructions mentionnent un outil absent de la liste, considérez-le comme indisponible.

Si l’utilisateur demande une action qui nécessite un outil indisponible :

1. Ne prétendez pas avoir effectué l’action.
2. Expliquez brièvement que l’outil est indisponible.
3. Proposez l’action prise en charge qui se rapproche le plus de la demande.

Annoncez que l’action a été effectuée uniquement après la réussite de l’appel à l’outil concerné.

Utilisez le méta-prompt d’audit en annexe pour repérer les contradictions, les outils manquants et les instructions trop fragiles dans vos prompts de production.

Gérez les silences et les sons ambiants

Par défaut, les agents vocaux ont tendance à répondre. En production, ils captent souvent des sons qui n’appellent aucune réponse orale : silence, bruit de fond, musique d’attente, son de la télévision ou conversation entre d’autres personnes.

Utilisez un outil d’attente sans effet lorsque l’assistant doit garder le silence et continuer d’écouter. Il dispose ainsi d’une action valide qui ne l’oblige pas à dire « Je suis là » ou « Je n’ai pas bien entendu ».

Définition de l’outil :

{
  "name": "wait_for_user",
  "description": "Appelez cet outil lorsque le dernier segment audio n’appelle aucune réponse orale, par exemple si vous n’entendez que du silence, du bruit de fond, de la musique d’attente, la télévision, une conversation entre d’autres personnes ou des propos qui ne s’adressent pas à l’assistant. Cet outil permet de terminer le tour de parole sans répondre à l’oral.",
  "parameters": {
    "type": "object",
    "properties": {},
    "required": []
  }
}

Associez-lui des instructions dans le prompt :

## Gestion des silences et du bruit de fond

Appelez `wait_for_user` si le dernier segment audio n’appelle aucune réponse orale : vous n’entendez que du silence, du bruit de fond, de la musique d’attente, la télévision, une conversation entre d’autres personnes ou des propos qui ne vous sont pas adressés.

Après cet appel, ne répondez pas à l’oral.

Ne dites pas « Je suis là », « Je n’ai pas bien entendu », « Prenez votre temps » ou « Dites-moi quand vous serez prêt ».

Reprenez l’échange uniquement lorsque l’utilisateur s’adresse clairement à vous ou demande de l’aide.

Réservez cet outil aux sons qui ne s’adressent pas à l’assistant. Si l’utilisateur s’adresse manifestement à lui mais que ses propos sont inintelligibles, demandez une précision.

Utilisez les canaux de message à bon escient

gpt-realtime-2 peut produire des messages intermédiaires visibles par l’utilisateur dans le canal commentary et des réponses définitives dans le canal final. Si le comportement attendu dépend du canal, donnez des instructions propres à chacun.

Canal Visible par l’utilisateur ? Utilisation
commentary Oui Préambules et appels d’outils.
final Oui Message final destiné à l’utilisateur.

Par exemple, les appels d’outils se font dans le canal commentary. Si vous voulez que l’assistant parle avant, pendant ou après l’utilisation d’un outil, précisez ce comportement dans les instructions relatives à ce canal.

Avant d’appeler un outil dans le canal commentary, indiquez brièvement à l’utilisateur ce que vous faites.

gpt-realtime-2 peut produire plusieurs phases de réponse au cours d’un même tour de parole. Dans la sortie de l’API, l’événement response.done les distingue grâce à la valeur de phase, qui indique s’il s’agit d’un commentaire intermédiaire ou de la réponse finale.

Votre application peut utiliser ce champ pour traiter chaque phase différemment. Par exemple, elle peut lire ou afficher le commentaire comme une brève annonce intermédiaire et réserver final_answer à la réponse complète de l’assistant.

response.output[0].phase: "commentary"
response.output[1].phase: "final_answer"

Gérez les propos difficiles à comprendre

Le modèle ne doit agir que s’il comprend avec certitude ce qu’il entend. Si les propos sont indistincts, il doit poser une brève question de clarification au lieu de deviner.

Ne laissez pas le modèle déduire les mots manquants, appeler des outils, saisir des entités, générer un préambule ou consacrer du temps de raisonnement interne à reconstituer ce que l’utilisateur a pu dire.

## Propos indistincts

- Répondez uniquement aux propos ou aux textes que vous comprenez clairement.
- Si les propos de l’utilisateur sont indistincts, demandez-lui de répéter en utilisant une courte phrase en anglais, par exemple « Sorry, could you repeat that clearly? »
- Ne demandez pas deux fois la même précision avec la même formulation.
- Considérez le son comme indistinct s’il est ambigu, bruité, silencieux, inintelligible ou partiellement coupé, ou si vous doutez des mots exacts prononcés par l’utilisateur.
- Si les propos sont indistincts, ne devinez pas ce que l’utilisateur voulait dire.
- Ne raisonnez pas si les propos sont indistincts.
- Si les propos sont indistincts, ne prononcez pas de préambule et n’appelez pas d’outil dans le canal commentary.

Exemple :

Audio de l’utilisateur : « Vérifiez la commande trois un… » [coupure]

À éviter :

Assistant : Je vérifie la commande 31.

À privilégier :

Assistant : Je n’ai entendu qu’une partie du numéro de commande. Pourriez-vous le répéter chiffre par chiffre ?

Saisissez les entités avec exactitude

De nombreux workflows en temps réel exigent des valeurs exactes : identifiants de commande, numéros de suivi, adresses e-mail, codes de confirmation, numéros de compte ou de dossier, identifiants de ticket, références d’assistance et numéros de téléphone.

La saisie à l’oral est délicate. Les utilisateurs parlent vite, regroupent les chiffres de différentes façons, n’épellent qu’une partie d’une valeur, hésitent, se corrigent en cours de phrase ou prononcent des caractères aux sonorités proches. Un seul chiffre erroné peut faire échouer une recherche ou renvoyer le mauvais compte.

Soyez prudent lors de la saisie. Recueillez une valeur à la fois, normalisez uniquement ce qui est clair, faites confirmer les valeurs qui exigent une grande précision avant tout appel d’outil et prévoyez la possibilité de corriger chaque valeur.

Recueillez une seule entité à la fois

Lorsqu’un workflow exige plusieurs valeurs, recueillez-les une par une. Vous éviterez ainsi de confondre les champs, en particulier dans les conversations vocales.

## Ordre de collecte des entités

Recueillez les valeurs requises une par une.

- Demandez uniquement la prochaine valeur manquante.
- Ne demandez pas plusieurs valeurs au cours du même tour de parole.
- Avant de poser la question, vérifiez si la valeur a déjà été fournie au cours de la conversation ou de la session.
- Si vous disposez déjà d’une valeur possible, faites-la confirmer par l’utilisateur avant de l’utiliser.

Exemple :

« Vous avez indiqué le numéro de suivi ABC-54321 tout à l’heure. Dois-je utiliser celui-ci ou avez-vous un autre numéro de suivi ? »

N’appelez aucun outil tant que la valeur en cours de collecte n’a pas été recueillie, validée et confirmée.

Traitez les caractères épelés

Appliquez cette méthode lorsque les utilisateurs épellent un identifiant, un code, un nom ou une adresse e-mail caractère par caractère. La suite de sons reçue doit être convertie en valeur finale.

## Caractères épelés

Lorsqu’un utilisateur dicte un identifiant, un code ou une adresse e-mail caractère par caractère, regroupez la séquence dictée en une seule valeur. Conservez les séparateurs explicitement prononcés, comme le tiret, le point, le tiret bas, la barre oblique ou le signe plus. Sinon, n’ajoutez ni espace ni séparateur.

Exemples :

- « A B C un deux trois » -> « ABC123 »
- « B C tiret neuf huit sept » -> « BC-987 »
- « J O H N arobase example point com » -> « john@example.com »

N’insérez pas d’espaces entre les caractères épelés, sauf si l’utilisateur indique explicitement que la valeur contient des espaces.

Normalisez avec soin les nombres dictés

Pour dicter un identifiant numérique, l’utilisateur peut énoncer les chiffres séparément, les regrouper ou les lire comme un nombre. Si le champ attend une suite continue de chiffres, convertissez en chiffres les nombres que vous comprenez sans ambiguïté.

## Traitement des nombres dictés

Lors de la collecte d’identifiants numériques, transcrivez les nombres dictés en chiffres.

Exemples :

- « un deux trois quatre » -> « 1234 »
- « un vingt-trois » -> « 123 »
- « un dix-neuf » -> « 119 »
- « quatre-vingt-dix-neuf onze » -> « 9911 »
- « neuf mille neuf cent onze » -> « 9911 »

Si plusieurs interprétations sont plausibles, demandez une précision à l’utilisateur avant d’utiliser la valeur.

Exemple :

« J’ai entendu soit 119, soit 1-19. Pourriez-vous répéter le numéro chiffre par chiffre ? »

Faites confirmer les identifiants exacts avant les appels d’outils

Les identifiants de commande, numéros de suivi, numéros de compte ou de dossier, codes de confirmation et autres identifiants similaires doivent être exacts. Faites-les confirmer avant de les utiliser dans un appel d’outil.

Pour un identifiant numérique, répétez la valeur chiffre par chiffre. Si vous la lisez comme un nombre entier, une erreur risque de passer inaperçue.

Exemple :

Assistant : Pour vérifier, j’ai entendu 8… 3… 5… 2… 1. C’est bien ça ?

Si l’utilisateur corrige un caractère ou un chiffre, répétez la valeur corrigée en entier avant d’appeler l’outil.

Exemple :

Assistant : D’accord. J’ai donc 8… 3… 5… 7… 1. C’est bien ça ?

## Confirmation des identifiants exacts

Avant d’appeler un outil avec un identifiant qui doit être exact :

- Faites confirmer la valeur finale normalisée par l’utilisateur.
- Relisez les identifiants numériques chiffre par chiffre.
- N’utilisez aucune valeur supposée, partielle ou ambiguë.
- Si l’utilisateur corrige la valeur, répétez la valeur corrigée en entier avant d’appeler l’outil.

Faites confirmer les adresses e-mail caractère par caractère

Il est important de saisir correctement les adresses e-mail. Un point, un tiret, un tiret bas, une lettre en double ou deux noms qui se prononcent de façon similaire peuvent faire échouer une recherche de compte ou entraîner l’envoi d’un message à la mauvaise adresse.

Demandez à l’utilisateur d’épeler son adresse e-mail :

Assistant : Pourriez-vous épeler votre adresse e-mail caractère par caractère pour que je puisse vérifier que je l’ai bien notée ?

Lorsque vous la répétez, faites confirmer l’adresse finale exacte :

Assistant : Je vérifie : c-h-e-n arobase example point com, c’est bien ça ?

## Confirmation des adresses e-mail

Saisissez chaque adresse e-mail avec exactitude.

Si l’utilisateur prononce son adresse e-mail sans l’épeler, demandez-lui de la répéter caractère par caractère.

Exemple :

« Pourriez-vous épeler votre adresse e-mail caractère par caractère pour que je puisse vérifier que je l’ai bien notée ? »

Lorsque vous relisez l’adresse, faites confirmer l’adresse finale exacte.

Exemple :

« Je vérifie : c-h-e-n arobase example point com, c’est bien ça ? »

Workflow de collecte des entités

Évitez les pièges d’une interprétation littérale

gpt-realtime-2 suit les instructions plus littéralement que les modèles Realtime précédents. Les prompts qui fonctionnaient bien avec les anciens modèles peuvent nécessiter des ajustements.

Choisissez des formulations précises. Le modèle peut privilégier la lettre d’une instruction au détriment du comportement que vous aviez en tête. Des règles générales ou rigides risquent d’influencer son comportement de manière inattendue, surtout si plusieurs règles se recoupent.

Employez avec discernement les termes qui imposent une contrainte, comme must, only, never et always. Réservez-les aux comportements réellement obligatoires. Si vous les utilisez simplement pour insister, l’assistant risque de devenir rigide, excessivement prudent ou incapable de gérer des exceptions raisonnables.

Privilégiez une règle au champ d’application précis :

Pour les opérations d’écriture qui modifient les données de l’utilisateur, demandez confirmation avant d’appeler l’outil.

Évitez les règles trop générales :

Demandez toujours confirmation avant de faire quoi que ce soit.

La règle générale peut entraîner des demandes de confirmation inutiles pour des opérations sans risque en lecture seule, comme vérifier le statut d’une commande, consulter les disponibilités ou lire les informations d’un compte.

Exemple d’interprétation littérale

Recommandations générales pour la rédaction des prompts :

  • Formulez explicitement vos instructions au lieu de laisser le modèle deviner votre intention.
  • Évitez les termes contraignants sauf si le comportement doit impérativement être respecté.
  • Réduisez autant que possible les consignes contradictoires.
  • Soyez prudent lorsque vous superposez des règles de priorité ou qu’elles entrent en concurrence.
  • Testez les prompts progressivement. Une légère reformulation peut modifier considérablement le comportement.
  • Lors d’une migration depuis un modèle Realtime antérieur, prévoyez de restructurer certains prompts pour obtenir les meilleurs résultats.

Réglez séparément la langue et l’accent

La langue et l’accent nécessitent des consignes distinctes.

L’accent d’une personne ne permet pas de déterminer la langue dans laquelle elle souhaite échanger. Elle peut parler anglais avec un accent hindi, espagnol, français ou mandarin et attendre une réponse en anglais.

Évitez les instructions linguistiques trop générales comme celles-ci :

Imitez la façon de parler de l’utilisateur.
Répondez naturellement dans la langue de l’utilisateur.
Changez de langue lorsque c’est approprié.
Parlez comme quelqu’un de la région.
Adaptez-vous à l’accent de l’utilisateur.

Avec de telles instructions, le modèle risque de changer de langue à cause d’un accent, d’un mot de remplissage, d’une brève marque d’écoute ou d’un mot étranger isolé.

Règles pour répondre en anglais

## Langue

Répondez en anglais par défaut.

- Ne déduisez pas la langue du seul accent.
- Pour identifier la langue, ignorez les brèves hésitations, les marques d’écoute et les mots étrangers isolés.
- Changez de langue uniquement si l’utilisateur le demande explicitement ou formule un propos substantiel dans une autre langue.
- Si vous avez un doute sur la langue, posez une courte question de clarification au lieu de deviner.
- Utilisez la même langue pour les préambules, les transitions orales, les messages relatifs aux outils et les réponses finales.
- L’adaptation de l’accent ne doit pas modifier la langue de réponse.

Règles pour les échanges multilingues

## Langue

Répondez en anglais par défaut, sauf si l’utilisateur emploie clairement une autre langue.

Changez de langue uniquement dans les cas suivants :

- l’utilisateur demande explicitement d’utiliser une autre langue ;
- l’utilisateur formule un propos substantiel dans une autre langue. Il doit s’agir d’une demande, d’une question ou d’une correction complète. Une salutation, un nom, une adresse, un mot de remplissage ou une expression empruntée à une autre langue ne suffit pas.

Ne changez pas de langue sur la seule base des éléments suivants :

- l’accent ;
- la prononciation ;
- les mots de remplissage ;
- les brèves marques d’écoute ;
- les noms ;
- les adresses ;
- les mots étrangers isolés.

En cas de doute, demandez :

« Préférez-vous que je continue en anglais ou en [LANGUAGE] ? »

Réglage de l’accent

gpt-realtime-2 suit plus fidèlement les instructions relatives à l’accent, mais un prompt vague peut entraîner une variation progressive de l’accent ou un changement de langue involontaire.

Pour de meilleurs résultats, précisez :

  • l’accent souhaité ;
  • les caractéristiques qui doivent rester stables ;
  • le débit, l’accentuation et la prosodie recherchés ;
  • si l’adaptation de l’accent doit influencer le choix de la langue.

Au lieu de :

Prenez un accent australien.

Utilisez :

## Accent

Parlez anglais avec un léger accent australien.

- Gardez le même accent du premier au dernier mot.
- Prononcez les voyelles comme on le ferait naturellement en anglais australien, en restant facile à comprendre.
- N’exagérez pas l’accent.
- Ne changez pas de langue de réponse en fonction de l’accent de l’utilisateur.

Voix personnalisées

Utilisez les voix personnalisées lorsque les voix standard ne répondent pas de façon fiable aux exigences de votre marque, à l’accent recherché ou aux caractéristiques d’un personnage.

Un prompt peut guider l’accent, le débit et la façon de s’exprimer, mais il ne remplace pas entièrement la conception d’une voix. Si votre cas d’usage exige une identité vocale de marque constante ou une reproduction fidèle d’un accent, envisagez les voix personnalisées.

Seuls les clients approuvés ont accès aux voix personnalisées. Contactez l’équipe chargée de votre compte pour en demander l’accès.

Suivez l’état des sessions longues

gpt-realtime-2 fait passer la fenêtre de contexte en temps réel de 32 000 à 128 000 tokens, ce qui le rend mieux adapté aux sessions longues. Pour une conversation soutenue dans les deux sens, 128 000 tokens correspondent approximativement à une à deux heures d’audio brut. Cette durée varie selon les appels d’outils, le raisonnement interne, les données ajoutées au contexte et les autres caractéristiques de la session.

Pour les cas d’usage à contexte long, gpt-realtime-2 donne les meilleurs résultats lorsqu’il peut distinguer les informations à jour, les éléments de contexte et les sources à écarter en cas de contradiction. Structurez les données au lieu de compter sur le modèle pour déduire l’ordre de priorité des sources à partir d’une transcription brute ou d’un grand volume de contexte non organisé.

Utilisez un modèle structuré si vous commencez une session avec beaucoup de contexte : données récupérées, historique de conversation, politiques, résumés, notes sur le compte ou documents de référence.

Migrez depuis un modèle Realtime antérieur

Lors d’une migration depuis un modèle Realtime antérieur, examinez le comportement que définit le prompt au lieu de vous limiter à en transférer le texte.

  1. Utilisez Codex ou un modèle de raisonnement performant pour restructurer le prompt selon les dernières recommandations Realtime. Incluez un lien vers ce guide afin que la migration s’appuie sur les pratiques recommandées.
  2. Réglez l’effort de raisonnement sur low au lieu de conserver la valeur par défaut. Augmentez-le uniquement pour les workflows qui exigent une planification plus approfondie.
  3. Vérifiez que les noms d’outils, les paramètres, les énumérations, les schémas JSON et les autres réglages correspondent à l’implémentation prévue.
  4. Supprimez les exemples obsolètes. Ajoutez des exemples courts pour le déroulement nominal, les ambiguïtés, les interruptions, les appels d’outils et les solutions de repli.
  5. Comparez des conversations représentatives avant et après la migration. Recherchez les régressions à l’aide d’une évaluation existante et documentez les changements de comportement intentionnels.
  6. Effectuez une dernière vérification de cohérence. Assurez-vous que le prompt distingue clairement les exigences impératives, les comportements par défaut, les règles d’utilisation des outils, les règles de sécurité et les solutions de repli.
  7. Lancez les évaluations, examinez des échecs représentatifs et ajustez le prompt jusqu’à obtenir de façon fiable les comportements attendus.

Étapes suivantes

Pour GPT-Live :

Pour Realtime :