本地知识库RAG总结

新的模型在不断地发布，大家都可能会经历领先-落后-又领先的循环。                                       ——Mike Krieger（Anthropic  CPO）

2025年3月4日

杰文斯悖论（Jevons Paradox）：技术进步提升资源使用效率，但可能导致资源总需求与消耗量增加。

缩放定律（ Scaling Law ）：在机器学习和人工智能领域，随着模型规模、数据量、计算能力等因素的增大，模型性能的提升呈现出一定的规律性。

即：更大算力 + 更大数据 +更大尺寸 = 更大智能 ，目前还没有到头撞墙的迹象。

目录

RAG流程:

知识库的要求：

知识抽取：

知识存储:

向量化:

知识检索:

应用客户端:

RAG智能问答应用几个痛点：

如何提升召回率改进思路：

如何提升回答专业性：

RAG评测：

构建知识库的其他注意事项：

总结：

参考链接：

RAG流程:

知识加载 -> 知识切片 -> 信息抽取 -> 知识加工(embedding/graph/keywords) -> 知识存储

知识库的要求：

1、支持多人同时编辑

2、事件通知机制：新增或修改以后同步通知（有最佳）

3、有对外的api或可以爬取的页面

4、支持多路召回，检索的时候可以同时从多个知识库进行检索

知识抽取：

1、目前支持向量抽取，知识图谱抽取，关键词抽取。

知识图谱抽取 -> knowledge graph， 通过利用大模型提取(实体,关系,实体)三元组结构。

倒排索引抽取 -> keywords分词，可以用es默认的分词库，也可以使用es的插件模式自定义分词

知识存储:

Dify 在v0.6.x 及更高版本中默认集成PGVector（基于 PostgreSQL 的向量扩展）在配置文件中可改

MaxKB 默认使用Weaviate作为向量存储引擎

选型建议

超大规模数据+分布式：Milvus、Vespa。

高维向量+GPU加速：FAISS（需自研存储层）、Milvus。

轻量级+快速开发：Chroma、Annoy。

混合查询（向量+属性）：Weaviate、Qdrant。

向量化:

高精度要求建议自己写程序处理，更准确一些，能解决索引质量和信息丢失的问题

分段优化4原则：  
语义完整性校验（BERTScore>0.85）  
动态重叠窗口（建议15%-20%文本长度）  
关键实体锚点锁定（使用spaCy实体识别）

知识切片默认使用分割符separator（换行”\n”）+固定size，其他切片方式包括基于页面page、段落paragraph、markdown header等。

知识检索:

question -> rewrite -> similarity_search -> rerank -> context_candidates

Graph RAG

首先通过模型进行关键词抽取，这里可以通过传统的nlp技术进行分词，也可以通过大模型进行分词，然后进行关键词按照同义词做扩充，找到关键词的候选列表，最好根据关键词候选列表调用explore方法召回局部子图。

应用客户端:

RAG智能问答应用几个痛点：

1、知识库文档越来越多以后，检索噪音大，召回准确率不高

2、召回不全，完整性不够

3、召回和用户问题意图相关性不大

4、只能回答静态数据，无法动态获取知识，导致答疑应用比较呆，比较笨。

5、用于大模型推理相关上下文的召回率低，推不准确，幻觉严重

6、从数据库中检索到包含答案的文档，因为重排序/过滤规则等策略，导致有用的文档没有被整合到上下文中。

7、召回的上下文中，依然存在过多的噪音或矛盾，导致问题难以被准确回复。

8、仅基于上下文提供的内容生成答案，会导致回答的内容不够充整。

9、当用户的提问过于笼统时，也会出现准确性不足的问题。

10、召回率还有巨大改进空间。

11、已经有现成的知识库(自动采集)

12、嵌入向量拆分的时候可能会丢失信息(分段优化，分段最大长度500，分段重叠长度50)

13、给llm的信息受令牌数量限制(分级召回策略)

14、使用dify建知识库加集成ollama，感觉效果一般(索引优化)

15、局域网内多终端访问同一个向量数据库(web应用)

如何提升召回率改进思路：

1、融入“关键字检索”技术，用于排除召回文档中和问题关键字无关的内容。

2、保持双向量数据库架构，保持chunk中前后端以及文档结构描述。

3、融入“知识图谱”技术，将文档中的实体和属性形成可解释的知识图谱，在检索的时候，通过问题中语义实体或关系，基于知识图谱库获取和该问题推理相关的上下文（事实或逻辑），让大模型按照可解释的推理过程进行问题的分解和答案生成。

4、构建依据问题的自动检素路由，用于提高问题的回复效率。

5、知识处理优化

