WINSYN: An Automated Pipeline for RealisticEnterprise Question-Answering Evaluation——面向真实企业问答评估的自动化流

《WINSYN: An Automated Pipeline for Realistic Enterprise Question-Answering Evaluation》主要研究如何自动生成逼真的企业问答评估数据集，以解决现有基准测试在真实企业场景中复杂度不足的问题。以下是其核心研究内容的全面总结：

一、研究背景与问题

企业问答（Enterprise QA）与传统的文档问答有本质区别：答案往往不包含在任何单一文件中，而是分散在邮件、聊天、文档、工单等不断演变且可能相互冲突的工件中。要回答一个查询，系统必须从碎片化、分布式、有时矛盾的证据中重建组织状态。

然而，真实企业语料库因涉及隐私和合规问题很少公开，现有合成基准又存在明显局限：

• 一些依赖人工模板，难以适应新领域；

• 一些数据静态、非冲突，核心挑战只是多源事实检索，而非时间推理；

• 查询类型单一，答案多为短式，缺乏真实工作场景的复杂性。

二、核心贡献：WINSYN 流水线

作者提出了WINSYN（Workplace Interaction Synthesis），一种自顶向下、多阶段的自动化流水线，从紧凑的种子文档生成完整的企业问答数据集。

关键设计思想

1. 分层扩展，保持全局一致性：不采用端到端智能体模拟（容易失控），而是先将种子文档扩展为公司背景、员工、史诗（Epic）、任务依赖图（DAG）、每日日记，再生成邮件和问答对。

2. 隐藏脚手架与评估证据分离：流水线内部使用结构化中间表示来维护时间和因果一致性，但被评估的系统只能看到最终的邮件工件。这确保基准测试的是系统从碎片化证据中恢复结构的能力，而非依赖生成时的特权信息。

3. 金标准答案先冻结，邮件后生成：QA 在邮件生成之前就基于每日日记确定，邮件只添加不改变答案的细节。这解决了“如何保证金标准答案正确”的循环性问题。

流水线主要阶段

质量保障机制

• 接地式构建：每个工件都基于前一阶段的工件。

• 验证-反思-精炼循环：每个阶段后运行程序化验证和LLM反思，直至输出合格。

• 条件生成：金标准答案在邮件生成前冻结，邮件仅添加不影响答案的细节。

三、数据集

作者生成了四个企业QA数据集，涵盖不同技术领域：

查询类型覆盖从短式事实查询（如所有权归属、行动项检索）到长式综合查询（如每日简报、项目状态报告），强调多跳推理、跨协作者责任归属、时间推理和分布式信息聚合。

四、实验评估

评估系统

• ReAct Agent：混合BM25+密集检索器，结合ReAct推理-行动循环。

• Onyx Deep Research Agent：沙盒化改编，多周期行动→观察→反思循环。

评估指标

使用LLM-as-a-judge协议，六个主要指标：完整性、可靠性、相关性、忠实性、可读性、检索准确性。最终得分为加权综合：

Final=0.30⋅Comp.+0.30⋅Sound.+0.15⋅Relev.+0.15⋅Faith.+0.10⋅Read

主要发现

1. 整体表现不佳：所有数据集的平均聚合得分均低于80%，表明企业部署仍有显著改进空间。

2. 长式查询比短式查询更难：长式查询（每日简报、项目状态）需要跨多文档综合，两个系统的整体得分均低于2.8，完整性明显降低。

3. 完整性与相关性的权衡：

   • ReAct 倾向于包含更广泛的上下文信息，完整性更高；

   • Onyx 产生更有针对性和简洁的回答，相关性更高。

4. 检索仍是瓶颈：MRR值总体适中，将最相关文档检索到第1位仍然困难。

5. 干扰项增加难度：包含干扰邮件的变体使检索和回答更具挑战性。

五、结论与局限

结论

