从过载到洞见：AI代理如何支持科学家分析复杂数据

# 从超载到洞见：AI Agent 如何助力科学家分析复杂数据
来源：https://arxiv.org/html/2607.16845
###### 摘要

欧洲 XFEL 的科学家开展的实验会产生规模极大且极其复杂的数据集。随后的数据分析工作颇具挑战，因为科学家们必须将自身的领域专业知识与分散在文档、工具和支持渠道中的设施及软件特定知识结合起来。为解决这一问题，我们设计并评估了一个针对科学家需求量身定制、并与欧洲 XFEL 高性能计算环境集成的代理式人工智能（AI）系统。采用设计科学研究方法，我们进行了快速文献综述、对 16 种 AI 工具的系统评估、多次访谈、一次焦点小组讨论以及一项针对欧洲 XFEL 专家的用户研究，以开发并评估两个原型。我们的研究识别出科学数据分析中的关键知识挑战，推导出支持知识检索和源代码生成的 AI Agent 的需求，并提出了一个适用于不断演变的 AI 工具环境的专业化系统的设计建议。这些发现为在高度专业化的科学环境中开发可维护的 AI 支持提供了指导。

## I. 引言

欧洲 XFEL 是一个用户设施，访问科学家（用户）利用独特类型的 X 射线脉冲在多台复杂仪器上研究物质 [decking_mhz-repetition-rate_2020]。这些用户拥有深厚的领域专业知识，但他们在应对设施特定的分析环境以及将实验数据转化为科学发现时，常常需要帮助。

这些实验产生的数据集规模极大且极其复杂，有些可达 PB 级 [malka_data_2023, sobolev_data_2024]。为了将这些数据转化为科学成果，用户需要强大的计算资源和与实验背景匹配的临时数据分析软件。与类似设施一样，欧洲 XFEL 通过一个高性能计算（HPC）集群、专门的软件以及由具备光子科学、数据科学和软件工程专业知识的员工提供的用户支持来实现这一过程。

用户支持散布在广泛的文档和直接协助中，这使得它既强大又全面。然而，这种支持的可扩展性不佳，因为直接协助的水平受限于可用的人力资源，而静态的文档又缺乏针对广泛具体分析任务所需的上下文指导。这些局限性因用户数据分析经验和需求的多样性而进一步放大，尤其是在离线数据分析可能跨越数据收集后的数月时间时 [schmidt_turning_2024]。

为改善现状，用户需要一个对上下文敏感、始终可用的系统，来弥合通用知识资源与个人工作流程之间的差距 [maalej_task-first_2009]。基于 AI 的支持系统可以通过将现有的大量文档转化为情境化的协助来缩小这一差距。检索增强生成（RAG）是一个特别相关的概念，因为它能帮助助手将回答建立在经过整理的知识上，并减少幻觉 [james_retrieval-augmented_2025]。AI Agent 通过不仅回答问题，还能规划和执行任务（包括代码生成）来扩展这种支持 [sapkota_ai_2026]。然而，对于科学工作流程而言，只有当系统行为保持可追溯、可控且与人类监督兼容时，Agent 才是有用的 [tang_risks_2025]。

在这项工作中，我们设计并评估了一个针对欧洲 XFEL 离线数据分析的代理式 AI 系统。该系统旨在帮助用户检索文档和生成分析代码，同时与 HPC 集群集成。我们的目标是提供一个功能强大、始终可用且对上下文敏感的助手，以增强设施的知识资源 [maalej_task-first_2009, maalej_lightweight_2008]。

我们遵循了包含七项活动的设计科学研究（DSR）方法来回答以下研究问题：

RQ1：设施用户和成员在离线数据分析过程中遇到哪些知识挑战？

RQ2：代理式 AI 系统必须满足哪些要求才能应对这些挑战？

RQ3：从实践中部署和评估该系统，可以得出哪些关于有效且可维护的 AI 支持的设计建议？

本文的其余部分介绍了研究方法与发现、讨论、局限性以及相关工作。

## II. 设计科学研究方法

### II-A 概述

