RAG索引优化实战：摘要与父子索引提升检索质量

1. 项目概述：当RAG遇上“索引优化”的深水区

如果你已经跟着这个系列从零开始搭建过基础的RAG系统，那么恭喜你，你已经成功“下水”了。但就像游泳一样，在浅水区扑腾和到深水区应对暗流完全是两码事。很多朋友在初步跑通RAG流程后，会立刻遇到一个瓶颈：为什么我的系统回答质量时好时坏？有时候能精准命中，有时候又答非所问，甚至胡言乱语？问题的根源，十有八九出在“索引”这个最基础，也最容易被轻视的环节。

我们之前聊过的文本分块（Chunking）和向量化，只是构建索引的“第一步”。今天要深入的这个话题——Advanced RAG中的摘要索引与父子索引优化，才是决定你的RAG系统是“玩具”还是“生产级工具”的关键分水岭。这不再是简单地用个RecursiveCharacterTextSplitter把文档切碎就完事了，而是要从信息检索的底层逻辑出发，去设计一种更聪明、更贴合大语言模型（LLM）理解习惯的数据组织形式。

简单来说，摘要索引和父子索引是两种用于优化检索质量的进阶索引策略。它们共同的目标是解决传统“扁平化”向量索引的固有缺陷：信息丢失和上下文割裂。当你把一篇长文档切成几百个独立的小片段（Chunk）并分别嵌入成向量后，每个片段都像一个孤岛，失去了与原文整体结构和其他部分的关联。检索时，系统可能只召回了一个包含关键词但语义不完整的“孤岛”，导致LLM得到的上下文支离破碎，自然生成质量低下。

而摘要索引和父子索引，就是搭建在这些“孤岛”之间的桥梁和导航图。接下来，我会结合我踩过的坑和实战经验，带你彻底搞懂这两种策略的原理、实现方法以及如何将它们应用到你的项目中，真正提升RAG的召回精度和回答质量。

2. 核心困境：为什么扁平化向量索引不够用？

在深入解决方案之前，我们必须先诊断清楚“病情”。直接对所有文本块进行扁平化的向量索引，是大多数RAG入门教程的做法，但它至少存在三个致命伤，限制了系统性能的天花板。

2.1 信息丢失与“金块”被埋没

想象一下，你有一份50页的产品技术白皮书。其中最关键的核心结论和独特卖点，可能只分布在某几页的特定段落里。当你用固定大小的窗口（比如512个token）去滑动切割这份文档时，会发生什么？那些核心的“金块”信息，很可能被切在了两个文本块的边界上。比如，一个重要的定义前半句在A块的末尾，后半句在B块的开头。当用户查询这个定义时，无论A块还是B块的向量，都无法完整表达该概念，导致两者与查询的语义相似度都不高，从而双双落选，这块“金子”就被彻底埋没了。这就是边界效应带来的信息丢失。

2.2 上下文割裂与“断章取义”

即使“金块”幸运地完整存在于某个文本块中，这个文本块脱离了前后文的支撑，也可能变得难以理解或容易被误解。比如，文档中有一句“这个方案不建议在性能敏感的场景中使用”。如果它所在的文本块被单独检索出来，LLM看到的就是一个孤立的否定结论。但它可能忽略了前文提到的“在资源充足的情况下，该方案具有简化架构的优势”，以及后文补充的“但可以考虑其变体方案B”。缺乏上下文，LLM就无法做出准确、全面的回答，甚至可能基于片面的信息给出错误建议。检索系统给了LLM一堆“断章取义”的碎片，却指望它拼出完整的图画，这显然不合理。

2.3 检索粒度与回答粒度的不匹配

这是最微妙也最普遍的一个问题。用户的提问是有不同粒度的。有些是“针尖式”的精确事实问答（“本公司产品的保修期是多久？”），有些是“伞状式”的概括性询问（“请总结一下这份财报的要点”）。而传统的扁平索引，其检索粒度在索引创建时就被固定了（比如每个块500字）。用固定粒度的“渔网”去捞不同大小的“鱼”，结果就是：针对细节问题，可能捞上来一个包含答案但也包含大量无关信息的大块，增加了LLM的处理噪音；针对概括性问题，可能捞上来几十个相关但重复的小块，却无法提供高层次的摘要视角。这种不匹配直接导致了回答冗余、重点不突出或缺乏洞见。

