Ontology 学习 - 技术栈

参考：

什么是Ontology本体论数据结构？Palantir 技术原理解析 - 知乎

Palantir到底强在哪里？一文看懂它的产品、技术与服务体系

Palantir官方产品体系可以概括为四大平台：

Gotham：面向国防、情报、公共安全等复杂任务的决策操作系统
Foundry：面向商业企业的数据运营与业务操作系统
AIP：把大模型、Agent和企业真实业务连接起来的AI平台
Apollo：跨云、跨边缘、跨高安全环境的软件持续交付平台

Foundry：企业数据运营平台，不只是数据中台

把企业分散的数据、模型、流程和应用，统一映射到一个可操作的业务语义层上。

Foundry的典型能力

它不是停留在"Dashboard看板"，而是进一步进入"业务动作"。

例如：

发现某个工厂产线异常，不只是展示异常，而是触发维修流程
预测某个区域库存不足，不只是生成报表，而是建议补货计划
识别某个客户流失风险，不只是打标签，而是推送给销售行动
发现供应链延迟，不只是报警，而是模拟替代供应商方案

Foundry试图回答：现在该怎么做？

Ontology不是一个简单的数据字典，也不是字段映射表。它更像是企业的"数字孪生语义层"。

它把真实世界里的业务对象抽象成：

Object Type：对象类型，比如客户、订单、飞机、工厂、设备、供应商
Property：对象属性，比如订单金额、交付时间、设备状态
Link Type：对象关系，比如客户属于某区域、订单关联某供应商
Action Type：动作类型，比如审批、调度、修改计划、派发任务
Function：业务逻辑，比如预测风险、计算优先级、生成方案

有了Ontology，AI才可以进入业务现场：

理解业务对象
读取可信数据
调用业务逻辑
遵守权限边界
触发真实动作
保留审计记录
接受人类复核

AIP不是简单让员工"问AI问题"，而是让AI在受控环境下参与真实业务流程。

AIP的核心能力

AI不能只是生成答案，它必须在安全、权限、审计和业务上下文里完成行动。

AIP强调Evals。因为企业里的AI不是玩具，不能只看"回答是否像人"。它必须被测试：

输出是否稳定？
是否调用了正确数据？
是否越权？
是否符合业务规则？
是否能被审计？
不同模型之间哪个更适合这个场景？
Prompt变化是否影响结果？
Agent动作是否可控？

这就是企业AI从Demo走向Production必须经历的一步。

制造业

代表方案：Warp Speed

核心场景：

生产计划
供应链协同
质量管理
产能优化
供应商风险
本土制造能力提升

制造业的问题非常适合Ontology，因为它天然包含大量对象关系：工厂、设备、产线、物料、订单、供应商、工艺、质量、库存。

从外部看，Palantir似乎可以被拆成几个已有品类：

数据平台像Snowflake / Databricks
工作流像ServiceNow
应用开发像Retool
BI像Tableau / Power BI
AI Agent像各种大模型应用平台
DevOps像GitLab / Harness

但Palantir给出的路径是：

1. 先定义业务对象
2. 再打通关键数据
3. 建立企业Ontology
4. 围绕高价值场景构建工作流
5. 接入AI和Agent
6. 加上权限、审计、评估和人类复核
7. 最后进入真实业务动作

Context，不只是文档，不只是知识库，而是包括：

业务对象
数据关系
组织权限
流程规则
决策逻辑
历史行动
反馈结果
行业经验

Palantir真正做的是一套面向复杂组织的"决策基础设施"。

它把数据连接起来，把数据映射成业务对象，把业务对象变成工作流，把AI放进工作流，把权限和审计嵌入全过程，最后让组织能够更快、更安全、更持续地行动。

参考：

Palantir本体论开源实现：TIS Ontology × ChatBI落地方案解析

