简介这份源码资源面向正在搭建RAG应用、需要优化长文档切分环节的开发者与AI学习者围绕检索增强生成中的切片策略展开帮助解决文档切分粒度不当导致检索召回差、生成答案质量低的问题。资源包共5个文件以Python脚本为主另含requirements.txt依赖清单、.inscode与.gitignore等工程配置文件整体约13KB轻量易读可直接运行验证。内容覆盖改进的固定长度切片、语义切片、LLM语义切片、层次切片与滑动窗口切片五种方法并配有结合FAISS搭建本地知识库的流程图与选型指南便于对照不同场景选择合适策略。目前已有201人学习下载适合希望快速理解切片原理、动手调试参数并落地到本地知识库项目的中级开发者参考。1. RAG 切片策略为什么成了知识库效果的黑匣子做过 RAG 知识库的人大多有过这种体验向量库建好了检索链路也通了模型回答却总是差一口气——要么答非所问要么把两段不相干的内容缝在一起。排查到最后问题往往不在 embedding 模型也不在 rerank而是最上游那个最容易被忽略的环节切片策略。切片决定了知识以什么粒度进入向量空间粒度错了后面所有环节都在为它擦屁股。这份 RAG 切片策略指南要解决的就是把「凭感觉切」变成「按文档结构切、按检索目标切」。它适合两类人一类是刚跑通 RAG demo、准备上真实知识库的工程师另一类是知识库已经上线、但召回率和答案准确率卡在瓶颈上不去的从业者。切片不是玄学它有一套可复现的参数体系和判断标准源码层面也就那么几个关键函数。下面从原理到代码把这条链路拆开讲。2. 切片策略的四种主流方案与选型依据2.1 固定长度切片最简单也最容易翻车固定长度切片是最常见的入门做法按字符数或 token 数硬切配一个重叠窗口。它的优点是实现简单、切片数量可控缺点是几乎不考虑语义边界一句话被拦腰截断是常态。def fixed_chunk(text, chunk_size500, overlap50): # chunk_size 按字符计中文场景下 500 字约等于 350-400 token chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) # overlap 防止边界信息丢失但会带来冗余 start end - overlap return chunks这段代码里chunk_size和overlap是两个必须调的参数。中文技术文档我一般用 400 到 600 字overlap 取 chunk_size 的 10% 到 15%。overlap 太小跨边界的问题答不出来太大向量库里全是重复内容检索时挤占 top-k 名额。固定切片的适用场景很窄纯叙述性、没有明显层级的文本比如访谈记录、会议纪要。一旦文档有标题、表格、代码块固定切片就会把结构信息切碎。2.2 递归字符切片按分隔符优先级逐层降级递归切片是目前工程上最稳的默认方案LangChain 的RecursiveCharacterTextSplitter就是典型代表。它的思路是给一组分隔符按优先级从高到低尝试先按段落切段落还太大就按句子切句子还大就按逗号切最后才硬切。from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, # 分隔符顺序决定降级策略中文场景要把中文标点加进去 separators[\n\n, \n, 。, , , , , , ], length_functionlen, ) chunks splitter.split_text(document)separators的顺序是关键它决定了切片的语义完整度。中文文档一定要把全角标点放进去否则默认的英文分隔符在中文里几乎不起作用退化成固定切片。chunk_overlap建议设为 chunk_size 的 15% 左右。递归切片的局限在于它只认字符不认文档的真实结构——一个 Markdown 表格里的行会被当成普通文本切表头和数据行可能分到不同 chunk。2.3 结构化切片按标题层级和语义单元切当知识库以 Markdown、HTML、Word 这类带结构的文档为主时结构化切片的效果明显优于前两种。核心思路是先解析出文档的标题树再以最小语义单元一个三级标题下的完整内容为切片边界。import re def structure_chunk(markdown_text, max_size800): # 按标题层级切分保留标题作为上下文前缀 sections re.split(r(?^#{1,3}\s), markdown_text, flagsre.MULTILINE) chunks [] for sec in sections: if not sec.strip(): continue # 超长章节再按段落二次切分 if len(sec) max_size: paras sec.split(\n\n) buf for p in paras: if len(buf) len(p) max_size: chunks.append(buf) buf p else: buf \n\n p if buf: chunks.append(buf) else: chunks.append(sec) return chunks这里max_size是二次切分的兜底阈值防止某个章节过长导致单条向量语义过载。结构化切片最大的价值是保留了标题路径检索命中时能直接知道这段内容属于哪个章节对生成答案的引用溯源特别有用。代价是需要针对不同文档格式写解析逻辑Markdown 好办PDF 和扫描件就得先过 OCR 和版面分析。2.4 语义切片用 embedding 相似度找断点语义切片是效果上限最高、成本也最高的方案。它先把文本按句子拆开计算相邻句子的 embedding 相似度在相似度骤降的地方断开。import numpy as np from sentence_transformers import SentenceTransformer model SentenceTransformer(BAAI/bge-small-zh-v1.5) def semantic_chunk(sentences, threshold0.75): embs model.encode(sentences, normalize_embeddingsTrue) chunks, cur [], [sentences[0]] for i in range(1, len(sentences)): # 余弦相似度归一化后直接点积 sim float(np.dot(embs[i-1], embs[i])) if sim threshold: chunks.append(.join(cur)) cur [sentences[i]] else: cur.append(sentences[i]) chunks.append(.join(cur)) return chunksthreshold是最难调的参数中文技术文档我一般从 0.7 到 0.8 之间试。阈值太高切片过碎太低等于没切。语义切片的成本在于每个句子都要过一次 embedding长文档处理慢而且断点位置不稳定同一份文档两次跑可能结果略有差异。它适合对召回精度要求极高、文档量不大的场景比如法律条款、医疗指南。四种方案的选型可以对照下表方案实现成本语义完整度适用文档主要风险固定长度低低纯叙述文本语义截断递归字符低中通用文本结构丢失结构化中高Markdown/HTML解析依赖语义切片高高高精度小库参数敏感3. 从源码角度拆解切片函数的参数与边界3.1 chunk_size 到底该按字符还是按 token 算这是被问得最多的问题。结论是切片阶段按字符算入库前按 token 校验。原因是 embedding 模型有最大输入长度限制比如 bge 系列通常是 512 token如果切片按字符算出来 600 字中文里可能超过 512 token超长部分会被静默截断你根本不知道丢了什么。from transformers import AutoTokenizer tokenizer AutoTokenizer.from_pretrained(BAAI/bge-small-zh-v1.5) def validate_chunk(chunks, max_tokens500): valid [] for c in chunks: ids tokenizer.encode(c, add_special_tokensFalse) if len(ids) max_tokens: # 超长切片按 token 边界二次切 for i in range(0, len(ids), max_tokens): valid.append(tokenizer.decode(ids[i:imax_tokens])) else: valid.append(c) return validmax_tokens要留出余量模型上限 512 的话切片控制在 480 到 500 之间给特殊 token 留位置。这一步是很多知识库效果差的隐藏原因切片看着没问题实际入库时被截断检索到的内容缺头少尾。3.2 overlap 设置多少才不浪费向量空间overlap 的本质是用存储冗余换边界信息。经验值是 chunk_size 的 10% 到 20%。低于 10%跨 chunk 的问题容易丢上下文高于 20%向量库里重复内容占比明显上升检索时 top-5 里可能三条都是同一段的重叠部分。判断 overlap 是否合理有个简单方法随机抽 20 个跨边界的问题看检索结果里是否至少有一条能覆盖完整答案。如果经常需要拼两条 chunk 才能答全说明 overlap 偏小如果 top-k 里大量重复说明偏大。这个验证比拍脑袋定参数靠谱得多。3.3 元数据怎么随切片一起入库切片不只是切文本元数据决定了检索时能不能过滤、生成时能不能溯源。我一般给每个 chunk 挂这几项来源文件名、标题路径、chunk 序号、字符数。def build_chunk_records(chunks, source, title_path): records [] for idx, c in enumerate(chunks): records.append({ text: c, metadata: { source: source, title_path: title_path, chunk_index: idx, char_len: len(c), } }) return recordstitle_path在结构化切片里尤其重要它让检索结果自带层级上下文。生成答案时把 title_path 拼在 chunk 前面模型对内容归属的判断会准很多。chunk_index用于相邻 chunk 扩展检索命中某条后可以把前后各一条一起喂给模型弥补切片边界的信息损失。4. 切片效果排查五类高频翻车现场4.1 检索命中但答案答非所问现象检索返回的 chunk 看起来相关但模型生成的答案跑偏。原因通常是 chunk 里混入了多个主题向量被平均化相似度虚高。解决检查该 chunk 是否跨越了标题边界把结构化切片的最小单元收紧到三级标题超长章节强制二次切分。4.2 表格和代码块被切碎现象问表格里的某个数值检索到的 chunk 只有半张表表头在另一条里。原因递归切片把表格行当普通文本处理。解决解析阶段识别表格和代码块把它们作为不可分割单元整块作为一个 chunk超长时按行切但每片都带上表头。4.3 短切片召回噪声大现象top-5 里全是几十字的短句信息量不足。原因语义切片阈值设太高或者文档里本身短句多。解决设一个最小 chunk 长度比如 100 字低于这个长度的切片合并到相邻切片同时检查阈值是否过严。4.4 同一文档切片结果不稳定现象重新跑一次切片chunk 数量和边界都变了。原因语义切片依赖 embedding模型版本或归一化方式变动都会影响断点。解决切片结果落盘缓存入库和检索用同一份切片产物不要每次动态切。4.5 多文档标题层级不一致导致切片粒度混乱现象有的文档切出来 200 字一条有的 2000 字一条。原因不同来源文档的标题层级深度不同结构化切片按标题切时粒度失控。解决统一预处理把各级标题归一化到固定层级再按 max_size 兜底二次切分保证切片长度分布集中。5. 把切片质量量化一套可复用的验证脚本切片调完之后怎么知道它到底好不好靠肉眼看几条是不够的得有一套量化指标。我常用的做法是构造一组「问题-答案-来源片段」的测试集跑检索看命中率。def eval_retrieval(questions, retriever, top_k5): hit, total 0, 0 for q in questions: results retriever.search(q[query], top_ktop_k) total 1 # 命中判定检索结果里是否包含答案所在片段的关键句 for r in results: if q[answer_key] in r[text]: hit 1 break return hit / total if total else 0.0answer_key是答案片段里的一个特征字符串用它判断检索是否命中。这个脚本跑下来命中率低于 80% 就说明切片或检索参数有问题。测试集不用多30 到 50 条覆盖各类问题就够关键是要包含跨 chunk 的问题专门验证 overlap 和相邻扩展是否生效。除了命中率我还会看两个分布指标切片长度分布和切片数量。长度分布应该集中在目标区间出现大量超短或超长切片就是参数没调好切片数量突然比预期多很多往往是分隔符配置有问题把不该切的地方切了。调参的顺序建议是先定切片方案再调 chunk_size 和 overlap最后用测试集验证。不要一上来就同时改多个参数那样出了问题根本不知道是哪个引起的。我自己的习惯是每次只动一个参数跑一遍测试集记录命中率找到拐点再动下一个。切片这件事没有一劳永逸的最优解文档变了、问题类型变了参数就得重新看。把这套验证脚本留着每次知识库更新后跑一遍比事后拍脑袋强得多。希望帮到你。本文还有配套的精品资源点击获取