Pneuma-Seeker: A Relational Reification Mechanism to Align AI Agents with Human Work over Relational Data

本文介绍了 Pneuma-Seeker 系统，该系统通过“关系具体化”机制将用户模糊的信息需求迭代转化为共享的关系模式，并利用 LLM 智能体架构在异构数据上发现源数据并生成可执行程序，从而有效解决了大模型在处理未明确定义意图时的脆弱性问题，显著提升了答案准确性与系统的可解释性。

要点

这篇文章介绍了一个名为 Pneuma-Seeker（可以想象成“寻气者”或“数据侦探”）的智能系统。它的核心任务是帮助那些面对海量数据却不知如何下手的人，把模糊的想法变成精准的答案。

为了让你轻松理解，我们可以把整个数据工作过程想象成**“在一家巨大的、混乱的图书馆里找书并写出一篇报告”**。

1. 痛点：模糊的指令 vs. 混乱的图书馆

现状：
想象你是一位老板，你想让助手去图书馆（数据库）找点资料，写个报告。

• 你的想法（信息需求）： “我想看看咱们公司最近有没有什么‘麻烦事’，比如那些容易出问题的危险品。”
• 助手的困境： 这是一个模糊的指令。
  • 什么是“麻烦事”？是发货晚了？发票错了？还是客户投诉了？
  • 什么是“危险品”？是化学的？还是放射性的？
  • 图书馆里有几百万本书（数据表），分散在不同的房间（不同的系统），有的书甚至没有目录。

传统 AI 的问题：
现在的普通 AI（大语言模型）就像是一个**“过度自信的实习生”**。

• 你问它，它马上就会编造一个答案。
• 它可能会自己瞎猜：“哦，‘麻烦事’肯定是指‘发货延迟’，‘危险品’就是‘化学品’。”
• 然后它直接给你写个报告。结果你发现它编造了数据，或者找错了书。这就是所谓的“幻觉”。

2. 核心创新：把“想法”变成“蓝图” (Relational Reification)

Pneuma-Seeker 的聪明之处在于，它不直接给你答案，而是先和你一起画一张**“寻宝蓝图”**（也就是论文里说的“关系模式”或 Schema）。

比喻：从“口头描述”到“施工图纸”

• 普通 AI： 你问“怎么做蛋糕？”，它直接给你端上来一个可能是烧焦的蛋糕。
• Pneuma-Seeker： 你问“怎么做蛋糕？”，它先拿出一张图纸给你看：
  • “老板，根据您的意思，我们需要‘面粉’（数据 A）、‘鸡蛋’（数据 B）和‘糖’（数据 C）。我们要把它们混合（连接），然后烤（计算）。”
  • 关键点： 这张图纸是具体的、可检查的。
  • 你一看图纸说：“不对！‘面粉’太宽泛了，我要的是‘低筋面粉’（具体数据列）；还有，‘糖’不能加太多，要换成‘代糖’（修改条件）。”
  • 于是，你们在图纸上修改。直到图纸完美了，系统才去执行。

这样做的好处：

1. 不再猜谜： 系统不再瞎猜你的意图，而是通过修改图纸来确认。
2. 透明可信： 你可以看到它是怎么把“危险品”定义出来的，而不是只听它说“我查过了”。
3. 迭代修正： 就像改图纸一样，你可以一步步把模糊的想法变得精准。

3. 系统架构：一个高效的“施工队”

为了画好这张蓝图并执行，Pneuma-Seeker 组建了一个**“智能施工队”**，而不是让一个人干所有活。

• 指挥家 (Conductor)：
  • 就像乐队的指挥。它负责听你的需求，然后指挥大家画图纸、找材料。它不直接去搬砖，而是做计划。
• 材料员 (Retriever)：
  • 负责去图书馆（数据库）里找书。它很聪明，不仅看书名，还会看书里的具体内容（比如搜索“放射性”这个词是否出现在某本书的某一行）。
• 施工员 (Materializer)：
  • 负责把找到的书（数据）按照图纸（蓝图）拼在一起。它擅长用标准的工具（比如“把这两本书的某一页粘在一起”），而不是乱写代码。
• 微操助手 (Micro Context Management)：
  • 这是最厉害的一点。当书太厚（数据太多）时，指挥家不会把整本书塞给施工员（因为读不完）。
  • 它会说：“施工员，你先翻到第 50 页，看看有没有‘2024 年’这个字？”
  • 施工员去翻一下，告诉指挥家：“有，而且这一页的数据分布是这样的。”
  • 指挥家根据这个具体的证据，再决定下一步怎么画图纸。这避免了“盲人摸象”。

4. 为什么它更靠谱？(可解释性与信任)

在传统的 AI 回答中，你只能看到结果：“是的，危险品导致了很多麻烦。”
在 Pneuma-Seeker 中，你可以看到**“证据链”**：

