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

Délégation et outils dans GPT-Live

Connectez un agent backend et transmettez ses résultats vérifiés à la conversation en direct.

GPT-Live délègue le raisonnement et l’utilisation des outils à un backend pendant qu’il mène la conversation vocale. Le backend peut s’appuyer sur le modèle Responses configuré ou, avec la délégation côté client, sur tout modèle, agent ou service que votre application exploite. Dans les deux modes, votre application gère les autorisations, les confirmations, les données métier et l’état des tâches.

Le guide de rédaction des prompts explique comment guider le modèle en direct lorsqu’il délègue des tâches ou utilise des outils.

Les exemples d’événements de cette page utilisent connection, une connexion WebSocket Live principale ou auxiliaire déjà établie selon les guides de connexion. Sur une connexion principale, attendez session.started avant d’appeler une fonction utilitaire d’envoi d’événements. Une connexion auxiliaire est déjà rattachée à une session en cours.

Choisissez un mode de délégation

Avec la délégation via Responses, GPT-Live appelle le modèle Responses de votre choix, lui fournit le contexte de la conversation et réintègre les résultats du backend dans la conversation en direct. Avec la délégation côté client, votre application prépare le contexte, exécute un agent ou un workflow et renvoie les résultats à GPT-Live.

Commencez par la délégation via Responses si vous souhaitez que GPT-Live gère les requêtes. Choisissez la délégation côté client si vous devez exécuter votre propre workflow ou examiner les résultats avant de les envoyer à GPT-Live.

Critère Privilégiez la délégation via Responses si… Privilégiez la délégation côté client si…
Effort de mise en œuvre Vous souhaitez que GPT-Live prépare les requêtes destinées au backend, gère les connexions et réintègre les résultats dans la conversation. Vous souhaitez développer et exploiter vous-même ces composants.
Vérification des résultats du backend Les résultats du backend peuvent être renvoyés directement à GPT-Live. Votre application doit valider les résultats, en masquer certains éléments, les combiner ou les écarter avant qu’ils ne parviennent à GPT-Live.
Fonctionnalités du backend Les paramètres et outils Responses pris en charge par GPT-Live conviennent à votre workflow. Vous avez besoin d’un autre backend, de plusieurs modèles ou de fonctionnalités de l’API qui dépassent le cadre de la configuration gérée.
Maîtrise du contexte Le contexte conversationnel fourni par GPT-Live convient à votre application. Vous devez choisir précisément quels éléments de l’historique, de la mémoire et de l’état de l’application inclure dans chaque requête au backend.
Règles d’exécution Le modèle configuré et sa boucle d’appels d’outils conviennent à la tâche. Vous devez répartir les étapes entre du code et des modèles selon vos propres règles, prévoir des solutions de repli, définir des points de contrôle ou gérer des budgets sur plusieurs étapes du backend.

Par exemple, un assistant de voyage peut transmettre les questions sur le statut d’un vol au service d’une compagnie aérienne et confier les changements d’itinéraire à un agent de planification distinct. L’application choisit le backend à appeler et le résultat vérifié à renvoyer à GPT-Live.

Dans les deux modes, votre application suit l’avancement de la tâche et vérifie les autorisations ainsi que les confirmations requises de l’utilisateur avant d’exécuter des outils personnalisés. GPT-Live peut continuer à parler pendant que votre application examine un résultat du backend. Si votre application doit déterminer à quel moment l’utilisateur entend le son, ajoutez des commandes de lecture audio.

La délégation côté client exige aussi que votre application conserve le contexte de la conversation. L’événement de délégation contient des métadonnées et ne fournit pas le texte de la tâche. Utilisez les événements de transcription et l’état de l’application pour préparer la requête au backend.

Lors de l’évaluation de votre agent vocal, comparez la latence, le taux de réussite des tâches et le coût sur votre propre charge de travail. Pour des conseils adaptés à votre architecture actuelle, consultez le guide Migration vers GPT-Live.

Choisissez le mode à la création de la session. Pour en changer, démarrez une nouvelle session.

Mode de délégation

Configurez la délégation via Responses

Ajoutez cette configuration de délégation lors de la création de votre session Live. Choisissez le modèle Responses indépendamment du modèle vocal :

