1. 从RAG的痛点看父子索引的价值
在构建RAG(检索增强生成)系统时,我们常常陷入一个两难困境:如果文本切片(chunk)设置得太小,虽然检索准确率提高了,但上下文信息支离破碎,导致大模型生成的回答缺乏连贯性;如果切片太大,又会引入大量无关内容,降低检索的精准度。
这个矛盾在我去年参与的一个金融知识问答系统项目中表现得尤为明显。最初我们使用固定大小的512token切片,结果发现:
- 对于"什么是LPR利率"这类简单问题,系统表现良好
- 但当用户询问"比较LPR改革前后房贷计算方式的差异"这类需要跨段落理解的问题时,生成的回答经常出现逻辑断层
经过多次实验,我们最终采用父子索引方案,使问答准确率提升了37%。这种技术之所以有效,是因为它做了一个聪明的分层设计:让小切片负责精准匹配,让大切片保证上下文完整。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 父子索引的工作原理详解
2.1 核心设计理念
父子索引的核心在于"分而治之"的策略:
- 检索层(子块):100-200token的小切片,确保向量搜索的敏感度
- 生成层(父块):600-2000token的大切片,保持语义连贯性
这种设计类似于学术论文的检索过程:先通过关键词找到相关段落(子块),然后阅读整节内容(父块)获取完整上下文。
2.2 技术实现四部曲
2.2.1 分层切分策略
python复制parent_splitter = RecursiveCharacterTextSplitter(chunk_size=600)
child_splitter = RecursiveCharacterTextSplitter(chunk_size=200)
- 父块按语义完整性划分(如完整段落或章节)
- 子块在父块内部进一步细分,并携带parent_id标识
2.2.2 智能索引构建
python复制vectorstore = Chroma(collection_name="split_parents") # 存储子块向量
store = InMemoryStore() # 存储父块原始文本
- 仅对子块进行向量化处理
- 父块以原始文本形式存储,节省计算资源
2.2.3 检索回溯机制
python复制retriever
