TIS ChatBI 系统需求与设计概要文档

[baisui1981]

一、项目背景与目标

• 背景：当前企业数据仓库（基于 Apache Doris）包含大量数据表（100+），业务人员通过自然语言查询数据时，面临“表名与业务术语不一致”、“上下文Token限制”、“复杂业务逻辑无法理解”等痛点。
• 目标：构建一个基于“本体论 + GraphRAG + MCP”架构的智能 ChatBI 系统。该系统能够精准理解业务意图，自动检索相关元数据，生成符合 Doris 方言的高质量 SQL，实现“所问即所得”的数据分析体验。

二、核心架构设计

系统采用分层架构，核心由“语义层（本体建模）”、“检索层（GraphRAG）”和“执行层（MCP + LLM）”组成。

架构分层

• 用户层：接收自然语言提问（如“上个季度业绩最好的销售是谁？”）。
• 语义层：基于本体论构建的知识图谱，存储实体、关系、规则和指标定义。
• 检索层：GraphRAG 引擎，负责根据用户问题在图谱中检索相关上下文。
• 执行层：利用 Doris MCP Server 动态获取物理表结构，结合 LLM 生成 SQL。
• 数据层：Apache Doris 数据库（存储物理表与数据）。

三、本体论建模需求（语义层）

为了解决物理表与业务含义的鸿沟，需在外部系统（如向量数据库或图数据库）中构建轻量级本体。

实体定义

• 概念实体：将物理表抽象为业务对象。例如，物理表 fact_order 映射为业务实体 订单。
• 属性映射：定义实体的业务属性。例如，订单 实体包含 下单时间、支付金额 等属性，并关联到具体的物理字段。

关系定义

• 关联路径：明确实体间的连接方式，解决 Join 路径问题。例如：销售员 --(完成)--> 订单。
• 基数约束：定义关系类型（1:1, 1:N, M:N），辅助 LLM 判断聚合逻辑（如 1:N 关系通常暗示需要 SUM 或 COUNT）。

规则与指标

• 计算规则：存储复杂指标的计算公式。例如，毛利率 = (销售额 - 成本) / 销售额。
• 约束规则：定义数据有效性。例如，订单状态 枚举值含义（0-待支付，1-已完成）。

四、功能流程设计（GraphRAG + MCP）

这是解决“100张表Token浪费”问题的核心流程。

意图识别与图谱检索

• 输入：用户自然语言问题。
• 动作：系统提取关键词（如“业绩”、“销售”），在知识图谱中进行向量检索或子图匹配。
• 输出：筛选出与问题最相关的 N 个实体（如 销售员、订单）及其关联的物理表名列表（如 ['dim_salesman', 'fact_order']）。

动态上下文构建

• 动作：系统调用 Doris MCP Server 的 get_table_schema 工具。
• 参数：仅传入上一步筛选出的表名列表。
• 获取：获取这 N 张表的 DDL、字段注释和示例数据。

SQL 生成与执行

• Prompt 组装：系统提示词 + 检索到的业务规则 + 动态获取的物理表 DDL + 用户问题。
• 生成：LLM 生成精准 SQL。
• 执行：通过 MCP 或直连 Doris 执行查询并返回结果。

五、关键技术指标

模块	关键指标	说明
上下文管理	Token 效率	仅传递相关表（如 2-5 张）的元数据，而非全库 100+ 张表。
语义理解	准确率	通过本体映射，解决“业绩”对应 gmv 字段的语义对齐问题。
SQL 生成	可执行性	生成的 SQL 必须符合 Doris 方言，且 Join 路径正确。
扩展性	解耦	本体层与物理层解耦，物理表变更只需更新映射，无需重训模型。

六、实施路线图

阶段一：基础语义层构建

• 梳理核心业务表（Top 20）。
• 在外部系统中定义实体、属性及简单的表关联关系。

阶段二：GraphRAG 链路打通

• 部署 Doris MCP Server。
• 开发检索服务：实现“问题 -> 实体 -> 物理表名”的映射逻辑。

阶段三：规则与指标注入

• 在图谱中增加“计算规则”节点。
• 优化 Prompt 工程，使 LLM 能够读取规则并生成复杂表达式。

