写在最前，参加2024.04 DataWhale组队学习所写读书笔记。
项目github地址 https://github.com/datawhalechina/llm-universe

参考文章：
什么是LLM大语言模型？Large Language Model，从量变到质变
从零详细地梳理一个完整的 LLM 训练流程
一文读懂：大模型RAG（检索增强生成）
微调与RAG的优缺点分析
什么是LangChain
LLM领域有没有哪些理论上RAG可以解决，但是实际上还没有被RAG解决的问题？

1.LLM

1.1 LLM简介

大语言模型（LLM，Large Language Model），也称大型语言模型，是一种旨在理解和生成人类语言的人工智能模型。它们在大量的文本数据上进行训练，可以执行广泛的任务，包括文本总结、翻译、情感分析等等。LLM的特点是规模庞大，包含数十亿的参数，帮助它们学习语言数据中的复杂模式。这些模型通常基于深度学习架构，如转化器，这有助于它们在各种NLP任务上取得令人印象深刻的表现。

1.2 LLM发展

2003 年深度学习先驱 Bengio 在他的经典论文 《A Neural Probabilistic Language Model》中，首次将深度学习的思想融入到语言模型中。强大的神经网络模型，相当于为计算机提供了强大的"大脑"来理解语言，让模型可以更好地捕捉和理解语言中的复杂关系。

2017谷歌推出 transformer 模型，2018 年的时候谷歌提出了 Bert 的模型，然后到 GPT 2，从 340 兆到 10 亿 、15 亿，然后到 83 亿，然后到 170 亿，然后到 GPT3 1750 亿的参数。

最早的是 2017 年出来的，就是我们所了解的那个GPT， GPT 名字里面有一个叫做transformer，就是这个 transformer 模型。它是 2017 年出现的，其实也很早，所以计算机领域来说， 2017 年可以归结于上一个时代的产品。然后 2018 年第一代 GPT 出来，当时还不行，相对来说比较差，性能也不行，然后像一个玩具一样。然后 2018 年谷歌又推出了一个新的模型，叫BERT，但是这些模型都是基于之前谷歌推出的这个 transformer 模型进行发展的。然后到了 2019 年， open AI 除了 GPT 2 也没有什么特别，就是它没有办法来产生一个语言逻辑流畅通顺的一段名词，你一看就知道这是机器写的。

但是到了 2020 年的5月， GPT 3 出来之后，其实就有了非常大的变化， GPT 3 的性能比 GPT 2 好很多，它的数参数的数量级大概是 GPT 2- 10 倍以上。

研究人员发现，随着语言模型规模的扩大（增加模型大小或使用更多数据），模型展现出了一些惊人的能力，在各种任务中的表现均显著提升。这一发现标志着大型语言模型（LLM）时代的开启。

1.3 市面常见的LLM

GPT-3（OpenAI）： Generative Pre-trained Transformer 3（GPT-3）是最著名的LLM之一，拥有1750亿个参数。该模型在文本生成、翻译和其他任务中表现出显著的性能，在全球范围内引起了热烈的反响，目前OpenAI已经迭代到了GPT-4版本在这里插入图片描述

BERT（谷歌）：Bidirectional Encoder Representations from Transformers（BERT）是另一个流行的LLM，对NLP研究产生了重大影响。该模型使用双向方法从一个词的左右两边捕捉上下文，使得各种任务的性能提高，如情感分析和命名实体识别。

T5（谷歌）： 文本到文本转换器（T5）是一个LLM，该模型将所有的NLP任务限定为文本到文本问题，简化了模型适应不同任务的过程。T5在总结、翻译和问题回答等任务中表现出强大的性能。

ERNIE 3.0 文心大模型（百度）：百度推出的大语言模型ERNIE 3.0首次在百亿级和千亿级预训练模型中引入大规模知识图谱，提出了海量无监督文本与大规模知识图谱的平行预训练方法。

