RAG系统检索效果差，是不是我分块方式有问题？

固定500字符切确实容易出这问题，尤其技术手册这种文档，一个段落里可能前半截讲配置后半截讲报错，切完语义就碎了。你遇到“网络”匹配到故障排查段落，本质就是向量把关键词当成了主要信号，但片段本身没有完整语义。按标题层级切会好很多，LangChain里有MarkdownHeaderTextSplitter，PDF的话可以先转成markdown或者用unstructured提取结构再切。不过更关键的是检索策略，纯向量检索对技术术语的区分度不够，可以试试混合检索，BM25加向量再用rerank重排，LangChain里能接Cohere或bge-reranker。另外chunk size也不是固定的，FAQ类可以小一点，操作步骤类得整段保留，不然步骤断了反而更糟。还有个容易被忽略的点，PDF里的表格和代码块如果被切碎基本就废了，预处理时最好单独抽出来。你可以先拿几个bad case看看召回的片段到底长啥样，再决定是切的问题还是检索的问题。

固定长度切确实容易出这问题，500字符对技术手册来说太碎了，一个配置步骤可能被切成好几段，语义都散了。我之前也踩过类似的坑，后来改成按标题层级切，二级标题以下再按段落合并，效果提升挺明显的。另外你可以在检索前加个rerank，先粗召回再精排，能过滤掉不少带关键词但语义不相关的片段。PDF预处理也别忽略，有些表格和代码块直接抽文本会乱掉，最好用专门的解析工具过一遍。

固定长度切确实容易把上下文切碎，试试按标题层级做递归分块，再给每个块加个章节摘要当检索元数据。

固定长度分块对技术手册确实容易切碎语义，500字符可能刚好把标题和正文拆开，检索时自然抓不住重点。我之前也踩过这坑，后来改成按Markdown标题层级递归切，段落完整多了，召回质量明显提升。你可以先拿几份PDF试试LangChain的RecursiveCharacterTextSplitter，配合标题分隔符看看效果。另外检索时加个rerank模型或者BM25混合召回，也能压掉不少带关键词但无关的片段。

固定500字符切确实容易把语义切碎，尤其技术手册里标题和正文混在一起，检索时噪声很大。我之前也踩过这坑，后来改成按markdown标题层级切，再用RecursiveCharacterTextSplitter兜底，效果好不少。另外可以试试在chunk前面拼上所属章节标题，给embedding多点上下文。top-k老返回无关片段，有时候不是k的问题，是相似度阈值该卡一下。

固定500字符分块确实容易把语义切碎，尤其技术手册这种结构规整的文档，一个配置步骤可能被拦腰截断，检索时自然拼不出完整意图。我之前做类似项目时也踩过这个坑，后来改成先按Markdown标题层级切，再用递归字符分割兜底，效果提升挺明显的。你问“如何配置网络”却返回故障排查段落，很可能是因为那块文本里“网络”出现频率高但语义中心是排障，embedding没区分开。可以试试在分块时给每个chunk加上所属章节标题作为上下文前缀，检索时命中率会高不少。另外top-k调到8还不行，说明召回阶段就有问题，光靠后面rerank救不回来。PDF预处理也别忽略，很多技术手册是双栏排版，直接抽文本顺序会乱，先做版面分析再切分。如果条件允许，混合检索（BM25+向量）对这类关键词密集的文档比纯向量更稳。