简介：这份源码包面向RAG应用开发者与AI大模型学习者，聚焦长文档切片这一检索增强生成流程中的关键环节，帮助解决切片粒度不当导致检索召回与答案质量下降的问题。包内共5个文件，以2个Python脚本为核心，分别演示LLM语义切片与RAG切片流程，另含requirements.txt依赖清单、.inscode与.gitignore等工程配置文件，整体约13KB，轻量易读，可直接运行对照学习。内容覆盖改进的固定长度切片、语义切片、LLM语义切片、层次切片与滑动窗口切片五种策略，并给出结合FAISS搭建本地知识库的流程图与选型指南，便于按场景权衡效果与性能。目前已有202人学习下载，适合希望快速理解切片原理、动手验证不同策略差异并落地到本地知识库项目的开发者参考。

1. RAG 切片策略指南：为什么你的检索总在“差一点”的地方翻车

做 RAG 的人大多有过同一种体感：向量库建好了，embedding 模型也换了三四个，召回结果却总是“差一点”——答案明明在文档里，检索出来的片段偏偏缺了半句关键条件，或者把两个不相干的段落拼在一起喂给大模型，最后生成一段看似通顺实则跑偏的回答。很多人第一反应是去调 top_k、换重排模型，折腾一圈发现收益有限，真正的病灶往往在更前面：切片策略。

切片（chunking）决定了知识被切成什么样、以什么粒度进入向量空间。切得太碎，单块语义不完整，检索命中却答不出；切得太粗，噪声稀释了关键信息，相似度被平均掉。这份 RAG 切片策略指南要解决的，就是把“凭感觉切”变成“按文档结构和检索目标切”，并给出一套能直接跑起来的源码实现。它适合已经跑通最小 RAG 链路、正卡在召回质量上的开发者，也适合准备把原型推向生产、需要稳定切片管线的工程团队。下面从策略选型讲到代码落地，再讲那些只有踩过才知道的坑。

2. 切片策略的选型逻辑：固定窗口、递归、语义三种路线怎么挑

切片不是越高级越好，而是要和文档形态、查询类型、成本预算三者对齐。这一章先把主流策略的适用边界讲清楚，再落到可执行的实现。

2.1 三种基础策略的适用边界

固定长度切片是最朴素的方案：按字符数或 token 数硬切，配一个重叠窗口。它的优点是实现简单、块大小可控、向量维度稳定，缺点是会在句子中间断开，把“因此”“但是”这类逻辑连接词切到下一块，导致单块语义残缺。它适合结构松散、句子独立性强的文本，比如日志、短评、FAQ 条目。

递归切片是目前最常用的默认方案。它按分隔符优先级逐层尝试：先按段落切，段落还太长就按句子切，句子还长就按字符切，直到每块落在目标长度内。这样能最大程度保留自然语义边界。LangChain 的RecursiveCharacterTextSplitter就是典型实现，中文场景需要把分隔符换成中文标点。

语义切片用 embedding 计算相邻句子的相似度，在相似度骤降处断开，理论上最贴合语义边界。但它要为每个句子算一次向量，成本和延迟都高，而且对短文档收益不明显。我的经验是：文档超过 50 页、且段落内部主题跳跃频繁时，语义切片才值得上。

2.2 块大小与重叠窗口的参数推导

块大小没有万能值，但有一个推导思路：先看你的查询平均长度，再看答案在原文中的平均跨度。如果用户问的是“XX 接口的超时参数怎么配”，答案通常集中在一两段内，块大小设在 256 到 512 token 比较合适；如果问的是“XX 系统的整体架构”，答案跨越多节，块大小要放到 800 到 1200 token，否则单块装不下完整论述。

重叠窗口的作用是防止边界信息丢失。经验值是块大小的 10% 到 20%。重叠太小，跨块的关键句仍会被切断；重叠太大，存储和检索成本上升，还会导致重复召回。我一般先用 15% 起步，再根据召回评估微调。

# 块大小与重叠的快速估算：基于文档平均段落长度 def estimate_chunk_size(docs, target_ratio=0.15): # 统计每篇文档的段落平均字符数 para_lens = [] for doc in docs: paras = [p for p in doc.split("\n") if p.strip()] para_lens.extend([len(p) for p in paras]) avg_para = sum(para_lens) / len(para_lens) # 块大小取段落均值的 2~3 倍，保证装下完整论述 chunk_size = int(avg_para * 2.5) overlap = int(chunk_size * target_ratio) return chunk_size, overlap

这段代码的逻辑是：段落平均长度反映了文档的自然语义单元大小，块大小取它的 2.5 倍，能容纳一个论点加支撑论据。target_ratio控制重叠比例，默认 0.15。注意这只是起点，最终值要靠召回评估确定，别把它当标准答案。

2.3 用递归切片器跑通第一版中文切片

中文递归切片的关键是分隔符顺序。英文用["\n\n", "\n", " ", ""]，中文要把句号、问号、感叹号、分号加进去，否则会在句子中间断开。

