从问题到证据：当AI被允许"自由发挥"查数据库，会发生什么

你有没有想过，同一个问题问两次，可能得到两个看起来都对、但其实互相矛盾的答案？

比如"上周有多少起温度异常偏差事件被批准了"。听起来是个简单的计数问题，答案是17。可这个17是怎么来的？"上周"是自然周还是过去七天？"温度异常"是数据库里明确标记的类别，还是靠语义相似度模糊匹配出来的？被作废的记录算不算数？两套系统完全可能各自跑出一个17，但统计的其实是两拨完全不同的东西。

这就是MasterControl AI Lab这篇论文想解决的问题。他们研究的是企业级数据分析场景，比如制药、制造业的质量管理系统里，AI要回答"哪个工厂上个月的偏差率最高"这类问题。这类场景有个特殊要求，答案不能只是一个数字，还得说清楚这个数字是怎么算出来的，用了哪些记录，套用了什么定义。

数字好造，意义难保

论文一上来就把这个"17"的问题讲透了。作者提出，一份合格的分析结果不应该只是一个孤零零的数值，而应该是一个三元组：

结构化答案*：论文里用R = (m, v, E)表示，m是被系统认定的问题含义，v是算出来的具体数值或表格，E是支撑这个结果的证据记录（比如具体是哪17条数据）。

这个设计思路其实挺朴素的。你去医院拿化验单，报告单上不会只写一个数字，还会标注参考范围、检测方法、采样时间。企业分析系统面对的是审计、监管这类高风险场景，光给数字不给出处，出了问题根本没法追溯。

那这跟AI大模型有什么关系？

现在流行的做法是让大语言模型自己去理解问题、自己写SQL查询、自己执行、自己判断结果对不对。这种模式叫智能体式规划。

智能体式规划*：指让AI模型在运行时自主决定用什么工具、怎么查询数据、以什么顺序执行，最终自己选定一套分析方法来回答问题的做法。

论文作者认为，这种做法在企业级事实性分析场景下有个根本性风险，模型不仅仅是在计算一个答案，它是在请求发生的那一刻临时设计一套统计口径。而统计口径这种东西，一旦允许临时发明，同样的问题问两次都可能得到不同答案。

这就引出了整篇论文的核心设计原则。

模型负责理解，不负责决定方法

论文提出了一个清晰的架构边界：语言模型可以解释用户问的是什么，但不能决定用什么分析方法去回答。

这句话拆开看是这样的。用户输入一句大白话，比如"这个月哪个工厂出问题最多"，语言模型的任务是把这句模糊的话翻译成一个精确、无歧义的结构化请求，判断用户说的"出问题"具体对应数据库里的哪个字段、哪个定义。这一步之后，系统不再让模型自己写查询逻辑，而是交给一套**确定性策略**去匹配一个早就写好、经过测试、经过审核的分析程序，然后执行它。

确定性策略*：一套固定的规则或映射表，根据输入的标准化请求，唯一确定应该调用哪一段预先编写好的分析代码，不涉及任何临时决策或随机性。

这里有个特别形象的类比。你可以把这套系统想象成一家连锁餐厅的中央厨房。顾客点餐时可以用自己的话说"我要一份不辣的、多加点肉的炒饭"，服务员负责把这句话翻译成标准菜单上的编号，比如"3号餐，微辣改无辣，加肉一份"。但真正做菜的，是中央厨房里按照标准SOP训练出来的厨师，用的是统一配方和固定流程，不是服务员临时跑进厨房自己发挥去炒。如果让每个服务员自己决定怎么做菜，你今天吃到的炒饭和明天吃到的，用的油、火候、调料比例可能完全不同，出了食品安全问题也没法追溯是哪个环节出的错。语言的入口可以灵活，但生产的核心必须标准化，这正是论文里反复强调的架构边界。

这套分析语言由八个"操作家族"组成，每一个都有明确的职责边界。比如**RESTRICT**决定哪些记录符合条件，AGGREGATE决定在什么粒度上做统计，WINDOW处理时间范围，RANK处理排序和并列规则，SIMILAR处理语义相似度匹配。这八个操作可以像搭积木一样组合成一条完整的分析流水线，但流水线本身是提前审核好、版本控制好的，不是模型临时拼凑的。

限制会不会牺牲能力？数学给出了答案

