企业官网建设流程全解析

简介：这份源码资源面向正在搭建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_size=500, overlap=50): # 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_size=500, chunk_overlap=80, # 分隔符顺序决定降级策略，中文场景要把中文标点加进去 separators=["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""], length_function=len, ) 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_size=800): # 按标题层级切分，保留标题作为上下文前缀 sections = re.split(r'(?=^#{1,3}\s)', markdown_text, flags=re.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, threshold=0.75): embs = model.encode(sentences, normalize_embeddings=True) 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 chunks

threshold是最难调的参数，中文技术文档我一般从 0.7 到 0.8 之间试。阈值太高，切片过碎；太低，等于没切。语义切片的成本在于每个句子都要过一次 embedding，长文档处理慢，而且断点位置不稳定，同一份文档两次跑可能结果略有差异。它适合对召回精度要求极高、文档量不大的场景，比如法律条款、医疗指南。

四种方案的选型可以对照下表：

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_tokens=500): valid = [] for c in chunks: ids = tokenizer.encode(c, add_special_tokens=False) if len(ids) > max_tokens: # 超长切片按 token 边界二次切 for i in range(0, len(ids), max_tokens): valid.append(tokenizer.decode(ids[i:i+max_tokens])) else: valid.append(c) return valid

max_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 records

title_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_k=5): hit, total = 0, 0 for q in questions: results = retriever.search(q["query"], top_k=top_k) total += 1 # 命中判定：检索结果里是否包含答案所在片段的关键句 for r in results: if q["answer_key"] in r["text"]: hit += 1 break return hit / total if total else 0.0

answer_key是答案片段里的一个特征字符串，用它判断检索是否命中。这个脚本跑下来，命中率低于 80% 就说明切片或检索参数有问题。测试集不用多，30 到 50 条覆盖各类问题就够，关键是要包含跨 chunk 的问题，专门验证 overlap 和相邻扩展是否生效。

除了命中率，我还会看两个分布指标：切片长度分布和切片数量。长度分布应该集中在目标区间，出现大量超短或超长切片就是参数没调好；切片数量突然比预期多很多，往往是分隔符配置有问题，把不该切的地方切了。

调参的顺序建议是：先定切片方案，再调 chunk_size 和 overlap，最后用测试集验证。不要一上来就同时改多个参数，那样出了问题根本不知道是哪个引起的。我自己的习惯是每次只动一个参数，跑一遍测试集记录命中率，找到拐点再动下一个。切片这件事没有一劳永逸的最优解，文档变了、问题类型变了，参数就得重新看。把这套验证脚本留着，每次知识库更新后跑一遍，比事后拍脑袋强得多。希望帮到你。

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