七月论文审稿GPT第2版:从Meta Nougat、GPT4审稿到Mistral、LongLora Llama

前言

如此前这篇文章《学术论文GPT的源码解读与微调:从chatpaper、gpt_academic到七月论文审稿GPT》中的第三部分所述,对于论文的摘要/总结、对话、翻译、语法检查而言,市面上的学术论文GPT的效果虽暂未有多好,可至少还过得去,而如果涉及到论文的修订/审稿,则市面上已有的学术论文GPT的效果则大打折扣

原因在哪呢?本质原因在于无论什么功能,它们基本都是基于API实现的,而关键是API毕竟不是万能的,API做翻译/总结/对话还行,但如果要对论文提出审稿意见,则API就捉襟见肘了,故为实现更好的review效果,需要使用特定的对齐数据集进行微调来获得具备优秀review能力的模型

继而,我们在第一版中,做了以下三件事

  1. 爬取了3万多篇paper、十几万的review数据,并对3万多篇PDF形式的paper做解析(review数据爬下来之后就是文本数据,不用做解析)
    当然,paper中有被接收的、也有被拒绝的
  2. 为提高数据质量,针对paper和review做了一系列数据处理
    当然,主要是针对review数据做处理(具体而言是,对paper做的是去掉reference,剩下其他都是对review做的数据处理)
  3. 基于RWKV进行微调,然因其遗忘机制比较严重,故最终效果不达预期

所以,进入Q4后,我司论文审稿GPT的项目团队开始做第二版(我司目前在不断迭代三大LLM项目,每个项目各自一个项目组,除了阿荀带头的论文审稿GPT之外,还有:霍哥带头的AIGC模特生成系统、朝阳带头的企业知识库问答),并着重做以下三大方面的优化

  • 数据的解析与处理的优化,meta的一个ocr即「nougat」能提取出LaTeX,当然,我们也在同步对比另一个解析器sciencebeam的效果
  • 借鉴GPT4做审稿人那篇论文,让ChatGPT API帮爬到的review语料,梳理出来 以下4个方面的内容
    1 重要性和新颖性
    2 论文被接受的原因
    3 论文被拒绝的原因
    4 改进建议
  • 模型本身的优化,比如Mistral或llama longlora

第一部分 第二版对论文PDF数据的解析

1.1 两大PDF解析器:nougat VS ScienceBeam

1.1.1 Meta nougat

nougat是Meta针对于学术PDF文档的开源解析工具(其主页、其代码仓库),以OCR方法为主线,较之过往解析方案最突出的特点是可准确识别出公式、表格并将其转换为可适应Markdown格式的文本。缺陷就是转换速读较慢、且解析内容可能存在一定的乱序

和另一个解析器sciencebeam做下对比,可知

  • nougat比较好的地方在于可以把图片公式拆解成LaTeX源码,另外就是识别出来的内容可以通过“#”符号来拆解文本段
    缺陷就是效率很低、非常慢,拿共约80页的3篇pdf来解析的话,大概需要2分钟,且占用20G显存,到时候如果要应用化,要让用户传pdf解析的话,部署可能也会有点难度
  • sciencebeam的话就是快不少,同样量级的3篇大约1分钟内都可以完成,和第1版用的SciPDF差不多,只需要CPU就可以驱动起来了

当然,还要考虑的是解析器格式化的粒度,比如正文拆成了什么样子的部分,后续我们需不需要对正文的特定部分专门取出来做处理,如果格式化粒度不好的话,可能会比较难取出来

  1. 环境配置
    # 新建虚拟环境
    conda create -n nougat-ocr python=3.10
    # 激活虚拟环境
    conda activate nougat-ocr
    # 使用pip安装必要库(镜像源安装可能会出现版本冲突问题,建议开启代理使用python官方源进行安装)
    pip install nougat-ocr -i https://pypi.org/simple
  2. 使用方法
    # 初次使用时会自动获取最新的权重文件
    # 针对单个pdf文件
    nougat {pdf文件路径} -o {解析输出目录}
    # 针对多个pdf所在文件夹
    nougat {pdf目录路径} -o {解析输出目录}
  3. 测试示例
    标题及开头
    公式识别与转换
    脚注识别

1.1.2 ScienceBeam

ScienceBeam是经典PDF文档解析器GROBID的变体项目,是论文《Can large language models provide useful feedback on research papers? A large-scale empirical analysis》所采用的文本提取方法,同其他较早期的解析方法一样,对公式无法做出LateX层面的解析,且该解析器仅支持在X86架构的Linux系统中使用