export const session = {
  model: "gpt-live-1",
  delegation: {
    type: "responses",
    responses: {
      model: "gpt-6-luna",
      instructions: "[Your backend prompt]",
    },
  },
};

Commencez avec gpt-6-luna ou essayez gpt-6-sol pour des tâches backend plus complexes. Comparez la qualité des réponses et la latence sur vos propres tâches avant de choisir un modèle pour le backend.

Déclarez les outils pris en charge dans delegation.responses.tools. Réglez delegation.responses.tool_choice sur "auto" pour laisser le backend choisir un outil, sur "required" pour imposer un appel d’outil ou sur "none" pour désactiver les appels d’outils. Vous pouvez aussi sélectionner une fonction par son nom.

Réglez delegation.responses.parallel_tool_calls sur true pour autoriser plusieurs appels d’outils dans une réponse ou sur false pour effectuer les appels successivement. Votre application exécute les fonctions personnalisées et vérifie leurs dépendances ainsi que les approbations requises. Ces paramètres s’appliquent une fois que GPT-Live a délégué la tâche. Utilisez le prompt du modèle en direct pour lui indiquer quand déléguer.

La configuration Responses exige un model pour le backend dès la création de la session. Outre les outils ci-dessous, elle permet de définir max_output_tokens (au moins 16 si vous renseignez ce paramètre), service_tier ainsi que les paramètres reasoning et text pris en charge par le modèle backend choisi. La section Réduisez la latence du backend détaille les réglages possibles.

Si le mode Rapide est disponible pour votre modèle et votre projet, envisagez de l’utiliser pour les appels sensibles à la latence. Dans GPT-Live, sélectionnez-le avec delegation.responses.service_tier: "priority".

Envoyez session.update avec les modifications dans session.delegation.responses pour mettre à jour le modèle backend, les instructions, les outils, tool_choice ou d’autres paramètres pris en charge pendant la conversation. Les paramètres omis conservent leur valeur actuelle.

Pour passer de la délégation via Responses à la délégation côté client ou inversement, créez une nouvelle session Live. Si vous réglez delegation sur null, vous sélectionnez le mode client. Si vous envoyez cette mise à jour à une session Responses en cours, elle échoue avec l’erreur immutable_field_update.

Ces paramètres reprennent des concepts familiers de Responses, mais Live ne prend en charge qu’une partie des fonctionnalités de l’API Responses autonome. Live fournit le contexte de la conversation et déclenche le travail délégué. Configurez le backend au niveau de la session. La commande Live response.create utilise cette configuration et n’accepte pas le corps d’une requête Responses autonome.

Ajoutez des outils hébergés

Ajoutez la recherche web, la recherche de fichiers, l’Interpréteur de code, le shell distant ou la génération d’images à delegation.responses.tools. Consultez les guides correspondants pour connaître la configuration, les modèles compatibles et les ressources nécessaires. Responses exécute ces outils et renvoie automatiquement leurs résultats.

Pour le shell, utilisez un conteneur hébergé, éventuellement avec des Skills. Si vous venez d’importer des Skills, attendez que la version référencée soit accessible en lecture avant de démarrer la session Live. Avec le shell local, votre application doit exécuter les appels. Live ne prend pas en charge le paramètre de shell domain_secrets.

Ajoutez MCP et d’autres outils

La délégation via Responses prend également en charge MCP, la recherche d’outils, les appels d’outils par programmation, les fonctions et outils personnalisés, l’utilisation de l’ordinateur, le shell local et l’application de correctifs. Consultez les guides correspondants pour la configuration. Transmettez les résultats de l’application et les décisions d’approbation en suivant la procédure de reprise de Live.

Live transmet à Responses les valeurs MCP authorization et headers que vous fournissez, mais les omet dans la configuration de session qu’il renvoie à votre application. Vous n’avez pas besoin de les renvoyer lorsque vous modifiez d’autres paramètres, comme les instructions. Si vous remplacez delegation.responses.tools, incluez à nouveau les informations d’authentification MCP.

Gérez les erreurs de configuration

Live valide les paramètres Responses de manière asynchrone après le démarrage et à chaque modification des paramètres. Les événements session.started et session.updated n’attendent pas cette validation. Écoutez les événements error portant le code responses_validation_failed et consultez leur message pour identifier le paramètre non pris en charge ou la ressource inaccessible. La session reste ouverte et conserve les paramètres envoyés. Corrigez-les avec session.update.