WINSYN 通过将生成工件接地于简洁的每日活动日志，确保金标准答案可验证、可审计。实证评估表明，即使强大的智能体基线也难以在企业条件下实现高性能，凸显了检索、推理和接地的持续挑战。

局限性

• 当前仅限电子邮件模态；

• 未量化统计真实性（与实际企业数据的分布相似性）；

• 未包含外部交互、公司特定文化或术语；

• 所有查询均可回答，未引入不可回答查询；

• 评估未利用句子级归因来检查接地情况；

• 生成成本随员工、史诗和任务数量近似二次增长，大规模数据集成本高昂。

WINSYN 的核心创新在于用“规划党”而非“裤子党”的方式生成企业数据——先建立全局结构，再逐步填充细节，从而在保持故事连贯性的同时牢牢掌握真相。它通过隐藏脚手架与评估证据分离、QA先冻结后生成邮件等设计，解决了合成企业数据中“如何保证金标准答案正确”的循环性问题。实验证明，当前最强的智能体系统在真实企业问答场景下仍有很大提升空间，为该领域的后续研究提供了严格的测试平台。这里是自己的论文阅读记录，感兴趣的话可以参考一下，如果需要阅读原文的话可以看这里，如下所示：

摘要

企业环境为问答智能体提供了一个充满挑战的场景，这些智能体通常依赖检索增强生成（Retrieval-Augmented Generation, RAG）、深度研究（Deep Research, DR）及相关技术。这一挑战很大程度上源于企业数据的复杂性：信息往往分散在不断演变且可能相互冲突的电子邮件、聊天消息、文档和其他工件之中。现有的基准测试通常只具备有限的真实世界复杂性、简短形式的回答以及不自然的查询，因此往往无法捕捉企业环境的挑战。在本工作中，我们引入了一种自动化流水线，用于生成反映真实工作场景的合成电子邮件数据集，以及基于这些数据的有据可查的长式和短式问题与金标准答案。

我们的方法模拟了跨越数月、涉及多达25名不同角色交互员工的长期企业项目。数据强调歧义性、分布式信息和自然产生的查询。为验证该流水线，我们使用最新的前沿模型在我们的数据集上评估了几个标准的智能体基线。我们发现，每个数据集上所有查询的平均聚合得分均低于80%，表明仍有显著的改进空间。这些发现表明，企业部署仍需更多工作，并凸显了为开发更强的真实世界企业DR系统而构建真实、高复杂度评估数据的重要性。

1 引言

企业问答与标准的基于文档的问答存在根本性差异：答案往往不包含在任何单一工件中。一个项目决策可能在一封电子邮件中被提出，在后续讨论中被修订，在规划文档中被论证，最终反映在工单、发布说明或事后复盘中。在此类场景中，回答查询所需的不仅仅是检索相关段落。系统必须从部分的、分布式的、有时相互冲突的证据中重建不断演变的组织状态。

这使得评估变得困难。真实的企业语料库很少可用于研究，因为它们通常包含私密、专有和合规敏感信息。因此，近期工作越来越依赖合成数据来评估检索增强生成（RAG）、深度搜索和智能体问答系统。然而，生成有用的合成企业数据本身也具有挑战性。真实的工作场所语料库不仅仅是合理文档的集合：它必须保持时间一致性、因果依赖关系、角色特定的沟通模式、隐含的组织背景，以及足够的接地结构，使参考答案可审计。

现有的合成企业基准测试在实现这一目标方面取得了重要进展，但它们往往在真实性、可扩展性、领域灵活性和答案可验证性之间做出权衡。一些流水线依赖手动指定的模板或工作流，这可能限制其对新领域的适应能力；例如，[6, 1]。这些局限性促使我们采用一种能够在保持全局连贯性的同时仍能产生局部工件级细节的生成过程。

