《书生·浦语大模型实战营》第1次学习笔记

《书生·浦语大模型实战营》第1次学习笔记

• 《书生·浦语大模型实战营》第1次学习笔记
  • 光谱图
  • 学习动机
  • 本次学习
  • 视频笔记
    • 大模型成为发展通用人工智能的重要途径
    • 书生浦语大模型开源历程
    • 书生浦语 2.0 (InternLM2) 的体系
    • 回归语言建模的本质
    • 书生浦语 2.0 (InternLM2) 的主要亮点
    • 性能全方位提升
    • 贴心又可靠的AI助手
    • 充满人文关怀的对话
    • 富有想象力的创作
    • 工具调用能力升级
    • 强大的内生计算能力
    • 代码解释器：更上一层楼
    • 实用的数据分析功能
    • 从模型到应用
    • 从模型到应用典型流程
    • 书生浦语的全链条开源开放体系
    • 全链条开源开放体系|开放高质量语料数据
    • 全链条开源开放体系|预训练
    • 全链条开源开放体系|微调
    • 全链条开源开放体系|评测
    • CompassRank：中立全面的性能榜单
    • CompassKit：大模型评测全栈工具链
    • CompassHub：高质量评测基准社区
    • OpenCompass助力大模型产业发展和学术研究
    • 洞见未来：年度榜单与能力分析
    • 洞见未来：OpenCompass年度榜单(综合性客观评测)
    • 洞见未来：OpenCompass年度榜单(主观评测-对战胜率)
    • 全链条开源开放体系|部署
    • 全链条开源开放体系|智能体
  • 论文阅读报告
    • 论文摘要
    • 上下文200k
    • 数据格式化
    • 数据清洗
    • 大海捞针(Needle-in-the-Haystack)
  • 其他
    • 一篇2024年2月的RAG综述
      • RAG Foundations
        • Query-based RAG
        • Latent Representation-based RAG
        • Logit-based RAG
        • Speculative RAG
      • RAG Enhancements
        • Input Enhancement
        • Retriever Enhancement
        • Generator Enhancement
        • Result Enhancement
        • RAG pipeline Enhancement
    • 之前参加《AIGC提示词工程师》培训

光谱图

先说学习总结

学习动机

2022年12月1日，ChatGPT发布，迅速发展，成为互联网历史上最快达到一亿用户的产品。我在互联网行业有二十多年的经验，看到ChatGPT的时候就仿佛小时候第一次接触计算机、1996年上大学后第一次接触互联网、2008年第一次购买iPhone一代手机。

2023年，随着以ChatGPT为代表的AIGC（生成式AI，GenAI）的快速发展，就开始找资料，渐渐理解了这不同于以往的搜索引擎的大规模集群方案，而是把海量知识压缩到一个很小的模型中。

最开始体验各种网上应用，然后看介绍资料，随着开源本地化部署的发展，开始体验Ollama、Ava、Jan、LM Studio、LocalAI等本地化部署，LangChain JavaScript、LangChain Python、Semantic Kernel（.Net）、LlamaIndex TypeScript、LlamaIndex Python等开发框架。

这期间也开始接触相关商业机会，拜访上下游客户了解实际需求。

随着理解逐渐清晰，深感需要更快速的学习，开始寻找培训。

2024年1月参加《AIGC提示词工程师》培训，学习后深感还需要继续学习。

本次学习

2024年3月开始参加《书生·浦语大模型实战营》

https://openxlab.org.cn/models/InternLM/subject

相关链接

https://github.com/InternLM/InternLM

https://huggingface.co/internlm

https://modelscope.cn/organization/Shanghai_AI_Laboratory

https://openxlab.org.cn/models/InternLM

这是第一次学习笔记，主要是结合近期对于行业的理解，记录学习过程中的一些想法。

笔记内容没有严格注明引用内容和学习心得，课程内容请看视频。

视频笔记

本次课程

https://github.com/InternLM/Tutorial/tree/camp2

第一次课程录播链接

https://www.bilibili.com/video/BV1Vx421X72D/

大模型成为发展通用人工智能的重要途径

从专用模型向通用模型发展，这也就意味着人工智能的产业协作方式发生改变，之前人工智能在产业的应用可以简化为这样的流程。

在这种流程中，项目实施往往仅起到辅助作用，随着通用大模型的发展，期望项目实施可以在项目中起到主导作用

书生浦语大模型开源历程