Par exemple, si le champ version d’un Skill contient un nombre tel que 1, vous obtenez une erreur non fatale responses_validation_failed pour session.start ou session.update. Le message d’erreur indique le champ invalide et le type attendu sans attendre response.create. Utilisez error.client_event_id pour retrouver l’événement de configuration correspondant. Pour poursuivre dans la même session, supprimez la configuration d’outil invalide avec session.update. Indiquez les versions sous forme de chaînes, par exemple "1".

La validation ne garantit pas que les outils pourront ensuite s’exécuter. L’accès aux ressources et la disponibilité des outils peuvent changer. Continuez donc à traiter les erreurs du backend pendant les tâches déléguées. La configuration d’outils hébergés peut entraîner l’initialisation de ressources, comme des conteneurs, pendant la validation.

Orientez la conversation en direct depuis votre application

La délégation via Responses gère le workflow du backend, mais votre application peut toujours envoyer du contexte directement au modèle GPT-Live. Si vous suivez l’appel via une connexion WebSocket auxiliaire ou la connexion principale qui transporte les événements, vous pouvez utiliser session.instructions.append, session.thinking.append ou session.commentary.append avec delegation_id: null. Par exemple, un garde-fou fondé sur la transcription peut ajouter une instruction pour réorienter la conversation. Cette instruction guide le modèle en direct sans modifier le prompt du backend Responses ni annuler le travail en cours.

Traitez les événements de délégation via Responses

Pour une tâche confiée à Responses, session.delegation.created contient target: "responses" et un response_id. Les événements Responses suivants arrivent dans une enveloppe response.event :

{
  "type": "response.event",
  "event_id": "event_response_1",
  "delegation_id": "item_9tA2cB6n2V8c4X1z7Q5r9",
  "event": {
    "type": "response.output_text.delta",
    "sequence_number": 4,
    "item_id": "msg_123",
    "output_index": 0,
    "content_index": 0,
    "delta": "The forecast is",
    "logprobs": []
  }
}

Lorsque l’événement de premier niveau est de type response.event, choisissez le traitement à appliquer selon envelope.event.type. Conservez le delegation_id de l’enveloppe pour associer l’événement du backend à sa délégation. Votre gestionnaire peut également recevoir d’autres événements imbriqués du cycle de vie de Responses que ceux présentés ici.

Ces événements imbriqués indiquent la progression des outils hébergés et contiennent les citations, les fichiers et les images générées. Pour recueillir les résultats, lisez les événements individuels correspondant aux éléments de sortie et aux images partielles. Les instantanés du cycle de vie transmis omettent les tableaux de sortie. Utilisez les API Responses de fichiers ou de conteneurs correspondantes pour télécharger les fichiers. Pour les événements contenant des images ou des artefacts volumineux, utilisez une connexion WebSocket ou auxiliaire, car la taille maximale d’un message peut être plus faible sur un canal de données WebRTC.

La parole en direct et le travail délégué se poursuivent indépendamment. La fin d’une réponse du backend ne suffit pas à établir que l’utilisateur a entendu la réponse. Pour la partie orale de l’interaction, utilisez la transcription et l’audio de sortie de Live.

Renvoyez les résultats des outils et les approbations

Pour les outils qui nécessitent une intervention de l’application, récupérez les appels complets dans les événements imbriqués response.output_item.done. Exécutez l’action autorisée ou vérifiez son approbation, puis envoyez l’élément correspondant avec response.item.create :

Élément reçu Élément de résultat
function_call function_call_output
custom_tool_call custom_tool_call_output
computer_call computer_call_output
Appel local shell_call shell_call_output
apply_patch_call apply_patch_call_output
tool_search_call avec execution: "client" tool_search_output avec execution: "client" et les outils trouvés dans tools
mcp_approval_request mcp_approval_response

Associez les résultats aux appels avec call_id. Pour les décisions d’approbation MCP, attribuez plutôt à approval_request_id la valeur du champ id de la demande d’approbation, puis réglez approve sur true ou false. Un mcp_call terminé n’exige pas à lui seul de résultat du client. Respectez le schéma de résultat de chaque outil, y compris les métadonnées caller pour les appels de fonctions par programmation et les confirmations de sécurité requises pour l’utilisation de l’ordinateur.