• “我定义了‘危险品’是‘放射性’和‘有毒’两类。”
• “我找到了 3 张表，把它们拼在了一起。”
• “我排除了那些数据缺失的行。”
• “最后算出结果是 X。”

这就像法官判案，不仅给判决，还给出了判决书和证据链。这让企业敢放心地使用它，因为如果结果不对，你可以顺着图纸和证据链找到是哪一步出了问题。

5. 总结：它到底解决了什么？

• 以前： 用户想问问题 -> 系统瞎猜 -> 给出一个可能错误的答案 -> 用户发现不对 -> 重新问 -> 循环往复，效率极低。
• 现在 (Pneuma-Seeker)： 用户想问问题 -> 系统画出“数据蓝图” -> 用户检查并修改蓝图 -> 系统按蓝图精准执行 -> 给出可信的答案。

一句话概括：
Pneuma-Seeker 不是一个只会“拍脑袋”给答案的 AI，而是一个擅长把模糊想法变成具体施工图纸，并带着你一步步确认、最终精准交付数据的“数据建筑师”。它让数据工作从“猜谜游戏”变成了“可验证的工程”。

技术摘要

Pneuma-Seeker 技术总结：面向智能体数据发现与准备的“关系实体化”

1. 研究背景与问题定义

1.1 核心痛点

在组织决策中，数据工作者（分析师、工程师等）经常面临信息需求模糊（Under-specified）的问题。用户往往无法精确描述其所需的数据模型，导致传统的数据发现（Data Discovery）和准备（Data Preparation）流程受阻。

• 现有 LLM 的局限性：虽然大语言模型（LLM）能理解自然语言，但在意图不明确时表现脆弱（Brittle）。它们容易产生幻觉（Hallucination），如虚构字段、错误假设连接路径（Join Paths）或生成无依据的答案。
• 工作流瓶颈：数据工作通常包含两个难以自动化的阶段：
  1. 数据发现：识别并检索满足需求的文档/表。
  2. 数据准备：将文档转换为下游分析可用的形式。
     这两个阶段高度依赖人工迭代、跨团队沟通和领域知识，耗时且昂贵。

1.2 问题陈述

给定一组表格集合 $C$ 和一个潜在的精确信息需求 $I^*$（用户最终想要的数据），目标是构建一个文档 $D$ 以满足 $I^*$。然而，用户最初只能表达一个模糊的活跃需求 $I^+$。现有系统难以在 $I^+$ 向 $I^*$ 收敛的过程中，自动完成从模糊意图到精确数据模型的转化，同时保证结果的可解释性和准确性。

2. 核心方法论：关系实体化 (Relational Reification)

Pneuma-Seeker 的核心创新在于提出关系实体化（Relational Reification）机制。

2.1 核心理念

系统不直接回答用户的自然语言问题，而是将用户不断演变的模糊需求 $I^+$ 实体化为一个显式的关系模式（Relational Schema），记为 $(T, S)$：

• $T$ (目标视图集)：一组派生视图（Tables），包含属性、类型和语义，代表分析就绪的数据模型。
• $S$ (可执行变换)：定义如何从 $T$ 计算出最终答案的变换逻辑（如 SQL 查询或 Python 代码）。

2.2 交互流程

1. 提案与迭代：系统首先根据 $I^+$ 提出一个初始的 $(T, S)$。
2. 用户反馈：用户检查 $T$ 的 Schema 和样本数据，发现逻辑偏差（例如：“危险品”定义太宽，需细化为“放射性物质”），并反馈修正。
3. 收敛：通过多轮迭代，$(T, S)$ 逐渐逼近真实的 $I^*$。
4. 执行：一旦 $(T, S)$ 确定，系统自动发现相关数据源，物化 $T$，并执行 $S$ 生成最终答案 $D$。

2.3 优势

• 对用户：提供了一个可检查、可修改的具体对象（Schema），降低了描述意图的认知负担，使隐式假设显性化。
• 对系统：将模糊的自然语言转化为结构化的数据操作任务，限制了 LLM 的搜索空间，减少了幻觉，并提供了可追溯的数据血缘（Provenance）。

3. 系统架构设计

Pneuma-Seeker 是一个基于 LLM 的智能体（Agentic）系统，采用指挥者（Conductor）- 执行者架构，并引入了宏观和微观两种上下文管理策略。

3.1 核心组件

1. Conductor (指挥者)：
   • 作为规划器和协调器，负责将 $I^+$ 转化为 $(T, S)$。
   • 维护动态规划循环，根据当前状态决定下一步行动（如检索、上下文提取、修改 Schema、执行等）。
   • 负责与用户交互，解释中间结果。
2. Materializer (物化器)：
   • 负责根据 $(T, S)$ 中的规范，利用检索到的表构建中间表 $T$。
   • 优先使用结构化算子（连接、并集、投影）而非自由代码生成，以提高可靠性。
   • 记录所有变换过程，生成有向无环图（DAG）作为血缘图。