我们引入WINSYN（Workplace Interaction Synthesis，工作场所交互合成），这是一种自动化流水线，用于从紧凑的种子场景生成合成企业问答数据集。WINSYN并非端到端地模拟无约束的智能体，而是遵循自顶向下的构建过程。它首先将种子文档扩展为公司背景、员工、项目史诗（Epic）、任务依赖图和每日活动日志。这些中间结构作为模拟工作场所的隐藏真相来源。然后，流水线从该脚手架生成通信工件和有据可查的问答对。

一个关键设计选择是将内部生成脚手架与评估时可用的证据分离。流水线使用结构化中间表示来保持时间和因果一致性，但被评估的系统仅观察最终的企业工件。因此，该基准测试的是系统能否从碎片化的职场证据中恢复相关结构，而不是依赖生成过程中使用的特权表示。

在本文中，我们以电子邮件语料库为例实例化WINSYN，同时将流水线设计为可扩展到其他工作场所模态，如聊天、会议、文档、工单和代码仓库。我们生成了四个跨不同技术领域的企业QA数据集，包括合成种子场景和用作种子的真实公开技术文档。每个数据集包含一个模拟的、涉及二十多名员工的数月工作场所项目，以及基于生成数据的问题、参考答案和引用集。

我们使用检索和答案质量指标在这些数据集上评估了代表性的智能体RAG和DR基线。我们的结果表明，当前系统在这种设置下仍然表现不佳，尤其是当问题需要综合跨越长期项目的证据而非检索孤立事实时。这些发现表明，时间结构化的合成企业数据集可以作为企业搜索和问答系统的有用压力测试。

我们的贡献如下：

我们提出了WINSYN，一种从紧凑种子场景生成时间结构化合成企业QA环境的自动化自顶向下流水线。我们引入了四个生成的企业电子邮件数据集，包含有据可查的问题、参考答案和引用集。我们提供了代表性智能体QA系统在检索、接地和答案质量维度上的评估，突出了当前企业QA系统中持续存在的差距。

组织结构。下一节首先讨论企业数据的相关特性，然后介绍我们的流水线。第3节讨论相关工作，第4节详述我们的实验结果。我们在第5节进行总结。

2 WINSYN：企业数据生成的自动化流水线

在本节中，我们概述流水线的工作原理。我们首先讨论促使我们设计该流水线的企业数据特征。

2.1 企业数据

为了说明我们所说的企业数据，考虑一个二十人的团队在三个月内从事一个项目。团队进行规划、执行、转向和重新执行。这些活动大部分被记录在工件中：电子邮件、聊天消息、文档、会议记录、拉取请求等。这些共同构成了一个（企业数据）数据集。

除了企业数据外，我们的数据集还包含以企业数据为基础的问题和金标准答案（QA）。这些将用于评估和/或训练AI智能体。我们如何保证给定企业数据后金标准答案是正确的？

要回答此类数据集上的复杂查询——为什么做出某个决策、什么导致了某个事件、谁在何时知道什么——必须重建分布在许多工件中的因果链。这些工件随时间演变，可能相互冲突。因此，将它们连接成一幅连贯的图景是一项基本挑战。其他挑战包括判断信息的权威性或时效性，以及驾驭组织的内部术语和文化。

企业数据的结构。真实的企业数据集具有跨越多个尺度和维度的丰富结构，其性质更接近故事或戏剧而非文档集合。

有具有个性、目标和行动的角色；事件引发新事件；存在一个随着行动采取而演变的分布式世界状态。这种因果结构在多个尺度上运作：

微观。客户发送一封关于缺陷的支持电子邮件 → 支持人员在一个Teams频道中标记它 → 开发人员打开一个工单。数据模式并未原生地链接这些工件；重建这些链接正是挑战的一部分。宏观。CEO宣布一个公司范围的目标与关键结果（OKR）→ 各部门启动项目，产生会议和规格说明的轨迹 → 产品发布 → 提交事件报告和复盘。

在这两极之间存在许多中间尺度。季度报告压缩了数月的活动；会议记录实时记录事件。单个决策通常跨越多种工件类型：问题在电子邮件中浮现，选项在会议中辩论，建议被撰写成文，决策被记录在会议纪要中，实施在工单中跟踪。

