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

前言

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

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

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

爬取了3万多篇paper、十几万的review数据，并对3万多篇PDF形式的paper做解析(review数据爬下来之后就是文本数据，不用做解析)
当然，paper中有被接收的、也有被拒绝的
为提高数据质量，针对paper和review做了一系列数据处理
当然，主要是针对review数据做处理(具体而言是，对paper做的是去掉reference，剩下其他都是对review做的数据处理)
基于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就可以驱动起来了

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

环境配置

# 新建虚拟环境
conda create -n nougat-ocr python=3.10
# 激活虚拟环境
conda activate nougat-ocr
# 使用pip安装必要库（镜像源安装可能会出现版本冲突问题，建议开启代理使用python官方源进行安装）
pip install nougat-ocr -i https://pypi.org/simple

使用方法

# 初次使用时会自动获取最新的权重文件
# 针对单个pdf文件
nougat {pdf文件路径} -o {解析输出目录}
# 针对多个pdf所在文件夹
nougat {pdf目录路径} -o {解析输出目录}

测试示例
标题及开头
公式识别与转换
脚注识别

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万篇 )

我司审稿项目组的其中一位用的2张24G的P40解析完其中一半，另外一半由另一位用的48G的A40解析完
因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点处理

过滤需求外的Review
主要是去掉作者自己的回复，以及对paper的评论
将Review字符串化
过滤内容过少的Review
将Review的内容规范出4个要点且进行“多聚一”，下文详述

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

// 待更

第三部分对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给你审稿呢？具体来说，如下图所示

爬取PDF语料
接着，解析PDF论文的标题、摘要、图形、表格标题、主要文本

然后告诉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.

最终，GPT-4针对上图中的这篇论文一针见血地指出：虽然论文提及了模态差距现象，但并没有提出缩小差距的方法，也没有证明这样做的好处

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

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

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

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

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

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

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

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

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

一种是多选一
但多选一有个问题，即是：如果那几个review都不是很全面呢，然后多选一的话会不会对review信息的丰富程度有损
一种是多聚一
对多个review做一下总结归纳(阿荀、我先后想到)，相当于综合一下，此时还是可以用GPT 3.5 16K或开源模型帮做下review数据的多聚一
一种是多轮交互
这种工作量比较大，非首选

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

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

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

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

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

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

zephyr-7b-alpha
Mistral-7B-Instruct-v0.1
OpenAI刚对外开放的gpt-3.5-turbo-1106，即上一节图中的GPT3.5 Turbo 16K

经过对比发现，用OpenAI的gpt-3.5-turbo-1106效果相对更好些，能力更强效果更好，加之经实际研判，费用也还好不算高

// 待更，具体怎么个对比法，以及怎么个效果更好，暂在线上营里见，至于本文后续更新