星火大模型：讯飞星火认知大模型是科大讯飞发布的语言大模型，支持多种自然语言处理任务。该模型于 2023 年 5 月首次发布，后续经过多次升级。2023 年 10 月，讯飞发布了讯飞星火认知大模型 V3.0。2024 年 1 月，讯飞发布了讯飞星火认知大模型 V3.5，在语言理解，文本生成，知识问答等七个方面进行了升级，并且支持system指令，插件调用等多项功能。

1.4 LLM涌现的能力

上下文学习。GPT-3 正式引入了上下文学习能力：假设语言模型已经提供了自然语言指令和多个任务描述，它可以通过完成输入文本的词序列来生成测试实例的预期输出，而无需额外的训练或梯度更新。
指令遵循。通过对自然语言描述（即指令）格式化的多任务数据集的混合进行微调，LLM 在微小的任务上表现良好，这些任务也以指令的形式所描述。这种能力下，指令调优使 LLM 能够在不使用显式样本的情况下通过理解任务指令来执行新任务，这可以大大提高泛化能力。
循序渐进的推理。对于小语言模型，通常很难解决涉及多个推理步骤的复杂任务，例如数学学科单词问题。同时，通过思维链推理策略，LLM 可以通过利用涉及中间推理步骤的 prompt 机制来解决此类任务得出最终答案。据推测，这种能力可能是通过代码训练获得的。

2.RAG

2.1 RAG简介

RAG（中文为检索增强生成， Retrieval-Augmented Generation） = 检索技术 + LLM 提示。

例如，我们向 LLM 提问一个问题（answer），RAG 从各种数据源检索相关的信息，并将检索到的信息和问题（answer）注入到 LLM 提示中，LLM 最后给出答案。

2.2 RAG 的工作流程

标准的 RAG 流程简介：
知识库部分：
将文本分块，然后使用一些 Transformer Encoder 模型将这些块嵌入到向量中，将所有向量放入索引中。
检索部分：创建一个 LLM 增强提示，告诉模型根据我们在搜索步骤中找到的上下文回答用户的查询。

2.3 RAG 和 Finetune 对比

• 知识的局限性
  模型自身的知识完全源于它的训练数据，而现有的主流大模型（ChatGPT、文心一言、通义千问…）的训练集基本都是构建于网络公开的数据，对于一些实时性的、非公开的或离线的数据是无法获取到的，这部分知识也就无从具备。
  相对微调，RAG能更适用于多变的业务场景，只需要配置对应需求的增强信息，即可结合LLM回答出满意的答案
  RAG对知识的掌控力会更强，相比微调更不用担心学不到或者是遗忘的问题。
  但是如果模型强缺乏某个领域的知识，足量数据的微调才能让模型对该领域有基本的概念，如果不具备领域知识基础，RAG仍旧无法正确回答。

• 幻觉问题
  所有的AI模型的底层原理都是基于数学概率，其模型输出实质上是一系列数值运算，大模型也不例外，所以它有时候会一本正经地胡说八道，尤其是在大模型自身不具备某一方面的知识或不擅长的场景。而这种幻觉问题的区分是比较困难的，因为它要求使用者自身具备相应领域的知识。

• 数据安全性
  对于企业来说，数据安全至关重要，没有企业愿意承担数据泄露的风险，将自身的私域数据上传第三方平台进行训练。这也导致完全依赖通用大模型自身能力的应用方案不得不在数据安全和效果方面进行取舍。

• 具体任务效果
  RAG相比微调能更容易获得更好的效果，突出的是稳定性、可解释性。
  对任务模式比较简单的任务，微调能触碰到更高的上限，但是对训练、数据等方面的要求会更苛刻。

• 成本方面
  RAG对知识的更新时间和经济成本更低。不需要训练，只需要更新数据库即可。

2.4 RAG的使用场景分析

产品百科问答
电商场景下，客服都要具备一个能力，就是产品百科问答，用户会需要咨询某些商品的属性等细节消息，这是一个很具体的场景了。然而实际我们需要面对的，除了这个功能本身，还需要解决一个问题，即商品信息是需要更新和变化的，例如新商品上架、价格优惠修改等，这个信息是需要快速反映在问答系统中的，此时我们RAG非常有必要性。