Envoyez les résultats de tous les appels en attente, puis envoyez response.create. Le simple ajout d’un élément ne relance pas le backend. S’il manque des résultats, vous obtenez l’erreur tool_outputs_required, ou function_call_outputs_required si seuls des résultats de fonctions manquent. Le backend rejette les doublons et les résultats dont le type ne correspond pas à l’appel.

Vous pouvez envoyer les résultats et demander la reprise avant que le backend ait terminé sa réponse en cours. Une fois accepté, response.create attend la fin de cette réponse. Ne le renvoyez pas. Si le backend émet ensuite d’autres appels, envoyez leurs résultats, puis un nouveau response.create.

Exécutez une fonction personnalisée et renvoyez son résultat

Récupérez les appels de fonctions complets dans les événements imbriqués response.output_item.done. L’élément de fonction complet contient call_id, name et arguments. Un événement signalant la fin des arguments ne suffit pas à identifier l’appel.

Conservez l’identifiant de réponse fourni par l’événement imbriqué response.created ainsi que le delegation_id de l’enveloppe. Recueillez les appels de fonctions de la réponse dans les événements response.output_item.done. Utilisez cette liste pour déterminer quels résultats d’outils envoyer avant de poursuivre.

Les événements du cycle de vie transmis, y compris response.completed, contiennent response.output: [] même lorsque des appels de fonctions attendent des résultats. Ces événements contiennent aussi un tableau tools vide et instructions: null, et n’ont pas de champ input. Pour récupérer les appels de fonctions, lisez les événements de chaque élément de sortie.

Après avoir exécuté l’opération autorisée, ajoutez le résultat sous forme d’élément Responses :

export function sendUpdate(connection) {
  connection.send({
    type: "response.item.create",
    event_id: "tool_result_1",
    item: {
      type: "function_call_output",
      call_id: "call_123",
      output: '{"status":"confirmed","order_id":"order_123"}',
    },
  });
}

Demandez ensuite explicitement la reprise de la réponse :

export function sendUpdate(connection) {
  connection.send({
    type: "response.create",
    event_id: "continue_1",
  });
}

Envoyez un résultat avec response.item.create pour chaque appel de fonction en attente, puis envoyez response.create pour que le backend poursuive sa réponse. response.item.create ne donne pas lieu à un accusé de réception distinct en cas de succès. Continuez à traiter les erreurs et les événements imbriqués du cycle de vie de Responses.

Ces deux commandes exigent la délégation via Responses. La commande Live response.create utilise la configuration du backend enregistrée dans la session. Utilisez le contenu d’événement présenté ci-dessus et configurez le modèle backend ainsi que les autres paramètres au niveau de la session.

Partez du prompt existant de votre backend

Prenez comme point de départ le prompt de votre agent textuel. Conservez ses instructions de tâche et ses règles métier dans le backend. Adaptez les instructions qui supposent un échange écrit ou un contrôle direct de la parole. Expliquez comment traiter les transcriptions vocales et renvoyer des résultats utiles. Faites respecter les autorisations et les exigences de confirmation dans votre application.

## Contexte de la conversation vocale
Vous aidez un assistant qui participe à une conversation vocale en direct.
Les transcriptions peuvent contenir des erreurs, des phrases inachevées
et des corrections apportées par la suite. Appuyez-vous sur le contexte
le plus récent et sur les données vérifiées. Si un détail nécessaire reste
incertain, demandez une précision à son sujet au lieu de le deviner.

## Instructions pour la tâche
[Vos instructions pour la tâche, vos règles métier, les outils disponibles
et les confirmations requises.]

## Renvoyez le résultat
Indiquez les faits pertinents, l’état actuel de la tâche et la prochaine étape.
Attendez que l’outil ou le service confirme la réussite de l’action avant
d’annoncer qu’elle est terminée. Si le résultat reste incertain, dites-le
et précisez ce qu’il faut vérifier.

Conservez dans le backend les données structurées volumineuses, les longues sorties d’outils et le Markdown destiné à l’affichage. Fournissez les faits pertinents à GPT-Live et laissez-le choisir comment les exprimer. Un résultat d’outil concis ne nécessite pas d’appel supplémentaire à un modèle pour être reformulé à l’oral.

