文档切片策略选择
假设你点了一个超大的披萨，18寸的那种。
直接抱着吃？不现实。得切成小块。
但怎么切有讲究：
- 切太大，嘴巴塞不下
- 切太小，馅料都掉了，吃起来没味道
- 切得位置不对，可能把一块完整的培根切成两半
文档分片也是同样的道理。
大模型的上下文窗口是有限的，一篇几万字的文档塞不进去。而且我们检索的时候，想找到的是最相关的那一小段，不是整篇文档。
所以要切块。但切多大、怎么切，直接影响后面的检索效果。
切大了切小了，都是问题
切太大会怎样
假设我把一篇5000字的文档切成5块，每块1000字。
问题一：检索不精准
用户问"打印机怎么换墨盒"，检索返回的那一块1000字里，可能只有100字是真正讲换墨盒的，其他900字讲的是打印机怎么联网、怎么设置纸张大小。
这900字就是噪音，会干扰大模型的判断。
问题二：超出上下文限制
检索返回5块，每块1000字，加上用户问题和系统提示词，总共可能有6000+字。
如果大模型的上下文窗口只有4096 tokens，直接就超了。
切太小会怎样
假设我切成50块，每块100字。
问题一：语义不完整
一句话被切成两半，前半句在A块，后半句在B块。
A块：如果打印机出现卡纸现象，请先
B块：关闭电源，然后打开后盖取出纸张。
单独检索到A块或B块，都是不完整的信息。
问题二：上下文丢失
有些内容需要结合上下文才能理解。比如：
上一段：XX-3000型号打印机支持双面打印。
这一段：该功能需要在驱动程序中开启。
如果"这一段"被单独切出来，"该功能"指的是什么就不清楚了。
所以到底切多大
没有标准答案，得看你的具体场景。
但有一些经验值可以参考：
| 场景 | 建议大小 | 原因 |
|---|---|---|
| 技术文档 | 500-1000字 | 技术内容逻辑性强，需要保持段落完整 |
| 新闻资讯 | 300-500字 | 内容相对独立，可以切小一些 |
| 法律合同 | 按条款切 | 每个条款是独立的语义单元 |
| 代码文档 | 按函数/类切 | 代码有明确的结构边界 |
分块大小经验值
通用起点：chunk_size = 500~1000字，overlap = chunk_size的10%~20%。宁可先设大一点，发现检索不精准再缩小。不同场景差异较大，最终要通过实际测试集来验证效果。
付费内容提示
该文档的全部内容仅对「JavaUp项目实战&技术讲解」知识星球用户开放
加入星球后，你可以获得：
- 超级八股文：100万+字的全栈技术知识库，涵盖技术核心、数据库、中间件、分布式等深度剖析的讲解
- 讲解文档：超级AI智能体、黑马点评Plus、大麦、大麦pro、大麦AI、流量切换、数据中台的从0到1的详细文档
- 讲解视频：超级AI智能体、黑马点评Plus、大麦、大麦pro、大麦AI、流量切换、数据中台的核心业务详细讲解
- 1 对 1 解答：可以对我进行1对1的问题提问，而不仅仅只限于项目
- 针对性服务：有没理解的地方，文档或者视频还没有讲到可以提出，本人会补充
- 面试与简历指导：提供面试回答技巧，项目怎样写才能在简历中具有独特的亮点
- 中间件环境：对于项目中需要使用的中间件，可直接替换成我提供的云环境
- 面试后复盘：小伙伴去面试后，如果哪里被面试官问住了，可以再找我解答
- 远程的解决：如果在启动项目遇到问题，本人可以帮你远程解决
进入星球后，即可享受上述所有服务，保证不会再有其他隐藏费用。