七、风险与应对

• 风险：图谱构建成本高。
• 应对：初期不追求全量本体，仅覆盖高频查询场景；利用 LLM 辅助从 DDL 注释中提取本体信息。
• 风险：检索召回率低。
• 应对：采用“关键词 + 向量”混合检索模式；引入“同义词”机制（如将“营收”映射为“销售额”）。
  你觉得这份设计文档的逻辑框架符合你的预期吗？
  为了让方案更完善，我可以继续帮你做以下调整：

1. 补充细节：需要我针对“本体层”补充具体的JSON/YAML 定义示例吗？
2. 丰富场景：需要增加几个具体的用户问答与系统处理流程的对比案例吗？
3. 调整侧重：如果这份文档是汇报给非技术高管看的，需要我将其改写为更侧重业务价值的版本吗？

[baisui1981]

问题

对于这个需求我想使用类似palantir的本体方式来定义GraphRAG中的对象，我知道本体中有以下概念：

1. 实体
2. 属性
3. 关系（定义实体之间是一对一，还是一对多，还是多对多的关系）
4. 规则（定义各种实体属性的约束规则）
5. 接口 定义实体之间各种继承关系
   这些在定义ChatBI使用场景下都是必要的吗？

回答

您希望引入 Palantir 式的本体论（Ontology）来定义 GraphRAG 中的对象，这是一个非常深刻且正确的方向。这标志着您的 ChatBI 系统正在从一个简单的“问答工具”演进为一个真正的“企业级语义层”。

您列出的五个概念（实体、属性、关系、规则、接口）是本体论的核心。但在 ChatBI 这个特定场景下，它们的必要性和实现方式有所不同。

简单来说：概念是必要的，但实现可以务实。 您不需要一开始就引入 OWL、RDF 等复杂的学术标准，而是应该吸收其核心思想，用更工程化的方式落地。

下面我将逐一解析这些概念在 ChatBI 场景下的必要性和实践建议。

🧬 实体 (Entity) 与 属性 (Attribute)

必要性：绝对必要

这是构建语义层的基础。它们的作用是将冰冷的物理表结构“翻译”成业务人员能理解的概念。

• 物理层: fact_order 表中的 usr_id 字段。
• 本体层 (Entity): 销售员 实体。
• 本体层 (Attribute): 销售员 拥有 姓名、工号、所属部门 等属性。

实践建议：
在您的 GraphRAG 中，销售员 就是一个核心实体节点。它的属性可以帮助 LLM 理解用户问题中的“销售”、“业务员”等词都指向这个实体。

🔗 关系 (Relation)

必要性：高度必要

关系是知识图谱的灵魂，它解决了“表与表如何 JOIN”这个核心难题。您提到的“一对一”、“一对多”等是关系的基数（Cardinality），在 ChatBI 中至关重要。

• 场景： 用户问“张三的总销售额是多少？”
• 图谱作用： 图谱中定义了 销售员 --(完成)--> 订单 的关系，并且明确了这是一个 1:N (一对多) 的关系。
• LLM 推理： LLM 看到 1:N 的关系，就知道在生成 SQL 时，应该从 销售员 表出发，通过 JOIN 关联到 订单 表，并对金额进行 SUM 聚合。

实践建议：
在定义关系时，不仅要定义“谁和谁关联”，还要尽可能标注关系的类型和基数。这能极大提升 LLM 生成复杂 SQL 的准确率。

⚖️ 规则 (Rule)

必要性：非常必要

规则是实现“精准”和“防幻觉”的关键。它将业务逻辑从代码中抽离出来，变成图谱的一部分。规则可以分为两类：

1. 约束规则 (Constraint Rules):

   • 作用： 保证数据质量和查询的合法性。
   • 例子： “订单 的 状态 属性只能是 待支付、已完成、已取消 中的一个。” 当用户问“查询所有有效订单”时，LLM 可以根据这条规则，自动生成 WHERE status IN ('已完成') 的条件。

