跳过正文

【速览】四篇长文本生成论文速览

·12111 字·25 分钟
研究 Agent 长文本生成
Ji Binquan
作者
Ji Binquan
现在也没研究明白
目录

LLM的长文本生成是一个广泛需求但难度较高的研究方向。自从大型语言模型首次进入大众视野以来,大家便积极尝试利用这些模型创作长篇故事。然而,由于上下文长度的限制和灾难性遗忘问题,如何确保生成内容前后一致、逻辑连贯并避免冗余输出,仍是亟待解决的挑战。同时,相较于LLM在语言处理或问答领域的应用,如何客观评估生成文章的质量也是研究者必须面对的重要问题。虽然目前LLM在问答和长文本输入方面已有不少成果,但长文本输出的研究热度相对较低。本文选取了自2024年以来发表的4篇长文本输出相关论文,旨在探讨它们如何应对上述研究难题。

1. STORM:通过检索和多视角提问综合生成主题大纲
#

发表单位:斯坦福大学

论文地址:[ 2402.14207] Assisting in Writing Wikipedia-like Articles From Scratch with Large Language Models

项目地址: stanford-oval/storm: An LLM-powered knowledge curation system that researches a topic and generates a full-length report with citations.

录用情况:NAACL 2024

任务目标
#

  • 动机:大型语言模型(LLMs)在写作方面表现出色,但如何利用它们撰写类似维基百科的长篇条目文章仍待探索。撰写此类文章需要在写作前的准备阶段进行彻底的研究和规划,而之前生成维基百科文章的工作通常跳过了这一阶段,假设参考文档或文章大纲已存在,这在一般情况下并不现实。
  • 现有问题:收集参考文献和制定大纲需要先进的信息素养技能,这对经验丰富的作家来说也极具挑战性。此外,仅依靠LLMs的参数知识生成大纲或文章存在缺乏细节和幻觉的问题,尤其是在处理长尾主题时。本文的目标即是生成一个具有深度广度的文章大纲,进而生成高质量文章。

具体方法
#

image-20250325135308443

论文通过提出一个名为STORM(Synthesis of Topic Outlines through Retrieval and Multi-perspective Question Asking)的系统来解决这个问题。STORM系统的核心思想是通过模拟多视角的对话来研究主题,并基于这些对话创建文章大纲。STORM的工作流程可以分为以下几个关键步骤:

Step1. 主题驱动的视角构建
#

  • 发现多样视角:STORM首先通过检索和分析类似主题的维基百科文章来发现不同的视角。它会检索与给定主题相关的维基百科文章,并提取这些文章的目录(TOC),然后基于这些目录来识别可以用于撰写全面文章的不同视角 $ P = {p_1,p_2,…,p_n}$。此外,作者在 $P$ 中添加了 $p_0$ 作为 “专注于广泛涵盖主题的基本事实的事实编写者”视角,以确保关于原始主题 $t$ 的基本信息也得到涵盖。
  • 指定具体视角:在识别出多样视角后,STORM会为每个视角创建一个角色,这些角色将指导后续的问题提问过程。例如,对于“2022年冬奥会开幕式”这一主题,可能的视角包括活动策划者、参与者、观众等,每个视角都有其独特的关注点。

Step2. 模拟对话
#

  • 初始化对话:对于每个视角,STORM会模拟一个维基百科写作者与主题专家之间的对话。对话从写作者基于主题和指定视角提出一个问题开始。

  • 多轮对话:在每一轮对话中,写作者会根据主题、指定的视角以及之前的对话历史提出一个问题。然后,系统会将这个问题分解成多个搜索查询,并使用搜索引擎来查找相关的网络信息。搜索结果会经过基于规则( Wikipedia:Reliable sources - Wikipedia)的筛选,以确保只使用可信的来源。最后,系统会综合这些可信的来源来生成专家的回答,并将这些回答添加到参考文献集合 $R$ 中。

  • 结束对话:当写作者没有更多问题时,对话结束。这个过程会为每个视角生成一系列的问题和答案,形成多轮对话的记录。

