如何1秒内快速总结100多页文档？QQ 浏览器首次揭秘大模型实现技术细节
嘉宾 | 郭伟东
QQ 浏览器是一个月活跃用户超过 4 亿的综合信息平台，旨在满足用户在搜、刷、用、看四个场景下的需求。
其中「用」是指 QQ 浏览器里工具的使用，也称为帮小忙，QQ 浏览器包含了众多实用工具，帮助用户提高工作和学习效率。今天我们讨论的文档阅读助手就是"帮小忙"中的一个工具。
长内容消费一直是用户非常重要的诉求，如何帮助用户快速了解长内容中的关键信息，也一直是各产品努力的方向，如网页速览、电影速看和小说速读等。
但是它们普遍存在一个问题：当用户想要深入了解内容时，由于缺乏交互能力和实时更新能力，往往无法满足需求, 所以是一种被动式的信息获取方式。
正因如此，QQ 浏览器做了一款产品: 文档阅读助手，可以让用户更加自由，更加自主地获取信息。同时秉承腾讯“科技向善”的理念，也会推出关怀模式和无障碍模式，让每个人的阅读都更简单。
以下是产品的 Demo 演示：
语言模型的发展始于 20 世纪 80 年代，最初基于统计方法，主要计算词汇在语料库中的概率。这一阶段，由于词汇量巨大，尤其是对于中文，需要处理庞大的统计空间，特别是多个词连续出现的概率。
第二阶段起始于 2003 年，Bingo 把神经网络引入到 NLP 领域，在 2013 年以 Word2Vec 模型推向高峰。主要特点是为每个词汇分配一个固定的向量表达（embedding），克服了以往统计方法的不足。但这种方法也存在问题，同一个词只有一个向量表示，对于多义词并不能区分，如“Bank”在“河岸”和“银行”不同的语义下，对应的 embedding 相同。
第三阶段以 BERT 为代表，主要做上下文相关的嵌入向量，允许相同的词在不同上下文中具有不同的表达，从而显著提高了模型的迁移性，NLP 的学习范式也由 end2end 方式变为预训练 + 业务微调的方式。
最后，是大语言模型阶段。2017 年，谷歌发布了具有里程碑意义的"Attention is All You Need"论文，介绍了 Transformer 模型。此后，几乎所有的大语言模型都基于 Transformer 结构。
从 2018 年到 2020 年，大语言模型领域的探索期。尽管 Transformer 架构已成为统一标准，但其包含的 Encoder 和 Decoder 两个关键部分被不同研究者以不同方式探索。
例如，OpenAI 的 GPT 系列是典型的 Decoder Only 模型，专注于自然语言生成任务；而谷歌的 BERT 模型则作为双向语言模型主要使用 Encoder 部分，专注于自然语言理解任务。这一时期，研究者们大量对 BERT 进行改进和变体研究。到 2019 年，谷歌推出了 T5 架构，旨在将理解和生成统一到一个框架下。
现在来看，GPT 系列成为了大家普遍的模型结构。但是当时虽然出现了参数规模巨大的模型如 GPT-3，这些模型在生成能力上非常强大，但是对于指令的理解并不好。2021 年，谷歌推出 FLAN 模型，并引入了指令微调（Instruct Tuning）技术，极大地增强了模型对具体指令的理解和执行能力。
到了 2022 年，模型发展进一步加速， OpenAI 提出 InstructGPT，不仅整合了指令微调技术，还引入了强化学习，使模型产出的答案更加符合人类的预期。直到 2022 年底，OpenAI 推出 ChatGPT 产品，全世界都为之振奋。
大语言模型主要通过提示工程和定制化模型两种方法来支持业务。
提示工程通过调整模型的输入指令（Prompt）以获得期望的输出格式和内容。例如，在生成问题时，可以通过精心设计的提示来引导模型产生更为结构化的内容。这种方法的优点在于不需要重新训练模型，仅通过修改输入指令即可快速适应各种业务场景，但它要求模型本身具有很全面的能力，模型往往比较大，对应的推理成本会比较高。
另一种方式是定制化模型。通过在特定业务数据上进行微调来优化大语言模型，使其更贴合业务场景。比如，针对数学场景，可以用数学数据集上进行微调以确保模型按需提供准确解答。这样的模型更专注于特定任务，可以允许更小的规模和降低推理成本。
QQ 浏览器文档阅读助手就是在腾讯混元模型的基础上定制化得到的业务大模型。腾讯混元大模型是全链路自研的通用大语言模型，拥有超千亿参数规模，预训练语料超 2 万亿 tokens，具备强大的中文创作能力，复杂语境下的逻辑推理能力，以及可靠的任务执行能力。为了更匹配应用场景的需求，腾讯也推出千亿、百亿以及十亿等不同尺寸的大模型。
目前，腾讯内部已有超过 300 项业务和应用场景接入腾讯混元大模型内测，包括 QQ 浏览器、腾讯会议、腾讯文档、企业微信、腾讯广告和微信搜一搜等。
要进行全文总结，先要阅读并理解原文，然后提取关键信息并进行概括。许多用户上传的 PDF 文件都很长。而现有的主流开源模型支持的上下文长度为 4000 Token 或更少，这意味着它们不能一次性处理过长的文章。
图 1：用户 PDF 长度分布
为了达到这一目标，有两种主要方法可以用来扩展上下文长度：
第一种是在训练阶段使用更长的上下文，但这会导致显著的显存和算力消耗增加，因为 Transformer 架构的显存需求与支持的长度平方成正比；
第二种是推理时通过某种方式扩展上下文长度，比如插值，但是扩展的范围有限。
虽然这些方法确实能在一定程度上扩展上下文长度，但它们都有局限性，要么是成本过高，要么是扩展长度有限。
因此，可以用以下几种方案，解决长文章摘要的问题：
第一种方案，不管文章多长，只取前 K 个 Token 供模型处理，然后生成摘要，但会丢失部分文章信息；
第二种，称为 MapReduce 的方法。先把文章分成 N 个片段，然后将每个片段分别输入模型，分别得到每部分的摘要。然后，将这 N 个摘要片段合并，形成一个新的文档，再次调用大语言模型进行最终总结。这个方案会多次调用大型语言模型，导致较高的成本和较长的处理时间。此外，由于语言模型生成的段落摘要可能存在不准确的情况，因此在最终全文总结中可能会累计错误。
为了解决这些问题，我们采用了一种结合抽取式和生成式的方法。
首先，我们在文章中识别并抽取出最重要的句子，然后使用大语言模型对这些抽取的句子进行概括和总结。方法只调用一次大语言模型，耗时较少，并且不容易遗漏重要信息。在实际测试中，这种方法用户满意度最高，而且事实一致性也最低。
为了提升用户获取信息的效率，产品会推荐一些用户可能问的问题，最直接的方法就是 LLM 利用原文信息生成一些问题。但是这种方法生成的问题通常都是非常简单的，与原文表达方式高度一致。
以腾讯第三季度的财报为例，原文提到“第三季度腾讯的总收入是多少元”，而生成的问题通常会直接是“第三季度腾讯的总收入是多少元？”。但是，实际上用户可能会用更口语化的方式表达，比如说“腾讯赚了多少钱？”。
真实的用户也会提出复杂的问题。例如，用户可能会问“从腾讯的财报中，我们能看出什么样的战略布局？”。
2023年，微软发布了一篇关于'进化学习'的论文 WizardLM，主要通过广度进化和深度进化让 SFT 数据更加丰富，复杂度也更高，从而提升模型效果。图 2 展示了随着迭代次数增加，问题长度的变化，可以看出问题复杂度随着进化轮数增多而增加。但问题的可用性却在持续下降，到了第五轮时，可用性已经下降至 85% 以下。
图 2:WizardLM 不同轮次的进化问题长度
图 3:WizardLM 不同轮次的训练样本可用率
针对上述问题，我们提出了一套新的进化算法——杂交进化，如图 4 示例所示：“小明是一个爱读书的人，他有一定的读书效率；小红则是一个爱写作的人，她有一定的写作速度”。杂交进化算法中，结合这两个种子的特点，能够生成一个更加复杂的问题，使得原本两个简单的问题被转化成了一个更加复杂的问题。
图 4：杂交进化示例图
与 WizardLM 相比，杂交进化方法有以下几个显著特点。首先是生成效率更高。WizardLM 方法如果总的种子数量是 n，每一轮进化生成新的 n 个样本，经过五轮后，总共只能新增 5n 个样本。而杂交进化，通过两个种子样本生成一个新的样本，增加效率是 n 乘以 n-1，所以当种子样本数量较多时，生产效率远超过微软的方法，并且杂交只需要进化一轮，准确率也更高。
其次，在样本的主题分布上，生成的样本（红色部分）相较于种子样本（蓝色部分）主题更加多样，对于大模型的训练帮助更大，更详细的细节可以参考我们的论文。
通过对用户真实问题的统计分析，我们发现用户问题主要分为四类：
原文中有答案的问题（Close QA）
原文中没有但互联网上有答案的问题（Open QA）
原文和网页中都没有答案，但基于基础信息可以深加工得到答案的问题（Agent QA）
依赖大模型通用能力的问题
最后一类问题混元模型本身可以解决很好，因此这里不需要特殊处理。
对于原文中有答案的问题，关键是通过检索系统找到与该问题相关的文本。根据用户问题检索相关文本之前需要对问题进行改写。因为在多轮对话中，用户常常会省略一些词汇，所以先对问题进行改写，然后再检索。
我们尝试了三种检索方法。首先是双塔架构，但在我们的场景下并不理想，召回率大约在 80% 左右。主要是原文片段经过 Pooling 方法进行语义压缩，导致相关文本片段的语义被稀释。如：一段 500 字的文本可能只有 50 字与问题直接相关，pooling 后的语义会稀释掉 50 字的语义，导致召回不足。
因此，我们尝试了第二种架构，保留了 500 字每一个词的向量表示，并计算与问题中每一个词的相似度。通过取片段的最大相似度作为整个文本片段的相似度，，这样虽然效率有所下降，但准确率有显著提升，在业务数据集中，效果超过 text-embedding-ada-002。
最后一种情况，针对答案分布在不同的文本片段的情况，做了进一步的改进，效果也得到了进一步的提升。
Open QA 与 Close QA 的主要区别在于原文中没有问题答案，但是互联网上有相关信息，可以通过 QQ 浏览器的搜索引擎提供相关网页，然后通过大型语言模型输出答案。
Agent QA 系统是解决原文和搜索引擎都无法提供答案时，大型语言模型将复杂任务分解成若干小步骤，然后分而治之。如: 用户想要了解腾讯流动利率时，LLM 回进行如下分解：首先，搜索流动利率的计算方法，即流动资产除以流动负债；然后，找出具体的流动资产和流动负债的数值；最后，使用计算器计算出流动利率。
这种方法听起来很好，但是存在一个问题，在专业领域，大型语言模型通常会泛泛而谈，模型往往无法规划出具体的执行步骤。为了解决这个问题，我们提出了一种新的解决方案：语言模型 + 专家知识库。
假设有一个专业问题关于“公司是否存在非法占用现金的情况”，大模型并不能做任务拆解，可以在知识库中检索到最相关的规划，然后让大型语言模型参考这个规划完成任务。实验显示，专家知识库可以显著提升专业领域问题的效果。
LLM 回复非常灵活，自动化评估是加速模型迭代效率的重要部分。以摘要功能为例，一种常用的方法是将完整文章和生成的摘要输入到大语言模型中，让 LLM 判断摘要的质量。
然而，这个方法的挑战在于，原文常含有大量无关信息，这可能导致模型错误地判断摘要是否准确反映了原文的主旨，详见参考文献。
第二种评估方法可以参考 TACL 的一篇论文。这个方法通过比较每个生成的摘要句子与原文中的句子是否相似来判断摘要是否产生幻觉。如果所有句子都足够相似，就认为摘要没有产生幻觉。但是，因为摘要通常是多个句子的汇总，当遇到融合性或概括性句子时，这个方法就不再有效，详见参考文献。
为了克服这一限制，我们采用了检索增强型方法，将精准问答的思想应用于自动评估。结果显示，在公开的摘要生成数据集上，我们的方法的问题可用率是最高的，达到了业界领先水平。
在训练过程中提升收敛速度也是一个加速模型迭代的重要方法。训练过程中，每个批次可能包含不同长度的样本，常规用 padding 的方法会浪费算力。我们采用了 Packing 策略，将多个短样本拼接在一起，以减少无效的填充部分，使得每个批次的计算更加高效。
实验表明，在达到相同训练效果的情况下，Packing 训练时长约 Padding 方式的 64.1%。因此，Packing 策略大大提高了训练的效率和模型的收敛速度。
今日荐文
前阿里员工抄袭YC初创公司并开源，老外：反正官司打不赢，不费那个劲了
国产GTPs上线！智谱AI推出GLM-4全家桶，我们浅试了一下
“AI女友”霸占GPT商店，OpenAI苦不堪言：开发者也难出头！
工资暴跌，还要训练AI替代自己？数据标注员正在被大厂抛弃
你也「在看」吗？ 👇
微信扫码关注该文公众号作者