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 款不同价位菜品,覆盖更多消费场景。