Palantir 的解法是先建立一层 Ontology，把所有业务语义固化下来。你不再是让模型直接面对数据库表，而是让模型面对一个经过语义建模的业务世界：里面有"客户""订单""产品"这些对象，有对象之间的关联，有"老客户"这个业务指标的标准定义，有"下单金额"的口径约束。

大模型只负责把用户问题转换成对本体层的查询，不需要知道底层有几张表、外键怎么关联。这就像你问一个前台"财务部王经理在哪个办公室"，他不需要知道公司管线的走向，只需要知道组织结构图。

将数据从物理模型（表结构）提升到语义模型（业务对象），让业务人员和技术人员使用同一套语言。

Ontology：对象、链接、动作与业务语义

2.1 Object（对象）

对象是业务世界的实体映射。它不是一个数据库表，而是一个带业务语义的实体类型。

"客户"对象不是 customer 表，而是一个聚合了客户姓名、等级、归属区域、历史订单数、复购率等信息的业务实体。对象可以来自一张表，也可以是多个表 JOIN 后的结果，甚至可以是从数据接口实时同步上来的。

2.2 Link（链接）

链接定义对象之间的关系。

一个"客户"可以有多个"订单"，一个"订单"可以包含多个"产品"。这些关系不是简单的数据库外键，而是带语义的连接。比如"客户下单"和"订单发货"是两种完全不同的关系，它们对应不同的业务含义、不同的权限范围。

2.3 Property（属性）

属性是对象的字段，但不仅仅是列名。

属性可以带有业务约束。比如"订单金额"要求非负且精确到分；"客户等级"的取值只能是"普通""银卡""金卡""黑卡"。属性也可以派生，例如"复购率"是根据历史订单自动计算的，不需要业务方自己算。

2.4 Action（动作）

在 Palantir Ontology 中，你可以在对象上定义动作，比如"调整客户等级""创建订单""关闭工单"。每个动作都有输入参数、前置条件、审批流和权限控制。

这意味着 Ontology 不只是查询层，还是一个业务操作层。ChatBI 不只是"问数"，还可以变成"办事"------用户说"把这个客户升级为金卡"，系统就能执行对应动作。

TIS Ontology 五大组件

把本体语义层拆解为五个部分：

ObjectType（对象类型）：一张业务表就是一个对象，从数据源一键导出主键外键，自动识别字段
Property（属性）：给每个字段盖上语义角色印章------标识列、分组维度、时间维度、可聚合度量，度量还能绑定十多种聚合函数（销售额用 SUM、客单数用 COUNT DISTINCT），并支持 Palantir 式的 value type、shared property、derived property 细粒度配置
Linker（关系类型）：把外键刻成桥梁，同时也是一份 JOIN 白名单，不在名单里的连接一律拦截
Glossary（业务术语词典）：GMV、成交金额、revenue 映射到同一个指标定义，支持同义词自动匹配，高频查询 1 秒级命中
Constraint（约束体系）：枚举范围、正则、时间窗口，让筛选条件永远不出格

GraphRAG 四路并行检索

面对几百张表的本体，系统用四路检索同时开火：向量召回理解语义、词点直配秒杀术语、关键词兜底不空手、子图扩展沿 Linker 自动发现 JOIN 路径。四路会合凝成一个约 3000 tokens 的"子图胶囊"，全程 150 毫秒。对比全量注入 15 万 tokens（约 4.5 美元），一次 GraphRAG 只需约 9 分钱，成本降低 98%，且上下文更聚焦、准确率更高。

ChatBI 六步执行流程与三层安全校验

以"2025 年各城市销售总额排名前十"为例：

GraphRAG 检索本体
Prompt 组装器拼好 Doris 方言规则和业务上下文
大模型生成 SQL
三层安全校验：白名单只放行 SELECT（直接拍碎其他语句）→ AST 校验把 SQL 拆成语法树，逐表、逐字段、逐 JOIN 核对白名单 → EXPLAIN 动态校验让 Doris 先预演，方言错误、类型错误、聚合错误统统现形，危险 SQL 拦截率 100%
Doris 执行，秒级出结果
结果返回并附完整 trace 日志（检索了什么、提示词是什么、SQL 怎么来的），全程透明

