完整题目
在RAG系统中，针对医疗、法律等专业领域文档，应如何进行有效的文本切块（Chunking）？常见的切块策略及其优缺点是什么？
本文目录
核心原则
专业文档（医疗/法律）的核心特征是强结构、强引用、术语密集，切块需优先保证语义完整性和上下文可追溯性，而非简单按token切分。
常见策略对比
| 策略 | 做法 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 固定长度切块 | 按token/字符数硬切（长度需通过实验确定） | 简单、批量处理快、embedding对齐 | 切断语义、丢失章节边界、表格被破坏 | 非结构化文本、快速原型 |
| 递归字符切块 | 按标点→句子→段落层级递进切分 | 保留基本可读性、实现简单 | 对复杂嵌套结构（法律条款层级）处理粗糙 | 通用文档、博客文章 |
| 语义切块 | 用embedding相似度检测主题边界 | 块内语义一致、检索精度高 | 计算成本高、边界可能漂移 | 长论述性文本、医学综述 |
| 结构感知切块 | 解析PDF/DOC的标题、章节、条款编号 | 完全保留文档逻辑结构、支持精确引用溯源 | 依赖文档解析质量（如OCR、版式分析） | 法律合同、病历、监管文件 |
| 智能体切块（Agentic） | LLM先读全文，按主题/事件主动划分 | 最贴合人类理解、可提取跨段落关联 | 成本高、延迟大、需设计prompt | 超高价值文档、需要深度推理的场景 |
医疗/法律领域的实践要点
1. 优先保结构
- 法律：以"条款→款→项"为最小单元，而非固定长度
- 医疗：以"主诉-现病史-检查-诊断"等病历章节为边界
2. 元数据增强
chunk = {
"content": "...",
"source": "民法典第X条第X款",
"parent_section": "合同编",
"related_chunks": ["id_xxx", "id_yyy"] // 引用关系
}3. 重叠策略（Overlap）
- 比较零重叠、短窗口和较长窗口，用同一评测集验证是否缓解边界信息丢失
- 对法律引用链（如"参见第X条"），需在metadata中显式链接
4. 多粒度索引
- 粗粒度：章节级（用于过滤）
- 细粒度：段落/条款级（用于精确匹配）
一句话总结
专业RAG的切块不是预处理步骤，而是知识建模——把文档的结构权威转化为检索系统的可解释性。
学习建议
建议系统学习该知识点
换一种问法，检查是否真正理解
场景切入
假设你在做一个医疗知识库的RAG系统，用户问‘阿司匹林和布洛芬能一起吃吗’，结果系统返回了半句诊断和一个检查结果，完全答非所问。你觉得问题大概率出在文档切块上？具体你会怎么切病历和指南这类文档？
层层追问
你平时做RAG时，文档切块一般怎么考虑？……那如果文档是法律合同，有嵌套条款和引用，你还会用固定长度切吗？……所以针对这种强结构、强引用的专业文档，你觉得关键策略是什么？
直球架构
在医疗或法律领域的RAG系统中，文本切块需要怎么设计？请你对比固定长度、递归字符、语义、结构感知和智能体这几种策略，说说它们的优缺点，以及你会选哪种并如何做元数据增强。
练习口述回答 · 约4分钟
- 一句话定位：结构化知识建模
- 边界划分：不同策略的适用场景
- 真实业务场景：医疗病历切块
- 落地风险与前提：文档质量、元数据工程
- 工程师姿态判断：多粒度索引加结构感知
- 可延伸点：跨段落引用链的挑战
这道题其实不是在问怎么切文本，而是在问怎么把文档的结构权威转化成检索系统的可解释性。说白了，就是知识建模。
先说一下常见的[[切块]]策略，它们各有各的适用场景。固定长度切块最简单，按token硬切，但很容易把语义切断，比如法律条款的‘第X条’可能被一刀两断，所以只适合快速原型。递归字符切块按标点、句子、段落递进，保留基本可读性，但处理复杂嵌套结构比如法律条款层级时就很粗糙。语义切块用 [[Embedding]] 相似度检测主题边界，块内语义一致，检索精度高，但计算成本高，边界可能漂移。真正落地时，我会把结构感知切块和语义切块结合起来，因为专业文档的核心特征是强结构、强引用、术语密集。
举个例子，医疗病历。一份病历有主诉、现病史、检查、诊断等章节，如果按固定长度切，一个章节被切成两半，检索时可能只找到一半信息，导致诊断依据不完整。我会先解析PDF或文档结构，以章节为边界切块，比如主诉一段、现病史一段，这样保证了语义完整性。但病历里还有引用关系，比如诊断里写着‘参见影像检查报告’，这就需要在元数据里显式链接。所以我会给每个块加上元数据，包括来源章节、父级标题、相关块ID，这样检索时能追溯上下文。
这里有个坑：结构感知切块的前提是文档解析质量。如果PDF是扫描件，[[OCR]] 识别不准，标题层级都乱了，切块就全崩。所以上线前我会特别关注文档预处理，用版式分析或者LLM辅助提取结构。常见失败场景是OCR把‘第一章’识别成‘第，章’，导致章节边界丢失。
我更倾向采用多粒度索引：粗粒度用章节级做过滤，细粒度用段落或条款级做精确匹配。比如法律合同，先按编、章、节、条、款、项分层，检索时先定位到章，再在章内精确匹配条款。这样既能控制检索范围，又能保证精度。
最后我想说，专业[[RAG]]的切块不是预处理步骤，而是知识建模的一部分。它需要你把文档的结构权威转化成检索系统的可解释性。
还有一个挑战是跨段落引用链。比如法律条文里‘参见第X条’，如果切块时没有把引用关系显式链接，检索时可能只找到引用点而找不到被引用的内容。所以我会在元数据里维护引用关系图，检索时做多跳查询。