1、大模型应用开发的三种模式

首先要提到进行大模型应用设计时可能会用到三种方式。

分别是【提示工程、RAG 、微调】

那么这三种分别应该在什么时候使用呢？

一般来说是需要有一个循序渐进的过程，比如当回答出现问题，先思考提示词是否不够准确，然后才考虑是否知识信息不具备（比如一些内部私有信息），在此基础上提示词已经非常准确，需要的知识也通过RAG进行了提供但还是有问题，此时说明大模型能力还不够这个时候就需要微调了或者换大模型

微调成本很高所以基本上应该优先在原有的基础上优化，微调的成本体现在：首先数据集的建立就很耗人力，而且特定数据多了还会导致破坏大模型原有的能力有这种风险。以及需要的硬件成本。

2、什么是RAG

回到正题那么什么是RAG呢？

RAG全称Retrieval-Augmented Generation 翻译过来就是检索增强生成，是一种结合信息检索（Retrieval）和文本生成(Gen)的技术

优势是什么？

解决知识的时效性
减少模型幻觉
提升专业领域的回答质量

2.1 RAG构建的步骤

step1 数据预处理

知识库构建：收集并整理文档、网页、数据等多元数据，构建外部知识库

文档分块：将文档分为合适的大小（挺重要）

向量化处理：使用合适的嵌入模型（一般现在用BAAI的BGE-M3）

step2 检索阶段

查询处理：将用问题转化为向量，在向量数据库进行相似度检索 top-k

重排序：对检索结果进行相关性排序，选择最相关的

step3 生成阶段

上下文组装：通过设计提示词将检索信息和用户问题结合，形成增强的上下文输入

生成回答：大语言模型基于增加看i的上下文生成最终回答。

RAG的本质上重构了新的提示词：

LLM => 推理引擎大脑
知识库 => 外挂硬盘记事本

3、NativeRAG

刚刚整个步骤的实现就是NativeRAG，也是最基础的RAG。之后还有一些变体比如图谱的

比较好用的线上的产品有NotebookLM 可以创建多个RAG应用，每个应用它可以一共传入五十个文档，每个可以两百兆，然后他就只根据这些知识来进行回答。

这样你可以创建一个应用，传入你自己手上某个方向的质量好资料或者一些相关的书籍没时间自己消化（Youtube视频链接也可以），然后它就变成这个领域的专业助手了，从别的地方问可能有很多错误，但这个就是从你自己的资料库当中回答问题，非常好用推荐推荐。

国内的这种产品结构的有腾讯的 imacopilot，比较NotebookLM质量实际体验弱一点
![[Pasted image 20250317123706.png]]

即使通过相同的大模型，加上NotebookLM的RAG进行提示组装之后会等到更准确的推理结果，并且可以指出参考哪一篇的REK，方便医生快速进行验证它的正确性

在使用上你除了用来构建知识库助手（往一个应用在长期的使用中慢慢的补充资料，毕竟50个还是挺多的，一本书的pdf就算一个），该应用在这个知识方向越来越好用。

除此之外有些你懒得看的东西比如就只有一篇pdf的保险介绍也可以创建一个临时应用，问一问。
![[Pasted image 20250317125907.png]]

![[Pasted image 20250317130042.png]]

4、Embedding模型的选择

关于模型选择可以到如下的地址去查看对比，目前来说的话语言能力最好的是BGE-M3

huggingface.co/spaces/mteb/leaderboard

![[Pasted image 20250317130519.png]]

![[Pasted image 20250317130726.png]]

试了一下BGE-M3和gte-Qwen2，案例代码如下地址：
https://github.com/Jasper-zh/agi_study/tree/main/embeding/embedding_model

5、OpenAI + Faiss 构建 RAG

PDF文本读取: 使用的PyPDF2
向量数据库的构建：使用OpenAI的Embedding模块转向量、使用Faiss进行存储知识库
语义搜索与问答：使用Faiss提供的函数进行相近搜索、OpenAI进行语言回答
成本跟踪与结果展示：使用langchain的get_openai_callback来解析本次调用成本，前面记录每个chunk的页码，最终展示时可以通过chunk去找到参考页码

代码如下地址：
https://github.com/Jasper-zh/agi_study/blob/main/embeding/rag/chatpdf-faiss.py

![[Pasted image 20250317164020.png]]

6、常见问题

6.1 如果LLM可以处理无限上下文了，RAG还有意义么？

