LLM数据智能体的追踪完整性：真实系统中可审计结构化推理的愿景

arXiv:2608.26036v1

摘要

答案准确率不足以作为LLM数据智能体的可靠性判断依据。在结构化数据任务中，即便输出了基准测试的正确答案，其背后的计算追踪也可能是无效的。本文提出追踪完整性（Trace Integrity），一套面向部署场景的可靠性评判标准，用于评估答案背后记录的计算过程是否具备：显式可记录、可执行、符合模式约束、算子忠实、可复现、与答案一致、可审计七大特性。

本文定义结构鸿沟（Structure Gap），这是造成追踪完整性缺失的部署失效模式：自然语言推理与自由文本理由，无法可靠落地为真实系统所必需的算子级程序。本文使用**执行契约（execution contracts）**将追踪完整性可操作化，这是一类结构化产物，将用户意图绑定数据库模式元素、算子执行计划、假设条件、可执行查询、校验状态以及最终答案关联。

同时提出CAIT指标（正确答案‑无效追踪率，Correct Answer / Invalid Trace Rate），用于衡量仅靠答案做评估时，有多少计算逻辑不成立的输出被误判为成功。

基于BIRD Mini‑Dev数据集开展实证实验：直接SQL方案、操作摘要+SQL、契约优先SQL三种方案答案准确率分别为20.0%、22.0%、24.0%；但追踪完整性通过率仅为39.0%、43.0%、40.0%；CAIT错误率依旧居高不下，分别达到55.0%、59.1%、45.8%。

实验证明：答案准确率、追踪有效性、隐性失败风险是三套完全独立的评估信号。面向生产环境的LLM数据智能体，不能只看输出答案是否匹配参考答案，还必须保证答案背后存在一套可审计的完整计算过程。

关键词：大语言模型；数据智能体；追踪完整性；可审计AI；Text‑to‑SQL；CAIT指标；执行契约；结构化推理

1 引言

LLM数据智能体正在成为操作数据的交互入口：读取数据库模式、生成SQL、调用工具、执行查询、汇总结果，向分析师、运维人员、临床人员、审计人员、普通用户输出结论。它降低数据库、表格、日志、企业分析系统的查询门槛，但同时引入新的可靠性难题。

问题不再只是"系统是否返回预期数值"。数据智能体可以输出看起来合理、基准测试正确的答案，但背后计算逻辑却用错筛选条件、关联条件、聚合函数、时间窗口、分组键或者模式绑定关系。

示例业务问题：排除试用账号，上个季度哪个区域的活跃客户平均收入最高？

智能体可以自信输出一个区域名称，但背地里：计算的是总收入而非人均平均收入；没有排除试用账号；按照销售办事处分组而不是客户区域；使用日历季度而非财年；依靠不稳定的名称字段做表关联，而不是稳定客户ID。

只评估最终答案，无法区分"计算逻辑完全正确"和"纯属巧合蒙对结果"。部署团队不仅需要知道输出了什么答案，还需要知道实际执行了怎样的计算。

这是工程部署层面的现实问题，不局限于学术基准测试。业务流程中，答案的使用者往往无法复现查询逻辑：BI报表使用者、合规审核人员、数据工程师、领域专家。他们不只是需要流畅的自然语言解释，更需要一份可检查的产物，明确记录使用了哪些模式字段、过滤器、关联、聚合逻辑、前提假设、执行结果，以此支撑最终答案。

本文提出：面向真实环境的LLM数据智能体，应当把计算追踪作为一等公民对象 ，这套评判标准就是追踪完整性 Trace Integrity。

注意：追踪完整性 ≠ 通用可信度。它不保证底层数据完整、公平、适合下游决策。它只解决特定部署风险：答案正确，不等于系统执行了用户真正请求的计算。

该需求来源于结构鸿沟（Structure Gap）：大模型以token序列生成推理，结构化数据任务却要求具备严格语义的算子级程序。有效结果依赖投影、过滤、表连接、分组、聚合、排序、排序选优、时间约束、模式绑定。Text‑to‑SQL、表格推理基准集中大量体现该痛点，任务核心是把自然语言请求映射为可执行计算，而不是生成看上去通顺的解释文本。

