别再背 500 tokens + overlap 50：它可能把制度条款切碎，让召回片段从 0.83 掉到 0.41。这一课承接上一课"Embedding 怎么评估"，给出 Chunk 切分的真正判断框架。
先把术语翻成人话
chunk：切出来的一小段资料
chunk size：每段切多长
overlap：前后多留一点重复
section-aware split：按章节条款切
semantic split：按意思完整切
一、面试现场
面试官提问
“你们 RAG 的 chunk 是怎么切的？为什么这么切？”
腾讯知识库系统一面。面试官的语气很平淡，但这是分水岭题——一句"500 tokens 加 overlap"就把候选人钉在"只用过教程默认参数"那一档；只有讲清"先看文档类型再选策略"，才进入工程级别的对话。
**直接回答：chunk 不是固定 size，是先按文档类型分类再选切分策略，制度/FAQ/表格/代码各有各的切法。**这一句先抛出去，再展开。
二、大多数人怎么答的
典型翻车回答
“chunk size 设成 500 tokens，再加 overlap 50，差不多就行了。”
这个回答有一点对：固定 size + overlap 是合理的兜底，对纯叙事文本（博客文章、长报告、新闻）能跑得动；LangChain、LlamaIndex教程默认就是这套，对原型 demo 也够用。所以面试官不会说"完全错"。
但天花板在哪？企业知识库 90% 的文档不是叙事文——是制度文件、SOP、合同、API 手册、FAQ、工单、表格混合排版的 PDF。这些文档一刀切 500 tokens 等于把"一条规定"或"一个问答对"从中间剁开，召回出来的片段读起来像断头新闻：上半句在这个 chunk 里，下半句在下一个 chunk 里，引用框里就是没头没尾的半句。不是 chunk size 的问题，是"用一种策略切所有文档"的问题。
三、深度解析
Chunk 切分的底层逻辑：你切的颗粒就是用户最终看到的引用片段。这件事拆成 4 条判断标准，不绕。
判断一：召回粒度 = 引用粒度，不能反着想
chunk 切多大，retrieval 就召回多大，prompt引用框就摆多大。关键在于：先想清楚"用户最终读到的引用片段应该是什么粒度"，再倒推 chunk size。制度文件用户希望看到"完整一条规定"，FAQ 用户希望看到"完整问答对"，代码助手用户希望看到"完整一个函数"——这都是 chunk 策略的目标，不是 size 数字。
判断二：chunk 太小 ≠ 召回更准
切得越细，recall@k数字看起来越漂亮（更容易命中字面），但答案质量反而下降。典型案例：用户问"请假提前几天申请"，chunk 切到只有"应提前 3 天"那一句，但完整条款是"普通假提前 3 天，调休假提前 5 天"——只看半句直接答错，因为条件被剥离。我认为应当：chunk 至少要包含一个完整语义单元（一条政策、一个步骤、一组问答），单元之上才考虑拆 size。
判断三：表格、代码、FAQ 必须独立策略
表格按行切，每行都要带表头列名（不带表头的中间行是垃圾）；代码按函数/类切，每段带签名和 docstring（切到if中间用户读不懂）；FAQ 按 Q+A 对切，问题和答案永远在同一个 chunk。更值得做的是：入库前先做文档分类（一个简单分类器或基于扩展名/路径），不同类走不同 splitter，混排 PDF 拆成"叙事段 / 表格块 / 代码块"分别处理。
判断四：overlap 不是越大越安全
overlap 太小，跨段语义断裂；overlap 太大，同一段被 retrieval 反复召回，top-k名额被同义重复占满，prompt 上下文里全是冗余。经验起点：中文长文 50-100 字 overlap，英文 50-100 tokens，约 5-15% 的 chunk 长度，再按 eval 调整。overlap 修不了 chunk size 选错——overlap 翻倍救不了一刀切的制度文件，只会让回答更啰嗦。
四、面试官追问链
追问 1
“chunk 太小为什么会让答案缺上下文？”
一条业务规则的"语义单元"通常是 200-600 字（一个条款、一个步骤、一段流程描述）。chunk 切到 100 字以下，单元被劈成两半：条件留在前一个 chunk，结论跑到下一个 chunk。retrieval 命中其中之一，LLM 看到的是"应提前 3 天"但不知道"应提前 3 天的是普通假"，自然答错。这种 case 在指标上表现为recall@10高、人工准确率低，是切太小最隐蔽的代价。
追问 2
“有表格、代码、FAQ 的混合文档应该怎么处理？”
入库流水线第一步是结构识别：用 markdown 解析、PDF layout 检测（unstructured/pdfplumber）或简单规则把文档拆成"叙事段 / 表格块 / 代码块 / FAQ 段"四类元素。然后分别走对应 splitter：叙事段用 size+overlap；表格按行切（每行注入表头）；代码按 AST 或函数边界切；FAQ 按 Q-A 对切。关键在于：每个 chunk 都自带"我属于哪种类型"的 metadata，retrieval 时可以分类型加权或过滤。
追问 3
“overlap 是不是越大越安全？”
不是。overlap 是为了缓冲"语义跨段"，不是用来兜底"切得不准"的。overlap 太大有三个直接代价：① 同一段反复入库，向量库存储和成本翻倍；② retrieval 召回相邻 chunk 时全是重复内容，top-k名额被浪费；③ prompt 引用框里出现复读机式的重复段落，影响 LLM 推理质量。我的经验数字是 5-15%，超过 25% 几乎一定是在用 overlap 掩盖 chunk 策略本身的问题——回去重切，不要加 overlap。
五、报销制度真实迁移
员工报销制度是 RAG 翻车最经典的场景之一：制度文件结构清晰但条款细，固定 size 切完后用户问"差旅住宿限额"召回的是"附录三表格 + 半个第六条"。下面是真实迁移前后的对照。
STEP 1：先按文档类型分流：制度、FAQ、表格、代码不要同切。
STEP 2：制度按章节条款切，保证一条规定完整。
STEP 3：用 bad case 回看 chunk 是否断句、缺上下文。
↳ 复盘数字
迁移前后用同一套 50 条 query eval 跑（数据来源：内部知识库回归集）：整体recall@100.78 → 0.91，"金额/限额"类 query0.41 → 0.83，引用框人工可读率62% → 96%。没有换 embedding 也没有上 rerank，只动了 chunk 策略。
六、本课总结
一句话总结
Chunk 不是固定 size，而是先按文档类型分类再选切分策略，引用粒度等于召回粒度。
面试锦囊
先说：召回粒度 = 引用粒度，chunk size 是结果不是起点。再说：先做文档分类（制度 / FAQ / 表格 / 代码 / 叙事），不同类走不同 splitter——制度按章节、FAQ 按 Q-A 对、表格按行带表头、代码按函数。最后补：overlap 5-15% 起步，超过 25% 一定是在掩盖 chunk size 选错。
判断 checklist
□ 入库流水线是否先做文档类型分类？
□ 制度/手册/法规类是否按章节、条款切而不是固定 size？
□ 表格按行切时是否每行都注入了表头/列名？
□ FAQ 是否保证 Q+A 对在同一个 chunk？
□ 代码是否按函数/类切并保留签名 + docstring？
□ overlap 是否在 5-15% 区间，没拿它兜底切错？
□ 是否人工抽样 10 个 chunk，确认每个都"读起来像完整一段话"？
别再踩的坑
□ 一种切分策略 PDF / Markdown / Excel 通吃。
□ chunk 切得越小越好，召回会更准。
□ overlap 加大就能解决跨段语义断裂。
□ 不抽样人工读 chunk，只看recall@k一个数字。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