// 待更

1.2 对2.6万篇paper的解析

最终,针对有review的2.6万篇paper (第一版 全部paper3万篇,其中带review的2.5万篇;第二版 全部paper3.2万篇,其中带review的2.6万篇 )

  1. 我司审稿项目组的其中一位用的2张24G的P40解析完其中一半,另外一半由另一位用的48G的A40解析完
  2. 因nougat解析起来太耗资源,加之当时我们的卡有限,所以这个PDF的解析,我们便用了一两周..

// 待更

第二部分 第二版对paper和review数据的处理

2.1 第二版对paper数据的处理

在第一版中,我们对paper和review数据做了如下处理(:对paper做的是去掉reference,剩下其他都是对review做的数据处理)

总之,第一版中

  • 面向paper  更多是做的PDF解析,数据处理方面只去除reference这一项
  • 面向review 则更多做的数据处理,毕竟如本文前言中所说的:“review数据爬下来之后就是文本数据,不用做解析”

第二版中对paper处理沿用第一版的处理方法,即去除paper中的reference项

2.2 对review数据的处理

以“b_forum”字段为与Paper数据所关联的外键,“b_forum”为对应Paper的唯一标识符(id)

  • 某篇paper所对应的Review数据如果只是单行即为单个Review
  • 但很多时候,单篇Paper可能对应有多个Review,故存在多行数据下b_forum相同的情况

针对原始数据,我们做以下4点处理

  1. 过滤需求外的Review
    主要是去掉作者自己的回复,以及对paper的评论
  2. 将Review字符串化
  3. 过滤内容过少的Review
  4. 将Review进行“多聚一”,下文详述

本部分数据处理的代码,暂在七月在线的「大模型项目开发线上营」中见

// 待更

第三部分 对review数据的进一步处理:规范Review的格式且多聚一

3.1 斯坦福:让GPT4首次当论文的审稿人

近日,来自斯坦福大学等机构的研究者把数千篇来自Nature、ICLR等的顶会文章丢给了GPT-4,让它生成评审意见、修改建议,然后和人类审稿人给出的意见相比较

  • 在GPT4给出的意见中,超50%和至少一名人类审稿人一致,并且超过82.4%的作者表示,GPT-4给出的意见相当有帮助
  • 这个工作总结在这篇论文中《Can large language models provide useful feedback on research papers? A large-scale empirical analysis》,这是其对应的代码仓库

所以,怎样让LLM给你审稿呢?具体来说,如下图所示

  1. 爬取PDF语料
  2. 接着,解析PDF论文的标题、摘要、图形、表格标题、主要文本
  3. 然后告诉GPT-4,你需要遵循业内顶尖的期刊会议的审稿反馈形式,包括四个部分
    成果是否重要、是否新颖(signifcance andnovelty)
    论文被接受的理由(potential reasons for acceptance)
    论文被拒的理由(potential reasons for rejection)
    改进建议(suggestions for improvement)
    Your task now is to draft a high-quality review outline for a top-tierMachine Learning (ML) conference fora submission titled “{PaperTitle}”:
    
    ```
    {PaperContent}
    ```
    
    ======
    Your task:
    Compose a high-quality peer review of a paper submitted to a Nature family journal.
    
    Start by "Review outline:".
    And then:
    "1. Significance and novelty"
    "2. Potential reasons for acceptance"
    "3. Potential reasons for rejection", List multiple key reasons. For each key reason, use **>=2 sub bullet points** to further clarify and support your arguments in painstaking details. Be as specific and detailed as possible.
    "4. Suggestions for improvement", List multiple key suggestions. Be as specific and detailed as possible.
    
    Be thoughtful and constructive. Write Outlines only.
  4. 最终,GPT-4针对上图中的这篇论文一针见血地指出:虽然论文提及了模态差距现象,但并没有提出缩小差距的方法,也没有证明这样做的好处

3.2 为了让模型对review的学习更有迹可循:规范出来4个要点且多聚一

3.2.1 设计更好的提示模板以让大模型帮梳理出来review语料的4个内容点