这里作者面临一个很自然的质疑：把分析方法锁死成预先审核的程序，会不会导致系统能回答的问题范围变窄，很多复杂分析根本做不了？

论文用了整整两个定理来回应这个疑虑，思路借鉴的是数据库理论里一个经典的结果。

关系代数*：一套操作数据表的基本运算工具，包括筛选、投影（选取部分字段）、重命名、合并、并集、差集等，是现代数据库查询语言（比如SQL）背后的理论基础。

论文的第一个定理证明，对于任何可以用一阶逻辑公式精确描述的有限域查询问题，都存在一个只用RESTRICT、SHAPE、RELATE这三种基础操作构造出的程序，能给出完全一致的答案。反过来也成立，这套关系核心能表达的所有查询，也都能翻译回逻辑公式。这个证明的关键技巧是用差集运算实现逻辑上的"否定"，用投影运算实现"存在"量词，用并集实现"或"。

光有关系代数还不够，因为它没法直接表达"计数"这种会生成新数值的统计操作。所以论文又引入了第二层扩展，加入AGGREGATE、WINDOW、COMPARE、RANK、SIMILAR这些分析内核，并证明只要这些内核实现了声明的语义，任何属于这个统计分析类别的有限、无环的问题描述，都能找到对应的精确程序。

这里有个特别重要的措辞选择。论文反复强调，这个"完备性"不是说这套语言能做任何计算，而是相对某个明确划定的问题类别而言的完备。这就好比说，一套螺丝刀套装能拧开市面上所有标准规格的螺丝，但这不代表它能撬开一块石头。作者很诚实地承认了这个边界，这套系统能保证的是，只要问题落在预先定义好的分析范畴内，就一定有精确解法，而不是号称能应付一切奇思妙想的问题。

如果没有这种明确的能力边界划分会怎样？系统要么被过度神化，让用户误以为它无所不能，出了覆盖不到的问题时反而更容易临时发挥出错；要么就被过度保守地限制，明明能力范围内的问题也不敢交给它做。划清边界本身，就是一种诚实的工程态度。

同样的策略，还得保证每次跑出来的结果一模一样

除了"能不能算"，论文还证明了另一件事，"能不能每次算出同一个结果"。这叫**可重放性**。

可重放性*：指在数据快照、策略版本、程序版本、内核版本、数值计算规则完全相同的前提下，同一个分析请求无论重复执行多少次，都会返回完全相同的结果和证据。

这个证明本身逻辑不复杂，核心思路是把整个分析流程看成一张有向无环的依赖图，只要每个节点的输入相同、计算函数是确定性的，那么这个节点的输出就必然相同，一路推到最终输出也是相同的。

但论文在这里加了一个很值得注意的技术细节，关于近似计算的容错边界。如果某个分析环节用的是近似算法（比如语义相似度打分），只要真实分数和近似分数之间的误差不超过某个阈值η，并且这个误差没有大到跨越判断的临界线，那么最终的判定结果（比如是否超过某个阈值、是否进入排行榜前几名）依然是稳定的。但如果误差大到能跨越这条临界线，哪怕计算过程再"确定性"，结果也可能翻转。

这个提醒挺重要的，光是代码逻辑固定不等于结果永远稳定，数值层面的边界条件也得管住，不然表面上看起来严谨的系统，照样可能在临界点附近悄悄翻车。

论文还特意强调了一点，确定性的工具本身，不能保证一个自由选择工具的智能体也是确定性的。就算你给模型的每一个可调用工具都是精确无误的，如果模型在多个同样"合法"的工具组合之间可以自由挑选，那么它挑哪一个依然是不确定的，除非你再加上明确的搜索策略、收敛条件和验证规则。这句话其实是在给后面的实验结果埋伏笔。

真刀真枪地比一比：策略执行 VS 模型自由发挥

理论证明得再漂亮，终究要靠实验说话。研究团队设计了一个440轮次的对照实验，比较两种做法在同一批分析任务上的表现。

实验用的是一个模拟的质量管理制造业数据集，覆盖十一类典型分析任务，包括计数、分组（含零计数分组这种容易被忽略的边界情况）、缺失值查询、带并列的排序、比率计算、周期对比、贡献度拆解、连接表的多重匹配问题、精确均值、阈值判断、区域分组。