• 2023年7月6日InternLM全面开源
• 2024年1月17日开源InternLM2

从这个节奏看，未来向客户交付大模型也需要按照半年的周期预估更新频率。

书生浦语 2.0 (InternLM2) 的体系

• 7B
  • 为轻量级的研究和应用提供了一个轻便但性能不俗的模型
• 20B
  • 模型的综合性能更为强劲，可有效支持更加复杂的实用场景

之前测试过其他的7B模型，感觉和商用有距离，估计商用还是需要20B

• InternLM2-Base
  • 高质量和具有很强可塑性的模型基座，是模型进行深度领域适配的高质量起点
• InternLM2
  • 在Base基础上，在多个能力方向进行了强化，在评测中成绩优异，同时保持了很好的通用语言能力，是我们推荐的在大部分应用中考虑选用的优秀基座
• InternLM2-Chat
  • 在Base基础上，经过SFT和RLHF，面向对话交互进行了优化，具有很好的指令遵循、共情聊天和调用工具等的能力

具体商用的情况比较复杂，更多需要商业客户的实际需求来确定。

回归语言建模的本质

书生浦语 2.0 (InternLM2) 的主要亮点

• 超长上下文200k
• 综合性能全面提升
• 优秀的对话和创作体验
• 工具调用能力整体升级
• 突出的数理能力和实用的数据分析能力

在商业项目调研中发现，上下文是比较难以解释的事情，因为随着技术的发展，客户对于数据的数量级有了较高的期望，会关注总数据处理能力，超长上下文能为实际项目的具体技术选型提供灵活的弹性。

性能全方位提升

贴心又可靠的AI助手

充满人文关怀的对话

富有想象力的创作

工具调用能力升级

这是商业项目的刚需，特别是和存量数据的集成。

强大的内生计算能力

• 高准确率
• 复杂运算和求解

代码解释器：更上一层楼

实用的数据分析功能

这是商业项目的刚需，特别是和存量数据的集成。

从模型到应用

• 智能客服
• 个人助手
• 行业应用

从模型到应用典型流程

这是商业方案中技术方案需要重点考虑的因素。

书生浦语的全链条开源开放体系

从实际商业项目的调研来看

• XTuner微调是刚需，特别是LoRA这种低成本微调，能和RAG连续覆盖场景和成本，在一定范围内，预计避免随着数据规模增加出现成本激增的情况
• LMDeploy部署是刚需，从过去二十多年的商业项目经验来看，客户对于部署这类非直接需求的费用比较敏感
• OpenCompass评测是刚需，实际商业项目不需要全方位评测，更多的可能是针对商业项目的需求编写评测集，保障微调达到预期效果
• Lagent和AgentLego是刚需，实际商业项目中需要针对存量数据进行定制开发

全链条开源开放体系|开放高质量语料数据

全链条开源开放体系|预训练

全链条开源开放体系|微调

• 增量续训
• 有监督微调

XTuner微调是刚需，特别是LoRA这种低成本微调，能和RAG连续覆盖场景和成本，在一定范围内，预计避免随着数据规模增加出现成本激增的情况

和前面内容可以构成一个技术选型矩阵

全链条开源开放体系|评测

CompassRank：中立全面的性能榜单

CompassKit：大模型评测全栈工具链

• 数据污染检查
• 更丰富的模型推理介入
• 长文本能力评测
• 中英文双语主观评测

CompassHub：高质量评测基准社区

OpenCompass助力大模型产业发展和学术研究

洞见未来：年度榜单与能力分析

洞见未来：OpenCompass年度榜单(综合性客观评测)

• 整体能力仍有较大提升空间
• 复杂推理仍是短板
• “理科”能力和模型尺寸关联性高
• 模型主客观性能需综合参考

洞见未来：OpenCompass年度榜单(主观评测-对战胜率)

全链条开源开放体系|部署

LMDeploy部署是刚需，从过去二十多年的商业项目经验来看，客户对于部署这类非直接需求的费用比较敏感

全链条开源开放体系|智能体

• 轻量级智能体框架Lagent
  • 代码解数学题
  • 零样本泛化：多模态AI工具使用
• 多模态智能体工具箱AgentLego

Lagent和AgentLego是刚需，实际商业项目中需要针对存量数据进行定制开发

论文阅读报告

论文链接

https://arxiv.org/pdf/2403.17297.pdf

论文摘要

