Tokkio 零售#

简介#

Tokkio 零售参考应用程序是一个示例，展示了 Tokkio 可以部署的众多零售应用之一。然后，可以根据最终用户的需求自定义此应用程序。它旨在促进使用流行的大型语言模型 (LLM) 和自定义检索增强生成 (RAG) 解决方案的头像实时交互。

  • 主要功能

    • 多模态集成：最终用户可以通过语音和触摸的组合与 Tokkio 零售应用程序进行交互。

    • 自定义和集成：用户可以自定义应用程序以满足特定需求。 自定义零售 Bot 部分详细介绍了这种灵活性。

    • 架构增强：该应用程序展示了改进，例如使用自定义目录 RAG 管线和不同的 LLM 模型。

  • 优势

    • 易于使用：该应用程序支持简单的集成和自定义，使用户能够根据特定用例定制系统，而无需大量的技术开销。

    • 高级功能：借助手势生成和响应流式传输等功能，Tokkio 提高了用户交互质量和系统响应速度。

来源#

此资源的源代码可以在 NGC 上找到

最低 GPU 要求#

下表显示了默认动画头像渲染（OV 渲染）的最低 GPU 要求

最低 GPU 要求#

3 路流部署

4xT4 或 4xL4

6 路流部署

4xA10

对于基于 Unreal Engine 或 A2F-2D 的渲染选项，请分别参考 Tokkio LLM-RAG - Unreal Engine 和 Tokkio LLM-RAG - A2F-2D，了解最低 GPU 要求。

部署#

可以在 NVIDIA/ACE 中找到带有 OV 渲染的零售应用程序的示例 UCS 应用程序规范

有关构建和部署步骤，请参阅 自定义。

示例 LLM RAG 工作流程的 Helm Chart 可以在 https://helm.ngc.nvidia.com/nvidia/ace/charts/ucs-tokkio-app-base-3-stream-retail-3d-ov-4.1.4.tgz 中找到

有关 Tokkio 构建和 Tokkio UI 的部署说明，请参阅 部署。

Tokkio Retail running on Tokkio UI

自定义零售 Bot#

可以自定义 Tokkio 零售 Bot 以连接到自定义目录。如果目录模式与默认模式保持一致，则插件服务器、购物车管理器、UI 或 UI 服务器无需更改。有关更多信息，请参阅目录 RAG 的目录自定义 目录自定义 部分。

如果目录 RAG 使用了不同的模式，则可能需要根据需要对上述所有微服务进行修改。

有关上传和使用自定义 Bot 资源的步骤，请参阅 插件资源自定义。

架构#

下图概述了 Tokkio 零售中使用的微服务及其交互。 Tokkio 零售中使用的特定于应用程序的微服务包括：ACE 代理插件服务器、目录 RAG、购物车管理器、UI 服务器和 UI 前端。这些应用程序依赖的微服务通过 ACE 代理和聊天控制器微服务进行协调。

Architecture Diagram

Tokkio 零售工作流程中的所有微服务（插件服务器、目录 RAG、购物车管理器和 UI 服务器）都通过 REST API 通过 HTTP 相互交互。用户的输入查询传递到聊天引擎，然后聊天引擎协调插件服务器（以及最终的其余工作流程特定微服务）以满足请求。

与零售 Bot 的示例对话流程#

用户进入摄像机的视野 (FOV) 并设置了麦克风进行语音输入。 Bot 检测到用户存在并继续进行以下对话

Bot: "Hi, I am Ben. How can I help you"

User: "What drinks do you have?"

Bot: "We have regular cola, cofee, diet cola and lemonade. What would you like to order?"

User: "Add a large lemonade"

Bot: "A large lemonade has been added to your order"

User: <Silent for some time>

Bot: "Feel free to ask me any questions about the menu"

User: "Checkout please"

Bot: "Your order will be available shortly. Thanks for visiting, good bye!"

请注意，用户也可以使用触摸输入在零售工作流程中订购商品。

可以执行自定义以处理任何受支持的操作（并添加更多操作）。有关此方面的更多信息，请参阅此工作流程的 自定义部分。

零售插件资源#

