引言: 电子表格中的“幻觉”

我们都熟悉大型语言模型 (LLM) 的超能力。它们能写诗、总结邮件，还能生成代码。但我们也痛苦地熟悉它们的软肋: 事实。当你问 LLM 一个需要精确数据分析的问题时——例如“加利福尼亚州的野火严重程度排名与全国平均水平相比如何？”——模型经常会产生幻觉。它就像一个没复习就去考试的学生，试图在论文中蒙混过关。

为了解决这个问题，业界采用了 检索增强生成 (Retrieval Augmented Generation, RAG) 。 RAG 将 LLM 连接到文本文档库，允许它在写作前“查找”答案。这对于非结构化文本效果奇佳。但是，当答案不在文档中，而是隐藏在庞大的 SQL 数据库里时会发生什么？如果答案需要数学运算、聚合或过滤呢？

仅仅检索文本是不够的。我们需要 分析增强生成 (Analytics Augmented Generation, AAG) 。

在这篇文章中，我们将剖析一篇来自西北大学的精彩论文，该论文介绍了 SATYRN , 一个旨在弥合 LLM 与结构化数据之间鸿沟的平台。与简单地要求 LLM 编写 SQL 代码 (这通常会出错) 的工具不同，SATYRN 使用一种确定性的、神经符号 (neurosymbolic) 方法来保证提供给 AI 的数据是准确的。

“代码解释器”的问题

在深入了解 SATYRN 之前，我们需要了解现状。目前处理 LLM 数据问题的最先进方法是“代码解释器”模式 (OpenAI 等公司使用) 。

在这种模式下，你给 LLM 一个架构和一个问题，LLM 尝试编写 Python 脚本或 SQL 查询来获取答案。虽然令人印象深刻，但这在本质上是 不确定的 (non-deterministic) 。 如果 LLM 幻想出了一个列名、编写了错误的逻辑或未能正确处理连接 (join) ，执行就会失败，或者更糟——执行成功但返回了错误的数字。LLM 既充当分析师又充当作家，但它很少能胜任前者的工作。

SATYRN 提出了一条不同的路径: 将 分析 与 生成 分离。通过使用符号引擎处理数据逻辑，并使用 LLM 处理语言表达，SATYRN 在不牺牲流畅性的情况下实现了显著更高的准确性。

核心方法: SATYRN 架构

SATYRN 平台建立在“神经符号”架构之上。这意味着它结合了神经网络 (LLM) 和符号处理 (硬编码逻辑和结构化查询计划) 。

工作流是一个四步管道，旨在确保 LLM 永远不需要猜测数字。它只能看到经过验证的事实。

SATYRN 及其分析增强生成的高层方法。

如上图 1 所示，该过程在进行任何语言生成之前，会从用户的请求流入一个严格的分析管道。让我们分解一下使其工作的四个关键组件。

1. 环 (The Ring) : 让数据为 LLM 做好准备

原始数据库架构通常很混乱。像 col_x_99 这样的列名对 LLM 来说毫无意义，而且仅仅知道某列是“整数”并不能说明它代表的是美元、年份还是 ID 号码。

SATYRN 将数据库包裹在一个称为 环 (Ring) 的语义层中。环定义了:

  • 实体 (Entities) : 现实世界的对象 (例如，“野火”、“州”) 。
  • 属性 (Attributes) : 具有语义类型的属性 (例如，区分像英亩数这样的“度量 (Metric) ”和像 ID 这样的“标识符 (Identifier) ”) 。
  • 关系 (Relationships) : 表之间预定义的连接。

定义了两个实体 (州和野火) 的 SATYRN 环示例。

通过使用环 (图 2) ，SATYRN 抽象掉了底层数据库的复杂性。系统不需要在运行时弄清楚 SQL 连接；它们被编码在环中。这使得系统可以与领域无关——无论数据是关于野火、法庭案件还是城市住房，逻辑都保持不变。

2. SQR: 分析的语言

如果不让 LLM 编写 SQL，我们要如何查询数据？研究人员开发了一种新的中间语言，称为 结构化问题表示 (Structured Question Representation, SQR) 。

SQR 是一个有向无环图 (DAG) ，其中每个节点代表一个原子操作——如 retrieve (检索) 、filter (过滤) 、groupby (分组) 或 average (求平均) 。

用于确定 2020 年每个州平均野火规模的 SQR 计划，包含文本和图形形式。

在图 3 中，你可以看到关于“平均野火规模”的问题是如何被分解为逻辑步骤的。与作为声明式文本块的 SQL 不同，SQR 是可组合的。系统可以提取小的 SQR 片段 (模板) 并将它们拼接在一起，构建复杂的查询而不会出现语法错误。

3. 报告蓝图 (Report Blueprints)

用户很少只想要一个数字；他们想要一份报告。SATYRN 使用 报告蓝图 来定义标准的分析工作流。蓝图就像一个配方。例如，“排名报告”蓝图知道要对实体进行排名，它需要:

  1. 计算目标实体的度量指标。
  2. 统计实体总数。
  3. 找到目标的排名。
  4. 确定用于比较的前 3 名实体。