参考：TIS介绍 | 零代码数据集成平台 + ChatBI智能问数

TIS 是新一代 AI 原生数据集成平台。在大模型重塑行业的今天，TIS 率先将 LLM 深度融入数据工程全链路------

🗣️ 用自然语言创建数据管道 ：告别复杂配置，一句话描述业务需求，Pipeline AI Agent 自动完成插件选型、参数生成与任务编排

🧠 用知识图谱理解业务语义 ：Ontology 本体层 + Neo4j 图数据库，将业务术语、指标口径、实体关系沉淀为可持续积累的企业知识资产

💬 用自然语言洞察数据：ChatBI 模块基于 GraphRAG 四路并行检索，业务用户无需 SQL，直接提问即得数据分析结

果

1. ChatBI --- 自然语言驱动数据洞察

基于 Ontology知识图谱 + GraphRAG检索增强 技术，TIS v5.1.0 引入 ChatBI 能力，让业务用户无需编写 SQL，直接用自然语言提问即可获得数据分析结果：

语义理解：Ontology 本体层精确定义业务实体（Glossary词典、聚合函数、语义角色等），消除歧义
图谱检索：GraphRAG 四路并行召回 + 子图扩展，精准定位相关数据实体及其关联关系
多模型支持：无缝接入 DeepSeek、通义千问、GPT-4 等主流 LLM
知识沉淀：Neo4j 图数据库持久化业务知识，随着使用不断积累，越用越聪明

用户问："上个月华东区销售额最高的产品是哪些？"

↓ Ontology 语义解析

↓ GraphRAG 知识检索

↓ LLM SQL生成

↓ 结果可视化

2. Pipeline AI Agent --- 让数据管道听懂人话

告别复杂配置，自然语言描述需求即可创建管道
智能插件检测与自动安装，LLM辅助参数生成
支持DeepSeek/通义千问等国产模型，成本低至几毛钱

参考：

本体（Ontology）概述 | 零代码数据集成平台 + ChatBI智能问数

TIS 本体（Ontology）是构建在物理数据之上的语义层，将底层数据库表、字段等物理概念抽象为业务实体（Object Type）和关联关系（Link Type），使数据具有明确的业务含义。

核心价值

价值	说明
统一语义	跨系统、跨数据源的数据以统一的业务语言描述，消除字段命名差异
ChatBI 基础	为 TIS ChatBI 模块提供语义理解基础，支持自然语言查询数据
业务一致性	业务分析人员、数据开发人员使用同一套概念体系沟通，降低理解成本
可复用	共享属性（Shared Property）、值类型（Value Type）可在多个实体间复用，保证一致性

Domain（本体域）

Domain 是 TIS 本体的顶层命名空间，用于将不同业务场景下的本体元素（Object Type、Link Type、Shared Property、Value Type、Glossary）进行逻辑隔离与分组管理。

在企业级数据集成场景中，不同业务线（如"交易"、"供应链"、"会员"）往往需要各自独立的语义定义，彼此间的概念并不相通。例如，"交易域"中的 order_amount 代表订单金额，而"供应链域"中的 amount 可能代表库存数量。若将所有本体元素混放在一起，会带来命名冲突、语义混淆等问题。

通过 Domain，可以：

命名空间隔离：不同 Domain 内允许存在同名的 Object Type 或属性，各自独立管理，互不干扰
业务场景分组：一个 Domain 对应一个完整的业务领域，聚焦该领域的数据语义定义
权限与管理边界：Domain 是本体管理的基本单元，后续的权限控制、ChatBI 启用等均以 Domain 为粒度

Domain 的结构

一个 Domain 包含以下本体子元素：