像故事一样，数据集必须在内部一致且没有情节漏洞；例如，[2]。它具有由人们追求目标而产生的方向性。后来的工件可能与先前的工件矛盾（例如，设计决策在实施工作后被推翻），但这种反转本身必须被记录和解释；它们是一致性的一部分，而不是对一致性的违反。

数据集围绕实体（人员、项目、产品、客户、日期）组织，这些实体的关系在文档中被断言、假设或暗示。贯穿其中的是更柔和的主题：公司文化、正式和非正式社交网络、集体情绪（发现模式和危机模式）。许多这种背景从未被明确表达；工件预设了共享的历史、词汇和关系，读者必须推断。最后，数据集不是封闭的。相关背景存在于数据集之外，在人们的头脑中，在外部文档中，在从未被记录的对话中。

因此，企业数据最好被理解为一个分布式的、多智能体的、时间延伸的话语，而不是文档的集合。

真实性的其他维度。迄今为止的讨论强调了逻辑和因果结构。真实性还有许多其他维度。不可能穷举；我们仅列出一些：

统计真实性。词数分布、句子长度、响应时间模式，以及人物角色、风格、语气和情感的多样性，都必须反映真实的企业沟通。

语用真实性。一封“回复全部”的“听起来不错”承载着隐含的承诺并结束了话题。公司沟通的许多真实内容存在于语用推理中，而非字面内容中。被拒绝的选项、被放弃的话题和未回复的电子邮件在因果上是有意义的——它们标记了未走的路径。

幸存者偏差。并非所有工件都同等存续。电子邮件线索会持续存在；走廊对话则不会。真实的数据集必须考虑这种系统性差距，并模拟短暂沟通在其他工件中留下的痕迹。

2.2 我们的流水线

设计一个能自动构建具有上述丰富结构的企业数据集的流水线，是本文研究的问题。

挑战。构建此类数据集首先想到的方法可能是运行智能体模拟：创建具有人物角色的员工，赋予他们目标，让他们互动以实现这些目标。我们不采用这种方法，因为很难确保这些互动保持连贯、实现目标且不偏离主题。此外，为这样的数据集构建QA会遇到循环性问题：我们如何知道给定问题的金标准答案？除了应对这些挑战外，我们的方法还旨在处理出现的各种其他挑战：保持整个数据集真实且一致、上下文大小限制、微妙的指令遵循失败，以及即使是最好的前沿模型也会出现的幻觉。

为简单起见，本文中我们专注于电子邮件。然而，我们的方法可推广到其他模态，但需要增加更多流水线阶段。如前所述，真实的企业数据具有复杂的结构；我们的流水线在许多方面接近它，但并非全部：我们强调因果结构和一致性，并未明确考虑统计真实性和语用真实性。

多阶段流水线。我们的分层多阶段流水线从一个种子文档开始，该文档是一个简短叙述，总结了数据集所涵盖期间发生的主要事件。该文档可以是公司博客文章、内部通讯、变更日志、季度报告等。它可以是真实世界文档，也可以根据用户的初步输入（公司规模、行业部门、项目、事件等）合成构建。其思想是通过在每个扩展阶段填充更多细节，逐步将此叙述扩展为企业数据。每个生成阶段之后都会运行若干验证检查，包括程序化检查和基于LLM的检查。这种扩展大致遵循上述企业数据的多尺度结构：高层事件和行动首先被合成，然后是它们的低层对应物。事实上，我们对某些阶段使用了类似流行敏捷方法[5]的术语。让我们简要回顾一下它是什么。