Step3. 创建文章提纲
#

  • 初步提纲生成:在实际写作开始前,STORM先创建一个大纲。即首先提示模型仅根据给定的主题 $t$ 生成草稿大纲 $O_D$。这个提纲是一个包含多级标题的列表,用于指导文章的撰写。
  • 提纲细化:在完成所有视角的模拟对话后,STORM会进一步结合对话中的信息来细化和优化初步大纲 $O_D$,使其更加全面和有组织,改进后的大纲 $O$ 将被用于生成全文。

Step4. 撰写全文
#

  • 基于提纲撰写:在完成提纲后,STORM会根据提纲和收集到的参考文献来撰写完整的维基百科文章。因为参考文献集合 $R$ 一次性塞不进大模型,系统会逐段撰写文章,每段内容都基于提纲中的相应标题和使用标题检索到的参考文献集合 $R$ 中的相关信息。
  • 文章整合与优化:最后,把生成的各段内容拼接到一起,再直接输入到LLM中提示其删除重复信息,优化文章的连贯性和逻辑性,并根据维基百科的风格规范添加摘要部分,即完成了整体文章的生成。

评估方法
#

为了评估大纲覆盖率,作者引入了两个指标:标题软召回和标题实体召回。这些指标比较人类撰写的多级章节标题(视为真实值)与O.。考虑到这两组标题元素之间不需要完全匹配,作者使用来自标题的句子BERT嵌入(Reimers和Gurevych,2019年)计算标题软召回(Franti和Mariescu-Istodor,2023)。作者还计算标题实体召回,量化为人类撰写的文章标题中被O覆盖的命名实体百分比。作者提取FLAIR命名实体识别(NER)(Akbik等人,2019年)中的实体。

数据集
#

  • FreshWiki数据集:作者创建了一个名为FreshWiki的数据集,包含2022年2月至2023年9月期间创建或大量编辑的高质量维基百科文章。这些文章是最近编辑的,以避免与训练大型语言模型(LLMs)时使用的数据重叠,确保评估的公正性和有效性。数据集中的文章经过筛选,确保其质量达到B类或以上,并且排除了列表文章和没有子部分的文章。

评估指标
#

  • 大纲质量评估
    • 标题软召回率(Heading Soft Recall):通过计算生成提纲中的标题与人工撰写文章中的标题之间的相似度来衡量提纲的覆盖范围。具体来说,使用Sentence-BERT嵌入来计算标题之间的余弦相似度,然后根据软召回率的定义来评估生成提纲与人工撰写文章的匹配程度。这种方法不要求标题完全一致,而是考虑语义上的相似性。
    • 标题实体召回率(Heading Entity Recall):计算生成提纲中的标题所涵盖的命名实体在人工撰写文章标题中的比例。通过FLAIR命名实体识别(NER)工具来提取实体,从而评估生成提纲在涵盖文章关键实体方面的表现。
  • 文章质量评估
    • 自动指标:采用ROUGE分数来评估生成文章与参考文章之间的相似度。ROUGE是一种常用的文本摘要评估指标,通过比较生成文本和参考文本中的重叠n-gram、词对和词序列来衡量文本的相似性。此外,还计算文章级别的实体召回率,以评估生成文章涵盖关键实体的情况。
    • LLM/人工评价指标:根据Wikipedia标准,从以下五个方面对文章进行评价:
      • 兴趣水平(Interest Level):评估文章是否引人入胜,能否吸引读者的注意力并激发思考。
      • 连贯性和组织性(Coherence and Organization):判断文章是否结构清晰、逻辑连贯,段落之间是否有良好的过渡。
      • 相关性和聚焦性(Relevance and Focus):检查文章是否紧扣主题,避免无关内容的干扰。
      • 覆盖范围(Coverage):衡量文章对主题的各个方面是否有深入探讨,是否提供了全面的覆盖。
      • 可验证性(Verifiability):确保文章中的每个陈述都有可靠的引用支持,避免原创研究和未经证实的主张。

基线方法
#

  • Direct Gen:直接提示LLM生成提纲,然后使用该提纲生成完整文章。
  • RAG(检索增强生成):使用主题进行搜索,并结合搜索结果和主题来生成提纲或整篇文章。
  • Outline-driven RAG(oRAG):与RAG在提纲创建上相同,但在生成文章时,进一步使用部分标题进行搜索,以获取更多信息来逐部分生成文章。

LLM评估
#