现有相关工作存在短板：

思维链CoT提示：生成中间自然语言推理文本，但自然语言理由本身不可执行，并且不一定忠实还原真实计算过程。
程序/工具增强方法：把计算交给外部系统执行；但是查询可以成功运行，却回答了错误问题。执行成功不等于程序匹配用户真实意图。

最隐蔽的失效场景：答案正确，但背后追踪无效。仅靠答案评估会把这类输出算作成功，但记录的计算过程根本无法支撑该答案。本文将该失效模式命名为CAIT（Correct Answer / Invalid Trace），使用CAIT Rate量化该现象。

本文贡献：

提出概念体系：结构鸿沟、追踪完整性；
提出执行契约 Execution Contract，让追踪完整性可以落地实现；
提出隔离原则 Isolation Principle，作为默认规划约束；
定义CAIT Rate指标，量化"答案对、计算追踪无效"这类隐性失败；
在BIRD Mini‑Dev数据集开展概念验证实验，证明答案准确率、追踪有效性、隐性失败风险三者相互独立。

核心观点：LLM数据智能体作为可靠的数据接口，不能只看返回的答案，还必须保证答案背后的计算过程可检查、可复现、可审计。

2 追踪完整性问题

2.1 算子约束与结构鸿沟

结构化数据问题会隐含大量算子层面约束：包含哪些记录、实体如何对齐、计算什么指标、用什么维度分组、时间窗口范围、排序规则如何确定极值。

示例："活跃客户的平均收入"，计算必须明确分子、分母；"上个季度"必须明确时间区间；"区域维度结果"必须绑定区域字段，不能使用语义近似的位置属性。

结构鸿沟（Structure Gap）定义：自然语言推理与算子级可执行计算之间的不匹配。自然语言表达用户意图，但无法强制落实结构化数据所必需的离散算子：过滤、连接、分组、聚合、排序选优、时间约束、模式绑定。

模型可以生成看起来合理的操作描述，但漏掉表连接、把平均值改为求和、过滤器作用到错误表、使用语义相似但含义完全不同的字段分组。在部署的智能体中，这就是可靠性故障：答案得不到计算过程的支撑。

该论述属于表征层面问题，不是否定大模型通用推理能力。有效的结构化数据回答，必须把用户请求绑定到可执行计算。Text‑to‑SQL任务直观体现该矛盾。

2.2 业务数据工作流中的隐性失效

结构化数据隐性失效的危险在于：一切输出表象完全正常。

SQL智能体生成可以正常执行的查询，但分组键错误；
调用了正确数据库，但缺少必须的排除过滤器；
自然语言理由写着"排除试用账号"，但实际执行SQL没有做过滤。

接口返回答案，用户很难怀疑计算已经偏离原始请求。

现实业务场景案例：

BI分析：需要客户人均收入，模型返回总收入；
合规报表：需要统计管辖司法辖区内交易，却统计全部交易；
临床分析：使用就诊日期做队列筛选，而不是诊断日期。

结论：只看最终答案不足以保证可靠性，计算过程本身必须可供检查。

2.3 CAIT失效模式

答案准确率把多种可靠性状态折叠成单一结果：

✅正确答案 + 有效追踪：真正可靠成功；
❌错误答案 + 无效追踪：显性结构故障；
❌错误答案 + 有效追踪：可能来源于数据问题、执行故障、用户问题存在歧义、基准参考存在其他合理解读；
⚠️正确答案 + 无效追踪（CAIT）：最具备部署风险的隐性失败。仅靠答案评估会把该情况算作成功，但记录的计算逻辑无法支撑输出结果。

CAIT Rate（正确答案‑无效追踪率） ：在系统所有输出正确答案的样本中，背后计算追踪无效的样本占比。