子元素	说明
Object Type	业务实体定义，对应物理数据源中的一张表
Link Type	描述两个 Object Type 之间的关联关系
Shared Property	跨 Object Type 复用的共享属性定义
Value Type	可复用的语义数据类型定义
Glossary	业务术语字典，支持 ChatBI 自然语言问数

使用场景

按业务线划分：交易域、供应链域、会员域、财务域
按数据源划分：MySQL 业务库域、数仓域、实时流域
按团队划分：不同团队维护各自的本体域，避免相互干扰

Object Type（对象类型）

Object Type 是 TIS 本体（Ontology）中对业务实体的抽象描述。每个 Object Type 对应数据源中的一张物理表，代表一类具有明确业务含义的对象，例如"客户"、"订单"、"商品"等。

核心概念

实体映射：一个 Object Type 绑定一张具体的数据库表，其属性（Property）与表中的列一一对应。
属性集合：Object Type 通过添加 Property 来描述实体的各项特征，包括标识符、维度、时间维度和度量值。
关联关系：通过 Link Type 将多个 Object Type 连接起来，构建实体间的关联语义。

Object Type 的作用

在 TIS 中，Object Type 是语义层的基础单元：

统一命名：为来自不同数据源的同一业务对象建立统一的语义名称，避免因表名差异导致的混乱。
属性语义化：通过为每个 Property 设置语义角色（SemanticRole），使查询引擎和 ChatBI 能够理解哪些字段是维度、哪些是度量值。
关系建模：作为 Link Type 的端点，参与构建跨表的关联关系，支持多表联查与导航。

与数据源的绑定

创建 Object Type 时，需要选择目标数据源（DataSource）并指定绑定的物理表。系统会自动读取表结构，用户可在此基础上为各列添加语义描述。

需要填写以下信息及将 Object Type 与物理数据表关联：

字段	说明	要求
名称（Name）	Object Type 的唯一标识名称	必填，符合标识符规则
描述（Description）	对该业务实体的业务含义说明	建议填写，便于团队理解

选择数据源（DataSource）：从已配置的数据源列表中选择目标数据源
选择目标表：在选定数据源中选择与该 Object Type 对应的物理表

可以为 Object Type 配置初始属性（Properties）：

系统会自动列出物理表中的所有列
您可以选择将哪些列纳入语义层管理

系统会自动列出物理表中的所有列
您可设置那一列为主键
您可设置那一列为标题键

Link Type 概述

Link Type（链接类型）用于描述两个 Object Type 之间的语义关联关系。通过 Link Type，TIS 本体能够将分散在不同数据表中的业务实体连接起来，形成完整的语义数据图。

Link Type 的作用

在实际业务数据中，实体之间往往存在各种关联关系，例如：

订单（Order）关联到客户（Customer）
商品（Product）属于某个类目（Category）
员工（Employee）隶属于部门（Department）

Link Type 将这些关联关系显式建模为本体中的一等公民，使 ChatBI 查询引擎能够自动理解并利用这些关系，在查询时完成跨实体的数据聚合与分析。

Link Type 的关联方式

TIS 支持三种关联方式，以适配不同的物理数据模型：

类型	适用场景
ObjectTypeForeignKeys	两张表之间有直接外键引用关系
JoinTableDataset	多对多关系，通过中间关联表连接
BackingObjectType	通过已定义的 Object Type 作为中间桥接

关联的 ObjectType 要求

参与关联的 ObjectType 必须已经在本体中创建
使用 BackingObjectType 类型时，左右两端的 ObjectType 必须已设置主键（PK）
一个 ObjectType 可以同时参与多个 Link Type

类型一：ObjectTypeForeignKeys（外键关联）

适用场景：事实表与维表之间存在直接外键关联。例如，订单表（Order）通过 customer_id 字段关联到客户表（Customer）。

配置字段：

字段	说明
Left（左端）	左侧 Object Type 及其关联字段（通常为事实表侧）
Cardinality（基数）	关联的基数关系，可选 `MANY_ONE`、`ONE_ONE` 等
Right（右端）	右侧 Object Type 及其关联字段（通常为维表侧）