Avec la délégation côté client, renvoyez le résultat directement à GPT-Live. Avec la délégation via Responses, renvoyez les résultats d’outils ou les approbations requis pour que le backend poursuive son travail. Les outils hébergés poursuivent leur exécution sans que l’application ait à fournir de résultats.

Choisissez le bon type de mise à jour

Choisissez l’événement selon l’usage que GPT-Live doit faire du contenu :

Contenu à envoyer Événement
Instructions pour une conversation en direct, par exemple une mention à communiquer ou une consigne pour cesser de parler session.instructions.append
Informations destinées au raisonnement interne, que le modèle n’énonce pas à réception mais peut utiliser pour répondre aux questions pertinentes de l’utilisateur session.thinking.append
Informations que le modèle doit communiquer à voix haute en reformulant le texte ajouté session.commentary.append

Ces trois événements attendent dans content une simple chaîne de caractères, limitée à 500 tokens par ajout. Incluez delegation_id. Pour une mise à jour concernant une tâche, utilisez l’identifiant de la délégation côté client d’origine. Pour le contexte général de la session, utilisez null. Tout identifiant non nul doit correspondre à une délégation côté client connue. Les instructions s’appliquent toujours à la session en direct. Un identifiant ne les transforme pas en prompt distinct pour le backend.

Pour accueillir l’appelant, incluez les consignes de salutation dans un message developer de session.input à la création de la session. Après session.started, envoyez une seule fois les mêmes consignes avec session.commentary.append, en veillant à ce que l’entrée audio soit active et en fournissant un event_id unique et delegation_id: null. Le modèle peut reformuler le texte, et l’accusé de réception ne confirme ni la prise de parole ni la lecture audio. La section Saluez l’appelant avant qu’il ne parle présente la séquence complète et le contrôle de la lecture par l’application si vous avez besoin d’une formulation exacte ou de vérifier que le message a bien été diffusé.

L’ajout d’une instruction peut interrompre la prise de parole ou le comportement en cours du modèle. Utilisez cette possibilité lorsque l’application doit réorienter la conversation. Si un outil ou une action doit aussi être bloqué, faites respecter ce blocage dans l’état de l’application.

Pour signaler la progression sans prise de parole pendant une tâche gérée côté client :

export function sendUpdate(connection) {
  connection.send({
    type: "session.thinking.append",
    event_id: "availability_progress",
    delegation_id: "item_123",
    content: "Checking Thursday availability. No appointment has been booked.",
  });
}

Pour une réservation confirmée, envoyez le résultat que l’utilisateur doit entendre :

export function sendUpdate(connection) {
  connection.send({
    type: "session.commentary.append",
    event_id: "appointment_result",
    delegation_id: "item_123",
    content: "Your appointment is confirmed for Thursday at 2:00 PM",
  });
}

N’envoyez ce résultat qu’une fois la réservation effectivement enregistrée. Pour une instruction qui concerne toute la session, utilisez session.instructions.append avec delegation_id: null.

Par exemple, si votre application bloque une demande en vertu de ses garde-fous, vous pouvez réorienter la conversation :

export function sendUpdate(connection) {
  connection.send({
    type: "session.instructions.append",
    event_id: "guardrail_block_17",
    delegation_id: null,
    content:
      "Stop speaking about that request. Briefly explain that you cannot help with it, then wait for the user.",
  });
}

L’instruction n’annule pas le travail du backend. Bloquez l’action concernée et gérez les opérations déjà en cours dans votre application.

Les accusés de réception correspondants sont session.thinking.appended, session.commentary.appended et session.instructions.appended. Associez leur client_event_id à l’event_id que vous avez envoyé. L’accusé de réception est émis au moment estimé de l’intégration du contexte, sans attendre la fin de la prise de parole ou de la lecture audio. Pour connaître les délais et le traitement des erreurs, consultez la section Quand le contexte parvient au modèle.

Envoyez des faits et de brefs points d’avancement que GPT-Live pourra utiliser dans la conversation. Le contenu transmis avec session.thinking.append peut influencer les réponses orales ultérieures. Conservez les secrets et le raisonnement privé du backend dans votre application.

Désactivez les confirmations automatiques pendant l’exécution des outils

Avec la délégation côté client, vous pouvez annuler la confirmation automatique en attente en envoyant une mise à jour silencieuse du contexte avant la génération de cette confirmation.