上一节介绍的斯坦福这个让GPT4当审稿人的工作,对我司做论文审稿GPT还挺有启发的

  1. 正向看,说明我司这个方向是对的,至少GPT4的有效意见超过50%
  2. 反向看,说明即便强如GPT4,其API的效果还是有限:近一半意见没被采纳,证明我司做审稿微调的必要性、价值性所在
  3. 审稿语料的组织 也还挺关键的,好让模型学习起来有条条框框 有条理 分个 1 2 3 4 不混乱,瞬间get到review描述背后的逻辑、含义
    比如要是我们爬取到的审稿语料 也能组织成如下这4块,我觉得 就很强了,模型学习起来 会很快
    1) 成果是否重要、是否新颖
    2) 论文被接受的理由
    3) 论文被拒的理由
    4) 改进建议

对于上面的“第三大点 审稿语料的组织”,我们(特别是阿荀,其次我)创造性的想出来一个思路,即通过提示模板让大模型来帮忙梳理咱们爬的审稿语料,好把审稿语料 梳理出来上面所说的4个方面的常见review意见

那怎么设计这个提示模板呢?借鉴上节中斯坦福的工作,提示模板可以在斯坦福那个模板基础上,进一步优化如下

// 暂在七月在线的「大模型项目开发线上营」中见,至于在本文中的更新,待更

3.2.2 如何让梳理出来的review结果更全面:多聚一

我们知道一篇paper存在多个review,而对review数据的学习有三种模式

  1. 一种是多选一
    但多选一有个问题,即是:如果那几个review都不是很全面呢,然后多选一的话会不会对review信息的丰富程度有损
  2. 一种是多聚一
    对多个review做一下总结归纳(阿荀、我先后想到),相当于综合一下,此时还是可以用GPT 3.5 16K或开源模型帮做下review数据的多聚一

  3. 一种是多轮交互
    这种工作量比较大,非首选

如此,最终清洗之后的24000篇paper的review,用多聚一的思路搞的话,便可以直接一次调用支持16K的GPT 3.5(毕竟16K的长度足够,可以把所有的review数据一次性给到GPT3.5 16K),或开源模型让它直接从所有review数据里提炼出4个要点,大概是24000多次

3.2.3 通过最终的prompt来处理review数据:ChatGPT VS 开源模型

综上,即是考虑多聚一策略来处理Review数据,主要是对Prompting提出了更高的要求:

  1. 要求大模型聚合所有Review的观点来进行摘要
  2. 为保证规整Review的统一性,需提供具体的类别(如新颖性、接受原因、拒绝原因、改进建议等)对观点进行明确“分类”
  3. 强调诚实性来缓解幻觉,在prompt中提供“示弱”选项(如回复“不知道”或允许结果为空等)
  4. 为使得后续工作更容易从大模型的输出中获取到所关注的信息,需对其输出格式进行要求

相当于咱们得基于上述要求来设计Prompt (最终设计好的prompt暂在七月在线的「大模型项目开发线上营」里讲,至于本文本部分内容的更新则明年Q1更新)

当我们最终的prompt设计好了之后,接下来,便可以让大模型通过该prompt处理review数据了,那我们选用哪种大模型呢,是ChatGPT还是开源模型,为此,我们对比了以下三种大模型

  1. zephyr-7b-alpha
  2. Mistral-7B-Instruct-v0.1
  3. OpenAI刚对外开放的gpt-3.5-turbo-1106,即上一节图中的GPT3.5 Turbo 16K
    不过OpenAI会限访问且限得比较严格,访问经常会假死不给返回、也没报错,需要想办法比如怎么切代理或者过限制

// 待更

第四部分 模型的训练/微调:从Mistral到LongLora LLaMA13B

4.1 Mistral 7B:通过分组查询注意力 + 滑动窗口注意力超越13B模型

今年5月,DeepMind和Meta的三位前员工在巴黎共同创立了Mistral AI(其CEO Arthur Mensch此前在DeepMind巴黎工作,CTO Timothée Lacroix和首席科学家Guillaume Lample则在Meta共同参与过LLaMA一代的研发,很像当年OpenAI的部分员工出走成立Anthropic啊),今年10月,他们发布了第一个基座大模型,即Mistral 7B