• 商品信息的更新，不定期且频繁，这种更新通过微调来做，敏捷度不足，风险也比较高。

• 知识如果是结构化，本身用于微调训练并不方便，需要转化，但是数据库存储则比较方便。

• 商品型号很多很接近，容易混淆，大模型很容易出现“张冠李戴”现象。

日常工作工具
写周报、灵感、工作日志、修改一份材料、查错查重、话术推荐、会议纪要之类的，类似这些问题，我们更多的日常使用方式就是prompt+大模型完成，我们做起来非常自然，可能顶多会根据自己的需求加一些例子，但往往不会优先考虑RAG。

• 对固有信息要求不高，甚至没有需求。

• 供给检索的数据，如果不是因为产品本身的信息收集，一般情况下很难获取，对RAG而言可以说是无米之炊了。

• 类似灵感的任务，案例反而可能限制模型发挥。

• 要求的更多是指令的执行能力，这个如果不具备，很可能就要考虑通过微调来整了。

从上面日常工作工具例子，可以看到RAG并不是全能的，需要基于需求进行选型，而不是一昧使用RAG

3. LangChain

3.1 LangChain简介

LangChain是一个开源框架，允许从事人工智能的开发者将例如GPT-4的大语言模型与外部计算和数据来源结合起来。该框架目前以Python或JavaScript包的形式提供。

3.2 LangChain的核心组件

• 模型输入/输出（Model I/O）：与语言模型交互的接口
• 数据连接（Data connection）：与特定应用程序的数据进行交互的接口
• 链（Chains）：将组件组合实现端到端应用。比如后续我们会将搭建检索问答链来完成检索问答。
• 记忆（Memory）：用于链的多次运行之间持久化应用程序状态；
• 代理（Agents）：扩展模型的推理能力。用于复杂的应用的调用序列；
• 回调（Callbacks）：扩展模型的推理能力。用于复杂的应用的调用序列；

3.3 LangChain 入门

LangChain 入门

4.开发 RAG 应用的整体流程

• 步骤一：项目规划与需求分析
  1.项目目标：基于个人知识库的问答助手
  2.核心功能
  将爬取并总结的MD文件及用户上传文档向量化，并创建知识库；
  选择知识库，检索用户提问的知识片段；
  提供知识片段与提问，获取大模型回答；
  流式回复；
  历史对话记录
  3.确定技术架构和工具
  框架：LangChain
  Embedding模型：GPT、智谱、M3E
  数据库：Chroma
  大模型：GPT、讯飞星火、文心一言、GLM 等
  前后端：Gradio 和 Streamlit
• 步骤二：数据准备与向量知识库构建
  本项目实现原理如下图所示（图片来源）：加载本地文档 -> 读取文本 -> 文本分割 -> 文本向量化 -> question 向量化 -> 在文本向量中匹配出与问句向量最相似的 top k 个 -> 匹配出的文本作为上下文和问题一起添加到 Prompt 中 -> 提交给 LLM 生成回答。

1. 收集和整理用户提供的文档
   用户常用文档格式有 PDF、TXT、MD 等，首先，我们可以使用 LangChain 的文档加载器模块方便地加载用户提供的文档，或者使用一些成熟的 Python 包进行读取。

由于目前大模型使用 token 的限制，我们需要对读取的文本进行切分，将较长的文本切分为较小的文本，这时一段文本就是一个单位的知识。

2. 将文档词向量化
   使用文本嵌入(Embeddings)技术对分割后的文档进行向量化，使语义相似的文本片段具有接近的向量表示。然后，存入向量数据库，完成 索引(index) 的创建。

利用向量数据库对各文档片段进行索引，可以实现快速检索。

3. 将向量化后的文档导入 Chroma 知识库，建立知识库索引
   Langchain 集成了超过 30 个不同的向量数据库。Chroma 数据库轻量级且数据存储在内存中，这使得它非常容易启动和开始使用。

