RDS AI(基于 Supabase)提供知识图谱-Ontology 能力,可基于业务数据库自动抽取实体与关系,构建本体(Ontology)层,并一键生成可被 AI Agent 调用的 Skill,帮助您快速将业务数据转化为具备语义理解能力的 AI 应用。
注意事项
LLM 自动建模为一次性流程,运行中不可切换页面。自动建模依赖 LLM 推理整库表结构与业务语义,过程通常需要数分钟。建模过程中若切出当前页面或刷新浏览器,任务会被中断且无法恢复,需重新触发。
本文档中的业务数据(用户、订单、店铺等)均为通过 LLM 批量造数生成的演示数据,数值与结论不代表真实业务。在生产场景中,请基于真实业务数据进行验证。
步骤一:准备实例环境
1. 创建知识图谱实例
登录 RDS AI 应用开发控制台,进入实例购买页。
在购买页参照下表完成关键参数配置,其中 RDS AI 应用模块 必须勾选 知识图谱。
参数
说明
RDS AI 应用项目名称
自定义项目名称,用于在控制台中标识该实例。
地域
选择业务所在地域,购买后不可更改。建议与上层应用部署在同一地域以降低网络延迟。
VPC、主可用区及网络
选择已有的 VPC 和交换机。如无,可单击 点击创建 跳转 VPC 控制台新建。
RDS AI 应用模块
务必勾选 知识图谱。Supabase 和 长期记忆 可按业务需要勾选。
Dashboard 用户名
系统固定为
supabase,不可修改。Dashboard 密码
长度为 8~32 位,必须包含大写字母、小写字母、数字、下划线(_)四种字符中的至少三种。用于后续登录知识图谱工作台。
付费类型
支持 包年包月 和 按量付费。长期使用建议包年包月。
引擎
支持 PostgreSQL 17 和 PostgreSQL 18。无特殊需求建议选择 PostgreSQL 17。
SLR 角色授权
确认
AliyunServiceRoleForRds和AliyunServiceRoleForRdsPgsqlOnEcs两个服务关联角色已显示绿色对勾。如未授权,按页面提示完成授权。产品系列
测试和功能验证场景选择 基础系列;生产环境建议选择 高可用系列。
规格分类、规格
根据业务数据量和并发量选择规格。本文档演示场景建议至少选择
pg.n2.2c.1m(2 核 4 GB)。存储空间
默认 20 GB,可根据业务数据规模调整。
数据库密码
长度为 8~32 位,字符组合要求同 Dashboard 密码。用于直连 PostgreSQL 数据库进行业务数据操作。
确认订单并完成支付,等待实例创建完成(通常需要数分钟)。
2. 配置访问白名单
在RDS AI 应用开发控制台的实例列表中,单击目标项目名称,进入实例详情页。
将本地客户端的公网 IP 添加到访问白名单后保存。
3. 登录知识图谱实例
在 RDS AI 应用开发控制台,单击目标项目名称进入实例详情页。
在 网络信息 区域,复制 外网连接地址(形如
59.xxxx.182:80)。在浏览器中访问该外网连接地址,使用 Dashboard 用户名
supabase和购买时设置的 Dashboard 密码登录。登录成功后即进入知识图谱工作台,后续构建数据集、本体建模、生成 Skill 等操作均在此工作台完成。
实例详情页的 网络信息 区域还会展示 PostgreSQL 外网地址(形如 pgm-xxxxxxxx.pg.rds.aliyuncs.com)和 PostgreSQL 内网地址,用于后续步骤二直连 RDS PostgreSQL 数据库,请提前记录。如外网地址未启用,可在该页面单击 允许实例访问公网 开关开启。
步骤二:准备业务数据
本步骤完成业务库表结构创建和测试数据生成。建议使用 RDS PostgreSQL 直连方式操作,效率最高。
1. 直连RDS PostgreSQL实例
登录 RDS 管理控制台。
在实例列表中,找到与 RDS AI 实例关联的 PostgreSQL 实例,单击实例 ID 进入详情页。
在 数据库连接 页面,复制 外网连接地址(形如
pgm-xxxxxxxx.rds.aliyuncs.com),并记录配套的端口、数据库名、账号和密码。
2. 创建业务表结构
使用任意 PostgreSQL 客户端(如 psql、DataGrip、Navicat 等)连接 RDS PostgreSQL 实例,在目标数据库(如 supabase_db)中执行以下 DDL,创建外卖点单系统所需的全部表、外键、索引和约束。
3. 生成关联测试数据
建议使用 QoderWork 通过自然语言 Prompt 批量生成相互关联的测试数据。打开 QoderWork,输入类似以下的 Prompt:
我要做一个数据插入脚本,目前我的数据库是 PostgreSQL,连接地址是:pgm-XXX.rds.aliyuncs.com,库是 supabase_db,用户名是 XXX,密码是 XXX。
请帮我查一下我目前的表结构,生成 10W 条关联数据,包括用户、订单、下单、饭店、菜单全部关联。
请将 Prompt 中的 pgm-XXX.rds.aliyuncs.com、用户名、密码替换为步骤 1 中获取的真实连接信息。QoderWork 会自动连接 RDS PostgreSQL 实例、读取表结构、生成符合外键约束的关联数据并完成插入。
步骤三:构造 Ontology 本体
Ontology(本体)是对业务领域中实体、属性和关系的语义建模,是 AI Agent 理解业务的基础。本步骤基于已就绪的业务数据,通过 Agent 自动建模生成 Ontology,流程包含:进入自动建模入口、创建 Ontology 数据集、完成连接配置、预览与精炼本体、注册并查看知识图谱。
1. 进入Agent自动建模
使用 Dashboard 用户名
supabase和密码登录知识图谱工作台(参见 步骤一第 3 节)。在左侧导航栏 ONTOLOGY 分组下单击 类型建模,进入 Ontology 类型建模页面。
在类型定义区域,单击Agent 自动建模按钮,进入自动本体建模流程。
页面顶部 建模模板 区域提供 Agent 结构化记忆 等预定义本体模板,涵盖人员、项目、任务、事件、文档、笔记等通用实体。若您的业务符合通用 Agent 记忆场景,可直接单击 一键应用 跳过自动建模。本文档以"外卖点单系统"自定义业务为例,使用 Agent 自动建模流程。
2. 创建 Ontology 类型数据集
进入 自动本体建模 页面后,顶部会显示三段式流程进度:连接配置 → 预览 & 精炼 → 完成。需先创建一个 Ontology 类型的数据集用于承载本体定义。
在页面右上角的数据集下拉框中,单击创建数据集,弹出创建对话框。
参照下表填写数据集信息。
参数
说明
名称
必填。数据集名称,建议与业务场景对应,例如
food_delivery_ontology。描述
可选。简要说明数据集用途,便于后续维护。
RAG 类型
下拉支持 GraphRAG、Ontology、Skills 三种类型。本场景必须选择 Ontology。
存储类型
固定为本地存储,不可修改。Ontology 与 Skills 类型的数据集仅支持本地存储。
单击 创建数据集 完成创建。创建成功后,数据集会自动被选中并激活(状态显示为 active)。
3. 完成连接配置并触发自动建模
在 连接配置 阶段,选择 Schema 为 public , 输入业务逻辑:这是一个外卖点单系统,该描述会作为 LLM 抽象实体语义的方向锚点,描述越精准,生成的本体越贴合业务。
确认无误后,单击 开始分析 进入 预览 & 精炼 阶段,LLM 开始扫描表结构、外键关系并推断 ObjectType / LinkType / ActionType。
LLM 自动建模为一次性长流程,通常需要数分钟。建模过程中请勿切换页面、刷新浏览器或关闭标签页,否则任务会中断且无法恢复,需重新发起建模。
4. 预览&精炼本体
建模完成后,页面会以 ObjectType(对象类型)、LinkType(关联类型)、ActionType(动作类型)、映射 四个标签页展示推断结果。每个 ObjectType 卡片会标注 PK(主键字段)、属性数量、创建时间。
在 建议中心 区域查看 refine 生成的调整建议,根据业务实际逐项接受或忽略;也可手动编辑实体名称、属性、关系类型,使本体更贴近真实业务语义。
确认本体结构无误后,单击 注册到数据集 并点击确认注册后进入完成阶段。
5. 完成注册并查看知识图谱
在 完成 阶段,系统会按本体定义自动从 RDS PostgreSQL 业务库抽取数据,构建实体节点与关系边并写入知识图谱,首次同步耗时取决于数据量。
注册完成后,在左侧导航栏 ONTOLOGY 分组下单击 本体图谱,查看知识图谱可视化视图。单击任一节点可查看具体实例数据,验证本体抽取效果。
在 实例管理 中可查看每个 ObjectType 对应的实例总数,用于核对数据同步是否完整。
步骤四:生成并安装 Skill
本体注册完成后,可在"完成"阶段直接由 LLM 根据 Ontology 自动生成 Agent Skill 包,供 AI Agent 调用。
1. 单击"生成 Skill"打开生成对话框
在自动本体建模的完成页面底部操作栏,单击 生成 Skill,弹出 从建模生成 Agent Skill 对话框。该对话框副标题会显示当前数据集名称,例如 根据当前数据集的 Ontology 建模自动生成完整的 Agent Skill包(food_delivery_ontology)。
2. 填写 Agent Skill 配置
参照下表填写对话框中的参数。
参数 | 说明 |
Skill 名称 | 自定义 Skill 名称,例如 |
场景标题 | 可选。用一句话描述 Skill 适用场景(如 |
API URL | 必填。Skill 调用知识图谱时使用的 RAG 网关地址(形如 |
使用 Agent 模式(LLM 生成) | 建议勾选(默认勾选)。勾选后,LLM 会理解领域语义,为 Skill 生成贴合业务场景的查询优先级和推理链路;不勾选则仅生成基础的 ObjectType 查询模板。 |
自动发布到 Skills | 可选。勾选后,生成的 Skill 会自动发布到 Skills 数据集,无需手动发布即可被 Agent 调用。如需先人工审阅 SKILL.md 再发布,请保持不勾选。 |
3. 单击"Agent 生成"启动 LLM 推理
参数填写完成后,单击对话框右下角的 Agent 生成。对话框中央会显示 Agent 生成 SKILL.md(LLM 推理中)… 的加载提示,以及 LLM 正在理解领域语义并生成 Skill 文档,请稍候… 的提示文案。
等待 LLM 推理完成(通常需要数分钟,与本体规模和 ObjectType 数量正相关),系统会自动生成
SKILL.md及配套 Skill 包文件。如未勾选 自动发布到 Skills,可在生成完成后的预览页确认
SKILL.md内容,确认无误后手动安装到 Skills 数据集。
LLM 推理过程中请勿关闭对话框、刷新浏览器或切换页面,否则推理任务会被中断,需重新单击 Agent 生成 重启流程。
4. 安装 Skill 到本地客户端
Skill 生成完成后,需要将其安装到本地 AI 编程客户端,才能被 Agent 加载调用。
在左侧导航栏的 SKILLHUB 区域,单击 Skills 进入 Skill 列表页。在刚生成的 Skill 卡片(如
food-delivery-agent)上,单击 安装。在弹出的 安装技能 对话框中,按本地使用的客户端切换页签:Claude、Cursor、Gemini、通用 或 Qoder。对话框会展示对应客户端的 目标目录(如 Qoder 默认为
~/.qoder/skills/<skill-name>)与一条完整的 安装命令。单击命令区域右上角的 复制,将命令粘贴到本地终端执行。命令会通过
curl从 SkillHub 制品仓库下载 zip 包,并解压到目标目录;终端无报错即代表安装成功。返回对话框,单击 关闭。在本地Qoder客户端中重新加载或重启 Skill 列表,即可看到新安装的 Skill,进入步骤五验证调用效果。
步骤五:在 QoderWork 中验证效果
1. 选择 Skill 并发起提问
打开 QoderWork 客户端,在 Skill 列表中选择已安装的 Skill(如
food-delivery-agent)。在对话框中用自然语言提问。例如:
帮我看一下我的门店:李xx的中餐店Skill 会基于 Ontology 调用知识图谱查询底层 RDS PostgreSQL 数据,并以结构化的分析报告形式返回结果。
2. 效果展示:李xx的中餐店深度分析报告
以下为针对示例数据库执行上述提问后,Skill 返回的完整分析报告示例。
店铺基本信息
属性 | 详情 |
店铺 ID | f28b7494xxxx63defce99c5 |
店铺名称 | 李xx的中餐店 |
品类 | 甜品 |
评分 | 3.2 / 5.0 |
营业状态 | 休息中 |
营业时间 | 09:00 - 22:00 |
联系电话 | 1522499**** |
地址 | 杭州市南山区解放路xxx号 |
入驻时间 | 20xx年7月29日 |
菜品结构分析
店铺目前上线 5 款菜品,全部标注为"热销"标签:
菜品名称 | 分类 | 价格 | 状态 |
特色海鲜 | 小吃 | ¥149.88 | 可售 |
特色鸡肉 | 饮品 | ¥68.07 | 可售 |
招牌鸡肉 | 招牌菜 | ¥53.83 | 可售 |
特色牛肉(款1) | 招牌菜 | ¥144.01 | 可售 |
特色牛肉(款2) | 招牌菜 | ¥172.21 | 可售 |
菜品策略特点:
精简 SKU:仅 5 款菜品,聚焦核心品类,降低运营复杂度。
高价定位:均价 ¥117.60,远超平台快餐类均值,走精品路线。
招牌菜为主:3/5 为招牌菜,强调差异化竞争力。
分类混乱:"特色鸡肉"被归类为"饮品","特色海鲜"归类为"小吃",存在数据质量问题。
订单运营分析
总订单数:24 单(全平台排名第 1)。
订单状态分布
状态 | 数量 | 占比 |
completed(已完成) | 8 | 33.3% |
delivering(配送中) | 6 | 25.0% |
preparing(制作中) | 5 | 20.8% |
pending(待处理) | 4 | 16.7% |
cancelled(已取消) | 1 | 4.2% |
关键发现:
完成率 33.3%,低于平台平均 35.1%。
在途订单占比高达 62.5%(preparing + delivering + pending),说明店铺近期活跃度较高。
取消率仅 4.2%,优于平台 5% 的平均水平。
营收表现
指标 | 数值 |
已完成订单总收入 | ¥7,043.33 |
平均客单价 | ¥880.42 |
最高单笔订单 | ¥1,496.06 |
最低单笔订单 | ¥140.77 |
客单价 ¥880.42 远超平台均值 ¥549(高出 60%),验证了其高端定位策略。
用户行为洞察
订单备注分析
24 单中有 13 单带有备注(54.2%),远高于一般外卖店,说明用户对该店有明确的个性化需求:
备注内容 | 频次 |
"发票抬头:个人" | 3 次 |
"多放辣" | 3 次 |
"送到前台" | 2 次 |
"请快一点" | 2 次 |
"打包带走" | 1 次 |
"少放葱" | 1 次 |
"不要辣" | 1 次 |
辣度偏好分化明显:"多放辣"和"不要辣"同时出现,说明用户群体口味差异大。
月度订单趋势
月份 | 订单数 |
20xx-04 | 2 |
20xx-05 | 1 |
20xx-06 | 2 |
20xx-07 | 3 |
20xx-08 | 2 |
20xx-09 | 5(峰值) |
20xx-10 | 1 |
20xx-11 | 4 |
20xx-12 | 2 |
20xx-01 | 2 |
9 月为订单高峰期(5 单),可能与秋季消费旺季或店铺促销活动相关。整体月均约 2.4 单,订单量偏低但稳定。
配送范围分析
订单配送地址覆盖多个城市:
杭州:2 单
深圳:4 单
上海:4 单
北京:1 单
广州:1 单
武汉:2 单
成都:2 单
西安:2 单
配送范围极广,跨越全国 8 个城市,这在实体餐饮中较为罕见,可能说明:
该店是虚拟店铺或连锁品牌。
数据存在模拟/测试性质。
使用了跨城配送服务。
核心问题与改进建议
存在的问题
评分偏低(3.2/5.0):在 Top 10 门店中排名倒数,口碑是最大短板。
完成率不高(33.3%):低于平台均值,可能存在出餐效率或服务质量问题。
品类与名称不匹配:店名"中餐店"但品类是"甜品",菜品分类也有混乱。
目前处于休息状态:错失订单机会。
改进建议
提升服务质量:重点关注用户反馈,优化出餐速度和菜品质量,争取将评分提升至 4.0 以上。
恢复营业:尽快恢复营业状态,抓住当前在途订单带来的流量。
规范菜品分类:修正"特色鸡肉→饮品"等分类错误,提升用户搜索体验。
辣度分级:针对用户"多放辣"和"不要辣"的分化需求,提供辣度可选(微辣/中辣/重辣/不辣)。
扩大 SKU:5 款菜品过于单薄,建议增加 10~15 款不同价位菜品,覆盖更多消费场景。