不过我们在实际使用的过程中，发现OpenAI对API的访问有各种限制且限制的比较严格(即对用户有多层限制：https://platform.openai.com/docs/guides/rate-limits/usage-tiers?context=tier-one，比如分钟级请求限制、每日请求限制、分钟级token限制、每日token限制 )，访问经常会假死不给返回、也没报错，所以很多时间耗费在被提示“访问超限”，然后等待又重复访问、再被提示超限这样的过程，使得我们一开始使用OpenAI的官方接口23年11.24到11.30大概7天才出了2600多条，并且后续限制访问的出现频率愈加高，头疼..

后面实在没办法，我们找了一个国内的二手商，最终调二手商的接口，而二手商调OpenAI的接口，于此，用户访问频率限制、代理等问题就让二手商那边解决了(我们也琢磨了下为何二手商可以解决这类访问限制的问题，根据以往的经验，我们判断，应该是二手商那边的OpenAI账户很多、代理路线很多，做了统一调度管理，然后在用户调用的时候选取当前低频的官方账户来访问官方接口，时不时还自动切换下代理，要知道一个代理被用来高频访问OpenAI的时候，其实有可能是会被放进黑名单的，所以持续维护一个代理池来做自动切换也很重要 )
当然，二手商的接口晚上(或者别的高峰期)有时候还是会返回访问受限的提示，那时候应该用的人比较多，导致即使“最低频访问”的官方接口，访问频率也不算低了，所以也会被访问受限
最终，使用二手商的中转接口，12.04到12.08大概5天出了9000多条

// 待更

3.3 相关工作之AcademicGPT：增量训练LLaMA2-70B，包含论文审稿功能

3.3.1 AcademicGPT: Empowering Academic Research

11月下旬，我司第二项目组(即负责论文审稿GPT的项目组)的阿荀发现

有一个团队于23年11.21日，在arXiv上提交了一篇论文《AcademicGPT: Empowering Academic Research》，论文中提出了AcademicGPT，其通过学术数据在LLaMA2-70B的基础上经过继续训练得到的
然后该团队AcademicGPT的基础之上延伸开发了4个方面的应用：学术问答、论文辅助阅读、论文评审、标题和摘要的辅助生成等功能，由于其中的论文问答、论文摘要等功能已经很常见了(比如此文提到的chatpaper、中科院一团队的gpt_academic都通过GPT3.5的API做了还可以的实现)，但论文评审此前一些开源工具通过GPT3.5做的效果并不好，所以既然AcademicGPT做了论文审稿这一功能，而且还用了70B的模型，那必须得关注一波，于是便仔细研究了下他们的论文
(当然，我相信，他们很快也会关注到我司论文审稿GPT这个工作，然后改进他们的训练策略，毕竟同行之间互相借鉴，并不为怪 )

他们与我们有两点显著不同的是，一者，他们对LLaMA做了增量预训练(AcademicGPT is a continual pretraining on LLaMA2)，二者，我司目前的论文审稿GPT暂只针对英文论文的评审(毕竟七月的客户要发论文的话，以英文EI ei期刊 SCI论文为主，其次才中文期刊)，而他们还考虑到了中文，故他们考虑到LLaMA2-70B有限的中文能力与学术领域知识，所以他们收集中文数据和学术英文数据来对相关方面进行提高

中文数据：取自CommonCrawl、Baike、Books等(此外还从互联网爬取了200K学术文本)
由于CC这类数据通常会包含很多广告、色情等有害信息，所以需要对其进行数据清洗，最终他们借助LLM且使用下图所示的Prompt来对取自互联网的数据进行清洗，比如对文档进行各种标注
(根据论文原文，我们判断，他们应该是先让模型基于人类给的prompt 对一些文本做标注，之后ChatGPT对同样那些文本做标注，最后对比这两者之间的差异，建损失函数然后微调模型本身，差不多后，模型对剩下的文本做标注)
英文学术数据：爬取来自200所顶尖大学的100多万篇Paper、Arxiv的226万篇Paper(截止到23年5月)，其中较长的Paper使用Nougat进行解析(和我司七月一样 )、较短的Paper使用研究团队自己的解析器，此外还有4800多万篇来自unpaywall2的免费学术文章，以及Falcon开源的数据集中的学术相关数据

基于上述所得的120B的数据，他们使用192个40G显存的A100 GPU进行继续二次预训练(他们的所有工作我没有任何羡慕，但唯独他们有192块A100，让我个人着实羡慕了一把，好期待有哪个大豪可以解决下我司七月的GPU紧缺问题，^_^)，最终通过37天的训练，使得LLaMA2-70B进一步获得理解中文与学术内容的能力，以下是关于训练的更多细节

且为了加快训练过程，用了FlashAt-tention2 (Dao, 2023)，它不仅加快了注意力模块的速度，而且节省了大量内存，且通过Apex RMSNorm实现了融合cuda内核(Apex RMSNorm that implements a fused cuda kernel)
由于AcademicGPT是LLaMA2- 70b的二次训练模型，因此它使用了一些与LLaMA2相同的技术，包括
RMSNorm (Zhang and Sennrich, 2019)而不是LayerNorm,
SwiGLU (Shazeer, 2020)而不是GeLU
对于位置嵌入，它使用RoPE (Su et al.， 2021)而不是Alibi(Press et al.， 2021)
对于tokenizer，它使用BPE (Sennrich等人，2015)
且使用DeepSpeed (Rasley et al.， 2020)和Zero (Rajbhandari et al.， 2020)，且他们的训练基于gpt-neox (Black et al.， 2022)框架，其中我们集成了许多新引入的技能。使用具有40GB内存的192个A100 gpu完成120B数据的训练需要大约37天

3.3.2 论文评审：借鉴ReviewAdvisor归纳出review的7个要点(类似我司借鉴斯坦福工作把review归纳出4个要点)

他们和我司一样，都是从同一带有论文review的网站上收集了29119篇Paper和约79000条Review，然后经过下述处理

Paper侧处理：剔除了7115篇无内容或无Review的Paper、剔除了解析失败的Paper
Review侧处理：
- 剔除了具有过多换行符的Review
- 剔除了过短(少于100 tokens)，或过长(多于2000 tokens)的Review
- 剔除了与Decision Review决策不一致、且confidence低的Review
- 和我司「借鉴斯坦福用GPT4当审稿人，且让GPT4按照评判论文质量高低的4个要点给出审稿意见」类似
  他们则参考的是《Can We Automate Scientific Reviewing?》中的7个方面要点，去掉Summary所以是7个：
  $\rightarrow$ 1 动机/影响Motivation/Impact
  $\rightarrow$ 2 原创性Originality
  $\rightarrow$ 3 合理性/正确性Soundness/Correctness
  $\rightarrow$ 4 实质性Substance
  $\rightarrow$ 5 可复现性Replicability
  $\rightarrow$ 6 有意义的对比Meaningful Comparison
  $\rightarrow$ 7 清晰程度Clarity)
  使用该论文的源码对Review进行进一步标注，即抽取出相应的要点
  「具体而言，他们在归纳单篇review的7或8个要点时，给定一篇review，让模型逐个逐个的标注出每个token/词它可能所属的要点类别，模型对整篇review标注完以后，把有要点标注结果的内容给抽出来，比如下图，模型逐个对每个token标注出了summary(紫色)、clarity(黄色)、substance(橙色)等等，然后把带颜色的要点部分抽出来作为该篇review的归纳，其中+表示积极的情绪，-表示负面情绪」