效率成本：RAG通过检索，减少了输入token
知识更新：LLM知识是截止于训练数据
可解释性：RAG的数据是透明的，可查看来源
定制化：可针对特定领域定制
数据隐私：可以在本地私有数据进行检索，避免上传云端

=> 结合RAG的能力，可以提升整体性能，提供更全面、准确的回答。

6.2 如何提升RAG质量？

数据准备阶段

面对的问题 ->

数据质量差：特别是一些非结构数据缺乏良好的管理，包含很多过时、矛盾或者不正确的信息
多模态信息：提取、定义和理解文档中的不同元素内容，如标题、配色方案、图像和标签等存在挑战
复杂的PDF提取：PDF是为人类阅读设计的，机器解析起来非常复杂

如何提升数据准备阶段的质量？

目前两种方式：

构建完整的数据准备流程
智能文档技术

第一种方式就是做好以下几点：

数据评估与分类
- 数据审计：全面审查现有数据，识别敏感、过时、矛盾或者不准确的信息
- 数据分类：按类型、来源、敏感性和重要新对数据做好分类
数据清洗
- 去重：去除重复数据
- 纠错：发现错误进行修正比如格式错误或者拼写错误
- 更新：替换过时的信息，确保数据时效
- 一致性：解决数据矛盾，确保逻辑一致
敏感信息处理
- 进行脱敏，确保合规
数据标记与标注
- 元数据标记：添加元信息，如来源、创建时间等
- 内容标注：对非结构化数据进行标注，便于后续检索和分析
数据治理框架
- 制定政策：明确数据管理、访问控制和更新流程
- 责任分配：指定数据治理负责人，确保政策执行
- 监控与审计：定期监控数据质量，进行审计

数据治理是很漫长很花精力的一个工作，不是一次性就能完成的，需要多人花时间按照指制定的标准一直去维护

第二种方式就是智能文档技术

这种技术相当于是把不同的文件类型，都能按照统一的特征空间去表示，相当于是一个多模态大模型。在这样的理论上，就可以解决文档的内容读取和分割的问题，特别是PDF的文字读取。直接通过文件就能知道含义而不是取出文字再给语言模型分析语义。

![[Pasted image 20250317165331.png]]

这是一个还处于比较新的方向，目前已知的产品有 LayoutLM

知识检索阶段

上面说完了数据准备阶段的点，现在说讲知识检索阶段，那么知识检索阶段可能会出现如下问题：

内容缺失：检索过程中确实关键内容，系统提供不完整碎片化的答案 => 降低RAG的质量
错过排名靠前的文档：用户查询相关文档时被检索到，但相关度很低，导致不满足需求，因为只经过一次top-k，这个k设置多少也需要长时间使用以及调试经验
不在上下文：从数据库返回了包含答案的文档，但未能出现在提示词当中，可能数量太大需要进行整合

如何提升知识检索阶段的质量？

转换澄清用户意图
采用混合检索和重排策略

两个点第一个就是详细化用户意图，当用户比较含糊时，可以细化用户意图可以给用户确定也可以直接细化后直接检索

第二个点就是混合检索和重排，意思就是既进行语义检索也进行关键字匹配检索，或者进行第二次排序

答案生成阶段

在这个阶段的问题可能如下：

未提取：答案与所提供的上下文不相符，可能上下文太多存在噪音，或者有冲突信息
不完整：尽管能根据上下文生成答案，但信息缺失会导致回答不完整
格式错误：当提示词中的附加指令格式不正确时，LLM可能误解从而导致错误答案
幻觉：大模型可能产生误导性或者虚假信息

如何提升答案阶段的质量

改进提示词模板：比如利用推理模型 DeepSeek-r1 、qwq
实施动态防护栏

抛开前面的问题，仅仅答案阶段的效果就只能是提示词了，动态防护栏也是提示词的一种方式例子如下，可以通过另外的模型去分析需要回答的要素，拼接到提示词当中

![[Pasted image 20250317171933.png]]

![[Pasted image 20250317172054.png]]

![[Pasted image 20250317172226.png]]

7、总结

RAG是目前应用实践效果最好的一种大模型的应用架构，主要分为三个部分数据、向量化、检索回答。其中最主要的部分还是数据的处理，想要做一些练习的话可以做类似谷歌的NoteBookLM可以上传不同类型文件，同时回答会显示参考来源文件