from langchain.text_splitter import RecursiveCharacterTextSplitter splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=75, length_function=len, separators=[ "\n\n", # 段落 "\n", # 换行 "。", "！", "？", # 中文句末 "；", # 中文分号 "，", # 中文逗号 " ", # 空格 "" # 兜底逐字切 ] ) chunks = splitter.split_text(long_text)

chunk_size=500是字符数，中文一个汉字算一个字符，500 字大约对应 350 到 400 token，适合中等粒度问答。chunk_overlap=75是 15% 重叠。separators的顺序决定切分优先级，越靠前越优先保留。这里把中文标点放在空格之前，是因为中文文本里空格少，若把空格提前会导致切分粒度失控。跑完这一步，你就有了第一版可检索的切片，接下来才是评估和调优。

3. 从源码落地一套可配置的切片管线

选型讲完，这一章把切片做成一条可配置、可替换、可评估的管线。核心思路是把“切分策略”抽象成接口，让固定、递归、语义三种实现可以互换，方便做 A/B 对比。

3.1 切片器的抽象接口设计

管线要解决三个问题：输入统一、策略可换、输出带元数据。元数据很重要，它记录了每块来自哪个文档、第几段、字符偏移，排查召回问题时全靠它定位。

from abc import ABC, abstractmethod from dataclasses import dataclass, field from typing import List @dataclass class Chunk: text: str doc_id: str chunk_index: int start_offset: int metadata: dict = field(default_factory=dict) class BaseSplitter(ABC): @abstractmethod def split(self, text: str, doc_id: str) -> List[Chunk]: pass def _build_chunks(self, pieces, doc_id): chunks, offset = [], 0 for i, piece in enumerate(pieces): chunks.append(Chunk( text=piece, doc_id=doc_id, chunk_index=i, start_offset=offset, metadata={"length": len(piece)} )) offset += len(piece) return chunks

Chunk用 dataclass 定义，字段固定，方便序列化进向量库。BaseSplitter强制子类实现split，_build_chunks负责统一编号和偏移计算。start_offset是字符级偏移，用于回溯原文；metadata留作扩展，比如塞入标题层级、页码。这套接口的好处是，后面加新策略不用改调用方。

3.2 递归切片器的完整实现

把 2.3 的思路封装成类，并补上分隔符逐层回退的逻辑。LangChain 已经实现了，但自己写一遍能看清边界处理。

class RecursiveSplitter(BaseSplitter): def __init__(self, chunk_size=500, chunk_overlap=75, separators=None): self.chunk_size = chunk_size self.chunk_overlap = chunk_overlap self.separators = separators or ["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""] def split(self, text, doc_id): pieces = self._recursive_split(text, self.separators) return self._build_chunks(pieces, doc_id) def _recursive_split(self, text, separators): if len(text) <= self.chunk_size: return [text] if text.strip() else [] sep = separators[0] rest = separators[1:] parts = text.split(sep) if sep else list(text) result, buffer = [], "" for part in parts: candidate = buffer + sep + part if buffer else part if len(candidate) <= self.chunk_size: buffer = candidate else: if buffer: result.append(buffer) # 单段仍超长，用下一级分隔符继续切 if len(part) > self.chunk_size and rest: result.extend(self._recursive_split(part, rest)) buffer = "" else: buffer = part if buffer: result.append(buffer) return result

_recursive_split是核心：先按当前分隔符切，逐段累加，超过chunk_size就落盘并开新缓冲。如果单段本身超长且还有下一级分隔符，递归下去继续切。separators末尾的空字符串是兜底，保证任何文本都能切完。注意这里没有实现重叠，重叠要在落盘后单独处理，否则递归逻辑会变复杂。生产环境建议直接用成熟库，自己写主要用于理解边界。

3.3 语义切片的相似度断点检测

语义切片的核心是找“语义断崖”。做法是把文本按句子切开，逐句算 embedding，相邻句子余弦相似度低于阈值就断开。

import numpy as np def semantic_split(sentences, embed_fn, threshold=0.6, max_len=800): if not sentences: return [] vectors = embed_fn(sentences) # 返回 shape=(n, dim) chunks, current = [], [sentences[0]] for i in range(1, len(sentences)): sim = float(np.dot(vectors[i-1], vectors[i]) / (np.linalg.norm(vectors[i-1]) * np.linalg.norm(vectors[i]) + 1e-8)) current_len = sum(len(s) for s in current) if sim < threshold or current_len + len(sentences[i]) > max_len: chunks.append("".join(current)) current = [sentences[i]] else: current.append(sentences[i]) if current: chunks.append("".join(current)) return chunks

threshold=0.6是断点阈值，低于它就认为话题切换。这个值要按语料调：技术文档句子间相似度普遍偏高，阈值可以设 0.5；口语化文本相似度低，设 0.7 更合适。max_len是硬上限，防止语义连贯但超长的段落撑爆块。embed_fn是外部传入的批量编码函数，方便替换模型。语义切片慢，建议离线跑一次缓存结果，别在请求链路里实时算。

4. 切片质量的评估与调参：别靠感觉，靠指标

切片做完不能凭感觉说“好像还行”。这一章给一套可量化的评估方法，让调参有依据。

4.1 用召回命中率定位切片问题

最直接的指标是：拿一批已知答案的问题，看正确答案所在块是否被召回。如果答案跨块，就说明块太小；如果召回的块里混了大量无关内容，就说明块太大。

def recall_hit_rate(questions, retriever, ground_truth): # questions: 问题列表 # ground_truth: 每个问题的答案关键句 hits = 0 for q, gt in zip(questions, ground_truth): docs = retriever.search(q, top_k=5) if any(gt in d.text for d in docs): hits += 1 return hits / len(questions)

top_k=5是常用召回深度，gt in d.text做的是关键句包含判断。这个指标低于 0.7 就说明切片或检索有问题。注意它只衡量“找得到”，不衡量“排得前”，所以还要配合 MRR 看排序质量。

4.2 块大小与重叠的网格搜索

与其手动试，不如小范围网格搜索。块大小取 256、512、768，重叠取 10%、15%、20%，跑九组对比召回命中率。

从这组模拟数据能看出，512 配 15% 是拐点，再大命中率反而降，因为噪声稀释了相似度。实际项目里要跑真实数据，但思路一样：先粗搜定位区间，再细调。

4.3 元数据过滤对切片召回的增益

切片时保留标题层级、页码、章节号，检索时就能做元数据过滤。比如用户问“第 3 章的接口定义”，可以先按章节号过滤再算相似度，召回精度明显提升。

def filtered_search(query, retriever, chapter=None, top_k=5): filters = {"chapter": chapter} if chapter else None return retriever.search(query, top_k=top_k, filters=filters)

filters是向量库支持的元数据过滤条件。关键在切片阶段就要把chapter写进metadata，否则检索时无从过滤。这一步的收益常被低估，实际上它比换 embedding 模型便宜得多，效果也直接。

5. 切片避坑清单：五条血泪经验

这一章全是踩过的坑，每条按现象、原因、解决写。看完能省你至少两周试错。

5.1 现象：召回块总是缺半句关键条件

原因：固定长度切片在句子中间断开，把“在 XX 条件下”切到了上一块。解决：改用递归切片，把中文句末标点加入分隔符，并保证块大小不低于 256 字符。如果必须用固定切片，重叠比例提到 20% 以上。

5.2 现象：同一段内容被召回多次，答案重复

原因：重叠窗口过大，相邻块内容高度重合，向量相似度都高。解决：重叠降到 10% 到 15%，并在入库前做去重，按文本哈希过滤。去重放在切片后、入库前，别放在检索后。

5.3 现象：表格和代码块被切得支离破碎

原因：递归切片按标点切，表格的行、代码的语句被当成普通文本。解决：切片前先做结构识别，把表格和代码块整体保留，不参与递归切分。常见做法是用正则或解析器标记这些区域，切片时跳过。

5.4 现象：语义切片跑得慢，还切出很多超短块

原因：相似度阈值设太高，句子间稍有波动就断开。解决：阈值下调 0.1 到 0.15，并加最小块长度限制，低于 100 字符的块合并到相邻块。语义切片适合离线批处理，别放实时链路。

5.5 现象：换了 embedding 模型后召回反而变差

原因：新模型的训练语料和你的切片粒度不匹配，块太长超出它的有效上下文。解决：查模型的最大输入长度，把块大小压到它的 70% 以内。换模型和调切片要一起做，别只换一个。

6. 进阶：把切片策略和检索目标对齐的一个技巧

最后讲一个我常用的技巧：反向切片。大多数人是先切好再检索，反向切片是先看查询长什么样，再决定怎么切。具体做法是，从真实查询日志里抽样，统计问题的平均长度和答案跨度，然后让切片粒度去匹配这个分布。如果查询短、答案集中，就切小块；如果查询长、答案分散，就切大块并保留更多上下文。

def align_chunk_to_query(queries, answers, base_size=512): # 统计答案在原文中的平均跨度 spans = [len(a) for a in answers] avg_span = sum(spans) / len(spans) # 块大小取答案跨度的 1.5 倍，保证装下完整答案 aligned = int(avg_span * 1.5) # 限制在合理区间，避免极端值 return max(256, min(aligned, 1200))

avg_span是答案平均字符数，乘 1.5 留出上下文余量，再用max和min夹到 256 到 1200 的安全区间。这个函数的输入来自你的真实业务数据，不是拍脑袋。我一般每季度重跑一次，因为查询分布会随业务变化漂移。

验证方法也简单：用对齐前后的切片各跑一遍召回命中率，提升超过 5 个百分点就保留。别小看这几个点，在 RAG 链路里，召回每提升一点，最终答案质量的提升是指数级的。

我自己的习惯是，每次上线新切片策略前，先在一个小流量桶里跑一周，对比召回指标和人工抽检结果，确认没有翻车再全量。切片这东西没有后悔药，切错了重建向量库的成本很高，宁可前期多花两天调参。希望帮到你。

本文还有配套的精品资源，点击获取