什么是 RAG 中的分块？为什么需要分块？
- 标签：AI、大模型、RAG
🏛 业务架构师
分块（Chunking）是把长文档切成较小片段再向量化入库的过程。
为什么必须分块，我从三个业务约束解释：
- 检索粒度：Embedding 是把整段文字压缩成一个向量，文档越长语义越"糊"——把一份 50 页年报压成一个向量，用户问净利润它根本区分不出来。切成小片后"一片一义"，检索才能精准命中。
- 窗口经济性：命中的内容要放进大模型上下文，按 token 计费。整篇文档塞进去既贵又稀释注意力，小分块只送"相关段落"，成本可控、答案更聚焦。
- 引用体验：业务上要求答案能定位到原文出处（合规审计、用户核验），分块是可引用、可溯源的最小单元。
分块大小的权衡是核心：太小（如 100 字）语义残缺，召回回来"只见树木"；太大（如 2000 字）精度下降、成本上升。我的经验起点是 300~500 字、10%~20% 重叠，再按 badcase 迭代。原则是：分块策略跟着知识形态走——FAQ 类可以整条入库，制度手册按条款切，技术文档按章节结构切，不追求统一参数。
🏗 系统架构师
分块（Chunking）是把长文档切成检索与生成的基本单元，它同时是检索精度和上下文效率的杠杆点。
为什么必须分块：
- 检索粒度：整篇文档一个向量，语义被平均稀释，召回不精；粒度合适的 chunk 才能让"向量代表一段完整语义"；
- 窗口预算：LLM 上下文按 token 计费，且 attention 对超长上下文有稀释效应，RAG 的本质就是"只送相关的几段"而不是整本书；
- 命中精度：Top-3 个 500 token 的精准 chunk，比 1 个 5000 token 的泛化 chunk 效果好且便宜。
架构视角的深层原因：分块其实是 RAG 的"索引设计"，等价于数据库建模——chunk 大了召回准但浪费窗口、噪声多；chunk 小了省 token 但语义破碎、召回碎。所有后续优化（重叠、父子块、上下文扩充）都是在修补这个粒度矛盾。
生产注意：分块策略必须与文档结构对齐（按标题/段落而不是机械切），元数据（文档 ID、标题路径）随 chunk 存储，用于溯源和权限过滤。经验：结构化切块对比固定长度切块，在文档问答场景通常有 10 个点以上的端到端提升。
💻 全栈开发专家
分块是把长文档切成可检索的小段。为什么必须切：
- Embedding 有长度上限，一般 512~8192 token，长文整篇没法有效编码；
- 语义粒度：整篇文档的向量是「平均语义」，用户问的是一个点，粒度太粗匹配不上；
- 上下文预算：top 5 召回要塞进 Prompt，每块太大 token 成本和噪声都爆炸；
- 溯源：引用要落到段落/页码级别，才可验证。
反过来说，切分不当的代价也很直接：块太大——语义稀释，一个块里混多个主题，召回准了但模型被无关内容干扰；块太小——语义不完整，召回到半句话，模型拼不出完整事实。
工程默认值我一般用 512 token、10%~15% overlap，再按文档类型调整：FAQ 类按问答对整条切；合同/制度按条款切（标题层级驱动）；技术文档按 Markdown header 切。核心原则是让块的边界贴合语义边界，而不是机械等分。上线前用 recall@k 评测集对比几组 chunk_size，数据说了算——不同语料最优值差异很大，照抄别人参数是常见坑。