CAIT=Ncorrect∩invalidNcorrect \mathrm{CAIT}=\frac{N_{\mathrm{correct}\cap\mathrm{invalid}}}{N_{\mathrm{correct}}} CAIT=NcorrectNcorrect∩invalid

CAIT数值越高，代表仅依靠答案评估会高估系统可靠性，大量计算逻辑不成立的输出被统计为成功。

补充：查询执行成功也不等于可靠。SQL可以跑通，但回答的不是用户想问的问题。追踪完整性聚焦：记录的计算是否显式、可执行、模式合法、算子忠实、可复现、答案自洽、可审计。

3 追踪完整性作为审计契约

3.1 追踪完整性定义

追踪完整性：结构化数据答案背后记录的追踪，可以被检查、复现、审计。

这里的追踪不是模型内部隐式推理，也不是冗长自然语言解释；是系统记录的，用于证明答案具备计算支撑的全部记录：模式字段、过滤器、表连接、分组、聚合、排序、前提假设、执行查询/程序、和最终答案的关联关系。

一条追踪满足全部下表维度，才算通过追踪完整性校验。该条件不等同于完全语义正确；它定义最低限度条件：我们可以认为该数据智能体输出得到记录计算过程的支撑。正是这种分离，才使得CAIT指标具备意义：答案匹配参考结果，追踪依旧可以无效。

维度	校验内容	暴露的部署故障
显式 Explicit	追踪完整记录回答请求需要的全部计算约束	返回数值，但没有记录指标、分组键、过滤器、时间窗口、表连接路径
可执行 Executable	追踪包含可运行/可确定性校验的查询、程序、结构化计划	系统只存储自由文本理由，没有任何可复现产物
模式‑合法 Schema‑valid	引用的表、列、连接键、字段在数据库模式真实存在	请求绑定`customer.region`，实际库只存在`office_region`
算子忠实 Operator‑faithful	算子运算严格保留用户原始计算意图	用户要求人均平均值，追踪使用SUM求和；按办事处分组而不是客户区域分组
可复现 Replayable	在完全相同数据快照、执行环境重新运行，得到完全一致结果	答案依赖未记录隐式状态、未记录工具输出、未指定数据快照
答案‑自洽 Answer‑consistent	最终输出严格来源于执行得到的追踪结果	SQL查询输出A区域，自然语言回答输出B区域
可审计 Auditable	审核人员/校验系统可以检查计算、假设、故障模式	系统只保存最终答案，完全不记录生成过程

表1 LLM数据智能体追踪完整性七大维度

3.2 执行契约 Execution Contracts

执行契约是一份紧凑结构化产物，在执行前（或伴随执行）记录预期计算逻辑。它把用户意图绑定：模式元素、算子计划、前提假设、待执行查询、校验状态、最终答案。

契约不是冗长自然语言解释，也不能替代确定性执行。它的作用：让校验器、审计人员、下游答案生成模块，能够看到智能体做出的全部计算层面承诺。
清单1 一份精简的执行契约示例，记录可在校验、审计的计算承诺。

json 复制代码

{
  "intent": "highest average revenue per active customer last quarter, excluding trial accounts",
  "schema": {
    "tables": ["customers", "revenue"],
    "join": "customers.customer_id = revenue.customer_id",
    "filters": [
      "customers.status = 'active'",
      "customers.account_type != 'trial'",
      "revenue.date in last_quarter"
    ],
    "group_by": "customers.region",
    "metric": "SUM(revenue.amount) / COUNT(DISTINCT customers.customer_id)"
  },
  "plan": [
    "filter",
    "join",
    "group_by",
    "compute_metric",
    "sort_desc",
    "top_1"
  ],
  "verification": {"trace_integrity": "pending"}
}

校验器可以检查：引用的模式字段是否真实；SQL是否包含排除试用账号过滤器；关联键是否使用customer_id；指标分母是否为客户去重计数；最终答案是否来自执行结果。

契约驱动的数据智能体生命周期

用户查询 → 模式与策略上下文 → 执行契约 → 校验 → 确定性执行 → 最终答案 → 可审计追踪存储