最终，经过上面一系列梳理之后得到的paper数据 + 归纳好的review数据去微调70B模型

为方便大家理解，我补充一下关于这篇《Can We Automate Scientific Reviewing?》的解释说明

事实上，该篇论文的视角在于将“Review”视作对Paper的摘要与对应内容的评估，以此保证事实正确性。因此该篇论文考虑将Paper Review问题建模为摘要生成任务，采用当时(2021)较为先进的BART模型进行训练，得到ReviewAdvisor模型

通过设计好的评估系统，得出如下观察：

模型容易生成非事实性陈述

模型尚未学习到高级理解，如没法实质地分辨Paper的高质量与低质量

模型倾向于模仿训练数据的语言风格(倾向低级模式)，如容易生成训练样本中的高频句子

可以较好地概括论文核心思想

最终结论是：“模型评审还尚未能替代人工评审，但可以辅助人工进行评审”

这项工作有两个值得关注的地方：

增强Review数据(对review数据归纳出8个要点)
对于相对杂乱的Review内容来说，研究团队只想保留有用的“结构化”内容，因此他们将从定义“结构化方面”开始，从Review中取出相应的结构化内容，由此实现Review侧的数据增强
1 定义结构化方面
研究团队讨论出了他们所认为的一篇“好的Review”所应该具备的各个方面，包括如下8个要点：
Summary(SUM)：总结摘要
Motivation/Impact(MOT)：动机/影响
Originality(ORI)：原创性
Soundness/Correctness(SOU)：合理性/正确性
Substance(SUB)：实质性
Replicability(REP)：可复现性
Meaningful Comparison(CMP)：有意义的对比
Clarity(CLA)：清晰程度

