亿问 Data Agent 是一款面向企业经营分析场景的私有化数据分析 Agent，通过自研的NL2LF2SQL引擎杜绝幻觉，帮助业务分析师高效生产可信分析报告。

上一期，我们介绍了 SemanticDB 在整条链路里的角色，回答了以下问题：

• 为什么企业级数据问答不能直接做端到端 NL2SQL？
• 为什么中间一定需要 LogicForm 这样的语义表达？
• 为什么要由 SemanticDB 去把 LogicForm 稳定翻译成 SQL、API 或 URL？

本期，我们再往前追一层，讨论一个更关键的问题：

如果目标不是做一个能跑通 demo 的问答系统，而是做一个真正能完成 Data Agent 任务的 Production 级产品，那么 NL2SQL 到底应该优化什么？

如果说上一篇已经论证清楚，企业级数据问答应该采用 NL2LogicForm2SQL 这样的链路，那么本期真正要讨论的，就是其中最关键、也最困难的一段：NL2LogicForm 本身应该怎么做。

换句话说，这篇要回答的不是"要不要 NL2LogicForm"，而是"什么样的 NL2LogicForm 方案，才是 Production 级的最佳方案"。

---

先定目标，再谈方案

很多团队一上来会先盯准确率、榜单分数，或者某个固定场景下的成功率。

但这些指标都不够，因为 Data Agent 解决的从来不是一道孤立题，而是一种持续分析能力。用户要的是像分析师一样连续追问、稳定得到正确数字，并且在复杂业务语义里长期可用。

如果核心指标订错了，后面的架构、训练、检索、推理和治理，方向都会跟着偏掉。

所以在讲"怎么做到"之前，第一件事不是谈方案，而是先把目标定义清楚。我们最终把核心指标订成了四个条件同时成立：

「5秒内 + "无限上下文" + 100%稳定 + 复杂语义」

这四个条件不是四个可选优点，而是同一个目标的四个约束。少任何一个，都不能算真正完成了 Data Agent 任务。

---

为什么这四个指标缺一不可

企业级 Data Agent 的难点，从来不在某一个单点上，而在于多个约束要同时成立。

• 只追求快，通常会牺牲语义复杂度。
• 只追求复杂语义，通常会牺牲稳定性。
• 只追求稳定，往往只能在很小的固定空间里成立。
• 只追求大上下文，又很容易把问题退化成"把更多东西塞进 prompt 里让模型猜"。

真正的难点不是把其中一个指标做高，而是四个指标必须一起成立。

5秒内

"5秒内"不是一个随意拍脑袋的体验指标，而是分析师思路能否保持连贯的时间窗口。 数据分析不是一次性提问，而是一条连续的思考链路。

用户会先问"今年怎么样？" → 接着追问"那上个月呢"、"原因是什么"、"按区域拆一下"、"前十门店是谁"。

如果系统响应过慢，用户的思路就会断掉，分析过程会从"连续推理"退化成"等待任务返回结果"。一旦退化成这种模式，产品形态就不再像 Agent，而更像一个慢速报表工具。

"5秒内"不是锦上添花，而是 Data Agent 能不能成立的前提。

"无限上下文"

这里说的"无限上下文"，不是指模型 token window 字面意义上的无限，而是指在同一个业务空间内，表、字段、指标、维度、实体、别名、口径、项目术语的规模可以持续增长，而系统仍然能够稳定工作。

真正的企业环境不是"一个场景配一套 prompt，一个部门配一个空间"，而是同一个数据空间会不断膨胀：今天多一个指标，明天多一张表，后天又多一套新的业务口径。

真正 Production 级的产品，必须满足一个要求：同一空间里的语义规模可以近似无限扩展，而系统仍然能在每次提问时只取到和当前问题最相关的那一小部分上下文，再完成稳定推理。

如果每增加一些表和指标，系统就必须重新划空间、重新写规则、重新做人工路由，那它本质上还是 demo 方案，不是生产方案。

100%稳定