踩坑实录：在我早期的一个客服知识库项目中，我们使用了标准的512-token分块。结果发现，对于“如何重置密码”这种具体操作，回答常常混入相邻的“账户安全须知”内容，显得啰嗦；而对于“你们有哪些服务套餐”这种需要概括的问题，回答则是机械地罗列了四五个文本块的内容，重复且没有归纳。这就是典型的粒度错配。

所以，仅仅依靠语义相似度的向量检索，就像只靠关键词匹配的搜索引擎一样，已经触及了瓶颈。我们需要更丰富的索引结构，来承载更多的信息和关系。这就是摘要索引和父子索引登场的背景。

3. 摘要索引：为文档建立“导航地图”

摘要索引的核心思想非常直观：为每个文档或大的文本单元（如章节）创建一个简洁、准确的摘要，并将这个摘要单独做成一个可检索的“导航点”。

3.1 设计思路与工作原理

它的工作流程可以拆解为两步：

1. 摘要生成：在索引构建阶段，使用LLM（通常是性价比更高的轻量级模型，如GPT-3.5-Turbo或Claude Haiku）为每个文档生成一个高质量的摘要。这个摘要需要捕捉文档的核心主题、关键论点和结论。
2. 两级检索：在查询阶段，系统首先在“摘要库”中进行检索。找出与用户问题最相关的几个摘要（即最相关的几篇文档或章节）。然后，只在这几篇被选中的文档内部，进行传统的、针对原始文本块的向量检索或关键词检索。

你可以把它理解为图书馆的“目录卡”系统。用户先查目录卡（摘要），找到可能相关的书籍区域（文档），然后再去那个区域的书架上仔细翻阅（细粒度检索）。这样做的好处是：

• 效率提升：避免了在全量海量文本块中进行暴力搜索，首轮检索的范围大大缩小。
• 主题保真：摘要能更好地代表整个文档的中心思想，对于主题性、概括性的查询，召回准确率显著提高。
• 控制上下文长度：最终提供给LLM的，是来自少数几篇高度相关文档的精确文本块，上下文更干净、更聚焦。

3.2 实操实现：以LlamaIndex为例

在LlamaIndex中，实现摘要索引非常优雅。它提供了高级抽象，让我们无需手动管理两个索引。关键概念是SummaryIndex和VectorStoreIndex的组合使用。

from llama_index.core import SimpleDirectoryReader, SummaryIndex, VectorStoreIndex from llama_index.core.node_parser import SentenceSplitter from llama_index.core import Settings from llama_index.llms.openai import OpenAI import os # 1. 设置LLM（用于生成摘要） os.environ["OPENAI_API_KEY"] = "your-api-key" Settings.llm = OpenAI(model="gpt-3.5-turbo") # 摘要生成不需要用太重的模型 # 2. 加载文档 documents = SimpleDirectoryReader("./your_data").load_data() # 3. 创建摘要索引 summary_index = SummaryIndex.from_documents(documents) # 4. 从摘要索引中提取出“文档摘要节点” # 每个文档会被LLM总结成一个摘要节点（SummaryNode） summary_nodes = summary_index.as_retriever().retrieve("用户的概括性问题") # 假设我们取最相关的一个摘要节点，获取其对应的源文档 target_document_id = summary_nodes[0].node.ref_doc_id # 5. 为所有原始文本创建向量索引（用于细粒度检索） # 首先进行文本分块 node_parser = SentenceSplitter(chunk_size=512, chunk_overlap=50) base_nodes = node_parser.get_nodes_from_documents(documents) # 为每个节点添加元数据，记录它属于哪个源文档 for node in base_nodes: node.metadata["document_id"] = node.ref_doc_id vector_index = VectorStoreIndex(base_nodes) # 6. 构建查询引擎：先摘要检索，后向量检索 from llama_index.core.retrievers import RecursiveRetriever from llama_index.core.query_engine import RetrieverQueryEngine # 定义摘要检索器（第一轮） summary_retriever = summary_index.as_retriever(similarity_top_k=2) # 返回top2最相关的文档摘要 # 定义向量检索器，但将其包装成一个“根据文档ID过滤”的检索器 from llama_index.core import QueryBundle from llama_index.core.retrievers import BaseRetriever from typing import List class FilteredVectorRetriever(BaseRetriever): def __init__(self, vector_index, target_doc_ids): self._vector_retriever = vector_index.as_retriever(similarity_top_k=5) self._target_doc_ids = target_doc_ids def _retrieve(self, query_bundle: QueryBundle) -> List[NodeWithScore]: # 先进行普通向量检索 all_nodes = self._vector_retriever.retrieve(query_bundle) # 过滤出属于目标文档的节点 filtered_nodes = [n for n in all_nodes if n.node.metadata.get("document_id") in self._target_doc_ids] return filtered_nodes # 在查询时动态组合 def query_with_summary_first(user_query): # 第一轮：摘要检索 summary_results = summary_retriever.retrieve(user_query) target_doc_ids = [node.node.ref_doc_id for node in summary_results] if not target_doc_ids: return "未找到相关文档。" # 第二轮：在目标文档内做向量检索 filtered_retriever = FilteredVectorRetriever(vector_index, target_doc_ids) fine_grained_nodes = filtered_retriever.retrieve(user_query) # 用检索到的细粒度节点构建上下文，交给LLM生成最终答案 query_engine = RetrieverQueryEngine.from_args(filtered_retriever) response = query_engine.query(user_query) return response # 使用 result = query_with_summary_first("请概括一下公司去年在人工智能领域的主要投入和成果") print(result)

