Migrez vers GPT-Live

Depuis Realtime API

Commencez par le guide de rédaction de prompts pour GPT-Live. Répartissez votre prompt existant entre le modèle vocal et le backend plutôt que de le copier intégralement dans session.instructions. Conservez le style de conversation et les consignes de délégation dans le prompt vocal. Transférez les workflows détaillés et les instructions d’utilisation des outils dans le prompt du 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, et votre application continue de vérifier et d’exécuter les appels. Les étapes ci-dessous 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, ses instructions et ses outils dans delegation.responses. Lorsque GPT-Live détermine qu’une demande nécessite un traitement côté backend, le service Live appelle ce modèle Responses et lui fournit les éléments pertinents de la conversation. Le backend analyse 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 les résultats.

Dans le cas de l’assistant de prise de rendez-vous :

1. L’utilisateur demande quels créneaux sont disponibles vendredi, et GPT-Live délègue sa demande.
2. Le backend Responses demande l’appel de check_availability.
3. Votre application exécute la fonction, renvoie son résultat et demande au backend de poursuivre sa réponse.
4. GPT-Live s’appuie sur la réponse du backend pour discuter des créneaux disponibles avec l’utilisateur.

GPT-Live peut continuer à parler pendant que le backend travaille. Suivez séparément la tâche du backend et la lecture audio : utilisez les résultats des outils pour mettre à jour l’état de la tâche et l’état du lecteur audio pour mettre à jour l’indicateur de prise de parole. Consultez la section Délégation et outils pour la configuration et la séquence complète des événements.

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

Remplacez la procédure d’ouverture de session Realtime par la procédure de connexion à GPT-Live. Vérifiez de nouveau comment votre transport démarre et quel format audio il utilise. WebRTC transmet l’audio sur les pistes multimédias et les événements JSON sur le canal de données. Une connexion WebSocket principale transmet 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 pour utiliser la connexion auxiliaire de GPT-Live. Suivez la section Adaptez vos garde-fous pour modifier les contrôles de la conversation et la lecture audio.

Génération et lecture : pilotez l’indicateur de prise de parole à partir du lecteur audio. Le serveur peut avoir terminé la génération alors qu’il reste une seconde d’audio dans la file d’attente du lecteur. Dans Realtime, response.output_audio.done signale la fin de la génération et response.done marque la fin du flux de réponse. Vérifiez response.status pour détecter une interruption ou un échec. GPT-Live ne fournit pas d’événement équivalent pour signaler la fin de chaque réponse orale.

Sous-titres : lorsque la transcription de l’entrée est activée, Realtime envoie des fragments de texte via conversation.item.input_audio_transcription.delta et la transcription finale via conversation.item.input_audio_transcription.completed. Dans GPT-Live, ajoutez chaque fragment aux sous-titres de l’appelant ou de l’assistant. Les deux peuvent évoluer en même temps. Votre application choisit comment regrouper le texte et suit la lecture à partir du lecteur audio. Consultez la section Affichez les sous-titres.

Utilisez response.create pour lancer ou poursuivre le traitement délégué à Responses. GPT-Live écoute la conversation et décide quand prendre la parole. Pour le démarrage, les salutations, les interruptions et la clôture d’une session, consultez le guide Gestion des sessions.

Répartissez les instructions entre la conversation et le backend

Pour migrer un assistant Realtime vers GPT-Live, partez de votre prompt existant. Transférez les instructions sur le style oral et les tours de parole dans le prompt Live et ajoutez les règles qui précisent quand déléguer. Conservez les instructions relatives aux tâches et les procédures d’utilisation des outils dans le prompt du backend.

Si vous ajoutez une interface vocale à un agent textuel, réutilisez le prompt de son backend et rédigez un prompt Live pour les échanges oraux.

Préservez la cohérence de l’expérience

Conservez le rôle de votre assistant, le public auquel il s’adresse et sa mission. Préservez les détails qui façonnent la conversation :