在企业级数据分析场景里，数字必须持续保持正确。 这里的"正确率"没有一个舒服的中间地带，只有两个选项：0% 和 100%。

一个系统如果只是"绝大多数时候是对的"，那用户在每一次使用时都必须自己判断这次能不能信。一旦用户还要自己兜底，它就不是一个可以依赖的 Data Agent。

数据分析领域最危险的错误，不是报错，而是给出一个看起来很合理、但其实错了的数字。 这种错误会直接摧毁信任，而且几乎不会被容忍。

所以这里说的 100%稳定，并不是指模型天然没有不确定性，而是指整个系统架构必须把不确定性隔离在可治理的范围之外：同样的问题、同样的业务语义、同样的上下文条件下，系统必须稳定地产生同样的正确语义结构，并最终得到同样的正确结果。

复杂语义

这是最容易被低估、但实际上决定上限的指标。

LogicForm 的表达能力可以非常强。它不仅要表达一个简单的"查某个指标"，还要表达多条件过滤、时间比较、同比环比、分组排序、TopN、交并关系、口径约束、多轮追问继承，以及各种企业内部特有的业务概念。

但问题在于，大模型并没有在预训练阶段学过你的 LogicForm。它既不天然知道你的语法，也不天然知道你的业务语义边界，更不天然知道企业里的那些黑话、别名和口径定义。

我们要解决的，不是"模型能不能偶尔写出一个像样的 LogicForm"，而是"在复杂语义持续增长的前提下，系统凭什么还能长期、稳定、可治理地产生正确的 LogicForm"。

5秒内 + "无限上下文" + 100%稳定 + 复杂语义，本质上不是四个并列卖点，而是我们为 Data Agent 设定的一组同时成立的生产级约束。 后面所有方案，都是围绕这组约束展开的。

---

为什么 NL2DSL 不能靠端到端大模型同时满足这四个指标

市面上已经有很多 NL2DSL 方案。LogicForm 本质上也是一种 DSL。无论是 NL2MQL，还是其他把自然语言直接翻译成某种查询语义表达的方案，核心思路都很相似：让大模型直接生成最终 DSL。

在 demo 阶段，这条路常常有效。

但如果目标不是做 demo，而是同时满足上面四个约束，端到端 NL2DSL 会遇到结构性问题。

为了"无限上下文"，它必须先把无限空间压进一次 prompt

端到端 NL2DSL 的前提，是模型在生成 DSL 的那一刻，已经拿到了足够完整的业务语义上下文。但真实企业环境里，同一个空间内的表、字段、指标、维度、实体、别名、口径、项目术语会持续增长，不可能每次都完整塞进 prompt。

所以系统只能做一件事：先检索，再把"看起来最相关"的那一部分上下文送给模型。只要是检索，就一定存在召回边界；只要存在召回边界，就不可能天然保证 100%稳定。

端到端方案表面上在解决"无限上下文"，本质上是在把大空间问题压缩成一次 prompt 内的召回博弈。

为了"复杂语义"，它必须让模型一次性完成太多事

一条复杂 DSL 不是单纯的语法生成，而是很多子任务叠加在一起的结果：补全上下文、解析省略和指代、识别业务对象和指标、命中实体值/别名和黑话、消解歧义、继承多轮条件、组合过滤/分组/排序/比较关系、最后再拼成合法 DSL。

端到端 NL2DSL 把这些工作全部压进了一次生成里。任何一个环节轻微漂移，最终 DSL 都可能整体错误。而且最危险的地方在于，这种错误经常不是语法错误，而是语义错误——DSL 看起来是合法的，结果也能执行，但表达的并不是用户真正想问的意思。

可一旦上下文持续变多，端到端生成的稳定性就不会只是线性下降，而会指数级下降。

为了"100% 稳定"，它必须缩小生成自由度；但一缩小，就会牺牲复杂语义和开放空间

哪怕温度设成 0，只要 prompt 略有变化、检索结果顺序略有变化、业务上下文略有缺失，最终生成都可能不同。

