Konzepte für den KI-Agenten für Food Ordering

Dieses Dokument bietet einen allgemeinen Überblick über die wichtigsten Konzepte der Food Ordering AI Agent API.

Agent-Konfiguration

Das Verhalten des Food Ordering AI Agent wird durch die Konfiguration von mehreren API-Ressourcen beeinflusst: Brand, Store und Menu. Diese Ressourcen definieren die Identität des Restaurants, seine physischen Standorte und die angebotenen Produkte und liefern so den notwendigen Kontext für den KI-Agenten, um Bestellungen zu bearbeiten.

Marke

Ein Brand ist die Ressource der obersten Ebene und steht für eine Restaurantmarke, die einem oder mehreren Standorten dieser Restaurantmarke entspricht. Sie enthält die Konfiguration, die für alle Standorte dieses Restaurants gilt. Brand kann die Konfiguration vieler Funktionen der Agent-Persona umfassen, z. B. das Begrüßungsverhalten und die Stimmeigenschaften. Viele dieser Funktionen können durch Werte überschrieben werden, die in der Ressource „Store“ oder sogar in der Konfiguration pro Sitzung festgelegt sind (siehe Lebenszyklus von Sitzungen).

Store

Eine Store-Ressource steht für einen einzelnen physischen Restaurantstandort, der zu einer Brand gehört. Sie definiert die Konfiguration, die für diesen Standort spezifisch ist, z. B. die Zeitzone, den Status (z. B. ACTIVE, DISABLED), die Öffnungszeiten und die Tageszeiten (z. B. Zeiträume wie „Frühstück“ oder „Mittagessen“, in denen bestimmte Menüpunkte verfügbar sind).

Eine Menu-Ressource definiert alle Produkte, die von einem Restaurant angeboten werden, einschließlich aller möglichen Auswahlmöglichkeiten und Anpassungen für jedes verkäufliche Produkt. Ein Menu muss mit einem Storeverknüpft sein. Das Menü ist flexibel gestaltet und kann verschiedene Menüstrukturen aufnehmen, von kleinen Listen mit einzelnen Artikeln bis hin zu komplexen Bäumen mit Kombi-Menüs mit verschachtelten Modifikatoren.

Zu den wichtigsten Komponenten eines Menu gehören:

  • Items: Verkaufbare Produkte der obersten Ebene wie À-la-carte-Gerichte, Getränke, Beilagen oder Kombi-Menüs.
  • ModifierGroups: Sammlungen von Auswahlmöglichkeiten, die auf ein Item oder einen anderen Modifier angewendet werden können, z. B. „Beilage auswählen“ oder „Beläge hinzufügen“.
  • Modifiers: Einzelne Optionen innerhalb einer ModifierGroup, z. B. „Pommes“, „Extra Käse“ oder „Cola“. Modifikatoren können den Preis des Artikels anpassen und können verschachtelte ModifierGroups für weitere Anpassungen enthalten.
  • MenuCategories: Organisationseinheiten wie „Vorspeisen“ oder „Getränke“.

Eine Menu-Ressource wird durch einen Namen im folgenden Format: projects/{project}/locations/{location}/menus/{menu}.

Weitere Informationen zum Strukturieren von Menüdaten finden Sie unter Menüdaten einbinden.

Bestellsitzungen

Bestellsitzungen sind das Herzstück des Food Ordering AI Agent und ermöglichen konversationelle Interaktionen zwischen einem Kunden und dem KI-Agenten. Jede Sitzung steht für eine einzelne Essensbestellung und wird entweder mit der bidirektionalen Streamingmethode in Echtzeit (FoodOrderingService.BidiProcessOrder) oder mit der auf Zügen basierenden unären Anfrage-Antwort-Methode (FoodOrderingService.ProcessOrder) verwaltet.

BidiProcessOrder-RPC-Methode

Dies ist eine bidirektionale Streaming-RPC: Die Clientanwendung streamt Eingaben an den Agenten und der Agent streamt gleichzeitig Antworten zurück an den Client. Dies ermöglicht multimodale Interaktionen (Sprache und Text) in Echtzeit mit geringer Latenz.

  • Stream vom Client zum Agenten: Der Client sendet einen Stream von BidiProcessOrderRequest-Nachrichten mit Audioeingabe (Kundenrede), Texteingabe oder Ereigniseingaben (z. B. eine clientseitige Warenkorbaktualisierung, die von einem Kunden über eine Tippoberfläche ausgeführt wird, oder ein vom Drive-in-Restaurant-Hardware erkanntes Drive-off-Ereignis).
  • Stream vom Agenten zum Client: Der Agent gibt einen Stream von BidiProcessOrderResponse-Nachrichten mit Audioausgabe (synthetische Agentenrede), Textausgabe, Transkripten der erkannten Rede, Aktualisierungen des Bestellstatus des Kunden oder anderen Signalen wie erkannten Unterbrechungen zurück.

ProcessOrder-RPC- und REST-Methode

ProcessOrder ist eine unäre Anfrage-Antwort-Methode, die für textbasierte, schrittweise Essensbestellungen entwickelt wurde (z. B. Chat-Widgets, Webformulare und REST-Clients). Sie ist über gRPC und REST zugänglich (POST /v1/{config.session=projects/*/locations/*/sessions/*}:processOrder).

Im Gegensatz zu BidiProcessOrder, arbeitet ProcessOrder mit diskreten Anfrage-Antwort-Zügen und ist rein textbasiert:

  • Modusanforderung: config.mode muss explizit auf TEXT (oder 2 in JSON) gesetzt werden.
  • Lebenszyklus von Zügen: turn_type sollte im ersten Zug auf INITIALIZE gesetzt werden, um Sitzungsvariablen einzufügen (z. B. Menü- und Standortmetadaten), und in den folgenden Zügen auf SUBSEQUENT.

Lebenszyklus von Sitzungen

Jede Sitzung im Food Ordering AI Agent muss mit einer vom Client bereitgestellten Konfiguration beginnen, die mit einer Config-Nachricht angegeben wird. In der Config wird Folgendes angegeben:

  • store: Der vollständige Ressourcenname des Store, für den die Bestellung aufgegeben wird (z.B. projects/PROJECT/locations/LOCATION/brands/BRAND/stores/STORE). Die Sitzung übernimmt die Konfiguration, die in der referenzierten Store-Ressource und der übergeordneten Brand-Ressource dieses Stores angegeben ist. Bei Konfigurationskonflikten zwischen Brand und Store hat die Store-Konfiguration Vorrang.
  • session: Eine eindeutige Sitzungs-ID im Format projects/PROJECT/locations/LOCATION/sessions/SESSION. Die session_id ist eine vom Client generierte ID, die eine Kundeninteraktion oder -unterhaltung eindeutig identifiziert.
  • mode: Der Modus der Sitzung (HYBRID oder TEXT). Bei BidiProcessOrder ist mode optional und wird standardmäßig auf HYBRID (Sprache und Text) gesetzt. Bei ProcessOrder (unär / REST) muss mode explizit auf TEXT gesetzt werden.