RAG系统里文档切块大小到底怎么设？试了好几种都不太对

技术文档其实挺适合按结构切的，比如按标题层级或者代码块边界来分，硬套固定size确实容易把一段完整逻辑切碎。我一般会先按markdown header切，超过800token的再二次拆分，overlap留个10%-15%就够了，太多反而引入噪音。还有个容易被忽略的点是embedding模型本身对长文本的语义压缩能力有限，chunk太大向量表达会糊，检索自然不准。你可以试试小块检索、大块喂给LLM的方案，就是召回时用256的小块定位，但把相邻的几个块拼起来送进prompt，兼顾精度和上下文。

我后来发现chunk size真不能拍脑袋定，得看文档结构。技术文档如果按标题层级切，比固定字符数好很多，MarkdownHeaderTextSplitter这类工具可以试试。另外embedding模型本身也有影响，text-embedding-3-large对长文本的语义压缩比小模型强不少。建议先拿十几条真实query手动测召回，别光看参数调优，体感差异比想象中大。

我最近也踩过这个坑，后来发现单纯调chunk size可能方向不太对。技术文档里代码块、表格和正文混在一起，统一切块肯定顾此失彼。我的做法是按Markdown标题先做语义分块，代码块单独处理，再对超长段落做二次切分。另外embedding模型对512左右比较友好，可以试试按段落边界切到400-600之间，overlap给到10%到15%就行。

可以试试按语义切块，别死磕固定size，用RecursiveCharacterTextSplitter按段落标题分效果会好很多。

技术文档其实可以试试按标题层级切，比如H2或者H3为界，比固定字符数靠谱多了。我之前也卡在这，后来发现纯按字数切根本不管语义边界，256切出来的经常半句话就断了。另外embedding模型对中文和英文的粒度敏感度也不太一样，你用的文档是中文还是英文？overlap给个10%-15%就行，给太多反而会让相邻块高度相似，检索时挤掉真正有用的内容。

技术文档其实挺吃结构的，纯按字数切确实容易把表格、代码块、列表切得七零八落，召回时自然就碎片化或者夹带无关内容。我后来试过按标题层级切，比如用MarkdownHeaderTextSplitter先按章节分，再在章节内部做递归切分，效果比死磕chunk size好不少。overlap也不是万能的，加太多反而让相邻块高度相似，检索时挤掉真正相关的段落，50到100这个区间对技术文档可能都偏大。还有个容易被忽略的点是embedding模型本身对长文本的语义压缩能力，1024的块丢给text-embedding-3-small，它未必能抓住块内重点，检索分数就飘。可以试试在检索前加一层重排，或者用小块召回、大块喂给LLM的parent-document思路，兼顾精准和上下文。另外每篇2-8页这个量级，其实可以考虑按段落或语义相似度做动态切分，LangChain里的SemanticChunker值得跑一下对比。你现在评估召回效果是用什么指标看的，人工还是命中率？这个不搞清楚，调参容易变成盲试。

我之前也踩过这个坑，后来发现光调chunk size不够，得先看文档结构。技术文档如果有明确的章节标题，按标题切比固定长度好很多，再用小一点的overlap兜底就行。另外embedding模型对长度也敏感，可以试试把chunk控制在300-500token，配合metadata过滤，效果会稳一些。

这个思路不错，收藏了。

写得挺好，建议补充一些性能数据。

写得挺好，建议补充一些性能数据。