非结构化/半结构化/结构化数据的处理，准备决定着RAG应用的上限，因此首先需要在知识处理，索引阶段做大量的细粒度的ETL工作，主要优化的思路方向：

(1)非结构化 -> 结构化：有条理地组织知识信息。

(2)提取更加丰富的, 多元化的语义信息。

(3)建议将docx、txt或者其他文本事先处理为pdf或者markdown格式，这样可以利用一些识别工具更好的提取文本中的各项内容。

(4)提取文本中的表格信息。

(5)保留markdown和pdf的标题层级信息，为接下来的层级关系树等索引方式准备。

(6)保留图片链接，公式等信息，也统一处理成markdown的格式。

(7)切片Chunk尽量保持完整，保存上下文完整性和相关性，这直接关乎回复准确率。保持在大模型的上下文限制内，分块保证输入到LLMs的文本不会超过其token限制。

(8)图片 + 表格 单独抽取成Chunk，将表格和图片标题保留到metadata元数据里。

(9)文档内容尽量按照标题层级或者Markdown Header进行拆分，尽可能保留chunk的完整性。

(10)如果有自定义分隔符可以按照自定义分割符切分。

(11)知识图谱，依赖大模型提取(实体,关系,实体)三元组关系。依赖前期高质量，结构化的知识准备，清洗，抽取，通过业务规则通过手动或者自定义SOP流程构建知识图谱。

(12)Doc Tree，以标题层级构建chunk的树形节点，形成一个多叉树结构，每一层级节点只需要存储文档标题，叶子节点存储具体的文本内容。这样利用树的遍历算法，如果用户问题命中相关非叶子标题节点，就可以将相关的子节点数据进行召回。这样就不会存在chunk完整性缺失的问题。

(13)提取QA对，需要前置通过预定义或者模型抽取的方式提取QA对信息。预定义:预先为每个chunk添加一些问题。模型抽取:通过给定一下上下文，让模型进行QA对抽取。

(14)元数据抽取，根据自身业务数据特点，提取数据的特征进行保留，比如标签，类别，时间，版本等元数据属性。

(15)总结提取，通过mapreduce等方式分段抽取，通过模型为每段chunk提取摘要信息。

6、RAG流程优化

(1)原始问题分类，通过问题分类可以LLM分类(LLMExtractor)，构建embedding+逻辑回归实现双塔模型，text2nlu DB-GPT-Hub/src/dbgpt-hub-nlu/README.zh.md at main · eosphoros-ai/DB-GPT-Hub。tip:需要高质量的Embedding模型，推荐bge-v1.5-large

(2)反问用户，如果语义不清晰将问题再抛给用户进行问题澄清，通过多轮交互。通过热搜词库根据语义相关性给用户推荐他想要的问题候选列表

(3)槽位提取，目的是获取用户问题中的关键slot信息，比如意图，业务属性等等。LLM提取(LLMExtractor)

(4)问题改写，热搜词库进行改写，多轮交互。

(5)元数据过滤，当我们把索引分成许多chunks并且都存储在相同的知识空间里面，检索效率会成为问题。比如用户问"浙江我武科技公司"相关信息时，并不想召回其他公司的信息。因此，如果可以通过公司名称元数据属性先进行过滤，就会大大提升效率和相关度。

(6)多策略混合召回。按照优先级召回，分别为不同的检索器定义优先级，检索到内容后立即返回。定义不同检索，比如qa_retriever, doc_tree_retriever写入到队列里面， 通过队列的先进先出的特性实现优先级召回。

(7)多知识索引/空间并行召回。通过知识的不同索引形式，通过并行召回方式获取候选列表，保证召回完整性。

(8)后置过滤。经过粗筛候选列表后，怎么通过精筛过滤噪音呢？无关的候选分片剔除、时效性剔除、业务属性不满足剔除、topk去重、重排序，仅仅靠粗筛的召回还不够，这时候我们需要有一些策略来对检索的结果做重排序，比如把组合相关度、匹配度等因素做一些重新调整，得到更符合我们业务场景的排序。因为在这一步之后，我们就会把结果送给LLM进行最终处理了，所以这一部分的结果很重要。使用相关重排序模型进行精筛，可以使用开源的模型，也可以使用带业务语义微调的模型。

(9)显示优化+兜底话术/话题引导。让模型使用markdown的格式进行输出。

如何提升回答专业性：

原生RAG的困难：

1、文档来源复杂，质量参差不齐，要精确解析文档非常困难。对于文档中的公式、图片和表格等，既要保持原语义的基础上，又要处理为字符，目前的技术相当的困难。

