本体推理技能 - AI 辅助语义层建设
本体推理技能（Infer Ontology From LLM） 是 TIS 最具革命性的 AI 能力之一，它能够从已有的表结构中自动推断出关联关系、共享属性、值约束和业务术语等本体资源，将原本需要数小时甚至数天的手动建模工作压缩到几分钟内完成。
为什么需要本体推理
传统建模的痛点
在构建企业级语义层时，数据建模师需要手动完成以下工作：
- 分析表结构：逐个查看每张表的字段、类型、注释
- 识别关联关系：找出哪些字段是外键，表之间如何 JOIN
- 提取共享属性：发现多张表中重复出现的字段（如
create_time、status） - 定义值约束：根据业务规则，为字段添加枚举值、取值范围等约束
- 编写业务术语：整理业务名词与数据库表/列的映射词典
这些工作：
- 耗时长：一个中等规模的数据仓库（50 张表）可能需要 2-3 天
- 易出错：人工识别外键关系容易遗漏或判断错误
- 门槛高：需要同时熟悉业务语义和数据库设计
AI 推理的优势
| 维度 | 传统手动建模 | AI 推理技能 |
|---|---|---|
| 效率 | 数小时到数天 | 5-10 分钟 |
| 准确率 | 依赖人工经验 | 90%+（高置信度建议） |
| 覆盖度 | 容易遗漏边缘关系 | 全面扫描，不遗漏 |
| 可控性 | - | 人工审核，保留最终决策权 |
能推断哪些本体资源
1. LinkType（关联关系）
自动识别表之间的关联关系，支持三种关联类型：
| 关联类型 | 识别依据 | 示例 |
|---|---|---|
| ObjectTypeForeignKeys | 某表的列名为 xxx_id，且另一张表名为 xxx 并有 id 主键 | orders.user_id → users.id（一对多） |
| JoinTableDataset | 某表只有两个外键列组成联合主键，分别指向两张实体表 | user_roles 表（仅 user_id + role_id）连接 users 和 roles（多对多） |
| BackingObjectType | 某表有两个外键列，但还有其他业务属性列 | order_items 表（order_id + product_id + quantity）（带属性的多对多） |
AI 如何判断：
- 分析字段命名模式（
xxx_id、xxxId、fk_xxx） - 检查是否存在同名表（
user_id对应user或users） - 识别联合主键组合
- 读取列注释中的外键说明
2. SharedProperty（共享属性）
提取多张表中重复出现的相同语义字段。
识别依据：
- 至少在 2 张表中出现相同名称且相同类型的列
- 常见共享属性：
create_time、update_time、status、is_deleted、currency_code、version等
价值：
- 确保同一语义字段在不同表中类型一致
- 方便批量更新定义（如统一时区格式）
- 减少重复配置
3. ValueType（值约束）
为字段定义取值约束，包括枚举值、范围约束、正则表达式等。
识别依据：
| 约束类型 | 识别线索 | 示例 |
|---|---|---|
| Enum | 列注释中包含枚举值列表 | 注释："状态：PENDING/PAID/SHIPPED" → 生成枚举约束 |
| Range | 列类型暗示范围 | VARCHAR(3) + 列名 country_code → 范围约束（3个字符的国家代码） |
| Regex | 列注释中包含格式说明 | 注释："手机号格式：1[3-9]\d{9}" → 正则约束 |
价值：
- 数据质量校验
- 前端表单自动生成下拉框
- ChatBI 查询时理解合法取值
4. Glossary（业务术语词典）
将业务口语化表达映射到本体实体，支持 ChatBI 自然语言查询。
三种映射类型：
| 类型 | 映射目标 | 示例 |
|---|---|---|
| GlossaryTargetOT | 映射到某个 ObjectType | 术语"客户" → customer 表，同义词：["用户","User","buyer","购买方"] |
| GlossaryTargetProperty | 映射到某列 | 术语"订单金额" → orders.amount，同义词：["金额","总额","订单总额"] |
| GlossaryTargetMetricExpr | 映射到 SQL 表达式 | 术语"总销售额" → SUM(orders.amount)，同义词：["销售总额","GMV"] |
AI 如何生成同义词：
- 中文 ↔ 英文互译
- 业务术语 ↔ 技术名词（如"客户"与"user"）
- 口语化表达（如"卖了多少钱"与"销售额"）
- 行业术语（如电商领域的"GMV"）
以下是 Glossary 推理结果示例，包含术语、同义词、目标类型
使用流程（5 步）
本体推理是一个多步骤配置流程，采用"分批推理、逐步确认"的策略：
步骤 1：基本配置
在这一步完成：
打开本体域技能
选择 LLM Provider（大语言模型）
选择要分析的 ObjectType（最多 30 张表）
选择 LLM Provider
推荐的模型（按推理能力排序）：
- Claude Sonnet / Opus：推理能力强，尤其擅长分析复杂关系
- GPT-4 / GPT-4 Turbo：平衡推理能力与速度
- 通义千问 Max：国内推荐，中文理解好，性价比高
- DeepSeek Chat：性价比最高，适合中小规模表
注意：推理任务对 LLM 要求较高，不推荐使用 turbo 或 3.5 等轻量级模型。
选择目标表
从本体域中已导入的 ObjectType 列表中，勾选要分析的表。
限制：
- 最多同时分析 30 张表（防止 LLM 推理超时）
- 所有选中的表必须已设置主键（系统会自动校验）
建议：
- 首次使用：选择 5-10 张核心表，熟悉流程
- 批量推理：分多次运行，每次 20-30 张表
步骤 2：配置推理提示词（非关联关系）
在这一步完成：
- 编辑 ValueType 推理提示词
- 编辑 Glossary 推理提示词
- 编辑 SharedProperty 推理提示词
什么是推理提示词
提示词（Prompt）是指导 LLM 如何分析表结构的"任务说明书"。TIS 提供了默认提示词，但用户可以根据业务特点自定义。
默认提示词包含的内容：
- 任务目标（如"从表结构中提取枚举约束"）
- 识别规则（如"列注释中包含多个斜杠分隔的值，如 PENDING/PAID/SHIPPED"）
- 置信度判断标准（如"有显式注释 → high，根据命名推断 → medium"）
- 输出格式要求（结构化 JSON Schema）
何时需要自定义提示词
- 特殊命名约定：公司内部有特定的字段命名规范（如
f_xxx表示外键） - 行业术语：行业有专门的业务术语体系（如金融、医疗）
- 多语言环境：表注释是英文，但业务术语需要中文
示例：
假设公司规定所有外键字段以 fk_ 开头，可以在 LinkType 提示词中添加：
识别外键的额外规则：
- 字段名以 fk_ 开头，如 fk_user 指向 user 表
步骤 3：审核并接受建议（非关联关系）
在这一步完成：
- LLM 自动分析表结构，返回 ValueType、SharedProperty、Glossary 的推理结果
- 用户逐条审核，勾选要接受的建议
- 点击"保存"，系统创建选中的本体资源
推理结果的呈现
每条建议包含以下信息：
| 字段 | 说明 | 示例 |
|---|---|---|
| 名称 | 资源名称 | status_enum（ValueType） |
| 类型 | 本体资源类型 | ValueType / SharedProperty / Glossary |
| 置信度 | high / medium / low | high（列注释中明确标注枚举值） |
| 描述 | AI 生成的说明 | "订单状态枚举：待支付、已支付、已发货" |
| 详细配置 | 可展开查看完整定义 | 枚举值列表：PENDING, PAID, SHIPPED |
如何判断是否接受
- high 置信度：通常准确率 >95%，可直接接受
- medium 置信度：基于命名约定推断，需要人工核对
- low 置信度：AI 不确定，建议仔细审核或拒绝
审核技巧：
- 优先审核 high 置信度建议，快速处理大部分正确结果
- 对 medium/low 置信度建议，展开详细配置检查
- 遇到不确定的建议，可以先跳过，后续手动创建
步骤 4：配置 LinkType 推理提示词
在这一步完成：
- 编辑 LinkType（关联关系）推理提示词
为什么 LinkType 单独推理
关联关系的推理比其他资源更复杂：
- 需要综合分析多张表之间的关系
- 涉及外键约束、命名模式、业务逻辑
- 错误的关联关系会严重影响 ChatBI 查询准确性
因此，TIS 将 LinkType 推理放在独立步骤，让用户有更多时间调整提示词和审核结果。
LinkType 提示词的关键要素
- 外键命名规则：如
xxx_id指向xxx表的主键 - 关联表识别规则：如何判断一张表是"中间关联表"
- 特殊前缀/后缀：如
fk_、_ref、_link等 - 置信度判断：显式外键约束 → high，命名推断 → medium
步骤 5：审核并接受 LinkType 建议
在这一步完成：
- LLM 返回 LinkType 推理结果
- 用户逐条审核，勾选要接受的关联关系
- 点击"保存"，系统创建选中的 LinkType
LinkType 推理结果示例
| 关系名称 | 源表 | 目标表 | 关联类型 | 置信度 | 说明 |
|---|---|---|---|---|---|
orders_to_users | orders | users | ObjectTypeForeignKeys | high | orders.user_id → users.id（一对多） |
user_roles | users | roles | JoinTableDataset | high | 通过 user_roles 表关联（多对多） |
order_items | orders | products | BackingObjectType | medium | 通过 order_items 表关联，含数量等属性 |
审核要点
- 验证外键字段：确认源表的字段确实指向目标表的主键
- 检查关联类型：确认是一对多、多对多还是带属性的多对多
- 考虑业务合理性：AI 推断的关系是否符合业务逻辑
常见误判场景：
- 字段名相似但无实际关联（如
order_id和old_order_id） - 历史遗留字段已不再使用
- 跨业务域的表不应建立关联
使用最佳实践
1. 准备工作
确保表结构清晰：
- 所有表都有明确的主键
- 字段命名遵循一致的约定（如外键统一使用
xxx_id格式） - 列注释尽量详细（AI 会读取注释获取上下文）
补充表和列的描述：
- 在 ObjectType 的
description字段填写业务含义 - 为关键字段添加注释，说明取值范围、业务规则
2. 分批推理
不要一次性推理所有表：
- 首次使用：选择 5-10 张核心表，熟悉流程
- 熟悉后：每次 20-30 张表（接近上限）
- 优先推理核心业务表，再推理辅助表
优势：
- 避免 LLM 推理超时
- 逐步验证效果，及时调整提示词
- 降低一次性审核压力
3. 迭代优化提示词
第一次推理后：
- 检查 medium/low 置信度建议的准确率
- 如果某类错误频繁出现，调整对应提示词
- 例如：AI 总是把
xxx_code误判为外键 → 在提示词中明确"code 后缀通常不是外键"
积累领域知识：
- 保存优化后的提示词模板
- 新建本体域时复用模板，提升首次推理准确率
4. 交叉验证
使用多个 LLM 推理同一批表：
- Claude 和 GPT-4 对同一张表的推理结果通常有 80%+ 的重合
- 重合的建议往往是高准确率的
- 分歧的建议需要人工仔细判断
与传统方法结合：
- 将 AI 推理结果与数据库的
SHOW CREATE TABLE对比 - 检查是否有显式的
FOREIGN KEY约束被遗漏
5. 审核技巧
批量接受高置信度建议：
- 先筛选出所有
high置信度建议，快速浏览后批量勾选 - 节省时间，聚焦在 medium/low 置信度上
展开查看详细配置：
- 对于重要的 LinkType，务必展开查看源字段、目标字段是否正确
- 对于 ValueType 枚举约束，检查枚举值是否完整
遇到疑问时保守处理：
- 不确定的建议先跳过，后续手动创建
- 宁可少推理几条，也不要接受错误的关联关系
常见问题
Q1：为什么有些明显的外键关系没有被推理出来？
可能原因：
- 字段命名不符合常规模式（如
uid而不是user_id） - 目标表名与字段名差异较大（如
customer_no指向clients表） - 表或列的注释缺失，AI 缺少上下文
解决方法：
- 在 LinkType 提示词中补充公司特定的命名规则
- 为关键字段添加注释说明其外键含义
- 对于漏推理的关系，手动创建 LinkType
Q2：推理结果中有很多错误建议怎么办？
可能原因：
- 选择的 LLM 推理能力不足
- 提示词过于宽泛，导致 AI "过度推理"
- 表结构本身不规范（如字段命名混乱）
解决方法：
- 更换推理能力更强的模型（如 Claude Opus、GPT-4）
- 在提示词中增加"排除规则"（如"不要将 _code 后缀的字段判断为外键"）
- 标记表结构不规范的表，暂时跳过推理，优先整理表设计
Q3：推理任务超时或失败怎么办？
可能原因：
- 选择的表数量过多（超过 30 张）
- 单张表的列数过多（>100 列）
- LLM 服务响应慢或限流
解决方法：
- 减少每次推理的表数量（降到 15-20 张）
- 对于超大表，先简化表结构（只保留核心列）再推理
- 更换 LLM Provider 或稍后重试
Q4：如何评估推理质量？
量化指标：
- 准确率 = 接受的建议数 / 总建议数
- 召回率 = AI 推理出的关系数 / 实际存在的关系数（需要人工统计基线）
经验阈值：
- high 置信度建议准确率通常 >90%
- 整体准确率 >80% 视为良好
- 如果准确率 <70%，建议调整提示词或更换 LLM
持续优化：
- 记录每次推理的准确率
- 根据错误类型迭代提示词
- 建立"黄金标准数据集"（人工标注的正确关系），定期测试新提示词
Q5：推理后还能修改吗？
可以：
- 接受的建议创建为本体资源后，可以在对应的编辑页面修改
- 例如：修改 LinkType 的关联字段、调整 ValueType 的枚举值
- 修改后的资源不会再被推理覆盖
不会丢失：
- 推理历史记录保留，可以回看 AI 的原始建议
- 拒绝的建议不会自动再次出现（除非重新运行推理）
技术说明（高级）
本节面向对技术细节感兴趣的用户，非必读。
推理流程概览
- 收集上下文：系统提取所有选中 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 服务（如私有化部署的通义千问）