作者使用Prometheus进行自动评估,这是一个13B的开源评估LLM ,可以根据定制的1-5分量规对长篇文章进行评分,从兴趣水平、连贯性和组织、相关性和焦点以及覆盖范围的角度给文章打分。下表给出了作者的评分标准。虽然Prometheus评估最好与分数为5的标准文档一起使用,但添加标准文档会超出模型的上下文长度限制。由于Prometheus原论文表明没有参考答案的Prometheus评分也与人类偏好密切相关,因此作者省略了参考答案,并通过迭代删除最短部分的内容来缩短输入文章至2000字以内,以确保输入可以适应模型的上下文窗口。

image-20250325165955681

人类评估
#

  • 评估者:邀请了10位经验丰富的维基百科编辑者参与评估,他们至少在维基百科上进行了500次编辑,并且有超过1年的经验。
  • 评估方式:从数据集中随机抽取20个主题,评估这些主题下由STORM和oRAG生成的文章。每位编辑者会根据上述五个方面对每对文章进行评分,使用1到7的评分标准,其中1表示非常差,7表示非常好。此外,编辑者还需提供开放性反馈和成对偏好。
  • 评估结果:通过计算平均评分、成对比较结果以及p值来分析STORM与oRAG之间的差异。结果表明,STORM生成的文章在组织性、覆盖范围、趣味性等方面均优于oRAG,且在与人类撰写的文章相比时,也展现出一定的优势。不过,编辑者也指出了STORM生成文章在中立性和可验证性方面存在的问题,如存在互联网来源的偏见、过度推断等。

实验结果
#

image-20250325194842492
image-20250325194853075
  • 实验结果:STORM在提纲覆盖范围和文章质量方面均优于基线方法。具体来说,STORM生成的文章在组织性、覆盖范围和引用质量等方面表现出色,且能显著提高文章的趣味性和相关性。
  • 人类评估:经验丰富的维基百科编辑者认为STORM生成的文章在组织性和覆盖范围上优于基线方法,并且在与人类撰写的文章相比时,也展现出一定的优势。不过,编辑者也指出STORM生成的文章在中立性和可验证性方面仍存在挑战,如存在互联网来源的偏见、过度推断等问题。

评价
#

基本就是使用多智能体的思想进行文章生成,使用的也是斯坦福自己的DsPy框架(不愧是斯坦福啊),先大纲后分部分生成也是逻辑十分顺畅的思路。评估方法与思路也有借鉴意义,人工评估财大气粗(不愧是斯坦福啊),大纲正文分别评估的方式有理有据,是比较不错的开拓性工作(不愧是斯坦福啊)。

2. LongWriter:释放长上下文LLM的10,000+字生成能力
#

发表单位:清华大学、智谱AI

论文地址:[ 2408.07055] LongWriter: Unleashing 10,000+ Word Generation from Long Context LLMs

项目地址:[THUDM/LongWriter: ICLR 2025] LongWriter: Unleashing 10,000+ Word Generation from Long Context LLMs

录用情况:ICLR 2025

任务目标
#

​ 当前的长上下文大型语言模型(LLMs)能够处理长达100,000个token的输入,但在生成等长的输出上存在困难,通常输出长度限制在2,000个单词左右,这限制了其在需要长篇内容生成的应用场景中的使用。

经过作者的研究,这种情况是模型采用的SFT数据集更多偏向于长输入,忽略了长输出任务的构建造成的。具体可见下图2,训练数据的输出文本越长,LLM就越能输出更长的文本。

image-20250324162051854

具体方法
#

AgentWrite
#

本文的目的还是构建一个能够一次性输出超长文本的LLM,那没有输出这么长的训练数据怎么办呢?作者就设计了AgentWrite,具体来说,这是一个用来造数据的AGENT。

image-20250324162946459

这个 AgentWrite 分成两个阶段,首先是利用LLM的规划能力,在给定一个写作指令的情况下输出一个写作大纲,其中包括每段的主要内容和字数要求。

image-20250324163518340

然后,多次调用LLM,逐步完成每一个子章节的写作任务。这里作者是采用串行的方式进行每个章节的生成,即在生成第 $n$ 块文本时,会把前 $n-1$ 块文本和大纲一起输入给大模型。作者给出的理由是,经过实验,这种方式获得的整体连贯性和质量远优于并行生成的结果。