据其对应的论文《Mistral 7B》称( 另,这是其GitHub地址)

  1. Mistral 7B在所有评估基准中均胜过了目前最好的13B参数模型(Llama 2),并在推理、数学和代码生成方面超越了发布的34B参数模型(Llama 34B)
    Mistral 7B outperforms the previous best 13B model (Llama 2, [26]) across all testedbenchmarks, and surpasses the best 34B model (LLaMa 34B, [25]) in mathematics and codegeneration.
  2. 该模型采用了分组查询注意力(GQA),GQA显著加快了推理速度,还减少了解码期间的内存需求,允许更高的批处理大小,从而提高吞吐量
    GQA significantly accelerates the inference speed, and also reduces the memory requirement during decoding, allowing for higher batch sizes hence higher throughput

    关于GQA,请参见《一文通透各种注意力:从多头注意力MHA到分组查询注意力GQA、多查询注意力MQA》
  3. 同时结合滑动窗口注意力(slidingwindow attention,简称SWA)以有效处理任意长度的序列,
    SWA is designed to handle longer sequences more effectively at a reduced computational cost

此外,作者提供了一个针对遵循指令进行了微调的模型,名为Mistral 7B-Instruct,它在人工和自动化基准测试中均超过了LLaMA 2 13B-chat模型

4.1.1 滑动窗口注意力:扩展上下文长度

vanilla attention的操作次数在序列长度上是二次型的,记忆量随着token数量线性增加。在推理时,由于缓存可用性的降低,这导致了更高的延迟和更小的吞吐量(The number of operations in vanilla attention is quadratic in the sequence length, and the memory increases linearly with the number of tokens. At inference time, this incurs higherlatency and smaller throughput due to reduced cache availability)

为了缓解这个问题,我们使用滑动窗口注意力(sliding window attention)

  1. 每个token最多可以关注来自上一层的W个token(上图中,W = 3)。请注意,滑动窗口之外的token仍然影响下一个单词预测
    each token can attend to at most W tokens from the previous layer (here, W = 3). Note that tokensoutside the sliding window still influence next word prediction.

    举个例子,在我们面对这个序列时:The cat sat on the
    如果是标准注意力,在计算最后一个token “the”时,得计算the本身所对应的query与整个上文每个token对应的key的内积,当序列长度一长时,该计算量还是比较大的
    但如果是滑动窗口注意力,则在计算最后一个token “the”时,只需计算the本身所对应的query与上文中3个token对应的key的内积(这里说的上文中的3个token 包括the自己在内)
  2. 在每个注意力层,信息可以向前移动W个token。因此,在k层注意力之后,信息最多可以向前移动k个×W个token
    At each attention layer, information can moveforward by W tokens. Hence, after k attention layers, information can move forward by up to k ×W tokens.

4.1.2 滚动缓冲区缓存(Rolling Buffer Cache)

固定的注意力长度意味着我们可以使用滚动缓存来限制我们的缓存大小(A fixed attention span means that we can limit our cache size using a rollingbuffer cache)

  1. 缓存的大小是固定的W,时间步长i的键和值存储在缓存的位置i mod W中。因此,当位置i大于W时,缓存中过去的值就会被覆盖,缓存的大小就会停止增加
    The cache has a fixed size of W, and the keys and values for the timestep i are storedin position i mod W of the cache. As a result, when the position i is larger than W, past valuesin the cache are overwritten, and the size of the cache stops increasing

    以“The cat sat on the mat”为例..
    当 i = 0 时,指The,0 mod  3=0
    当 i = 1 时,指cat,1 mod  3=1
    当 i = 2 时,指sat,2 mod  3=2

    当 i = 3 时,指on,3 mod  3=0
    当 i = 4 时,指the,4 mod  3=1
    当 i = 5 时,指mat,5 mod 3 = 2
  2. 在32k token的序列长度上,这减少了8倍的缓存内存使用,而不影响模型质量
    On a sequence length of 32k tokens, this reduces the cache memory usageby 8x, without impacting the model quality.

如果把缓冲区比作一座仓库,每存进一个新东西,都会占据相应的位置,而仓库的总容量是固定的,当仓库被装满时,就会把最早放入的东西移除,让新的物品继续进仓,相当于入仓时间更接近当前时间的物品则会留在仓库中,如此,即能在节约资源的同时保留一定长度的序列

4.1.3 预填充与分块:减少重复运算