表 I：研究活动与 Peffers 等人 [peffers_design_2007] 的研究问题及设计科学研究方法对照
| 编号 | 活动 | PI | OS | DD | DE | EV | 研究问题 |
|------|------|----|----|----|----|----|----------|
| 1 | 与 2 位管理者进行访谈，讨论研究范围及初始工具概念。 | X | X | | | | RQ1, RQ2 |
| 2 | 与 16 名数据分析组成员进行焦点小组讨论，分析离线数据分析的工作流程与挑战。 | X | | | | | RQ1 |
| 3 | 对 3 名设施用户和 5 名成员进行访谈，分析离线数据分析的挑战及对 AI Agent 的需求。向 13 名数据分析组成员汇报。 | X | X | | | | RQ1, RQ2 |
| 4 | 第一个原型的设计/演示。与 12 名数据分析组成员进行评估。需求重新评估。 | | | X | X | X | RQ1, RQ2, RQ3 |
| 5 | 对 224 篇文章进行快速多声部综述，将相关研究的见解整合到需求中。 | | X | | | | RQ2 |
| 6 | 对代理式 AI 系统组件的解决方案进行评估。需求重新评估。 | | X | | | | RQ2 |
| 7 | 第二个原型的设计/演示。与 13 名专家进行评估。迭代式原型改进。 | | | X | X | X | RQ1, RQ2, RQ3 |

PI = 问题识别与动机，OS = 解决方案目标定义，DD = 设计与开发，DE = 演示，EV = 评估，步骤 6 = 沟通（未在上文列出；我们通过本文传达我们的发现）

DSR 适用于这项探索性研究，因为它专注于为组织问题设计和评估 IT 工件 [peffers_design_2007]。本研究通过问题识别、需求工程、工具设计和评估的迭代循环进行。DSR 使这些活动的方法论逻辑得以明确 [engstrom_how_2020]。

