同一查询不同答案：语义查询引擎的运行间方差难题

语义查询引擎（Semantic Query Engine）正在成为连接大语言模型与结构化数据的桥梁。这类系统让 LLM 逐行判断数据内容——比如判断某条文本是否符合某个条件、从表格中抽取特定字段。但一个被长期忽视的问题浮出水面：同样的查询，重复运行两次，答案可能不一样。一项基于 120 万次模型调用的研究，系统性地量化了这种运行间方差（run-to-run variance），并对现有基准测试的可靠性提出了严肃质疑。

温度为零也无法保证确定性

直觉上，当 LLM 的采样温度（temperature）设为 0 时，输出应当是确定的。但研究团队重新运行了 SemBench、LRO-Bench 和 UDA-Bench 三个基准的文本与表格工作负载，记录了全部 120 万次模型调用后发现：即便在 temperature 0 的条件下，五次执行中仍有 0.07% 到 10.2% 的行会改变其算子输出，具体比例取决于模型，而在某个任务上这一数字高达 24.0%。

这意味着所谓的"确定性推理"在工程实践中并不成立。硬件浮点运算的非确定性、并发调度、以及模型服务端的实现细节，都可能让同一输入产生不同的 token 分布。对于逐行判断的语义查询而言，哪怕单行的翻转概率很低，累积效应也不容忽视。

采样温度（temperature）是控制语言模型输出随机性的核心参数。temperature = 0 时，模型在每个解码步骤都选择概率最高的 token（即贪心解码），理论上对同一输入应给出完全相同的输出。然而这一理论前提在工程实践中存在多个漏洞：现代 GPU 的浮点运算在并行化条件下不满足结合律，不同批次大小或并发请求量会导致中间计算结果产生细微差异；模型服务框架（如 vLLM、TensorRT-LLM）为提升吞吐量引入的连续批处理（continuous batching）和 PagedAttention 等机制，进一步使单次请求的计算路径因系统负载而变化；部分云端 API 在服务端会对 temperature 的语义做额外解释或修改。这些因素叠加后，所谓"确定性"只是统计意义上的"大概率相同"，而非数学意义上的"必然相同"。

查询计划如何指数级放大误差

真正棘手的问题在于误差的传播机制。研究用"可能世界"（possible-worlds）模型来刻画这一现象：查询计划会随答案所涉及的行数呈指数级放大这些变化。

在 UDA-Bench 上，只有几个百分点的抽取值发生改变，但最终约有三分之二的答案发生了变化。原因不难理解：一个最终答案往往聚合了多行的判断结果，只要其中任意一行翻转，整个答案就可能不同。单行的微小不稳定，经过聚合算子的组合，被急剧放大成答案层面的巨大波动。这对任何依赖多行聚合的分析型查询都是致命的隐患。

「可能世界」（possible worlds）模型是数据库不确定性理论中的经典框架，最初用于描述包含不确定数据的概率数据库。其核心思想是：当数据中每个事实都以某个概率存在时，整个数据库对应着指数多个"可能的确定性世界"，查询结果需要在所有可能世界上取期望或求分布。将这一框架迁移到语义查询场景，每一行的模型判断都成为一个概率事件——模型以 p 的概率输出"满足条件"，以 1-p 的概率输出"不满足"。对于需要聚合 n 行结果的查询（如 COUNT、SUM 或需要收集多行后才能回答的问题），最终答案的稳定性由所有参与行的联合分布决定。即便每行翻转概率仅为 1%，100 行中至少有一行翻转的概率已接近 63%，这正是 UDA-Bench 上少量行变化却导致大多数最终答案改变的数学根源。

基准测试的结论可能站不住脚

这项研究最具冲击力的发现，是对现有基准测试可信度的直接挑战。

在 SemBench 已发布的结果中，21% 的文本结果在不同执行间质量发生变化——其中甚至包括那些查询计划本身是确定性的引擎。换言之，论文里报告的"A 引擎优于 B 引擎"的结论，可能仅仅是某一次执行的偶然产物。

研究进一步指出，若干针对单个查询的系统对比结论，以及 LRO-Bench 实现建议中 28 项测试里的 16 项，都无法被基准实际运行的那几次执行所"判定"。这些结论处于统计噪声之内，重跑一遍就可能反转。对整个领域而言，这意味着大量已发表的性能排名需要重新审视。

哪些行会改变，是可以预测的

变化并非完全随机。研究揭示了几条清晰的规律：

• 发生改变的行，正是模型之间彼此存在分歧的行。不同模型对同一行判断不一致，恰好对应了单一模型自身输出不稳定的那些行。
• 单次执行内的重复请求，其分歧频率与跨执行的分歧频率相当。这说明不确定性是模型行为的内在属性，而非跨会话的偶然。
• 决策边界（decision margin）或推理长度可以预测哪些行会改变。模型越"犹豫"（置信度低、推理链冗长），该行翻转的可能性就越大。

这条发现极具实用价值——它意味着系统可以提前识别出高风险的行，并对其采取针对性的稳定化措施。

决策边界（decision margin）的概念来源于分类模型的可解释性研究：在二元分类中，越靠近决策边界的样本，模型越难以明确归类，其预测置信度越低、也越容易因输入的微小扰动而翻转。在使用思维链（Chain-of-Thought）或推理步骤的 LLM 判断中，推理链长度是决策边界距离的一个代理指标——当模型需要大量推理步骤才能得出结论时，往往意味着该行的语义特征落在判断标准的模糊地带。这两类信号的可预测性为工程实践提供了重要接口：系统可以在首次执行后，对置信度低的行自动触发多次重跑或升级到更强的模型，而对置信度高的行则沿用单次结果，从而在精度与计算成本之间实现动态权衡。

投票与级联：缓解而非根治

面对方差，常见的工程手段是投票（voting）——多次执行取多数结果。研究证实投票确实能降低方差，但无法将其消除。另一种方案是校准级联（calibrated cascade），它在保持自身保证的同时，返回的行集合仍会发生变化。

换句话说，目前没有任何单一技术能彻底消除运行间方差。可行的路径是组合策略：用决策边界识别高风险行、对关键行投票、并在报告时如实披露不确定性。

对基准设计和引擎设计的启示

基于以上发现，研究为两个群体给出了明确建议：

对基准测试的报告规则：不应只报告单次或少数几次 temperature 0 执行的结果，而应多次执行并报告方差区间，明确标注哪些对比结论在统计上尚未定论。否则排行榜的"胜负"可能毫无意义。

对引擎的设计规则：引擎应当将不确定性视为一等公民，利用决策边界和推理长度等信号识别不稳定的行，并通过投票、级联等机制在成本与稳定性之间取得平衡。

这项工作的意义超越了具体数字。它提醒整个语义数据处理社区：当我们把 LLM 当作数据库算子来用时，必须正视其概率本质。确定性不是免费的，而评估的严谨性，正是建立在对这种不确定性的诚实量化之上。