在生成序列时,我们需要一个一个地预测token,因为每个token都以前面的token为条件。然而,prompt是提前知道的,我们可以用prompt预填充(k, v)缓存,即

  1. 如果prompt非常大,我们可以把它分成更小的块,用每个块预填充缓存。为此,我们可以选择窗口大小作为我们的分块大小。因此,对于每个块,我们需要计算缓存和块上的注意力
  2. 下图展示了注意力掩码在缓存和分块上的工作原理

    在预填充缓存时,长序列被分块,以限制内存使用
    我们把一个序列分成三个块来处理,“The cat sat on”,“the mat and saw”,“the dog go to”。上图中显示了第三块(“the dog go to”)发生的情况:它使用因果掩码(最右块)来关注自己,使用滑动窗口(中心块)来关注缓存,并且不关注过去的token,因为它们在滑动窗口之外(左块)

// 待更

4.2 LongLora LLaMA13B

// 待更

第五部分 模型的评估:如何评估审稿GPT的效果

5.1 斯坦福研究者如何评估GPT4审稿意见的效果

如下图所示

  • 针对LLM提出的Review与人类的Review,均分别使用一定的prompt交由GPT-4进行摘要处理
    即对LLM下达任务,要求其关注Review中潜在的拒绝原因,并以特定的JSON格式来提供Review所指出的关键问题所在,研究团队解释侧重关键问题的目的在于“Review中的批评直接有助于指导作者改进论文”
  • 将需要评估的LLM Review与人类Review由上一步得到的内容共同输入至GPT-4中,利用特定的prompt来指示GPT-4输出新的JSON内容,让GPT-4指出两个传入的内容中的匹配项,并且对匹配程度进行评估(5-10分)
    作者研究发现5分、6分的相似项置信程度不佳,因此设定7分以上视为“匹配”,再基于Hit = \frac{|A \cap B|}{ |A| }计算重叠程度,其中|A|为LLM提出的批评项数,|A \cap B|为LLM与人类提出的匹配批评项数

5.2 借鉴斯坦福的工作,我司如何评价审稿GPT的效果

上一节斯坦福研究者对模型review效果评估的工作看似很完美,不过其中有个小问题,即

  1. 尽管LLM可以根据指令遵循来基于Prompt的要求返回JSON格式的内容,但并非每次都能生成得到利于解析的JSON格式内容
  2. 但好在gpt-4-1106-preview和gpt-3.5-turbo-1106版本中提供了JSON mode,在接口中传入response_format={“type”: “json_object”}启用该模式、并在prompt中下达“以JSON格式返回”的指示后,将会返回完全符合JSON格式的内容

// 待更

至此,本文中已透露了很多我司论文审稿GPT项目的各种工程细节,这些细节网上很少有,毕竟商用项目,当然 更多在「大模型项目开发线上营」见

参考文献与推荐阅读

  1. GPT4当审稿人那篇论文的全文翻译:【斯坦福大学最新研究】使用大语言模型生成审稿意见
  2. GPT-4竟成Nature审稿人?斯坦福清华校友近5000篇论文实测,超50%结果和人类评审一致
  3. 几篇mistral-7B的中文解读
    从开源LLM中学模型架构优化-Mistral 7B
    开源社区新宠Mistral,最好的7B模型
  4. Mistral 7B-来自号称“欧洲OpenAI”Mistral AI团队发布的最强7B模型

创作、修改、完善记录

  1. 11.2日,开写本文
  2. 11.3日,侧重写第二部分、GPT4审稿的思路
  3. 11.4日,侧重写第三部分中的Mistral 7B
  4. 11.5日,继续完善Mistral 7B的部分
  5. 11.11日,更新此节:“2.2.2 如何让梳理出来的review结果更全面:多聚一”
    完善1.1.1节Meta nougat
    顺带感慨下,为项目落地而进行的技术研究,这种感觉特别爽,^_^
  6. 11.15,增加2.2节:对review数据的二次处理
  7. 11.18,优化2.2节中的部分描述
  8. 11.22,补充了第二部分关于论文审稿GPT第一版中数据处理部分的细节,比如对paper数据处理只是做了去除reference
    补充“3.2.3节 通过最终的prompt来处理review数据:ChatGPT VS 开源模型”的相关内容
  9. 11.23,新增此节:1.2 对2.6万篇paper的解析
  10. 11.25,考虑到数据解析、数据处理、模型训练之后,还得做模型的评估
    故新增一部分的内容,即第五部分 模型的评估:如何评估审稿GPT的效果

文章出处登录后可见!

已经登录?立即刷新

共计人评分,平均

到目前为止还没有投票!成为第一位评论此文章。

(0)
社会演员多的头像社会演员多普通用户
上一篇 2023年12月4日
下一篇 2023年12月4日

相关推荐