2. 推导规则 (Inference Rules):

   • 作用： 将复杂的业务指标公式化。
   • 例子： “毛利率 = (销售额 - 成本) / 销售额”。当用户问“上个季度的毛利率”时，LLM 无需“知道”如何计算，它只需在图谱中找到 毛利率 这个指标节点，并读取其关联的推导规则，然后生成对应的 SQL 表达式。

实践建议：
规则是让您的 ChatBI 系统具备“业务知识”的核心。从最核心的指标定义开始，逐步丰富规则库。

🧩 接口 (Interface) / 继承关系

必要性：非必要 (在工程实践中可简化)

您提到的“接口”在本体论中通常指类的继承和层次结构（例如，猫 是 动物 的一种）。在学术上这很重要，但在 ChatBI 的工程实践中，它的优先级相对较低。

• 学术场景： 动物 有属性 呼吸方式，猫 继承 动物，所以 猫 也有 呼吸方式。
• ChatBI 场景： 您可能定义 线上订单 和 线下订单 都是 订单 的子类。虽然这在逻辑上很完美，但在生成 SQL 时，LLM 更关心的是它们是否在同一张表里，或者是否通过 order_type 字段区分。

实践建议：
不要过度设计。 您可以使用更简单的“标签（Tag）”或“分类（Category）”来代替复杂的继承体系。例如，给 订单 实体打上 线上业务 和 线下业务 的标签，就能满足大部分业务查询的需求，实现成本也低得多。

📌 总结与行动指南

您的思路非常超前。引入本体论是构建强大 ChatBI 系统的正确方向。但为了快速落地并看到效果，建议采用分阶段、抓重点的策略。

本体概念	ChatBI 必要性	核心作用	工程化建议
实体 & 属性	绝对必要	将物理表“翻译”为业务概念	从核心业务对象（如销售、订单）开始建模
关系	高度必要	解决表与表的 JOIN 路径问题	明确定义关系类型和基数（1:1, 1:N, M:N）
规则	非常必要	封装业务逻辑和指标定义	优先实现指标计算公式和关键约束
接口/继承	非必要	构建复杂的概念层次	初期可忽略，或用简单的“标签”替代

推荐的落地步骤：

1. 第一步：定义核心实体和关系。

   • 梳理出 5-10 个最核心的业务实体（如 销售员、产品、订单）。
   • 定义它们之间的关键关系（如 销售员-完成->订单）。
   • 将这些信息存入图数据库（如 Neo4j）或甚至是一个精心设计的 SQL 表中。

2. 第二步：为核心指标添加规则。

   • 挑选 3-5 个最常用的业务指标（如 GMV、毛利率）。
   • 在图谱中为它们创建节点，并用属性或关系来存储其计算规则（SQL 表达式）。

3. 第三步：让 GraphRAG 工作起来。

   • 当用户提问时，您的 GraphRAG 系统先从图谱中检索相关的实体、关系和规则。
   • 将这些精简后的、富含业务语义的信息作为上下文，连同物理表的 DDL 一起交给 LLM。

通过这种方式，您就构建了一个真正“懂业务”的 ChatBI 系统，它不仅能生成 SQL，更能理解业务背后的逻辑。

[baisui1981]

还有一个问题，如果实现构建的graphRAG的内容没有覆盖到doris数据库的相关表，例如：用户询问业绩相关的BI请求，但是管理员还没有 针对相关表的领域知识构建到graphRAG库中，此时用户如果发起询问，很明显系统无法正常执行逻辑，此时应该如何处理呢？

这是一个非常切中要害的问题。在工程实践中，“冷启动”（即图谱尚未构建完全）和**“长尾需求”**（即用户查询了图谱未覆盖的边缘领域）是必须面对的现实。

如果 GraphRAG 中找不到对应的实体，系统不应该直接报错或拒绝回答，而是需要一套**“降级策略”（Fallback Mechanism）**。

我们可以借鉴 RAG 系统中的“混合检索”思想，设计一套从“语义检索”到“暴力检索”再到“人工介入”的漏斗式处理流程。以下是具体的解决方案：

🛡️ 核心策略：多级降级机制

当 GraphRAG 检索失败（或置信度低）时，系统应按顺序尝试以下方案：

1. 第一级降级：基于向量相似度的“模糊匹配”

