RAG 不是把文档切块就完事:父子分片、句子切割与动态重叠

一、"切块"是 RAG 最容易被做错的一步

很多人以为 RAG（检索增强生成）就是"把文档按 500 字一刀切，向量化，存库，查的时候捞几块喂给大模型"。我一开始也这么干，然后被打脸了：

• 按字符数硬切，经常把一句完整的中文从中间劈开——"用户需要在系统设置中"和"开启双因素认证"被切成两片，检索时各打五折，命中率直接拉胯；
• 块切太小，检索是准了，但喂给模型的上下文支离破碎，答非所问；
• 块切太大，上下文是完整了，可向量把一整页揉成一个点，语义被平均掉，检索又不准。

这本质是个两难：检索要"细"，生成要"整"。我最终的方案是业界经典的 父子分片（Parent-Child Chunking），再叠加"句子为基本单位"和"动态重叠（overlap）"两个细节。下面把工程里这套完整设计拆开讲。

二、核心：父子分片，检索用子、生成用父

我用两张表，把"细"和"整"分开存：

• 子分片 rag_child_chunk：细粒度（默认 childSize = 200 字），带向量 embedding，用来做向量 / 全文检索——要的是"准"。
• 父分片 rag_parent_chunk：大粒度（默认 parentSize = 800 字），存完整上下文，检索命中后展开，喂给大模型——要的是"全"。

两者靠 parent_chunk_id 关联。检索链路是：在子分片层算相似度，命中后顺着 parent_chunk_id 把整段父分片捞出来给模型。这样既不丢精度、也不丢上下文。

-- 子分片：细粒度向量化 + 与父分片关联CREATETABLE rag_child_chunk (    chunk_id        TEXT NOTNULLUNIQUE,    parent_chunk_id TEXT NOTNULL,          -- 指回父分片    document_id     TEXT NOTNULL,    content         TEXT NOTNULL,    embedding       vector(1024) NOTNULL-- PGvector，维度 1024);-- 向量用 HNSW 余弦索引，全文用 ParadeDB 的 BM25 索引CREATE INDEX idx_rag_child_chunk_embedding ON rag_child_chunk USING hnsw (embedding vector_cosine_ops);CREATE INDEX idx_rag_child_chunk_content_bm25 ON rag_child_chunk USING bm25 (content) WITH (text_config='schema_hushi.chinese_zh');-- 父分片：大粒度，存完整上下文，只挂 BM25（不参与向量检索）CREATETABLE rag_parent_chunk (    chunk_id    TEXT NOTNULLUNIQUE,    document_id TEXT NOTNULL,    content     TEXT NOTNULL);CREATE INDEX idx_rag_parent_chunk_content_bm25 ON rag_parent_chunk USING bm25 (content) WITH (text_config='schema_hushi.chinese_zh');

ℹ️ 向量和全文检索都跑在 PostgreSQL 里（PGvector + ParadeDB 的 BM25），不用再搭一套 Elasticsearch——运维成本直接少一半。

三、以"句子"为基本切割单位，绝不劈句

无论父分片还是子分片，底层单位都是完整的句子，不是字符。先按中文句末标点切句：

// 中文句子切分（。！？；\n）public List<String> sentenceSplit(String text) {    List<String> list = newArrayList<>();intstart=0;for (inti=0; i < text.length(); i++) {charc= text.charAt(i);if (c == '。' || c == '！' || c == '？' || c == '；' || c == '\n') {Stringsentence= text.substring(start, i + 1).strip();if (!sentence.isEmpty())                list.add(c == '\n' ? sentence + "。" : sentence); // \n 归一化成句号            start = i + 1;        }    }if (start < text.length()) list.add(text.substring(start)); // 结尾残句也收进来return list;}

然后父 / 子分片都是"若干完整句子的组合"——按 parentSize / childSize 逐个把句子累加进去，加到下一句会超阈值就收口成一片：