四套系统被放在同一硬件环境下对比，其中三套是运行时规划智能体，分别用了Qwen3-8B、Ministral-3-8B、Granite-4.1-8B三个80亿参数级别的开源模型，让它们自己检查数据、写SQL、执行、必要时修改，最终自己选定一个程序。第四套是本文提出的策略执行分析器，同样用Qwen3-8B做语言理解，但方法执行环节完全交给确定性策略。

特别值得一提的是，Qwen3-8B同时出现在两组实验里，一组是让它自由发挥写SQL，另一组是只让它做语义理解、不碰执行环节。这个设计非常聪明，因为它把"模型能力"这个变量彻底控制住了，两边用的是同一个模型，唯一的区别就是要不要给它决定分析方法的权力。

实验还专门设置了两个对照面板。一个是从自然语言问题开始的全流程测试，另一个是直接给系统一个已经标准化好的请求，跳过语言理解这一步，专门测"就算意思理解对了，运行时自己拼装查询逻辑这件事本身靠不靠谱"。每个生成出来的程序还要在四个额外的隐藏数据库变体上重新跑一遍，专门测试重复计数、时间边界、空结果、并列和空值这些容易踩坑的边界情况，防止系统只是背下了一个可见的答案而不是真正学会了统计逻辑。

结果如何？看这张表就知道了。

| 测试面板 | 系统 | 最终提交 | 完全正确 | Token消耗 | 重试次数 | 耗时(秒) |

| 自然语言 | Qwen3-8B智能体 | 0/55 | 0/55 | 6,850 | 0.64 | 6.372 |

| 自然语言 | Ministral-3-8B智能体 | 10/55 | 0/55 | 11,219 | 0.00 | 20.029 |

| 自然语言 | Granite-4.1-8B智能体 | 0/55 | 0/55 | 17,307 | 0.00 | 12.815 |

| 自然语言 | **策略分析器：Qwen3-8B** | **55/55** | **55/55** | **1,433** | **0.00** | **0.219** |

| 固定请求 | Qwen3-8B智能体 | 15/55 | 0/55 | 8,019 | 0.36 | 10.771 |

| 固定请求 | Ministral-3-8B智能体 | 5/55 | 0/55 | 15,252 | 0.09 | 23.670 |

| 固定请求 | Granite-4.1-8B智能体 | 25/55 | 0/55 | 17,912 | 2.91 | 34.003 |

| 固定请求 | **策略执行** | **55/55** | **55/55** | **0** | **0.00** | **0.0028** |

330轮智能体测试里，只有55轮生成了最终程序，剩下220轮直接被拒绝，55轮耗尽了工具调用预算都没跑出结果。而在成功生成程序的55轮里，全部对照五个数据库快照检验，没有一个是完全正确的。策略执行分析器则是110轮全对，一次没错。

这个结果有个特别细节值得展开讲讲。有五次运行确实在可见的开发数据集上算出了正确数字17，全部来自Ministral模型跑最简单的计数任务。但仔细一看，这五次生成的查询虽然数字对了，证据记录却贴错了角色标签，而且用的分组聚合逻辑在面对空结果的情况时会直接不返回任何行，这在边界情况测试里直接暴露出来。也就是说，这套查询记住了一个正确答案，却没有真正学会这道题背后的统计逻辑，这就是为什么论文坚持要用"数字加证据加边界测试"这个三重标准，而不是只看数字对不对。

固定请求这个对照面板特别能说明问题。因为语言理解的环节被完全跳过了，意味着运行时智能体失败不能再甩锅给"没理解错题目"，它们依然要自己决定怎么实现这个分析，结果还是165轮里0轮完全正确。

同模型对比也很直观。在自然语言这个面板里，策略分析器用的token数只有Qwen智能体的约五分之一，耗时是它的三十分之一都不到，正确率却从0跳到了满分。在固定请求面板里，策略执行完全不需要调用模型，耗时是十万分之三秒级别，而Qwen智能体还要花上万个token、跑十秒钟。

这个对比让我想起一个场景。假设你要给一批产品贴合格标签，一种做法是每次贴标签前都让工人重新测量一遍尺寸、重新判断合格标准该怎么定义，另一种做法是提前把测量方法和合格标准定死，工人只需要把产品放到检测机器上读数。前一种做法看似灵活，但每个工人对"合格"的理解可能有细微差异，测量习惯也不一样，出来的结果自然不稳定。后一种做法看似死板，但恰恰是这种死板保证了同一批产品无论谁来测、什么时候测，结论都一致。企业分析系统面对的正是这种需要一致性远胜于灵活性的场景。

