RAG 的效果，70% 取决于分片质量。这是业内共识，但真正讲清楚"怎么分、为什么这么分"的系统性内容并不多。这篇就是来解决这个问题的。

一、RAG 是什么？为什么需要分片？

RAG 这个概念这两年被频繁提及，但很多人对它的理解还停留在表面。在讲分片之前，先说清楚一件事：RAG 到底是什么？

RAG（Retrieval-Augmented Generation，检索增强生成）是目前最主流的大模型落地架构之一。它的核心思想很简单：

不给大模型讲它不知道的东西，而是让它自己去找。

具体来说，RAG 的工作流程是四步：

1. 建库：把你的文档切分成小块，转成向量，存入向量数据库
2. 检索：用户提问时，把问题也转成向量，在数据库里找最相似的那几块
3. 增强：把检索到的内容拼到提示词里，作为上下文
4. 生成：大模型基于原始问题 + 检索到的上下文，生成回答

画个流程图：

用户提问 ↓向量检索 → 找到最相关的文档片段 ↓拼接到提示词中（原始问题 + 片段） ↓大模型生成回答

那分片（Chunking）在整个流程中扮演什么角色？

分片是 RAG 第一步"建库"时的核心操作。分片质量直接决定检索精度——这个说法不是夸张。

打个比方最直观：

• RAG 系统= 一家图书馆
• 文档= 一本书
• 分片= 你把书拆成章节还是切成页
• 向量检索= 图书管理员帮你找相关内容
• 大模型= 借书的学生

书切成太碎的纸片，管理员找不到完整章节，学生读到的是断章取义的片段。把整本书塞给管理员，检索效率低，大量无关内容稀释重点。

刀工不好，要么切碎了拼不回原样，要么块太大塞不进锅。

分片直接决定了：

1. 检索精度——用户的问题能不能找到最相关的片段
2. 上下文完整性——检索到的内容是否包含完整的语义单元
3. Token 成本——分片太大浪费 Token，分片太小丢失信息
4. 向量质量——向量模型对短文本的理解能力 vs 对长文本的稀释效应

二、分片的本质矛盾

分片的核心矛盾有三个。

矛盾一：粒度 vs 完整性

• 分太细：单个分片语义不完整，检索到的是碎片信息，LLM 无法独立回答
• 分太粗：单个分片包含大量无关信息，稀释了向量表示，检索精度下降

矛盾二：检索精度 vs 上下文覆盖

• 精确检索需要小分片，确保向量表征高度聚焦
• 上下文完整需要大分片，确保检索结果包含足够的回答信息

矛盾三：通用性 vs 场景适配

• 法律文档需要严格按段落切分
• 技术文档需要保持代码块完整性
• FAQ 适合按问答对切分
• 学术论文需要按章节切分

没有万能的分片策略。

三、常见分片策略详解

1. 固定长度分片（Fixed-Size Chunking）

思路：按固定字符数或 Token 数切分。

"我是一家科技公司..." → 每 512 个字符一刀切

• 实现简单，性能最高，分片大小可控
• 经常从句子中间切断，语义断裂，不区分内容结构

适合快速原型，或者对精度要求不高的场景。

最佳实践：

• 中文建议 200-500 字符，英文 256-512 Token
• 设置 overlap（重叠）30-50 字符，避免边界信息丢失
• 不要设太大，向量模型对长文本的表征能力会下降

2. 分隔符分片（Delimiter-Based Chunking）

思路：按文档自然结构切分。

# 按段落切分chunks = text.split('\n\n')# 按标题切分（Markdown）# 注意：中文文档标题（如 # RAG 原理）后面没有空格，需要去掉 \schunks = re.split(r'(?=^#{1,6}\s{0,1})', text, flags=re.MULTILINE)

• 尊重原文结构，语义完整性好
• 对结构化的文档效果极佳
• 遇到"没有标题的长段落"就懵了
• 不同文档格式（PDF、Word、HTML）需要不同的预处理

适合 Markdown 文档、技术手册、结构化知识库。

3. 递归分片（Recursive Character Chunking）⭐

LangChain 的经典实现。按优先级从粗到细尝试切分：

1. 先按段落切分2. 段落太长 → 按句子切分3. 句子太长 → 按单词切分4. 单词还太长 → 按字符切分

这是 LangChain 默认的RecursiveCharacterTextSplitter的实现逻辑。

• 自适应粒度，兼顾完整性和精度
• 内置 overlap 机制
• 经过大规模验证，工业级可靠
• 不真正理解语义，只是物理切分
• 遇到跨段落的连贯内容可能切断

大多数项目的起点。先从它开始，后续再优化。

4. 语义分片（Semantic Chunking）🧠

