# 从能查数到决策链：我对 AI 问数的理解

**共创** · 作者：[SummerBetter](https://github.com/SummerBetter)

> 个人经验整理；具体效果与验证范围待补充。

结合在不同公司搭建和迭代问数系统的经历，聊聊问数的四个阶段，以及背后的架构演进。

关于 AI 问数，我经历过四个阶段：**能查数、能查准、能用数、决策链。**

这四个阶段并不是逐一迭代、逐一舍弃的关系。不是到了“能用数”，就不用再关心“能查准”；也不是开始做“决策链”，问数本身的建设就结束了。每个阶段都仍然在向前推进，并为下一阶段提供更好的服务。

如果把这几个阶段连起来看，就会发现：问数最初是一个数据查询问题，随后会变成数据治理问题，再往后，则会推动整个系统从问数工具演进为智能体系统。

## 一、我理解的问数四个阶段

在我看来，目前问数的行业标杆水平，应当具备下面这些能力：

| 阶段 | 应当达到的能力 |
| --- | --- |
| 能查数 | 支持多数据源查询，既包含结构化数据，也包含非结构化数据。其中，云上数据源是必须支持的。 |
| 能查准 | 能够完成复杂关联查询，并在相似语义下准确找到用户真正需要的数据。 |
| 能用数 | 查询到的数据不应该只用于展示，还应当成为其他 skill 的支撑，参与更深入的业务工作。 |
| 决策链 | 能够根据数据触发经营决策与执行动作，让数据从查询走向执行闭环。 |

> 图 1 · 四个阶段是持续延伸的能力线。越接近经营行动，对底层数据质量与可追溯性的要求越高。
>
> 能查数从最早开始持续推进，能查准、能用数和决策链依次加入；新增能力不替代原有能力。

这看起来只有四句话，但真正落实到系统建设上，会涉及很多细节。下面按照我在不同公司搭建问数及迭代系统的经历，展开讲讲这条演进路径。

## 二、最初的问数：先把 ODPS 云上数据查出来

一开始做问数时，我优先支持的是 ODPS 云上数据源。原因很直接：在当时的业务环境里，ODPS 往往有着最全的业务维度数据。订单、会员、商品、门店等数据汇集在一起，可以支撑比较完整的经营问题。

这个阶段的核心链路并不复杂：用户用自然语言提出问题，AI 理解问题，结合表结构生成 SQL，再执行查询、返回结果。

当时 AI 刚刚兴起，大家对产品的容忍度普遍比较高。只要能够用一句话查出原本需要找数据同学才能拿到的结果，就已经能带来比较直观的价值。

但用得越多，问题越明显。单表查询往往具有较高的精度，而一旦需要关联三至五张表，效果就容易大幅下降。另一个问题是相似语义：同一个业务指标可能出现在多张表里，字段名字看起来也差不多，但实际含义、统计粒度或使用场景并不完全相同，AI 很容易选错。

于是，下一阶段的要求就自然出现了：**如何让 AI 在多表关联和相似语义下，仍然能够查准数据？**

## 三、为了查准，需要数据清洗与图数据库的配合

到了这个阶段就会发现，单纯让 AI 更努力地理解表结构是不够的，还必须有数据清洗的配合。需要把字段含义、业务口径以及表与表之间的关系整理清楚，让 AI 有明确的依据。

为了解决多表关联的准确性，我认为目前较好的方法，是**建立表、字段级别的图数据库，根据图数据库中的明确关系完成关联**，从而让多表查询取得更好的效果。

### 图数据库里，具体要建立什么？

这里建立的图，主要描述数据结构及业务关系，而不是把业务数据库里的每条订单、每条交易都复制进去。可以先把数据表和字段分别作为节点，再把它们之间的关系建立起来。

- **表节点：**记录表名、业务含义、数据粒度，以及这张表主要服务什么场景。例如，一行代表一笔订单，还是一笔订单中的一件商品。
- **字段节点：**记录字段名称、类型、业务说明，以及它属于哪张表。对于金额、时间、状态等关键字段，补充其具体含义。
- **关联关系：**记录字段之间如何连接，哪些是一对一，哪些是一对多，连接时是否还需要组织、租户或时间等额外条件。
- **指标与业务语义：**将业务叫法、同义词和指标定义关联到具体表字段，帮助 AI 区分名字相近、含义不同的数据。

例如，“销售额”可以对应订单金额，也可以对应支付金额或退款后的净额。如果只提供字段名，AI 很难稳定选择；如果图中同时建立了“指标—业务定义—来源字段—适用场景”的关系，就有了更明确的判断依据。

> 图 2 · 图数据库保存表、字段和业务语义之间的关系。示例中的关联需以实际数据验证为准。
>
> 销售额指标通过口径定义关联到订单表的金额字段；订单表的门店编号和会员编号分别关联门店表和会员表。图中记录关联基数、字段含义和适用条件。

### 这张图，可以怎样建立起来？

第一步是采集元数据。读取数据源中的表结构、字段类型、注释、已有主外键信息，以及现有 SQL 和数据加工任务里已经使用的关联关系，先建立基础节点和候选关系。

第二步是结合业务数据进行清洗和验证。同名字段不一定具有相同含义，已有 SQL 里的连接方式也需要确认。可以通过字段唯一性、空值比例、关联匹配率以及连接前后行数变化，检查候选关系是否成立。对于关键业务关系，再由数据专家结合业务含义确认。

第三步是补充语义。把业务常用词、指标解释和字段映射填进去，尤其要处理那些“名字相似、口径不同”的指标。比如同样叫销售额，分别按下单时间、支付时间还是结算时间统计，需要在图中明确。

第四步是让图真正参与查询。用户提出问题后，先定位指标和维度，再从图中找到相关表及连接路径，把明确的字段、关联条件和口径交给 AI 生成 SQL。这样，AI 不再面对一堆彼此孤立的表结构，而是沿着已经建立好的关系完成查询。

例如，要查询“某区域不同会员等级的销售额”，系统可以先定位销售额指标，再沿着订单与门店、订单与会员的关系取得区域和等级。对于一对多关系，则需要结合统计粒度安排聚合，避免因为连接后行数增加而重复累计金额。

最后，这张图也需要随着业务迭代而更新。新增表、字段变更、指标口径调整，都应同步反映到图中。到这里，多表关联和相似语义的问题有了更好的解决方式，但另一个问题也开始显现：**业务数据的维护成本越来越高。**

## 四、架构的主体，应当从问数变成智能体系统

随着深度使用，这个阶段通常会带来两个问题：一是业务数据维护成本高，二是只是查数还不够，需要更深层次地使用数据。

我认为这里有一个关键点：**你构建的系统，现在不应当只服务于问数了。**如果之前的整体架构就是围绕问数搭建的，那么到了这里，应当考虑进行重构：基于一个 harness 或 loop 底座，把问数作为其中的一个 skill 或专家。

也就是说，架构的主体应当从“问数系统”变成“智能体系统”。问数仍然重要，但它成为整个系统的一项专业能力，可以被其他任务调用，也可以与其他专家共同完成一个业务目标。

在这个架构里，harness 负责把模型、上下文、工具和任务执行过程组织起来；loop 则让系统能够根据执行结果继续向前推进：理解目标、选择下一步、调用工具、观察结果，再决定继续查询、补充分析，还是进入执行。

例如，用户提出“分析这个月某区域销售下滑的原因”，系统不必一次生成一个完整答案。它可以先让问数专家查整体变化，看到结果后再拆分门店、品类或会员维度；发现某个方向值得深入，就继续调用相应专家。前一步的结果，成为后一步工作的依据。

> 图 3 · 架构主体是智能体系统。问数是其中一个专家，AI 通过 CLI 原子能力构建数据引擎，并在自评测反馈下迭代。
>
> Harness 与 loop 组织专家团协作。问数专家提供数据，其他专家进行归因、决策和执行。AI 通过 CLI 原子能力设计维护数据引擎层，数据引擎基于业务数据建立表和指标，自评测结果反馈给 AI。

基于这样的架构，再去解决数据维护成本和数据深度使用的问题，就会顺手很多。因为系统已经具备了持续执行、使用工具和根据结果调整下一步的基础，不再局限于“一问一答”的查询流程。

## 五、让 AI 自己设计数据引擎，降低业务维护成本

对于业务数据维护成本高的问题，我现在的做法是：**基于业务数据，由 AI 结合数据自行分析、设计一个数据引擎层。这层的所有表和指标，都由 AI 来进行设计。**

我们需要做的，是通过 CLI 为它提供原子能力。比如读取表结构、查看样本、执行查询、创建表、更新指标、运行加工任务以及执行评测。AI 将这些能力组织起来，自主构建自己更容易理解和使用的表结构，最终以业务效果来考核整体系统。

这里的“原子能力”，可以理解为一组明确、可组合的操作。每个操作有清晰的输入、输出和执行反馈：建表是否成功，查询返回了什么，评测失败在哪个案例。底层工具负责把动作执行好，AI 负责根据目标决定何时调用、如何组合。

举个例子，如果 AI 发现某一类经营问题总要重复关联订单、门店和商品数据，它就可以结合查询需要设计一张更适合分析的主题表；如果发现多个问题反复使用同一种计算口径，就可以将它沉淀为一个指标。之后的问数便可以复用这些结构，减少每次从原始数据重新理解和拼接的负担。

这也是我理解的真实的 AI 原生架构：**不仅是让 AI 使用一套人设计好的数据结构，而是让 AI 参与设计、构建和迭代它自己的数据使用环境。**

### 从专家指导，逐步走向自评测驱动

当然，在最初建立表和指标时，仍然需要业务与数据专家的指导。哪些数据可信、某个指标在公司内部如何定义、哪些关联符合业务事实，这些经验需要在早期传递给系统。

接下来，就要逐步建立自评测体系。把典型业务问题、正确口径和参考结果沉淀为评测案例，AI 每次调整表结构或指标后，都可以运行这些案例，查看是否改善了实际查询效果、有没有影响原来已经正确的问题。

例如，新增一张主题表之后，不只是检查“表有没有建成功”，还要检查：以前复杂的查询是否更容易完成了，统计结果是否与参考结果一致，相似指标是否更容易区分，以及维护和查询成本是否有所下降。

自评测中的参考结果，需要来自已确认的业务口径或数据核验，不能只是让 AI 对自己的输出打分。有了这样的反馈，系统就可以围绕失败案例继续调整，逐步形成“分析数据—设计模型—构建表和指标—评测—再改进”的循环。

随着这个循环运转起来，业务和数据专家就不必长期陷在大量重复维护中，而可以更多地关注业务效果和关键口径。这也是这一层架构要解决的核心问题。

## 六、问数进入专家团，数据才能被更深地使用

对于“能用数”和“决策链”的问题，基于 harness 架构，可以构建多专家、多技能体系，让问数作为其中的一个专家参与工作。

问数专家的职责，是提供辅助数据。其他专家基于这些数据进行深度归因分析，再进一步参与经营判断。这样，数据就不再止于界面上的一张表或一张图，而是成为其他 skill 的输入。

例如，用户希望了解某品牌经营表现变差的原因，问数专家可以先提供销售、客流、会员、商品等维度的数据；归因分析专家根据这些数据拆解变化，提出需要进一步验证的问题；问数专家再补充查询。经过几轮协作，专家团逐步形成更完整的判断。

在这个过程中，harness 保存任务上下文和各专家的结果，loop 推动“提出问题—补充数据—分析—再查询”的过程。数据专家不需要一次就把所有可能用到的数据查完，而是随着分析需要持续提供支持。

为了让专家之间协作顺畅，问数返回的内容除了数据本身，还应包含相应口径、时间范围和必要说明。这样，其他专家能够知道自己使用的是什么数据，不至于在后续分析里误解指标。

至于是否真正参与业务决策，则因“司”而异。有的公司会先让系统提供分析和建议，有的会让业务人员确认后执行，有的则会在适合的场景下，允许系统根据数据触发经营动作。

当执行结果再回流为新的数据，系统就可以继续观察动作是否有效，决定下一步如何调整。至此，问数才从数据查询进一步进入经营执行闭环。

## 七、走向商业化，再把多数据源补齐

当这样一整套系统建立起来，接下来很自然就会考虑商业化：如何把产品提供给更多公司？

这时会遇到新的问题。目标客户的体量不同，数据基础也不同，不一定都有 ODPS 云上数据，使用的数据库也可能多种多样。所以，系统需要进一步支持多数据源查询。

沿着前面的架构，实现这一步的核心思路并不难：**添加一个 SQL 执行引擎，根据不同数据源进行区分和查询。**上层问数专家继续负责理解业务问题和组织查询，下层执行引擎负责把查询交给相应的数据源。

具体来说，可以为不同数据源提供对应适配，处理连接配置、SQL 方言、执行状态与结果返回。这样，每新增一种数据库，主要扩展的是执行层，而不需要重新搭建整个问数和专家协作流程。

结构化数据沿着这条路径接入；对于非结构化数据，也可以在同一套工具体系中提供检索与内容读取能力，让问数和其他专家按需使用。

到这里，一个以降低业务人员深度维护负担为目标，同时能够查准数、用好数的问数系统，就逐步建立起来了。也可以看到，虽然系统已经走到了专家协作和决策链，“能查数”这一阶段仍然在通过多数据源接入继续向前推进。

## 八、最后一个问题：如何让用户敢用查出来的数据？

问数还有一个通用的弊端：AI 是生成式的预测模型，在实际开放式使用中，我们不能期待它每一次都准确。

对于数据查询，这会带来一个很直接的问题：假设一百次查询有九十九次正确，那如何让用户相信，这一次看到的不是错误的那一次？即使整体准确率已经很高，这个疑问仍然存在。

在我看来，现阶段不能只等技术把准确率继续提高，才来解决用户敢不敢用的问题。未来模型能力不断发展，可能从两个九提升到四个九，错误影响进一步降低；但在今天，产品本身也需要提供一种让用户理解和校对结果的方式。

我目前采取的方法是：**AI 执行一次查询后，输出的不只是结果，还要把此次实际执行的 SQL 翻译回业务语言，进行语义校对，并附上口径说明。**

例如，用户问“上个月的销售额”，返回结果时，应同时说明统计的是订单金额还是实收金额，按下单时间还是支付时间，是否扣除退款，以及包含哪些门店。用户看到这段说明，就能判断系统此次的理解是否符合自己的本意。

> 不是告诉用户：“你的问题，我查到了什么数据。”
> 而是告诉用户：“根据你的问题，我查询了什么口径的数据，结果是什么。”

这种表达上的变化，看起来只是多了一段说明，实际上是把问数过程中原本隐藏的理解过程，转化成了用户可以校对的业务口径。用户不需要理解 SQL，也能发现“这不是我想要的销售额口径”，并继续修正问题。

这里展示的是基于已执行 SQL 的业务解释，包括筛选条件、统计范围和计算方式。它不能代替结果校验，但可以先从产品层面缓解“只有一个数字、不知道该不该信”的问题，也为专家团后续使用数据进行决策，多增加一道保障。

## 结语

从最初支持 ODPS 查询，到通过图数据库改善复杂关联，再到基于 harness 构建 AI 数据引擎和专家团，这条演进路径的背后，是业务对数据使用要求的不断提高。

能查数，解决数据能不能被访问；能查准，解决业务问题能不能被正确理解；能用数，让问数成为其他技能和专家的支撑；决策链，则进一步将数据与经营动作连接起来。

这四个阶段始终都在往前推进。每一个阶段做得更好，都是为了更好地服务下一阶段。

## 延伸：问数领域的关键面试问题

| 考察项 | 问题 | 答案 | 追问 |
| --- | --- | --- | --- |
| 查询效果与能力边界 | 查询准确率怎么样？支持多表查询吗？ | 准确率需要结合业务场景和评测口径说明，不能只看 SQL 执行成功率。应分别看单表、多表关联及相似语义下的结果正确率，并用真实问题和已核验的结果评测。支持多表查询，也需要说明实际验证过的复杂度、典型错误和能力边界。 | 你们的准确率是怎么测出来的？单表和三至五张表关联的效果分别如何？能否举一个 SQL 执行成功但结果错误的案例？ |
| 多表关联与语义准确性 | 如何做多表关联查询？ | 配合数据清洗，建立表、字段级图数据库，记录表字段含义、数据粒度、关联键、关联基数和必要的附加条件。查询时先定位指标与维度，再根据图中的明确路径生成 SQL。对相似指标，补充口径与来源字段的映射，避免选对了关联却选错了指标。 | 图中的关联关系从哪里来，如何验证和更新？一对多关联导致金额重复累计怎么处理？多个表都有“销售额”时如何选择？ |
| 数据使用与决策链路 | 问数的结果会用到什么地方？是否加入归因分析或决策链路中？ | 基于 harness 或 loop 底座，把问数作为一个 skill 或数据专家，为其他专家提供数据及口径说明。归因专家根据结果分析并提出补充查询，策略专家形成建议，再根据公司的实际情况进入人工确认或授权执行。执行结果回流后，继续评估效果，形成闭环。 | 能否用一个真实业务问题讲清楚专家之间如何协作？谁决定继续查什么？目前做到展示、归因、建议还是执行，执行后的效果如何反馈？ |
| 数据维护成本与 AI 数据引擎 | 问数的数据维护成本怎么样？考虑过如何用 AI 降低这个成本吗？ | 维护成本主要来自表结构、指标口径、关联关系和业务变化。可以基于业务数据，让 AI 自行分析和设计数据引擎层的表与指标，通过 CLI 提供查询、建表、指标管理和评测等原子能力。早期由业务与数据专家指导，随后通过自评测持续改进，以最终业务效果和维护成本检验系统。 | 目前最耗费人力的维护工作是什么？你会给 AI 哪些原子能力？评测参考结果从哪里来，如何证明 AI 调整后效果更好、维护成本更低？ |
| 多数据源扩展 | 多数据源怎么处理？ | 增加统一的 SQL 执行引擎，根据不同数据源路由到相应适配器，处理连接、SQL 方言、执行状态与结果返回，让上层问数和专家协作复用同一套流程。非结构化数据通过检索、读取能力接入同一工具体系；同一个问题需要跨源关联时，再明确数据整合与执行方式。 | 新增一种数据库需要改哪些地方？如果一个问题同时用到两个数据源，关联在哪里执行？非结构化资料如何与查询结果一起被使用？ |
| 单次查询的可信与可用性 | 数据是一个严谨性要求很高的 AI 场景，如何确保此次数据可用？ | 整体准确率高，不代表当前这一次一定正确。返回结果时，应将实际执行的 SQL 翻译回业务语言，附上指标口径、时间范围、筛选条件和数据来源，让用户校对“此次到底查了什么”，并把说明一起传给后续专家。口径解释之外，还应结合结果校验与必要的对账；存在未解决的歧义或异常时，应明确说明，不能直接视为可用。 | 即使准确率达到 99%，你怎么回应用户对这一次结果的担心？如果 SQL 和解释一致但都理解错了，如何发现？用于一般分析和直接触发经营动作时，可用标准是否相同？ |

[返回最佳实践](README.md)