3. Retriever (检索器)：
   • 基于 Pneuma 系统，结合语义检索和基于内容的检索（Content-aware search）。
   • 支持正则表达式枚举（如 water_body_testing_\d{4}），解决相似表名但年份/地点不同的问题，提高召回率。
4. DBService & LMService：
   • 提供持久化存储（DuckDB）和 LLM/Embedding 模型接口。

3.2 关键策略：上下文管理

• 宏观上下文管理 (Macro Context Management)：
  • 将工作流分解为 Conductor、Materializer、Retriever 等独立组件，每个组件只处理特定任务，避免将所有数据塞入单一 Prompt 导致的上下文窗口溢出和性能下降。
• 微观上下文管理 (Micro Context Management)：
  • 核心创新：允许 LLM 主动通过执行 Python 脚本（调用 DBService API）来“探测”表内容，而不是被动接收样本数据。
  • 作用：当 LLM 对表结构或数据分布不确定时（例如：某列是离散值还是连续区间？），它可以主动查询特定值是否存在、统计分布等。这解决了仅靠少量采样行导致推理错误的问题。

4. 主要贡献

1. 信息需求的关系实体化：首次将用户演变的模糊需求形式化为 $(T, S)$ 对，作为人机协作的中间工件，实现了从“问答”到“规范协商”的转变。
2. 分层上下文管理技术：
   • 提出了微观上下文管理策略，赋予 LLM 主动查询和探测数据的能力，显著提升了在复杂、非结构化表格上的推理准确性。
   • 结合宏观任务分解，有效解决了大规模异构数据下的上下文限制问题。
3. Pneuma-Seeker 系统实现：构建了一个支持可解释性、血缘追踪和迭代修正的端到端智能体系统。
4. 实证评估与部署洞察：
   • 在 KramaBench 基准测试中证明了其优越性。
   • 在芝加哥大学的真实采购场景部署中，验证了“可解释性”和“可审查性”对于建立用户对 LLM 数据系统的信任至关重要。

5. 实验结果

5.1 回答质量 (Answer Quality)

• 基准测试：在 KramaBench（包含考古、天文、生物医学、法律等 6 个领域的多表数据集）上，Pneuma-Seeker 的回答准确率显著优于基线系统（DS-Guru 和 smolagents）。
  • 例如在生物医学数据集上，准确率达到 94.44%，比 DS-Guru 高出 27.77 个百分点。
• 消融实验：
  • 移除微观上下文管理（Context Extraction）会导致准确率大幅下降，特别是在需要细粒度数据验证的查询中（如法律数据集的欺诈金额分布）。
  • 移除关系实体化（即不构建 $(T, S)$ 直接生成答案）也会导致准确率下降，因为缺乏中间规范引导会导致数据覆盖不全（如遗漏某些州的表格）。

5.2 成本与可扩展性

• Token 消耗：Pneuma-Seeker 的 Token 使用量与 smolagents 相当，略高于 DS-Guru，但考虑到其更高的准确率，性价比（Pareto 前沿）更优。
• 内存与运行时：
  • 内存：得益于数据库后端执行（Database-backed execution）和仅加载样本行，Pneuma-Seeker 的内存占用极低（在 1GB 数据规模下仅约 135MB），远低于将全量数据加载到内存的 DS-Guru（>4GB）。
  • 时间：虽然由于结构化处理增加了部分运行时间，但其非 LLM 处理时间极短，且随着数据量增加，性能下降趋势平缓，展现了良好的可扩展性。

5.3 检索召回率

• Pneuma-Seeker 的检索器（Pneuma-Retriever）通过结合语义搜索和基于正则的表枚举，在复杂场景下（如需要检索 100+ 个相似表）实现了 94%-100% 的召回率，显著优于传统的 Top-K 检索器。

6. 意义与结论

Pneuma-Seeker 证明了关系实体化是构建可信、可解释的 LLM 驱动数据系统的有效范式。

• 信任机制：通过将黑盒的 LLM 推理过程转化为白盒的 Schema 和代码生成过程，用户可以在执行前审查数据模型和转换逻辑，从而建立信任。
• 人机协作新范式：系统不再试图一次性“猜对”答案，而是作为催化剂，帮助用户将模糊的意图逐步收敛为精确的数据规范，同时自动处理繁琐的数据发现和准备任务。
• 未来方向：该工作为未来的智能数据系统提供了设计原则：即通过显式的中间表示（Intermediate Representations）来解耦意图理解与数据执行，并利用主动式上下文管理来克服 LLM 的幻觉和上下文限制。

总结：Pneuma-Seeker 不仅仅是一个问答工具，它是一个意图协商与数据准备平台，通过“关系实体化”解决了数据工作中“意图模糊”与“执行精确”之间的矛盾，为大规模、异构环境下的智能数据分析提供了新的解决方案。