如果为了追求稳定性，开始大量增加模板、规则、例子和强约束，让模型只在很窄的空间里生成，系统确实会更稳，但覆盖能力会迅速下降。

端到端大模型很难同时做到：开放空间下的复杂语义稳定。大多数时候，它只能在稳定性和覆盖度之间二选一。

为了"5秒内"，它不能做太多补救；但不补救，稳定性又不够

很多团队在端到端 NL2DSL 路线上，会加入多次采样、候选重排、自我反思、语法修复、结果校验、多轮重试。但这些手段本质上都是事后补偿，并没有改变端到端生成本身的不稳定性。

你越想把稳定性补上，就越需要更多轮推理和校验；而这些额外步骤，又会直接侵蚀 5秒内这个指标。在端到端路线里，"5秒内"和"100%稳定"往往不是同时增强的，而是在互相拉扯。

根本原因：端到端生成是在"猜最终答案"，而不是"收敛到最终答案"

端到端 NL2DSL 的基本范式，是让模型在一次生成中直接写出最终 DSL。它的工作方式决定了，系统很难把"上下文处理、术语理解、实体匹配、歧义消解、语义组合"这些过程拆开治理。

当业务空间持续变大时，系统没有办法只针对某一个环节精准增强；当结果出错时，团队很难知道到底是哪个环节出了问题。

问题不在于"大模型能不能生成 DSL"，而在于"能不能把 NL2DSL 的全部责任都压给一次端到端生成"。

如果目标是 Production 级的 Data Agent，并且四个约束要同时成立，那么答案是否定的。NL2LogicForm 的最佳方案，必须不是"直接让模型写最终 DSL"，而是把这件事拆成一套可以收敛、可以约束、可以治理的系统。

---

Alisa：我们给出的 NL2LogicForm 最佳方案

Alisa 就是我们给出的答案。

Alisa 是亿问 100% 纯自研、具有完全自主知识产权的算法。它不是一个"让大模型把 LogicForm 写得更准一点"的 prompt 工程，也不是一个只能在固定场景里跑通的 demo 系统。它的目标从一开始就很明确：把 NL2LogicForm 做成一个真正 Production 级的能力层。

Alisa 不仅能回答简单的"维度 + 指标"组合问题，也能处理非常复杂的语义问题，包括嵌套查询、临时分组、跨实体关系链路推理、TopN 后再计算，以及条件组合筛选之后再聚合。

在我们的 testcase 里，有几类很典型的问题：

• "把价格划分成100以下，100～300，300以上三种区间，现在帮我计算各个价格区间在今年的销量分别是多少？"——这是典型的临时分组问题。
• "今年境外铜产量前十排名的企业的归母净利润是多少？"——这是先按一个指标做排名筛选，再回到另一套语义上做聚合的嵌套问题。
• "2025年6月30日总净值排名前10的组合类产品中，属于2024年成立的产品名称及成立月份有哪些？"——这是时间、排序、TopN、实体属性过滤共同叠加的复杂问题。
• "门店05所在品牌组的合并店中，产值为前80%的合并店的平均值。"——这是沿着实体关系链逐层推理之后，再做分位筛选和聚合的复杂问题。

先看性能，Alisa 的生成性能是毫秒级的，在 100 张表的情况下，生成速度可以做到 500ms。而这 500ms 的前提，并不是依赖大模型或 GPU 去硬堆算力，而是整个 Alisa 算法本身就完全不需要借助大模型，纯 CPU 即可完成。

再看稳定性。对于同样的输入内容、同样的业务语义、同样的上下文条件，问一万次，结果一定一样。这里不是"多数时候一样"，而是必须稳定一致。

再看语义覆盖。Alisa 能生成 LogicForm 所支持的全部语义，而不是只覆盖一小部分高频模板问题。它不是为了稳定性去牺牲表达能力，也不是为了表达能力去接受不稳定。