2 人工标注
研究团队邀请6名具有机器学习背景的学生对原本的Review进行注释，注释手法倾向于“抽取式摘要”，即标注原文本中哪些片段属于何种类别「which are Summary (SUM), Moti-vation/Impact (MOT) , Originality (ORI), Sound-ness/Correctness (SOU), Substance (SUB), Repli-cability (REP), Meaningful Comparison (CMP)and Clarity (CLA)」
类似于“... ... The results are new[Positive Originality] and important to this field[Positive Motivation] ... ...”

3 训练标注器
考虑到人工标注全部数据并不现实，使用第2步标注过的Review数据训练一个BERT抽取模型作为标注器，用于自动标注原Review中的方面项。即输入Review文本，模型对文本进行逐token分类预测，预测出Review哪些部分属于哪些方面

4 后处理
使用标注器对余下数据进行标注后，其结果并不完全可信，需要制定规则或使用人工对标注器的预测结果进行校正

5 人工检查
邀请具有机器学习背景的人员检查标注结果

「注，当我们通过paper和上面归纳出来的review要点去训练了一个模型之后，便可以用新paper给到这个模型，然后让其输出review」

生成Review(针对新paper推理时生成带有8个要点的review)
根据给定Paper生成Review，模型选型为彼时最大长度为1024的BART模型，考虑到Paper的长度较长，因此整个生成Review的方案被设计成了两阶段的形式，即首先从Paper中择取出突出片段(输入上下文长度压缩)，然后基于这些突出片段来生成review摘要

选取突出片段
使用诸如“demonstrate”“state-of-the-art”等关键词及对句子的诸多规则判断来确定突出片段

训练方面感知摘要（Aspect-aware Summarizaiton）模型
基于基础Seq2Seq模型实现的是由输入序列(Paper)预测输出序列(Review)的过程，研究团队在这个基础上引入了“方面感知”来辅助模型进行预测，强调模型对“方面要点”的输出，即引入两个的多层感知机来分别进行生成任务：模型不仅要逐token生成Review内容，还要逐token预测其对应的“方面要点”
因此模型需要同时学习两个损失函数
$\mathcal{L}=\mathcal{L}_{\text {seq2seq }}+\alpha \mathcal{L}_{\text {seqlab }}$
这也意味着模型在一次推理中将输出2条序列，其一为预测的Review内容(其损失函数为 $\mathcal{L}_{\text {seq2seq }}$ )，其二为预测的方面要点(其损失函数为 $\mathcal{L}_{\text {seqlab }}$ )

3.3.3 70B的AcademicGPT在论文审稿上效果不佳的原因

根据原论文中展示的对一些论文做审稿的案例来看，其效果并不佳

下图是论文中的两个审稿案例

下图左侧部分是论文中的审稿案例1，可以看出来，它指出对应论文的缺点：“写作需要打磨。存在太多的拼写和语法错误。实验设置不够令人信服。首先，没有提供基线。其次，作者仅在单一数据集上进行了实验。第三，作者没有报告结果的方差。”
这种审稿意见对于论文作者本身而言，参考价值可能不大，毕竟当你指出有太多的拼写和语法错误，最好是具体指出来所谓的拼写和语法错误是在论文中哪一段

下图右侧部分是论文中的审稿案例2，但第5个Weaknesses的点「5. The writing of the paper could be improved. For example, the authors should explain what xt,i means in
Eq. (1) 」是说论文应该解释下公式(1)中 $x_{t,i}$ 的含义，但原论文的公式(1)不涉及 $x_{t,i}$

而效果不佳的原因有多个方面

