RAG本地部署时遇到的一些问题和心得

2025年7月1日更新：用了一段时间谷歌的notebookLLM，便捷性准确性高效性，我原称之为目前notebookLLM地表最强RAG工具，仅仅是个人用户免费使用，其他的RAG工具都可以退下了。

--------------------------以下是原文-------------------------------

本文在我部署RAG知识库时，所遇到的一些情况，稍微整理一下思路，非专业人员，可能有误。

RAG系统是一种结合了信息检索和文本生成能力的AI架构。它的核心思想是，当需要生成文本时，不是仅仅依赖预训练模型自身的知识，而是先从外部知识库中检索相关信息，然后将检索到的信息作为上下文，辅助模型生成更准确、更丰富的文本。

说人话：就是把你的资料上传到一个库，作为一个外部知识库，通过某些开源工具的检索方式，输出资料的片段给大模型，大模型先读取你的片段再回答问题。

操作过程：用户上传文档→用户在开源工具里把文档按token分割成更小的块→存储分块，建立向量数据库，文本块转换成向量表示，实现语义检索。

模型过程：接收用户提出的问题→提取问题里关键字，在数据库中检索相关的文本块→对检索到的文本块进行重新排序，选出与查询最相关的文本块→将重新排序后的文本块进行整合→利用整合后的上下文，生成最终的回复。

网上随便搜出来几分钟的速搭教程，基本上教学都是教操作过程，一般傻瓜跟着操作也能部署，比较容易遇到分块或索引过程中出现错误，可能会需要换开源工具或者换embedding模型。而真正使用知识库，99%用户会遇到的问题是查询时，发现检索到的信息可能过于宽泛或过于狭窄，与实际需求不符的情况。一般RAG卖课付费的内容，也是在解决这些问题。

以下都是针对查询过程（Query Process）遇到的困境和痛点。

如，在模型提取关键字，去向量数据库里查询块，到重排序块返回，这一步容易出现：检索器搜索不到关键词，找不到正确的块

或是，模型将排序后的文本块进行整合，形成更连贯的上下文，这一步出现：整合后的上下文存在逻辑错误或信息冗余，返回小说的第30章和70章的片段，模型把他们拼一块，强行解释了因果

或是，模型输出回复，这一步：模型提不出关键信息，理解不了内容乱答。

一、RAG 的检索阶段痛点

RAG 在检索阶段主要存在三大痛点：①自身本文质量的问题，②使用软件自身的检索策略，③embedding模型

1、文本质量：要构建高质量知识库，人工处理数据是最佳方式。比如采用 QA 式问答形式，或者构建排版清晰、条理明确的文本。若直接上传从网上搜索的电子书、网盘下载的盗版 PDF 文档，切割后的数据往往不理想，可能出现数据丢失或夹杂大量无用信息的情况。有关向量检索的技术逻辑十个博主九个把这个说的很高大上，但是实际使用，它只能关联父亲=爸爸，而你指苹果说iphone，向量检索基本上无法建立对应的联系，因此也就检索不出相应的片段。所以你在提问时，要把它当作一个搜索工作，而不是有问必答的ai助手。
解决方法：人工数据清洗，这里笔者做的只是减少输出给大模型的垃圾信息，对于长文本类的小说散文，数据清洗的收益不大。

2、软件检索策略：市面上有众多部署 RAG 的开源工具，由于各工具的检测策略和检索算法不同，对相同问题的检索结果差异较大。有些工具能准确召回相关片段，而有些则返回风马牛不相及的文本。使用的软件决定了最终返回的片段顺序。
解决方法：找出最适合混合检索架构，个人实测后感觉RAGflow的策略是最强的，笔者问了一个干扰项的问题，同向量模型只有RAGflow召回了正确的片段。

3、embedding 模型：embedding 模型决定了模型对语义关联的理解程度，他决定了当你问“爸爸”时，它知不知道，爸爸同时也指父亲，你说苹果时它能不能猜iphone。
解决方法：挑选合适的embedding中文模型，笔者测试了免费开源的bge和阿里收费的textv3，发现召回确实收费的强。

