SemanticRAG：如何实现全过程语义检索

浩如烟海的文字，是你宝贵的财富...

大语言模型一成熟，基于RAG的知识检索、问答应用就像雨后春笋般冒出来了，这里头的商机，懂的都懂。最近GraphRAG又火了，被不少人称作RAG 2.0。那么问题来了——LangChain、LlamaIndex这些先行者是不是要过气？大家折腾了近一年的向量检索，难道又要打水漂？

技术迭代确实快得让人有点跟不上，但别急着唱衰。向量检索和图检索，其实是两条并行的技术路线，谁也替代不了谁。简单概括：图检索在固定关系、简单关系上表现好；向量检索则擅长处理时序性、复杂属性关系。而且，向量检索拿到的是第一手原始数据，没有经过二次加工；图检索目前主要保留三元组信息，会丢掉不少辅助信息或者没法识别的细节。具体怎么选、怎么用，改天再细聊。

不管技术路线怎么走，核心目标只有一个：高效、准确地从海量历史素材中把需要的知识提取出来。这件事才是根本。把图检索和向量检索结合，发挥各自优势，是以后可以深入探讨的方向。说到底，RAG服务Agent才是长期目标。基础不牢，地动山摇——随着RAG越来越精细化，大家对准确性和性能的要求也越来越高，向量检索这块，还得继续“卷”下去。

这半年来，翻了不少RAG的资料和源码，先由衷感谢社区各位大佬的无私分享。一个明显的感受是：大家都在喊“语义检索”，但现在的技术路线更多是盯着微观语义，跟宏观语义结合得比较少。我利用业余时间断断续续手搓了一个实验软件，姑且叫它SemanticRAG。借着周末，把关于“什么是语义”、“如何深层次地结合语义”这些思考整理出来，希望能起个抛砖引玉的作用。

一、当前RAG的通用做法

假设这是一段文本：

现在的常规操作，就是按固定大小，或者兼顾一下标点符号，把全文拆成小段。比如下面不同颜色的文字，会被拆成同一段：

然后再把这些片段首尾相接或部分重叠，进行向量化和存储：

最后，从里面找字面含义接近的片段，交给大语言模型生成回答。

二、对什么是语义的几点认识

上面这套通用做法，说实话，是有缺陷的。下面直接亮观点。

1. 文档结构是最大的语义

语义可不光是文本里的单词。古人讲“断章取义”，首先得把“章”断好——按字符长度来断，显然不科学。文档结构本身就是宏观的语义。在拆分、检索、生成各个环节，都应该跟文档的章节结构紧密结合起来。

2. 文档标题和目录是递进的语义摘要

标题和目录的文字，是文档作者按自己的理解归纳出来的核心表达。一段文本的语义，不仅仅基于自身，还基于它处于哪个章节里，并且要沿着目录层级一直追溯到一级标题、文档标题。这才是它完整的语义。当然，文档相关的属性（比如作者、日期）也属于整体语义的一部分。

3. 需要构建和表格等价的语义模式

文档里常有表格。现在的做法就是按文本顺序直接转成文字，说实话，转换后的文本很难读——表格内容已经跟行列标题“脱钩”了。每个单元格的内容，应该结合它所在的行列标题（包括复杂表头的多级标题），进行重构，才能保持完整语义。

4. 通过权重来调整语义的重要性

前段时间看到刘焕勇老师转了一篇文章，说人的思维是有权重的——这个观点很在理，符合直觉。实际生活中，我们看一篇文档会先判断来源的权威性；小孩也会根据说话人的身份来判断要求的重要程度。对于语义相近的文字，如果来源不同，语义相似度就应该体现来源的权重。重要来源的文字，哪怕相似度小一点，它对输出影响的优先级也可能要排前面。举个极端的例子：大Boss讲的话，能跟普通员工的个人总结相提并论吗？如果所有文本片段只按向量余弦相似度排序，那真叫鱼龙混杂。

三、SemanticRAG的实现思路

1. 向量库构建

（1）文档结构识别