• Les salutations, les présentations et les mentions à communiquer oralement, y compris les formulations et l’ordre imposés.
• Les exigences de langue et de prononciation, par exemple « Parlez anglais. »
• La personnalité, la chaleur, l’empathie, le niveau de langue et le rythme.
• Le niveau de détail des réponses orales et les exemples qui illustrent le style attendu.
• La façon dont l’assistant manifeste son écoute, laisse la parole à l’utilisateur et réagit aux interruptions.

Même un prompt Live court peut demander des réponses orales détaillées.

Rédigez le prompt Live

Utilisez la structure de prompt recommandée pour définir l’identité de l’assistant, son style oral et son comportement dans la conversation. Conservez les rubriques Backchannel policy et Interruption policy pour préciser comment l’assistant manifeste son écoute et réagit lorsqu’une personne lui coupe la parole.

Live doit connaître les capacités du backend pour savoir quelles demandes lui déléguer. Décrivez ces capacités en langage courant. Placez les noms de fonctions et les schémas des outils dans le backend, qui gère les appels d’outils.

Dans Delegation policy, adaptez les rubriques suivantes à votre application :

• Backend tools : énumérez les capacités de votre application en reprenant les termes du prompt existant. Par exemple : « Vérifiez les créneaux de rendez-vous disponibles et planifiez des rappels téléphoniques. »
• Delegate to the backend when : précisez quand utiliser ces capacités, par exemple « Déléguez la demande lorsque l’utilisateur souhaite planifier un rappel téléphonique. » Incluez les corrections, les confirmations et les nouvelles précisions nécessaires aux tâches en cours.
• Do not delegate to the backend when : décrivez ce que Live peut traiter directement, comme une salutation, une courte demande de précision ou la répétition d’une information tirée de la conversation ou d’un résultat du backend toujours valable.

Décrivez comment Live doit informer l’utilisateur de l’avancement d’une tâche, lui poser la prochaine question du backend ou lui transmettre un résultat vérifié.

Si votre assistant met fin aux appels, indiquez à Live comment prendre congé et déléguer la demande de fin d’appel. Placez l’outil de fin d’appel et la procédure correspondante dans le backend. Par exemple, une procédure peut exiger que l’application termine la lecture du message de fin d’appel, ferme la connexion, annule les calculs en attente et bloque tout nouvel enregistrement. Live prend congé et délègue la demande. Le backend et l’application exécutent les étapes restantes.

Adaptez le prompt du backend

Partez de votre prompt d’origine. Conservez sa formulation, son ordre, ses exemples et sa structure partout où ils restent pertinents. S’il décrit principalement des tâches, vous pouvez en conserver l’essentiel tel quel.

Conservez ici les instructions qui indiquent comment :

• Interpréter la demande de l’utilisateur, appliquer les corrections, recueillir les informations manquantes et suivre l’avancement de la tâche.
• Utiliser les connaissances métier, vérifier les critères d’éligibilité et consulter les données ou les services qui permettent d’établir la réponse.
• Suivre les procédures de recherche, de mise à jour, de confirmation, d’acheminement, de transfert, de rappel téléphonique et de toute autre action prise en charge.
• Appliquer les règles de sécurité, de confidentialité et d’autorisation, gérer les échecs et restreindre les actions après un transfert ou une fin d’appel.
• Préparer des informations exactes, un état d’avancement et la prochaine question à transmettre par l’intermédiaire de Live.

Transférez dans le prompt Live les instructions sur la voix, les salutations, les tours de parole et les conditions de délégation. Adaptez les instructions qui supposent que le backend s’adresse directement à l’utilisateur pour qu’il renvoie les informations à Live. Dans chaque prompt, conservez les limites de sécurité et de confidentialité qui s’appliquent à ce que le modèle peut dire, demander ou faire.

Conservez dans les instructions du backend les noms de fonctions, les exigences relatives aux arguments et les procédures d’utilisation des outils. Placez les définitions des outils dans la configuration des outils du backend. Votre application exécute les outils. Elle vérifie les autorisations, la validité des arguments et les confirmations requises en fonction de l’état actuel de la tâche.