2、当文档的数量增多增大的时候，正确地召回到包含答案的文档是最大的挑战。原生RAG召回的文档和问题的语义关联相差甚远。

3、当噪声文档多的话，会正确的答案生成造成极大干扰。

4、专业技术文档里有大量的专业术语、缩写，大模型理解不正确。

5、问题只涉及局部信息时，召回率高;问题涉及到全局信息时，召回率就很低。

改进思路:

1、生成问答对新语料

基于Qwen2-72B 模型，利用提示词，对每个chunk的内容产生多个问答对数据，将问答数据整合(N:1)Embedding，存储“问答向量数据库”中。

2、Chunk的前后段和文档结构保持

第一、依据自然段，对原文档进行切分，以自然段为chunk基准。第二，对每个自然段进行摘要。第三，将某自然段的前后自然段摘要，链接到该自然段前后，作为前后段。第四，将该自然段所处文档的结构，作为上下文添加到该自然段中。最后将以上整合的语块以Embedding的方式，存储在“原文档+前后端+文档结构向量数据库”中。

3、利用工具拆分表格和图像

用专门的工具对文档内容中涉及图片、公式(图片格式)和表格(图片格式)进行重命名，其图片保存为同文档目录下的同名的图片。在检索成功后，依据文字中的名称从同目录下获取对应的图片。

RAG评测：

在评估智能问答流程时，需要单独对召回相关性准确率以及模型问答的相关性进行评估，然后再综合考虑，以判断RAG流程在哪些方面仍需改进。

RAG召回指标(RetrieverEvaluationMetric)：

RetrieverHitRateMetric:命中率衡量的是RAG retriever召回出现在检索结果前top-k个文档中的比例。

RetrieverMRRMetric: Mean Reciprocal Rank通过分析最相关文档在检索结果里的排名来计算每个查询的准确性。更具体地说，它是所有查询的相关文档排名倒数的平均值。例如，若最相关的文档排在第一位，其倒数排名为 1；排在第二位时，为 1/2；以此类推。

RetrieverSimilarityMetric: 相似度指标计算，计算召回内容与预测内容的相似度。

模型生成答案指标:

AnswerRelevancyMetric:智能体答案相关性指标，通过智能体答案与用户提问的匹配程度。高相关性的答案不仅要求模型能够理解用户的问题，还要求其能够生成与问题密切相关的答案。这直接影响到用户的满意度和模型的实用性。

构建知识库的其他注意事项：

检索增强生成（Retrieval Augmented Generation），简称 RAG。在构建RAG（Retrieval-Augmented Generation）的向量知识库时，数据的处理方式直接影响系统的性能和可靠性。不能随意塞入未经处理的数据，否则可能导致检索效果差、生成结果不准确甚至安全隐患。

数据质量直接影响结果（向量知识库数据集严禁噪声与微调不一样！！！）

• 问题：噪声、重复、低质数据会污染知识库，导致检索到无关内容。
• 解决方案：
  • 清洗数据：去除HTML标签、特殊符号、乱码等噪声。
  • 去重：合并相似内容，避免冗余数据干扰检索。
  • 标准化：统一文本格式（如日期、单位）、大小写、标点符号。
  • 质量筛选：优先保留权威来源、高可信度的内容。

数据与场景的匹配性

• 问题：知识库与应用场景偏离会导致检索失效。
• 解决方案：
  • 场景过滤：仅保留与目标任务相关的数据（例如医疗场景需剔除无关行业内容）。
  • 动态更新：定期增量更新数据，避免时效性内容过期。
  • 冷启动优化：初期可引入人工标注的高质量种子数据。

安全与合规风险

• 问题：随意导入数据可能泄露敏感信息或引入偏见。
• 解决方案：
  • 敏感信息过滤：使用NER识别并脱敏（如身份证号、电话号码）。
  • 偏见检测：通过公平性评估工具（如Fairness Indicators）筛查歧视性内容。
  • 权限控制：对知识库分级访问，限制敏感数据检索权限。

如果你不是使用Dify开源框架构建向量数据库，而是使用类似faiss向量数据库构建向量数据库还有以下注意事项：

1.文本分块（Chunking）需策略化

• 问题：随意分块可能导致语义不完整，影响向量表示。
• 解决方案：
  • 按语义切分：使用句子边界检测、段落分割或基于语义相似度的算法（如BERT句间相似度）。
  • 动态调整块大小：根据数据特性调整（例如技术文档适合较长的块，对话数据适合短块）。
  • 重叠分块：相邻块保留部分重叠文本，避免关键信息被切分到边缘。

2.向量化模型的适配性