Définissez delegation.acknowledgement_delay_ms à la création de la session pour laisser à votre application le temps d’envoyer la mise à jour. Par exemple, utilisez cette configuration de délégation côté client :

{
  "delegation": {
    "type": "client",
    "acknowledgement_delay_ms": 800
  }
}

Dès que vous recevez session.delegation.created, envoyez session.thinking.append avec un champ content vide. Utilisez un event_id unique et copiez event.delegation.id dans delegation_id. Envoyez cet événement avant d’attendre le résultat du backend :

{
  "type": "session.thinking.append",
  "event_id": "event_quiet_progress_1",
  "delegation_id": "item_9tA2bF3h7K9m2P5q8R1s4",
  "content": ""
}

Poursuivez le travail du backend. Lorsque le résultat a été vérifié et peut être communiqué à voix haute, envoyez-le avec session.commentary.append et le même identifiant de délégation. Pour donner des précisions sur l’avancement, vous pouvez aussi inclure un message factuel tel que "Lookup in progress." dans la mise à jour du contexte de raisonnement. Cela annule également la confirmation en attente sans demander au modèle de communiquer cette mise à jour à voix haute.

Tout ajout au raisonnement ou au commentaire annule toutes les confirmations automatiques en attente dans la session, y compris celles des autres délégations. Il n’arrête pas l’audio déjà généré et n’empêche pas le modèle de prendre la parole de sa propre initiative. Le délai détermine le moment où la confirmation automatique est demandée. Le modèle peut prendre la parole plus tôt. Consultez la référence sur la configuration de la délégation côté client et l’ajout au contexte de raisonnement pour connaître le contrat de ces événements.

Pour l’événement session.thinking.appended, associez son client_event_id à l’événement que vous avez envoyé. Cela confirme que le contexte a été transmis, sans garantir le silence. Testez l’audio obtenu sur votre propre charge de travail. Si vous devez garantir le silence, utilisez le contrôle de la lecture par l’application.

Envoyez des mises à jour exactes et utiles

Pour les tâches de longue durée, envoyez une mise à jour lorsqu’un changement mérite d’être signalé, par exemple lorsqu’une étape se termine, qu’un délai devient significatif ou que l’utilisateur doit répondre à une question.

Utilisez session.thinking.append pour signaler la progression en arrière-plan en mode client. Utilisez session.commentary.append si la mise à jour mérite d’être communiquée à voix haute.

Pour les mises à jour orales, envoyez session.commentary.append avec un contenu qui correspond à l’état vérifié de la tâche :

État Exemple de contenu
En cours « Je vérifie les créneaux disponibles. »
Terminé « Votre rendez-vous est confirmé pour jeudi à 14 h. »
Échec « Ce créneau n’est plus disponible. »
Annulation confirmée « Votre rendez-vous a été annulé. »

Lorsque l’utilisateur modifie sa demande, mettez à jour la tâche en cours dans votre application. Par exemple, s’il choisit finalement jeudi au lieu de vendredi, utilisez jeudi pour la suite et ignorez les résultats de la demande obsolète concernant vendredi. Gérez toute annulation dans le backend et vérifiez qu’elle a abouti avant de l’annoncer à l’utilisateur. Une interruption de la conversation vocale laisse le travail du backend se poursuivre.

Avant de relancer un appel d’outil qui a échoué, vérifiez si l’action initiale a déjà eu lieu. Par exemple, la perte d’une réponse ne doit pas entraîner une deuxième réservation. Si l’issue est incertaine, indiquez-le et proposez une prochaine étape utile.

Partagez le contexte de l’interface

Fournissez à GPT-Live un résumé concis de la page ou de la tâche en cours, des sélections pertinentes et des faits qui aident à interpréter des références telles que « cette option ». Produisez le résumé directement à partir de l’état de l’application. Aucun appel supplémentaire à un modèle n’est nécessaire pour le mettre en forme.

Envoyez le contexte de l’interface au démarrage de la session et lorsque l’état pertinent change. Évitez de renvoyer un état inchangé. Si plusieurs changements se succèdent rapidement, regroupez-les dans un bref résumé du dernier état. Indiquez explicitement les modifications apportées aux sélections précédentes :

  • Contexte initial : « L’utilisateur examine une réservation au restaurant pour deux personnes le 6 août à 19 h. Aucune réservation n’a encore été effectuée. »
  • Correction : « L’heure sélectionnée est désormais 20 h. L’heure choisie précédemment était 19 h. »

