Freigeben über

So verwenden Sie die GPT-4o Echtzeit-API für Sprache und Audio (Vorschau)

  • Artikel

Hinweis

Dieses Feature ist zurzeit als öffentliche Preview verfügbar. Diese Vorschauversion wird ohne Vereinbarung zum Servicelevel bereitgestellt und sollte nicht für Produktionsworkloads verwendet werden. Manche Features werden möglicherweise nicht unterstützt oder sind nur eingeschränkt verwendbar. Weitere Informationen finden Sie unter Zusätzliche Nutzungsbestimmungen für Microsoft Azure-Vorschauen.

Die Azure OpenAI GPT-4o Echtzeit-API für Sprache und Audio ist Teil der GPT-4o-Modellfamilie, die latenzarme Unterhaltungsinteraktionen mit Sprachein- und ausgabe unterstützt. Die GPT-4o Realtime-API wurde entwickelt, um Unterhaltungsinteraktionen in Echtzeit und mit niedriger Latenz zu verarbeiten. Die Echtzeit-API eignet sie sich hervorragend für Anwendungsfälle, die Liveinteraktionen zwischen einem Benutzer und einem Modell umfassen, z. B. Kundendienstmitarbeiter, Sprachassistenten und Echtzeitübersetzer.

Die meisten Benutzer der Echtzeit-API müssen Ton von einem Endbenutzer in Echtzeit bereitstellen und empfangen, einschließlich Anwendungen, die WebRTC oder ein Telefoniesystem verwenden. Die Echtzeit-API ist nicht für die direkte Verbindung mit Endbenutzergeräten konzipiert und basiert auf Clientintegrationen zum Beenden von Endbenutzer-Audiodatenströmen.

Unterstützte Modelle

Derzeit unterstützt nur die Version gpt-4o-realtime-preview: 2024-10-01-preview unterstützt Echtzeitaudio.

Das gpt-4o-realtime-preview-Modell ist für globale Bereitstellungen in den Regionen USA, Osten 2 und Schweden, Mitte verfügbar.

Wichtig

Das System speichert Ihre Prompts und Vervollständigungen, wie im Abschnitt „Datennutzung und Zugriff auf Missbrauchsüberwachung der dienstspezifischen Produktbedingungen für Azure OpenAI Service beschrieben wird, es sei denn, die eingeschränkte Ausnahme gilt nicht. Die Missbrauchsüberwachung wird für die Verwendung der gpt-4o-realtime-preview-API auch für Kunden aktiviert, die ansonsten zur modifizierten Missbrauchsüberwachung zugelassen sind.

API-Unterstützung

Die Unterstützung für die Echtzeit-API wurde erstmals in der API-Version 2024-10-01-preview hinzugefügt.

Hinweis

Weitere Informationen zur API und Architektur finden Sie im „Azure OpenAI GPT-4o real-time audio“-Repository auf GitHub.

Erste Schritte

Bevor Sie GPT-4o-Echtzeitaudio verwenden können, benötigen Sie Folgendes:

Schritte zum Bereitstellen und Verwenden des gpt-4o-realtime-preview-Modells finden Sie in der Schnellstartanleitung zu Echtzeitaudio.

Weitere Informationen zur API und Architektur finden Sie in den verbleibenden Abschnitten in diesem Handbuch.

Beispielcode

Derzeit besteht die schnellste Möglichkeit, mit der Entwicklung mit der GPT-4o-Echtzeit-API zu beginnen, darin, den Beispielcode aus dem GitHub-Repository Azure OpenAI GPT-4o real-time audio herunterzuladen.

Das Azure-Samples/aisearch-openai-rag-audio-Repo enthält ein Beispiel für die Implementierung der RAG-Unterstützung in Anwendungen, die VoIP als Benutzeroberfläche verwenden, unterstützt von der GPT-4o-Echtzeit-API für Audio.

Verbindung und Authentifizierung

Die Realtime-API (über /realtime) basiert auf der WebSockets-API, um die vollständig asynchrone Streamingkommunikation zwischen Endbenutzer und Modell zu erleichtern.

Wichtig

Gerätedetails wie das Aufzeichnen und Rendern von Audiodaten liegen außerhalb des Umfangs der Echtzeit-API. Sie sollte im Kontext eines vertrauenswürdigen Zwischendiensts verwendet werden, der sowohl Verbindungen mit Endbenutzern als auch Modellendpunktverbindungen verwaltet. Verwenden Sie sie nicht direkt von nicht vertrauenswürdigen Endbenutzergeräten.