DeepSeekR1本地RAG知识库(13):Embedding模型讲解(小白也能懂) - 今日头条

Embedding模型讲解，如何提高知识库问题准确率？_哔哩哔哩_bilibilihttps://www.bilibili.com/video/BV1XzADeFEMs/?spm_id_from=333.1007.tianma.2-2-5.click&vd_source=e0e4e4122d077cc783600ddc34cdbd00

二、RAG 的增强阶段难点

此阶段是大模型的信息输入阶段，RAG 技术将检索到的信息传递给大模型，存在以下潜在问题：①输入给大模型，检索到质量很差的片段。②输入给大模型，很少的信息。③输入给大模型，跳跃性的片段。

1、片段质量差：表现返回来的信息与问题不匹配，导致本地部署的大模型会出现“幻觉”式回答，如果模型接收到的信息乱七八糟和问题无关，并且你本地部署模型推理能力还不强，有很多的模型是不能发现检索信息是碎片化的、毫无关系的，就会强行编造虚假回复，或者发疯式输出，你问天他答地。
解决方法：前期召回不匹配的片段，可以尝试换个工具换检索策略和换embedding模型，进行召回测试看哪个工具能匹配的上片段。LLM模型则需要更换能够进行长思维链模式的模型，加明确prompt限制，让大模型回复禁止瞎编。

2、信息整合不充分：信息整合不足，明明答案就在返回头部片段里，但是大模型无法准确回答，生成笼统、缺乏实质内容的重复性回答，或者是生成不准确或模棱两可的回复。
解决方法：如果模型召回是排序靠前的片段出现问题，则在前期策略阶段更换更大maxtoken的embedding模型，模型回阶段换更联系输出更多token的大语言模型。限制token K的段数，从策略的优化。如果模型召回片段排序在后面，更换reranker模型。

3、缺乏上下文：检索到的文本片段可能被截断或上下文缺失，致使大模型无法正确理解信息含义，进而生成错误回答。
解决方法：优化提问方式，可分步骤提问，因为模型有自动联系上下文的功能，或者用api，或写提示词，让它不要瞎编。

三、RAG 的生成阶段表现

这一阶段是大模型的输出阶段，常出现以下情况：①大模型输出被截断。②回答很笨。③回答很慢。

1、输出截断：本地部署的大模型存在 token 限制，若第二阶段输入的片段字数过多，占用大量 token，大模型可能因无剩余 token 而导致输出截断。
解决方法：设置模型的最大 token 数，这可能需要强大的硬件支持，或者直接使用 Api。

2、回答质量差：大模型性能不佳时，无法依据检索信息进行正常判断推理，生成的回答仅复述检索内容，缺乏深度推理和创新性见解。
解决方法：尝试不同的模型。

3、检索范围过大，会引入大量无关信息，增加模型处理负担；检索范围过小，则可能遗漏关键信息，导致回答不完整。过多无意义的垃圾信息会干扰模型回复。
解决方法：过多，给模型的无意义的垃圾信息太多了，反而给模型的回复造成了干扰，用更智能能判断上下文因果的模型，或者是用更精确的检索。模型回复很慢，这个无解，只能找api用。

我所提出的解决办法只是基于实践的设想，若有更优方法，欢迎交流探讨。

笔者RAGflow聊天模式突然无法读取知识库了，之前发现dify输出+ragflow的检索策略还挺好用，召回比dify自带的要准确，输出又比ragflow块，推荐给各位

dify外挂ragflow+千问QWQ,解决dify解析和检索短板 - 知乎

-----------------------------------------------

更新，在B站刷了几个视频感觉也说到了我遇到的问题，解决的办法待完善

RAG实战中的常见问题_哔哩哔哩_bilibili

另外一种解决方法的思路：

用notebookLM分析deepseek技术报告，检索+AI，避免“幻觉”_哔哩哔哩_bilibili