Dans les deux modes de délégation, utilisez session.thinking.append avec delegation_id: null pour les mises à jour du contexte en arrière-plan. Conservez le HTML complet, les arbres DOM, les données JSON volumineuses et les journaux d’interaction dans votre application ou votre backend. Traitez le contenu de la page comme des données de référence, sans en faire des instructions.

Acceptez les saisies au clavier

Transmettez au backend les valeurs saisies, comme les numéros de commande, en tant que données fournies par l’utilisateur pour qu’il puisse en reprendre le texte exact.

Avec la délégation via Responses, placez un message utilisateur dans la file d’attente du backend :

export function sendUpdate(connection) {
  connection.send({
    type: "response.item.create",
    event_id: "typed_order_number",
    item: {
      type: "message",
      role: "user",
      content: [
        {
          type: "input_text",
          text: "My order number is A0042.",
        },
      ],
    },
  });
}

Envoyez response.create lorsque vous êtes prêt à lancer ou à reprendre le travail du backend. Si le backend attend des résultats de fonctions, renvoyez d’abord tous les résultats requis. Placer du texte dans la file d’attente n’annule pas le travail déjà en cours.

Ajoutez des images et du contexte visuel

Pour aider un appelant à discuter d’une photo ou du contenu d’un écran, envoyez l’image et le contexte pertinent depuis votre application à un backend capable d’analyser des images. Le backend interprète l’image et renvoie du texte que GPT-Live peut utiliser dans la conversation. L’interface audio de Live n’accepte pas directement les images.

Avec la délégation via Responses, configurez un modèle backend capable d’analyser des images. Placez un élément d’entrée image pris en charge par Responses dans la file d’attente avec response.item.create, puis envoyez response.create pour lancer ou reprendre le travail du backend. Avant de poursuivre, renvoyez tous les résultats d’outils et toutes les approbations encore attendus. Consultez la section Traitez les événements de délégation via Responses.

Séparez les images destinées au backend de session.input, qui initialise l’interface Live avec un historique textuel au démarrage. Consultez le guide Images et vision pour connaître les formats d’image pris en charge et les limites des modèles.

Réduisez la latence du backend

Réduisez le délai entre la demande de travail au backend et l’obtention d’un résultat utile à la conversation. Mesurez la latence à chaque étape pour localiser les retards. Comparez le délai avant une réponse orale utile et le taux de réussite des tâches sur les mêmes scénarios. Pour guider vos évaluations, consultez le Cookbook sur l’évaluation des agents vocaux.

Délégation via Responses

Live gère des connexions WebSocket persistantes à Responses et prépare à l’avance les paramètres de requête déjà connus. Il peut également réutiliser l’état d’une réponse précédente si la connexion active et cet état le permettent. Pour en mesurer l’effet sur votre charge de travail, relevez le temps de réponse et l’utilisation du cache indiquée.

Ajustez les paramètres du backend dans delegation.responses :

  • model : choisissez le modèle chargé du raisonnement et de la sélection des outils indépendamment du modèle vocal.
  • reasoning.effort : trouvez le compromis entre la durée du raisonnement et la qualité d’exécution de la tâche à l’aide des valeurs prises en charge par ce modèle.
  • service_tier : utilisez auto, default, flex ou priority selon les valeurs prises en charge par le modèle et les droits d’accès du projet. auto suit la configuration du projet. Évaluez les performances et le coût de l’offre choisie.

Mettez à jour les paramètres pris en charge pendant la session avec session.update. Vos outils personnalisés continuent de s’exécuter dans votre application. Les appels de service lents, les files d’attente et la mise en mémoire tampon des résultats d’outils peuvent donc retarder la réponse même lorsque Live gère la connexion à Responses. Renvoyez rapidement chaque résultat d’outil requis et demandez au backend de poursuivre sa réponse.

Réagissez aux fragments de transcription

Le traitement des fragments de transcription dans votre application est facultatif et fonctionne avec les deux modes de délégation. Les fragments de transcription des propos de l’utilisateur et de l’assistant arrivent via WebSocket ou le canal de données WebRTC. Vous pouvez les traiter avec la logique de l’application ou un modèle léger pour commencer le travail avant la réception d’un événement de délégation. Vous pouvez aussi utiliser la transcription elle-même pour déclencher des opérations gérées par l’application.