关键参数与经验：

• 摘要生成模型的选择：不必使用最顶级的模型（如GPT-4），gpt-3.5-turbo或claude-3-haiku在大多数情况下足以生成质量不错的摘要，成本更低。你可以通过设计更好的提示词（Prompt）来引导摘要质量，例如要求其“突出三个关键创新点”或“遵循‘背景-方法-结果’结构”。
• 摘要检索的Top-K：第一轮摘要检索返回的文档数（similarity_top_k）不宜过多，通常2-5个足矣。目的是快速筛选出最相关的文档池，而不是一次性找全所有相关片段。
• 元数据关联：这是整个架构的“粘合剂”。务必确保在创建细粒度文本块（Node）时，通过node.metadata字段将其与原始文档ID（ref_doc_id）强关联。否则，第二轮过滤将无法进行。

3.3 适用场景与注意事项

最适合摘要索引的场景：

1. 文档集合主题明确、区分度大：比如公司内部不同产品的技术手册、各个独立项目的报告、多个客户的案例分析等。摘要能清晰区分不同文档的主题。
2. 用户查询多为概括性、主题性：例如“介绍一下A项目”、“总结Q3的财务状况”、“你们在环保方面做了哪些工作”。
3. 文档长度较长，内部结构复杂：如书籍、长篇研究报告、学术论文。

需要警惕的坑：

• 摘要质量瓶颈：摘要的质量直接决定第一轮检索的准确性。如果LLM生成的摘要歪曲了原文主旨，整个检索方向就会跑偏。务必对摘要结果进行抽样检查，特别是对于关键文档。
• 额外成本与延迟：摘要索引需要在构建阶段为每个文档调用一次LLM，产生了额外的成本和时间。对于动态更新非常频繁的知识库（如实时新闻），需要设计增量摘要更新策略。
• 不适用于碎片化知识：如果知识库本身是由大量独立的、短小的FAQ条目或代码片段组成，每个条目本身就很短，再生成摘要意义不大，反而增加了复杂度。

4. 父子索引：构建“金字塔”式上下文结构

如果说摘要索引是“地图导航”，那么父子索引就是“层层递进的多级菜单”。它解决的是如何在保持细粒度检索能力的同时，为召回的文本块自动提供必要的上下文。

4.1 设计思路与工作原理

父子索引的核心是创建一种层次化的节点关系：

1. 父节点（Parent Node）：代表一个较大的文本单元，例如一个完整的章节、一个模块的文档，或者是由多个小段落合并而成的“大块”。父节点提供了较宽的上下文视野。
2. 子节点（Child Node）：代表从父节点中切割出来的、更小的、更精确的文本块。这是我们进行向量检索的基本单位。
3. 关系绑定：在索引中，明确记录每个子节点归属于哪个（或哪些）父节点。

当进行查询时，系统首先像往常一样，通过向量相似度找到最相关的子节点。但是，在将这些子节点作为上下文发送给LLM之前，系统会自动将每个子节点对应的父节点内容（或其中的一部分）也附加上去。这样，LLM在阅读那个精确的答案片段时，也能看到它周围的背景信息。

4.2 实操实现：双索引与自动上下文注入

在LlamaIndex中，实现父子索引通常需要维护两个索引：一个用于子节点的向量检索，另一个用于存储和查询父子关系。