Auf die Echtzeit-API wird über eine sichere WebSocket-Verbindung mit dem /realtime-Endpunkt Ihrer Azure OpenAI-Ressource zugegriffen.

Sie können einen vollständigen Anforderungs-URI erstellen, indem Sie Folgendes verketten:

  • Das sichere WebSocket-Protokoll (wss://)
  • Den Hostnamen Ihres Azure OpenAI-Ressourcenendpunkts, z. B. my-aoai-resource.openai.azure.com
  • Den openai/realtime-API-Pfad
  • Einen api-version-Abfragezeichenfolge-Parameter für eine unterstützte API-Version, z. B. 2024-10-01-preview
  • Einen deployment-Abfragezeichenfolge-Parameter mit dem Namen Ihrer gpt-4o-realtime-preview-Modellimplementierung

Das folgende Beispiel ist ein gut konstruierter /realtime-Anforderungs-URI:

wss://my-eastus2-openai-resource.openai.azure.com/openai/realtime?api-version=2024-10-01-preview&deployment=gpt-4o-realtime-preview-deployment-name

Zum Authentifizieren:

  • Microsoft Entra (empfohlen): Verwenden Sie die tokenbasierte Authentifizierung mit der /realtime-API für eine Azure OpenAI Service-Ressource mit aktivierter verwalteter Identität. Wenden Sie ein abgerufenes Authentifizierungstoken mithilfe eines Bearer-Tokens mit dem Authorization-Header an.
  • API-Schlüssel: api-key kann auf eine von zwei Arten bereitgestellt werden:
    • Verwenden eines api-key-Verbindungsheaders für die Prehandshake-Verbindung. Diese Option ist in einer Browserumgebung nicht verfügbar.
    • Verwenden eines api-key-Abfragezeichenfolge-Parameters für den Anforderungs-URI. Abfragezeichenfolgenparameter werden bei Verwendung von https/wss verschlüsselt.

Architektur der Echtzeit-API

Sobald die WebSocket-Verbindungssitzung zu /realtime aufgebaut und authentifiziert ist, findet die funktionale Interaktion über Ereignisse zum Senden und Empfangen von WebSocket-Nachrichten statt. Diese Ereignisse nehmen jeweils die Form eines JSON-Objekts auf.

Abbildung mit Realtime-API-Authentifizierung und Verbindungssequenz

Ereignisse können parallel gesendet und empfangen werden, und Anwendungen sollten sie in der Regel sowohl gleichzeitig als auch asynchron behandeln.

  • Ein Anrufer auf Clientseite stellt eine Verbindung mit /realtime her, wodurch eine neue session gestartet wird.
  • Eine session erstellt Automatisch eine standardmäßige conversation. Mehrere gleichzeitige Unterhaltungen werden nicht unterstützt.
  • Die conversation sammelt Eingabesignale, bis ein response-Ereignis ausgelöst wird, entweder über ein direktes Ereignis durch den Anrufer oder automatisch per VAD (Voice Activity Detection, Sprechaktivitätserkennung).
  • Jede response besteht aus einer oder mehreren items, die Nachrichten, Funktionsaufrufe und andere Informationen kapseln können.
  • Jede Nachricht item hat content_part, so dass mehrere Modalitäten (Text und Audio) in einem einzigen Element dargestellt werden können.
  • Das session verwaltet die Konfiguration der Behandlung von Anrufereingaben (z. B. Benutzerton) und der gemeinsamen Erzeugung von Ausgaben.
  • Jedes vom Aufrufer initiierte response.create kann, falls gewünscht, einen Teil des Verhaltens der Ausgabe response außer Kraft setzen.
  • Das vom Server erstellte item und das content_part in den Nachrichten können asynchron und parallel aufgefüllt werden. So können beispielsweise Ton-, Text- und Funktionsinformationen gleichzeitig und nach dem Rotationsprinzip empfangen werden.

Sitzungskonfiguration

Häufig ist das erste Ereignis, das vom Aufrufer in einer neu eingerichteten /realtime-Sitzung gesendet wird, eine session.update-Nutzlast. Dieses Ereignis steuert ein breites Spektrum an Ein- und Ausgabeverhalten, wobei Eigenschaften der Ausgabe- und Antwortgenerierung später über das response.create-Ereignis außer Kraft gesetzt werden können.

Das session.update-Ereignis kann verwendet werden, um die folgenden Aspekte der Sitzung zu konfigurieren:

  • Die Transkription von Benutzeraudioeingaben wird über die input_audio_transcription-Eigenschaft der Sitzung aktiviert. Das Angeben eines Transkriptionsmodells (whisper-1) in dieser Konfiguration ermöglicht die Übermittlung von conversation.item.audio_transcription.completed-Ereignissen.
  • Die Verarbeitung von Sprecherwechseln wird von der turn_detection-Eigenschaft gesteuert. Diese Eigenschaft kann auf none oder server_vad festgelegt werden, wie im Abschnitt Eingabeaudiopuffer und Verarbeiten von Sprecherwechseln beschrieben.
  • Tools können so konfiguriert werden, dass der Server externe Dienste oder Funktionen aufrufen kann, um die Unterhaltung anzureichern. Tools werden als Teil der tools-Eigenschaft in der Sitzungskonfiguration definiert.

Es folgt ein Beispiel-session.update, das verschiedene Aspekte der Sitzung, einschließlich der Werkzeuge, konfiguriert. Alle Sitzungsparameter sind optional und können bei Bedarf weggelassen werden.

{
  "type": "session.update",
  "session": {
    "voice": "alloy",
    "instructions": "Call provided tools if appropriate for the user's input.",
    "input_audio_format": "pcm16",
    "input_audio_transcription": {
      "model": "whisper-1"
    },
    "turn_detection": {
      "threshold": 0.4,
      "silence_duration_ms": 600,
      "type": "server_vad"
    },
    "tools": [
      {
        "type": "function",
        "name": "get_weather_for_location",
        "description": "gets the weather for a location",
        "parameters": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "The city and state such as San Francisco, CA"
            },
            "unit": {
              "type": "string",
              "enum": [
                "c",
                "f"
              ]
            }
          },
          "required": [
            "location",
            "unit"
          ]
        }
      }
    ]
  }
}

