Conceptos del agente de IA de Pedidos de comida

En este documento, se proporciona una descripción general de alto nivel de los conceptos clave de la API del agente de IA de Pedidos de comida.

Configuración del agente

El comportamiento del agente de IA de Pedidos de comida está influenciado por la configuración de varios recursos de la API: Brand, Store y Menu. Estos recursos definen la identidad del restaurante, sus ubicaciones físicas y los productos que ofrece, lo que proporciona el contexto necesario para que el agente de IA gestione los pedidos.

Marca

Un Brand es el recurso de nivel superior, que representa una marca de restaurante correspondiente a una o más ubicaciones de esa marca. Contiene una configuración que se comparte en todas las ubicaciones de ese restaurante. Brand puede incluir la configuración de muchas funciones de la personalidad del agente, como el comportamiento de saludo y las características de voz. Muchas de esas funciones se pueden anular con los valores configurados en el recurso Store o incluso en la configuración por sesión (consulta Ciclo de vida de la sesión).

Almacén

Un recurso Store representa una sola ubicación física de un restaurante que pertenece a un Brand. Define la configuración específica de esa ubicación, como su zona horaria, estado (p.ej., ACTIVE, DISABLED), horario de atención y partes del día (p.ej., períodos como "Desayuno" o "Almuerzo" durante los cuales están disponibles ciertos elementos del menú).

Un Menu recurso define todos los productos que ofrece un restaurante, incluidas todas las opciones y personalizaciones posibles para cada producto vendible. Un Menu debe estar asociado con una Store. El menú está diseñado para ser flexible y adaptarse a varias estructuras de menú, desde pequeñas listas de elementos independientes hasta árboles complejos de comidas combinadas con modificadores anidados.

Los componentes clave de un Menu incluyen lo siguiente:

  • Items: Productos vendibles de nivel superior, como entradas a la carta, bebidas, acompañamientos o comidas combinadas.
  • ModifierGroups: Colecciones de opciones aplicables a un Item o otro Modifier, como "Elige un acompañamiento" o "Agrega ingredientes".
  • Modificadores: Opciones individuales dentro de un ModifierGroup, como "Papas fritas", "Queso extra" o "Cola". Los modificadores pueden ajustar el precio del artículo y pueden contener ModifierGroups anidados para una mayor personalización.
  • MenuCategories: Unidades organizativas como "Aperitivos" o "Bebidas".

Un recurso Menu se identifica con un nombre en el siguiente formato: projects/{project}/locations/{location}/menus/{menu}.

Para obtener más detalles sobre la estructuración de los datos del menú, consulta Cómo integrar datos del menú.

Sesiones de pedidos de comida

Las sesiones de pedidos de comida son el núcleo del agente de IA de Pedidos de comida, lo que permite interacciones conversacionales entre un cliente y el agente de IA. Cada sesión representa una sola conversación de pedidos de comida y se administra con el método de transmisión bidireccional en tiempo real (FoodOrderingService.BidiProcessOrder) o el método unario de solicitud-respuesta por turnos (FoodOrderingService.ProcessOrder).

Método RPC BidiProcessOrder

Se trata de una RPC de transmisión bidireccional: la aplicación cliente transmite la entrada al agente, y el agente transmite las respuestas al cliente de forma simultánea. Esto permite interacciones multimodales (voz y texto) en tiempo real y de baja latencia.

  • Transmisión de cliente a agente: El cliente envía una transmisión de BidiProcessOrderRequest mensajes que contienen entrada de audio (voz del cliente), entrada de texto o entradas de eventos (como una actualización del carrito del cliente realizada por un cliente con una interfaz táctil o un evento de salida detectado por hardware del hardware del restaurante de comida para llevar).
  • Transmisión de agente a cliente: El agente devuelve una transmisión de BidiProcessOrderResponse mensajes que contienen salida de audio (voz del agente sintetizada), salida de texto, transcripciones de voz reconocida, actualizaciones del estado del pedido del cliente o cualquier otra señal, como interrupciones detectadas.

Método REST y RPC ProcessOrder

ProcessOrder es un método unario de solicitud-respuesta diseñado para integraciones de Pedidos de comida paso a paso basadas en texto (como widgets de chat, formularios web y clientes REST). Se puede acceder a él a través de gRPC y REST (POST /v1/{config.session=projects/*/locations/*/sessions/*}:processOrder).

A diferencia de BidiProcessOrder, ProcessOrder opera en turnos discretos de solicitud-respuesta y es solo de texto:

  • Requisito de modo: config.mode se debe establecer de forma explícita en TEXT (o 2 en JSON).
  • Ciclo de vida del turno: turn_type se debe establecer en INITIALIZE en el turno inicial para insertar variables de sesión (como metadatos del menú y de la tienda) y en SUBSEQUENT en los turnos de seguimiento.

Ciclo de vida de Session

Cada sesión en el agente de IA de Pedidos de comida debe comenzar con la configuración proporcionada por el cliente que se especifica con un mensaje Config. El Config especifica lo siguiente:

  • store: Es el nombre completo del recurso de la Store para el que se realiza el pedido (p.ej., projects/PROJECT/locations/LOCATION/brands/BRAND/stores/STORE). La sesión adopta la configuración especificada en el recurso Store al que se hace referencia y en el recurso Brand superior de esa tienda. Cuando hay conflictos de configuración entre Brand y Store, la configuración de Store tiene prioridad.
  • session: Es un identificador de sesión único en el formato projects/PROJECT/locations/LOCATION/sessions/SESSION. El session_id es un ID generado por el cliente que identifica de forma única una interacción o conversación del cliente.
  • mode: Es el modo de la sesión (HYBRID o TEXT). Para BidiProcessOrder, mode es opcional y el valor predeterminado es HYBRID (voz y texto). Para ProcessOrder (unario / REST), mode debe establecerse de forma explícita en TEXT.