当前位置：首页 > news >正文

本地知识库RAG总结

news 来源：原创 2025/8/12 5:17:00

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	PB级（分布式）	毫秒级	⭐⭐⭐⭐⭐	大规模AI应用
FAISS	内存限制	微秒~毫秒级	⭐⭐	内存内快速检索
Weaviate	TB级	毫秒级	⭐⭐⭐	混合查询
Vespa	PB级	<50ms	⭐⭐⭐⭐	企业级实时搜索
Qdrant	TB级	毫秒级	⭐⭐⭐	带过滤的向量搜索
Chroma	GB级	毫秒级	⭐	原型开发与小规模应用
Elastic	PB 级	毫秒级	⭐⭐⭐⭐	日志分析、全文搜索

选型建议

超大规模数据+分布式：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方法召回局部子图。

应用客户端:

产品	形式	对外api服务	外部知识库	外部向量库
cherry studio	桌面	否	否	否
anythingLLM	桌面或web	是	否	是
dify	web	是	是	否
MaxKB	web	是	是	否
ragflow	web	/	否	否
FastGPT	web	是	是	否
openwebui	web	否	否	否

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

总结：

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流程:

知识库的要求：

知识抽取：

知识存储:

向量化:

知识检索:

应用客户端:

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

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

如何提升回答专业性：

RAG评测：

总结：

参考链接：

相关文章：