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改写把意图先分类再检索试试。

试试加个业务同义词表，把“退款”映射到“退货/返款”这些词再检索。RAG对口语化query确实很吃力。

这种问“怎么退款”却召回“换货流程”的情况，八成是分块把语义切碎了。手册和FAQ混在一起切，退款和换货的段落经常挨着，embedding很容易把它们混成一类。建议先按业务动作重新分块，比如把退款、换货、退货各自独立成块，再在块里保留标题和适用条件。query改写可以加一层意图分类，先把用户问题归到退款类，再去检索对应块，比单纯调rerank更直接。

你这个问题其实挺典型的，很多做Agent知识库的都会踩到这个坑。光调chunk和换embedding模型确实很难根治，因为“退款”和“换货”在语义空间里本来就靠得很近，embedding模型分不开也正常。我建议你先从query侧下手，比如加一层轻量的query改写，把用户口语化的“怎么退款”扩展成“退款申请流程、退款条件、退款到账时间”这类更贴近文档表述的关键词，再拿去检索。另外rerank真的值得上，用一个cross-encoder对粗召回的结果重新打分，能把“换货流程”这种擦边球压下去。不过更关键的可能是你文档分块的问题，手册和FAQ如果按固定长度切，很容易把“退款”和“换货”混在同一块里，建议按语义段落或者问答对来切，保证每块主题单一。还有个小技巧是给每个chunk加上标题或业务标签，检索时先做一层元数据过滤，能砍掉不少无关召回。你可以先拿十几条bad case手动跑一遍，看看是召回阶段就没捞到对的，还是排序阶段被挤下去了，定位清楚再调会省很多力气。

退款和换货在语义空间里确实挨得太近，光调chunk和embedding很难拉开差距。我建议加一层query意图分类，先判断用户问的是售后哪类子问题，再限定检索范围，比纯靠向量召回靠谱。另外rerank可以用bge-reranker这类交叉编码器，对“退款”“换货”这种细粒度区分效果挺明显。文档分块也检查下，别把退款条件和换货条件切到同一块里了。

试试加一层query改写，把“退款”扩成“退货退款流程”，再上rerank，效果一般能拉回来不少。

你这个“怎么退款”被匹配到“换货流程”，大概率是query和文档都用同一套embedding，但退款和换货在语义空间里挨得太近了。我建议先加一层query改写，把“怎么退款”扩成“退款条件、退款流程、退款到账时间”这类具体意图，再配合轻量rerank模型做二次排序，效果会明显不少。另外你文档如果是手册和FAQ混在一起，chunk策略最好按问答对来切，别按固定字数硬切，不然条款上下文全断了。

退款和换货这种query在向量空间里确实太近了，语义相似度都高，光靠embedding模型很难拉开差距。你光调chunk大小和换模型，方向可能有点偏，因为问题大概率不在编码那一步，而是在召回之后的排序上。可以试试加一个cross-encoder做rerank，把召回top20重新打分，对这类近义意图的区分会明显好一些。另外query改写这块，可以针对业务场景做意图分类，比如先判断用户问的是退款、换货还是物流，再带上意图关键词去检索，比直接拿原句去搜强。还有个容易被忽略的点，你手册和FAQ的分块如果是按固定长度切的，很容易把“退款条件”和“换货条件”切到相邻块里，检索时互相干扰，建议按标题层级或者问答对来切。我之前做类似客服知识库的时候，还加了一层同义词映射，把“退款”“退钱”“退货退款”统一归一化，召回率提升挺明显的。你可以先拿几十条bad case看看是召回阶段就没捞到正确文档，还是捞到了但排序靠后，定位清楚再动手调，不然容易瞎试。

分块别按固定长度切，按语义段落来。再加个rerank模型，query改写可以试试把“怎么退款”扩成“退款流程 条件 到账时间”。

有没有更详细的教程推荐？