向量数据库做RAG，召回率上不去怎么办？求实战经验

我也遇到过类似的情况，text-embedding-3-small做中文技术文档其实还行，但确实有几个坑容易踩。你描述的现象里，CPU部署混进GPU配置，我觉得大概率不是embedding模型本身的问题，而是chunk切得太碎了，200-300字对技术文档来说很可能把一个完整概念拆散了，检索时上下文就不够用。另外你提到重叠50字，这个比例其实偏低，可以试试重叠拉到80-100字，宁愿冗余也别丢信息。还有个容易被忽略的点是，你用的distance是L2或IP，但OpenAI的embedding本身是归一化过的，用cosine更合适，Milvus里选COSINE试试看。metadata过滤只在你知道答案属于哪篇文章时才有用，对召回率提升有限，不如先做query改写或者加个rerank。如果条件允许，加一个cross-encoder重排，前20条重新打分再取前5，效果通常立竿见影。最后建议你先别急着换embedding模型，拿十几个badcase手动看看切出来的chunk长什么样，很多时候看一眼就知道问题在哪了。

你这个情况我碰到过类似的，其实大概率不是embedding模型的锅。text-embedding-3-small在技术文档上表现没那么差，问题更可能出在切块和检索策略上。200-300字一个chunk，重叠才50字，对于技术文档来说有点尴尬——一个完整的配置步骤可能被切断了，导致语义不完整，检索时自然容易混进不相干的内容。你可以先做个实验：拿几个query手动看看正确的chunk到底长什么样，如果连你都觉得那个chunk单独拿出来语义模糊，那模型肯定也抓不准。另外L2和IP换来换去意义不大，归一化之后差别很小，不如把精力放在加一个rerank环节上，用bge-reranker或者cohere的rerank对top20做精排，效果提升通常比调distance明显得多。还有个小技巧，给每个chunk拼上它所属文档的标题和章节路径再embedding，能帮模型建立上下文，对专业术语多的场景挺管用的。metadata过滤别只按标题，试试按文档类型或者技术栈标签做前置过滤，把CPU部署那类内容直接排除掉。最后建议你先别急着换模型，把chunking和rerank这两步跑通了再看，大概率召回率能上来。

你这个情况我踩过差不多的坑，先别急着怀疑embedding模型，text-embedding-3-small在技术文档上其实没那么差。最该查的我觉得是chunking，200-300字按段落切听起来合理，但技术文档里“GPU配置”和“CPU部署”很可能出现在同一段落或相邻段落里，切完两边语义都混在一起，检索时自然分不开。你可以先做个笨办法验证：把召回的前几条原文打出来看，如果里面确实同时提到GPU和CPU，那就是切块的问题，不是模型的问题。重叠50字也可能加重这种混淆，因为重叠部分经常是过渡句，容易把两个主题粘在一起。我自己后来改成按语义或按标题层级切，再给每个chunk补一句“所属章节标题”拼到文本前面，召回明显稳了很多。metadata过滤只能兜底，解决不了语义本身糊成一团的情况。另外L2和IP换来换去意义不大，归一化之后差别很小，不如把精力放在切块和加标题上下文上。

几千篇文档用text-embedding-3-small其实不算小马拉大车，但专业领域术语多，这个模型对“GPU”“CPU”这种词的语义区分确实容易糊。你描述的那种混进CPU部署内容的情况，我第一反应不是chunking，而是embedding本身没把关键词的区分度拉出来。可以先去OpenAI的embedding模型页面对比一下3-large，或者本地跑个bge-m3试试，光换模型可能就能看到明显差异，成本也不高。chunking那块200-300字加50重叠对技术文档来说偏碎了，配置步骤这种内容一旦被切断，向量里就只剩半截语义，检索时自然容易飘。我一般会先把chunk按标题层级合并到500字左右，再让重叠只发生在段落边界，别硬切。另外你加metadata过滤按文章标题走，这个方向对，但标题粒度太粗了，试试把章节标题也写进metadata，检索时做一层轻量重排。还有个容易忽略的点：查询本身要不要做改写或HyDE，问句和文档段落的向量分布差挺多的，先拿十几条bad case手动看看top20里到底有没有正确答案，有的话就是排序问题，没有才是召回问题，这一步比瞎调参数有用。