Migrez vers GPT-Live

Depuis Realtime API

Commencez par le guide de conception de prompts pour GPT-Live. Répartissez votre prompt existant entre le modèle vocal et le backend au lieu de le copier intégralement dans session.instructions. Conservez le style de conversation et les consignes de délégation dans le prompt vocal ; déplacez les workflows détaillés et les instructions d’utilisation des outils vers le backend.

Avant : le modèle Realtime gère la parole et sélectionne des fonctions telles que check_availability et book_appointment. Votre application exécute les fonctions et renvoie leurs résultats.

Après : GPT-Live gère la parole et délègue le traitement des tâches. Le backend sélectionne les mêmes fonctions ; votre application continue de les valider et de les exécuter. Les étapes présentées ici utilisent la délégation à Responses. Si vous conservez un agent externe, utilisez plutôt l’adaptateur client.

Fonctionnement de la délégation à Responses

Configurez le modèle backend, les instructions et les outils dans delegation.responses. Lorsque GPT-Live décide qu’une demande nécessite un traitement par le backend, le service Live appelle ce modèle Responses et lui fournit le contexte pertinent de la conversation. Le backend raisonne sur la tâche et sélectionne les outils. Votre application continue d’exécuter les fonctions personnalisées, de faire respecter les autorisations et de renvoyer leurs résultats.

Pour l’assistant de prise de rendez-vous :

1. L’utilisateur demande quels rendez-vous sont disponibles le vendredi, et GPT-Live délègue la demande.
2. Le backend Responses demande l’exécution de check_availability.
3. Votre application exécute la fonction, renvoie son résultat et poursuit la réponse du backend.
4. GPT-Live utilise la réponse du backend pour discuter des créneaux disponibles avec l’utilisateur.

GPT-Live peut poursuivre la conversation pendant que le backend travaille. La fin de ce traitement ne signifie pas que l’assistant a fini de parler. Consultez Délégation et outils pour la configuration et le déroulement complet des événements.

Préservez les décisions fondées sur l’audio

Vérifiez si les décisions actuelles concernant les outils reposent sur des indices acoustiques, comme le bip d’une messagerie vocale ou le rythme d’un message d’accueil enregistré. GPT-Live entend l’audio entrant, mais son interface vocale délègue le travail au lieu d’émettre des appels de fonction structurés classiques. En mode client, session.delegation.created contient des métadonnées et des informations temporelles, sans audio brut, texte de la tâche ni arguments d’outils analysés. Le backend auquel le travail est délégué ne reçoit pas automatiquement la forme d’onde.

Pour détecter les répondeurs, acheminez explicitement l’audio entrant vers un détecteur capable de traiter l’audio. Une architecture à évaluer, gérée par l’application, consiste à exécuter une session Realtime distincte en parallèle de GPT-Live pendant une partie de l’appel :

1. Envoyez une copie de l’audio entrant de l’appel aux deux sessions.
2. Configurez le détecteur pour qu’il communique sa classification par un appel de fonction structuré. Vérifiez chaque résultat par rapport à votre schéma, rejetez les résultats obsolètes et conservez un état inconnu lorsque les indices sont insuffisants. Prévoyez la possibilité de réviser la décision à partir d’indices ultérieurs.
3. Envoyez à GPT-Live les éléments de contexte fiables et pertinents, et appliquez la politique de votre application à la lecture de l’audio sortant.

Distinguez la classification humain ou machine de la possibilité de commencer l’enregistrement. Reconnaître une messagerie vocale ne permet pas d’établir que le message d’accueil et le bip sont terminés, ni que l’enregistrement peut commencer. Le résultat d’un classificateur ou un accusé de réception du contexte n’autorise pas non plus la lecture audio. Appuyez-vous sur Adaptez vos garde-fous et sur les commandes de lecture pour faire appliquer cette décision dans le circuit audio contrôlé par votre application.