思路：利用 embedding 模型，检测语义边界。当两个相邻文本片段的语义差异超过阈值时，在此处切分。

核心逻辑：

计算相邻句子间的语义相似度 → 如果相似度低（语义跳跃大）→ 在此处切分 →如果相似度高 → 合并到同一片段

• 真正的语义边界，切分后每个片段内主题一致
• 避免从连贯段落中间切断
• 分片大小自适应，不需要硬编码
• 需要调用 embedding 模型，速度较慢
• 阈值调优需要实验
• 计算成本高，不适合海量文档预处理

对检索精度要求高、文档结构不规则的场景。

最佳实践：

• cosine similarity 阈值设为 0.7-0.85
• 可先粗切分再在粗分片内做语义细化
• 配合 overlap 使用效果更好

5. 基于结构的分片（Structure-Aware Chunking）

思路：利用文档本身的层级结构（标题层级、表格、列表、代码块等）进行智能切分。

示例：

• Markdown：按#标题层级切分
• HTML：按<section>、<article>切分
• PDF：识别章节结构
• 代码：按函数/类定义切分
• 最大程度保留原文结构
• 特别适合有明确层级结构的文档
• 每种文档格式需要专门解析
• 解析质量直接影响分片质量

6. 按问答对分片（Q&A Pair Chunking）

思路：将 FAQ、问答文档直接按"问题-答案"对切分。

• 与用户查询意图天然对齐
• 检索精度较高
• 只适用于有明确问答结构的文档
• 开放式文档无法使用

如果原始数据就是 Q&A 格式，直接按问答对切。原始数据是长文档的话，可以先用 LLM 做"反向提取"——自动生成问题形成 Q&A 对。长答案（超过 1000 字）可按子段落拆分，但每个子段落要补全父问题上下文。overlap 设为 0-10%。

四、Overlap（重叠）的必要性

分片时 overlap 基本是必选项。

overlap 解决两个问题：

• 防止边界信息丢失：一个关键信息可能在两个分片的交界处
• 保持上下文连续性：检索到的片段不会因为"刚好切在中间"而丢失开头
• 固定长度分片：10-20%
• 递归分片：LangChain 默认 20%
• 语义分片：5-10%
• overlap 越大，存储和检索成本越高

五、分片大小的选择指南

经验法则

为什么不要太大？

1. 向量表征稀释——embedding 模型是为短文本优化的，过长会导致语义模糊
2. Token 浪费——检索到大分片后，LLM 需要处理更多无关 Token
3. 检索精度下降——大分片包含更多噪声，向量相似度计算不准确

为什么不要太小？

1. 语义不完整——检索到的片段无法独立回答
2. 存储成本翻倍——分片越多，向量库越大
3. 上下文碎片化——LLM 需要拼接多个片段才能理解

六、不同场景的分片策略

场景一：Q&A / 知识库问答

典型场景：企业帮助文档、产品 FAQ、客服知识库

推荐策略：问答对分片

把每一个"问题+答案"对当成一个完整的分片单元。

用户提问时意图明确——“怎么重置密码？”、“API 密钥在哪找？”。如果按传统方式把整个文档切成一段段，检索时可能找到包含答案但夹杂大量无关信息的段落，或者把答案和前面的背景说明切断。

问题和答案天然在一起，检索到的分片本身就包含完整的回答逻辑。

最佳实践：

• 如果原始数据就是 Q&A 格式，直接按问答对切，overlap 设为 0
• 如果是长文档，可以先用 LLM 做反向提取——自动生成问题形成 Q&A 对
• 每个 Q&A 分片建议附加元数据：标签、分类、难度级别
• 答案很长（超过 1000 字）的话，可以按子段落拆分，但每个子段落要补全上下文（把父问题加到子段落开头）

这种策略在客服场景的检索精度通常能达到 90% 以上。

场景二：技术文档 / API 文档

典型场景：开发者文档、SDK 使用说明、API 参考

推荐策略：结构感知分片 + 代码块保护

按文档结构（标题层级）粗切分，同时确保代码块不被切断。

技术文档有两个特点：有明显的章节层级结构；代码块是完整语义单元，不能被从中间切断。

按固定长度分片很可能把代码块切断，检索到的片段既不完整也缺乏上下文。按段落分片又可能把两个相关的 API 说明合并到一个分片里。

最佳实践：

• 第一层：按标题层级切分（##一级标题下的内容作为一个大块）
• 第二层：在标题块内按段落递归切分（300-500 Token）
• 代码块特殊处理：每个代码块单独成 chunk，带上对应的说明文字
• overlap 设为 10-15%
• 附加元数据：文档路径、章节名、代码语言类型

示例结构：

