本篇论文是：Assisting in Writing Wikipedia-like Articles From Scratch with Large Language Models
ps: 虽然是 NAACL（CCF-B 类会议）的论文，但一方面是斯坦福 NLP 实验室的文章，一方面其 工程代码 在 Github 达到了 7.8k 的 star，证明其含金量和工程的参考价值还是有不少的，更像是一个工程问题，而不是学术问题，而对于作者是博一的学生，所以有一些疏漏也都很正常。
ps: 我会先详细介绍 STORM 是个什么系统，解决了什么问题，实验达到了什么效果，然后会有一个彩蛋内容，描述一个真实的商业场景，这个场景与本篇论文内容无关，主要做一个参考。
参考文章：
从海量信息中脱颖而出：Workflow智能分析解决方案，大语言模型为AI科技文章打造精准摘要评分体系(总篇章)
(翻译篇章)从海量信息中脱颖而出：Workflow智能分析解决方案，大语言模型为AI科技文章打造精准摘要评分体系
(分析篇章)从海量信息中脱颖而出：Workflow智能分析解决方案，大语言模型为AI科技文章打造精准摘要评分体系
整篇论文一直在探讨如何如何利用 LLM 编写类似于维基百科的文章，并且提出了一套系统模式叫做 STORM（Synthesis of Topic Outlines through Retrieval and Multi-perspective Question Asking, 通过检索和多视角提问的方式模拟对话），在其他的一些如 Agent 的九种设计模式 里被理解成多 Agent 协作的一种设计模式。整体来说，作者创建了一个包含高质量维基百科文章的数据集，并使用评估指标对大纲进行了评估。结果表明，与基于大纲检索增强（RAG）的基准相比，STORM 系统生成的文章更加有组织性且覆盖知识的范围更广。
那么编写一篇长文章，需要深入的研究、规划、识别验证、和组织外部资源，对专业的作家来说都是有挑战的，对大模型来说应该如何进行尝试。这篇文章分成了两部分任务：
任务一： 进行一些预先的研究，生成大纲，对大纲生成每一个分节的名字，并且附带一些参考文献。
任务二： 使用上述的大纲和参考文献，补充完整篇文章。
这个看上去挺合理，和人类写作过程差不多，都是先预写、起草和修改，预写的过程会收集整合各种资料。
对任务一来说，由于预训练模型本身有拥有丰富的知识，一种直接的方法是利用它们的已有知识来生成大纲甚至整篇文章（直接生成）。然而我们都知道，这种方法受到缺乏细节，很容易产生幻觉，特别是在处理长尾的主题时。这个就强调了利用外部信息的重要性，当前策略通常涉及检索增强生成（RAG），这又回到了在写作前研究主题的问题，因为简单的主题搜索无法获取大量信息。所以他们提出的 STORM 系统，里面会通过检索和多视角提问来合成主题大纲。
STORM 的设计基于两个假设：
(1) 多样化的观点会导致不同的问题；
(2) 形成深入的问题需要不停的研究。在这些假设的基础上，STORM 使用了一种新颖的多阶段玩法。它首先通过检索和分析来自类似主题的维基百科文章来发现多样化的视角，然后针对提问对 LLM 进行人格化，如下图所示：
比如对上图的 B，对这个问题会提出不同的视角问题，其 prompt 也会引导大模型去提出不同方向的问题。提出不同视角问题后，后续会和大模型模拟多轮对话（也就是上述的图 C），生成的答案会结合互联网检索的内容。最后，基于语言模型内部的知识以及收集的外部信息，STORM 会创建一个大纲，逐节扩展从而构建出类似维基百科的完整文章。
- 数据集
作者使用自己构建的 FreshWiki 数据集来评估 STORM，该数据集收集了最近且高质量的维基百科文章，以避免在预训练期间发生数据泄露。而且为了便于研究前期写作阶段，他们定义了一些指标来评估大纲质量与人工撰写的文章相比如何。而且他们还邀请了一组经验丰富的维基百科的编辑，来进行专家评估。编辑们发现，STORM 比基于大纲的 RAG 基准表现更好，尤其是在文章的广度和语言组织方面。
另外由于现代 LLM 通常是在维基百科文本上进行训练的，因此他们需要寻找在 LLM 测试中使用的时间截止之前的训练数据集之后创建（或大量编辑）的维基百科文章来减轻数据泄漏问题，这样才能证明一些知识不是大模型自己的，而是通过 RAG 灌进去的，这样才说明系统方法是有效的，这样后续如果出现新的大语言模型，哪怕底层数据没更新，这套玩法依然是有效的。
所以他们抓了从 2022 年 2 月到 2023 年 9 月每个月被编辑次数最多的前 100 个页面。为了确保高质量的参考文献，他们筛选这些文章，只保留 ORES 评估为 B 级或更高级别的文章，也排除了那些包含错误信息的文章。最后，还针对每篇文章进行了人工审核，以确保其准确性和完整性。（这个过程剔除了多模态的一些数据，只保留了文本）
- 指标
生成或评估一篇长篇文章是一项艰巨的任务。当人类教师教授学生学术写作时，他们有时会在大纲阶段监督学生。一般来说，一个详尽的大纲表明对主题有全面的理解，并为撰写长篇文章提供了坚实的基础。受此启发，他们也把任务分解为两个阶段，在预写作阶段，系统创建一个大纲 O，定义为多级章节标题列表。在写作阶段，系统使用主题 t、参考文献 R 和大纲 O 来产生长篇文章 S。
为了评估大纲覆盖率，引入了两个指标：【标题软召回】和【标题实体召回】。这些指标比较人类撰写的多级章节标题（视为真实值）与 O（生成的大纲）。考虑到这两组标题元素之间不需要完全一一匹配，所以会使用来自标题的句子 BERT Embedding 来计算标题软召回。针对【标题实体召回】，需要量化为人类撰写的文章标题中被 O（生成的大纲）覆盖的命名实体百分比。
说白了其实就是把生成的大纲，和人自己写的，做相似度对比，以及相关实体内容的召回对比。
核心系统的链路并不复杂，如图所示，几个阶段写的都很明确：
第一阶段，预先定好主题并搜寻一些话题，先给定一个主题（标记为 t），STORM 先通过调查类似主题的现有文章来发现不同的视角，并使用这些视角来控制提问过程。具体来说，STORM 提示一个 LLM 生成相关主题列表，然后从维基百科文章中提取相应的目录，这些信息可以全部灌到一篇文章里，作为整体的一个信息输入，尽量能够囊括话题相关的知识。第二阶段，主要是两个 Agent 进行模拟对话，STORM 模拟维基百科作者与主题专家之间的对话，作者会给出各种观点的问题，专家会结合可靠的互联网信息来解答，专家会进行一些纠错行为，对一些专家认定的事实信息，可以弄到一起，形成一套可靠的参考来源。第三阶段，创建文章大纲，基于上述两个阶段的内容，可以先仅仅根据第一阶段的主题，直接创建一个草稿大纲，然后和第二阶段的模拟对话信息一起细化一个改进的大纲。第四阶段，写长文，基于第二阶段收集的可靠信息，和第三阶段生成的大纲，可以开始逐节编写全文。因为 LLM 上下文长度的限制，需要使用所有的子标题来检索语义相似的信息，提示 LLM 生成带引用的章节。等所有的章节都生成了，它们就可以连接起来形成完整的文章。因为这些章节是并行生成的，他们还会进一步，用合并的文章提示 LLM 删除重复的信息以提高连贯性，此外，为了符合维基百科的文体规范，还需要利用 LLM 合成整篇文章的摘要，形成开头的部分。- 自动生成的文章质量评估
对上述的实验，对比是这么几项：
- 直接提示：直接用 LLM 生成大纲，然后使用该大纲生成完整文章。
- RAG：这个是一个检索增强生成基线，它根据主题搜索，并使用搜索结果与主题（第一阶段生成的）一起生成大纲或整篇文章。
- oRAG：它在创建大纲时与 RAG 完全相同，但会进一步搜索带有部分标题的额外信息来逐节生成文章。
可以从结果看到，本身 oRAG 的效果就挺好了，STORM 在这之上进行了微小的提升，这里可以理解成提升是因为有多种不同观点的补充。
- 不同的模型带来的影响
这里作者提到，对于最终文章生成的应用，只会使用 gpt-4 的结果，因为当引用文本时，gpt-3.5 不能总是很诚实的表示来源。
- 人类分析
他们与 10 位经验丰富的维基百科编辑合作进行了人类评估，他们从数据集中随机抽取了 20 个主题，并使用 STORM 的方法以及根据自动评估结果确定的 baseline oRAG 对生成的文章进行了评估。每对文章都分配给两名编辑进行审阅，结果如下：
从结果能看出，STORM 生成的文章比 oRAG 输出的文章具有更广泛的广度和深度。编辑人员判断由 STORM 生成的文章比 oRAG 输出的文章更有趣、更有条理且覆盖范围更广。具体来说，STORM 生成的文章中被认为更有组织性（组织性评级 > = 4） 的文章数量多出 25%，被认为涵盖面广（覆盖率评级 > = 4） 的文章数量多出 10% 。即使直接与人工编写的文章相比，一位编辑认为 STORM “提供了更多”。
另外也有一些挑战，生成的文章落后于经过仔细校对的人类作品。虽然 STORM 评测上优于 oRAG，编辑们认为生成的文章不如实际维基百科页面信息丰富。另一个主要问题是，从互联网来源到生成文章，会存在偏见和语气的转移，其中 10 位编辑中有 7 位提到，由 STORM 生成的文章听起来 “情绪化” 或 “不中立”。这些反馈表明，在写作前阶段减少检索偏差是有价值的工作方向。
不过编辑者一致认为 STROM 可以帮助他们在写作之前进行预处理，该工具对经验丰富的编辑也有帮助。80% 的编辑者认为 STORM 能够帮助他们编辑维基百科文章。
上述的四节都在描述 STORM 这个系统，但从文章的解读中我们可以发现，还是具备很多的缺陷，无论是幻觉问题，还是最后编辑提出的 “情绪不稳定” 的情况，可以看到这个系统基于 GPT-4，但还无法达到直接生成百科内容的地步，依然需要人工来辅助。
- 一个基于 DIFY 的实践
BestBlogs.dev（Github 地址：https://github.com/ginobefun/bestblogs ）是一个面向技术从业者、创业者和产品经理的网站，主要收集和分享有关软件开发、人工智能、产品管理、营销、设计、商业、科技和个人成长等领域的高质量内容。
直接看图，核心原理就是通过 RSS 订阅和爬虫，收集来自各个领域的优质博客文章，并通过大语言模型进行筛选和评估，以提高内容的质量和效率，很像 ATA 的文章总结这种：
不过整个过程并没有那么简单，包含 爬取文章 - 初评文章 - 文章分析 - 分析翻译 几个过程，参考下图：
那么通过 DIFY，可以很快很容易的搭建出上述的流程，主要得把握住多 Agent 协作的核心玩法。
- 通过 DIFY 搭建文章初评流程
流程的输入为网站的文章 ID，然后通过 Workflow 内置的 HTTP 调用节点和代码节点，调用网站的 API 获取文章的元数据（标题、来源、链接、语言等）和全文内容。
然后为中文和英文文章采用不同的模型和提示词，可以更加灵活的调整和优化。
文章初评 LLM 节点通过 CO-STAR 提示词框架定义上下文、目标、分析步骤、输入输出格式，提供输出示例，完整的提示词可以在上述项目地址查看。
- 文章分析流程
分析流程非常庞大：
- 首先通过 Workflow 内置的 HTTP 调用节点和代码节点，调用网站的 API 获取文章的元数据（标题、来源、链接、语言等）和全文内容。
- 为了能不遗漏各个段落的关键信息，分析流程首先判断文章的长度，如果超过 6000 个字符则进行分段处理，否则直接对全文进行分析。
- 分析的内容输出主要包括一句话总结、文章摘要、文章关键词、主要观点和文章金句等，方便读者快速了解文章内容。
- 这里运用了 Workflow 中的分支、迭代、变量聚合等节点，使得我们能对流程进行灵活控制，对于不同的分支处理结果，可以采用变量聚合将全文分析的内容归集为一个，便于后续节点处理。
- 随后是领域划分和标签生成节点，通过大语言模型对文章内容进行分类，生成文章所属领域和标签列表，这里的标签主要包括主题、技术、领域、应用、产品、公司、平台、名人、趋势等，便于后续文章的组织，增强后续搜索和推荐的实现。
- 再之后的文章评分节点，通过大语言模型对文章内容进行评分，主要包括内容深度、写作质量、实用性、相关性等多维度评估，生成文章的评分，便于读者快速筛选优质文章。
- 然后是检查反思节点，输入为文章元数据和全文内容，以及分析结果、领域和标签列表、评分等，要求大语言模型扮演技术文章评审专家，按照全面性、准确性、一致性等原则，对前述输出进行检查，输出检查结果和反思内容。
- 最后是基于检查反思结果的优化改进节点，要求大语言模分析检查和分析结果，并再次确认输出格式和语言，输出最终的分析结果和更新原因。
- 网站应用通过 Dify Workflow 开放的 API 传入文章 ID，获取并保存文章的分析结果，根据文章评分判断是否继续往下处理。
- 分析结果的翻译流程
分析结果翻译流程的输入为网站的文章 ID，然后通过 Workflow 内置的 HTTP 调用节点和代码节点，调用网站的 API 获取文章的元数据（标题、来源、链接、语言、目标语言等）、全文内容和分析结果。
翻译流程采用了 初次翻译 – 检查反思 – 优化改进，意译 三段式翻译流程，从而让翻译更加符合目标语言的表达习惯。
参考文章：
从海量信息中脱颖而出：Workflow智能分析解决方案，大语言模型为AI科技文章打造精准摘要评分体系(总篇章)
(翻译篇章)从海量信息中脱颖而出：Workflow智能分析解决方案，大语言模型为AI科技文章打造精准摘要评分体系
(分析篇章)从海量信息中脱颖而出：Workflow智能分析解决方案，大语言模型为AI科技文章打造精准摘要评分体系
书籍推荐