ACE 代理插件服务器的零售插件负责制定所需的元数据和事件，以驱动对话和 Bot 的行为。它与不同的微服务交互，以了解用户查询的意图，提取有关商品的必要信息，并最终制定必要的信息来控制 Bot 行为。

零售插件的职责包括

  • 根据查询分析（由目录 RAG 执行）确定需要采取哪些操作来满足用户的请求

  • 从客户特定的目录 RAG 中获取相关信息。

  • 通过与购物车管理器交互来维护用户购物车的状态，以执行添加、删除和替换商品等操作。

  • 通过显示用户询问的选项来控制 UI 的状态。

  • 为用户询问的商品制定叙述。

  • 使用 LLM 生成合适的响应并将其返回给聊天引擎。

ACE 代理插件微服务在需要时从以下微服务获取输入，以制定不同类型的元数据。插件服务器的输入源是

  1. ACE 代理微服务 - 插件模块从 ACE 代理接收查询。

  2. 目录 RAG 微服务 - 插件模块调用目录 RAG 微服务公开的 API，以获取与商品关联的所有详细信息，例如尺寸和价格。这些详细信息用于验证用户请求以及制定所需的元数据以进行必要的澄清。插件模块还调用目录 RAG 的 /analyze_query API 进行查询分析和参数提取。

  3. 购物车管理器微服务 - 插件模块调用购物车管理器公开的 API 以获取用户购物车的当前状态。示例：Add cheeseburger to my cart。

  4. 用户界面服务器 - 插件模块调用 UI 服务器公开的 API，以服务与 UI 相关的查询。示例：What entrees do you have?。

在从这些微服务获取输入后，ACE 代理插件模块制定以下元数据，这些元数据将发送到 ACE 代理微服务和购物车管理器微服务。元数据包括

  1. 有关用户购物车上不同操作的信息，例如添加商品、删除商品、替换商品等，将发送到购物车管理器公开的 API。

  2. 当用户说出某些请求（例如在屏幕上显示所有侧面、显示购物车、返回上一页等）时，有关用户界面上不同操作的信息将发送到 UI 服务器公开的 API。

  3. 用于制定头像对 ACE 代理的口语响应的信息。


在较高的层面上，对话流程如下所示

  1. Colang 运行时作为聊天引擎的一部分运行，以提供防护栏和对话交互管理功能。它将查询转发到插件模块的 /analyze_query API，插件模块又调用目录 RAG 的同名 API 以获取查询分析 - 意图和参数提取。

  2. 插件服务器实现逻辑，以借助购物车管理器、目录 RAG 和 UI 服务器，根据意图和已识别的商品来执行操作，从而实现分类的意图（例如：将商品添加到购物车）。

  3. 插件服务器操作的结果将传递到 Colang 运行时

  4. Colang 运行时调用 LLM 以人性化的方式转述响应。

  5. 然后，转述的响应由聊天引擎使用，以响应用户请求。

您可以在 架构 中阅读有关它如何与其他 Tokkio 零售微服务交互的信息。

有关更多详细信息，请参阅 零售插件服务器 API。

购物车管理器#

活动用户的整个购物车管理由购物车管理器处理。它是一个轻量级服务，其主要功能是更新用户购物车并与 ACE 代理插件和 UI 通信有关更新的信息。 CM 的主要职责包括

  • 存储和检索用户购物车相关数据。

  • 与目录 RAG 服务通信，以获取有关要添加到购物车的商品的信息。

  • 购物车管理器需要运行健康的 MongoDB 实例。它使用 MongoDB 来存储用户购物车信息。

目录 RAG#

目录 RAG API 基于馈送到管线的目录 (json) 提供快速搜索和检索查询。它旨在将查询逻辑与后端解决方案分离。

  • 目录 RAG 在启动时使用 FAISS 库进行向量存储创建，并使用 HuggingFace 模型基于默认目录 (menu.json) 生成嵌入。

  • 目录 RAG 支持对目录商品进行广泛的搜索和过滤功能，例如 REGEX 模式匹配、逻辑链接、排序等。

  • 它还允许用户通过 API 调用动态批量导出和导入目录内容（对目录的修改不会在重启之间持久保存）。

  • 此外，它还支持分析插件服务器转发的查询，并为查询参数和查询意图提供结构化输出。插件服务器利用此功能来确定要对用户查询执行的操作。

