已实现：指标语义层（数据 × 语义结合）默认功能

语义融合的第一块已落地——指标不再只是数字，每个指标都绑定「业务口径 + 计算公式 + 关联知识文档」（即 Property Federation 的最小实现）。

接口：GET /api/semantic/metrics（指标目录 + 口径）· GET /api/semantic/metrics/values（取值）· GET /api/semantic/explain?q=退款率（取值+口径+公式+知识 一次返回）。LLM 绝不直出 SQL——指标由注册表声明、编译为参数化 SQL。

Entity Hub：实体上下文包

语义融合的第二块也已落地：GET /api/semantic/entity?object=account&id=A3001 把一个实体的结构化数据 + 关联对象（外键关系）+ 关联知识（知识库挂到该对象的文档）组装成统一上下文包。对话里问「把客户 A3001 的完整上下文给我」→ 助手用 entity_context 工具取整包，综合「客户概况 + 关联用户 + 关联质检报告」作答——即 Entity Hub 把同一实体在 DB 与 KB 中的存在对齐。

Relationship Cross-linking：关系跨链归因链

第三块也已落地：GET /api/semantic/chain?object=account&id=A3001 从实体出发沿关系图多跳遍历（正/反向外键），合并为一张 nodes + edges 图，每个节点聚合其关联知识文档——把 DB 关系与 KB 知识跨链成一条可走的归因链。对话里说「从客户 A3001 走一条归因链」→ 助手用 relation_chain 工具：起点(含质检报告) → 第1跳(用户/产品) → 第2跳(订单/门店/线索)… 串成链路叙述。实测从 A3001 展开 11 节点 / 23 边 / 3 跳。

一、问题：数据平台只走了第一公里

大多数数据平台（含传统 CDP / BI）只有一层 SQL 层：你问什么它查什么，但它不知道「退款率」是什么意思、8% 是否异常、退款和批次质量有没有关系。AI Agent 出现后，Agent 能写 SQL，但依然不懂业务——它能输出「退款率 8.2%」，却无法回答「给我分析一下」，因为它不知道 SKU 背后有供应链、批次里有质检报告。

数据平台只告诉你「发生了什么」，剩下的「为什么、怎么办」全靠人来走。缺少的，就是语义层。

二、什么是语义层

介于原始数据与上层应用之间的翻译层，做三件事：

关键洞察：让 AI 能回答业务问题的，不是写 SQL 的能力，而是理解业务的能力——这需要把数据库（结构化）和知识库（非结构化）在语义层融合起来。

三、语义融合架构

融合层由三部分组成：

一条完整的归因链

四、与知识库的融合（双源）

语义层的非结构化一极正是 知识库 Knowledge。两者的关系：

知识库支持多模态文件存储 + 关联到对象记录（如 account/A3001），这正是语义融合的落点：知识库文件经 Entity Hub 与数据库实体对齐、经 Property Federation 绑定到字段口径、经关系跨链并入统一关系图。能力组成：

• 知识切片与向量化 —— 知识库文件解析、切片、Embedding，支持语义检索。
• 实体对齐 —— 文件/段落与对象记录的自动 / 人工对齐（扩展现有「关联对象」能力）。
• 口径绑定 —— 把字段（如 total_orders）绑定到知识库里的口径说明文档，回答时一并给出定义。
• 归因链编排 —— Agent 沿统一关系图跨 DB / KB 多跳，构建归因链并生成建议。

五、一个真实例子

同一问题「上周退款率为什么突然升高？」，Agent 的处理不再是「查一下数据库」：

• 意图理解：混合型问题，需定量（退款率）+ 定性（原因）。
• 实体解析：「退款率」→ Entity Hub 定位到 orders.status=refunded 数据集 + 行业基准知识库文档。
• 数据采集（DB 侧）：上周 8.2%（前 4 周均值 2.7%，3 倍）；78% 退款来自同一 SKU FUR-2026-WINTER；质量问题集中在 B202603 批次。
• 知识关联（KB 侧）：B202603 质检报告「色泽不均，质检退回率 15%」；供应商 A 投诉率同比 +300%；行业基准 3–5%。
• 归因链构建：供应商 A 的 B202603 批次色泽不均 → 集中在该 SKU → 上周大量交付新客 → 新客退款 → 退款率飙升。

六、范式对比