chunk-1: [API 概述] 300 字符chunk-2: [GET /users 参数说明] 400 字符 chunk-3: [GET /users 代码示例] 500 Token（完整代码块 + 说明）chunk-4: [POST /users 参数说明] 350 字符

场景三：法律/医疗等合规文档

典型场景：合同、法规条文、医疗指南

推荐策略：按条款/段落分片 + 大 overlap

严格按照原文的结构单元切分，不要破坏任何逻辑段落。

合规文档对完整性要求极高。一段法律条文可能几十行才是一个完整的条款，从中间切断后检索到的内容在法律上可能产生歧义。法律文档的措辞非常精确，不能有任何增删或模糊。

最佳实践：

• 按法律条文条款切分（“第 X 条”、“第 X 款”）
• overlap 设为 30% 甚至更高
• 分片大小可以稍大（800-1500 字符）
• 每个分片附加：文档名、章节号、条款号
• 不要使用语义分片——法律条文可能表面不相关但法律上紧密关联

场景四：学术论文 / 研究报告

典型场景：论文摘要、实验方法、结论分析

推荐策略：按章节粗切 + 段落细切 + 摘要独立

论文本身有严格结构，利用这个结构就行。

最佳实践：

• 摘要单独作为一个 chunk——摘要包含论文的完整概览，检索准确率极高
• 按章节切分（Introduction / Methods / Results / Discussion）
• 章节内部按段落递归分片（200-400 字符）
• 图表引用需要保留上下文引用关系
• 参考文献单独列出，不参与向量检索

场景五：长文本对话 / 聊天记录

典型场景：客服聊天记录、社群讨论、会议纪要、多轮对话

推荐策略：按会话轮次分片 + 语义连贯性合并

长文本对话的特点是信息密度波动大，同一话题可能跨越多轮对话。

最佳实践：

• 按会话轮次（用户/助手对）切分
• 同一话题的多轮对话通过语义相似度合并到同一片段
• overlap 设为 15-20%——关键信息可能在对话边界
• 附加元数据：会话时间、参与者角色、话题标签
• 长对话可以按时间窗口切分（如每 30 分钟一段），再在时间窗口内按话题合并

场景六：企业内部知识库（混合场景）

典型场景：同时包含产品文档、FAQ、技术规范、会议纪要

推荐策略：混合策略 + 分层索引

不同性质的文档用不同策略，最后统一到一个向量库，但带不同标签。

最佳实践：

• 给文档打上类型标签：faq、technical、policy、meeting
• FAQ 类 → 问答对分片
• 技术规范 → 结构感知 + 代码保护
• 公司政策 → 条款级分片
• 会议纪要 → 段落递归分片
• 检索时先根据用户意图做文档类型过滤，再在过滤结果中做向量检索
• 这就是混合检索的思路

场景策略速查表

七、主流开源方案

直接用哪些工具/框架。

LangChain 🦜

RAG 框架的事实标准，分片模块最成熟。

核心组件：

• RecursiveCharacterTextSplitter：递归分片（推荐首选）
• MarkdownHeaderTextSplitter：Markdown 结构感知
• SemanticChunker：语义分片（实验性）
• DirectoryLoader+Loader：文件解析 + 分片一体化
• 社区最大，文档最全，Star 30k+，生态最完善
• 与向量数据库、LLM 生态无缝衔接
• 支持几乎所有主流文档格式
• 语义分片仍在实验阶段
• 默认参数可能需要调优

新手入门、已有 LangChain 生态的项目、通用场景首选。

LlamaIndex 🦙

面向检索增强的专门框架，分片策略更丰富。

核心组件：

• SentenceSplitter：基于 NLP 的句子级分片
• SemanticSplitter：基于语义相似度的分片
• TokenTextSplitter：Token 级别的精确分片
• NodeParser：结构感知解析
• 语义分片实现比 LangChain 更成熟
• 原生支持节点（Node）概念，分片即节点
• 对复杂文档结构解析能力更强
• 社区相对 LangChain 较小
• 学习曲线稍陡

对语义分片有强需求、文档结构复杂的场景。

RAGFlow 🔥

国内团队开发的开源 RAG 引擎，2025-2026 年 GitHub 上关注量较高的 RAG 项目，专注深度文档理解。

核心能力：

• 基于深度文档理解的 RAG 引擎，融合 Agent 能力
• 可视化文本分片，支持人工干预和调整分片策略
• 支持 100+ 种文件格式（Word、PPT、Excel、扫描件、图片、结构化数据等）
• 多模态解析：支持 PDF/DOCX 中的图片理解
• 自动识别文档结构（标题、段落、表格、列表、代码块）
• 智能检索 + 重排序融合
• 可追溯的引用来源，支持引用溯源
• 可视化分片效果展示——在界面上直观看到分片结果并手动调整
• 一站式解决方案，无需自己搭管道
• 可视化分片调整适合需要精细控制的企业场景
• 中文文档理解能力强
• 支持飞书、Discord、Telegram 等多种聊天渠道接入