from llama_index.core import SimpleDirectoryReader, VectorStoreIndex from llama_index.core.node_parser import HierarchicalNodeParser, SentenceSplitter from llama_index.core.schema import IndexNode from llama_index.core.retrievers import RecursiveRetriever import os # 1. 加载文档 documents = SimpleDirectoryReader("./your_data").load_data() # 2. 使用分层解析器创建不同粒度的节点 # 方法一：使用简单的两级分割 node_parser = SentenceSplitter(chunk_size=1024, chunk_overlap=100) # 父节点块较大 parent_nodes = node_parser.get_nodes_from_documents(documents) # 为每个父节点创建更小的子节点 child_nodes = [] for parent_node in parent_nodes: # 对每个父节点内容再次进行分割，得到子节点 child_splitter = SentenceSplitter(chunk_size=256, chunk_overlap=50) children = child_splitter.get_nodes_from_documents([parent_node.text]) for child in children: # 关键：在子节点元数据中记录父节点ID child.metadata["parent_id"] = parent_node.node_id # 也可以选择存储父节点的部分文本作为引用 child.metadata["parent_text_snippet"] = parent_node.text[:500] # 存前500字符作为上下文预览 child_nodes.extend(children) # 方法二（更规范）：使用LlamaIndex的HierarchicalNodeParser（如果版本支持） # 它可以自动创建层级关系。 # 3. 创建索引 # 3.1 为子节点创建向量索引（用于精确检索） vector_index = VectorStoreIndex(child_nodes) # 3.2 构建一个父节点ID到父节点内容的映射字典，用于快速查找 parent_node_dict = {node.node_id: node for node in parent_nodes} # 4. 构建支持父子关系的检索器 from llama_index.core.retrievers import BaseRetriever from llama_index.core import QueryBundle class ParentChildRetriever(BaseRetriever): def __init__(self, vector_index, parent_node_dict, child_top_k=5, parent_context_length=500): self._vector_retriever = vector_index.as_retriever(similarity_top_k=child_top_k) self._parent_node_dict = parent_node_dict self._parent_context_length = parent_context_length def _retrieve(self, query_bundle: QueryBundle) -> List[NodeWithScore]: # 第一步：检索最相关的子节点 child_nodes_with_score = self._vector_retriever.retrieve(query_bundle) enriched_nodes = [] for child_node_w_score in child_nodes_with_score: child_node = child_node_w_score.node # 第二步：找到该子节点的父节点 parent_id = child_node.metadata.get("parent_id") if parent_id and parent_id in self._parent_node_dict: parent_node = self._parent_node_dict[parent_id] # 第三步：将父节点的部分内容作为上下文，与子节点内容合并 # 这里采取的策略是：将父节点文本作为前缀，与子节点文本拼接 parent_context = parent_node.text[:self._parent_context_length] enriched_text = f"[上下文背景]: {parent_context}\n\n[精确相关段落]: {child_node.text}" # 创建一个新的、内容被增强的节点对象，保留原分数和其他元数据 enriched_node = IndexNode( text=enriched_text, metadata=child_node.metadata, relationships=child_node.relationships ) enriched_node_w_score = NodeWithScore( node=enriched_node, score=child_node_w_score.score ) enriched_nodes.append(enriched_node_w_score) else: # 如果没有找到父节点，则使用原子节点 enriched_nodes.append(child_node_w_score) return enriched_nodes # 5. 使用增强后的检索器创建查询引擎 parent_child_retriever = ParentChildRetriever(vector_index, parent_node_dict, child_top_k=3, parent_context_length=600) query_engine = RetrieverQueryEngine.from_args(parent_child_retriever) response = query_engine.query("请解释一下‘动态负载均衡’在这个架构中是如何工作的？") print(response)

实现要点解析：

• 层级划分策略：如何定义“父”与“子”的粒度是关键。一个实用的经验法则是：父节点的大小应足以涵盖一个完整的子主题或逻辑单元（如一个小节），而子节点则是其中用于回答具体问题的“答案单元”。常见的比例是父节点大小是子节点的2-4倍。
• 上下文注入方式：上面的示例是将父节点文本直接拼接到子节点前。更精细的做法可以是：
  • 只注入父节点的开头和结尾部分。
  • 使用LLM提取父节点中与子节点最相关的几个句子。
  • 在元数据中存储父节点的摘要，然后注入摘要。
• RecursiveRetriever的替代方案：LlamaIndex也提供了内置的RecursiveRetriever，它可以与IndexNode配合，自动根据节点间定义的关系（如NodeRelationship.PARENT）进行递归检索。这对于更复杂的多层级结构（祖-父-子）非常有用。

4.3 适用场景与优化技巧