image-20250324164031142

数据评估
#

那光让Agent造数据了,数据的质量怎么样呢?怎么筛选高质量数据?参见下节评估方式

其他工作
#

  • LongWriter-6k数据集:通过上面的方法,作者利用AgentWrite和GPT-4o生成了包含6,000个SFT数据的LongWriter-6k数据集,输出长度范围为2k到32k个单词。

  • 模型训练:将LongWriter-6k数据集整合到模型训练中,通过监督微调和直接偏好优化(DPO)来扩展现有模型的输出窗口大小,使其能够生成超过10,000个单词的输出,同时保持输出质量。

评估方式
#

数据集
#

作者通过两个数据集进行评估。

LongWrite-Ruler:即规定不同的文章生成字数 $L$,如”写一篇关于罗马帝国的 $L$ 字文章($L∈{1000,2000,5000,10000,20000,30000}$),看看LLM能否很好的达到目标的字数。共48个不同的写作任务提示(一半英文一半中文)。

LongBench-Write:包含四个长度范围、七个文章类型共120个写作任务提示(一半英文一半中文)

image-20250324195052238

具体来说,作者通两个指标对输出进行评估,一个用于评分输出长度,另一个用于评分输出质量。

评估指标
#

首先,作者使用分段线性函数计算输出长度得分 $S_l$(其中 $l$ 是所需长度,而 $l’$是实际输出长度):

image-20250401192035177

换句话说,当输出长度匹配要求时,得分是完美的100分。当输出长度大于或小于要求的四倍或三分之一时,得分线性衰减到零。由于过短的输出往往比过长的输出更令人头疼,所以指标为过短的输出设置了更高的分数衰减系数。

image-20250324201238123

另一方面,为了自动评估输出质量,作者使用GPT-4o,对生成文本在六个维度上对输出进行评分:相关性、准确性、连贯性、清晰度、广度和深度以及阅读体验。并且作者在提示中指示裁判模型仅根据输出的质量进行评分,而不考虑其长度以尽可能地将质量指标与 $S_l$ 解耦。最后通过在六个维度上的平均得分来获得输出质量的整体分数$S_q$。最终的分数 $\overline{S}$ 是通过计算 $S_l$和 $S_q$的均值得到的。

实验结果
#

image-20250324201558800
image-20250324201426317

通过在LongBench-Write上的评估,LongWriter模型在输出长度和质量上均表现出色,其9B参数模型通过DPO进一步改进后,在基准上达到了最先进的性能,甚至超越了更大的专有模型。

评价
#

本文从pipeline方法回落到构造数据训练模型,目的在于激发模型输出长文本的潜力?文本质量评估方式也是直接通过LLM打分的方式进行的。就是还是存在这个问题:构造数据训练模型,输出第n个子章节需要输出前n-1个章节、LLM评估整个文章,都隐形限制了文本生成长度还是需要在模型可以接受的处理极限之内。

3. AutoPatent:用于自动生成专利的多智能体框架
#

发表单位:中科院深圳先进院、大连理工大学等

论文地址:[ 2412.09796] AutoPatent: A Multi-Agent Framework for Automatic Patent Generation

项目地址: QiYao-Wang/AutoPatent: Repository of AutoPatent.(代码目前没开源)

发布时间:2024年12月

任务目标
#

image-20250326132317157
  • 动机:专利作为知识产权的重要组成部分,其撰写过程繁琐且耗时费力,通常由熟悉专利法并通过专利代理人考试的人类专利代理人完成,效率低下且成本高昂。随着大型语言模型(LLMs)的发展,其在知识密集型领域的强大能力为自动专利撰写提供了可能。
  • 现有问题:现有的专利处理研究多集中在分类任务或短文本生成任务上,如专利分类、审查、摘要生成等,对于生成完整专利这一任务关注较少。此外,专利的特殊性、专业术语和长文本特性也给LLMs带来了挑战。

本文提出了一个具体的任务:D2P(Draft2Patent),模拟真实场景中发明人和专利代理人之间的互动,将发明人的草稿转换成完整的专利文档。具体来说,作者利用基于智能体的方法来模拟发明人和专利代理人之间的互动,设计了五个问题 $q_1、q_2、…、q_5$ ,这些问题是关于一项发明的所有相关信息。作者将它们与发明人的答案$a_1、a_2、…、a_5$ 结合起来形成专利草稿 $D$ 。任务目标即使用专利草稿 $D$ 生成专利 $P$,由专利的标题、摘要、背景、总结、主张和详细描述组成。