Utilisez cette approche pour :

  • Réduire l’attente. Lancez une recherche anticipée dès que vous disposez d’assez d’informations. Par exemple, vérifiez les disponibilités pendant que l’utilisateur continue de décrire ses préférences.
  • Appliquer les garde-fous. Examinez la transcription à mesure qu’elle s’enrichit pour détecter les demandes ou les réponses nécessitant une intervention. Consultez la section Appliquez des garde-fous à la conversation.
  • Adapter la conversation. Repérez les formulations qui traduisent de la confusion ou de la frustration, puis adaptez l’interaction ou envoyez une instruction ciblée.
  • Mettre à jour l’interface. Mettez en évidence les commandes pertinentes, préremplissez les champs suggérés ou affichez les résultats dès qu’ils sont disponibles.

Dans les applications web, utilisez le canal de données WebRTC pour les sous-titres et les mises à jour locales de l’interface. Lorsque votre serveur traite les transcriptions pour appliquer des garde-fous, effectuer des vérifications avec un modèle léger ou lancer des appels d’outils anticipés, utilisez une connexion WebSocket auxiliaire pour recevoir les événements et guider directement la même session GPT-Live.

Traitez le texte accumulé lorsque de nouvelles informations significatives apparaissent. Un fragment peut être incomplet et la suite des propos peut modifier la demande. Écartez les résultats obsolètes, coordonnez les opérations avec les tâches déléguées par la suite pour éviter les doublons et appliquez vos contrôles habituels d’autorisation et de confirmation avant toute action ayant des conséquences importantes.

Renvoyez les conclusions ou les instructions à GPT-Live avec l’événement d’ajout adapté à la mise à jour. Pour les opérations lancées en dehors d’une délégation côté client, utilisez delegation_id: null. Votre application applique les modifications de l’interface et gère l’exécution et l’annulation des appels d’outils.

Optimisations communes

Les mêmes améliorations du backend profitent aux deux modes de délégation :

  • Adaptez le modèle et l’effort de raisonnement à la tâche. Comparez les configurations qui répondent à vos exigences de précision. Réduisez l’effort de raisonnement si la tâche reste exécutée de façon fiable.
  • Renvoyez des réponses concises. Transmettez les faits et l’état de la tâche dont GPT-Live a besoin pour poursuivre la conversation. Évitez les longues explications et les appels supplémentaires à un modèle dans le seul but de reformuler les résultats pour l’oral.
  • Réduisez les délais liés aux outils et les appels inutiles. Lancez les opérations autorisées dès que leurs entrées sont disponibles, réutilisez les résultats tant qu’ils restent valides et évitez de répéter une recherche déjà effectuée.
  • Exécutez les opérations indépendantes en parallèle. Plusieurs recherches indépendantes peuvent s’exécuter simultanément. Respectez les dépendances entre actions et les confirmations requises. parallel_tool_calls permet au modèle de demander plusieurs appels. Votre application reste chargée de planifier et d’exécuter ses fonctions personnalisées.

Consultez le guide Optimisation de la latence pour des conseils généraux sur Responses, et le guide Mise en cache des prompts pour réutiliser les entrées stables.

Vérifiez l’interaction de bout en bout

Vérifiez que le backend a exécuté l’action prévue et que le client a diffusé la réponse orale attendue. Par exemple, après une réservation réussie, vérifiez à la fois l’enregistrement de la réservation et l’audio diffusé. Le backend peut terminer son travail même si la réponse orale est interrompue. Testez donc ces deux résultats séparément.

En plus de l’identifiant de délégation GPT-Live, attribuez un identifiant d’opération distinct à chaque action de l’application et un numéro de révision de la tâche à chaque modification de la demande. Utilisez ces enregistrements pour reconnaître les opérations déjà terminées après une reconnexion ou une nouvelle tentative, et pour écarter les résultats de demandes obsolètes.

Appuyez-vous sur le guide Évaluation des agents vocaux pour réaliser des tests reproductibles. Si vous utilisez déjà une boucle d’appels d’outils Realtime ou un backend en chaîne, suivez le guide Migration vers GPT-Live.