作者没有回避的问题

这篇论文有个挺难得的地方，作者没有把这个结果过度推广。他们明确写道，这个实验结果是特定配置下的经验观察，不是在证明智能体架构天生做不了分析。用更大的模型、原生函数调用能力、更好的提示词设计、更大的工具调用预算，或者配合形式化验证的程序合成方法，都有可能让运行时规划表现得更好。

作者也划出了运行时规划真正适合的场景，那就是寻找方法本身就是任务目标的情况，比如开放式研究、新方法探索、代码生成、运营规划这类问题。论文的主张更精确地说是，如果一个事实性分析问题的正确方法已经被人类专家确定下来了，那么再让模型在请求发生的瞬间去重新发明一遍这个方法，只是白白增加了一个不必要的出错环节，对系统能表达的分析范围本身并没有任何帮助。

策略路线也不是没有代价的。审核过的分析程序需要人工编写、审核、测试、维护、做版本管理，覆盖面是靠人力一点点铺开的，不会自动扩展。所以作者提出，真正值得追问的产品问题不是"这套代数体系理论上能表达一切吗"，而是"现实中用户提出的问题里，有多大比例能被已审核的程序覆盖到，扩展这个覆盖面又要花多大成本"。这需要用真实的生产环境使用数据去回答，光靠理论证明和实验室基准测试是给不出答案的。

写在后面

读完这篇论文，最触动我的其实不是那两个数学定理，而是那五次"答案对但过程错"的案例。

一个模型明明算出了正确的17，却因为证据标签贴错、边界处理漏洞而被判定失败，这恰恰戳中了当前很多AI评测体系的软肋。我们太习惯用"最终数字对不对"去衡量一个AI系统是否靠谱，但在真正需要担责任的场景里，比如审计、合规、医疗质量管理，答案背后的推导路径和支撑证据往往比数字本身更重要。这提醒我，评估AI系统的正确标准，本身就需要被重新设计。

另一个让我反复琢磨的地方是，论文里那句"确定性工具不等于确定性智能体"。这句话拆开看其实挺反直觉的，我们通常会觉得，只要每个工具本身是可靠的、代码是没有随机性的，那把这些工具交给AI自由组合，结果应该也是稳定的。但论文点出的问题是，如果存在多条同样"合法"但互相矛盾的路径，模型选哪一条依然是不确定的。这跟"每个厨师做的每道菜都合格，但今天换个厨师你吃到的口味就不一样"是同一个道理，工具的确定性和系统整体行为的确定性，根本是两回事。

这套思路会不会推广到更多需要"可信度"而不只是"聪明度"的领域？金融风控、法律文书生成、医疗诊断建议，这些场景是不是也该问一句：我们到底是想要一个每次都能想出新办法的聪明系统，还是一个每次都用同一套经过验证的方法、并且愿意把证据摆在你面前的可靠系统？

Q&A

Q1：论文提出的策略执行分析器和普通的AI智能体查数据库有什么本质区别？

A：普通智能体在运行时自己决定用什么工具、怎么写查询、选什么方法，相当于每次现场发明一套统计口径。策略执行分析器则是让AI只负责理解用户问题的含义，具体怎么分析交给一套预先审核、测试、版本控制好的确定性策略去执行，不允许模型临时拼装分析逻辑。

Q2：论文里330轮运行时智能体测试为什么0轮完全正确？

A：因为评判标准不只看最终数字对不对，还要求匹配正确的记录、正确的证据角色标签，并且在四个隐藏的边界数据集上都表现一致。有5次运行虽然算出了正确数字，但证据标签贴错，且面对空结果时查询逻辑直接漏掉不返回，因此没有一次被判定为完全正确。

Q3：限制AI不能自由选择分析方法，会不会导致很多复杂问题回答不了？

A：论文用两个数学定理证明，只要问题属于论文定义的统计分析类别，就一定存在一个由固定操作组合成的精确程序能解决它，这叫"相对某个问题类别的完备性"。但作者也坦承，这套系统不是万能的，超出预先定义范畴的问题依然会暴露覆盖缺口，而不是被强行编造一个答案。