image-20250326143815377

具体方法
#

image-20250326132344839

作者提出了一个名为AutoPatent的自动多代理专利起草框架,如上图所示。其设计了一个具有八个智能体和三个步骤的专用流程,以模拟现实场景中的专利起草过程。

Step1. 短文本组件生成(Short Components Generation)
#

  • 目的:根据草稿 $D$ 生成专利的各个短文本组件,包括标题(T)、摘要(A)、背景(B)、总结(S)和权利要求(C),即除去详细描述之外的其他文本。

  • 方法:使用不同的写作者Agent(componentWriter)来生成这些短文本组件。对于参数规模小于14B的开源模型,使用D2P训练集对其进行微调以增强其生成高质量短组件的能力;对于商业模型或较大模型,则使用零样本提示(见下图)。

  • 结果:生成的标题、摘要、背景、总结和权利要求与草稿 $D$ 结合形成参考 $R$ ,为详细描述的生成提供有用信息。

image-20250326134930626
image-20250326134943382

2. 专利撰写指南树(PGTree)构建(Building PGTree)
#

image-20250326135837335
  • 目的:为专利的详细描述生成一个撰写指南树(PGTree),以指导描述写作者完成详细描述的撰写。

  • 方法:使用规划Agent(planningAgent)根据草稿 $D$ 生成PGTree。PGTree是一个两层多路树结构,第一层提供部分的概述,第二层提供具体的撰写指令。

  • 结果:生成的PGTree将详细描述的撰写任务分解为多个部分和子部分,为描述写作者提供清晰的撰写指导。

image-20250326135933930

3. 参考-审查-增强生成(RRAG)(Reference-Review-Augmented Generation)
#

  • 目的:根据PGTree的指导和参考 $R$ 中的信息,生成专利的详细描述。
  • 方法
    • 检索:描述写作者Agent(descriptionWriter)根据PGTree中的指导 $n_{ij}$ 从参考 $R$ 中检索有用信息 $r_{ij}$。
    • 生成:结合检索到的信息 $r_{ij}$、指导 $n_{ij}$和 PGTree $W$,描述写作者生成详细描述的子部分 $d_{ij}$。
    • 审查与反馈:审查Agent(examinerAgent)主动介入,评估生成的子部分 $d_{ij}$ 的质量,并提供反馈。如果审查未通过,描述写作者将根据反馈对 $d_{ij}$ 进行修改,直到审查通过。
    • 拼接:经过审查和修改的所有子部分 $d_{ij}$ 被拼接在一起,形成完整的详细描述 $D$。
  • 结果:生成的详细描述 $D$ 与之前生成的短文本组件结合,形成完整的专利 $P$。
image-20250326150350429
image-20250326150216975

评估方式
#

客观指标评估
#

  • BLEU:一种基于n-gram的机器翻译自动评估指标,通过比较机器生成的文本与参考文本之间的n-gram重叠程度来衡量生成文本的质量。在本文中,使用BLEU指标来评估生成专利与真实专利在词汇和短语层面的相似度。

  • ROUGE系列:包括ROUGE-1、ROUGE-2和ROUGE-L,也是基于n-gram的指标,用于评估生成文本与参考文本之间的相似度。ROUGE-1和ROUGE-2分别考虑了单字和双字的重叠,而ROUGE-L则基于最长公共子序列(LCS)来衡量文本相似度。这些指标能够从不同角度反映生成专利与真实专利在内容上的接近程度。

  • IRR(Inverse Repetition Rate):本文新提出的指标,用于衡量专利文本中句子重复的程度。其计算公式为: $$ IRR(\mathcal{P},t)=\frac{C_n^2}{\sum_{i=1}^{n-1}\sum_{j=i+1}^nf(s_i,s_j)+\varepsilon} $$

    其中 $P$ 表示专利文本,由 $n$ 个句子组成;$ε$ 是一个小值,用于平滑防止除以零;$t$ 是阈值,用于根据句子 $s_i$ 和 $s_j$ 的 Jaccard 相似度 $J$ 来判断它们是否为重复句;函数 $ f(s_i, s_j) $ 根据Jaccard相似度是否大于等于 $t$ 来取值为1或0。IRR值越低,表示文本中的句子重复程度越低,生成的专利质量越高。\

    Jaccard 相似度: $$ J(A, B) = \frac{|A \cap B|}{|A \cup B|} $$