敏捷方法是一种流行的迭代式、灵活的项目管理方法，将大型项目分解为小型、可管理的工作块。史诗（Epic）是分解为更小任务（Task）的大型工作体。史诗通常跨越数周到数月，而任务持续一两周。为简单起见，我们使用两个层级，尽管更大的项目可能使用更多层级。我们不是生成独立的史诗，而是构建一个捕获它们之间依赖关系的有向无环图（DAG），并记录交接的工件。类似地，每个史诗被组织为一个任务DAG。我们指出，我们的技术并不绑定于敏捷方法；相反，它依赖于这样一个事实：任何复杂的工作流都必须是分层的，以应对复杂性。

多阶段流水线设计镜像了真实的组织工作流，并确保所有生成的内容在时间、组织和信息维度上保持连贯和一致，因为每个阶段生成的数据都忠实于前一阶段的数据。循环性问题通过保持一个简洁的真相来源得以避免，所有答案都接地于此，如下所述。它还允许我们保持上下文大小较小：由于我们知道数据的分层结构，在生成任何特定信息（例如一个任务）时，我们知道最相关的信息（例如，包含该任务的史诗、相关的其他史诗、前置任务），我们可以在上下文中提供这些信息，而不必提供前一阶段的整个数据集。请注意，在测试时，智能体无法获得这些信息，必须通过电子邮件来理解数据的结构。

现在我们列出数据集创建的步骤：

1. 公司信息。在此步骤中，首先生成公司名称、行业部门、规模，然后是员工、他们在公司中的角色、汇报结构、员工的个人和技术背景。

2. 史诗。我们创建5-10个史诗，以及它们之间的依赖有向无环图（DAG）。每个史诗的生成包括标题、范围描述、分配员工、工作日时间线、史诗间依赖关系（当前史诗开始前需要完成哪些史诗，哪些其他史诗依赖当前史诗；需要接收和交接哪些工件）。（一个史诗示例见图17）

3. 任务。为每个史诗生成5-10个任务及其DAG。每个任务具有与史诗类似的相关信息。参考图18中的示例任务。任务生成后，我们偏离敏捷方法。

4. 每日日记。这些是通过将任务描述扩展为每日活动日志而获得的。对于每个任务及其时间线中的每一天，我们生成一个结构化日记条目，包含工作摘要、每位员工的详细活动、进度说明、阻塞项（含报告人）、解决方案（含解决人）、协作互动（含参与者列表）等字段。

每日日记（如图19所示）构成完整数据集的骨干，并作为简洁的真相来源，QA和电子邮件及其他最终通信工件都接地于此。

1. QA。如前所述，确保数据集中答案确实正确的主要思想是在生成答案时控制上下文大小。这之所以可行，是因为我们知道数据的分层结构。一些示例见图21、22、23和24。

2. 电子邮件。电子邮件（以及其他工件类型，如聊天，如果包含）从每日日志生成。主要思想是电子邮件填充不会改变QA中任何问题答案的低层细节。电子邮件为每日日志增加了显著更多的细节。如前所述，使用电子邮件回答查询的智能体面临的任务比我们的流水线要困难得多；它需要理解整个数据集（与我们的流水线不同，它没有被提供底层递归结构和回答查询时恰好合适的上下文）。

流水线的其他部分包括答案到电子邮件的句子级归因、为增加真实性而在电子邮件中添加干扰项，以及广泛的验证检查和反思-精炼循环。虽然概念上是次要的，但验证检查和反思-精炼循环是流水线的重要组成部分，因为即使是最好的前沿LLM在我们的用例中也总是会犯微妙和不那么微妙的指令遵循错误，尽管我们大量修订了指令；我们在其设计上投入了大量精力。此类错误的一个例子是未来泄露：史诗的描述有时会错误地提及未来发生的事情；我们的流水线会修复此类问题。示例电子邮件线索见图20。流水线的详细讨论见附录A。图1显示了我们的流水线从种子文档到构成数据集的最终电子邮件和QA的整体流程。

3 相关工作