即使你没有在 GraphRAG 中构建“业绩 -> fact_order”的明确关系，但如果你的元数据管理表中存储了所有表的注释或字段描述的向量索引，系统依然可以尝试“碰运气”。

• 原理： 将用户问题（“业绩”）转化为向量，去全量元数据向量库中检索 Top-K 最相似的表注释。
• 场景： 虽然图谱里没配“业绩”，但 fact_order 表的注释里写了“记录销售流水和金额”。向量相似度可能会把这两个概念拉近。
• 处理： 如果相似度分数超过某个阈值（如 0.75），则视为“潜在相关”，将这些表作为候选集传递给 LLM。

2. 第二级降级：基于关键词的“暴力扫描”

如果向量检索也没结果，退回到最基础的关键词匹配。

• 原理： 提取用户问题中的名词（“业绩”、“销售”），在所有表的 表名、字段名、字段注释 中进行子串匹配。
• 场景： 用户问“业绩”，虽然图谱没配，但 t_sales_performance 表名里直接包含了“performance”。
• 处理： 只要命中关键词，就将该表列入候选名单。

3. 第三级降级：LLM 的“常识推理” + 全量表名扫描

如果上述都失败了，利用 LLM 强大的通用知识库。

• 原理： 虽然不能把 100 张表的 DDL 都给 LLM，但可以把100 张表的“表名 + 简短注释”（非常省 Token）发给 LLM。
• Prompt 示例：

  “用户问‘业绩’，但我没找到明确的映射。这是数据库所有表的列表：[t_user, t_order, dim_product, ...]。请根据你的常识，猜测哪张表可能包含‘业绩’相关的数据？”

• 处理： LLM 可能会回答：“通常 t_order 或 fact_sales 可能包含业绩数据。” 系统据此获取这几张表的详细 DDL 进行尝试。

4. 第四级防线：澄清与人工反馈

如果连 LLM 都无法猜测，或者生成的 SQL 执行结果置信度极低，系统应诚实地“示弱”。

• 多路召回与澄清：
  • 系统：“我找到了几张可能相关的表：t_order（订单表）、t_kpi_result（绩效表），请问你想查询的是哪张表的数据？”
  • 用户选择后，系统再基于选定的表生成 SQL。
• 标记待办：
  • 系统记录这条失败的 Query：“用户查询‘业绩’，但图谱未覆盖”。
  • 这就形成了一个**“本体构建待办清单”**，管理员可以定期查看这些日志，将缺失的知识点补充到 GraphRAG 中，实现系统的自我进化。

🔄 优化后的系统流程图

结合之前的 GraphRAG 架构，现在的完整流程如下：

1. 用户提问：“上个季度业绩最好的销售是谁？”
2. GraphRAG 检索：
   • 去图谱查“业绩”实体。
   • 结果 A（命中）： 找到实体，获取关联表 fact_order。 -> 进入正常 SQL 生成流程。
   • 结果 B（未命中）： 图谱中无“业绩”实体。 -> 触发降级流程。
3. 降级流程：
   • Step 1 (向量检索)： 在元数据向量库搜“业绩”。 -> 未找到高分结果。
   • Step 2 (关键词匹配)： 搜表名/注释含“业绩”。 -> 未找到。
   • Step 3 (LLM 猜测)： 发送全量表名列表给 LLM 进行常识推理。 -> LLM 建议 fact_order。
4. 验证与执行：
   • 系统获取 fact_order 的 DDL。
   • 生成 SQL 并尝试执行（或在沙箱中验证）。
   • 成功： 返回结果，并提示用户“我是根据表名猜测的，结果仅供参考”。
   • 失败/存疑： 触发澄清模式，询问用户具体指哪张表。
5. 闭环优化：
   • 无论成功与否，将此次“未命中”记录写入日志，提示管理员：“建议将‘业绩’一词添加到 fact_order 的本体定义中”。

📌 总结

不要试图在第一天就构建完美的 GraphRAG。

系统必须具备**“容错性”。通过向量兜底**、LLM 常识推理和用户澄清这三道防线，即使 GraphRAG 内容缺失，系统依然能保持基本的可用性（虽然可能准确率稍低），同时通过日志记录不断反哺 GraphRAG 的建设。