夜雨聆风同一段文档，不同分片策略的检索结果天差地别
先看一个真实案例。下面是一段公司制度文档：
原文：
"员工年假管理细则。第一条：年假天数根据工龄计算，工龄1-10年每年5天，10-20年
每年10天，20年以上每年15天。第二条：年假申请需提前3个工作日，通过OA系统提交
申请，经部门经理审批后生效。第三条：年假可分段使用，每次最少半天。第四条：年
假有效期至当年12月31日，过期作废，不可累积至下一年度。"
用户提问："我工龄8年，年假有几天？"
现在用三种分片策略处理这段文档，看看检索结果：
分片策略A：固定200字，无重叠
分片1："员工年假管理细则。第一条：年假天数根据工龄计算，工龄1-10年每年5天，"
分片2："10-20年每年10天，20年以上每年15天。第二条：年假申请需提前3个工作日，"
分片3："通过OA系统提交申请，经部门经理审批后生效。第三条：年假可分段使用，"
检索结果：匹配到分片1，相似度0.72。但分片1只包含"工龄1-10年每年5天"，关键的"10-20年每年10天"被切到了分片2。如果TopK=1，用户只能看到半条规则。
分片策略B：固定500字，无重叠
分片1："员工年假管理细则。第一条...第二条...第三条：年假可分段使用，每次最少半天。"
分片2："第四条：年假有效期至当年12月31日，过期作废，不可累积至下一年度。"
检索结果：匹配到分片1，相似度0.58。分片包含了所有相关信息，但也混入了"申请流程""分段使用"等无关内容，向量被稀释了，相似度反而下降。
分片策略C：递归分片300字，重叠50字
分片1："员工年假管理细则。第一条：年假天数根据工龄计算，工龄1-10年每年5天，10-20年
每年10天，20年以上每年15天。"
分片2："10-20年每年10天，20年以上每年15天。第二条：年假申请需提前3个工作日，通过OA
系统提交申请，经部门经理审批后生效。"
分片3："通过OA系统提交申请，经部门经理审批后生效。第三条：年假可分段使用，每次最少
半天。第四条：年假有效期至当年12月31日，过期作废。"
检索结果：匹配到分片1，相似度0.85。分片1包含了完整的第一条规则，没有无关内容，也没有被切断。这就是理想的分片效果。
三种策略的对比一目了然：分片不是越细越好，也不是越粗越好，而是要在"语义完整性"和"信息密度"之间找到平衡。
分片策略深度对比
1. 固定长度分片
// 最简单粗暴：按字符数切
DocumentSplitter splitter = DocumentSplitters.recursive(500, 0);
优点：实现简单，分片均匀，容易控制Token数量。
缺点：句子被切断，语义不完整。比如"1. 入职满一年 2. 提前三天申请"可能被切成"1. 入职满"和"一年 2. 提前三天申请"。
适用场景：文本结构简单、没有层级关系的文档（如新闻、博客）。
2. 按段落分片
// 按段落边界切，保证每个分片是完整的段落
DocumentSplitter splitter = DocumentSplitters.recursive(1000, 0);
// 注意：LangChain4j的recursive分片器会优先按段落边界切
优点：语义完整，不会切断段落。
缺点：段落长度不可控，有的段落200字，有的2000字，导致分片大小不均匀，检索精度不稳定。
适用场景：结构清晰的文档（如制度文件、法律法规）。
3. 按句子分片
// 按句子边界切，保证每个分片是完整的句子
DocumentSplitter splitter = DocumentSplitters.recursive(300, 0);
优点：粒度细，检索精度高。
缺点：单个句子可能缺乏上下文，比如"费用为100元"单独拿出来，不知道是什么费用。
适用场景：FAQ、问答对、知识卡片。
4. 语义分片
// 高级方案：基于Embedding相似度判断语义边界
publicclassSemanticSplitter{
privatefinal EmbeddingModel embeddingModel;
privatefinaldouble similarityThreshold;
/**
* 语义分片：当相邻句子的语义相似度低于阈值时，认为是一个主题边界
*/
public List<String> split(String text){
String[] sentences = text.split("(?<=[。！？])");
List<String> chunks = new ArrayList<>();
StringBuilder currentChunk = new StringBuilder();
for (int i = 0; i < sentences.length; i++) {
currentChunk.append(sentences[i]);
if (i < sentences.length - 1) {
// 计算当前句子和下一句的语义相似度
float[] currentVec = embeddingModel.embed(sentences[i]).vector();
float[] nextVec = embeddingModel.embed(sentences[i + 1]).vector();
double similarity = cosineSimilarity(currentVec, nextVec);
if (similarity < similarityThreshold) {
// 语义突变，开始新的分片
chunks.add(currentChunk.toString().trim());
currentChunk = new StringBuilder();
}
}
}
// 最后一个分片
if (currentChunk.length() > 0) {
chunks.add(currentChunk.toString().trim());
}
return chunks;
}
}
优点：按语义边界切分，最接近人类理解文档的方式。
缺点：每次调用Embedding模型，性能开销大，不适合实时处理。
适用场景：长文档、混合主题的文档。
5. 递归分片（推荐）
// LangChain4j的默认策略：先按段落，段落太大按句子，句子太大按字符
DocumentSplitter splitter = DocumentSplitters.recursive(500, 100);
原理：先用\n\n（段落）切，如果段落超过500字，再用。！？（句子）切，如果句子还超过500字，再用字符切。这就是"递归"的含义——逐级降级切分。
优点：兼顾语义完整性和大小控制，是生产环境最常用的策略。
分片大小对检索精度的影响
我用同一份企业文档（约5万字），测试了不同chunkSize下的检索精度：
publicclassChunkSizeBenchmark{
publicstaticvoidmain(String[] args){
int[] chunkSizes = {200, 300, 500, 800, 1000, 2000};
String[] testQuestions = {
"年假有几天？",
"加班费怎么算？",
"报销流程是什么？",
"离职需要提前多久通知？",
"公司有哪些福利？"
};
for (int size : chunkSizes) {
DocumentSplitter splitter = DocumentSplitters.recursive(size, size / 5);
// 分片、索引、检索...
double avgScore = evaluateRetrieval(splitter, testQuestions);
System.out.printf("chunkSize=%d, 平均相似度=%.3f\n", size, avgScore);
}
}
}
典型测试结果：
结论：对于中文文档，300-500字的chunkSize是最优区间。太小切碎信息，太大引入噪声。
重叠窗口（Overlap）的作用
Overlap是分片策略里最容易被忽略但影响巨大的参数：
// 没有Overlap：关键信息可能在分片边界被切断
DocumentSplitter noOverlap = DocumentSplitters.recursive(500, 0);
// 有Overlap：相邻分片有重叠，保证边界信息不丢失
DocumentSplitter withOverlap = DocumentSplitters.recursive(500, 100);
实际效果对比：
原文："...第十条：加班费计算标准为：工作日加班1.5倍工资，休息日加班2倍工资，
法定节假日加班3倍工资。第十一条：..."
分片1（无重叠）："...第十条：加班费计算标准为：工作日加班1.5倍工资，休息日"
分片2（无重叠）："加班2倍工资，法定节假日加班3倍工资。第十一条：..."
分片1（有重叠）："...第十条：加班费计算标准为：工作日加班1.5倍工资，休息日加班2倍工资"
分片2（有重叠）："休息日加班2倍工资，法定节假日加班3倍工资。第十一条：..."
用户问"休息日加班怎么算"，无重叠时两个分片各包含一半信息，有重叠时分片1就包含了完整信息。
Overlap大小建议：chunkSize的10%-20%。比如chunkSize=500，overlap=50-100。
向量相似度算法对比
三种常用相似度算法，选错的话检索结果会差很多：
余弦相似度（Cosine Similarity）
publicstaticdoublecosineSimilarity(float[] a, float[] b){
double dotProduct = 0.0;
double normA = 0.0;
double normB = 0.0;
for (int i = 0; i < a.length; i++) {
dotProduct += a[i] * b[i];
normA += a[i] * a[i];
normB += b[i] * b[i];
}
return dotProduct / (Math.sqrt(normA) * Math.sqrt(normB));
}
特点：只关心向量的"方向"，不关心"长度"。两个向量指向同一方向 = 相似度1，正交 = 0，相反 = -1。
适用场景：文本检索（推荐），因为文本Embedding的语义主要取决于方向，文本长度不影响相似度。
欧氏距离（Euclidean Distance）
publicstaticdoubleeuclideanDistance(float[] a, float[] b){
double sum = 0.0;
for (int i = 0; i < a.length; i++) {
double diff = a[i] - b[i];
sum += diff * diff;
}
return Math.sqrt(sum);
}
特点：计算两个向量在空间中的直线距离，受向量长度影响大。
适用场景：图像检索（图片特征向量的长度有意义），不推荐文本检索。
点积（Dot Product / Inner Product）
publicstaticdoubledotProduct(float[] a, float[] b){
double sum = 0.0;
for (int i = 0; i < a.length; i++) {
sum += a[i] * b[i];
}
return sum;
}
特点：两个向量长度越长、方向越接近，点积越大。
适用场景：推荐系统（用户向量和物品向量的匹配），适用于已归一化的向量。
实战对比
// 测试代码：同一对文本，三种算法的表现
String query = "年假怎么申请？";
String doc1 = "年假申请需要提前3天通过OA系统提交"; // 相关
String doc2 = "年假天数根据工龄计算"; // 部分相关
String doc3 = "加班餐补标准为每人30元"; // 不相关
float[] queryVec = embeddingModel.embed(query).vector();
float[] doc1Vec = embeddingModel.embed(doc1).vector();
float[] doc2Vec = embeddingModel.embed(doc2).vector();
float[] doc3Vec = embeddingModel.embed(doc3).vector();
System.out.println("余弦相似度: doc1=" + cosineSimilarity(queryVec, doc1Vec)
+ ", doc2=" + cosineSimilarity(queryVec, doc2Vec)
+ ", doc3=" + cosineSimilarity(queryVec, doc3Vec));
// 输出: doc1=0.89, doc2=0.72, doc3=0.35 → 区分度好
System.out.println("欧氏距离: doc1=" + euclideanDistance(queryVec, doc1Vec)
+ ", doc2=" + euclideanDistance(queryVec, doc2Vec)
+ ", doc3=" + euclideanDistance(queryVec, doc3Vec));
// 输出: doc1=0.47, doc2=0.75, doc3=1.12 → 区分度差
结论：文本检索统一用余弦相似度，别纠结。
检索TopK的调优
K太小：漏掉关键信息
// 用户问"年假怎么申请，能休几天？"
// 这个问题包含两个子问题：申请流程 + 天数计算
// TopK=1：只返回"申请流程"的分片，漏掉了"天数计算"
// 大模型回答："年假申请需要提前3天通过OA系统提交"（只回答了流程，没说天数）
// TopK=3：返回了"申请流程"、"天数计算"、"加班规定"三个分片
// 大模型有完整信息，能同时回答流程和天数
K太大：引入噪声
// 用户问"年假怎么申请？"
// TopK=10：返回了10个分片，包括"加班规定"、"报销流程"、"离职手续"等
// 大模型被噪声干扰，可能把加班规定混入年假回答中
动态TopK策略
publicclassDynamicTopK{
/**
* 根据问题复杂度动态调整TopK
*/
publicstaticintcompute(String question, int contextWindow, int avgChunkTokens){
// 1. 基础TopK：预留50%上下文空间
int availableTokens = (int)(contextWindow * 0.5);
int baseTopK = availableTokens / avgChunkTokens;
// 2. 问题复杂度调整
if (question.contains("和") || question.contains("以及") || question.contains("还有")) {
// 多子问题，增加TopK
baseTopK = (int)(baseTopK * 1.5);
}
if (question.contains("详细") || question.contains("完整") || question.contains("全部")) {
// 要求详细回答，增加TopK
baseTopK = (int)(baseTopK * 2.0);
}
// 3. 限制范围
return Math.max(1, Math.min(baseTopK, 10));
}
}
// 使用示例
int topK = DynamicTopK.compute(question, 8192, 500);
// 问题"年假怎么申请？" → topK = 3
// 问题"年假和加班的规定" → topK = 5
// 问题"详细说明公司所有福利政策" → topK = 8
重排序（ReRanking）：让检索结果更精准
向量检索的TopK结果是粗筛，再经过一次ReRanking可以让精度提升10-20%：
@Component
publicclassReRankingService{
privatefinal ChatLanguageModel chatModel;
/**
* 用大模型对检索结果进行二次排序
* 原理：让大模型判断每个分片与问题的相关性，给出0-10分
*/
public List<SearchResult> rerank(String question, List<SearchResult> candidates){
if (candidates.size() <= 3) {
return candidates; // 候选太少，不需要重排
}
// 构建ReRanking Prompt
StringBuilder prompt = new StringBuilder();
prompt.append("请对以下文档片段与问题的相关性打分（0-10分），只返回JSON数组。\n\n");
prompt.append("问题：").append(question).append("\n\n");
for (int i = 0; i < candidates.size(); i++) {
prompt.append("文档").append(i).append("：")
.append(candidates.get(i).getContent()).append("\n\n");
}
prompt.append("请返回JSON格式：[{\"index\":0,\"score\":9},{\"index\":1,\"score\":5},...]");
String response = chatModel.call(prompt.toString());
// 解析评分
List<ScoreResult> scores = parseScores(response);
// 按评分重新排序，取Top3
return scores.stream()
.sorted((a, b) -> Integer.compare(b.getScore(), a.getScore()))
.limit(3)
.map(s -> candidates.get(s.getIndex()))
.toList();
}
}
注意：ReRanking会额外调用一次大模型，增加延迟和成本。如果检索结果本身质量不错（Top1相似度>0.8），可以跳过ReRanking。
故障复现
故障1：检索结果和问题完全无关
排查步骤：
// 1. 打印检索结果和相似度
List<SearchResult> results = search(question, 10);
for (SearchResult r : results) {
System.out.printf("相似度: %.3f, 内容: %s\n", r.getScore(), r.getContent());
}
// 2. 如果所有相似度都低于0.5，检查：
// - Embedding模型是否匹配语言（中文文档用英文模型？）
// - 文档内容是否被正确解析（PDF乱码？）
// - 分片是否太大（1000字以上？）
// 3. 如果一些结果相似度很高但内容不相关，检查：
// - 文档中是否有大量重复内容
// - 是否有元数据污染（如页码、页眉页脚混入文本）
故障2：检索结果重复
// 原因：Overlap设太大，相邻分片内容高度重叠
// 结果：Top3返回的三条结果，内容几乎一样
// 解决方案：检索结果去重
public List<SearchResult> deduplicate(List<SearchResult> results){
Set<String> seen = new HashSet<>();
List<SearchResult> unique = new ArrayList<>();
for (SearchResult r : results) {
// 用内容的前100字做指纹
String fingerprint = r.getContent().substring(0,
Math.min(100, r.getContent().length()));
if (seen.add(fingerprint)) {
unique.add(r);
}
}
return unique;
}
隐性坑点
坑1：Embedding模型的维度
不同Embedding模型的向量维度不同，切换模型时必须重建向量库：
// 如果从384维换到1024维，必须重建索引
// 否则Milvus会报错：dimension mismatch
// 错误信息：vector dimension 1024 does not match collection dimension 384
坑2：不同语言对分片的影响
中文和英文的分片策略完全不同：
// 中文：1个汉字≈1个语义单位，300字足够表达一个完整意思
DocumentSplitter zhSplitter = DocumentSplitters.recursive(300, 50);
// 英文：1个单词≈1个语义单位，500 tokens更合适
DocumentSplitter enSplitter = DocumentSplitters.recursive(500, 100);
// 中英混合文档：按段落分，保持语义完整性
DocumentSplitter mixedSplitter = DocumentSplitters.recursive(800, 150);
坑3：分片策略固化后难以调整
分片策略一旦确定，修改意味着重建整个向量库。建议在项目初期多做实验，用A/B测试验证效果：
@Component
publicclassChunkStrategyEvaluator{
/**
* 评估不同分片策略的检索效果
*/
public Map<String, Double> evaluate(List<DocumentSplitter> strategies,
List<QuestionAnswerPair> testSet){
Map<String, Double> scores = new LinkedHashMap<>();
for (DocumentSplitter strategy : strategies) {
double totalScore = 0;
for (QuestionAnswerPair pair : testSet) {
// 用该策略分片、索引、检索
List<SearchResult> results = searchWithStrategy(strategy, pair.question());
// 检查答案是否在检索结果中
double score = calculateHitRate(results, pair.answer());
totalScore += score;
}
scores.put(strategy.toString(), totalScore / testSet.size());
}
return scores;
}
}
RAG的核心不是大模型，是检索——检索质量决定了最终答案质量。分片策略、相似度算法、TopK、ReRanking，这四个环节任何一个出问题，大模型再强也白搭。