通过RAG外挂知识库提升大语言模型的个性化能力

本文将列举几种对大语言模型进行个性化的方法，简单说明使用检索增强生成技术（RAG）外挂知识库的基本原理，最后介绍 AnythingLLM 这款高度集成且易于使用的软件。阅读本文后，如果你的应用场景恰好幸运的避开该软件现阶段存在的一些缺点，那么恭喜你将能得到一个私人定制的人工智能助手。

在很多应用场景中，如果大语言模型只能基于公共知识进行问答，它的答案将因为缺乏针对性而显得低效或不实用。比如作为一个编程助手，它不知道你遵循的编码规范和使用的底层框架，那么提供给你的代码还得手工重构才能符合你的需求；比如作为一个客服机器人，它如果不了解公司的产品体系和售后服务标准，那么就只能进行一些简单的礼貌问候而无法解决实质性的问题。此时我们就急需一种方法，让大模型在回答问题时能优先考虑特定的资料，再结合其本身的能力来解决问题。

个性化大模型的方法

第一种方法是通过新的数据集对底座模型进行再训练得到新模型。在客服机器人的例子中，将公司的所有产品介绍资料、价格体系、售前售后服务标准等客服的培训材料作为训练数据，得到一个内置了这些知识的新模型，再用这个模型去回答客户的提问。但是训练模型需要相对较高的专业能力要求，训练成本也比较高，而且每次资料发生变化时，就得再次训练，因此并不适合这个场景。

第二种方法是通过系统提示词或上下文预先创造一个包含这些信息的对话环境，比如每次与客户对话前，通过系统提示词，或借助编程的方式先与大模型进行几轮对话，告诉大模型要参照哪些资料去进行对话，然后将这个聊到一半的上下文环境给到客户进行问答，这样也能对本轮对话起到个性化的效果。这个方法的优点是结构非常简单，使用的都是大模型本身就具备的能力。缺陷是大模型通常有上下文长度限制，如果资料很多可能就会超出系统的能力范围，而且上下文越长，系统所需进行的计算量也越大，且呈非线性的上升。因此这种方法只适合额外添加少量个性化信息，比如针对当前对话的客户，提前告诉大模型该客户之前买了哪款产品，以此提高回答的针对性。

第三种方法就是本文要重点介绍的检索增强生成技术（RAG）。

检索增强生成（RAG）

根据维基百科的定义：

检索增强生成 (RAG) 是一种具有信息检索功能的生成式人工智能。它修改了与大型语言模型 (LLM) 的交互，使模型能够根据指定的一组文档响应用户查询，并优先使用这些信息而不是从其自身庞大的静态训练数据中提取的信息。这允许 LLM 使用特定领域和/或更新的信息。

要实现RAG，实际上有四个步骤而非三个，分别是索引、检索、增强、生成。

索引就是为RAG准备数据的过程，将用户提供的文档资料转换成可以被大模型读取和理解的向量化数据，通常被存储在向量数据库中。

当用户发起对话时，文档检索器先从向量数据库中找出与当前对话最相关的资料，然后将这些资料与原始的上下文以及提示词进行结合起到增强的效果，最后再交给大模型进行处理生成最终结果。

langchain-chatchat 文档中的图比较清晰的反应了这个过程。

总结下来，RAG就是借助一个外挂的知识库来对模型进行个性化定制的方式。

AnythingLLM

接下来，我们就来实际操作一下，看看如何通过 AnythingLLM 这款软件实现基于知识库的问答。

首先通过 https://anythingllm.com/download 下载桌面客户端并进行安装。

安装过程比较简单，此处不再展开，安装完毕后打开软件并跳过欢迎界面，进入到初始化配置

在此处可以看到它支持多种模型服务，最简单的方式就是选择默认的 AnythingLLM 并从下方的 Official Modals 里选择一个，然后点击右侧的箭头，完成确认后，再等待它完成下载就可以开始使用了。

如果你跟我一样已经安装过 Ollama，那么也可以在设置界面直接选用 Ollama 作为 Provider 并直接使用已经安装好的模型。

