用LangChain做RAG，检索结果老是不准，是分块的问题还是Embedding模型选错了？

分块和Embedding其实都值得查，但你这个场景我第一个怀疑的是PDF解析质量。技术手册里表格、参数列表特别多，LangChain默认的PDF loader经常把表格拍成一坨乱文本，chunk再合理也救不回来。你可以先抽几个答非所问的case，把原始chunk打出来看看到底喂给模型的是什么，很可能根本不是切分的问题。至于embedding，ada-002对中文不是不能用，但中文技术文档里术语密集，BGE-large-zh或者m3e确实会稳一些，值得做个A/B对比。分块上500/50对操作步骤类文档偏碎了，试试按标题层级切，或者用MarkdownHeaderTextSplitter配合语义分块，让一个完整步骤落在同一块里。还有个容易忽略的点是检索策略，纯向量召回对"具体参数值"这种精确匹配很吃亏，加个BM25做混合检索再rerank，提升通常比分块调参明显。建议别一次改太多变量，先把PDF解析和chunk可视化做扎实，再动模型。

我做过类似的内部手册问答，chunk_size 500配50 overlap对技术手册确实太碎了，尤其参数表附近经常把上下文切没。建议先别急着换模型，换成按标题层级切再合并小段落，效果往往立竿见影。text-embedding-ada-002对中文不是不能用，但BGE-m3或bge-large-zh在中文技术文档上召回确实更稳。另外你检索时加个rerank，或者试试MMR，能把不同章节混在一起的情况压下去不少。

这个问题我踩过类似的坑，感觉你两个方向都值得查，但优先级不太一样。chunk_size 500配上50的overlap对技术手册来说确实偏碎了，尤其是参数表或者操作步骤，一刀切下去经常把上下文拦腰截断，检索出来的片段单看像那么回事，拼起来就串味了。你可以先试试按标题层级切，LangChain里有MarkdownHeaderTextSplitter，PDF的话可以先用unstructured把章节结构抽出来再切，效果通常比RecursiveCharacterTextSplitter硬切好不少。Embedding这块，ada-002对中文技术文档其实不算差，但BGE-m3或者bge-large-zh在中文语义匹配上确实更稳，尤其你们文档里如果有大量专有名词和缩写，换模型带来的提升可能比调分块更明显。不过别急着同时改两个变量，先固定embedding只动分块策略，跑一批bad case对比召回，再换模型复测，不然出了问题都不知道是哪个改动的锅。另外Chroma默认的余弦距离和top_k也值得看看，有时候不是召回不准，是排序把真正相关的挤下去了，可以加个rerank试试。

分块确实太碎了，500连一段完整步骤都包不住，先按标题切试试，不行再换BGE。

分块确实太碎了，500字把操作步骤都切断了，先按标题切再合并试试。ada-002中文一般，换BGE-small先跑跑对比下。

分块太机械确实容易切碎语义，试试按标题递归切；中文场景ada不如换bge-large，我换完召回明显好了。

PDF技术手册按章节切比较好，RecursiveCharacter一刀切容易把上下文切碎，先换分块策略试试。