分块大小如何影响 RAG 召回率与延迟

在构建基于检索增强生成（RAG）的系统时，分块策略是影响系统性能的关键因素之一。客户反馈 DeepSeek-RAG 服务在医疗报告问答场景出现 42% 的漏召回问题，经过日志分析发现，80% 的查询涉及 3000+ tokens 的长文档。这表明默认的 512-token 固定分块策略存在明显不足，具体表现为以下三个维度：

1. 过小分块：当文档被过度切碎时，跨页表格的完整性会遭到破坏，导致关键临床指标丢失。实测数据显示，这会使召回率下降 28%，尤其在实验室检查结果解读场景中，数值变化的连续性被切断后，模型无法正确理解指标演变趋势。例如血常规报告中白细胞计数与中性粒细胞比例的关联性分析会失效。

2. 过大分块：虽然增大分块能保留更多上下文，但会引发两个问题：一是 BERT 重排阶段的延迟显著劣化（P99 延迟从 1.2s 飙升至 4.7s），二是 GPU 显存占用增加约 40%。在并发请求场景下，显存不足会导致服务降级甚至崩溃。

3. 边界效应：随机切断的句子会产生语义断层，典型的医疗场景案例包括：

4. 治疗建议被截断："建议进行穿刺活检但患者拒绝"被分离到不同分块
5. 否定表述丢失："未发现转移灶"在分块边界处被切断
6. 时间序列断裂："用药三天后症状加重"被分割为孤立片段

动态分层的分块实践

内容敏感分块架构设计

采用动态分块策略需要在预处理管道中实现多级处理逻辑：

1. 结构化文本处理（耗时占比 35%）：
2. 解析 Markdown/PDF 标题层级，将 h1/h2 作为强制分块边界
3. 保留完整的章节结构，例如确保"既往史"和"现病史"不会混合

4. 对章节内连续段落，启用最大 800-token 的滑动窗口保护

5. 非结构化段落合并（耗时占比 45%）：

6. 使用 all-MiniLM-L6-v2 模型计算相邻段落嵌入
7. 动态合并条件：余弦相似度 >0.82 且合并后长度 <1024 tokens

8. 特殊处理引文和参考文献，避免与正文错误合并

9. 表格处理模块（耗时占比 15%）：

10. 开发定制解析器识别 PDF/HTML 表格结构
11. 整表作为原子单元，超过 1500 tokens 时触发横向分列处理

12. 保留表头与表体的关联，确保生化指标单位不丢失

13. 医学实体保护（耗时占比 5%）：

14. 加载 UMLS 术语集构建保护词典
15. 对"EGFR p.L858R突变"等复杂术语设置 20-token 保护半径
16. 对切断实体添加 [CONT] 标记供下游模型识别

性能与精度的权衡

医疗报告场景实测数据显示： - 漏召回率从 42% 降至 9% - 预处理时间增加 15%（主要来自相似度计算） - 显存占用降低 22%（因分块大小更均衡）

实施注意事项： - 动态分块仅适用于离线预处理，实时索引场景延迟增加 3-5 倍 - 相似度阈值需通过验证集网格搜索（推荐 0.75-0.85 范围） - 需监控分块大小分布，异常值表明解析规则需要调整

混合检索的妥协方案

三级检索加速策略

当分块优化无法满足 SLO 时，建议采用以下组合方案：

1. 向量+关键词混合检索：
2. 第一阶 BM25 检索：
   • 使用 Elasticsearch 快速筛取 Top 50 候选
   • 查询改写：扩展医学术语同义词（如"心梗"->"心肌梗死"）
   • 字段映射确保与向量库结构一致
3. 第二阶向量精排：
   • 对 BM25 结果用 bge-large 模型重排
   • 引入查询感知评分（query-aware scoring）

4. 成本增加 20%，但 P99 延迟降至 2.1s

5. 分级缓存体系：

   graph LR
   A[新查询] -->|SimHash| B{缓存查询?}
   B -->|是| C[返回缓存结果]
   B -->|否| D[完整检索流程]
   D --> E[缓存结果]

6. 高频查询缓存 5 分钟，缓存键包含：
   • 查询文本 SHA256
   • 时间范围参数
   • 患者类型筛选条件

7. 长尾查询指纹库使用 SimHash 去重

8. 渐进式截断策略：

9. 对超长查询（>512 tokens）：
   1. 使用 Med7 模型提取临床实体
   2. 保留包含最多实体的 300-token 核心段
   3. 剩余部分转化为过滤条件（如日期范围）
10. 二次检索时拼接原始查询与截断补偿条件

检查清单：何时需要放弃纯 RAG

微调方案评估指标

当出现以下任意两项时，应考虑微调方案：

1. 术语覆盖不足：
2. UMLS 标准术语召回率 <60%

3. 机构特有缩写（如"HIS"->"医院信息系统"）未映射

4. 人工干预频繁：

5. 每周相同问题修正超过 3 次

6. 规则列表维护耗时 >2 人天/周

7. 业务规则动荡：

8. 医保政策变更频率 >2 次/周

9. 临床路径版本迭代周期 <1 个月

10. 复杂逻辑需求：

11. 需要多文档联合推理（如检查结果+用药史）
12. 决策树深度 >5 层的条件判断

实施路线图与技术风险

分阶段推进计划

关键监控指标

1. 质量指标：
2. 分块边界准确率（人工抽检）
3. 临床实体完整率

4. 表格结构保留率

5. 性能指标：

6. 预处理延迟百分位
7. 缓存命中率波动

8. 显存占用峰值

9. 业务指标：

10. 临床问题首答准确率
11. 人工接管率趋势
12. 平均对话轮次

最终决策建议：医疗报告场景推荐采用 800±200 token 的动态分块，配合混合检索与分级缓存。当业务规则稳定后，可逐步引入 LoRA 微调提升复杂查询处理能力。建议每季度重新评估分块策略与业务需求的匹配度。