最近参加了一些行业交流会，围绕 Data Agent 落地，和业内专家、客户做了不少交流。一个感受是，大家对问数这个任务的判断，分歧还挺大。有些人认为问数（ChatBI）已经被解决了，有些人认为问数无法被解决，还有些人认为问数是一个伪命题，根本没有需求。今天，我们想从自己的经验和视角出发，聊聊这个事情。
01 在谈更复杂的任务之前，先把问数做好
在我看来，现在行业里有一个倾向：还没有学会走路，已经在考虑跑步的事情了。关于 Data Agent 类产品，核心任务主要包含：问数、归因、报告/报表/看板制作、预警推送、预测等任务，权限控制贯穿其中。
归因、报告、预警、预测等上层任务，都建立在可靠的数据获取之上。准确性会沿着依赖关系逐层传导，只要其中每一环都存在一定误差，链路越长，最终结果偏离真实业务的风险就越高。
另外，有些人会觉得问数是一个伪命题，直接看 BI 不就行了吗？其实不是。到了今天，问数已经不只服务于“人类”。在我们看来，未来最大的增量场景，是被各类 AI Agent 调用。当一个系统成为另一个系统的底层依赖时，调用频次和任务链长度都会放大准确率、延迟和成本的影响。
目前行业里关于 Data Agent 的讨论，更多集中在“如何用本体解决业务问题、推动业务动作”。而作为这些任务基础的问数，却常常被一笔带过，或者只用一个“95%以上的准确率”来概括。
问题在于，有些准确率并没有同时交代完整的评价指标和测试条件。实验室里能通过的测试，放到复杂生产环境中，是否依然成立？以我们目前接触到的方案来看，复杂生产环境中的问数问题，还远没有被普遍解决。
我们从 2019 年开始做 ChatBI，一路走到今天的 Data Agent，累计参与了上百个项目，其中正式落地项目几十个，截至目前项目验收率接近 100%。在问数、归因、看板制作及预警推送等全场景实践中，沉淀了大量的一线认知。今天，我们聚焦‘问数’这个核心场景展开拆解。
02 问数任务需要评估的性能参数
对于问数任务，我们认为，一个合格的生产级产品，应该评估以下几个性能参数：
1. 执行准确率：生成的 SQL 与标准 SQL 在数据库上执行后，返回的结果集是否一致。
2. 延迟：单条查询的推理耗时，通常以秒或毫秒计。
3. Token消耗：Prompt 与 Completion 的 Token 数量，直接关联 API 成本。
4. 稳定性：这和准确率有所不同，指的是同一个问题重复执行若干次，结果是否一致。
5. 是否白盒：当一个SQL出问题后，是否能知道原因，是否能修复，修复后是否能稳定不再发生bug，修复后是否不会造成之前成功的问题的执行准确率下降。
同时，还要看对接的数据表数量，因为表数量会显著影响这些参数的实际表现。
以下是亿问 Data Agent 在这些参数上的表现。
人类直接提问模式
以下是在500张表情况下的实测表现（架构在理论上不限制表数量）
1. 执行准确率：理论可达到98%以上，甚至100%（和客户数据现状、FDE水平、项目工期有关）。
2. 延迟：一般使用 flash 模型，单条查询的推理耗时在2秒内，不随着表数量增加而增加。
3. Token消耗：和表数量无关，稳定在1万 Token 内，不随表数量上升而上升。
4. 稳定性：单条查询100%稳定，不随着表数量上升而下降。
5. 是否白盒：是。若 SQL 出了问题，可以定位原因并修复；修复后，同样的问题不再发生，也不会影响其他问题。
AI 调用极速模式
前面这组参数，对应的是“人类”直接提问的情况，需要一个前置大模型对语言进行标准化。对于 AI 调用，我们还提供了极速模式。
同样在500张表的情况下，极速模式的实测表现如下
1. 执行准确率：接近100%（和客户数据现状、FDE水平、项目工期有关）。
2. 延迟：300~600毫秒。
3. Token消耗：0。无需大模型、无需GPU、仅CPU执行。
4. 稳定性：单条查询100%稳定，不随着表数量的上升而下降。
5. 是否白盒：是。如果SQL出问题，可以知道原因、修复、并且稳定不再发生，且不会影响其他问题。
03 亿问 Data Agent 算法架构
问数属于 NL2SQL 的一个子集，只涉及查询，不会修改表结构或者更新数据。我们的解决方案，说得精确一点，是"NL2NL2LF2SQL"。大家可以看到，这里出现了两次 NL。这不是写错，而是我们架构的精髓所在。核心流程分为三部分。
NL2NL：把泛化的查数需求转化为精准的查数需求
这部分由大模型完成。比如，用户输入：【你好呀，给我看下近四年的整体营业收入是多少呀，我说的近四年是22年-25年哦，不到26年】。
输出可能是【2022年～2025年整体营业收入】，也可能是【2022年～2025年营业收入】。具体措辞不会100%不变，但整体比较稳定。
这一部分的提示词不需要包含任何业务信息，只约束如何把需求转化为精准的查数表达。加上制作看板和报告的 Skill 提示词、Agent 基础提示词，也只需3万 Token，并且不会随着业务信息增多而增加，所以行为非常稳定。
NL2LF：把精准查数需求转化为 Logicform
LF 全称 Logicform，是我们针对查数场景自定义的一种 DSL 语言。它以JSON 为表达载体，方便二次处理和加工，因此可以植入特殊业务逻辑、权限、自定义算法等等。
这一部分由我们纯自研的算法 Alisa 完成，是整套架构的两个核心之一。Alisa 仅需要 CPU 推理，不限制表数量，平均能在500ms内给出结果。同样的输入，问一万次，结果一定一模一样。
另外，Alisa 并不是简单的“维度+指标”映射 NLP 算法。比如：【2025年销售额前三的门店，在2026年的销售额、销售额同比分别是多少？】这样精确但相对复杂的问题，它可以直接支持。
LF2SQL：把 Logicform 转化为 SQL
另一个核心，是我们自研的数据库语义层 SemanticDB。它通过“Schema+指标”来表达企业业务。我们定义了 Logicform 的语法，并开发了执行器，将 Logicform 转化为客户侧的 SQL 语句。
Logicform 封装了具体的业务算法，能够支持财年、缓慢变化维等多种特殊场景。这部分也没有大模型参与。
关于 Alisa，我们之前专门写过一篇文章亿问 Data Agent 与其他 Data Agent 到底有什么区别？这里简单展开一下。
它是基于知识图谱语义建模的自研算法，并不采用 DeepLearning 架构。处理一个问题时，需要先把用户说的业务词，映射到企业实际定义的指标、对象和关系上，再处理时间和查询条件。这里用到的业务知识，需要事先在语义模型中定义清楚。
但真实的业务问题，并不总能直接解析。比如，用户只说【上周那个情况怎么样】，连要查什么都没有说清楚。或者，一个业务词可能对应几个不同的指标。这个时候，系统就需要先把问题搞清楚。
我们的处理方式是：如果有多个可能的业务含义，就通过语义召回找到相关候选，再交给大模型和用户进行澄清。如果无法解析，Alisa 会返回这个状态，由大模型改写问题、拆解需求，或者让用户补充信息，然后再查。
所以，在我们的系统里面，无法解析也是一个明确的结果，可以继续处理。我们认为，这比需求还没有搞清楚，就先生成一个 SQL 执行，要好得多。
04 未来的问数，可能更多地是给 AI 用
未来，企业内部会出现越来越多的 Agent，其中相当一部分都需要持续查询企业数据。随着调用主体从“人类”扩展到“AI”，权限如何控制、身份如何传递、业务定义如何复用，都会成为必须解决的问题。
我们产品的每一层，都可以单独对外开放。比如 SemanticDB 层、Alisa 层、AI 员工层、权限层等等。不同企业可以根据自身已有的技术能力，选择从不同层级接入。
先说权限。
一个 Agent 代表谁在查询，应该继承谁的权限；如果任务被继续转交给其他 Agent，权限是否能够正确传递，这些都需要有明确的定义。
比如，门店负责人让一个 Agent 分析自己门店的经营情况，这个 Agent 就只能在相应的授权范围内查询数据。即使任务被进一步转交给其他 Agent，也不能因此扩大数据访问范围。
所以，权限必须在实际查询链路中生效。仅仅在提示词里告诉大模型“哪些数据不能查”，我们认为是不够的。
在接入方式上，也可以根据调用方自身的能力来选择：
- 如果调用方已经能够生成符合语法要求的 Logicform，可以直接接入 SemanticDB；
- 如果提供的是精准的查数需求，可以接入 Alisa；
- 如果需要完整的自然语言交互和数据任务能力，可以使用 AI 员工层。
无论采用哪种接入方式，调用身份和对应权限都需要贯穿整个查询过程。
还有一个很重要的问题，是业务定义的复用。
未来企业里可能同时存在销售 Agent、财务 Agent、经营分析 Agent，它们承担的任务可以不同，但如果查询的是同一个口径的营业收入，就应该使用同一套业务定义，而不是由每个 Agent 各自理解一遍。
否则，每个 Agent 都维护一套业务知识，一旦指标定义发生变化，就需要逐个同步，最终很容易造成不同 Agent 之间的口径不一致。
我们的想法是，把业务定义和查询能力统一维护，让不同的 Agent 按自己的任务需要来调用。
上层 Agent 可以持续增加和变化，底层已经沉淀好的指标口径、对象关系和查询规则则可以稳定复用。这样，企业前面做过的语义建模工作，才不会只服务于某一个 Agent，而能够真正成为整个 AI 应用体系共同使用的基础能力。
05 写在最后：先把基础能力做扎实
回到开头的分歧，问数不能简单地说“已经被解决”，也不能说“无法解决”，更不是一个“伪命题”。它本质上是一项必须长期做扎实的基础能力。
归因、报告、预警、预测等上层任务，都建立在可靠的数据获取之上。未来，当越来越多 Agent 开始持续调用企业数据，底层一次查询中的误差、延迟和不稳定，也可能沿着后续任务链被持续放大。
所以，在讨论更复杂的 Data Agent 能力之前，更重要的是先把问数这项基础能力做扎实。