对于一篇文档，首先要重建它的结构。如果是Word、PPT、PDF，可能已经包含了一些章节结构，要识别并利用起来。除了已有的章节结构，还可能有一些文档没标出章节结构，这时需要进一步智能识别章节名称、列表编号、手工编号、短标题，力争识别到最小层级的、可以当目录用的程度。

虽然现在有些开源工具能判断Word文档的章节结构，但不同版本、样式差异巨大，章节结构的表示方法千奇百怪，提取效果并不理想，坑特别多。可能需要用人工智能的方式来恢复章节结构——但大家现在好像都热衷版面识别和图标识别，鲜少看到这个方向的工作。

如下图，先识别文档的章节结构及包含关系：

（2）构建层级的语义等价模型

在系统中，对于解析完成的文档，要形成跟文档章节结构对应的树状结构，最小节点就是自然段（包括各级标题）。这个层级关系在数据库里也得体现出来。从语义上讲，拆分后的文档应该跟原始文档等价——也就是能通过工具反过来生成物理文档，章节结构和文本逻辑顺序跟原来一致。文本片段、表格、图片，都得能恢复。这样就不会出现跨章节、跨段落的拆分情况。

（3）段落拆分

原始文档可能太长，超出大语言模型能接受的输入长度。这时需要结合模型上下文长度，按自然句对段落内容进行拆分。这样就不会出现跨自然句拆分的情况，也打破常规200字符的约束，更好地发挥大语言模型长上下文的优势。

（4）文本节点预处理

首先，要形成摘要。包括末级节点内容的文本摘要、层级目录拼接形成的原始创作者设定语义摘要，以及图表的标题文字提取形成的图表语义摘要（也可以在语义等价转换或识图后按文字再次形成摘要）。

此外，除了生成向量，还要生成不同节点文本的Token长度。为什么需要摘要和Token长度？后面结合使用的时候再解释。

2. 文本语义召回

（1）从上至下进行并发串行多路召回

从语义检索的角度，这里跟LangChain、SemanticKernel等工具的逐条向量查找有本质区别。需要和文档结构结合起来。

首先，找到所有可检索内容的根节点。用并发线程，从各个根节点开始往子节点做广度遍历。如果某个节点满足召回要求，就把该节点及其所有子节点当作一条检索记录增加到结果集合中，不再遍历其子节点。

其次，检索时可以按优先级先后使用关键词查找、向量相似度判断。只要一个条件满足，就立刻增加到检索结果中，避免分开进行多路召回时可能产生的重复检索和合并问题。

注意：检索结果可能是带子节点的子文档片段，要保持符合原文的自然层级结构，方便后续进行语义生成。

（2）对相似度进行差异化处理

先得到原始相似度。全文或关键字匹配的情况，预设一个固定相似度；向量检索的情况，使用实际向量相似度。接着，将原始相似度和该文档的权重相乘，得到权重相似度。最后按相似度阈值筛选，得到满足要求的检索结果。目前还没有引入专用的rerank模型，暂时无法判断其必要性。

3. 语义生成

（1）从下至上按照层级生成回答

对于检索回来的每个带层级信息的文本片段，按照深度遍历的方式，用正常问答不断聚合，提取有效答案信息，直到根节点形成一段文字。最后，再基于各段文字，用正常问答做新一轮聚合，得到最终答案。

注意：只能把某个文本片段下属的相邻同级节点进行语义聚合，以保持语义的对等性。

（2）根据大语言模型的能力生成

生成过程中，要尽可能减少大语言模型的问答次数。结合上下文窗口，合理把握对话时机，尽量让语料累积到接近可用的输入长度上限再提交，减少生成次数。

整个处理流程如下图：

四、几点注意事项

1. 关于提升性能

（1）缓存文档树形结构

可以在内存缓存需要处理的文档，包括上下级结构、向量和Token数量，便于快速检索。这个数据结构可以采用双向无环图。

（2）按需动态使用摘要

根据不同情况，分别对摘要或文本内容做向量相似度判断。比如目录可以用摘要，减少对下级节点文本的检索。

（3）使用预处理形成的Token长度

