夜雨聆风1、Embedding切Chunk应该怎么做，为什么固定长度切分经常不够？
怎么做：
我先看文档类型——FAQ/结构化数据本身完整，不强切；技术文档、SOP 这类长文本，优先按标题→段落→句子递归切
chunk 大小结合模型来定——BGE/Sentence-Transformers 虽然支持 512 token，但最佳区间通常是 100~400 token
必须加 overlap——10%~20% 的重叠，防止关键信息刚好落在边界被切断
为什么固定长度不行：
它只保证长度，不保证语义完整。两个典型问题：
语义断裂：一个定义、一个步骤被切成两半，向量表示变成残缺语义，检索时召不回来
主题混杂：一个 chunk 混了多个话题，embedding 变成"平均意义"，用户问具体问题反而找不到
最终调优方法：
"语义优先 + 长度约束 + overlap + 评估验证"，最后用真实 query 的 hit_rate / MRR 来倒调 chunk 大小。
2、硬切分在实际场景中有哪些弊端？
第一，破坏语义边界
固定长度切分根本不管文档结构，标题、段落、句子、逻辑关系全部无视。一个完整概念被拦腰截断是常事。最典型的例子就是接口文档——接口名、参数、错误码本来应该放一起，硬切之后你检索到一块 chunk 只有条件说明，对应的接口上下文却跑到了别的 chunk 里，等于白切。
第二，边界信息容易丢
版本号、接口名、错误码、配置项这类关键标识，如果刚好落在两个 chunk 的交界处，那两个 chunk 里谁都没写全。检索的时候两个都"不太像"你要的答案，排序时谁都排不上去，最后关键信息直接丢了。
第三，embedding 质量下降
不是说硬切的 chunk 长度一定不对，而是它只管长度、不管语义完整性——chunk 里面只有半句话或者混了好几个主题，embedding 出来的向量要么残缺、要么变成"平均语义"。后果就是该召回的召不回来，不该召回的反而凑上来了。
第四，后面要花更多力气去补救
前面切得烂，后面就得靠 overlap、rerank、LLM 重组、上下文补全来填坑。不仅计算量上去了、延迟变大了，整个 RAG 链路也更难调试。