示例：

复制代码

Left:  Order.customer_id
Cardinality: MANY_ONE
Right: Customer.id

生成的 Link 标识名格式为：{left_objectType}_join_{right_objectType}

类型二：JoinTableDataset（中间关联表）

适用场景：两个 Object Type 之间为多对多关系，需要借助一张中间关联表来记录关联关系。例如，订单（Order）与商品（Product）之间通过订单明细表（OrderItem）关联。

配置字段：

字段	说明
Left（左端）	左侧 Object Type 及其在关联表中的关联字段
Right（右端）	右侧 Object Type 及其在关联表中的关联字段
Join（关联表）	中间关联表的 Object Type，以及两个关联键字段（`targetField` 和 `rightTargetField`）

Left: Order.id

Right: Product.id

Join: OrderItem（关联字段：order_id → rightTargetField: product_id）

类型三：BackingObjectType（背靠对象关联）

适用场景：两个 Object Type 通过另一个 Object Type 桥接关联，系统会自动从左侧和右侧 Object Type 中推断主键字段，无需手动指定关联字段。

配置字段：

字段	说明
leftObjectType	左侧 Object Type 名称（必须已设置主键）
rightObjectType	右侧 Object Type 名称（必须已设置主键）
joinObjectType	桥接中间 Object Type 及其在中间表上的两个关联字段

leftObjectType: Customer（主键：id，自动推断）

rightObjectType: Product（主键：id，自动推断）

joinObjectType: CustomerProduct（关联字段：customer_id → rightTargetField: product_id）

特性	ObjectTypeForeignKeys	JoinTableDataset	BackingObjectType
关联方式	直接外键	中间关联表	中间 ObjectType 桥接
需要指定关联字段	是	是	仅指定中间表字段
自动推断主键	否	否	是（两端自动推断）
适用关系	一对多、一对一	多对多	多对多（主键推断）
前提条件	无	无	两端必须设置主键

属性（Properties）

属性（Property）是 ObjectType（对象类型）的核心组成部分，描述了业务实体具备的各个数据字段。每个属性对应物理表中的一列或由物理列派生计算出的值。

属性的作用

数据语义化：将物理字段名转换为具有业务含义的语义标签
类型约束：为每个字段指定数据类型（整数、字符串、时间等）
主键标识：标记哪个属性作为 ObjectType 的唯一标识符
查询优化：通过物理表达式支持列的预处理转换
ChatBI 支持：通过语义角色（SemanticRole）为 AI 查询提供分析维度信息

属性包含的配置项

配置项	说明
名称（name）	属性标识名，需符合数据库列命名规则
描述（description）	业务含义描述，供查询引擎和 ChatBI 使用
数据类型（typeRef）	属性的数据类型，或关联到 SharedProperty / ValueType
是否主键（pk）	标记是否为 ObjectType 的主键列
是否可空（nullable）	属性值是否允许为 NULL
语义角色（roleType）	指定 ChatBI 场景下属性的角色（标识符、维度、度量等）
物理表达式（physicalExpression）	可选，描述从物理列到查询格式的转换逻辑

添加属性

属性（Property）是 Object Type 的核心组成部分，描述业务实体的各项数据字段。每个属性代表 Object Type 在物理数据源中对应表的某一列，或通过物理表达式派生的计算列。

属性字段说明

在为 Object Type 添加属性时，需要填写以下字段：

基本字段

字段	说明	必填
名称（name）	属性的唯一标识名，必须符合数据库列名规范（字母、数字、下划线），同一 Object Type 内不允许重名	✅
描述（description）	属性的业务含义说明，建议用简洁的中文描述该字段的业务用途	✅
数据类型（typeRef）	属性的数据类型，从系统支持的本体类型中选择（如 STRING、INTEGER、DOUBLE、TIMESTAMP 等）	✅
主键（pk）	是否为该 Object Type 的主键列。每个 Object Type 建议设置一个主键，主键值唯一标识该实体的每条记录	✅
可空（nullable）	该字段是否允许为空值。当 pk=true 时，nullable 不能设为 true	✅
语义角色（roleType）	属性的业务语义角色，用于 ChatBI 等分析场景。详见角色类型说明	✅