从原理上说，Alisa 不是把问题交给一次端到端文本生成去完成，而是基于业务知识图谱和图计算，对结果空间进行推理和收敛。 自然语言里的业务对象、指标、属性、实体、别名、口径和约束关系，不是以一堆松散文本的形式堆在 prompt 里，而是被组织在一个可计算、可推理的语义结构里。

系统面对一个问题时，不是直接"猜最终 LogicForm"，而是先在语义图里定位候选空间，再通过图上的关系约束逐步收敛到最终结果。

Alisa 处理的不是"文本生成空间"，而是"结果空间"。正因为它是在结果空间里做推理，而不是在开放文本空间里做猜测，所以它才能同时把性能、稳定性和复杂语义覆盖拉到 Production 级。

从结果上看，Alisa 解决的并不是一个局部优化问题，而是把前面看起来彼此冲突的几个约束同时拉到了一起：

• 性能是毫秒级，不只是 5秒内
• 稳定性是 100%，不是"平均准确率很高"
• 语义覆盖是完整的，不是只支持部分 DSL 能力
• 目标空间是可持续扩展的，不是靠切碎空间来维持效果

但这还不是问题的全部。Alisa 虽然能力很强，但它更擅长处理已经相对精准、相对规范的问题输入。对于一些非常泛化的表达、强缩略的业务黑话，以及上下文严重省略的问题，单靠 Alisa 本身并不适合直接处理。

---

完整方案：让大模型做标准化，让 Alisa 做确定性推理

我们最后采用的完整解决方案是这样一条链路：

自然语言 → 大模型完成问题标准化与上下文补全 → Alisa →（若存在未知词汇，则触发向量库搜索 / 大模型二次确认）→ LogicForm

这条链路的关键，不是简单把大模型和 Alisa 串起来，而是给它们做了非常明确的分工。

大模型负责的，不是直接生成最终 LogicForm，而是先把用户原始提问整理成一个更标准、更完整、更明确的问题表达。 它主要处理的是自然语言层面的问题，例如上下文补全、省略恢复、代词指代、口语表达整理和句式标准化。这些事情本质上是语言理解问题，而不是业务语义推理问题。

Alisa 负责的，则不是语言润色，而是在标准化之后的问题基础上，做确定性的语义推理、结果空间收敛，以及最终的 LogicForm 生成。

这就是整套方案成立的关键：大模型做自己擅长的语言标准化，Alisa 做自己擅长的确定性推理。两者不是互相替代，而是能力边界非常清楚地拼在一起。

为什么标准化阶段不需要业务知识

大模型在做问题标准化的时候，不需要任何业务知识。

它不需要知道企业里有多少张表、多少个指标、多少种口径、多少个实体值，也不需要知道某个缩略词最后到底对应哪个业务对象。它只需要做一件事：把一句原始的人话，整理成一个语义更完整、表达更规范、上下文更明确的问题。

例如用户说"华东女装今年怎么样"、"那上个月呢"、"前十呢"、"核心店看一下"，大模型在这一层要做的，不是去决定"核心店"到底映射成哪个业务定义，也不是直接生成 DSL，而是先把这些问题恢复成一个更完整、可以进入后续语义推理的标准化表达。

正因为这一层不需要加载业务知识，所以它的 prompt 和 token 可以被严格控制在一个非常小的范围内。

这会直接带来两个结果：速度更快，因为大模型处理的是一个很小、很稳定的语言标准化任务；稳定性更高，因为 prompt 更短、任务边界更清晰、变量更少，不会因为业务上下文膨胀而持续失稳。

我们并不是在用大模型去解决最难的业务推理问题，而是在用它做一个它最擅长、同时也最容易被约束的小任务。

为什么要单独处理未知词

真实用户提问里，总会不断出现系统还没显式吸收过的新词、缩写、别名、黑话和项目代号。如果这些词直接进入 Alisa，它们可能并不在当前已知语义空间里；但如果一开始就把所有未知词都交给端到端大模型去猜，系统又会重新回到不稳定状态。