故事写作。如前所述，企业数据与故事有一些相似之处，同时也有许多差异。简要说明我们的流水线设计与故事写作的关系可能有所启发。大多数小说作者处于一个光谱上，该光谱由他们在开始正式写作前规划多少来定义。这个光谱的两端是“裤子党/园丁”和“规划党/建筑师”；例如，[11]。前者从一个前提开始发展，不知道结果会是什么，而后者在实际写作前规划一切。前面提到的智能体模拟方法代表了裤子党风格。我们在本文中的方法更接近规划党风格。选择这一方法的原因，如前所述，是为了保持故事连贯并牢牢把握真相。两种方法的混合可能会产生更真实的企业数据，但我们将其留待未来工作。还有大量关于AI生成小说的文献，例如，[14]。据我们所知，小说生成框架不能直接适用于合成企业数据生成。

现有基准测试。从HotpotQA [17]等早期数据集开始，已经为信息检索任务以及信息检索作为重要骨干的相关任务构建了大量新基准。我们只能给出一个很小的样本：用于研究论文的RAG [4]、用于深度研究 [9]，以及其他相关任务如OfficeQA Pro [13]、DRACO [19]、APEX-Agents [15]、PRBench [3]、TheAgentCompany [16]。在合成企业数据集中，与本工作最接近的是DRBench和HERB：

HERB [6]对39,190个合成企业工件（Slack、文档、GitHub PR、会议记录）进行RAG基准测试，跨越30个软件产品。其查询优先设计：人类专家在通过LLM模拟工作流生成支持证据之前定义查询，这保证了可追溯的金标准，以及基于真实企业流程的自然多跳问题。这些问题需要聚合来自多个异构来源的证据，使该基准成为对检索完整性的有意义测试。然而，该流水线是领域特定的：其查询模板和工作流规范是为软件生命周期手工设计的，需要大量专家重新设计才能应用于其他领域。

DRBench [1]在企业环境中对AI智能体进行开放式深度研究任务的基准测试。包括诸如“个性化如何推动销售，Lee's Market可以使用哪些策略？”之类的查询，需要跨私有企业数据和公共网络进行多步综合，评估洞察回忆、事实性和报告质量。每个任务提供20个文件，涵盖DOCX、XLSX、Matternost聊天日志和电子邮件，金标准洞察分布在所有来源类型中。然而，平均每个任务只有0.5个外部事实，主要挑战是对内部企业数据进行推理，而非网络检索。关键的是，企业文件是静态且非冲突的：聊天日志和电子邮件作为预置事实的容器，而非演变的对话，使得核心挑战是多源事实检索而非时间推理。这与HERB形成对比，在HERB中，版本化文档、功能反转和迭代Slack讨论要求模型跟踪哪个版本的事实是当前的。与HERB一样，DRBench是一个固定基准，并非为适应新的企业环境而设计。

其他有些相关的工作包括CRM Arena-Pro [10]和DataMorgana [8]。

4 实验

4.1 数据集

我们考虑四个不同的数据集，每个代表公司内的一个不同团队。每个数据集包含相应团队执行特定项目的工作场所模拟。我们生成的四个数据集包括以下团队：（i）Cloud DevOps平台团队，（ii）数据平台工程团队，（iii）Stripe Billing，以及（iv）VS Code Changelog。这些数据集在领域和来源上各不相同：Cloud DevOps平台和数据平台工程使用LLM生成的合成企业通讯，而Stripe Billing和VS Code Changelog基于Stripe工程博客和官方VS Code发布说明的真实公开技术文档。这些源文档通过我们的自动化生成流水线转化为长期工作场所模拟。

我们的数据集涵盖多样化的企业查询类型，反映真实的工作场所信息需求。这些范围从短的事实性查询（如所有权归属和行动项检索），到需要跨多个来源综合的更复杂的长式查询，包括项目状态报告、复盘和多领域摘要。查询集旨在捕捉企业搜索中的一些关键挑战，包括多跳推理、跨协作者的责任归属、演变工作流上的时间推理，以及分布式信息的聚合。此外，我们还包括结构化高层查询，如每日简报和项目状态报告，这要求系统生成基于异构证据的连贯多节响应。