大型语言模型（LLMs）如ChatGPT和GPT-4的发展引发了关于通用人工智能（AGI）来临的讨论。然而，将这样的进步应用到开源模型中一直颇具挑战。本文介绍InternLM2，一个开源的大语言模型，它在6个维度和30个基准的全面评估中超越了其前身，特别是在长序列建模和开放性主观评估方面，通过创新的预训练和优化技术实现了这一突破。InternLM2的预训练过程详细阐述，特别强调了对多样数据类型的准备，包括文本、代码和长文本数据。InternLM2有效地捕捉长期依赖性，预训练阶段从4k个token开始，然后扩展到32k个token，其在200k个“大海捞针”测试中的表现优异。InternLM2还通过监督微调（SFT）和一种基于人类反馈的新型条件在线强化学习方法（COOL RLHF）策略进行进一步校准，以解决人类偏好冲突和奖励策略滥用问题。我们通过发布不同训练阶段和模型大小的InternLM2，为社区提供了模型演进的洞察。

上下文200k

如何有效地延长大语言模型的上下文长度目前是研究的热点，因为许多下游应用，如检索增强生成（RAG） (Gao et al., 2023)和代理模型 (Xi et al., 2023)，依赖于长上下文。InternLM2首先采用分组查询注意力（GQA）来在推断长序列时减少内存占用。在预训练阶段，我们首先使用4k个上下文文本训练InternLM2，然后将训练语料库过渡到高质量的32k文本进行进一步训练。最终，通过位置编码外推 (LocalLLaMA, 2023)，InternLM2在200k个上下文中通过了“大海捞针”测试，表现出色。

这是我重点关注的领域，通过实际商业项目的调研，客户对于定期微调的成本还是比较敏感的，特别是现阶段难以评估定期微调是否能获得对应的收益。

项目实施的成本分析中，对于定期微调费用，可以简化为如下模型：

$$单次微调的成本>微调周期\times 单位时间使用次数\times (微调后新模型的收益-微调前原模型的收益)$$

初次微调可以训练海量的存量数据，后续微调的增量数据就少的多，难以体现价值。

因此借助长上下文的模型，使用RAG，就可以把项目的成本结构回归为传统的研发成本结构，易于被客户接受。

数据格式化

我们将以网页数据为例详细介绍数据处理流程。我们的网页数据主要来自Common Crawl。首先，我们需要解压缩原始的Warc格式文件，并使用Trafilatura (Barbaresi, 2021)进行HTML解析和主文本提取。然后，我们使用pycld2库进行语言检测和主文本分类。最后，我们为数据分配一个唯一标识符，并以jsonl（JSON行）格式存储，从而获得格式化数据。

实际商业项目的海量历史存量数据往往缺乏详细技术文档，此时直接从网页中获取内容反而比研究数据库结构更加方便快捷，然而网页解析的工具良莠不齐，选型比较困难。

读到这段也解答了工具选型的困惑

• Trafilatura
  • https://trafilatura.readthedocs.io/
  • https://github.com/adbar/trafilatura

数据清洗

从互联网随机提取的网页数据通常包含大量低质量数据，如解析错误、格式错误和非自然语言文本。常见的做法是设计基于规则的正则化和过滤方法来修改和过滤数据，如 (Rae et al., 2021)、C4 (Dodge et al., 2021)和RefinedWeb (Penedo et al., 2023)。基于对数据的观察，我们设计了一系列启发式过滤规则，重点关注分隔和换行中的异常、异常字符的频率以及标点符号的分布。通过应用这些过滤器，我们得到了干净数据。

互联网上存在的大量重复文本会对模型训练产生负面影响。因此，我们采用基于Locality-Sensitive Hashing (LSH)的方法对数据进行模糊去重。更具体地说，我们使用MinHash方法(Broder, 1997)，在文档的5-gram上使用128个哈希函数建立签名，并使用0.7作为去重阈值。我们的目标是保留最新数据，即优先考虑具有较大Common Crawl数据集版本号的数据。在LSH去重后，我们得到了去重数据。

这两段描述的方式也是实际商业项目中遇到的挑战

大海捞针(Needle-in-the-Haystack)