Testez le cas d’un bref « allô » qui se prolonge en message d’accueil de messagerie vocale, les messages de filtrage des appels et le cas d’une personne qui décroche pendant la messagerie vocale. Si vous arrêtez le détecteur avant la fin de l’appel, testez le cas d’une personne qui décroche après cet arrêt. Choisissez quand arrêter le détecteur en fonction de ces tests et de son coût supplémentaire. Une première classification comme humain ne suffit pas à établir que la poursuite de la détection est inutile.

Adaptez la connexion et le cycle de vie de l’audio

Remplacez la configuration de session Realtime par la procédure de connexion à GPT-Live. Vérifiez à nouveau le démarrage et le format audio de votre transport. WebRTC transporte l’audio sur les pistes multimédias et les événements JSON sur le canal de données. Une connexion WebSocket principale transporte l’audio dans des événements JSON.

Si votre application Realtime utilise une connexion serveur pour surveiller l’appel ou appliquer des garde-fous, adaptez-la à la connexion auxiliaire de GPT-Live. Suivez Adaptez vos garde-fous pour modifier les vérifications de la conversation et la lecture audio.

Génération et lecture audio : Dans Realtime, response.output_audio.done marque la fin de la génération audio, tandis que response.done marque la fin du flux de réponse. Ces événements peuvent également survenir lorsqu’une réponse est interrompue ou échoue ; vérifiez response.status dans response.done. Aucun des deux ne confirme que la lecture de l’audio mis en mémoire tampon est terminée. Par exemple, le serveur peut avoir terminé la génération alors qu’il reste encore une seconde d’audio à lire côté client. Pilotez un indicateur « en train de parler » à partir de l’état de la lecture.

Sous-titres : La transcription d’entrée représente les paroles de l’utilisateur ; la transcription de sortie représente les paroles générées par l’assistant. Lorsque la transcription d’entrée est activée, Realtime envoie des mises à jour via conversation.item.input_audio_transcription.delta et une transcription finale via conversation.item.input_audio_transcription.completed. Un delta est un nouveau fragment de texte. Dans GPT-Live, ajoutez chaque fragment à la suite des sous-titres du locuteur correspondant, indépendamment de l’autre, car l’écoute et la parole peuvent se chevaucher. Un fragment ne constitue ni un tour de parole complet ni une confirmation de lecture audio. Consultez Affichez les sous-titres pour un exemple de mise en œuvre de l’affichage.

Dans GPT-Live, response.create lance ou poursuit le traitement délégué à Responses. Il n’autorise pas le modèle vocal à prendre la parole. Pour le démarrage, les salutations, les interruptions et la fermeture d’une session, suivez le guide Gestion des sessions.

Séparez les instructions de conversation de celles du backend

Déplacez les consignes de style de conversation et de délégation dans session.instructions. Déplacez les règles métier et les instructions d’utilisation des outils dans delegation.responses.instructions. Si vous exécutez vous-même le backend, conservez ces règles dans son prompt existant.

Avant : un seul prompt Realtime

Help callers book appointments. Speak briefly. Check availability with the tool,
ask the caller to confirm a slot, then book it. Never claim an unverified booking.

Après : instructions de conversation GPT-Live

Help callers book appointments. Keep spoken replies brief. Delegate availability
checks and booking requests. Ask the caller to confirm the proposed slot.
Only announce a booking when the backend reports that it succeeded.

Après : instructions du backend

Use the appointment tools to check current availability. Before booking, verify
that the caller confirmed the exact slot and still has permission to book it.
Apply the latest correction. Return verified availability, booking, or failure
status with the date, time, and time zone.

Vérifiez les confirmations et les autorisations dans votre application avant d’exécuter un outil. Les instructions des prompts guident les modèles ; elles ne font pas respecter ces contrôles. Pour concevoir vos prompts, consultez Conception de prompts pour les modèles vocaux.

Adaptez vos gestionnaires de fonctions

Conservez l’implémentation de check_availability et de book_appointment. Déplacez leurs définitions de session.tools ou response.tools dans Realtime vers delegation.responses.tools, en utilisant le schéma de fonction de Responses. Déplacez les paramètres de sélection des outils vers delegation.responses.tool_choice et delegation.responses.parallel_tool_calls. Consultez Configurez la délégation Responses.