查询类型的完整分类，连同代表性示例和预期答案长度，见表5。表1显示了数据集、原始和整体统计。

表1：数据集来源、内容和统计。

4.2 评估

我们使用数据集评估两个系统。这些系统包括[6]中定义的ReAct智能体和开源深度研究（DR）智能体Onyx [12]的改编版。问题-答案对及引用的详细示例，概述数据集的质量和深度，见附录C。

RAG（ReAct）。我们采用此配置作为主要基线，遵循Choubey等人[6]的研究，他们表明混合BM25+密集检索器与ReAct智能体配对时，在其基准研究中表现最佳，优于HERB中评估的所有RAG方法，包括GraphRAG和HippoRAG-2等基于图的方法，该智能体混合配置实现了最高整体性能，使其成为自然的参考点。

该系统围绕ReAct [18]构建，这是一个在迭代循环中交错推理和行动的框架。在每一步，智能体首先生成一个自然语言思考，描述还需要什么信息，然后选择并调用一个工具（例如，混合文档检索、员工查找），并在继续之前观察结果。这种思考-行动-观察循环使智能体能够在轨迹中途自适应地优化其搜索策略，使其非常适合HERB中的多跳、跨源查询。

Onyx深度研究智能体的改编。Onyx [12]是一个领先的智能体RAG平台。它包括一个深度研究（DR）智能体。我们的智能体是Onyx深度研究循环的沙盒化改编版，限制为每个问题可见的电子邮件语料库。它首先发出一个规划调用，返回2-5个子问题和1-4个种子工具调用，然后进入多周期行动→观察→反思循环（最多十周期），最后综合出最终答案。在每个周期，LLM可以发出单个动作或2-4个互补动作的批次，从六个本地工具中选择：hybrid_search、cosine_search、bm25_search、lexical_search、grep_search和find_files，所有这些都限定在可见语料库内；网络搜索和所有非本地工具被禁用。

我们使用gpt-5.4作为底层语言模型，使用text-emb-ada-002进行嵌入。²

4.3 评估指标

所有系统均使用LLM作为评判者的协议进行评估，以gpt-5.4作为评估器。对于每个查询，评判者获得问题、参考答案、候选答案，以及（如适用）检索到的文档和金标准引用文档。评判者使用结构化提示（见附录D.2）在多个维度上评估系统输出。

我们报告六个主要指标：完整性、可靠性、相关性、忠实性、可读性和检索准确性，汇总于表2。每个指标评分范围为[0, 1]，除了整体综合得分，其报告采用1到5的李克特量表。

表2：LLM评判指标。缩写参考：Q：问题；Ref：参考答案；Cand：候选答案；Retrieved：检索到的块；Gold：金标准引用文档；Sub-scores：前述六个指标的分数。

加权综合最终得分计算如下：

Final=0.30⋅Comp.+0.30⋅Sound.+0.15⋅Relev.+0.15⋅Faith.+0.10⋅Read.(1)

最终得分或排名应根据用例中指标的重要性计算，所选择的权重强调完整性和可靠性，因为我们关注答案对提问者的效用。相关性、忠实性和检索等指标是诊断搜索系统检索组件的中间指标。我们根据自己对各个指标相对重要性的理解，在公式（1）中确定了权重。我们认为未加权平均不能证明整体得分的合理性。这受到了各种RAG实现中采用的类似策略的启发（如[7]）。

除评判者指标外，我们还报告标准信息检索指标，以独立于生成来评估检索质量。这些包括平均倒数排名（MRR）、命中率@k、召回率@k，以及引用覆盖率召回，定义为金标准引用文档出现在检索集中的任何位置的比例。

4.4 结果