Eingabeaudiopuffer und Verarbeiten von Sprecherwechseln

Der Server verwaltet einen Eingabeaudiopuffer, der vom Client bereitgestellte Audiodaten enthält, die noch nicht zum Unterhaltungszustand committet wurden.

Eine der wichtigsten sitzungsweiten Einstellungen ist turn_detection, die steuert, wie der Datenfluss zwischen dem Anrufer und dem Modell gehandhabt wird. Die Einstellung turn_detection kann auf none oder server_vad (zur Verwendung der serverseitigen Sprechaktivitätserkennung) festgelegt werden.

Ohne Serverentscheidungsmodus

Standardmäßig ist die Sitzung so konfiguriert, dass der Typ turn_detection effektiv auf none festgelegt wird.

Die Sitzung stützt sich auf vom Anrufer initiierten Ereignisse input_audio_buffer.commit und response.create, um Gespräche voranzutreiben und Ausgaben zu generieren. Diese Einstellung ist nützlich für Anwendungen oder Situationen, die „Drücken zum Sprechen“ verwenden, in denen ein externes Steuerelement für den Audiofluss verwendet wird (z. B. anruferseitige VAD-Komponente). Diese manuellen Signale können auch im server_vad-Modus verwendet werden, um die vom VAD ausgelösten Reaktionen zu ergänzen.

Abbildung der Realtime-API-Eingabeaudiosequenz ohne Serverentscheidungsmodus

Serverentscheidungsmodus

Die Sitzung kann mit dem auf server_vad festgelegten Typ turn_detection konfiguriert werden. In diesem Fall wertet der Server Benutzeraudiodaten vom Client (gesendet über input_audio_buffer.append) mithilfe einer VAD-Komponente (Sprechaktivitätserkennung) aus. Der Server verwendet diese Audiodaten automatisch, um die Antwortgenerierung für entsprechende Unterhaltungen zu initiieren, wenn ein Ende der Sprache erkannt wird. Die Stilleerkennung für den VAD kann bei der Angabe des server_vad-Erkennungsmodus konfiguriert werden.

Abbildung der Realtime-API-Eingabeaudiosequenz mit Serverentscheidungsmodus

Unterhaltung und Antwortgenerierung

Sie können pro Sitzung eine aktive Unterhaltung haben. Die Unterhaltung sammelt Eingabesignale, bis eine Antwort gestartet wird, entweder über ein direktes Ereignis durch den Anrufer oder automatisch per VAD (Voice Activity Detection, Sprechaktivitätserkennung).

Optional kann der Client Elemente in der Unterhaltung abschneiden oder löschen:

Abbildung der Elementsequenz einer Realtime-API-Unterhaltung

Zugehöriger Inhalt