UI 服务器和 UI 前端#

UI 服务器充当抽象层，以解耦表示层和所有后端 AI 微服务逻辑；因此，它提供了无缝集成自定义 UI 前端的灵活性，并最大限度地减少了必要的代码更改。 UI 服务器的主要功能包括

  • 用于管理（添加/删除/查看）购物车 API 中的购物车商品的 API

  • 用于从目录 RAG 提供目录内容的 API

  • 用于 Ace 代理插件操作 UI 渲染以进行语音输入的 API

  • 用于 UI 前端通信触摸输入以进行目录导航和食物订购的 API

  • 用于 UI 前端注册当前视图信息的 API，供 ACE 代理插件（或任何其他 MS）按需与 ACE 代理聊天控制器进行 gRPC 通信，以接收 ASR 并转发到 UI 前端进行渲染

  • 用于通过提供 JSON 请求负载在 UI 上渲染自定义视图的 API

  • 用于 FOV 进入/退出、摄像头添加/删除和错误报告的 Redis 事件监控

  • 具有轮换功能的多通道日志记录（文件、控制台等）

  • 支持 HTTP 和 HTTPS

UI 前端以用户友好的方式呈现目录商品。它使用户能够通过触摸和语音输入与 UI 交互。它通过明确定义的 REST API 和 Web 套接字连接与 UI 服务器通信。前端 UI 功能包括

  • 显示分类的目录商品

  • 浏览不同的类别

  • 向购物车添加/删除商品并显示购物车

  • 使用 WebRTC 协议流式传输动画 Tokkio 头像

  • 使用 Web 套接字连接显示 ASR 消息

  • 支持仅音频管线以在没有摄像头的情况下使用 Tokkio 应用程序

  • 根据提供的 JSON 负载渲染自定义视图组件

  • 生产构建配置和 Docker 化镜像

Tokkio 交互流程#

基于触摸的交互#

当用户进行触摸交互时，UI 会注册请求并根据用户浏览目录（显示更新）或将商品添加到购物车（购物车更新）的意图采取行动。对于显示更新，UI 服务器只需查询需要显示的商品，并与 UI 客户端通信以相应地更新显示。

对于涉及购物车更新的交互，UI 服务器与购物车管理器通信。 CM 反过来从数据存储中检索会话相关的购物车信息并更新购物车。然后相应地更新显示。请注意，会话标识符用于零售组件之间的所有通信，以确保检索和更新的会话信息是相关的。

基于语音的交互#

当用户通过语音进行交互时，ACE 代理插件会将相关请求传递给购物车管理器以进行任何购物车相关的更新，或传递给 UI 服务器以进行任何显示相关的更新。在这种情况下，CM 也会从数据存储中检索会话信息并更新购物车。然后相应地更新显示。

会话识别#

与用户会话关联的唯一令牌用于零售应用程序之间的所有通信。 sessionId 由聊天控制器生成。它标识从 FOV 进入触发到对话完成（FOV 退出或浏览器关闭）的对话会话，以维护用户上下文。请注意，从 ACE 代理插件传递到 UI 服务器以启动和停止会话的 connectionId 是与传入视频流关联的 ID。

零售工作流程限制#

Tokkio 的零售 Bot 工作流程仅供参考。它提供了在各个方面进行增强的潜力，包括支持与零售领域相关的新操作。已实现的工作流程具有以下限制，这些限制并非旨在详尽无遗

  • 不支持在单个查询中添加多个商品。商品必须一次添加一个，无论是否带有配料。

  • 不支持商品推荐。

  • 用户需要退出 FOV 并重新进入以开始新会话。

  • 如果意图未被正确识别，用户可能需要重新措辞某些查询。

  • Bot 默认使用商品的默认尺寸（小）来添加/删除商品，除非另有说明。

  • 开箱即用不支持上下文查询，如“添加那个”、“删除它”等，但可以通过在 \analyze_query API 中传递聊天历史记录来支持

  • 不支持商品替换

  • 目录在用户离开 FOV 后显示，但用户必须进入（或重新进入 FOV）才能下单

本页内容