我们报告四个数据集的得分。表3报告了每个数据集的得分。两个系统在所有四个数据集上的最终得分相对接近（相差在0.11以内），尽管ReAct在所有数据集上始终获得更高的最终得分。相比之下，Onyx通常获得更高的相关性和可靠性得分，表明其倾向于更精确但不够全面的回答。MRR值总体保持适中，表明在两个系统中，将最相关文档检索到第1位仍然具有挑战性。然而，Onyx在某些数据集上（例如，数据平台工程）获得了明显更强的MRR，表明尽管端到端答案质量较低，但早期排名检索更有效。

表3：ReAct和Onyx智能体在各数据集上的性能比较

为了解失败模式是否因任务结构而异，表4按答案形式对查询进行分组。长式查询（每日简报、项目状态报告）需要将许多文档中的信息综合成连贯的叙述。短式查询（会议回顾、行动项汇总、协作者查找等）针对特定事实或事件。

表4：按查询类型比较

答案细分揭示了不同查询结构下的不同失败模式。长式查询（每日简报和项目状态报告）需要将分布在许多文档中的信息综合成连贯的叙述。两个系统在这些查询上的表现明显差于短式查询，整体得分低于2.8，完整性也明显降低。ReAct在长式查询上获得更高的最终得分（0.717 vs. 0.679），主要由于更强的完整性（0.496 vs. 0.428）和检索准确性（0.551 vs. 0.406）。这些结果表明，两个系统都难以在长周期企业工作流中可靠地聚合所有相关上下文。

在短式查询上，最终得分几乎完全收敛（0.765 vs. 0.766），但指标细分揭示了一致的完整性-相关性权衡。ReAct获得更高的完整性（0.665 vs. 0.601），而Onyx获得显著更高的相关性（0.680 vs. 0.571）。这表明ReAct倾向于包含更广泛的上下文信息，而Onyx产生更有针对性和简洁的回答。各个查询类型的详细细分见表7。

5 结论与局限性

在本工作中，我们介绍了WINSYN，一种用于构建真实、多样的合成企业电子邮件语料库以评估问答系统的自动化流水线。WINSYN的设计受企业数据丰富结构的启发。通过将所有生成的工件——从分层项目结构到电子邮件通信——接地于简洁的每日活动日志，确保金标准答案保持可验证和可审计。流水线的分阶段设计，结合反思-精炼循环和程序化验证器，使得生成具有丰富复杂性的连贯、时间一致的数据成为可能。在多个数据集上的实证评估表明，即使强大的智能体基线也难以实现高性能，凸显了在真实企业条件下检索、推理和接地的持续挑战。我们希望这项工作既为可扩展数据集生成提供实用框架，也为推进企业搜索、检索和深度研究系统提供严格的测试平台。

我们当前数据集的范围仅限于电子邮件。虽然电子邮件已经能够代表大部分通信，从而捕捉大部分复杂性，但在真实工作场所环境中，通信和工作工件分布在多个渠道，包括会议、聊天、代码仓库、工单系统和其他协作工具。关于真实性，我们尚未量化或测量数据集与实际企业数据的分布相似性（我们称之为统计真实性）。我们也没有深入探索前面提到的其他真实性方面。我们没有包括外部交互（例如，面向客户的交互），也没有处理公司特定的文化或术语。更多类型的查询可以很容易地纳入我们的流水线，但我们所有的查询都是可回答的；引入不可回答的查询[6]也是一个有用的诊断工具。虽然我们将数据集视为用于评估的基准，但它也可以用于微调，或许需要一些增强。种子文档选择的自由度可以在这方面提供帮助。此外，从业者可以指定实践中遇到的特定失败模式，合成数据可以纳入这些模式。在另一类局限性中，我们的评估没有利用流水线构建的句子级归因。这要求基线智能体构建此类归因，然后可用于检查基线智能体生成答案的接地情况。

解决这些局限性并在规模上扩展数据集（更大的组织、更复杂的动态）和时间跨度，留待未来工作。我们相信我们的方法为此提供了坚实的基础。