工具推荐

TextQL：本体 vs 语义层 —— 企业智能问数系统概要设计方案

来源: 微信公众号「阿炳数记」
原文: https://mp.weixin.qq.com/s/QEa0pMd81eeGsbJE9hGImA
抓取时间: 2026-08-12
整理: A梦

一、核心观点

TextQL 发布檄文《语义层只是补丁，本体才是解药》，核心论点：

  1. **语义层（Semantic Layer）**能保证准确率（覆盖范围内接近100%），但覆盖范围外是0%
  2. 语义层建设依赖人工投入（FDE人员），建设速度跟不上业务变化
  3. **本体（Ontology）**是更好的解药：让 AI Agent 参与语义建设，而非仅消费语义

二、专有名词解释

2.1 语义层（Semantic Layer）

定义：在数据仓库之上建立的一层业务语义抽象，将数据库表字段映射为业务含义（如”销售额”、”客户数”）。

作用：

  • 让 AI/用户用自然语言问数时，能准确理解业务口径
  • 保证查询结果的一致性和准确性

代表产品：

  • Snowflake Semantic View
  • Databricks Metric View / Unity Catalog
  • dbt Semantic Layer

局限：

  • 覆盖范围内准确率接近100%，范围外为0%
  • 建设需要大量人工（FDE = Field Data Engineer）
  • 业务变化后定义需要同步更新

2.2 本体（Ontology）

定义：一组结构化的知识文件，描述企业中的指标、实体关系、数据来源、验证路径等。是 AI Agent 可以理解和使用的业务知识库。

与语义层的区别：

维度 语义层 本体
建设方式 人工为主 Agent + 人工审核
覆盖范围 有限（已建模部分） 可跨系统扩展
知识来源 主要在数仓 数仓 + 文档 + API
更新速度 慢（依赖人工） 快（Agent 自动探索）

2.3 Text-to-SQL

定义：将自然语言问题自动转换为 SQL 查询的技术。

准确率参考（dbt 2026 benchmark）：

  • 裸 Text-to-SQL：约70%
  • 加语义层：覆盖范围内接近100%

2.4 .tql 文件

定义：TextQL 的结构化语义定义文件，本质是带类型参数的 SQL 模板。

特点：

  • 参数会校验，过滤字段和操作符有白名单
  • 运行时可读取角色和租户属性（权限控制）
  • 最终执行的是仓库原生 SQL

2.5 FDE（Field Data Engineer）

定义：现场数据工程师，负责语义层的建设和维护。

工作内容：

  • 找表、确认关联关系
  • 定义指标、补业务解释
  • 测试和评审语义定义

2.6 Ana Agent

定义：TextQL 的 AI Agent，负责：

  • 理解自然语言问题
  • 跨系统查找数据
  • 生成 SQL 查询
  • 将发现的新知识提议回 Ontology

2.7 Memory + Reuse

定义：TextQL 的核心机制——Agent 探索过一次后，把走过的路径记下来，下次直接复用。

效果：TextQL 声称查询速度提升7倍

三、TextQL 系统概要设计方案

3.1 系统架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
┌─────────────────────────────────────────────────────────┐
│                    用户层（自然语言提问）                   │
└─────────────────────────┬───────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│                    Ana Agent（AI 代理）                   │
│  ┌─────────────┐  ┌──────────────┐  ┌────────────────┐  │
│  │ 意图理解     │  │ SQL 生成     │  │ 知识提议       │  │
│  │ 路径规划     │  │ 自由SQL/.tql │  │ Memory+Reuse   │  │
│  └─────────────┘  └──────────────┘  └────────────────┘  │
└─────────────────────────┬───────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│              Ontology Repository（企业知识库）            │
│  ┌─────────────┐  ┌──────────────┐  ┌────────────────┐  │
│  │ .tql 文件    │  │ 业务文档     │  │ Python/SQL     │  │
│  │ 指标定义     │  │ 财务制度     │  │ 可执行逻辑     │  │
│  │ 实体关系     │  │ 会议纪要     │  │ API 调用       │  │
│  └─────────────┘  └──────────────┘  └────────────────┘  │
└─────────────────────────┬───────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│                    数据源层                              │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌────────┐  │
│  │ 数据仓库  │  │ CRM      │  │ 工单系统  │  │ 文档   │  │
│  └──────────┘  └──────────┘  └──────────┘  └────────┘  │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│                    治理层（Git-based）                    │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌────────┐  │
│  │ Reviews  │  │ History  │  │ RBAC     │  │ Rollback│  │
│  └──────────┘  └──────────┘  └──────────┘  └────────┘  │
└─────────────────────────────────────────────────────────┘

3.2 核心工作流

流程1：标准查询（.tql 覆盖范围内）

1
用户提问 → Ana 理解意图 → 匹配 .tql 文件 → 填充参数 → 执行 SQL → 返回结果

流程2：自由探索（.tql 覆盖范围外）

1
2
3
4
5
6
7
用户提问 → Ana 理解意图 → 跨系统查找数据 → 生成自由 SQL → 执行查询 → 返回结果
                                                    ↓
                                          发现新知识/JOIN/口径
                                                    ↓
                                          提议修改 Ontology
                                                    ↓
                                          人工 Review → 固化为 .tql

流程3：知识沉淀

1
2
Agent 探索 → 发现新的数据关联/口径 → 提交 diff 到 Reviews
→ 人工审批 → 合并到 Ontology → 后续查询自动复用

3.3 关键设计决策

决策点 方案 理由
语义定义格式 .tql（结构化文件） 带类型参数、可校验、可版本化
知识库 统一 Ontology Repository 跨系统、跨格式、版本化管理
查询路径 双路径（.tql + 自由SQL） 确定性 + 灵活性兼顾
权限控制 文件夹级 RBAC 与 Git 权限体系一致
知识更新 Agent 提议 + 人工审批 效率 + 可信度平衡
上下文加载 按需加载（非全量塞入） 控制 token 成本

3.4 治理机制

  1. 版本控制：所有 Ontology 改动以 diff 进入 Reviews
  2. 审批流程：批准后才生效，支持回滚
  3. 审计追踪：History 记录谁在什么时候改了什么
  4. 权限边界：文件夹级权限决定用户/Agent 能读写什么
  5. Git 集成：支持 PR、CODEOWNERS、合并规则

四、与竞品对比

维度 Snowflake Databricks TextQL
语义定义 Semantic View Metric View .tql + Ontology
建设方式 人工定义 人工 + Agent建议 Agent探索 + 人工审批
覆盖范围 仓内 仓内 跨仓 + 文档 + API
查询路径 语义层 + Routing回退 语义层 + Free SQL .tql + 自由SQL
知识沉淀 集中建设 集中建设 持续生长

五、参考来源