• 问题：直接使用通用模型可能无法捕捉领域语义。
• 解决方案：
  • 领域微调：在领域数据上微调模型（如BERT、RoBERTa）以提升向量表征能力。
  • 多模态支持：若包含图表、代码等，需选择支持多模态的模型（如CLIP、CodeBERT）。
  • 轻量化部署：权衡精度与效率，可选择蒸馏后的模型（如MiniLM）。

3.索引结构与检索效率

• 问题：海量数据未经优化会导致检索延迟。
• 解决方案：
  • 分层索引：对高频数据使用HNSW，长尾数据用IVF-PQ（Faiss或Milvus）。
  • 元数据过滤：为数据添加标签（如时间、类别），加速粗筛过程。
  • 分布式部署：按数据热度分片，结合缓存机制（如Redis）提升响应速度。

将数据整理成问答对（QA Pair）形式是一种优化策略，而非必要步骤。但这种方式在特定场景下能显著提升检索和生成的效果。以下是其核心原因和适用场景的分析：

1. 1.为什么问答对形式能优化RAG？

（1）精准对齐用户查询意图

• 问题：用户输入通常是自然语言问题（如“如何重置密码？”），而知识库若存储的是纯文本段落（如技术文档），检索时可能因语义差异导致匹配失败。
• 问答对的优势：

直接以“问题-答案”形式存储知识，检索时相似度计算更聚焦于“问题与问题”的匹配（Question-Question Similarity），而非“问题与段落”的匹配。

例如，若知识库中存有QA对 Q: 如何重置密码？ → A: 进入设置页面，点击“忘记密码”...，当用户提问“密码忘了怎么办？”时，即使表述不同，向量模型也能捕捉到语义相似性。

（2）降低生成模型的负担

• 问题：若检索到的是长文本段落，生成模型（如GPT）需要从段落中提取关键信息并重组答案，可能导致信息冗余或遗漏。
• 问答对的优势：

答案部分已是对问题的直接回应，生成模型只需“改写”或“补充”答案，而非从头生成，降低幻觉风险。

例如，QA对中的答案已结构化（如步骤列表），生成结果更规范。

（3）提升检索效率与召回率

• 问题：传统分块检索可能因文本块过长或过短导致关键信息丢失（如答案分散在多个段落）。
• 问答对的优势：

每个QA对是自包含的语义单元，检索时直接返回完整答案，减少上下文碎片化问题。

可针对高频问题设计专用QA对，提高热门问题的响应速度和准确性。

 哪些场景适合问答对形式？

（1）任务型对话系统

• 适用场景：客服机器人、技术支持、医疗咨询等垂直领域。
• 原因：用户需求明确，答案通常简短且结构化（如操作步骤、诊断建议）。
• 案例：

用户问：“如何退订会员？” → 直接匹配QA对中的答案：“登录账号→进入订阅管理→点击取消”。

（2）FAQ（常见问题解答）库

• 适用场景：产品帮助文档、政策解读等。
• 原因：FAQ天然适合QA形式，直接覆盖高频问题。
• 案例：

知识库存储 Q: 保修期多久？ → A: 本产品保修期为2年。

（3）知识密集型生成任务

• 适用场景：需要精确引用事实的场景（如法律咨询、学术问答）。
• 原因：QA对中的答案可作为“事实锚点”，减少生成模型的自由发挥。
• 案例：

用户问：“《民法典》规定离婚冷静期多久？” → 返回QA对中的法条原文。

问答对构建的注意事项，并非所有数据都适合QA形式

• 避免强制转换：

（1）叙述性文本（如小说、新闻）或开放域知识（如百科条目）更适合以段落或实体为中心存储。

（2）强行拆分为QA可能导致信息割裂（例如将“量子力学发展史”拆解为多个不连贯的问答）。

总结：

1、Dify的强大之处在于流程引擎。知识库这方面，尤其是检索Retrieval这块其实只是基础版的实现，实验室跑跑demo还行，实际使用的话，召回很低。

2、摆在面前的3条路，何去何从，引人思考。第一，自己从0开始实现RAG，优点是灵活度高，可以定制，召回有保证，缺点是工作量大。第二，使用开源的RAG，优点是工作量少，缺点是召回太低，自己源码级别的修改又不知道自己是否能cover。第三，基于开源的做2次开发，优点解决了召回的问题，缺点还是不知道是否可以cover。

3、RAG这套流程想要做好，最少需要2个人以上的团队。

参考链接：

http://www.360doc.com/content/25/0208/14/58415156_1146300439.shtml

万字长文讲透 RAG在实际落地场景中的优化

架构思考 · 语雀

评估(Evaluation) · 语雀

RAG篇「数据集构建」保姆级教程来了！