将用户知识库内容经过 Embedding 存入向量数据库，然后用户每一次提问也会经过 Embedding，利用向量相关性算法（例如余弦算法）找到最匹配的几个知识库片段，将这些知识库片段作为上下文，与用户问题一起作为 Prompt 提交给 LLM 回答。

• 步骤三：大模型集成与 API 连接
  集成 GPT、星火、文心、GLM 等大模型，配置 API 连接。
  编写代码，实现与大模型 API 的交互，以便获取问题回答。
• 步骤四：核心功能实现
  构建 Prompt Engineering，实现大模型回答功能，根据用户提问和知识库内容生成回答。
  实现流式回复，允许用户进行多轮对话。
  添加历史对话记录功能，保存用户与助手的交互历史。
• 步骤五：核心功能迭代优化
  进行验证评估，收集 Bad Case。
  根据 Bad Case 迭代优化核心功能实现。
• 步骤六：前端与用户交互界面开发
  使用 Gradio 和 Streamlit 搭建前端界面。
  实现用户上传文档、创建知识库的功能。
  设计用户界面，包括问题输入、知识库选择、历史记录展示等。
• 步骤七：部署测试与上线
  部署问答助手到服务器或云平台，确保可在互联网上访问。
  进行生产环境测试，确保系统稳定。
  上线并向用户发布。
• 步骤八：维护与持续改进
  监测系统性能和用户反馈，及时处理问题。
  定期更新知识库，添加新的文档和信息。
  收集用户需求，进行系统改进和功能扩展。

5. 环境配置步骤参考

因为社畜，所以环境都已经装过了，且DataWhale的文档已经有很详细的环境配置步骤，在此不一一赘述。

• 阿里云服务器申请 （bai piao）
• 基础环境配置(配置 git 和 conda)
• 通用环境配置
• VSCode 配置 Python 环境
• 下载 NLTK

6.疑问记录

6.1 Bad Case的优化方式

文档中提到对于RAG业务，可以通过处理Bad Case使得模型的回答有更好的泛化效果

将不断从业务逻辑中收集当下 Prompt 的 Bad Case，并将 Bad Case 加入到验证集中，针对性优化 Prompt，最后实现较好的泛化效果。

理论上来说质量上肯定能获取一些提升，但是实践中由于检索的不准确，或者问题的多样性，可能会存在一些其他问题，比如有的问题不需要检索/检索内容过时了/需要找多个文档才能获得相应知识，这时候光靠常规的检索召回/问答准确率无法完整地评估RAG算法的好坏了，就引出了【能力需求】，可以看成是质量需求里的一些bad case的处理能力

能力需求的四个方面

1.噪声鲁棒性，当检索到了很多不相关文档时，模型是否能去噪声，自动识别出有用的文档辅助自己回答。
2.负排斥，如果模型根据文档和自身知识不能回答，能否对用户说不，而不是误导。
3.信息集成，模型能否融合多个文档，或者多种形式（结构化/非结构化/图像/音频）多种来源的数据来进行回答。
4.反事实鲁棒性，模型被给了错误的文档内容，或者用户诱导模型了一些反事实内容，模型能否自动纠正过来，或者也直接质疑用户。

目前的实战开发中，只接触到第一点噪声鲁班性，并且设计了一个方案提高检索相关性。
在输入query查询相关文档前，会先检索出和query相关的文档，再从知识库中检索相关文档的chuck，这样能提高检索结果相关性。希望在接下来的学习中能掌握更多提高RAG能力需求的技巧。

7.学习心得

第一章主要是了解LLM的含义、发展，随后通过LLM的不足（幻觉、需要微调等）引出了RAG方案，讲述了RAG的实现原理，同时介绍了连接智能LLM的流行框架LangChain、开发环境的搭建步骤。
讲解RAG时候表明可以通过Bad Case进行优化，这让RAG的回答有更好的泛化效果。
在介绍基于个人知识库的问答助手的技术选型时，前后端是Gradio 和 Streamlit，这两个框架是我没有接触过的，接下来又能学习新技术了。