// 父分片：按 parentSize 累积句子public List<List<String>> parentSentence(List<String> sentences) {    List<List<String>> result = newArrayList<>();intstart=0;while (start < sentences.size()) {        List<String> parent = newArrayList<>();inti= start, size = 0;while (i < sentences.size()                && size + sentences.get(i).length() <= valueUtil.getRag().chunkConfig().parentSize()) {            parent.add(sentences.get(i));            size += sentences.get(i).length();            i++;        }if (i == start) {                 // 极端：单句就超父分片，整句保留            parent.add(sentences.get(start));            start++;        } else start = i;        result.add(parent);    }return result;}

⚠️ 注意那个 if (i == start) 兜底：万一有一句比 parentSize 还长（比如一整段没标点的法律条文），宁整句保留也不硬劈——语义完整性优先。

四、动态重叠（overlap）：重叠大小随文档自适应

固定 overlap（比如永远重叠 50 字）有个问题：长文档句子普遍长，50 字可能只重叠半句，断点照样难看；短文档句子短，又白白重复一堆。

我的做法里，overlap 是算出来的、随文档自适应的：

public Pair<List<RagParentChunk>, List<RagChildChunk>> chunk(String text, String documentId) {    List<String> sentences = sentenceSplit(text);intoverlap= text.length() / sentences.size();   // ← 全文平均句长，作为动态 overlap// ……对每个父分片的句子列表，用这个 overlap 去切子分片}

overlap = 全文长度 / 句子数 = 平均句长。平均句越长，重叠区越大；平均句越短，重叠区越小——天然跟着文档节奏走。

子分片切割时，重叠是否触发还有一个巧思：上一句足够短才重叠。

// 子分片：按 childSize 累积极句子，动态重叠public List<String> childSentences(List<String> parentSentences, int overlap) {    List<String> result = newArrayList<>();intstart=0;while (start < parentSentences.size()) {StringBuildersb=newStringBuilder();inti= start;while (i < parentSentences.size()                && sb.length() + parentSentences.get(i).length() <= valueUtil.getRag().chunkConfig().childSize()) {            sb.append(parentSentences.get(i));            i++;        }if (i == start) {                 // 单句超 childSize，整句保留            sb.append(parentSentences.get(start));            start++;        } else {// 只有上一句足够短（≤ 平均句长 overlap），才让下一片回退一句重叠，避免冗余if (i < parentSentences.size() && overlap > 0 && parentSentences.get(i - 1).length() <= overlap) {                start = i - 1;            // 回退一格 → 当前片与下一片重叠一句            } else {                start = i;            }        }        result.add(sb.toString());    }return result;}

ℹ️ 这段的核心判断 parentSentences.get(i - 1).length() <= overlap：如果"刚切完的那句"本身就比平均句长还长，说明它是个超长句，重叠它会把一大段重复塞进两片，纯属浪费 token，所以不重叠、直接 start = i。只有"短句"才值得拿来当过渡重叠。这就是"动态"二字的落地——重叠不是无脑加，而是看上一句的长度决定加不加。

五、入库流水线：从一份文件到一堆向量

切片逻辑清楚了，再看"文档怎么进库"。入口是 RagService.split(file)，链条是：

publicvoidsplit(MultipartFile file) {// 1. Tika 抽文本 + 元数据（自动识别 pdf/word/markdown…）// 2. 落临时文件 → 上传 MinIO 存原件（object_name = rag/yyyy/mm/dd/uuid.ext）// 3. getRagDocument：解析元数据 + 调切片// 4. fillEmbedding：批量调 embedding 模型，给每个子分片填向量// 5. 落库：元数据表 + 父分片表 + 子分片表}

其中切片和向量化：

varpair= chineseDocSplitter.chunk(parseResult.content(), documentMeta.getDocumentId());this.fillEmbedding(pair.getRight());   // 给子分片（不是父分片）填向量// …… 返回 RagDocument(元数据, 父分片列表, 子分片列表)

向量化是批量调用（每批 10 条），省 embedding API 往返：

publicvoidfillEmbedding(List<RagChildChunk> chunks) {intbatch=10;for (inti=0; i < chunks.size(); i += batch) {varsub= chunks.subList(i, Math.min(i + batch, chunks.size()));        List<float[]> embeddings = embedding(sub.stream().map(RagChildChunk::getContent).toList());for (intj=0; j < embeddings.size(); j++)            sub.get(j).setEmbedding(newPGvector(embeddings.get(j)));    }}

⚠️ 只给子分片向量化，父分片不存向量——父分片是"生成用"的，不参与检索，省了整整一半的 embedding 开销。

ℹ️ embedding(...) 底层走的是上篇讲过的 EmbeddingModelENum 枚举策略（NVIDIA / Ollama 各自一套请求构建），这里无缝复用，不多写一行。

六、检索流水线：混合检索 + RRF 融合 + Rerank

问答时 ragContext(question) 干的事，是整个 RAG 的"精排大脑"：

public List<String> ragContext(String question) {// 1. 问题向量化    List<float[]> qe = embedding(List.of(question));// 2. 向量检索：HNSW 余弦最近邻    List<RagChildChunk> vectorChunks = ragChildChunkDao            .selectByEmbedding(qe.getFirst(), topN);            // ORDER BY embedding <=> ? LIMIT topN// 3. 全文检索：ParadeDB BM25    List<RagChildChunk> ftsChunks = ragChildChunkDao            .selectByContent(question, topN);                   // ORDER BY content <@> to_bm25query(?) LIMIT topN// 4. RRF 加权融合    Map<String, Double> rrf = newLinkedHashMap<>();for (inti=0; i < vectorChunks.size(); i++)        rrf.merge(vectorChunks.get(i).getChunkId(),                vectorWeight / (60 + i + 1), Double::sum);       // 向量权重 70for (inti=0; i < ftsChunks.size(); i++)        rrf.merge(ftsChunks.get(i).getChunkId(),                ftsWeight / (60 + i + 1), Double::sum);          // 全文权重 30// 5. 子分片 → 父分片：取命中的父分片，去重，limit topN// 6. Rerank 模型精排：对父分片内容重排    List<Integer> rerankIdx = rerank(question, sortedContents);return rerankIdx.stream().map(sortedContents::get).toList();}

几个设计要点拆开说：

① 混合检索：向量检索擅长"语义相似"（"怎么改密码"能命中"重置登录凭证"），但对专有名词、型号、错别字很钝；BM25 全文检索正好补这块短板。两条路各取 topN 再融合，召回更稳。

② 加权 RRF 融合：经典的 Reciprocal Rank Fusion 是 score += 1/(k+rank)（k=60 防止除零）。我给向量和全文各乘权重（向量 70、全文 30），重要性可调——你要更信语义就调高 vector-weight，要更信关键词就调高 fts-weight，全是 yaml 配置：

config:rag:top-n:5vector-weight:70fts-weight:30chunk-config:parent-size:800child-size:200

③ 子→父展开：融合打分是在子分片上做的（子分片有向量和全文索引），但最终返回给模型的是父分片内容——再次印证"检索用子、生成用父"。

④ Rerank 二次精排：向量 + 全文 + RRF 是"粗排"，只负责把可能相关的捞出来；再调一个 rerank 模型做"精排"，把最该进 prompt 的父分片顶到最前面。这一步对最终回答质量提升非常明显。

七、设计要点一览（可以直接抄）

一句话收尾：RAG 的"切块"绝不是按字数一刀切。把"检索要细、生成要整"拆给父子分片，把"切哪"交给完整句子，把"重叠多少"交给文档自己算——这套组合下来，召回和回答质量都稳了。

你做 RAG 时是被"切块"坑过，还是直接上了某家托管方案？留言聊聊你踩过的坑，我每条都看。

如果这篇对你有启发，点个关注。