Utilisez le modèle backend pour interpréter les demandes, les corrections et les confirmations dans le contexte de la conversation. Les expressions régulières, les listes de mots-clés et les règles fondées sur des formulations exactes ne permettent pas de saisir un sens qui dépend de propos antérieurs ou d’une correction. Par exemple, « oui » peut confirmer un créneau, indiquer qu’une question a été entendue ou renvoyer à une suggestion antérieure.

Conservez les règles applicables aux tâches déjà en cours lorsque l’appelant interrompt l’assistant, que l’appel est transféré ou qu’il prend fin. L’arrêt de la parole n’interrompt pas le traitement côté backend. Si l’appelant demande une annulation, le backend et l’application doivent la traiter et en communiquer le résultat à Live.

Résolvez les contradictions entre les instructions

Relisez le prompt d’origine et les deux nouveaux prompts pour repérer les instructions contradictoires. Regroupez les instructions répétées et placez les conditions et les exceptions à côté des règles auxquelles elles s’appliquent. Vérifiez les autorisations, les limites sur le nombre de questions, les confirmations et les actions possibles après la fin d’un appel.

Distinguez la demande de l’utilisateur des actions déjà effectuées. Si l’appelant remplace vendredi par jeudi, sa dernière demande indique au backend qu’il doit désormais rechercher un créneau pour jeudi. Les données de réservation lui indiquent si un créneau a déjà été réservé pour vendredi. Vos règles de confirmation et d’autorisation déterminent les modifications qu’il peut ensuite apporter.

Avant d’utiliser les prompts, tranchez les questions de comportement avec les personnes responsables du produit. Par exemple, si une instruction demande de poursuivre une réservation et qu’une autre impose d’arrêter tout traitement lorsque l’appelant interrompt l’assistant, déterminez quel comportement l’application doit adopter. Inscrivez la décision dans les prompts et dans la logique applicative qui la fait respecter.

Vérifiez que chaque action requise dispose d’une implémentation. Pour mettre fin à un appel, il faut pouvoir fermer la connexion. Un simple « au revoir » la laisse ouverte. Si une capacité manque, décidez de l’implémenter ou convenez d’une solution prise en charge avec l’équipe responsable du workflow.

Vérifiez les deux prompts

Comparez les deux prompts au prompt d’origine et vérifiez que chaque comportement requis figure au bon endroit :

• Le prompt Live conserve l’identité de l’assistant, son vocabulaire, son style oral, les mentions qu’il doit communiquer et sa façon de réagir aux interruptions.
• Le prompt du backend conserve les procédures, les faits, les conditions, les exemples, les autorisations et les consignes de gestion des échecs propres aux tâches.
• La délégation couvre les nouvelles demandes, les corrections, les confirmations et les demandes qui mêlent échanges conversationnels et informations sur la tâche.
• Les deux prompts concordent sur le nombre de questions autorisées, le moment où une action est confirmée et la façon de gérer les tâches qui se poursuivent, les annulations, les transferts et la fin des appels.

Placez le prompt Live dans session.instructions. Pour la délégation à Responses, placez le prompt du backend dans session.delegation.responses.instructions. Pour la délégation au client, conservez-le dans la configuration de votre agent. Gardez les définitions des outils côté backend. Consultez la section Délégation et outils pour la configuration et le traitement des résultats.

Vous êtes Rowan, l’assistant de prise de rendez-vous de Northstar Repairs.
Parlez anglais d’un ton calme et répondez brièvement. Saluez l’appelant une seule fois en disant :
« Hello, this is Rowan from Northstar Repairs. How can I help? »
Manifestez votre écoute en quelques mots. Si l’appelant vous interrompt, cessez de parler.