校验阶段就可以拦截各类问题：模式绑定错误、算子错误、假设条件、权限、契约‑SQL不一致、答案‑追踪不一致；系统可以据此决定：展示答案、拦截输出、上报人工复核。

3.3 隔离原则 Isolation Principle

隔离原则：默认情况下，LLM数据智能体应当在访问真实数值数据之前，先明确指定完整计算计划。

理由：一旦看到返回数据值，模型可以反向补全原本定义残缺的计划，编造一套看上去合理的理由，对应一套从未真正承诺的计算逻辑。基于用户问题、数据库模式、元数据、策略上下文做规划，强制智能体在看到返回数值之前声明需要哪些算子。

该原则不是一条绝对禁止读取数值的硬性规则。

探索性汇总、离群点检测、数据画像、基于数值的阈值处理，确实需要读取数值。遇到这类场景，契约必须记录：为什么需要访问数值、授予了哪些访问、访问如何修改计划。

工程价值：默认将"计划定义"与"执行读取数值"两件事分开；任何打破该默认行为，都留下可审计记录。

4 实证实验：测量隐性追踪失效

使用BIRD Mini‑Dev数据集，验证"答案正确性"和"追踪有效性"会发生分离。BIRD数据集相比小规模合成表格任务，数据库规模异构性更强，更贴近业务分析场景。本实验属于概念验证。

4.1 实验设计

数据集：BIRD Mini‑Dev，100条样本；
基础模型：claude‑haiku‑4‑5，temperature=0.0；
三组提示对比条件：
- Direct SQL（直接SQL）：根据问题+模式，直接生成SQL；
- Operation Summary + SQL（操作摘要+SQL）：先生成简短自然语言操作摘要，再生成SQL；
- Contract‑First SQL（契约优先SQL）：输出结构化执行契约，之后再生成SQL。
全部三组使用相同问题、模式上下文、执行器、追踪校验器。
流程：执行标准答案SQL拿到参考结果；执行模型生成SQL；将模型输出追踪与标准化标准追踪做比对。

4.2 评价指标与校验规则

共5项评价指标：

Answer Accuracy（答案准确率）：模型SQL返回集合与标准答案SQL结果集合是否完全相等；
Execution Success（执行成功率）：生成SQL是否可以无报错运行；
Trace Integrity Pass Rate（追踪完整性通过率）：追踪满足可执行、模式合法、无严重算子不匹配；
Answer‑Trace Consistency（答案‑追踪一致性）：最终答案严格来源于执行追踪结果；契约优先组额外校验契约与SQL是否匹配；
CAIT Rate（CAIT错误率）：正确答案样本中，追踪无效样本占比。

校验器优先检查明确可判定故障，不做完备的全量语义等价证明。

判定追踪完整性失败的严重故障清单：

聚合函数错误/缺失

过滤器缺失

表连接缺失、连接路径错误

分组键错误

排序/Top‑limit错误

引用模式字段非法

SQL本身不可执行

答案与执行追踪结果不一致

契约与生成SQL之间不一致
局限性：校验器无法证明SQL语义等价，部分语义等价但写法改写的SQL会被误判失败。但不影响本实验核心目标：验证"答案正确"和"追踪有效"在实践中可以相互分离。

表2 BIRD Mini‑Dev实验结果

方法	答案准确率	SQL执行成功率	追踪完整性通过率	答案‑追踪一致性	CAIT错误率
Direct SQL	20.0%	84.0%	39.0%	84.0%	55.0%
Operation Summary + SQL	22.0%	83.0%	43.0%	67.0%	59.1%
Contract‑First SQL	24.0%	82.0%	40.0%	82.0%	45.8%

指标说明：答案准确率、执行成功率、追踪完整性通过率、答案‑追踪一致性越高越好；CAIT错误率越低越好。

4.3 实验结果

三组答案准确率区间仅20.0%‑24.0%，但大量正确答案背后的追踪是无效的。

