Conceitos do agente de IA para pedidos de comida

Este documento oferece uma visão geral dos principais conceitos da API do agente de IA do Pedido de comida.

Configuração do agente

O comportamento do agente de IA do Pedido de comida é influenciado pela configuração de vários recursos da API: Brand, Store e Menu. Esses recursos definem a identidade do restaurante, os locais físicos e os produtos oferecidos, fornecendo o contexto necessário para que o agente de IA processe os pedidos.

Marca

Um Brand é o recurso de nível superior, que representa uma marca de restaurante correspondente a um ou mais locais dessa marca. Ele contém uma configuração compartilhada em todos os locais do restaurante. Brand pode incluir a configuração de muitos recursos da personalidade do agente, como comportamento de saudação e características de voz. Muitos desses recursos podem ser substituídos por valores configurados no recurso Store ou até mesmo na configuração por sessão (consulte Ciclo de vida da sessão)

Repositório

Um Store recurso representa um único local físico de restaurante pertencente a um Brand. Ele define a configuração específica desse local, como fuso horário, status (por exemplo, ACTIVE, DISABLED), horário de funcionamento e períodos do dia (por exemplo, períodos como "Café da manhã" ou "Almoço" em que determinados itens do cardápio estão disponíveis).

Um Menu recurso define todos os produtos oferecidos por um restaurante, incluindo todas as opções e personalizações possíveis para cada produto vendável. Um Menu precisa ser associado a uma Store. O menu foi projetado para ser flexível e acomodar várias estruturas, desde pequenas listas de itens independentes até árvores complexas de refeições combinadas com modificadores aninhados.

Os principais componentes de um Menu incluem:

  • Itens: produtos vendáveis de nível superior, como pratos à la carte, bebidas, acompanhamentos ou refeições combinadas.
  • ModifierGroups: coleções de opções aplicáveis a um Item ou outro Modifier, como "Escolha um acompanhamento" ou "Adicionar coberturas".
  • Modificadores: opções individuais em um ModifierGroup, como "Batata frita", "Queijo extra" ou "Coca-cola". Os modificadores podem ajustar o preço do item e podem conter ModifierGroups aninhados para mais personalização.
  • MenuCategories: unidades organizacionais como "Entradas" ou "Bebidas".

Um recurso Menu é identificado por um nome no seguinte formato: projects/{project}/locations/{location}/menus/{menu}.

Para mais detalhes sobre como estruturar dados de cardápio, consulte Integrar dados de cardápio.

Sessões de pedidos de comida

As sessões de pedidos de comida estão no centro do agente de IA do Pedido de comida, permitindo interações conversacionais entre um cliente e o agente de IA. Cada sessão representa uma única conversa de pedido de comida e é gerenciada usando o método de streaming bidirecional em tempo real (FoodOrderingService.BidiProcessOrder) ou o método de solicitação-resposta unário baseado em turnos (FoodOrderingService.ProcessOrder).

Método RPC BidiProcessOrder

Esse é um RPC de streaming bidirecional: o aplicativo cliente transmite a entrada para o agente, e o agente transmite respostas simultaneamente para o cliente. Isso permite interações multimodais (voz e texto) em tempo real e de baixa latência.

  • Stream de cliente para agente: o cliente envia um stream de BidiProcessOrderRequest mensagens contendo entrada de áudio (fala do cliente), entrada de texto ou eventos (como uma atualização do carrinho do lado do cliente realizada por um cliente usando uma interface de toque ou um evento de saída detectado por hardware de restaurante drive-thru).
  • Stream de agente para cliente: o agente retorna um stream de BidiProcessOrderResponse mensagens contendo saída de áudio (fala sintetizada do agente), saída de texto, transcrições de fala reconhecida, atualizações do estado do pedido do cliente ou outros sinais, como interrupções detectadas.

Método RPC e REST ProcessOrder

ProcessOrder é um método de solicitação-resposta unário projetado para integrações de pedidos de comida baseadas em texto, turno a turno (como widgets de chat, formulários da Web e clientes REST). Ele pode ser acessado por gRPC e REST (POST /v1/{config.session=projects/*/locations/*/sessions/*}:processOrder).

Ao contrário de BidiProcessOrder, ProcessOrder opera em turnos discretos de solicitação-resposta e é somente de texto:

  • Requisito de modo: config.mode precisa ser definido explicitamente como TEXT (ou 2 em JSON).
  • Ciclo de vida do turno: turn_type precisa ser definido como INITIALIZE no turno inicial para injetar variáveis de sessão (como metadados de cardápio e loja) e SUBSEQUENT nos turnos de acompanhamento.

Ciclo de vida da sessão

Cada sessão no agente de IA do Pedido de comida precisa começar com a configuração fornecida pelo cliente especificada usando uma Config mensagem. O Config especifica:

  • store: o nome completo do recurso do Store para o qual o pedido está sendo feito (por exemplo, projects/PROJECT/locations/LOCATION/brands/BRAND/stores/STORE). A sessão assume a configuração especificada no recurso Store referenciado e no recurso Brand pai da loja. Quando a configuração entra em conflito entre a Brand e a Store, a configuração da Store tem precedência.
  • session: um identificador de sessão exclusivo no formato projects/PROJECT/locations/LOCATION/sessions/SESSION. O session_id é um ID gerado pelo cliente que identifica exclusivamente uma interação ou conversa do cliente.
  • mode: o modo da sessão (HYBRID ou TEXT). Para BidiProcessOrder, mode é opcional e o padrão é HYBRID (voz e texto). Para ProcessOrder (unário / REST), mode precisa ser definido explicitamente como TEXT.