父子索引大显身手的场景：

1. 技术文档与代码库：一个函数（子节点）需要其所在的类或模块说明（父节点）作为上下文才能被正确理解。
2. 法律与合同文档：某个具体条款（子节点）的解释高度依赖于其所在的章节总则（父节点）。
3. 长叙事性内容：小说、历史资料中，一个具体事件（子节点）需要前后情节（父节点）来铺垫。
4. 解决“边界效应”：当答案恰好位于两个子块边界时，通过注入共同的父节点上下文，有很大概率能补全信息。

高级优化技巧：

• 动态上下文长度：不要总是注入固定长度的父节点文本。可以根据子节点在父节点中的位置（开头、中间、结尾）动态调整注入的上下文部分。例如，如果子节点在父节点开头，则多注入后面的一些内容；如果在结尾，则多注入前面的一些内容。
• 多父节点引用：一个子节点可能同时与多个父节点相关（例如，一个概念在两个章节都被提及）。可以在元数据中存储一个parent_ids列表，检索时注入多个父节点的摘要或关键部分。
• 与重排序（Re-Ranking）结合：在检索到子节点并注入父上下文后，可以引入一个轻量级的重排序模型（如Cohere Rerank、BGE Reranker），对增强后的节点文本与查询的相关性进行重新打分，确保最终送给LLM的是质量最高的上下文。

5. 混合策略与工程化实践

在实际生产环境中，摘要索引和父子索引往往不是二选一，而是可以组合使用，形成更强大的混合检索策略。同时，它们的引入也带来了新的工程复杂度。

5.1 摘要与父子的组合拳

一个典型的混合架构工作流如下：

1. 索引构建阶段：

   • 为每个文档生成摘要，建立摘要索引。
   • 对每个文档进行分层解析，生成父节点和子节点，并建立关联。
   • 为所有子节点建立向量索引（主检索索引）。
   • 存储所有父节点内容，并建立节点ID到内容的快速查找表（如内存字典或键值数据库）。

2. 查询阶段：

   • 第一轮：主题路由。用户查询先进入摘要索引检索，找出最相关的N个文档（比如Top-2）。这步过滤掉了大量不相关的文档。
   • 第二轮：精确检索。仅在上述N个文档对应的子节点池中，进行向量相似度检索，得到最相关的M个子节点（比如Top-5）。
   • 第三轮：上下文增强。为这M个子节点查找并注入其对应的父节点上下文。
   • 第四轮（可选）：重排序。对增强后的M个节点进行重排序，选出最终Top-K个（比如Top-3）节点。
   • 最终：将精选并增强后的上下文，连同用户查询，提交给LLM生成答案。

这个流程结合了摘要索引的“主题过滤”优势和父子索引的“上下文增强”优势，既能保证召回的相关性，又能提供丰富的背景信息，是应对复杂查询的利器。

5.2 性能、成本与更新权衡

引入高级索引意味着更多的计算和存储开销，需要在设计时权衡：

• 存储开销：除了存储原始文本块向量，还需要存储摘要向量、父节点文本/向量、以及关系映射。存储成本可能增加50%-100%。

• 构建成本与延迟：摘要生成需要调用LLM，分层解析需要额外的文本处理。索引构建时间会显著增加，不适合需要实时索引新数据的场景。

• 查询延迟：多级检索流程（摘要检索->子节点检索->父节点查找）会增加链式调用延迟。需要通过异步并行、缓存等机制优化。

  • 缓存策略：对高频查询的摘要检索结果、父子关系映射进行缓存。
  • 异步并行：第一轮摘要检索和后续针对不同文档的子节点检索，如果可以独立进行，可以考虑并行执行。

• 更新策略：这是最棘手的问题。当源文档发生修改时，你需要：

  1. 更新该文档的摘要。
  2. 更新该文档对应的所有父节点和子节点。
  3. 更新向量索引中所有受影响子节点的嵌入向量。
  4. 更新关系映射。 一种实践是采用“标记-重建”策略：将发生变化的文档标记为“脏数据”，在低峰期批量重建其相关的所有索引结构。对于实时性要求极高的场景，可能需要设计增量更新算法，但这非常复杂。

5.3 评测与迭代：如何判断优化是否有效？

不能凭感觉说“好像变好了”，必须建立量化评估体系。对于摘要和父子索引的优化，可以关注以下指标：