Direct SQL：准确率20.0%，追踪完整性39.0%，CAIT=55.0%；
Operation Summary + SQL：准确率22.0%，追踪完整性三组最高43.0%，CAIT最高59.1%；
Contract‑First SQL：答案准确率三组最高24.0%，CAIT最低45.8%，追踪完整性40.0%略低于操作摘要方案。

关键结论：答案准确率、追踪有效性、隐性失效风险，是完全不同的评估信号。同一个系统，在某一个指标表现好，另一个指标可能很差。生产环境必须同时上报多套指标，不能把执行成功当作唯一成功标准。

四象限拆分统计（正确答案 & 无效追踪即CAIT案例）：

Direct SQL：11例；
Operation Summary + SQL：13例；
Contract‑First SQL：11例。

只看答案，这些样本全部被判定成功，但底层计算追踪并不成立。

全部300次预测中，有51条SQL无法执行（占17.0%），属于显性故障。但更值得工程关注的是执行成功，但追踪依旧无效的隐性故障：错误表连接、聚合错误、文本摘要和SQL逻辑背离、契约与生成SQL不匹配。

追踪完整性带来工程价值：故障可以被归类为：模式合法性问题、算子不匹配、契约‑SQL不一致、答案‑追踪不一致，而不是被一个流畅的最终答案掩盖。

5 部署启示与结论

追踪完整性是面向部署的评判标准，不只是学术评估指标。

生产环境数据智能体实践建议：

将执行契约与答案一起持久化存储；
在执行SQL之前校验契约；
当答案与追踪出现矛盾时触发告警；
将失败的追踪产物复用于回归测试；
契约产物同时支持分析师复核、合规审计、故障排查、监控数据库模式漂移。

本概念验证实验不代表"契约优先提示彻底解决Text‑to‑SQL任务"。核心发现：看似正确的答案，背后完全可能是无效计算；仅评估答案无法暴露该风险。

面向企业分析、合规报表、金融分析、医疗分析这类决策相关场景，LLM数据智能体不应当仅仅输出结构化问题的答案；还必须留下可检查、可复现、可质疑的计算记录，故障发生时可以转化回归测试用例。

这才区分两类系统：一类只是偶尔蒙对答案；另一类可以展示凭什么该答案值得信任。

6 局限性

本论文属于愿景+小规模概念验证，不是对各大模型、提示策略的全面基准评测。实验仅使用BIRD Mini‑Dev 100条分层样本，单模型Claude‑Haiku‑4.5，固定提示与执行配置。报告得到的绝对百分比，仅用来证明现象存在，不能作为模型/提示方案稳定排名依据。
追踪校验器使用确定性算子级检查，保证可复现；但它做不到完备语义等价校验。部分语义等价SQL改写会被误判失败；同一条问题BIRD数据集本身就允许多种合法SQL写法。CAIT Rate是诊断指标，不是对单条查询的最终语义判决。
SQL执行失败占据一部分追踪完整性失败样本；这属于显性故障。论文最核心论证证据来源于：SQL执行成功，但追踪依旧无效的隐性CAIT案例。

7 伦理考量

数据集使用公开基准BIRD Mini‑Dev，没有采集全新人类受试者数据；实验仅使用基准问题、数据库模式、生成SQL、执行结果、追踪产物；不涉及用户隐私数据、PII个人身份信息。
追踪完整性同时具备伦理意义：业务场景中流畅正确的答案，可能掩盖无效计算逻辑，决策者信任没有计算支撑的输出，会带来现实风险。追踪层面评估可以暴露过滤器、关联、聚合、假设条件，降低该风险。
但追踪/执行契约本身带来新治理责任：契约、追踪日志会暴露业务敏感细节，必须和其他业务数据做同等保护，设置访问权限、数据保留周期、脱敏策略、审计日志。
追踪完整性不等于要暴露模型内部隐式思维链，契约只记录计算层面承诺，不存储无限制原始快照。
追踪完整性只是辅助人工审核的工具，不能替代领域专家判断。即便追踪完整有效，也不代表底层数据质量足够支撑下游决策。高风险业务，依旧要结合现有数据治理流程、人工复核、机构监管一起使用。