亿问 Data Agent 智能问数板块核心算法解析：语义收敛，问数可信

本期我们将详细介绍亿问 Data Agent 可信问数部分的相关核心算法流程，其核心目标是将自然语言查询稳定、可控地转化为结构化 SQL，并在复杂真实业务环境中同时兼顾“确定性执行能力”和“语义不确定性处理能力”。

整体系统并不是单一的 NL2SQL 模型，而是由主链路确定性算法流程 + 异常语义增强机制共同构成的双层架构体系。

01 整体架构设计思想

亿问 Data Agent 的核心设计原则可以概括为一句话：用确定性链路保证结果可信，用增强机制覆盖真实世界的不确定性。因此系统被划分为两层：

• 第一层：主链路（确定性语义分析链路）：用于稳定生成 SQL，保证输出一致性与可解释性
• 第二层：增强链路（语义不确定性处理机制）：用于处理歧义表达、模糊意图和无法解析的复杂问题

02 主链路：核心算法流程（确定性路径）

主链路是整个系统的核心执行路径，保证从自然语言到 SQL 的稳定转换。

Step 1：用户输入（自然语言）

用户输入业务查询，例如：

“我要看下销售额，去年的”

该阶段特点：

• 非结构化表达
• 强口语化
• 信息缺失明显（指标、时间、口径）

因此需要进入语义标准化阶段。

Step 2：大模型语义标准化（意图净化层）+ 上下文继承

在这一阶段，系统的目标是将用户的自然语言问题，转换为结构化的业务语义表达，并补全缺失信息。

2.1

基础标准语义

例如：

输入：

“我要看下销售额，去年的”

标准化后：

• 指标：销售额（可能映射为 GMV / revenue）
• 时间：去年（需进一步解析为具体时间区间）
• 动作：查询（query）

输出：

查询指标 = 销售额

时间范围 = 2025 年（或系统定义的去年区间）

2.2

上下文继承机制（多轮语义保持）

在真实分析场景中，用户的提问往往是连续的，而不是孤立的。

例如：

第 1 轮问题：

销售额前三的 SKU 是哪些？

系统输出：

• SKU1
• SKU2
• SKU3

第 2 轮追问：

这些产品在哪些省份卖得好？

此时系统不会重新理解“这些产品”，而是会进行上下文继承与指代消解（Coreference Resolution）：

系统自动补全为：

SKU1、SKU2、SKU3 在哪些省份卖得好？

2.3

上下文继承的核心能力

Data Agent 在该阶段需要具备三类能力：

1）实体继承（Entity Carryover）

自动继承上一轮对话中的关键业务实体，

例如：

商品（SKU）| 客户 | 门店 | 渠道 | 区域 | 活动

例如：

• “这些客户”
• “上述门店”
• “刚才提到的产品”

都需要映射回上一轮真实实体集合。

2）条件继承（Condition Carryover）

继承上一轮的筛选条件，例如：

• 时间范围（如“去年”“最近30天”）
• 区域范围（如“华东地区”）
• 人群标签（如“高价值客户”）

例如：

第 1 轮问题：

华东地区去年销售额是多少？

第 2 轮追问：

按门店拆一下

自动补全为：

华东地区去年销售额，按门店拆分

3）语义补全（Semantic Completion）

在用户表达不完整时，系统结合业务语义自动补全缺失信息，例如：

• “销售额” → 补全为 GMV / revenue（基于企业语义层）
• “去年” → 补全年份区间
• “卖得好” → 转换为销量 / 销售额 / 转化率等可计算指标
• “哪些省份” → 补全地理维度映射

关键设计

在亿问 Data Agent 的架构中，这一层有一个非常关键但容易被忽略的设计原则：不需要给大模型任何业务知识。大模型在这里仅承担“语言规范化器”的角色，而不是业务推理引擎：

• 不注入指标口径
• 不注入业务规则
• 不注入数据模型
• 不参与 SQL 生成逻辑

它只做一件事：把自然语言“翻译”为结构统一的标准表达。

架构稳定性关键点

由于这一层不依赖业务知识与复杂提示词工程，因此带来一个非常重要的系统优势：提示词越少，系统越稳定。原因在于：

• 减少了大模型的自由发挥空间
• 降低了语义漂移概率
• 避免业务知识污染推理过程
• 输出更收敛、更一致

这一层的本质价值

这一设计使得系统具备一个非常关键的工程特性：在不牺牲理解能力的前提下，把大模型的输出“压缩为稳定接口”。因此这一层不是“智能增强层”，而是：系统稳定性的入口控制层（Stability Gate）。

Step 3：Alisa 语义理解引擎（核心结构化层）

Alisa 是系统的核心语义解析引擎，其特点如下：

• 100% 纯自研语义理解算法
• 基于知识图谱语义建模
• 非 DeepLearning 架构
• CPU 即可运行
• 100% 稳定、确定性输出
• 无需大模型参与，无任何 Token 消耗

其核心任务是接受一句自然语言，将标准意图转换为结构化 LogicForm：

{ "preds": [ { "name": "总销售金额", "pred": "销售金额", "operator": "$sum" } ], "query": { "日期": { "$offset": { "year": -1 } } }, "schema": "fact_sales" }

该阶段完成三件关键工作：

• 指标映射（销售额 → 销售金额）
• 时间语义解析（去年 → year -1）
• 数据域识别（schema 定位）

同时，LogicForm 的语义表达能力非常强，并不仅限于简单的单表查询。它还可以表达企业黑话、多表、嵌套查询、临时定义维度、跨数据源（多数据库+API调用）等复杂分析语义。

3.1

场景一：嵌套查询