1. 检索精度（Precision@K）：在前K个召回结果中，真正相关的文档/片段所占的比例。优化后，这个指标（尤其是对于概括性查询）应有提升。
2. 答案相关性（Answer Relevance）：使用LLM作为裁判，评估最终生成的答案与标准答案或文档内容的契合度。这是最直接的端到端指标。
3. 上下文利用率（Context Utilization）：分析LLM在生成答案时，是否真正用到了你提供的父节点上下文。可以通过检查输出中是否包含仅存在于父节点中的信息来间接判断。
4. 人工评估（A/B测试）：选取一批有代表性的真实用户查询，分别用优化前（扁平索引）和优化后（混合索引）的系统进行回答，让领域专家进行盲评打分。

建立一个持续的评估流水线，将上述指标自动化，是迭代优化RAG系统的基石。每次索引策略的调整，都应通过这个流水线来验证其效果。

6. 避坑指南与常见问题排查

在实际部署摘要和父子索引时，我遇到过不少“坑”，这里总结出来，希望能帮你绕过去。

6.1 摘要质量不稳定

• 问题：LLM生成的摘要有时会遗漏关键信息，或加入原文没有的“臆测”。
• 排查与解决：
  • 优化提示词（Prompt）：不要只用“请总结以下文档”。尝试更结构化的指令，如“请以‘背景、挑战、解决方案、结果’四部分总结该技术文档，确保涵盖所有关键技术参数。”。
  • 提供示例（Few-Shot）：在提示词中给出一两个好的摘要示例，引导LLM遵循所需的格式和风格。
  • 分而治之：对于超长文档，不要一次性总结全部。先让LLM总结各个章节，再基于章节摘要生成总摘要。
  • 后处理校验：可以设计一个简单的规则或使用另一个轻量模型，检查摘要中是否包含了原文的关键实体（如产品名、技术术语、数字指标）。

6.2 父子节点关联错误或断裂

• 问题：检索到的子节点找不到对应的父节点，或者关联的父节点内容不匹配。
• 排查与解决：
  • 确保ID唯一性与一致性：在创建节点时，使用确定性的方式生成node_id（如f”doc_{doc_id}_chunk_{chunk_idx}”），并在存储父子关系时，严格校验ID是否存在。
  • 关系持久化：不要仅依赖内存中的字典。将父子关系持久化到数据库（如SQLite、PostgreSQL）或图数据库中，确保在服务重启后关系不丢失。
  • 构建时验证：在索引构建完成后，运行一个简单的验证脚本，随机采样一批子节点，检查其parent_id是否能找到对应的父节点，并预览注入的上下文是否合理。

6.3 查询延迟明显增加

• 问题：引入多级检索后，接口响应速度变慢。
• 排查与解决：
  • 性能剖析：使用 profiling 工具，测量查询各阶段的耗时（摘要检索、向量检索、父节点查找、上下文拼接）。瓶颈往往出现在某一环。
  • 向量检索优化：确保子节点的向量索引使用了高效的近似最近邻搜索（ANN）库，如FAISS、HNSW，并设置了合理的索引参数。
  • 并行化：如果摘要检索和子节点检索没有严格依赖，可以考虑并行执行。
  • 缓存：对摘要向量、热门查询的中间结果进行缓存。可以使用Redis或内存缓存。

6.4 最终答案并未利用增强的上下文

• 问题：虽然成功注入了父节点上下文，但LLM生成的答案似乎还是只基于子节点的核心段落。
• 排查与解决：
  • 检查上下文格式：确保你注入的上下文在Prompt中清晰标识，例如使用明显的分隔符如[Background]: ...，并在系统指令中明确要求LLM“参考提供的背景信息”。
  • 调整上下文长度：注入的父节点上下文可能太长了，被LLM忽略。尝试缩短它，只保留最相关的几句。
  • 优化Prompt：在用户查询中，可以隐式地要求模型结合背景。例如，将查询改为“基于其所在章节的总体设计原则，请解释...”。

从扁平化的向量索引，到引入摘要索引和父子索引，是RAG系统从“能用”走向“好用”的关键一步。这本质上是从“统计相似度”匹配，走向“语义理解+结构关联”的智能检索。它要求我们更深入地理解自己的数据特性和用户需求，并投入更多的工程设计。虽然初期复杂度有所上升，但对于回答质量要求高的生产场景，这份投入是绝对值得的。我的建议是，先从你的知识库中挑选一个最有代表性的、问题最突出的子集，尝试实现这两种策略，进行严格的A/B测试。亲眼看到回答质量的提升，会是你继续深入优化RAG系统的最佳动力。