Aidez les appelants à trouver et à réserver un rendez-vous. Pour la date souhaitée et le fuseau
horaire, demandez à l’appelant les précisions qui manquent, puis utilisez check_availability.
Proposez uniquement les créneaux renvoyés. Demandez à l’appelant de confirmer le créneau exact
avant d’appeler book_appointment.
Si l’appelant modifie la date, le fuseau horaire ou le créneau, écartez la confirmation
précédente et vérifiez de nouveau les disponibilités.
N’annoncez la réservation qu’une fois sa réussite confirmée par l’outil. Si le résultat
est incertain, indiquez que la réservation n’est pas confirmée et ne réessayez pas automatiquement.

Vous êtes Rowan, l’assistant de prise de rendez-vous de Northstar Repairs.
Parlez anglais d’un ton calme et répondez brièvement. Saluez l’appelant une seule fois en disant :
« Hello, this is Rowan from Northstar Repairs. How can I help? »

Backchannel policy: Manifestez votre écoute en quelques mots.

Interruption policy: Si l’appelant vous interrompt, cessez de parler et écoutez-le.

Delegation policy:
Backend tools:
- Rendez-vous : vérifiez les créneaux disponibles et réservez des rendez-vous.

Delegate to the backend when:
- L’appelant souhaite trouver ou réserver un rendez-vous.
- L’appelant indique ou corrige une date, un fuseau horaire ou un créneau, ou bien
  répond à une question sur la réservation, y compris pour confirmer un créneau.

Do not delegate to the backend when:
- L’appelant vous salue ou vous demande de répéter un résultat toujours valable.
- Vous avez besoin d’une brève précision pour comprendre sa demande.

Transmettez les questions et les résultats du backend. Proposez uniquement les créneaux qu’il renvoie.
N’annoncez la réservation qu’une fois sa réussite confirmée par le backend.
Si le backend signale un résultat incertain, indiquez que la réservation n’est pas confirmée.

Aidez les appelants à trouver et à réserver un rendez-vous chez Northstar Repairs.
Pour la date souhaitée et le fuseau horaire, demandez à l’appelant les précisions qui manquent,
puis utilisez check_availability. Proposez uniquement les créneaux renvoyés.
Demandez à l’appelant de confirmer le créneau exact avant d’appeler book_appointment.
Si l’appelant modifie la date, le fuseau horaire ou le créneau, écartez la confirmation
précédente et vérifiez de nouveau les disponibilités.
Ne signalez la réservation qu’une fois sa réussite confirmée par l’outil. Si le résultat
est incertain, indiquez que la réservation n’est pas confirmée et ne réessayez pas automatiquement.

Renvoyez les créneaux disponibles, le résultat de la réservation ou la prochaine question
pour que l’assistant vocal les communique à l’appelant. Appuyez-vous sur la conversation et sur
l’état actuel de la tâche pour interpréter les dernières réponses et corrections de l’appelant.

Adaptez vos gestionnaires d’appels de fonctions

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

La fonction renvoie toujours un résultat associé au call_id d’origine. Ce qui change, c’est la façon dont votre gestionnaire reçoit l’appel et transmet le résultat :

Par exemple, une fois que check_availability a renvoyé un créneau vérifié, envoyez l’événement suivant sur votre session connectée. Remplacez call_availability par l’identifiant d’appel que vous avez reçu.

Avant : résultat dans 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 dans 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,
    )

1
2
3
4
5
6
7
8
9
10
11
12
13
14import (
	"context"
	"github.com/openai/openai-go/v3"
	"github.com/openai/openai-go/v3/live"
	"github.com/openai/openai-go/v3/responses"
)