预处理时，所有摘要和文本内容都预先生成了Token长度。在生成检索时，可以对累积的文本动态计算总Token长度，在恰好达到可用的输入长度时提交给大语言模型，减少调用次数，缩短时间开销。

（4）并发召回

从各个文档片段的根节点同时进行广度遍历，无需检索所有末级节点，也无需用不同算法重复检索，前面已经提到。

（5）按照权限对数据进行预过滤

按当前用户的权限及指定的检索范围（如文档类型、组织机构等），预先构建符合需要的树形结构，再进行检索。这样可以减少召回范围、加快遍历速度，同时确保信息安全。

2. 关于提升检索生成的准确性

（1）答案预生成

可以预先生成答案，再将原始问题和答案一起向量化，最后做向量比较。从逻辑上，答案进一步启发了答案的可能向量，便于找出更多余弦相似度高的文本。这也是目前多位大佬推荐的做法。

（2）选择合适的大语言模型进行嵌入和生成

现在的RAG系统，一般都用专门的嵌入模型，性能可能更好。但这里有一个不同的理解：

首先，建议使用同一个大语言模型来做嵌入和生成。大语言模型经过大量语料训练和微调，见多识广，在向量化上应该更精准。让一个模型做嵌入、另一个模型做生成，就好比一个人负责采买回来一匹马，另一个人负责入库非说这是头鹿。两个模型的知识面和理解能力都不在一个层次上，各管一头能行吗？哪个模型说文本里有我要的东西，就该它负责给我找出来，别互相踢皮球。这个观点可能不对，欢迎批评指正。

其次，如果条件允许，建议对不同语料使用不同的大语言模型进行向量化，包括文本和问题。之前的两篇文章有详细对比——不同大语言模型的文本生成能力和向量化能力差异很大，尤其是对不同语言的文本。建议结合具体要解决的领域内容，用不同的大语言模型做向量化比较，查看向量相似性值和空间分布。一个适用的大模型，相似的文本对和不相似的文本对，向量余弦相似度值差异越大越好，比如0.8和0.3的区别。一个不大适用的模型，可能把貌似不相关的文本对的相似度都整到0.6。举个例子，“王大力的籍贯在哪里？”与“单行。甘肃电信网络采用三级结构, 汇聚层：”的向量余弦相似度，WizardLM-2-7B_Q8给出的值是0.6022，Yi-1.5-9B-Chat-Q6_K给出的值是0.4913。0.6这个值，直觉上没法接受。当然，WizardLM很棒也很全面，这里可能是中文语料不足导致的。

（3）实现QOS按需检索

人有慢思维和快思维，有简单思考也有仔细琢磨。RAG也应该一样。快速检索时，可以只检索摘要，或者检索权重相对大的文档。如果实在找不到，或者想仔细翻箱倒柜，再仔细检索节点文本，或者不断降低相似度阈值和权重要求。这样就实现了一个逐步递进的思考过程——当然，代价是计算量和时间。这里还有一个数据置信度的概念，就不展开讨论了。

3. 关于检索生成的安全性和便利性

（1）要细化数据权限控制

在企业级应用或多租户场景，大家的文档都混在一起，必须严格控制访问权限。甚至同一份文档，可能同时涉及技术、商务、保密等不同内容，更需要控制不同章节的查看人员。因此，要考虑组织机构、文档类别、角色、目录、文档、章节等细粒度控制权限。

（2）实现向量数据和关系数据一体化存储

现在的开源系统在企业里很难直接拿来用，主要问题在于权限数据、文档数据、向量数据三者脱节，难以做细粒度权限控制。虽然像Postgres支持向量字段和向量检索，但开源系统一般倾向于用专用向量数据库。向量数据库检索速度是快了，但跟结构化数据很难快速有效地建立关系，制约了系统功能开发。

我采用了SQLite数据库，将文档结构、文本片段、组织机构权限以及向量全部存储在一起。向量作为文本存储，从数据库加载时虽然有性能损耗，但用起来很方便，尤其是对数据和关系做缓存后，对性能基本没影响。一体化存储最大的好处，是可以给已有的信息化系统快速添加向量检索和知识问答功能。

RAG的探索就告一段落。欢迎留言讨论。