高级字段

字段	说明	必填
物理表达式（physicalExpression）	可选。当物理存储中的列值需要转换后才能使用时，填写转换表达式。详见物理表达式	❌

派生属性（Derived Property）

派生属性是基于 Link Type 关系链路进行跨对象聚合计算的特殊属性，属于语义角色为 Measure（度量）的属性在启用派生模式时的配置形态。

什么是派生属性

在业务分析场景中，经常需要将不同对象间的数量关系汇总计算，例如：

统计某个"客户"关联的所有"订单"的总金额
计算某个"商品"被下单的总次数

这类计算需要跨越对象之间的关联关系（Link）进行聚合，不能直接从单表字段读取。派生属性正是为此而设计：通过配置 Link 链路 + 聚合函数，系统可以自动生成对应的查询逻辑。

配置项说明

派生属性由 MeasureRole 实现（对应源码 MeasureRole.java），包含以下核心配置：

配置项	说明
linkers（关联链路）	选择从当前 ObjectType 出发，经过哪些 Link 到达目标对象。支持多跳（最多 3 跳），以 `OntologyLinkerRef` 列表形式配置
aggregation（聚合方式）	对目标字段执行何种聚合操作，由 `AggregationKind` 枚举定义，包含 SUM、COUNT、AVG、MAX、MIN 等常见聚合函数
unit（单位）	聚合结果的单位，如"元"、"次"、"件"等，纯描述性字段，用于在 ChatBI 展示时附加单位标签
precision（精度）	数值结果的小数位精度，如设置为 `2` 则保留两位小数

共享属性（Shared Property）

共享属性（Shared Property）是一种可以在多个 Object Type 之间复用的属性定义。当多个业务实体拥有相同语义的字段时，通过共享属性可以统一管理该字段的名称、类型、描述等元数据，避免重复定义，确保跨实体的语义一致性。

核心概念

定义一次，多处引用：一个 Shared Property 创建后，可以被任意多个 Object Type 的属性所引用
统一语义：引用同一 Shared Property 的所有属性，在 ChatBI 等分析场景中会被视为同一语义维度
独立维护：修改 Shared Property 的元数据（如描述）后，所有引用它的属性都会同步更新

典型使用场景

场景	示例
多实体共用状态字段	`status`（状态）字段在订单、退款、物流等多个实体中含义相同
统一货币单位定义	`currency_code`（货币代码）在销售、采购、结算等实体中含义一致
跨域通用分类标签	`category_id`（类别编号）被商品、活动、内容等多种实体引用

Value Type（值类型）

Value Type（值类型）是 TIS 本体中用于描述具有特定业务语义的数据类型的概念。它允许你定义一种带有业务含义的类型（如"货币金额"、"电话号码"、"百分比"），然后在多个 Object Type 的属性中复用，确保同类数据的语义一致性。

order_amount（订单金额）和 weight（重量）在数据库中都是 DOUBLE，但业务含义不同
phone（电话号码）和 address（地址）都是 STRING，但格式约束不同

通过定义 Value Type，可以将"货币金额"、"重量"、"电话号码"等业务概念抽象为可复用的类型，一旦为属性关联了相应的 Value Type，该属性便继承了该类型的业务语义。

核心特点

可复用：一个 Value Type 可以关联到多个 Object Type 的多个属性
语义标注：为属性赋予更具体的业务含义，超越基础数据类型的描述
集中管理：在本体的 Value Type 管理界面统一维护，修改后自动在所有关联属性中生效

使用场景

