Lesson 04 · 定长切片 (512 tokens) → 关键条款被切断, 引用错乱¶

Problem¶

律所 / 医院 / 医疗器械 RAG 项目常见: - 用默认 LangChain 定长 512-token splitter - 检索出的 chunk 是"半个条款 + 上一条款结尾" - 生成答案时把两个不相关条款拼在一起 - 律师看了直接说"这不是我在找的" - 医生说"这引用的位置对不上原指南" - 检索命中率跌到 55-70%, 生产不可用

Root Cause¶

语义单元被机械切断.

• 法律条款: "第 XX 条 ..." 一条一段, 中间不能切
• 医疗指南: "推荐 · 理由 · 剂量" 是一组, 中间不能切
• 合同章节: "第一章 定义 · 第二章 权利义务" 章内不能乱切
• 表格 / 编号列表: 原子单元, 拆开就散架

定长 chunking 不理解这些结构, 只按 token 计数切.

Fix¶

语义 + heading-aware chunking:

• 300-800 tokens 每 chunk, 50 tokens overlap
• Heading-aware: 标题永远和紧邻段落绑定
• 语义边界优先: 段落 / 句子边界 > token 计数
• 表格 / 编号条款: 视为原子 — 不切
• 章节感知: "第 X 条" / "§" / "Article" 等标记识别为条款起点

工具: - LangChain 的 MarkdownHeaderTextSplitter + 自定义 clause splitter - Unstructured.io 对法律 / 医疗结构文档更友好 - 测试: 抽 30 条真实用户 query, 跑 hit@5 > 90% 才通过

How to Avoid¶

• 索引前做 chunking 效果评估 (30 query 样本 · 3 LLM 盲评)
• 结构化文档 (法律 / 医疗 / 合同 / 标书) 一律不用定长
• Chunk 大小要根据领域调整 (法律 500-800, 医疗 300-600, 合同 400-700)
• 每次 chunking 策略变化都要重跑评估
• 生产要版本化 chunk 库 (可回滚)

Related cases¶

• Case 04 · 律所三库合一 RAG — 律师条款检索 P50 45min → 3min, 引用准确率 >95%
• Case 01 · 三甲医院 AW36-72B — 指南查询 8-15min → 45s
• Case 06 · 医疗器械支持 RAG — 一线响应 -40%

Related how-tos¶

• RAG Cold Start · 6 Steps — 完整 chunking 决策方法

避坑成本估算: RAG 命中率不达标 = 6-12 个月项目返工, 用户信任崩塌.

下一步: 30 min RAG 冷启动对齐