La fonction renvoie toujours un résultat associé à son call_id d’origine. Ce qui change, c’est l’endroit où votre gestionnaire reçoit l’appel et envoie le résultat :

Par exemple, une fois que check_availability a renvoyé un créneau vérifié, votre résultat change comme suit. Ces messages sont échangés dans une session déjà connectée ; call_availability représente l’identifiant d’appel réel que vous avez reçu.

Avant : résultat Realtime

12345678{
  "type": "conversation.item.create",
  "item": {
    "type": "function_call_output",
    "call_id": "call_availability",
    "output": "{\"available\":true,\"slot_id\":\"slot_friday_14\",\"booked\":false}"
  }
}

Après : résultat GPT-Live

1
2
3
4
5
6
7
8
9
10
11export function sendUpdate(connection) {
  connection.send({
    type: "response.item.create",
    event_id: "availability_result_1",
    item: {
      type: "function_call_output",
      call_id: "call_availability",
      output: '{"available":true,"slot_id":"slot_friday_14","booked":false}',
    },
  });
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17from openai.resources.live.live import AsyncLiveConnection
from openai.resources.live.sideband import AsyncSidebandConnection
from openai.types.responses.response_input_item_param import ResponseInputItemParam


async def send_update(
    connection: AsyncLiveConnection | AsyncSidebandConnection,
) -> None:
    item: ResponseInputItemParam = {
        "type": "function_call_output",
        "call_id": "call_availability",
        "output": '{"available":true,"slot_id":"slot_friday_14","booked":false}',
    }
    await connection.response.item.create(
        event_id="availability_result_1",
        item=item,
    )

Après avoir envoyé tous les résultats de fonction requis, poursuivez le traitement du backend :

1
2
3
4
5
6export function sendUpdate(connection) {
  connection.send({
    type: "response.create",
    event_id: "continue_availability_1",
  });
}

1
2
3
4
5
6
7
8
9
10from openai.resources.live.live import AsyncLiveConnection
from openai.resources.live.sideband import AsyncSidebandConnection


async def send_update(
    connection: AsyncLiveConnection | AsyncSidebandConnection,
) -> None:
    await connection.response.create(
        event_id="continue_availability_1",
    )

Pour la migration initiale, définir parallel_tool_calls sur false simplifie la gestion des résultats. Collectez les appels à partir des événements de finalisation des éléments de sortie, même si un instantané de fin de cycle de vie contient output: []. Un événement de fin des arguments ne fournit pas à lui seul le nom de la fonction ni call_id. Suivez la procédure complète de gestion des résultats de fonction pour la collecte, l’envoi des sorties et la gestion des erreurs.

Préservez le contexte et appliquez les corrections

La délégation Responses fournit au backend le contexte pertinent de la conversation vocale. Conservez dans votre application l’état des rendez-vous qui fait autorité : créneau sélectionné, créneau confirmé, autorisations, opération en cours et résultat. L’historique des conversations Live peut être compacté ; il ne constitue pas votre registre de réservations.

Si l’utilisateur dit « Finalement, plutôt vendredi » alors qu’une recherche pour jeudi est en cours, mettez à jour la révision de la tâche et invalidez la confirmation du créneau précédent. Avant d’effectuer une réservation, vérifiez que ses arguments correspondent toujours à la tâche et à la confirmation actuelles. Pour chaque appel de fonction en attente que votre application refuse, renvoyez un résultat indiquant fidèlement qu’il est devenu obsolète ou a été annulé, puis complétez le lot de sorties requis avant de poursuivre. Si une réservation a déjà abouti, faites le point sur ce résultat et sur la modification demandée avant d’entreprendre une autre action.

Les fragments de transcription peuvent arriver en retard ou se chevaucher avec les paroles de l’assistant. Ajoutez chaque delta exactement tel qu’il est reçu et utilisez start_ms et end_ms pour regrouper les fragments à l’affichage. Ces horodatages ne constituent ni des limites définitives de tours de parole ni des horodatages de lecture mot à mot. Clarifiez les dates, les noms et les nombres importants lorsque l’intention est incertaine. Consultez Gestion des sessions pour la gestion des transcriptions et du contexte.

Images et contexte à l’écran : Si votre application Realtime accepte des images, acheminez-les vers un backend doté de capacités de vision et renvoyez le texte pertinent à GPT-Live. La délégation côté client et la délégation Responses prennent toutes deux en charge ce schéma. Consultez Ajoutez des images et du contexte visuel.

Depuis un agent textuel ou un pipeline en chaîne

Avant : un agent textuel reçoit des demandes écrites et utilise ses outils et son état enregistré. Un pipeline vocal en chaîne, ou en cascade, ajoute une étape de transcription audio en texte avant cet agent et une étape de synthèse vocale après celui-ci.

Après : GPT-Live fournit l’interface vocale et délègue l’exécution des tâches à votre agent existant. Dans un pipeline en chaîne, il remplace les étapes distinctes de transcription audio en texte et de synthèse vocale. Conservez les modèles, les instructions, les outils, le workflow et l’état persistant dans votre backend tant qu’ils restent adaptés à la tâche.

Connectez votre agent existant

Définissez delegation sur {"type":"client"} lors de la configuration de la session. Votre application reçoit une notification de ce type :

123456789{
  "type": "session.delegation.created",
  "offset_ms": 1000,
  "delegation": {
    "id": "item_appointment_1",
    "type": "delegation",
    "target": "client"
  }
}

La notification contient des métadonnées, et non le texte de la demande, les arguments des outils ou une transcription complète. Conservez la valeur réelle de delegation.id sans la modifier. Composez l’entrée de l’agent à partir des fragments récents de transcription étiquetés par rôle et de l’état vérifié de l’application, en incluant la tâche active et la dernière correction. Une délégation peut arriver avant qu’une phrase complète n’apparaisse dans la transcription. Si le contexte disponible ne permet pas de déterminer la demande, recueillez davantage de contexte ou demandez des précisions avant d’agir.

Dans une application textuelle, vous pouvez transmettre directement le dernier message de l’utilisateur à votre agent. Avec GPT-Live, ajoutez un adaptateur qui fournit ce contexte et renvoie un résultat concis et vérifié :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25async function handleDelegation(event, app) {
  if (
    event.type !== "session.delegation.created" ||
    event.delegation?.target !== "client"
  )
    return;

  const context = app.readContext();
  if (!context) return; // Retain the notice; resolve the request before acting.

  const summary = await app.runAgent({
    revision: context.revision,
    recentConversation: context.recentConversation,
    task: context.task,
  });

  if (app.currentRevision() !== context.revision) return;

  app.send({
    type: "session.commentary.append",
    event_id: crypto.randomUUID(),
    delegation_id: event.delegation.id,
    content: summary,
  });
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40from collections.abc import Awaitable, Callable
from dataclasses import dataclass
from uuid import uuid4

from openai.resources.live.live import AsyncLiveConnection
from openai.resources.live.sideband import AsyncSidebandConnection
from openai.types.live.server_event import ServerEvent


@dataclass(frozen=True)
class Context:
    revision: int
    recent_conversation: str
    task: str


async def handle_delegation(
    event: ServerEvent,
    connection: AsyncLiveConnection | AsyncSidebandConnection,
    *,
    read_context: Callable[[], Context | None],
    run_agent: Callable[[Context], Awaitable[str]],
    current_revision: Callable[[], int],
) -> None:
    if (
        event.type != "session.delegation.created"
        or event.delegation.target != "client"
    ):
        return
    context = read_context()
    if context is None:
        return  # Retain the notice; resolve the request before acting.
    summary = await run_agent(context)
    if current_revision() != context.revision:
        return
    await connection.session.commentary.append(
        event_id=str(uuid4()),
        delegation_id=event.delegation.id,
        content=summary,
    )

L’adaptateur utilise des fonctions de rappel de l’application pour lire le contexte, exécuter votre agent et vérifier la révision actuelle de la tâche ; il ne s’agit pas de méthodes du SDK. La fonction de rappel chargée du contexte renvoie un instantané prêt à l’emploi contenant les échanges récents et la tâche en cours, ou ne renvoie aucun instantané si la demande reste floue. La fonction de rappel chargée de l’agent invoque votre agent existant et renvoie un résumé vérifié de 500 tokens au maximum. En JavaScript, la fonction de rappel send fournie par l’application envoie l’événement JSON sur votre connexion Live. En Python, l’adaptateur envoie la mise à jour directement via l’objet connection du SDK.

Si le contexte n’est pas prêt, conservez la notification et invoquez de nouveau l’adaptateur après avoir clarifié la demande. Avant d’invoquer cet adaptateur, réservez le traitement de la délégation dans votre application afin qu’une notification reçue en double ne puisse pas lancer deux fois la même opération. Gérez les autorisations, les confirmations, les identifiants d’opération et les décisions de nouvelle tentative dans votre backend. Le contrôle de révision empêche cet adaptateur d’annoncer un résultat obsolète ; le backend doit également vérifier la révision actuelle avant toute action ayant un effet externe, comme une réservation.

Pour l’assistant de prise de rendez-vous, le contexte doit préciser la date et le fuseau horaire demandés, les créneaux proposés précédemment, tout créneau confirmé et la dernière correction. Un résultat de disponibilité doit indiquer qu’un créneau est disponible et qu’aucune réservation n’a été effectuée. Ne renvoyez une confirmation de réservation qu’une fois celle-ci réussie. Consultez Délégation côté client pour l’ensemble de la configuration et du flux de résultats.

Acheminez les mises à jour et les corrections

Conservez les sorties structurées des outils et les détails du workflow dans votre backend. Renvoyez à GPT-Live de brèves mises à jour factuelles :

• Utilisez session.thinking.append pour signaler l’avancement en arrière-plan, par exemple une recherche toujours en cours.
• Utilisez session.commentary.append pour un résultat vérifié que l’utilisateur doit entendre.
• Utilisez session.instructions.append pour les consignes de comportement rédigées par l’application.

Les trois acceptent un champ content sous forme de simple chaîne de caractères de 500 tokens au maximum et exigent delegation_id. Utilisez l’identifiant de délégation côté client d’origine pour les traitements associés, ou null pour le contexte général de la session. Associez les accusés de réception des ajouts aux événements correspondants à l’aide de client_event_id. L’acceptation ne prouve pas qu’une prise de parole ou une lecture audio a eu lieu. Consultez Envoyez le bon type de mise à jour.

Lorsque l’utilisateur dit « Finalement, plutôt vendredi », mettez à jour la tâche active et sa révision, invalidez toute confirmation pour jeudi et orientez l’agent existant vers la demande corrigée. Décidez s’il faut annuler ou modifier la recherche en cours, ou la laisser se terminer. Écartez tout résultat obsolète avant de le renvoyer à GPT-Live. Une interruption de la parole n’annule pas une opération du backend, et une demande d’annulation ne prouve pas qu’une action a été annulée.

Le traitement du backend peut se poursuivre après la fin de la session vocale. Enregistrez durablement son état dans votre application. Lors d’une interaction vocale ultérieure, démarrez une nouvelle session avec le contexte enregistré pertinent ; consultez Gestion des sessions.

Adaptez les protections pour le texte et la parole

Un agent textuel peut terminer et valider une réponse avant de l’afficher. Un pipeline en chaîne peut valider la réponse complète avant de l’envoyer à la synthèse vocale. GPT-Live peut parler pendant que le traitement du backend est encore en cours. Retenir un résultat d’outil ou suspendre la poursuite du traitement du backend ne bloque donc pas toute prise de parole.

Suivez Adaptez vos garde-fous pour conserver vos contrôles et tenir compte de la parole en continu.

Maintenez les saisies textuelles reliées à votre backend existant. Traitez une correction saisie comme une mise à jour de la même tâche et envoyez le contexte pertinent et vérifié à la session vocale. Consultez Acceptez les saisies textuelles et Gardez les mises à jour exactes et utiles.