《WINSYN: An Automated Pipeline for Realistic Enterprise Question-Answering Evaluation》主要研究如何自动生成逼真的企业问答评估数据集以解决现有基准测试在真实企业场景中复杂度不足的问题。以下是其核心研究内容的全面总结一、研究背景与问题企业问答Enterprise QA与传统的文档问答有本质区别答案往往不包含在任何单一文件中而是分散在邮件、聊天、文档、工单等不断演变且可能相互冲突的工件中。要回答一个查询系统必须从碎片化、分布式、有时矛盾的证据中重建组织状态。然而真实企业语料库因涉及隐私和合规问题很少公开现有合成基准又存在明显局限一些依赖人工模板难以适应新领域一些数据静态、非冲突核心挑战只是多源事实检索而非时间推理查询类型单一答案多为短式缺乏真实工作场景的复杂性。二、核心贡献WINSYN 流水线作者提出了WINSYNWorkplace Interaction Synthesis一种自顶向下、多阶段的自动化流水线从紧凑的种子文档生成完整的企业问答数据集。关键设计思想分层扩展保持全局一致性不采用端到端智能体模拟容易失控而是先将种子文档扩展为公司背景、员工、史诗Epic、任务依赖图DAG、每日日记再生成邮件和问答对。隐藏脚手架与评估证据分离流水线内部使用结构化中间表示来维护时间和因果一致性但被评估的系统只能看到最终的邮件工件。这确保基准测试的是系统从碎片化证据中恢复结构的能力而非依赖生成时的特权信息。金标准答案先冻结邮件后生成QA 在邮件生成之前就基于每日日记确定邮件只添加不改变答案的细节。这解决了“如何保证金标准答案正确”的循环性问题。流水线主要阶段阶段内容公司信息生成公司名称、行业、规模、20-25名员工及其角色、汇报结构、背景史诗Epic生成5-10个史诗及其依赖DAG包含标题、描述、分配员工、时间线、依赖关系任务Task每个史诗分解为5-10个任务及其DAG包含预期输出和下游解锁每日日记将任务扩展为逐日结构化活动日志作为整个数据集的真相来源QA生成基于日记生成短式和长式问题、参考答案及引用集邮件生成从日记生成邮件线索填充低层细节不改变QA答案句子级归因建立答案→日记→邮件的可追溯映射干扰项注入添加过程噪声、纠错链、切线项目通信等干扰邮件增加检索难度质量保障机制接地式构建每个工件都基于前一阶段的工件。验证-反思-精炼循环每个阶段后运行程序化验证和LLM反思直至输出合格。条件生成金标准答案在邮件生成前冻结邮件仅添加不影响答案的细节。三、数据集作者生成了四个企业QA数据集涵盖不同技术领域数据集种子来源邮件数员工数天数问题数Stripe BillingStripe工程博客真实1272211728VS Code ChangelogVS Code发布说明真实1422310022数据平台工程合成通讯1812511025Cloud DevOps合成通讯1512410625查询类型覆盖从短式事实查询如所有权归属、行动项检索到长式综合查询如每日简报、项目状态报告强调多跳推理、跨协作者责任归属、时间推理和分布式信息聚合。四、实验评估评估系统ReAct Agent混合BM25密集检索器结合ReAct推理-行动循环。Onyx Deep Research Agent沙盒化改编多周期行动→观察→反思循环。评估指标使用LLM-as-a-judge协议六个主要指标完整性、可靠性、相关性、忠实性、可读性、检索准确性。最终得分为加权综合Final0.30⋅Comp.0.30⋅Sound.0.15⋅Relev.0.15⋅Faith.0.10⋅Read主要发现整体表现不佳所有数据集的平均聚合得分均低于80%表明企业部署仍有显著改进空间。长式查询比短式查询更难长式查询每日简报、项目状态需要跨多文档综合两个系统的整体得分均低于2.8完整性明显降低。完整性与相关性的权衡ReAct 倾向于包含更广泛的上下文信息完整性更高Onyx 产生更有针对性和简洁的回答相关性更高。检索仍是瓶颈MRR值总体适中将最相关文档检索到第1位仍然困难。干扰项增加难度包含干扰邮件的变体使检索和回答更具挑战性。五、结论与局限结论WINSYN 通过将生成工件接地于简洁的每日活动日志确保金标准答案可验证、可审计。实证评估表明即使强大的智能体基线也难以在企业条件下实现高性能凸显了检索、推理和接地的持续挑战。局限性当前仅限电子邮件模态未量化统计真实性与实际企业数据的分布相似性未包含外部交互、公司特定文化或术语所有查询均可回答未引入不可回答查询评估未利用句子级归因来检查接地情况生成成本随员工、史诗和任务数量近似二次增长大规模数据集成本高昂。WINSYN 的核心创新在于用“规划党”而非“裤子党”的方式生成企业数据——先建立全局结构再逐步填充细节从而在保持故事连贯性的同时牢牢掌握真相。它通过隐藏脚手架与评估证据分离、QA先冻结后生成邮件等设计解决了合成企业数据中“如何保证金标准答案正确”的循环性问题。实验证明当前最强的智能体系统在真实企业问答场景下仍有很大提升空间为该领域的后续研究提供了严格的测试平台。这里是自己的论文阅读记录感兴趣的话可以参考一下如果需要阅读原文的话可以看这里如下所示摘要企业环境为问答智能体提供了一个充满挑战的场景这些智能体通常依赖检索增强生成Retrieval-Augmented Generation, RAG、深度研究Deep Research, DR及相关技术。这一挑战很大程度上源于企业数据的复杂性信息往往分散在不断演变且可能相互冲突的电子邮件、聊天消息、文档和其他工件之中。现有的基准测试通常只具备有限的真实世界复杂性、简短形式的回答以及不自然的查询因此往往无法捕捉企业环境的挑战。在本工作中我们引入了一种自动化流水线用于生成反映真实工作场景的合成电子邮件数据集以及基于这些数据的有据可查的长式和短式问题与金标准答案。我们的方法模拟了跨越数月、涉及多达25名不同角色交互员工的长期企业项目。数据强调歧义性、分布式信息和自然产生的查询。为验证该流水线我们使用最新的前沿模型在我们的数据集上评估了几个标准的智能体基线。我们发现每个数据集上所有查询的平均聚合得分均低于80%表明仍有显著的改进空间。这些发现表明企业部署仍需更多工作并凸显了为开发更强的真实世界企业DR系统而构建真实、高复杂度评估数据的重要性。1 引言企业问答与标准的基于文档的问答存在根本性差异答案往往不包含在任何单一工件中。一个项目决策可能在一封电子邮件中被提出在后续讨论中被修订在规划文档中被论证最终反映在工单、发布说明或事后复盘中。在此类场景中回答查询所需的不仅仅是检索相关段落。系统必须从部分的、分布式的、有时相互冲突的证据中重建不断演变的组织状态。这使得评估变得困难。真实的企业语料库很少可用于研究因为它们通常包含私密、专有和合规敏感信息。因此近期工作越来越依赖合成数据来评估检索增强生成RAG、深度搜索和智能体问答系统。然而生成有用的合成企业数据本身也具有挑战性。真实的工作场所语料库不仅仅是合理文档的集合它必须保持时间一致性、因果依赖关系、角色特定的沟通模式、隐含的组织背景以及足够的接地结构使参考答案可审计。现有的合成企业基准测试在实现这一目标方面取得了重要进展但它们往往在真实性、可扩展性、领域灵活性和答案可验证性之间做出权衡。一些流水线依赖手动指定的模板或工作流这可能限制其对新领域的适应能力例如[6, 1]。这些局限性促使我们采用一种能够在保持全局连贯性的同时仍能产生局部工件级细节的生成过程。我们引入WINSYNWorkplace 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。我们指出我们的技术并不绑定于敏捷方法相反它依赖于这样一个事实任何复杂的工作流都必须是分层的以应对复杂性。多阶段流水线设计镜像了真实的组织工作流并确保所有生成的内容在时间、组织和信息维度上保持连贯和一致因为每个阶段生成的数据都忠实于前一阶段的数据。循环性问题通过保持一个简洁的真相来源得以避免所有答案都接地于此如下所述。它还允许我们保持上下文大小较小由于我们知道数据的分层结构在生成任何特定信息例如一个任务时我们知道最相关的信息例如包含该任务的史诗、相关的其他史诗、前置任务我们可以在上下文中提供这些信息而不必提供前一阶段的整个数据集。请注意在测试时智能体无法获得这些信息必须通过电子邮件来理解数据的结构。现在我们列出数据集创建的步骤公司信息。在此步骤中首先生成公司名称、行业部门、规模然后是员工、他们在公司中的角色、汇报结构、员工的个人和技术背景。史诗。我们创建5-10个史诗以及它们之间的依赖有向无环图DAG。每个史诗的生成包括标题、范围描述、分配员工、工作日时间线、史诗间依赖关系当前史诗开始前需要完成哪些史诗哪些其他史诗依赖当前史诗需要接收和交接哪些工件。一个史诗示例见图17任务。为每个史诗生成5-10个任务及其DAG。每个任务具有与史诗类似的相关信息。参考图18中的示例任务。任务生成后我们偏离敏捷方法。每日日记。这些是通过将任务描述扩展为每日活动日志而获得的。对于每个任务及其时间线中的每一天我们生成一个结构化日记条目包含工作摘要、每位员工的详细活动、进度说明、阻塞项含报告人、解决方案含解决人、协作互动含参与者列表等字段。每日日记如图19所示构成完整数据集的骨干并作为简洁的真相来源QA和电子邮件及其他最终通信工件都接地于此。QA。如前所述确保数据集中答案确实正确的主要思想是在生成答案时控制上下文大小。这之所以可行是因为我们知道数据的分层结构。一些示例见图21、22、23和24。电子邮件。电子邮件以及其他工件类型如聊天如果包含从每日日志生成。主要思想是电子邮件填充不会改变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和HERBHERB [6]对39,190个合成企业工件Slack、文档、GitHub PR、会议记录进行RAG基准测试跨越30个软件产品。其查询优先设计人类专家在通过LLM模拟工作流生成支持证据之前定义查询这保证了可追溯的金标准以及基于真实企业流程的自然多跳问题。这些问题需要聚合来自多个异构来源的证据使该基准成为对检索完整性的有意义测试。然而该流水线是领域特定的其查询模板和工作流规范是为软件生命周期手工设计的需要大量专家重新设计才能应用于其他领域。DRBench [1]在企业环境中对AI智能体进行开放式深度研究任务的基准测试。包括诸如“个性化如何推动销售Lees Market可以使用哪些策略”之类的查询需要跨私有企业数据和公共网络进行多步综合评估洞察回忆、事实性和报告质量。每个任务提供20个文件涵盖DOCX、XLSX、Matternost聊天日志和电子邮件金标准洞察分布在所有来源类型中。然而平均每个任务只有0.5个外部事实主要挑战是对内部企业数据进行推理而非网络检索。关键的是企业文件是静态且非冲突的聊天日志和电子邮件作为预置事实的容器而非演变的对话使得核心挑战是多源事实检索而非时间推理。这与HERB形成对比在HERB中版本化文档、功能反转和迭代Slack讨论要求模型跟踪哪个版本的事实是当前的。与HERB一样DRBench是一个固定基准并非为适应新的企业环境而设计。其他有些相关的工作包括CRM Arena-Pro [10]和DataMorgana [8]。4 实验4.1 数据集我们考虑四个不同的数据集每个代表公司内的一个不同团队。每个数据集包含相应团队执行特定项目的工作场所模拟。我们生成的四个数据集包括以下团队iCloud DevOps平台团队ii数据平台工程团队iiiStripe Billing以及ivVS Code Changelog。这些数据集在领域和来源上各不相同Cloud DevOps平台和数据平台工程使用LLM生成的合成企业通讯而Stripe Billing和VS Code Changelog基于Stripe工程博客和官方VS Code发布说明的真实公开技术文档。这些源文档通过我们的自动化生成流水线转化为长期工作场所模拟。我们的数据集涵盖多样化的企业查询类型反映真实的工作场所信息需求。这些范围从短的事实性查询如所有权归属和行动项检索到需要跨多个来源综合的更复杂的长式查询包括项目状态报告、复盘和多领域摘要。查询集旨在捕捉企业搜索中的一些关键挑战包括多跳推理、跨协作者的责任归属、演变工作流上的时间推理以及分布式信息的聚合。此外我们还包括结构化高层查询如每日简报和项目状态报告这要求系统生成基于异构证据的连贯多节响应。查询类型的完整分类连同代表性示例和预期答案长度见表5。表1显示了数据集、原始和整体统计。表1数据集来源、内容和统计。数据集种子文档内容电子邮件员工天数问题StripeStripe工程博客文章使用Apache Flink和Pinot的实时计费分析1272211728VS Code官方VS Code 2025年10月发布说明涵盖智能体、MCP、终端和其他功能的IDE变更日志1422310022数据平台工程合成数据湖迁移、流处理、数据质量和成本1812511025Cloud DevOps合成开发者门户、OpenTofu迁移、Kubernetes、CI/CD和云成本15124106254.2 评估我们使用数据集评估两个系统。这些系统包括[6]中定义的ReAct智能体和开源深度研究DR智能体Onyx [12]的改编版。问题-答案对及引用的详细示例概述数据集的质量和深度见附录C。RAGReAct。我们采用此配置作为主要基线遵循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的李克特量表。表2LLM评判指标。缩写参考Q问题Ref参考答案Cand候选答案Retrieved检索到的块Gold金标准引用文档Sub-scores前述六个指标的分数。加权综合最终得分计算如下Final0.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表明尽管端到端答案质量较低但早期排名检索更有效。表3ReAct和Onyx智能体在各数据集上的性能比较数据集系统最终完整性可靠性相关性忠实性整体MRRStripeReAct0.7550.6070.7770.7040.9282.8450.475Onyx0.7100.4310.8080.7460.9122.9640.333VS Code ChangelogReAct0.7070.5170.7520.6370.9092.7880.392Onyx0.6940.4140.8030.7120.8922.6360.400Cloud DevOpsReAct0.7920.6720.8830.6630.8983.1200.430Onyx0.6860.4500.7470.7060.8792.7200.459数据平台工程ReAct0.7520.6400.8060.5870.9332.9600.357Onyx0.7030.4520.7840.7090.9152.8000.596为了解失败模式是否因任务结构而异表4按答案形式对查询进行分组。长式查询每日简报、项目状态报告需要将许多文档中的信息综合成连贯的叙述。短式查询会议回顾、行动项汇总、协作者查找等针对特定事实或事件。表4按查询类型比较答案形式系统完整性可靠性相关性可读性忠实性检索最终整体长式ReAct0.4960.7620.7570.8940.9090.5510.7172.724Onyx0.4280.8230.6190.8100.8660.4060.6792.667短式ReAct0.6650.8260.5710.9490.9170.3840.7652.993Onyx0.6010.8760.6800.8310.9200.3810.7663.220答案细分揭示了不同查询结构下的不同失败模式。长式查询每日简报和项目状态报告需要将分布在许多文档中的信息综合成连贯的叙述。两个系统在这些查询上的表现明显差于短式查询整体得分低于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]也是一个有用的诊断工具。虽然我们将数据集视为用于评估的基准但它也可以用于微调或许需要一些增强。种子文档选择的自由度可以在这方面提供帮助。此外从业者可以指定实践中遇到的特定失败模式合成数据可以纳入这些模式。在另一类局限性中我们的评估没有利用流水线构建的句子级归因。这要求基线智能体构建此类归因然后可用于检查基线智能体生成答案的接地情况。解决这些局限性并在规模上扩展数据集更大的组织、更复杂的动态和时间跨度留待未来工作。我们相信我们的方法为此提供了坚实的基础。