值类型示例	基础类型	适用属性
货币金额	DOUBLE	order_amount、refund_amount、cost
百分比	DOUBLE	discount_rate、tax_rate
电话号码	STRING	phone、mobile、fax
邮政编码	STRING	zip_code、postal_code
日期（无时间）	STRING	birth_date、expire_date

Glossary（业务术语词典）

Glossary（业务术语词典）是 TIS 本体语义层中的核心组成部分之一，用于在自然语言 与本体元素 之间建立明确的映射关系。它的本质是一张业务术语 → 本体元素的翻译字典，使 ChatBI 智能问数系统能够准确理解用户输入的业务语言，并将其转换为可执行的数据查询。

为什么 Glossary 至关重要

在企业的日常数据分析场景中，业务人员与技术人员之间往往存在明显的"语言鸿沟"：

业务人员说"GMV"，数据库里的字段名可能是 total_order_amount
业务人员说"活跃用户"，对应的是某个 Object Type 下特定筛选条件的人群
同一个指标在不同部门可能有不同称呼，例如"订单金额"、"成交额"、"营收"可能指向同一个度量

如果缺乏统一的术语管理，ChatBI 在面对这些多样化的提问方式时将无从应对。Glossary 正是解决这一问题的关键机制：

统一业务指标口径：通过为每个 Glossary 条目关联确切的本体元素（Object Type 或具体属性），确保同一个业务概念在全企业范围内只有一种解读
支撑同义词匹配：为每个术语配置多个同义词，让 ChatBI 能够识别用户说出的各种表达方式，并将其映射到同一个语义目标
消歧与解释：通过描述字段，明确记录该术语的业务含义，避免不同部门对同一词汇产生歧义

核心字段

Glossary 条目包含以下核心字段（来源：OntologyGlossary.java + DefaultOntologyGlossary.json）：

字段	标签	说明
term	实例名	术语的唯一标识名称，如 `GMV`、`active_user`。建议使用业务上约定俗成的简称
synonyms	同义词(s)	该术语的同义词列表，用于 ChatBI 自然语言匹配。例如 GMV 的同义词可以是"成交额"、"订单金额"、"营收"
description	描述	词汇的详细业务含义说明，明确该术语在企业中的口径定义
target	指向目标	术语映射到的本体元素，即该术语在语义层中对应的 Object Type、属性或其他本体对象

在 ChatBI 中的工作机制

当用户在 ChatBI 中输入自然语言问题（如"帮我看一下上个月的 GMV 是多少"）时，系统会经历如下流程：

术语识别：ChatBI 从用户输入中识别出关键词"GMV"
Glossary 检索：在当前本体域（Domain）的 Glossary 词典中查找匹配的 term 或 synonyms
语义映射 ：将识别出的 Glossary 条目对应的 target（本体元素）作为查询目标
查询生成：基于映射到的本体元素，结合用户的查询意图，生成可执行的数据查询

业务术语	同义词示例	指向目标
GMV	成交额、订单金额、营收	订单 Object Type 下的 `total_amount` 属性
活跃用户	DAU、日活	用户 Object Type（带活跃条件过滤）
复购率	回购率、留存率	派生属性（Measure）
客单价	人均消费	派生属性，GMV ÷ 用户数

使用流程

创建 Object Type --- 定义业务实体及其属性
创建 Link Type --- 定义实体间的关联关系
配置属性语义角色 --- 为属性指定 roleType，支持 ChatBI 查询
（可选）配置派生属性 --- 通过 MeasureRole 配置跨 Link 的聚合计算
（可选）创建 Shared Property--- 提取公共定义，跨实体复用
（可选）创建 Value Type --- 提取公共定义，跨实体复用
（可选）创建 Glossary --- 配置业务术语词典，统一指标口径，提升 ChatBI 自然语言理解能力
本体语义层冷启动 --- 配置语义层是一个非常繁琐，TIS提供基于大模型的语义层推理技能，帮你完成90%定义工作

推理流程概览