理论是一种单针检索任务，旨在测试大型语言模型(LLMs)回忆单个关键信息的能力。这是通过将关键信息插入目标长度的"海量"文本中的不同位置，然后在提示词的末尾询问模型关于这个关键信息的方式来实现的。这种方法精确地可视化了LLMs在不同长度的长文本的不同位置的回忆能力。我们遵循原始想法设计了一个中文"海量文本"，并利用Wei等人(2023)发布的Skywork/ChineseDomainModelingEval数据集，确保中文文本的来源具有多样性和质量。该数据集涵盖了从金融到技术的广泛领域，提供了高质量、 最新的中文文章，为评估不同模型处理特定领域长文本的能力提供了稳定的基准。在这个实验中,我们利用LMDeploy(Contributors, 2023a)推理引擎来加速推理过程。图13中的结果有效地展示了InternLM2的长文本建模能力。

从大海捞针的结果可以看出，实际商业项目中选择144k作为分界点

其他

一篇2024年2月的RAG综述

https://arxiv.org/pdf/2402.19473.pdf

Retrieval-Augmented Generation for AI-Generated Content A Survey

RAG Foundations

Query-based RAG

利用用户query检索得到相关文档，将检索结果跟用户query拼接到一起作为生成模型的输入。这是利用外部检索知识显示指导生成模型的方式，也是目前RAG主流的范式。这种范式的兴起跟生成模型能力不断提升有非常大的关系，尤其是到了大模型的时代，由于大模型的能力相当强大，所以只要直接将外部知识跟其他输入一起喂给大模型，大模型自身就可以处理这些信息并生成合适的回复，简单粗暴且效果不错。

Latent Representation-based RAG

利用用户query检索得到相关文档，并获取对应文档的向量表征，在生成模型生成阶段融入知识文档的表征信息。这是一种利用外部检索知识隐式指导生成模型的方式，生成模型会跟检索知识的向量表征进行交互，从而增强生成模型的理解能力跟生成文本的质量。最典型的就是FiD，这种范式在大模型时代前也曾一度流行，由于当时生成模型的能力不足，于是出现这种想在decoder阶段直接注入外部知识的方案，能够让检索枷锁更加直接地干预到生成结果。

Logit-based RAG

生成模型在decoder阶段计算下一个token的logit时，同时考虑生成预测的结果跟检索模块返回的信息。可以理解为将检索模块跟生成模块视作两个独立的链路，分别计算对应的下个token输出的logit值，再将两个链路的logit联合起来。最典型的就是knn-LM。

Speculative RAG

利用检索模块来替代生成模块的方式，主要用于节省资源跟加速文本生成。可以理解为利用检索结果提供一段候选回复，让生成模型判断这段候选回复是否适合作为最终结果，适合的话就保留，不适合的话就从不适合的位置起进行截断，然后重复上述过程。最典型的就是REST。

RAG Enhancements

Input Enhancement

用户query的质量会明显影响到检索模块的结果，可以通过query改写，数据增强等方式提升用户query的质量。

Retriever Enhancement

检索模块提供的内容质量越高，生成模块的效果越有保证。提升检索文章质量的以下几种方式。

1. recursive Retrieve 对用户query进行合理切分，再分别进行检索。

2. chunk optimaization 调整数据库的大小，例如sentence-window retrieval这种检索到特定文本后，将该文本的窗口内其他文本也一同返回。

3. finetune retriever 利用高质量的领域数据或者特定任务数据对embedding模型进一步微调。

4. hybrid retrieve 同时利用稠密检索跟稀疏检索等多种检索方案

5. re-ranking 利用额外的精排模型对召回结果做进一步排序。

6. meta-data filtering 利用某些属性对数据做进一步过滤

Generator Enhancement

生成模型的能力决定了整个RAG系统的上限。

1. prompt engineering 懂得都懂，大模型对于prompt还是很敏感的，正确掌握大模型的使用方式可以得到足够惊艳的效果。

2. decoding Tuning 在decoder阶段增加更多控制，调整解码参数以提升多样性，或者将输出词表限制到特定空间等等。

3. finetune generator 对生成模型做进一步finetune使得生成模型更适配特定领域或者检索模块。

Result Enhancement

若生成模型的结果未能达到预期效果，还能对结果进一步修饰。

RAG pipeline Enhancement

1. adatpive retrieval 在检索模块前新增一个模块，根据用户query判断是否需要调用外部知识库，避免滥用检索造成的资源浪费跟模型幻视问题。

2. iterative RAG 迭代RAG，反复调用检索-生成这个pipeline以获得更佳效果。

之前参加《AIGC提示词工程师》培训