人工评估
#

  • 评估人员:邀请了三位熟悉专利法和专利撰写的专家进行评估,每人拿到两篇专利,一篇来自
  • 评估标准:从准确性、逻辑性、全面性、清晰性、连贯性和一致性六个维度对生成的专利进行评估。具体来说:
    • 准确性:要求专利文本中的每一个技术细节都必须正确,避免模糊表达,参数、结构和过程应具体清晰地描述,以确保发明在技术上可实现,且用词应符合技术领域的标准,避免歧义和不必要的限制。
    • 逻辑性:专利文本的结构应符合专利法的要求,包括摘要、背景、总结、详细描述和权利要求等必要部分,且各部分之间的逻辑连贯,使读者能够逐步理解发明的背景、创新点和具体应用。
    • 全面性:专利文本应充分披露发明,使本领域的技术人员能够理解和实施,避免遗漏和模糊描述,同时使用广泛涵盖各种修改和替代方案的术语,以最大化法律保护的范围。
    • 清晰性:专利文本应在技术和法律方面取得良好的平衡,使技术解决方案的描述既清晰又易于理解,避免不必要的复杂和冗长的句子结构。
    • 连贯性:专利文本必须精确地表达发明,避免使用模糊或不确定的术语,各部分和段落之间应逻辑组织,确保思路的连贯性,使审查员能够逐步理解发明的整体内容。
    • 一致性:专利文本必须与提供的真实专利保持一致,确保技术解决方案的描述准确且连贯,各部分之间以及术语的使用应保持一致,避免出现矛盾,以降低专利被无效的风险并增强其法律稳定性。
  • 评估流程:将生成的专利文本与真实专利文本进行对比,专家们根据上述标准对生成专利的质量进行打分或评价,最终得到AutoPatent框架生成专利的综合质量评估结果。

由于专利的篇幅较长,作者选择不使用基于大语言模型(LLM)的评估方法,因为这些方法往往无法提供公正且准确的结果。

实验结果
#

image-20250326153650245
image-20250326153747465
  • 实验结果:实验结果表明,AutoPatent框架显著提高了各种LLMs生成完整专利的能力。以Qwen2.5-7B模型为基础的AutoPatent框架生成的专利,在客观指标和人工评估方面均优于GPT-4o、Qwen2.5-72B和LLAMA3.1-70B等更大、更强大的LLMs生成的专利。
  • 优势:AutoPatent框架能够生成长度更长、内容更完整、质量更高的专利,有效减少了重复错误,提高了专利撰写的效率和质量。

评价
#

除去短文本的生成部分,主要思想就是在先大纲再局部的基础上加入了一个质量审查模块…也行吧,工程和逻辑上都说的通。这个文本长度够长的,结果直接把LLM评估去了…人工评估样本量就很难上去了。

4. CogWriter: 约束长格式文本生成的认知写作视角
#

发表单位:穆罕默德·本·扎耶德人工智能大学、中国科学院大学、南洋理工大学

论文地址:[ 2502.12568] A Cognitive Writing Perspective for Constrained Long-Form Text Generation

代码未开源

发布时间:2025年2月

任务目标
#

  • 动机:尽管大型语言模型(LLMs)在自然语言处理任务中展现出了类似人类的写作能力,但在生成符合复杂约束的高质量长篇文本方面仍存在困难。根据认知写作理论,人类写作是一个复杂的认知过程,涉及计划、翻译、回顾和监控等迭代活动。而LLMs的单次生成方式与这些关键认知原则存在根本冲突,主要表现在:将长篇文本生成视为端到端任务,忽视了分层规划过程;自回归架构使得生成的文本不可变,无法进行回顾和重组;缺乏明确的评估机制,难以在长篇生成中保持与目标的一致性。
  • 现有问题:LLMs在生成长篇文本时,容易在长跨度文本中失去连贯性,难以处理复杂的多线程叙事,并且在满足详细指令要求方面表现不佳,如在超过10,000字的文本中遵循详细指令。这些问题限制了LLMs在需要扩展、结构化内容的应用中的使用,如创意设计提案、技术文档和综合研究报告等。