与我司现在整个项目组全力以赴迭代论文审稿GPT不同，对于AcademicGPT而言，论文审稿只是他们4大应用中的其中一块
数据集review侧用的是早期的摘要抽取模型BART来收集的，而让早期模型抽取的结果不一定准确，毕竟和GPT3.5还是没法比的
对review内容做抽取式摘要时，直接照搬一部分原话
可review是由各式各样的人写的，原话风格高度不统一，模型可能会收敛困难，换言之，他们的数据是通过“抽取式摘要”拿出来的，即如上文所说：“给定一篇review，让模型逐个逐个的标注出每个token/词它可能所属的要点类别，模型对整篇review标注完以后，把有要点标注结果的内容给抽出来”

总之，他们与我司论文审稿GPT的差异就在于
他们是抽取式提取要点、我们是生成式提取要点
$\rightarrow$ 抽取式抽出来的是原话，但是原话措辞风格迥异，而且抽取式模型能力有限需要做很多人工核验等后处理
$\rightarrow$ 但对于生成式而言，尤其是LLM的生成式可以根据要求生成相对统一的措辞风格

当然，在没有实际开源出来让用户使用之前，也不好下太多论断，具体等他们先对外开放吧

第四部分模型的训练/微调：从Mistral、Mistral-YaRN到LongLora LLaMA13B

论文审稿GPT第二版在做模型选型的时候，我司考虑了三个候选模型：Mistral、Mistral-YaRN、Llama-LongLora，以下逐一介绍这三个模型，以及对应的训练细节、最终效果

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地址)

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.
该模型采用了分组查询注意力(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》
同时结合滑动窗口注意力(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)

每个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自己在内)
在每个注意力层，信息可以向前移动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)

缓存的大小是固定的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
在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)缓存，即

如果prompt非常大，我们可以把它分成更小的块，用每个块预填充缓存。为此，我们可以选择窗口大小作为我们的分块大小。因此，对于每个块，我们需要计算缓存和块上的注意力
下图展示了注意力掩码在缓存和分块上的工作原理
在预填充缓存时，长序列被分块，以限制内存使用
我们把一个序列分成三个块来处理，“The cat sat on”，“the mat and saw”，“the dog go to”。上图中显示了第三块(“the dog go to”)发生的情况：它使用因果掩码(最右块)来关注自己，使用滑动窗口(中心块)来关注缓存，并且不关注过去的token，因为它们在滑动窗口之外(左块)

4.2 Mistral 7B结合YaRN

YaRN的论文原文：https://arxiv.org/abs/2309.00071

// 待更

4.3 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效果评估的工作看似很完美，不过其中有个小问题，即

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

// 待更

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

参考文献与推荐阅读

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

创作、修改、完善记录

11.2日，开写本文
11.3日，侧重写第二部分、GPT4审稿的思路
11.4日，侧重写第三部分中的Mistral 7B
11.5日，继续完善Mistral 7B的部分
11.11日，更新此节：“2.2.2 如何让梳理出来的review结果更全面：多聚一”
完善1.1.1节Meta nougat
顺带感慨下，为项目落地而进行的技术研究，这种感觉特别爽，^_^
11.15，增加2.2节：对review数据的二次处理
11.18，优化2.2节中的部分描述
11.22，补充了第二部分关于论文审稿GPT第一版中数据处理部分的细节，比如对paper数据处理只是做了去除reference
补充“3.2.3节通过最终的prompt来处理review数据：ChatGPT VS 开源模型”的相关内容
11.23，新增此节：1.2 对2.6万篇paper的解析
11.25，考虑到数据解析、数据处理、模型训练之后，还得做模型的评估
故新增一部分的内容，即第五部分模型的评估：如何评估审稿GPT的效果
12.8，因为要在武汉给一公司做内训，且也将在「大模型项目开发线上营」里讲论文审稿GPT，所以随着该项目的不断推进，故
补充在通过OpenAI的API对review数据做摘要处理时，如何绕开API做的各种访问限制
新增一节：“3.3 相关工作之AcademicGPT：增量训练LLaMA2-70B，包含论文审稿功能”
12.9，重点优化此节的内容：“3.3.2 论文评审：借鉴ReviewAdvisor归纳出review的7个要点(类似我司借鉴斯坦福工作把review归纳出4个要点)”