本期我们将详细介绍亿问 Data Agent 可信问数部分的相关核心算法流程其核心目标是将自然语言查询稳定、可控地转化为结构化 SQL并在复杂真实业务环境中同时兼顾“确定性执行能力”和“语义不确定性处理能力”。整体系统并不是单一的 NL2SQL 模型而是由主链路确定性算法流程 异常语义增强机制共同构成的双层架构体系。01 整体架构设计思想亿问 Data Agent 的核心设计原则可以概括为一句话用确定性链路保证结果可信用增强机制覆盖真实世界的不确定性。因此系统被划分为两层第一层主链路确定性语义分析链路用于稳定生成 SQL保证输出一致性与可解释性第二层增强链路语义不确定性处理机制用于处理歧义表达、模糊意图和无法解析的复杂问题02 主链路核心算法流程确定性路径主链路是整个系统的核心执行路径保证从自然语言到 SQL 的稳定转换。Step 1用户输入自然语言用户输入业务查询例如“我要看下销售额去年的”该阶段特点非结构化表达强口语化信息缺失明显指标、时间、口径因此需要进入语义标准化阶段。Step 2大模型语义标准化意图净化层 上下文继承在这一阶段系统的目标是将用户的自然语言问题转换为结构化的业务语义表达并补全缺失信息。2.1基础标准语义例如输入“我要看下销售额去年的”标准化后指标销售额可能映射为 GMV / revenue时间去年需进一步解析为具体时间区间动作查询query输出查询指标 销售额时间范围 2025 年或系统定义的去年区间2.2上下文继承机制多轮语义保持在真实分析场景中用户的提问往往是连续的而不是孤立的。例如第 1 轮问题销售额前三的 SKU 是哪些系统输出SKU1SKU2SKU3第 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 3Alisa 语义理解引擎核心结构化层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 4SemanticDB 语义 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:59Step 5数据库执行与结果返回SQL 在数据库执行执行查询进行聚合计算返回结构化结果最终输出业务指标结果去年总销售金额 XXX03 主链路设计核心价值主链路体现的是系统的工程化能力确定性相同输入必然得到一致 SQL 结果可解释性每一步语义都可追踪指标来源时间转换逻辑schema 映射关系结构收敛能力将自然语言逐层压缩为可执行SQL04 增强机制语义不确定性处理流程真实业务中大量问题无法在主链路中一次性解析因此系统设计了增强机制用于处理语义边界问题。场景一语义歧义处理向量召回 LLM 澄清当 Alisa 遇到这些情况指标定义不明确存在多种可能映射企业自定义术语系统进入增强流程Step 1向量数据库召回从语义向量库中检索相似指标历史定义企业标准口径Step 2候选语义返回将多个可能解释返回给大模型。Step 3LLM 进行澄清大模型负责解释不同候选含义向用户发起确认或基于上下文做推荐判断例如“你指的是近30天活跃用户还是登录用户”本质价值是用“语义召回 LLM 交互”替代直接失败。场景二无法解析问题语义失败回退当 Alisa 无法识别输入语义时无 schema 匹配无指标路径无结构化可能性进入失败回退机制Step 1回传大模型Alisa 返回“无法解析”状态。Step 2大模型二次处理大模型执行改写问题拆解意图引导用户补充信息例如用户输入“上周那个情况怎么样”系统反馈“你想看销售额、订单数还是客户数”或建议“上周销售额”“上周订单趋势”本质价值就是用大模型能力补齐结构化系统的语义边界。05 整体系统架构总结亿问 Data Agent 本质上是一个“双层语义系统”确定性执行层主链路LLM语义标准化Alisa结构化语义解析SemanticDBSQL 生成 目标稳定、可控、可解释不确定性增强层异常链路向量数据库语义召回LLM语义澄清与重写用户交互信息补全 目标提升真实业务覆盖率06 系统核心设计哲学整个系统的本质设计思想是不让大模型承担查数方面的语义理解仅让大模型处理语言的泛化理解以及和出问题后的用户交互。FAQ大模型直接生成 SQL 为什么在企业环境里不稳定主要原因是约束不足。企业查询涉及指标口径、时间规则、schema、权限和上下文继承大模型一次性生成 SQL 时容易把这些责任混在一起导致同义问题落到不同查询路径。中间表示一定要叫 LogicForm 吗不一定。LogicForm、DSL、MQL 或其他结构化语义表示都可以。关键不在名称而在它是否能稳定表达业务意图并在 SQL/API 生成前提供可检查、可治理的语义层。语义标准化和语义解析有什么区别语义标准化主要处理语言表达把口语、省略、指代和上下文整理成标准意图。语义解析则进一步把标准意图映射成结构化业务语义处理指标、时间、数据域和复杂分析关系。语义歧义应该让系统自动判断还是让用户确认取决于风险。如果候选定义之间差异很小可以基于上下文推荐如果会影响经营口径或决策结果应优先让用户确认。生产系统更关注可复核而不是盲目追求一次回答完成。这种架构的主要代价是什么主要代价是前期语义建模和工程治理成本更高。它不一定适合一次性临时分析但更适合长期复用、多部门协作、权限可控和结果需要复核的企业场景。