RAG系统做Agent知识库，检索效果总是不理想，怎么调？

先试试query改写，把口语问题转成关键词组合，比换模型见效快。

rerank用bge-reranker-large，配合hybrid检索，效果会明显改善。

我之前也踩过类似的坑，后来发现问题多半出在分块和query意图的错位上。你试试把FAQ按“问题-动作-对象”拆成更小的语义单元，比如“退款-条件”和“退款-流程”分开存，检索时用LLM先做一次意图分类再拼接查询词，比单纯改embedding有用。rerank的话，别一上来就上重模型，先试试bm25和向量分数加权融合，很多场景下成本低见效快。另外你文档里“换货”和“退款”如果经常同时出现，考虑在分块时把这类易混淆术语做同义词扩展，效果会直接不少。

试试在召回后加一层rerank，用bge-reranker-base，query和chunk一起过，效果立竿见影。

你这场景分块别按固定大小，试试按语义段落切，再把FAQ的原始问答对单独存，召回直接用问题匹配。

试试先做query改写，把口语问题拆成关键词再检索，效果比直接调chunk强不少。

说实话你这个情况我太熟了，之前我们做售后客服Agent也卡在这儿。分块策略和embedding确实不是最关键的，问题多半出在query意图太泛上，“怎么退款”这种问法，本身就没限定是售前还是售后、哪个订单，所以召回一堆换货条款太正常了。我的经验是先把rerank做起来，别用默认的cross-encoder，试试bge-reranker-base这类专门训过的模型，对FAQ场景的语义匹配会好很多。另外你可以试试在召回阶段加一层query改写，把口语化问题拆成几个子query去检索，比如“退款条件”“退款流程”“退款时效”，这样比单纯调chunk size有用得多。文档分块的话，建议按“一个操作闭环”来切，比如退款就完整包含入口、条件、步骤和常见问题，别按固定字数切。还有个野路子，直接把高频问法做成小样本few-shot，在召回前做个快速的意图预判，能很大程度缓解跑偏。你现在embedding用的是什么？如果是通用模型，建议换bge-m3或者text-embedding-3-large，对垂直领域术语的区分度会强不少。

之前做客服问答也踩过这个坑，后来发现问题往往不在分块和embedding，而是query意图太模糊。你可以先试试把用户问题做一层意图改写，比如“怎么退款”扩展成“退款条件、退款流程、到账时间”几个检索子问句，再分别去搜。rerank模型建议用bge-reranker-base，比单纯调向量相似度靠谱很多。另外文档侧，FAQ最好每个问答对单独成块，手册按章节+小节两级切，别贪大。你现在的分块大概是什么策略？

试试query rewrite把“怎么退款”扩写成“退款条件/流程/到账时间”再检索，rerank用bge-reranker-v2-m3，比换embedding管用。

手册和FAQ这种结构化文档，别急着上rerank，先看看是不是chunk切得太碎了，把退款条件和换货条件混在一起了。建议按标题层级切，每个FAQ独立成块，再给每块补一句摘要当检索锚点。query那边可以加个轻量改写，把“怎么退款”扩成“退款流程 退款条件 到账时间”，召回会稳很多。

这问题太典型了，我去年做客服Agent的时候也卡在这，调chunk和换embedding基本是治标不治本。你这种“退款”被“换货”挤掉的情况，八成是query和文档在语义空间里太近了，通用embedding压根分不清业务里的近义陷阱。我现在会先加一层轻量query改写，用LLM把“怎么退款”扩成“退款申请条件、到账时间、退款入口”，让检索信号更聚焦，而不是只靠一个短词去撞。然后rerank一定要上，别省这一步，用bge-reranker或者cohere的接口都行，top20重排到top3，效果比单纯调embedding明显得多。另外你文档分块可能也有坑，FAQ那种一问一答最好按QA对切，别按固定token硬切，不然“退款”和“换货”经常被塞进同一个块里，检索时自然互相干扰。还有个小技巧，给每个chunk前面拼上它所属的类目标题，比如“售后政策-退款”，等于给embedding加了个业务锚点。你可以先拿二十条bad case跑一遍，看看到底是召回阶段就没了，还是排序阶段被顶掉，再决定改哪层，别一股脑全调。

“怎么退款”能召回“换货流程”，这个其实挺典型的，不是单纯embedding的问题。FAQ类文档语义密度本来就低，很多条款之间差别只在几个关键词上，chunk再小也容易糊成一团。我一般会先检查文档是不是按业务意图重新组织过，而不是按原始手册的章节切，比如把退款、换货、退货各自拆成独立条目，再给每条加上明确的意图标签。query改写这块，可以试试把用户口语先映射到标准业务词，像“退款”直接扩成“退款 申请 条件 到账”，比硬调模型有用。rerank的话，bge-reranker或者cohere的rerank对短文本FAQ确实能拉开差距，但前提是召回池里得有正确的那条，不然怎么排都没用。还有个容易被忽略的点，FAQ场景用纯向量有时候不如BM25加向量混合检索，关键词命中在条款类文本里权重很高。你现在这个情况，我更倾向先回头看看分块和标注，而不是继续换embedding。

退款和换货语义太近了，光调embedding没用，加个query改写把意图先分类再检索试试。