Catalog 自定义#

来源#

注意

本节假定默认的 Tokkio Retail App 已经部署。

可以通过使用 exec 命令登录到 Kubernetes pod 部署后检查 Catalog RAG 源代码。将下面示例命令中的 catalog-rag-deployment-pod-name 替换为你的部署中 Catalog RAG 的实际 pod 名称。例如：catalog-rag-deployment-7b9786484d-v44d2

kubectl exec -ti <catalog-rag-deployment-pod-name> -- /bin/bash

下面各节中讨论的各种文件都可以在 pod 内找到。你也可以将这些文件复制到本地进行编辑。

Catalog 架构#

Catalog RAG 使用的 JSON 架构当前针对基于餐厅的零售应用程序。可以轻松地修改/更新 RAG 管线以适用于现有架构。可以在 Catalog RAG 源代码中的文件 menu.json 中观察到正在使用的架构。以下是 JSON 架构中各种字段的分解 -

  • _id [Dict] - 存储唯一 ID

  • $oid [Str] - 菜单中每个条目的十六进制唯一 ID

  • menu_item [Bool] ⇒ 如果你不希望在 UI 上将该项目显示为单独的项目（例如，配料、成分），则设置为 False，否则为 True

  • recommendation_type [List[Str]] ⇒ 保留供将来使用

  • synonyms [List[Str]] ⇒ 此项目的别名（如果有）

  • tags [List[Str]] ⇒ 基于限制、规范等的标签（例如，纯素食）

  • variations [List[Dict]] ⇒ 定义所有可能的变体

    • name [Str] ⇒ 保留供将来使用

    • size [Str] ⇒ 变体的相应尺寸（例如，小）

    • calories [Int] ⇒ 总卡路里

    • price [Float] ⇒ 总价

    • description [Str] ⇒ 食品项目的描述（如果未设置 is_default，则为可选）

    • image [Str] ⇒ NGC 注册表中的图像位置（如果未设置 is_default，则为可选）

    • is_default [Bool] ⇒ 如果可用并设置为 True，则当用户未提及特定变体尺寸时，此变体将添加到购物车

  • ingredients [List[Str]] ⇒ 所有存在的成分，确保成分也作为单独的食品项目添加到菜单中，menu_item=False）

  • toppings [List[Str]] ⇒ 所有可用的配料，确保配料也作为单独的食品项目添加到菜单中，menu_item=False）

  • name [Str] ⇒ 食品项目的名称

  • item_id [Str] ⇒ 唯一的字母数字项目 ID

  • category [Str] ⇒ 当前项目所属的食品项目类别

特定项目的所有键值对都是强制性的。因此，在更新或添加新菜单项时，请确保所有默认键值对都存在。以下是用于 Catalog RAG 的默认架构的代码片段 -

[
     {
     "_id": {
          "$oid": "string"
     },
     "menu_item": true,
     "recommendation_type": [
          "string"
     ],
     "synonyms": [
          "string"
     ],
     "tags": [
          "string"
     ],
     "variations": [
          {
          "name": "string",
          "size": "string",
          "calories": 0,
          "price": 0,
          "description": "string",
          "image": "string",
          "is_default": true
          }
     ],
     "ingredients": [
          "string"
     ],
     "toppings": [
          "string"
     ],
     "name": "string",
     "item_id": "string",
     "category": "string"
     }
]

修改默认 Catalog#

Catalog RAG 提供了一个 API POST /api/menu 以动态设置目录（使用相同的架构）。请注意，插件服务器、购物车管理器、UI 服务器和 UI 在此更新后需要重启。用户可以使用 Catalog RAG 服务端口在 Kubernetes 集群内访问此端点。可以通过 curl 或 fastapi 客户端页面发送请求（示例：https://127.0.0.1:8080/docs）。

对于包括将 Catalog RAG 用于与零售餐厅非常不同的应用程序的重大更改，建议更新提示 vectorstore_prompt.txt（在 Catalog RAG 源代码中找到）并在 Catalog 源代码中上传更新后的 JSON，以便在启动时用于创建向量存储。后一种方法需要用户重建 Catalog RAG 容器，并使用更新后的容器来构建可与 Tokkio 一起使用的自定义/新微服务。

更新 Catalog 图像#

Catalog 架构中项目对应的图像（menu.json 是默认文件）需要上传到前端源代码，以便它们能够正确显示给用户。查看 部署 UI 以了解有关下载 UI 源代码的信息。默认版本已包含与默认 menu.json 中项目相关的图像。

  1. 运行以下命令以生成 UI 生产构建。将生成“build”目录

    cd vst-streaming-lib
npm install
npm run build

2. 创建一个新的 /images 目录，并将其放在 UI 的 /build 目录中。此目录中的子文件夹应等于 UI 服务器 API 响应中的 image_loc 字段。例如，来自 GET: category/item/23 的 API 响应将具有 image_loc 字段。假设 image_loc 字段等于 images/image-category/item23.png。那么 UI 应该在目录 /public/images/image-category/item23.png 中具有项目 23 的图像。对于目录中的所有项目，都应遵循此操作。1. 新的 /images 目录应替换 /build/images 中的现有图像目录。2. 将更新后的 build 目录上传到 S3 存储桶

aws s3 sync ./build s3://tokkio-ui

  1. 将新生成的静态文件保存在 /build 目录中。

功能自定义 - Catalog 架构、CM、插件服务器和 UI#

Tokkio 零售参考应用程序希望用户坚持 Tokkio 零售微服务 (MS) 中定义的目录架构和 API 流程。但是，如果需要，可以修改这些内容以整合任何新需求。在大多数情况下，插件服务器、CM、Catalog RAG 和 UI 及其 API 都需要进行更改。

使用自定义 Catalog RAG#

  1. 在 下载 Catalog RAG 源代码 中演示的那样，在本地下载 Catalog RAG 资源

  2. 实施必要的修改以自定义资源。

  3. 导航到包含 Dockerfile 的源代码目录，并为更新后的容器构建容器

    docker build -t catalog-rag-container:test

  4. 标记创建的镜像以将其上传到你的组织使用的特定 NGC 路径

    sudo docker tag <image_name> <NGC_PATH/ucs-tokkio-catalog-rag-container:version_num>

  5. 将更新后的容器推送到 NGC

    docker push <NGC_PATH/ucs-tokkio-catalog-rag-container:version_num>

  6. 有关创建和使用可用于 Tokkio 应用程序的自定义微服务（在本例中为 Catalog RAG 的自定义版本）的详细信息，请参阅 添加新的微服务。

在本页中