例如，在“嵌套查询”场景中，可以先筛选出“销售额同比大于 0 的产品”，再在外层继续做计数统计：

{ "schema": "sales", "preds": [ { "name": "产品数量", "operator": "$count" } ], "from": { "schema": "sales", "groupby": "产品", "preds": [ { "name": "销售额同比", "pred": "销售额", "operator": "$yoy" } ], "query": { "日期": { "year": 2023 } }, "having": { "销售额同比": { "$gt": 0 } } } }

3.2

场景二：临时定义维度

又例如，在“临时定义维度”场景中，LogicForm 可以在查询时动态生成“金额段”这样的分析维度，而不要求这些维度必须预先固化在底层表结构中。这意味着 Alisa 输出的不是简单字段映射结果，而是一种具备强表达能力、可直接执行、可跨数据源迁移的统一语义结构。

{ "schema": "sales", "preds": [ { "pred": "销售金额", "operator": "$sum", "name": "总销售金额" } ], "groupby": [ { "_id": "用户_年龄", "name": "用户年龄段", "cases": [ { "name": "18岁以下", "query": { "$lt": 18 } }, { "name": "18-35岁", "query": { "$gte": 18, "$lt": 35 } }, { "name": "35岁以上", "query": { "$gte": 35 } } ], "default": "其他" } ] }

Step 4：SemanticDB 语义 SQL 生成

LogicForm 进入 SemanticDB 模块进行 SQL 生成。该模块核心能力为：

• 语义结构 → SQL 映射
• 指标口径一致性控制
• schema 级数据模型约束

输出 SQL 示例：

SELECT SUM(s.amount) AS 总销售金额 FROM fact_sales s WHERE s.date >= '2025-01-01 00:00:00' AND s.date <= '2025-12-31 23:59:59'

Step 5：数据库执行与结果返回

SQL 在数据库执行：

• 执行查询

• 进行聚合计算

• 返回结构化结果

最终输出业务指标结果：

去年总销售金额 = XXX

03 主链路设计核心价值

主链路体现的是系统的工程化能力：

• 确定性：相同输入必然得到一致 SQL 结果
• 可解释性：每一步语义都可追踪

1. 指标来源
2. 时间转换逻辑
3. schema 映射关系

• 结构收敛能力：将自然语言逐层压缩为可执行SQL

04 增强机制：语义不确定性处理流程

真实业务中，大量问题无法在主链路中一次性解析，因此系统设计了增强机制，用于处理语义边界问题。

场景一：语义歧义处理（向量召回 + LLM 澄清）

当 Alisa 遇到这些情况：

• 指标定义不明确
• 存在多种可能映射
• 企业自定义术语

系统进入增强流程：

Step 1：向量数据库召回

从语义向量库中检索：

• 相似指标

• 历史定义

• 企业标准口径

Step 2：候选语义返回

将多个可能解释返回给大模型。

Step 3：LLM 进行澄清

大模型负责：

• 解释不同候选含义
• 向用户发起确认
• 或基于上下文做推荐判断

例如：

“你指的是近30天活跃用户，还是登录用户？”

本质价值是用“语义召回 + LLM 交互”替代直接失败。

场景二：无法解析问题（语义失败回退）

当 Alisa 无法识别输入语义时：

• 无 schema 匹配
• 无指标路径
• 无结构化可能性

进入失败回退机制：

Step 1：回传大模型

Alisa 返回“无法解析”状态。

Step 2：大模型二次处理

大模型执行：

• 改写问题
• 拆解意图
• 引导用户补充信息

例如，用户输入：

“上周那个情况怎么样”

系统反馈：

• “你想看销售额、订单数还是客户数？”

• 或建议：

  • “上周销售额”

  • “上周订单趋势”

本质价值就是用大模型能力补齐结构化系统的语义边界。

05 整体系统架构总结

亿问 Data Agent 本质上是一个“双层语义系统”：

• 确定性执行层（主链路）

1. LLM：语义标准化
2. Alisa：结构化语义解析
3. SemanticDB：SQL 生成

👉 目标：稳定、可控、可解释

• 不确定性增强层（异常链路）

1. 向量数据库：语义召回
2. LLM：语义澄清与重写
3. 用户交互：信息补全

👉 目标：提升真实业务覆盖率

06 系统核心设计哲学

整个系统的本质设计思想是：不让大模型承担查数方面的语义理解，仅让大模型处理语言的泛化理解以及和出问题后的用户交互。

FAQ

大模型直接生成 SQL 为什么在企业环境里不稳定？

主要原因是约束不足。企业查询涉及指标口径、时间规则、schema、权限和上下文继承，大模型一次性生成 SQL 时容易把这些责任混在一起，导致同义问题落到不同查询路径。

中间表示一定要叫 LogicForm 吗？

不一定。LogicForm、DSL、MQL 或其他结构化语义表示都可以。关键不在名称，而在它是否能稳定表达业务意图，并在 SQL/API 生成前提供可检查、可治理的语义层。

语义标准化和语义解析有什么区别？

语义标准化主要处理语言表达，把口语、省略、指代和上下文整理成标准意图。语义解析则进一步把标准意图映射成结构化业务语义，处理指标、时间、数据域和复杂分析关系。

语义歧义应该让系统自动判断还是让用户确认？

取决于风险。如果候选定义之间差异很小，可以基于上下文推荐；如果会影响经营口径或决策结果，应优先让用户确认。生产系统更关注可复核，而不是盲目追求一次回答完成。

这种架构的主要代价是什么？

主要代价是前期语义建模和工程治理成本更高。它不一定适合一次性临时分析，但更适合长期复用、多部门协作、权限可控和结果需要复核的企业场景。