经常有人问我，你们的产品和其他 Data Agent 产品有什么不一样呢？ 今天，我就用最简单、最直白、最不绕弯子的一句话，来告诉大家核心差异：
我们的自然语言转 SQL 这一个步骤，不需要大模型的参与。
是的，你没看错。
比如你问这么一句话：【帮我找出近三个月销售额同比涨幅超过 20% 的门店，帮我按照销售额从大到小排序】
把这句话翻译成 SQL，再执行 SQL 得到正确答案，这个核心流程里：
✖️ 不需要大模型
✖️ 不需要GPU
✖️ 不需要网络
✖️ 不消耗任何token
✓ 100%稳定，也就是说同样的一句话问100次，结果分毫不差
✓ 速度快，平均在600毫秒左右
Q1：你们是如何做到的？
我们从 2019 年起，就开始研发一套基于本体和知识图谱的 100% 自研的图算法，用它来完成语义理解。
Q2：OK，那又怎么样呢？大模型也能做语义理解，你能比大模型做得更好吗？
在数据分析场景有一个特殊的情况，就是稳定性这件事只有 0% 和 100% 两种可能。 同一个问题，你问100次，结果一定要 100% 一致。 即使你达到95%了，在生产场景中也还是不可用。 因为如果使用者每一次拿到结果都要去核验，那这个产品就失去了使用意义。
而大模型作为一个概率模型，尤其是作为一个以预测下一个 token 的概率模型，它的输出天然存在不确定性。大模型获得了创造性和处理模糊语义的能力，也引入了结果的不确定性。我把这种取舍称为一把双刃剑。这是底层架构决定的。
在数据分析场景，天然就和此底层架构有根本性的矛盾。目前市场上不少 NL2SQL 方案遇到的落地和稳定性问题，也印证了我们的判断。
我们的算法走的是经典软件算法路线，可以在 CPU 上运行。在数据、业务规则、权限、配置和版本一致的条件下，相同的输入可以得到相同的结果，这种确定性从根本上就很契合数据分析场景。这套路线也已经在复杂项目中经过了验证。截至目前，我们单个项目最多对接过 400+ 张表，运行良好。
所以这并不是我们“算法好”还是“大模型好”的问题，而是应用场景是否适配的问题。
Q3：那你们这个算法没有缺点吗？
有的朋友，有的。
我们的这个算法，内部开发名称叫做 Alisa。她的“性格”非常像美剧《生活大爆炸》里面的 Sheldon。也就是说，提问者必须把问题说得非常标准、非常有逻辑，措辞也必须非常严谨，她才能理解。
还是以这句标准的查询语句为例：【帮我找出近三个月销售额同比涨幅超过 20% 的门店，帮我按照销售额从大到小排序】
如果这次提问者问的是：
【找出近三个月同比涨幅超过 20% 的门店】，省略了“销售额”这三个字，那么 Alisa 就歇菜了。因为系统里面有那么多指标，她不知道你要问的是哪个指标。这种情况在现实中比比皆是。
那怎么办呢？所以我们还是引入了大模型。
我们开发了一个叫 Nora 的 AI Agent。 她站在用户和 Alisa 之间，先接收用户的提问，措辞调整，再向 Alisa 问出那个正确的问题。
依旧是这个例子：
→ 用户提问：【帮我找出近三个月同比涨幅超过 20% 的门店，帮我按照销售额从大到小排序】
→ Nora：将问题改写为【帮我找出近三个月销售额同比涨幅超过 20% 的门店，帮我按照销售额从大到小排序】，再传给Alisa
→ Alisa：给出结果
在这个解决方案中，Nora 的系统提示词只需要告诉她一件事：如何向 Alisa 提问即可。在这一环节，系统提示词不需要直接承载表结构、业务知识和指标口径。这样可以大幅缩短系统提示词，并带来三个直接改善：
- 措辞调整的稳定性大幅提升：大模型的稳定性会随着提示词量的上升而指数级下降；
- 回答速度快：整体查数流程一般在5秒以内完成；
- token 消耗量不随数据集数量而变化：无论是 100 张表、200张表、还是500张表，token 消耗量始终稳定，大幅节省客户预算。
而即使 Nora 这边由于大模型的不稳定性，导致措辞调整每次都有略微不同，Alisa 也能「稳稳接住」。 下面几种问法虽然不同，但表达的是同一个查询语义，因此 Alisa 给出的答案始终会是一致的，并且也是可信的。
- 近三个月销售额同比涨幅超过 20% 的门店；
- 近三个月销售金额同比涨幅超过 20% 的门店；
- 近三个月各个门店的销售金额同比，给我筛选出销售金额同比超过 20% 的。
而回答速度快 + token消耗量小 + 100% 稳定这个组合，也让亿问 Data Agent 具备了作为底层 AI 供数平台，通过 MCP 服务器向外部系统、其他 AI 系统供数的能力。 其他 AI 系统本身也存在不确定性。如果同一条链路上的多个系统都在引入不确定性，风险就会层层叠加，甚至让整条链路不可用。
Q4：那未来大模型会发展的，迟早会碾压你们
我是这么看这个问题的：大模型的技术架构决定了他们一定是一个高概率事件占主导地位的算法，即它更擅长从海量样本中学习通用模式，而企业内部的知识和指标口径，绝大多数情况下，是个性化、定制化的小概率事件，也就是说是每家公司独有的，这正是我们的算法（Alisa） 擅长处理的问题。
所以未来更可能出现的情况是，大模型负责理解和交互，我们的算法则作为一种可以被长期调用的工具，在涉及企业内部知识和指标口径时，提供确定性的查询能力。
最后的话
回到最初的问题，我们与其他 Data Agent 的核心差异就是：我们的自然语言转 SQL 这一个步骤，不需要大模型的参与。
之所以坚定这条路线，是因为我们认为数据可信是底线。用户的表达可以模糊，但企业的指标口径必须确定；大模型的理解可以有差异，但进入经营决策的数据必须一致、可复核。
在离实际数据结果最关键的这一步，我们选择在前期投入大量精力做扎实的语义建模、严格的规则定义和充分的验证。我们不愿意把企业的指标口径交给“一次概率生成”。
这是我们对技术的判断，也是我们对可信的坚持。