按平均野火规模将加利福尼亚州与其他州进行排名的报告蓝图实例化。

图 4 展示了用户的请求 (目标: 加利福尼亚，度量: 野火规模) 是如何映射到蓝图上的。系统不会“猜测”哪些信息是相关的。蓝图确定性地规定了必须执行哪些 SQR 计划才能生成一份综合报告。

4. SQR 组合器与分析引擎

奇迹发生在 SQR 组合器 (SQR Composer) 中。它从蓝图中获取抽象需求，在环中查找特定的数据路径，并将它们组装成可执行的计划。

该图展示了 SATYRN 用于生成一组可执行 SQR 计划以获取报告所需信息的过程。

一旦组合完成 (图 8) , 分析引擎 将 SQR 计划转换为数据库的原生查询语言 (如 SQL) 并执行它。

关键在于，该引擎的输出 不是 原始数据表。它将数据行转换为 自然语言陈述 。

例如，SATYRN 不会将一行数据 [Oregon, 4, 280] 传递给 LLM，而是生成文本: *“Oregon is ranked 4 according to median fire size.” (俄勒冈州按野火规模中位数排名第 4。) * 和 *“The median fire size for Oregon is 280.00 acres.” (俄勒冈州的野火规模中位数为 280.00 英亩。) *

针对同一排名蓝图在三个领域生成的基于事实的陈述。

如图 10 所示，这些陈述充当了 LLM 的“上下文”。LLM 实际上是被告知: “这是一份真实事实的清单。把它们重写成一份流畅的报告。”这极大地降低了模型的认知负荷。它不需要计算；它只需要沟通。

实验与结果

为了测试 SATYRN，研究人员在 8 个不同的领域 (包括医疗保健、刑事司法和环境可持续性) 生成了 200 份报告。他们将 SATYRN 与以下方法进行了比较:

  1. 未增强的 GPT-4 (Unaugmented GPT-4) : 要求 GPT-4 在没有数据访问权限的情况下编写报告。
  2. 代码解释器 (Code Interpreter, GPT-4) : 给 GPT-4 数据文件，让它编写自己的代码。
  3. SATYRN (消融实验) : 使用 SATYRN，但向 LLM 传递 表格 而不是文本陈述。

他们从 准确性 (Accuracy) (数字是否正确？) 、流畅性 (Fluency) (读起来通顺吗？) 和 连贯性 (Coherence) 三个方面评估了报告。

准确性差距

结果令人震惊。SATYRN 在事实准确性方面明显优于基线。

被归类为事实的声明比例，而非虚构或被反驳的。

如图 5 所示，无论使用 GPT-4 还是较小的开源模型 Mistral-7B , SATYRN (最右侧的三个柱状图) 都达到了大约 86% 的准确率 。

与之相比, 代码解释器 (左数第二组) 仅达到了 57% 的准确率 。 代码解释器经常失败，因为它编写了错误的 Python pandas 逻辑或误解了数据结构。

错误类型

查看模型 如何 失败也很有启发性。

被归类为事实、虚构或被反驳的声明比例。

图 6 分解了错误类型:

  • 虚构 (Confabulated，橙色) : 模型捏造了事实。未增强的 GPT-4 (最左侧) 经常这样做，这是意料之中的。
  • 被反驳 (Refuted，红色) : 模型拥有数据但得出了错误的答案。代码解释器有大量的“被反驳”率。它试图计算答案但失败了。

SATYRN (最右侧) 将红色和橙色条都降到了最低。

小模型的力量

这篇论文中最有趣的发现可能隐藏在消融实验中。当研究人员以 表格 形式提供数据 (SATYRN-Table) 时，小模型 (Mistral-7B) 表现挣扎，仅达到 55% 的准确率。但当数据被转换为 自然语言陈述 (完整的 SATYRN 方法) 时，Mistral-7B 的准确率跃升至 89% , 与 GPT-4 不相上下。

这表明，如果数据被预处理成清晰的陈述性语句，那么高质量的报告并不一定需要昂贵的大型模型。

所有领域中每种配置的平均声明数量。

最后，图 7 显示 SATYRN 不仅准确，而且高效。它生成了大量可验证的声明 (右侧的灰色和蓝色柱状图) ，而未增强的模型往往含糊其辞，生成的具体声明较少。

结论与启示

SATYRN 代表了我们对“数据 AI”思考方式的转变。SATYRN 不依赖 LLM 成为编写查询、执行代码和起草文本的“万事通”，而是主张专业化。

通过使用符号引擎 (SQR 和环) 处理数据库的严格逻辑，并使用 LLM 处理语言的流动性，我们获得了两全其美的结果。该系统具有以下特点:

  1. 确定性: 分析计划由规则生成，而非概率。
  2. 模型无关: 它在本地开源模型上的效果与在 GPT-4 上一样好。
  3. 准确性: 与代码解释器相比，它大幅减少了幻觉和计算错误。

对于关注 RAG 未来的学生和开发者来说，教训很清楚: 当涉及到结构化数据时，不要仅仅检索——要去分析。而且永远不要让 LLM 去做数据库的工作。