作者将任务定义为受限长篇文本生成任务,即生成一系列相互关联的文本段落 $D = {D₁, D₂, …, Dₙ}$,其中每个 $Dᵢ$ 代表一个连贯的文本单元,并且必须满足一定的约束条件。这些约束条件通过指令集T来体现,T包含以下三种类型的指令:

  1. 单指令(Single Instruction, SI):这种指令指定了必须出现在确切、预定义位置的内容。例如,在生成摩天大楼设计文本时,指定第20层必须包含医疗中心。
  2. 范围指令(Range Instruction, RI):这种指令指定了在指定范围内每个描述必须包含的内容。例如,在生成摩天大楼设计文本时,指定第5-12层为公司办公室。
  3. 周期指令(Periodic Instruction, PI):这种指令要求在固定间隔周期性重复特定内容。例如,在生成摩天大楼设计文本时,每5层设置一个安全检查站。

这三种类型的指令被统一到一个综合的检查集 $T = {Tₛ, Tᵣ, Tₚ}$ 中,用于全面指导和约束文本生成过程

具体方法
#

image-20250326200415014

框架概述
#

  • 目标:CogWriter旨在通过整合规划、监控和回顾机制,弥合当前LLMs与人类写作过程之间的差距,从而提升LLMs在长篇文本生成任务中的表现。
  • 核心组件
    • 规划Agent(Planning Agent):负责分层分解任务,创建结构化计划,将复杂的写作任务分解为可管理的组件,同时保持它们之间的复杂关系。
    • 生成Agent(Generation Agents):负责根据计划生成文本段落,同时监控机制持续评估输出,检测内容、结构或要求方面的偏差。当发现问题时,会触发回顾过程,修订和优化输出,确保整体连贯性和对指令的遵循。

规划Agent
#

  • 功能:规划代理作为系统的战略核心,类似于有经验的作家从详细的提纲开始,分析任务要求,并在严格的格式约束下生成初始计划Pinitial。
  • 过程
    • 生成初始计划:根据任务特定的提示 $p_{plan}$ ,结合指令描述 $T$,生成初始计划 $P_{initial}$。
    • 计划修正:通过监控机制评估初始计划,验证其是否满足任务约束和结构正确性。如果发现问题,会触发修正过程,生成修订后的计划 $P_{revised}$,并进行格式修正,得到最终的计划 $P$。

生成Agent
#

  • 功能:一旦规划代理生成了最终的全局计划 $P$,多个生成Agent将接管,每个代理负责根据特定的描述任务 $Di$ 生成内容。
  • 过程
    • 验证和调整本地计划:每个生成代理首先验证和细化分配到的本地计划 $P_i$ ,通过监控和回顾机制确保其符合指令要求 $T$。如果发现不一致,会调整计划,得到 $P_i’$。
    • 生成内容:根据调整后的计划 $P_i’$,生成初始内容 $D_{initiali}$。
    • 长度调整:由于当前大多数LLMs在控制输出长度方面存在限制,会使用修订函数调整内容,使其满足指定的长度 $L$,同时保留关键细节、语义完整性和整体连贯性。
image-20250326201739440

整体流程
#

  1. 规划阶段
    • 规划代理根据任务指令生成初始计划。
    • 通过监控和修正机制,确保计划的高质量和有效性。
  2. 生成阶段
    • 多个生成代理根据优化后的计划并行生成文本段落。
    • 在生成过程中,持续监控和回顾,确保内容符合要求。
    • 对生成的文本进行长度调整和优化,确保最终输出既符合指令又具有良好的连贯性和逻辑性。

评估方法
#