开箱即用的企业团队、需要分片可视化调整的场景、中文文档为主的企业知识库。

链接：https://github.com/infiniflow/ragflow（Star[1] 50k+）

Haystack

Deepset（德国 AI 公司）开发，主打工业级部署。

核心组件：

• SentenceWindowRetriever：基于窗口句子的检索
• DocumentSplitter：多种分片策略
• EmbeddingRetriever：嵌入 + 检索一体化
• 工业级稳定性，生产环境验证充分
• 与 AWS Bedrock 等云服务商深度集成
• 支持多跳检索（Multi-hop Retrieval）
• 社区活跃度不如 LangChain
• 文档质量相对一般

需要工业级稳定性、已有 AWS 生态的团队。

自建方案

有特殊需求的场景可以选择基于 embedding 模型自建分片管道。

• 完全可控，可针对业务场景定制
• 不依赖第三方框架
• 开发和维护成本高
• 需要持续的调优工作

有定制分片逻辑需求、团队研发能力强的场景。

其他值得关注的项目

• GraphRAG：用图谱结构替代简单向量检索，能解决"跨段落推理"问题
• MinerU和Docling：文档解析层面的新力量，解析质量直接影响分片质量
• markitdown：微软开源的轻量级文档转化工具，支持 RAG-ready chunking

八、进阶技巧

1. 元数据增强

分片时除了存文本内容，还要附加元数据：

{ "content": "分片文本内容", "source": "文档路径", "section": "章节标题", "page": 12, "chunk_index": 3, "metadata": { "doc_type": "faq", "language": "zh", "tags": ["RAG", "分片"] }}

检索后可以按文档来源过滤、按章节聚合、排序重排。

2. 混合分片策略

组合使用效果更好：

• 大文档 → 先按章节粗切 → 再在章节内按语义细切
• 技术文档 → 代码块单独成 chunk，正文递归分片
• 法律文档 → 按条款切分 + overlap 30%

3. 分片后验证

分片完成后一定要验证：

• 随机抽查分片内容，确认语义完整
• 检查是否有过长的分片（>1000 字符需警惕）
• 检查边界处是否有信息丢失
• 用少量查询做检索测试，看检索质量

4. 持续迭代

分片不是一次性工作，随着使用反馈持续优化：

• 用户经常问但回答不准确的 → 检查对应分片质量
• 检索排名靠前的分片 → 分析为什么相关
• A/B 测试不同分片策略的效果

九、常见误区

❌ 误区一：分片越大越好

向量模型是为短文本优化的。过大的分片会导致向量表征模糊，检索精度反而下降。

❌ 误区二：固定长度最简单，直接用

一刀切经常从句子中间断开，丢失上下文。固定长度可以作为起点，但生产环境建议至少用递归分片。

❌ 误区三：一次配置，终身受用

不同文档类型、不同业务场景需要不同的分片策略。FAQ 用问答对切分，技术文档用结构感知切分，没有万能方案。

❌ 误区四：overlap 越大越好

overlap 有助于防止边界信息丢失，但过大会导致：

• 大幅增加向量库存储成本
• 引入大量重复内容，影响检索排序 建议 10-20%，不超过 30%。

❌ 误区五：分片是唯一重要的

分片只是 RAG 的环节之一。后续的 embedding 模型选择、向量数据库配置、检索策略（相似度 vs BM25）、重排序（Re-ranking）同样重要。

十、总结

RAG 分片的核心原则：

1. 语义优先——切分后每个分片应该是一个完整的语义单元
2. 粒度适中——太小丢失信息，太大稀释精度
3. 场景适配——没有银弹，根据文档类型和业务需求选择策略

• 通用文档 → 递归分片（LangChain），overlap 20%
• Markdown/结构化文档 → 结构感知 + 递归，overlap 15-20%
• FAQ → 问答对分片，overlap 0-10%
• 高精度需求 → 语义分片，overlap 10-15%
• 技术/代码文档 → 代码块独立 + 正文递归，overlap 10-20%
• 法律/合规文档 → 条款级分片，overlap 30%+
• 学术论文 → 章节粗切 + 摘要独立，overlap 15-20%
• 企业混合库 → 混合策略 + 分层过滤，overlap 10-20%

分片这件事看起来简单，实际做深了非常考验功力。建议先跑通递归分片的 baseline，然后根据检索效果的反馈，逐步引入语义分片、混合策略等更高级的方案。迭代比完美更重要。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】