所以我们的做法是，把未知词作为一个单独问题处理：当 Alisa 发现当前输入里存在未知词汇时，再引入向量库搜索或大模型二次确认，去帮助缩小候选空间、完成确认，然后再回到确定性链路中继续生成 LogicForm。

开放性的模糊处理被局部隔离在一个可控环节，而不是污染整个主链路。

整套方案的本质，不是"大模型 + 算法"的简单拼接，而是一次很严格的职责拆分：大模型负责把问题说清楚，Alisa 负责把语义做正确，未知词模块负责把开放问题局部补齐。最终得到的，才是一条既快、又稳、还能持续扩展的 NL2LogicForm 生产级链路。

---

总结

本期真正想说明的，不是 NL2LogicForm 能不能做，而是 Production 级的 NL2LogicForm 应该怎么做。

如果目标只是做一个 demo，那么端到端大模型直接生成 DSL，很多时候已经"看起来够用了"。

但如果目标是 Data Agent，并且要同时满足 5秒内 + "无限上下文" + 100%稳定 + 复杂语义，那就不能再把问题理解成一次开放文本生成，而必须把它拆成一条可以约束、可以收敛、可以治理的工程链路。

亿问的答案是：让大模型负责问题标准化和上下文整理，让 Alisa 负责确定性的语义推理和 LogicForm 生成，并在必要时通过向量库搜索或大模型二次确认处理未知词。

也正因为这样，整套系统才能同时做到三件原本看起来彼此冲突的事：

• 既利用大模型的语言理解能力，又避免端到端生成的不稳定；
• 既保持毫秒级性能和 100% 稳定，又不牺牲复杂语义覆盖；
• 既能在生产环境长期工作，又能随着业务空间扩展持续演进。

这就是我们对 NL2LogicForm 最佳方案的回答，也是 Alisa 这套系统存在的意义。

---

下期预告

本期我们展示了 Production 级的 NL2LogicForm 应该怎么做，核心是方案选型和架构设计。但方案选对了，不代表系统就能直接上线——还需要一套严格的评估体系来验证它在生产环境中到底表现如何。

下一期，我们将从方案设计转向实战评估，给出一份完整的 NL2SQL 性能评估手册。 我们会拆解多个最容易被忽视、但直接决定系统能否上线的核心维度：响应速度的真实瓶颈在哪里、稳定性应该怎么测才有意义、语义理解能力如何分级验证，以及时间智能、业务维度查询等专业场景下的隐藏陷阱。

如果说本期回答的是"怎么做"，下期要回答的就是"怎么验"，这也将是亿问 Data Agent 2.0 正式发布系列的完结篇。欢迎持续关注亿问的产品动态和技术演进。

---

FAQ

NL2LogicForm 和端到端 NL2SQL 到底有什么区别？

端到端 NL2SQL 让大模型在一次生成中直接写出最终 SQL 或 DSL，模型必须同时理解语义、匹配实体、组合逻辑。NL2LogicForm 则把这件事拆成多个可控环节：大模型只负责语言标准化，Alisa 负责确定性的语义推理和 LogicForm 生成，最后由 SemanticDB 翻译成 SQL。每个环节职责清晰，出错可定位、可治理。

Alisa 不依赖大模型，那它的原理是什么？

Alisa 是亿问 100% 纯自研的算法，基于业务知识图谱和图计算进行结果空间的推理和收敛。它把业务对象、指标、属性、别名、口径和约束关系组织在一个可计算的语义结构里，面对问题时在语义图里定位候选空间、通过关系约束逐步收敛到最终 LogicForm，纯 CPU 即可完成，100 张表场景下生成速度 500ms。

这套方案对已有数据基础设施有什么要求？

亿问 Data Agent 采用私有化部署，通过 SemanticDB 语义层屏蔽底层数据库差异。无论企业用的是 MySQL、ClickHouse、Oracle 还是多数据源混合，语义层都可以统一适配。核心要求是需要在 SemanticDB 中完成业务建模（实体、事件、指标、口径等），这个过程由亿问团队协助完成。