为什么分块策略决定RAG效果
RAG（检索增强生成）的核心流程是：文档分块 -> 向量化 -> 检索 -> 注入Prompt -> 大模型生成。其中分块策略是影响效果的第一道关卡。
很多团队RAG效果不好，不是因为模型不行，而是分块太粗暴——按固定字数切分，把一个完整的段落从中间截断，导致检索到的片段缺少上下文，模型无法正确理解。我们在上海的RAG项目实践中反复验证了这一点。
三种分块策略对比
1. 固定长度分块（不推荐）
按固定字数（如500字）切分，简单但效果差。问题：段落被从中间截断，表格和列表被打散。
2. 语义分块（推荐基础用法）
按自然段落、标题、列表项等语义边界切分。保留完整语义单元。
- Markdown文档：按#标题层级分块
- PDF文档：按段落+页面分块
- 代码：按函数/类分块
3. 递归分块（推荐进阶用法）
先按大语义单元（章节）分块，如果块太大再按小单元（段落）细分。配合overlap（重叠）保证上下文连续性。推荐参数：chunk_size=512，overlap=64。
检索优化三板斧
第一斧：混合检索
纯向量检索擅长语义匹配，但精确关键词匹配不如BM25。两者结合效果最好：
- 向量检索：召回语义相关的内容
- BM25检索：召回关键词精确匹配的内容
- RRF（Reciprocal Rank Fusion）：融合两路结果
第二斧：元数据过滤
给每个分块打元数据标签（部门、时间、文档类型、作者），检索时先过滤再相似度排序。大幅减少噪音，提升精确度。
第三斧：Reranker重排
向量检索速度快但精度有限。用bge-reranker-v2对top-20结果二次排序，精选最相关的top-5。准确率提升15-30%。
实战调优建议
- 先看Bad Case：收集回答错误的案例，分析是分块问题还是检索问题
- 分块大小：中文建议256-512字，英文建议512-1024 tokens
- Overlap：建议chunk_size的10-15%
- Embedding模型：中文推荐bge-large-zh-v1.5，英文推荐text-embedding-3-large
- top-k：检索召回20条，Reranker后取5条注入Prompt
Bad Case分析方法
当RAG回答错误时，按以下流程排查：
- 检查检索结果是否包含正确答案的文档块——如果没检索到，是分块或检索问题
- 如果检索到了但回答错误——是Prompt设计或模型理解问题
- 如果答案正确但缺少关键细节——是分块太小，上下文不完整
常见问题
RAG和微调大模型有什么区别？
RAG是检索时注入知识，不需要改模型，知识可实时更新。微调是把知识固化到模型参数中，更新需要重新训练。90%的企业场景用RAG即可，微调适合需要改变模型行为（如回答风格）的场景。
RAG支持实时更新吗？
支持。新增文档只需向量化并插入向量数据库，不需要重建整个库。增量更新延迟<5秒。
中英文混合文档怎么处理？
使用bge-large-zh-v1.5等多语言Embedding模型，中英文混合文档分块后向量化效果良好。不需要先翻译再分块。