收集上下文：系统提取所有选中 ObjectType 的表结构（表名、列名、类型、主键、注释）
构造 Prompt：将表结构序列化为结构化文本，附加用户自定义的推理提示词
流式推理：调用 LLM Structured Output API，要求返回符合 JSON Schema 的结果
增量解析：LLM 以流式方式返回结果，系统实时解析并展示在界面上
用户确认：用户勾选建议后，系统批量创建本体资源
落盘存储：创建的资源保存到 TIS 的 PluginStore（XML 文件）

使用的 LLM 能力

结构化输出（Structured Output）：强制 LLM 返回符合预定义 JSON Schema 的结果，避免解析失败
流式响应（Streaming）：支持大批量推理时实时展示进度
上下文窗口：推理 30 张表约需 10K-20K tokens 的上下文窗口

数据安全性

不上传敏感数据：只上传表结构（metadata），不上传实际数据行
本地处理：所有推理结果在 TIS 服务器本地处理，不会回传给 LLM 服务商
可配置 LLM：支持使用自建 LLM 服务（如私有化部署的通义千问）

语义角色（Role Type）

每个 Object Type 属性除了基础的数据类型（typeRef）之外，还可以设置一个语义角色（roleType） ，用来描述这个字段在业务语义上承担的作用。语义角色是 TIS ChatBI 能够"理解"数据表结构、自动生成统计口径的关键依据 ------ 同样是数值类型的字段，被标记为 Measure 与被标记为 Identifier，在被 ChatBI 引用时的处理方式完全不同。

五种语义角色

SemanticRole 枚举共定义了 5 种角色：

角色	枚举值	说明
Unknown	0	未识别 / 未设置，默认兜底值，不参与任何语义化处理
Identifier	1	实体的唯一标识列，通常对应主键或业务编码（如订单号、用户 ID）
Dimension	2	用于分组、筛选的分类型属性（如地区、渠道、状态）
TimeDimension	3	时间属性，支持按粒度（天/周/月/年等）进行切分与聚合
Measure	4	可被聚合计算的数值型度量（如金额、数量），需配合派生属性配置聚合方式

Identifier（标识列）

用于标记该属性是用于唯一定位一条记录的标识字段。一个 Object Type 通常会有一个标识列与主键（pk）字段重合，但 pk 描述的是数据库层面的主键约束，roleType=Identifier 描述的是语义层面"这是一个 ID"的含义，二者关注点不同，并不强制一致。

Dimension（维度）

用于标记该属性是可以用来做分组（GROUP BY）或筛选（WHERE）的分类型字段。例如商品类目、订单状态、所属部门等。在 ChatBI 场景下，当用户提出"按渠道统计"之类的问题时，TIS 会优先在标记为 Dimension 的属性中寻找匹配项。

TimeDimension（时间维度）

时间维度是一种特殊的维度，额外具备按时间粒度（日、周、月、季、年）切分聚合的能力。下单时间、创建时间等字段适合标记为 TimeDimension，从而支持"近 7 天""按月统计"等时间相关的查询语义。

Measure（度量）

度量是可以被聚合函数（SUM、AVG、COUNT 等）处理的数值型字段，是统计分析的核心。当一个属性的角色被设置为 Measure 时，通常需要进一步配置该度量的聚合方式 ------ 这正是派生属性（Derived Property）要解决的问题。

它是企业数据资产的"语义地图"，一次建模可以服务多个场景：

数据血缘追踪：清晰展示"销售额"这个指标来自哪些表、经过哪些计算、被哪些报表使用
影响分析 ：当需要修改order_amount字段的定义时，能立即知道会影响哪些下游应用
数据质量监控：基于本体中的ValueType约束（如枚举值、范围限制），自动发现数据异常
自动化文档：从本体生成业务可读的数据字典，无需手工维护Word文档
数据发现：新入职的分析师想找"用户留存率"相关的表，通过Glossary搜索即可定位
权限管理：基于ObjectType粒度配置数据访问权限，比传统的表级权限更灵活