数据集
#

  • 数据集名称:LongGenBench-16K
  • 数据集特点:该数据集专门用于评估模型在复杂约束下的长篇文本生成能力,包含四个场景,每个场景需要生成大约16,000个标记。具体场景包括:
    • 日记写作(Diary Writing):要求在一年的每周生成连贯的内容,注重时间一致性,每篇日记至少200字。
    • 菜单设计(Menu Design):同样要求在一年的每周生成连贯的内容,注重时间一致性,每篇菜单至少200字。
    • 摩天大楼设计(Skyscraper Design):通过详细设施安排来评估空间推理能力,每层楼描述至少150字。
    • 城市规划(Urban Planning):通过详细城市街区的设施安排来评估空间推理能力,每个街区描述至少150字。
  • 指令类型:每个场景涉及三种指令类型:
    • 单指令(Single Instructions):指定必须出现在确切、预定义位置的内容。
    • 范围指令(Range Instructions):指定在指定范围内每个描述必须包含的内容。
    • 周期指令(Periodic Instructions):指定在固定间隔周期性重复的内容。
  • 数据集规模:包含400个测试实例,每个场景100个实例。

评估指标
#

  • 主任务完成率(Comp. Rate)

    • 定义:主任务完成率衡量模型是否按顺序完成了所有指定的子任务,例如在日记写作任务中,是否为一年中的每一周都生成了条目。
    • 评估方式:通过检查生成的文本是否涵盖了所有要求的子任务来计算完成率。例如,在摩天大楼设计任务中,是否为每一层楼都提供了描述。
  • 指令遵循准确性

    • 定义:指令遵循准确性评估模型生成的文本是否符合指定的指令要求,包括单指令、范围指令和周期指令。
    • 具体指标
      • 单指令准确性(Acc. Once):衡量模型是否在指定的确切位置包含了特定内容。
      • 范围指令准确性(Acc. Range):评估模型是否在指定的范围内正确地包含了相关内容。
      • 周期指令准确性(Acc. Periodic):检查模型是否按照规定的间隔周期性地重复了特定内容。
    • 评估方式:通过对比生成文本与指令要求,统计符合要求的内容出现的次数与总要求次数的比例来计算准确性。
  • 平均准确性(Avg. Acc.)

    • 定义:平均准确性是单指令、范围指令和周期指令准确性的平均值,提供了一个综合的性能指标。
    • 评估方式:将上述三种指令准确性的数值相加后取平均值。
  • 字数统计(Words)

    • 定义:字数统计用于评估生成文本的长度是否达到了任务要求的最低字数标准。
    • 评估方式:直接统计生成文本的字数,并与任务要求的最低字数进行比较。
  • 长度控制性能

    • 定义:长度控制性能评估模型是否能够按照指定的长度要求生成每个文本段落,例如在摩天大楼设计任务中,每层楼的描述是否达到了150字的要求。
    • 评估方式:通过分析生成文本的长度分布,检查其是否集中在目标长度附近,以及是否存在较大的偏差。

实验结果
#

image-20250326202408734

实验结果表明,CogWriter在所有评估指标上均表现出显著的改进。例如,当以Qwen-2.5-14B-Instruct为骨干时,与基线模型相比,完成率提高了0.51,平均准确性提高了0.17。对于Llama3.3-70B-Instruct和GPT-4o,CogWriter实现了接近完美的完成率,并显著提高了指令遵循准确性。

评价
#

认知科学拯救世界了,现在LLMs研究者人均认知科学家,你永远不知道下一篇看到的工作来自哪个远古的认知科学理论。论文整体…感觉思路跟上一篇专利的差不多,先生成后修改。评估方式方面,因为他任务定义成约束条件下文本生成了,主要关注的都是任务完成情况……也算另辟蹊径吧……。

总结
#

长文本生成目前还是没有一个完整的评估基准去进行方法的评估比较,目前感觉还是都处于探索的阶段。俗话说的好,文无第一,如何客观的评价一篇文章的好坏本来就是及其难以取得共识的问题,加上长文本生成任务的超长输出难以让LLM进行一次性完整评估的限制,自动评估基本只能是从某些侧面入手去进行评估文章某一方面的质量。那人工双盲评估算是可以让大众都能接受的一种评估方法,就是费钱。但是,从上面的工作中我们也能获得一些共识:

  1. 对于模型一次无法完全输出的超长文本,先大纲后局部具体生成的方法是目前共识(因为这至少能一定程度上保证全文逻辑大方面的一致性)。对于局部输出质量的约束可以加入一定的质量监督模块进行保底。
  2. ROUGE分数与LLM评估虽然说服性有待考证,不过依然是主流的长文本评估方式。