表 I (https://arxiv.org/html/2607.16845#S2.T1) 将我们的研究活动映射到 Peffers 等人 [peffers_design_2007] 的六个 DSR 步骤以及我们的研究问题。我们进行了七项活动，每项活动至少对应一个 DSR 步骤。过程是迭代的：从第一个原型中获得的见解为第二个原型的需求分析、设计和评估提供了信息（图 2 (https://arxiv.org/html/2607.16845#S2.F2)）。以下小节按时间顺序描述这些活动。支持材料，如访谈记录、详细的软件评估工件以及原型设置，可在复制包中获取 [fuchs_reppack_2026]。

### II-B 与管理者的初始访谈

第一作者于 2025 年 6 月至 12 月期间与欧洲 XFEL 数据分析组和控制组的两位管理者进行了五次半结构化访谈。目标是迭代地界定离线数据分析中的挑战范围，并确定解决方案的初始设计目标。我们选择这两位管理者作为这项探索性首次活动的参与者，因为他们的职位使其贴近数据分析的软件、基础设施和用户支持，以及该设施的 AI 倡议。

访谈显示，用户的支持请求集中在三个阶段：实验准备的早期阶段、实验执行阶段（包括在线/实时数据分析），以及离线数据分析的后期阶段。在所有阶段，用户都必须将他们的科学领域专业知识与关于数据格式、仪器设置和 HPC 环境的设施特定知识结合起来。管理者还强调，该设施现有的软件手册虽然全面，但可能过于宽泛，无法有效指导具体的分析任务。这就是为什么数据分析组最近开始转向更面向实验和技术的文档 [euxfel_fxe_2026]。

当讨论转向解决方案目标时，管理者一致认为需要在离线数据分析期间提供一线支持。他们认为一个能够检索相关文档、提供量身定制的 Jupyter notebook 模板、帮助用户导航复杂数据集、为 HPC 环境优化分析代码，并向工作人员报告 Agent 对话以提高可追溯性的系统具有价值。这些能力被认为在正常工作支持时间之外尤其相关，此时用户仍需要指导，但工作人员可用性有限。

访谈还留下了一个重要的设计问题未解决：系统是否应该主要支持初学者、有经验的用户，或者两者都支持？因此，我们将这些初始访谈视为范围界定活动，并利用结果来指导后续与设施用户和成员的焦点小组及访谈，在这些活动中我们细化了需求并缩小了原型设计范围。

### II-C 与数据分析组的焦点小组

我们的焦点小组目标是描述欧洲 XFEL 目前的离线数据分析工作流程，并识别此过程中的知识相关挑战。我们选择焦点小组是因为参与者共享相同领域，可以互相借鉴经验 [kontio_focus_2008]。这个 60 分钟的会议于 2026 年 1 月举行，汇集了数据分析组的 16 名成员，并由第一作者主持。我们使用数字思维导图透明地记录笔记 [luke_improving_2014]，并在会议后将思维导图分享给参与者以支持成员检查 [burgessallen_using_2010]。

讨论表明，离线数据分析在不同科学仪器和实验之间差异很大，但仍然遵循一个重复出现的模式。广义上讲，工作从数据采集和数据传输到 HPC 环境的离线存储开始，然后是实际的数据分析，最后得出科学发现。在这些步骤中，用户检查实验日志 [maia_mylog_2025, maia_mymdc_2025]，与工作人员交流，设置分析环境，并根据模板、库和其他与实验相关的软件开发分析脚本。一个典型的设置包括 HPC 集群上的 JupyterLab 服务器 [reppin_interactive_2021]，一个包含数据分析组准备的多个库的软件模块，以及用户提供的其他软件。

第二个发现是，相关知识分散在许多来源中。参与者提到了数据分析组的一般用户文档、库文档、仪器特定资源、技术报告、出版物（例如，turkot_extra-xwiz_2023），实验提案以及 HPC 集群的文档。他们强调，主要挑战不在于这些不同资源的存在，而在于需要将它们组合成一个针对具体分析目标的工作流程。正是在这一点上，AI 系统可以通过检索和综合相关文档，而不仅仅是列出它们，来增加显著价值 [james_retrieval-augmented_2025]。

表 II：(RQ1) 欧洲 XFEL 离线数据分析中的挑战
| 编号 | 挑战 |
|------|------|
| 用户： | |
| 1 | 数据分析目标的清晰度 |
| 2 | 预期与实际数据分析复杂度之间的不匹配 |
| 3 | 离线数据分析阶段有限的设施支持 |
| 4 | 对基础设施复杂性的不熟悉 |
| 5 | 对高性能计算的不熟悉 |
| 6 | 对仪器数据分析程序的不熟悉 |
| 7 | 分散文档的检索与综合 |
| 数据分析组成员： | |
| 8 | 对仪器数据分析程序的不熟悉 |
| 9 | 分散文档的检索与综合 |
| 10 | 对用户分析目标的理解 |
| 11 | 用户支持的时间投入 |
| 专职科学家： | |
| 12 | 对用户分析目标的理解 |
| 13 | 用户支持的时间投入 |

总体而言，焦点小组揭示了 13 个重叠的挑战集，总结在表 II (https://arxiv.org/html/2607.16845#S2.T2) 中。用户可能难以具体化他们的分析目标和步骤，理解基础设施、HPC 环境和分析程序，以及综合分散的文档。数据分析组成员面临相同的文档挑战，但他们还需要推断用户的分析目标，并花时间支持他们。专职科学家经历类似的支持负担，尤其是在目标不明确时。

这些发现确定了与第一个研究问题相关的问题空间，并为随后与设施用户和成员的访谈提供了信息，在这些访谈中我们细化了挑战集并将其转化为需求。

### II-D 对设施用户和成员的访谈

我们在 2026 年 1 月举行的年度欧洲 XFEL 和 DESY 用户会议的海报环节中进行了非正式访谈。我们的目标是获取有关离线数据分析中知识挑战的第一手经验，并探索对 AI 助手的期望。第一作者与三位设施用户和五位成员（包括四位专职科学家和一位管理者）进行了交谈。所有参与者都有离线数据分析和使用可用用户支持的经验。尽管参与人数有限，但访谈记录以及随后与数据分析组 13 名成员的汇报帮助细化了关于问题识别和解决方案目标的见解。

两位成员强调，专职科学家和用户非常重视数据分析组的所有支持。然而，一位用户指出阅读文档很繁琐。这一评论强化了检索和综合分散文档以形成可用工作流程的挑战，这一点在早期的焦点小组中已经确定。

当讨论转向数据分析 AI 助手可能的功能时，受访者最为投入。他们认为最有价值的功能是支持关于设施软件和基础设施的技术问题、绘制复杂数据以及为 HPC 执行优化代码。他们还强调，系统不得将数据发送给第三方。更多可选的功能建议包括使生成代码的风格适应个人喜好，以及提供实验日志的每日摘要。最后，在汇报期间，数据分析组确定了一个由于 AI 辅助而产生的新风险：如果用户开始报告 AI 生成代码的问题，代理式系统可能会增加对人类支持的需求。

这些访谈通过添加用户和专职科学家的观点拓宽了我们的分析。他们确认了数据分析组提到的挑战，并提供了第一个原型的设计目标，我们接下来设计了该原型。

### II-E 第一个原型的设计、演示与评估

我们于 2026 年 3 月上旬设计并评估了第一个原型，作为离线数据分析期间一线用户支持的概念验证。为了使原型与典型的分析设置保持一致，我们选择了 Jupyter AI 作为用户界面，它直接集成到 Jupyter Lab 中。该原型使用了 Jupyter AI 的内置聊天人格，并连接到一个由欧洲 XFEL 内部开发的 RAG 后端。这种架构使得回答能够完全基于经过整理的文档。

我们将该系统部署在一台本地计算机上，并将 Jupyter Lab 连接到由 HPC 集群暴露的远程 Jupyter 内核。这种配置使 AI Agent 能够访问数据，