完成上述配置后，我们就进入了系统主界面。

AnytingLLM 以工作区的方式来管理知识库，这样你就可以将个人的资料和公司的资料进行区分。获得两个有不同知识库的智能助理。

应用示例

接下来用具体的场景进行演示，首先创建一个工作区用来存放我们的知识库，工作区用于将上传的资料互相隔离，在实际应用中，可以根据不同的项目，或者单纯按照个人资料或者工作资料进行区分。

以编程为例，我们可以通过电子书和接口文档等资料来增强模型的回答与我们日常使用的编程器语言和框架的相关性。

首先，我们需要将资料上传到系统中，完成索引。点击工作区的上传图标，进入资料管理界面。

丰富知识库的方式，又可以进一步分为上传本地文件(1)、从网页抓取(2)、拉取代码仓库(3)等方式。

上传或抓取到的文件会显示到左侧的文档管理框中，选中要纳入当前知识库的文档后，点击 Move to Workspace 即可移动到右侧工作区。

最后点击Save and Embed 将准备好的文件交给嵌入模型解析成向量数据并存储到向量数据库中进行持久化，等待系统提示成功后，即可关闭文档管理界面。

资料检索

准备完资料后，回到主界面，点击工作区下方的New Thread按钮创建一个新的对话，就可以对模型提出问题了。比如下图中我只是提出了“什么是面向切面编程”的问题，带知识库的回答就主动提及了Spring Boot 相关的内容，因为我上传的4份资料有3份是 Spring Boot 相关的书籍和文档。在回答的末尾，系统还会列出所引用的文档的名称。

缺点和不足

网上很多介绍的文章到此就结束了。初见确实很美好，但是稍微多体验了一会，我就发现其现阶段存在的几个问题，。

只能查询而非统计

打个比方，你可以将维基百科中2024年台风相关的词条加入到知识库中，这样就可以问模型各个台风的信息，比如级别、最大风速等，但是如果想要知道2024年登录浙江的台风数量，那么最好是参考资料中就有相关的统计数据，而不能奢望模型根据某某台风登录浙江这样的文字，找出所有的记录，并自行完成统计。

这里包括好几个难点，首先RAG是按照检索、增强、生成的顺序执行的。检索的过程你可以类比一下搜索引擎，默认只会大约展示前10条数据给你，RAG也只会检索出其认为匹配度最高的一部分数据作为上下文传递给大模型，因此提交给模型的数据就已经是不全的，门槛都过不去，自然无法作出正确统计。其次推理能力本来就是大语言模型的弱项，顶尖商业模型也尚未突破，本地运行的小模型就更是对此类问题无能为力了。

文件格式限制

目前AnythingLLM 仅支持 Word、PDF、各类纯文本文件格式，无法解析 Excel等常用文件，这样很多清单类的资料和格式化的数据资料就无法被直接使用，而且即便转换格式，也很明显会丢失掉行列这些对于数据而言非常重要的信息。

即使是 Word、PDF 文档，其中嵌入的图片是无法解析的，这会使很多文档丢失关键信息，并直接给各类扫描版的PDF资料判了死刑。图片的解析属于多模态模型的范畴，现阶段理论上是有技术可行性的，在解析文档的时候动用多模态模型就可以把图片的内容分析掉，但代价非常高昂，分析一页插图的算力足够将整本书中的所有文字完成向量化，解析后的图片如何在回答中重新呈现，也需要在架构上进行充分的考虑和设计。

资料来源不够明确

虽然大模型回答问题后，会列出所参照的文件，点击还能查看具体的上下文内容和匹配度评分，但回答和原始材料引用的联系还不够明确（特别是对PDF格式原始文件的展现，可读性非常差），给通过原文验证回答准确性增加了难度。

总结

由于技术的限制，现阶段RAG最能发挥作用的场景还属通过输入一些是什么、怎么做之类的文档，教会大模型应对这些与概念、定义、标准操作流程相关的问题。距离将知识库一股脑儿丢进去，然后让模型帮你分析和解决问题的理想世界还相差甚远。