大模型做数据分析，最让人不敢用的不是它不够聪明，而是它偶尔会一本正经地胡说八道。这篇文章不讲换个更强的模型，讲一套从工程上把幻觉关进笼子的做法，并以Dora为例，看这套方法论怎么落地成产品。
问题：幻觉不是 bug，是架构的必然
先对齐一个认知：企业 AI 问数里的幻觉，绝大多数不是模型抽风，而是架构选型决定的。
Text2SQL 是最普遍、门槛最低的起步路线——让模型直接把自然语言翻译成一段 SQL，去查物理表，再把结果包一层自然语言吐给用户。它至今仍是很多团队的第一选择，但这条路的问题在于，它把三个最不该交给概率模型的事，全交给了概率模型：
- 理解：用户说"毛利率"，财务和销售的口径可能不一样，模型得自己猜是哪个。
- 生成：模型要自己推断表结构、字段、join 关系，然后写 SQL。表一复杂，它就会脑补出不存在的字段。
- 计算：结果由模型参与生成，你没法验证中间过程对不对。
只要这三个环节里有一个是模型在自由发挥，幻觉就一定会出现，只是概率高低的问题。所以真正要做的，不是祈祷模型不犯错，而是从架构上把这三个环节从模型自由发挥改成确定性执行。
Dora 走的正是这条路。它的技术路线是 NL2DSL → BI 语义层 → 确定性计算引擎，而不是裸的 Text2SQL。下面拆开讲每一步怎么改，以及 Dora 具体是怎么实现的。
第一层：语义层，把理解变成检索
Text2SQL 的第一个坑，是让模型去理解物理表。物理表是给机器看的，字段名可能是 gross_profit_rate，也可能是 maolilv_2024_v2，模型要在这堆东西里猜业务含义，猜错是常态。
解法是引入一层语义层（Semantic Layer）：在物理表之上，抽象出一层业务可理解的指标和维度。
物理表：fact_sales, dim_product, dim_region ... ↓ 语义层映射 业务指标：毛利率、净利率、销售额、同比增速 业务维度：地区、产品线、时间、渠道
有了这一层，模型面对的不再是哪张表哪个字段，而是毛利率这个已经被定义好的指标。用户问"毛利率"，模型要做的不是猜这个词是什么意思，而是在语义层里查到这个指标的定义和计算口径。
这一步的价值在于：术语对齐从模型的主观推断变成了对既定定义的检索。企业里那些毛利率到底怎么算的口径之争，在语义层被一次性固化，AI 和业务人员查的是同一套定义。
Dora 在这层的工程化落点，是直接复用帆软生态已有的数据资产。企业过去在 FineBI、FineReport 里建好的数据模型、指标体系、权限设置，Dora 可以零配置对接，不用为了上 AI 把整套语义层从零重建。这意味着语义层不是一句口号，而是企业已经具备、可以直接拿来用的现成地基。权限也顺势挂在指标和维度上，而不是挂在物理表上，天然更符合业务语义，也更容易审计。
第二层：NL2DSL，把生成变成翻译
Text2SQL 的第二个坑，是 SQL 本身太自由。SQL 是图灵完备的，模型可以写出无数种语法正确但逻辑错误的查询，你很难判断它对不对。
更稳的做法是 NL2DSL——让模型生成的不是 SQL，而是一种受限的领域特定语言（DSL）。这个 DSL 面向的是语义层里已经定义好的指标和维度，而不是物理表。
两者的区别，用一个类比说清楚：
- Text2SQL：让 AI 直接动手盖房子，它得自己判断地基怎么打、钢筋怎么配，每一步都可能出错。
- NL2DSL：给 AI 一套预制好的构件，它只需要选对构件、按规则拼装，出错空间被压缩到选构件这一步。
因为 DSL 是受限的，它就有了一个 SQL 不具备的性质：可静态校验。一段 SQL 生成出来，你很难判断它对不对；但一段 DSL 生成出来，你可以用规则去检查——引用的指标存不存在、维度合不合法、聚合方式对不对。这为下一层的校验链路提供了抓手。
Dora 明确选择了 NL2DSL 而非裸 NL2SQL，这是它和市面上多数 Text2SQL 产品最根本的技术分叉。翻译出 DSL 之后，真正的计算交给确定性计算引擎去执行——模型只负责翻译，不负责算数。算数这件事，交给不会幻觉的引擎。
第三层：三层校验，给每个答案上安检
语义层管住了理解，DSL 管住了生成，但还不够。结果出来之前，Dora 还设了三道校验：
1. 术语对齐校验。 把用户问题里的业务术语，对齐到语义层已定义的指标和维度。确保 AI 理解的"断线率"，就是切片生产里那个有明确口径的断线率，而不是别的什么率。
2. DSL 合法性校验。 对生成的 DSL 做语法和语义双重校验，拦截非法查询。引用不存在的指标、维度组合不合法、聚合方式错误，在这一层就被拦下，而不是跑到数据库里报错，或者更糟——返回一个看似正常实则错误的结果。
3. 结果合理性校验。 查询结果出来后，用业务规则和统计常识去检查。一个数字如果明显超出合理区间、或者不符合业务常识，就打上标记。比如断线率从 8% 突然跳到 80%，物理上几乎不可能，合理性校验就能识别这种异常。
三层校验是递进的：
术语对齐校验 → 管理解对不对DSL 合法性校验 → 管查询对不对 结果合理性校验 → 管答案对不对
每一层拦截一类特定的错误，合起来把幻觉的生存空间压缩到最小。这套三层可信校验是 Dora 保障准确性的核心机制，也是它区别于让模型直接吐答案的关键。
第四层：证据链，把敢信变成可查
防住了幻觉，还要解决信任问题——用户凭什么相信这个答案是对的？
Dora 的做法是可追溯的证据链。AI 问数的答案，不能是一个黑盒里吐出来的数字，而必须是一条可以顺着往回查的链路：
- 脚注：每条结果标注数据来源，这个数字是从哪张表、哪个指标算出来的。
- 可信卡片：展示完整的查询链路和计算过程，用户能看到 AI 是怎么一步步得到结果的。
- 指标口径：明确展示所用指标的定义和计算口径。
- 数据源溯源：每条数据能追溯到原始数据源，出了问题能找到根。
- 证据链：完整记录从问题到答案的推理过程，可审计、可复盘。
这套机制在真实场景里怎么用，看一个案例就够了。
晶科能源用 Dora 做切片断线率管理，Agent 为每一条原因建议都展示数据证据、知识条目引用、适用条件和置信度，并且要求班长或工艺工程师确认后才能派单，低置信度的自动转人工。结果是断线率平均下降 3.3%，年化经济效益约 1148 万元。
关键不在于数字多漂亮，而在于：AI 给出的不只是答案，而是一个敢让一线人员照着执行的依据。 这才是敢信、敢用的真正含义。
落地：为什么这套方案能真正跑起来
任何防幻觉方案，如果落地成本高到要企业推倒重来，那它再正确也没用。Dora 这套方案能落地，靠的是三个现实条件：
复用已有资产。 语义层不是从零建的，它直接继承企业已有的 BI 数据模型、指标和权限。企业过去积累的数据资产，恰恰是防幻觉最需要的语义地基。
原地升级。 已有 BI 体系的企业，不用为了上 AI 把数据搬来搬去，在原有体系上叠加 Agent 能力即可，实施周期短、对业务打扰小。
私有化部署。 对央国企、金融这类数据不能出域的企业，支持本地化、私有化部署，校验链路和可信机制都在企业自己的环境里跑。
这三条合起来，意味着防幻觉不是给企业增加一个高成本的额外工程，而是把企业已经具备的条件，转化成 AI 问数的可信基础。
小结
回到开头那个判断：企业 AI 问数的分水岭，已经不是谁的模型更聪明，而是谁的答案敢让人信。
对抗幻觉的正确姿势，不是换更强的模型，而是从架构上把犯错的空间关掉：
- 语义层管住理解，让 AI 查术语而不是猜术语；
- NL2DSL + 确定性引擎管住生成，让 AI 翻译而不是自由发挥；
- 三层校验管住结果，让错误在到达用户之前被拦截；
- 证据链管住信任，让每个答案都能顺着往回查。
这套思路不依赖某一家厂商，任何想做可信 AI 问数的团队都可以照着搭。Dora 的价值在于，它把这套方法论从设计稿做成了可交付的工程化产品——语义层复用、NL2DSL、三层校验、证据链，每一环都有具体的实现和落地的案例。真正值钱的，是用确定性对抗概率这套方法论本身。
免责声明： 本文内容基于公开技术资料及客户案例整理，仅供技术交流与信息参考，不构成任何采购建议。文中涉及的产品功能、技术架构等信息可能随时间调整，请以相关厂商官方最新说明为准。