// SendUpdate requires a started Live session.
func SendUpdate(ctx context.Context, connection *live.LiveConnection) error {
	return connection.Send(ctx, live.ClientEventUnionParam{OfResponseItemCreate: &live.ResponseItemCreateEventParam{
		EventID: openai.String("availability_result_1"),
		Item:    responses.ResponseInputItemUnionParam{OfFunctionCallOutput: &responses.ResponseInputItemFunctionCallOutputParam{CallID: openai.String("call_availability"), Output: responses.ResponseInputItemFunctionCallOutputOutputUnionParam{OfString: openai.String("{\"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
17import com.openai.helpers.LiveConnection;
import com.openai.models.live.*;
import com.openai.models.responses.*;

public static void sendUpdate(LiveConnection connection) {
  connection.send(
      ClientEvent.ofResponseItemCreate(
          ResponseItemCreateEvent.builder()
              .eventId("availability_result_1")
              .item(
                  ResponseInputItem.FunctionCallOutput.builder()
                      .callId("call_availability")
                      .output(
                          "{\"available\":true,\"slot_id\":\"slot_friday_14\",\"booked\":false}")
                      .build())
              .build()));
}

1
2
3
4
5
6
7
8
9def send_update(connection)
  connection.send_event(
    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}"
    }
  )
end

Une fois tous les résultats de fonctions requis transmis, demandez au backend de poursuivre le traitement :

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",
    )

1
2
3
4
5
6
7
8
9
10
11
12import (
	"context"
	"github.com/openai/openai-go/v3"
	"github.com/openai/openai-go/v3/live"
)

// SendUpdate requires a started Live session.
func SendUpdate(ctx context.Context, connection *live.LiveConnection) error {
	return connection.Send(ctx, live.ClientEventUnionParam{OfResponseCreate: &live.ResponseCreateEventParam{
		EventID: openai.String("continue_availability_1"),
	}})
}

1
2
3
4
5
6
7
8import com.openai.helpers.LiveConnection;
import com.openai.models.live.*;

public static void sendUpdate(LiveConnection connection) {
  connection.send(
      ClientEvent.ofResponseCreate(
          ResponseCreateEvent.builder().eventId("continue_availability_1").build()));
}

1
2
3def send_update(connection)
  connection.send_event(type: "response.create", event_id: "continue_availability_1")
end

Au début de la migration, définissez parallel_tool_calls sur false pour traiter un seul appel d’outil à la fois. Récupérez chaque appel de fonction dans l’événement interne response.output_item.done et conservez son nom, ses arguments et son call_id. Conservez ces données même si un événement de fin ultérieur contient output: []. Attendez de recevoir l’élément complet avant d’exécuter le gestionnaire. L’événement qui signale la fin des arguments ne contient ni le nom de la fonction ni le call_id. Suivez la procédure complète de traitement des résultats de fonctions pour recueillir les appels, transmettre les résultats et gérer les erreurs.

Conservez le contexte et appliquez les corrections

La délégation à Responses fournit au backend les éléments pertinents de la conversation vocale. Conservez dans votre application les données qui font foi pour le rendez-vous : créneau sélectionné, créneau confirmé, autorisations, opération en cours et résultat. L’historique de conversation de Live peut être compacté et ne tient pas lieu de registre des réservations.

Lorsque l’utilisateur dit « Finalement, vendredi plutôt », enregistrez vendredi comme date de la demande en cours et effacez toute confirmation pour jeudi. Attribuez un nouveau numéro de version à la tâche, par exemple la révision 2, pour que votre application puisse reconnaître les résultats de la demande précédente.

Avant de réserver, vérifiez que la date, le créneau et la confirmation correspondent toujours à la demande en cours. Si vous refusez un appel de fonction en attente parce que l’utilisateur a modifié sa demande, renvoyez un résultat qui indique si l’appel a été ignoré ou annulé, selon ce qui s’est réellement passé. Transmettez un résultat pour chaque appel requis avant de demander au backend de poursuivre.

Si la réservation pour jeudi a déjà abouti, vérifiez son état actuel et traitez la modification demandée avant de tenter une nouvelle réservation.

Conservez chaque fragment de transcription tel que vous l’avez reçu, avec l’identité du locuteur, start_ms et end_ms. Utilisez ces informations pour mettre à jour le sous-titre ou la bulle de discussion de l’appelant ou de l’assistant, même si un fragment arrive en retard ou si les deux parlent en même temps. Déterminez dans votre application où commence et où finit chaque message, et suivez la lecture audio dans votre lecteur. Les horodatages de la transcription n’indiquent pas le moment exact où chaque mot est diffusé. En cas de doute sur l’intention de l’appelant, faites préciser les dates, les noms et les nombres importants. Consultez le guide Gestion des sessions pour le traitement des transcriptions et du contexte.

Images et contenu de l’écran : si votre application Realtime accepte des images, transmettez-les à un backend capable de les analyser et renvoyez à GPT-Live les informations pertinentes sous forme de texte. La délégation au client et la délégation à Responses prennent toutes deux en charge ce fonctionnement. Consultez la section Ajoutez des images et du contexte visuel.

Préservez les décisions qui dépendent de l’audio

Certaines décisions nécessitent le son lui-même, par exemple pour détecter le bip d’une messagerie vocale ou reconnaître un message d’accueil enregistré à son rythme. GPT-Live entend l’appel, mais la délégation ne transmet pas automatiquement l’audio à votre backend. En mode client, session.delegation.created contient un identifiant et des informations temporelles. Votre application fournit le contexte de la demande et tout signal audio dont le backend a besoin.

Pour détecter un répondeur, transmettez explicitement l’audio entrant à un détecteur capable de l’analyser. Vous pouvez évaluer une architecture dans laquelle votre application exécute une session Realtime distincte en parallèle de GPT-Live pendant une partie de l’appel :

1. Envoyez une copie de l’audio entrant aux deux sessions.
2. Demandez au détecteur de communiquer sa classification par un appel de fonction structuré. Vérifiez que chaque résultat respecte votre schéma, rejetez les résultats périmés et conservez l’état « inconnu » si les indices sont insuffisants. Prévoyez de réviser la décision à la lumière de nouveaux indices.
3. Transmettez à GPT-Live les éléments de contexte pertinents et fiables, puis appliquez les règles de votre application à la lecture de l’audio sortant.

Suivez deux décisions distinctes : avez-vous affaire à une personne ou à un répondeur, et le destinataire est-il prêt à enregistrer votre message ? Le détecteur peut reconnaître une messagerie vocale alors que le message d’accueil est encore en cours de lecture. Attendez de disposer des indices requis par votre application avant d’autoriser la diffusion de l’audio sortant. L’accusé de réception de la mise à jour du contexte indique que celle-ci a été acceptée. La décision de lancer la lecture revient toujours à votre application. Appuyez-vous sur la section Adaptez vos garde-fous et sur les commandes de lecture pour faire respecter cette décision dans le circuit audio que votre application contrôle.

Testez un bref « bonjour » qui se révèle être le début d’un message d’accueil enregistré, des annonces de filtrage d’appels et le cas où une personne décroche pendant le message du répondeur. Si vous prévoyez d’arrêter le détecteur avant la fin de l’appel, testez ce qui se passe lorsqu’une personne décroche ensuite. Utilisez ces résultats et le coût supplémentaire du détecteur pour déterminer combien de temps le laisser fonctionner. Incluez des cas où la classification initiale « humain » change à mesure que le détecteur reçoit davantage d’audio.

Depuis un agent textuel ou un pipeline en cascade

Avant : un agent textuel reçoit des demandes écrites et utilise ses outils et son état enregistré. Un pipeline vocal chaîné, ou en cascade, ajoute une étape de transcription de la parole en amont de l’agent et une étape de synthèse vocale en aval.

Après : GPT-Live fournit l’interface vocale et délègue le traitement des tâches à votre agent existant. Dans un pipeline en cascade, il remplace les étapes distinctes de transcription et de synthèse vocale. Conservez dans votre backend les modèles, les instructions, les outils, le workflow et l’état persistant qui 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 semblable à celle-ci :

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

Utilisez cette notification pour lancer le gestionnaire de délégation de votre application. Conservez delegation.id pour pouvoir rattacher le résultat à la même demande. Votre gestionnaire prépare les données d’entrée de l’agent à partir des transcriptions de l’appelant et de l’assistant, ainsi que des données de tâche conservées par votre application. La notification elle-même ne contient ni le texte de la demande ni les arguments d’un outil.

Par exemple, l’agent de prise de rendez-vous pourrait recevoir les éléments suivants :

Appelant : « Finalement, vendredi plutôt. »

Demande en cours : trouver un rendez-vous vendredi dans le fuseau horaire de l’appelant.

Résultat précédent : le créneau de jeudi à 14 h a été proposé.

Confirmation : aucun créneau n’a été confirmé pour vendredi.

Révision de la tâche : 2.

La notification peut arriver avant la fin de la transcription de la phrase. Conservez-la jusqu’à ce que vous disposiez d’un contexte suffisant, ou demandez à l’appelant de préciser sa demande avant d’agir.

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

Avant d’appeler l’adaptateur, enregistrez l’identifiant de délégation pour qu’un seul gestionnaire commence à la traiter. Si la demande manque de clarté, rappelez l’adaptateur lorsque vous disposez du contexte nécessaire.

Votre backend reste responsable des autorisations, des confirmations, des identifiants d’opération et des nouvelles tentatives. Vérifiez la révision actuelle de la tâche avant de modifier une réservation. L’adaptateur vérifie la révision ultérieurement, ce qui empêche seulement l’annonce d’un résultat périmé. Ce contrôle ne peut pas annuler une réservation déjà effectuée.

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,
    )

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
34import (
	"context"
	"crypto/rand"
	"github.com/openai/openai-go/v3"
	"github.com/openai/openai-go/v3/live"
)

type Context struct {
	Revision           int
	RecentConversation string
	Task               string
}

func handleDelegation(ctx context.Context, event live.ServerEventUnion, connection *live.LiveConnection,
	readContext func() *Context, runAgent func(context.Context, Context) (string, error), currentRevision func() int) error {
	if event.Type != "session.delegation.created" || event.AsDelegationCreatedEvent().Delegation.Target != "client" {
		return nil
	}
	snapshot := readContext()
	if snapshot == nil {
		return nil
	} // Retain the notice; resolve the request before acting.
	saved := *snapshot
	summary, err := runAgent(ctx, saved)
	if err != nil {
		return err
	}
	if currentRevision() != saved.Revision {
		return nil
	}
	return connection.Send(ctx, live.ClientEventUnionParam{OfSessionCommentaryAppend: &live.CommentaryAppendEventParam{
		EventID: openai.String(rand.Text()), DelegationID: openai.String(event.AsDelegationCreatedEvent().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
34import com.openai.helpers.LiveConnection;
import com.openai.models.live.*;
import java.util.UUID;
import java.util.concurrent.CompletionStage;
import java.util.function.*;

public record Context(int revision, String recentConversation, String task) {}

public static CompletionStage<Void> handleDelegation(
    ServerEvent event,
    LiveConnection connection,
    Supplier<Context> readContext,
    Function<Context, CompletionStage<String>> runAgent,
    IntSupplier currentRevision) {
  if (!event.isSessionDelegationCreated()
      || !event.asSessionDelegationCreated().delegation().target().toString().equals("client"))
    return java.util.concurrent.CompletableFuture.completedFuture(null);
  var snapshot = readContext.get();
  // Retain the notice; resolve the request before acting.
  if (snapshot == null) return java.util.concurrent.CompletableFuture.completedFuture(null);
  return runAgent
      .apply(snapshot)
      .thenAccept(
          summary -> {
            if (currentRevision.getAsInt() != snapshot.revision()) return;
            connection.send(
                ClientEvent.ofSessionCommentaryAppend(
                    CommentaryAppendEvent.builder()
                        .eventId(UUID.randomUUID().toString())
                        .delegationId(event.asSessionDelegationCreated().delegation().id())
                        .content(summary)
                        .build()));
          });
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18require "openai"
require "securerandom"
Context = Data.define(:revision, :recent_conversation, :task)

def handle_delegation(event, connection, read_context:, run_agent:, current_revision:)
  return unless event.type == :"session.delegation.created" && event.delegation.target == :client

  context = read_context.call
  return if context.nil? # Retain the notice; resolve the request before acting.

  summary = run_agent.call(context)
  return unless current_revision.call == context.revision

  connection.send_event(
    type: :"session.commentary.append", event_id: SecureRandom.uuid,
    delegation_id: event.delegation.id, content: summary
  )
end

Implémentez dans votre application les fonctions de rappel pour le contexte et pour l’agent. La première renvoie les échanges récents et la tâche en cours. Elle ne renvoie aucune valeur tant que la demande manque de clarté. La seconde exécute votre backend existant et renvoie une synthèse vérifiée 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.

Pour l’assistant de prise de rendez-vous, le contexte doit préciser la date et le fuseau horaire demandés, les créneaux déjà proposés, le créneau éventuellement confirmé et la dernière correction. Un résultat de recherche de disponibilités 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 la réservation réussie. Consultez la section Délégation au client pour la configuration complète et les étapes de transmission des résultats.

Acheminez les mises à jour et les corrections

Conservez les résultats structurés des outils et les détails du workflow dans votre backend. Renvoyez à GPT-Live des mises à jour courtes et factuelles :

• Utilisez session.thinking.append pour signaler l’avancement d’une tâche en arrière-plan, par exemple une recherche encore en cours.
• Utilisez session.commentary.append pour transmettre un résultat vérifié que l’utilisateur doit entendre.
• Utilisez session.instructions.append pour transmettre les consignes de comportement définies par votre application.

Les trois commandes acceptent un champ content sous forme de chaîne de texte simple de 500 tokens au maximum et exigent delegation_id. Utilisez l’identifiant de la délégation au client d’origine pour les tâches qui s’y rattachent, ou null pour le contexte général de la session. Associez chaque accusé de réception à la commande envoyée à l’aide de client_event_id. Il confirme que la mise à jour a été acceptée. Utilisez les événements de transcription de l’assistant pour observer les paroles générées, et l’état du lecteur pour suivre leur lecture. Consultez la section Envoyez le type de mise à jour approprié.

Lorsque l’utilisateur dit « Finalement, vendredi plutôt », enregistrez vendredi comme date de la demande en cours, incrémentez son numéro de version et effacez toute confirmation pour jeudi. Transmettez cette correction à votre agent existant. Décidez s’il faut demander l’annulation de la recherche pour jeudi, la modifier ou la laisser se terminer et écarter son résultat.

Vérifiez l’état de la recherche avant d’annoncer son annulation. Traitez cette décision côté backend même si l’utilisateur a déjà interrompu la prise de parole de l’assistant.

Le traitement côté backend peut se poursuivre après la fin de la session vocale. Enregistrez son état dans votre application. Lors d’un échange vocal ultérieur, ouvrez une nouvelle session avec les éléments de contexte enregistrés qui restent pertinents. Consultez le guide Gestion des sessions.

Continuez à transmettre le texte saisi à votre agent

Continuez à transmettre les saisies de texte à votre backend existant. Traitez une correction saisie au clavier comme une mise à jour de la même tâche et transmettez à la session vocale les éléments de contexte pertinents et vérifiés. Consultez les sections Acceptez les saisies de texte et Veillez à l’exactitude et à la pertinence des mises à jour.

Adaptez les protections du texte et de la parole

Un agent textuel ou un pipeline en cascade peut valider une réponse complète avant de l’afficher ou de la lire à voix haute. Avec GPT-Live, la conversation et le traitement côté backend se déroulent simultanément. Si chaque réponse orale doit faire l’objet d’un contrôle avant que l’utilisateur ne l’entende, placez ce contrôle dans le circuit de lecture audio que votre application maîtrise. Retenir un résultat du backend ne suffit pas à suspendre toute prise de parole.

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