向量库为何答不了“为什么”：RAG因果推理缺陷与工程补救

1. 从一个让人抓狂的提问说起

你有没有遇到过这种场景：花了大半天把一堆产品文档、客服话术、内部规范切好块、打好向量、灌进向量库，兴冲冲地打开对话框问一句"为什么我们的退款政策要设置成七天"，结果它给你返回三段原文——每段都写着"退款政策为七天"，但就是没有一句解释"为什么"。

你换个问法："这个政策是怎么来的"，它还是把同样的三段话原封不动端上来。你再追问："那如果客户情况特殊怎么办"，它开始一本正经地拼接不相关的段落，看起来像在回答，实际上什么都没回答。

这不是你的向量库坏了，也不是模型太笨。这是向量检索这套机制从娘胎里带出来的一个结构性缺陷：它能找到"是什么"，但几乎找不到"为什么"。

我前后在三个不同规模的项目里踩过这个坑。第一次以为是 embedding 模型选得不好，换了两个模型，没用。第二次以为是 chunk 切得不对，重新切了三遍，还是没用。第三次才想明白——问题根本不在工程细节上，而在于我们用了一种"相似度匹配"的工具，去干一件"因果推理"的活。

这篇内容就是把这三次踩坑的经验完整拆开，讲清楚向量库为什么回答不了"为什么"，以及在工程上我们到底能做什么、不能做什么、哪些是花架子、哪些是真管用。适合正在做 RAG 应用、知识库问答、智能客服的同行参考，也适合刚接触向量检索、还没被它坑过的朋友提前打个预防针。

2. 向量检索到底在干什么：先把机制说透

2.1 一句话讲清向量检索的本质

向量检索的本质，是把文本映射到一个高维空间里的点，然后找离你问题最近的那些点。

就这么简单。你问一句话，这句话也被映射成一个点，然后系统在这个高维空间里画一个圈，把圈里所有的点捞出来，按距离远近排序，取前 K 个返回。

这里的关键词是"距离近"。什么叫距离近？就是两段文本在语义上"说的是一回事"。注意，是"说的是一回事"，不是"一个解释了另一个"。

我常用一个类比来解释这件事：向量库就像一个巨大的图书馆，但它没有目录、没有索引、没有作者信息，只有一个管理员。这个管理员的工作方式是——你把你想找的内容描述一遍，他凭直觉去书架上抽几本"感觉最像"的书给你。他抽书的标准是"封面和内容看起来像"，而不是"这本书里有没有你真正需要的答案"。

所以当你问"为什么退款政策是七天"，管理员看到"退款政策""七天"这几个词，就去抽了几本标题里带这些词的书。至于书里有没有写"为什么"，他不管，也管不了。

2.2 相似度不等于因果性

这是整件事的核心。向量空间里的"近"，衡量的是语义相似度，不是逻辑关联度。

"退款政策为七天"和"为什么退款政策是七天"，这两句话在向量空间里确实很近——它们共享了"退款政策""七天"这两个核心概念，embedding 模型会把它们映射到相邻的区域。但"近"不代表后者能从前者的文本里被推导出来。

打个比方：你问"为什么天会下雨"，向量库给你返回十本写着"下雨是一种降水现象"的书。这些书和你的问题高度相关，但它们回答的是"下雨是什么"，不是"为什么会下雨"。你要的因果链条——水汽蒸发、遇冷凝结、重力下落——在这些书里可能一个字都没有。

向量检索能做的，是"相关内容的召回"。它不能做的，是"因果关系的推理"。这两件事在信息检索领域里是两个完全不同的任务，只是在大模型时代被混在一起了。

2.3 为什么大家会误以为它能回答"为什么"

因为在大模型出现之前，我们习惯了搜索引擎的行为模式。你在搜索框里输入"为什么XXX"，搜索引擎会返回一堆网页，其中有些网页确实在讨论原因。你点进去看，就得到了答案。

但这里有个关键区别：搜索引擎返回的是"可能包含答案的网页"，最终回答你的是网页的作者，不是搜索引擎。搜索引擎只负责找，不负责答。

向量库在 RAG 架构里扮演的角色，和搜索引擎一模一样——它只负责找，不负责答。真正"回答"你的是后面那个大模型。如果向量库找回来的内容里没有"为什么"的答案，大模型再强也变不出来。它只能基于你给它的材料说话，材料里没有的东西，它要么编，要么说"我不知道"。

所以问题的根源是：你的知识库里可能根本就没有"为什么"这个信息，或者有，但向量检索没能把它找出来。

3. 拆解"为什么"类问题的三种失败模式

3.1 第一种：知识库里压根没有原因

这是最常见也最容易被忽略的情况。很多团队在构建知识库的时候，收集的都是"结论性文档"——产品说明书、操作手册、政策条款、FAQ 标准答案。这些文档的特点是：只写"是什么"和"怎么做"，不写"为什么"。

比如一份退款政策文档，它可能写着：

用户可在购买后七天内申请无理由退款。退款将在三个工作日内原路返回。

它不会写：

我们设置七天这个期限，是因为行业惯例是七天，同时考虑到物流往返周期平均为五天，留出两天缓冲。三个工作日是基于支付通道的结算周期决定的。

后面这段"为什么"的信息，通常存在于产品评审会的会议纪要里、产品经理的脑子里、或者某个已经离职的同事的聊天记录里。它从来没有被写进正式文档，自然也就不在向量库里。

这种情况下，你问"为什么"，向量库只能返回那段"是什么"的原文。它不是找不到原因，是原因根本不存在于它的数据里。

3.2 第二种：原因存在，但被切碎了

假设你的知识库里确实有一份文档写了原因，比如一份产品设计说明：

退款期限设置为七天。这个期限的设定参考了行业通行做法，同时结合了我们自身的物流时效数据。物流往返平均需要五天，因此七天可以覆盖大部分场景。支付通道的结算周期为 T+1 到 T+3，所以退款到账时间承诺为三个工作日。

如果你按固定长度切块，比如每 500 字切一刀，很可能"退款期限设置为七天"和"物流往返平均需要五天"被切到了两个不同的块里。你问"为什么是七天"，向量检索命中的是第一个块，返回的是"退款期限设置为七天"，而解释原因的那句话在第二个块里，没被召回。

这就是切块策略带来的信息割裂。向量检索是按块召回的，一个块就是一个独立的检索单元。如果因果关系跨越了块的边界，检索就会断链。

3.3 第三种：原因存在且完整，但语义距离太远

还有一种更隐蔽的情况。原因和结论都在同一个块里，但它们的表述方式差异太大，导致 embedding 模型认为它们"不相关"。

举个例子。你的文档里写着：

该功能上线后用户投诉率下降了 40%，因此我们决定将其保留并推广到其他模块。

你问的是："为什么这个功能要保留"。这句话的 embedding 和"用户投诉率下降 40%"的 embedding 之间的距离，可能比你想的要远。因为"保留"和"投诉率下降"在语义上不是近义词，embedding 模型不一定能把它们关联起来。

向量检索擅长的是"同义替换"——你问"退款"，它能找到"退货""返还"；你问"七天"，它能找到"一周""7日"。但它不擅长"逻辑关联"——你问"为什么保留"，它很难联想到"因为投诉率下降"。

3.4 三种失败模式的对照

失败模式	根本原因	典型表现	工程上能否缓解
知识库无原因	数据缺失	返回的全是"是什么"	不能，只能补数据
原因被切碎	切块策略不当	返回结论不返回原因	能，调整切块
语义距离远	embedding 局限	返回不相关内容	部分能，混合检索

这张表是我自己在排查问题时总结的，每次遇到"向量库答不了为什么"，先对照这张表定位属于哪种情况，再决定怎么处理。大部分时候是第一种和第二种混在一起。

4. 工程上能做的补救：五种实操方案

4.1 方案一：在数据源头补"为什么"

这是最根本的解法，也是最费力的。你得回到知识库的构建环节，把那些"为什么"的信息补进去。

具体怎么做？我的做法是，在整理文档的时候，强制要求每一条结论性描述后面跟一段"背景说明"。格式可以是这样：

结论：退款期限为七天。 背景：行业通行做法为七天；物流往返平均五天，七天可覆盖大部分场景；支付通道结算周期 T+1 到 T+3。

这段"背景"就是"为什么"的答案。它和结论放在同一个块里，向量检索命中结论的时候，背景也一起被召回了。

这个方案的关键在于：你得有人去写这些背景。如果原始文档里没有，就得找产品经理、找业务方、找老员工去问。这是个体力活，但效果最扎实。

提示：补背景信息的时候，尽量用"因为""由于""考虑到""基于"这类因果连接词。这些词能帮助 embedding 模型更好地捕捉因果关系，提高召回率。

4.2 方案二：调整切块策略，保住因果链

如果你没法改数据，那就改切块方式。核心原则是：不要让因果关系被切断。

我试过几种切块策略，效果最好的是"语义切块 + 重叠窗口"的组合。

语义切块的意思是，不按固定字数切，而是按段落、按小节切。一个完整的段落通常表达一个完整的意思，因果关系一般不会跨段落。如果跨了，那说明作者写得有问题，你可以手动合并。

重叠窗口的意思是，相邻两个块之间保留一定的重叠内容。比如每个块 500 字，相邻块重叠 100 字。这样即使因果关系刚好在边界上，也有机会被其中一个块完整包含。

具体参数怎么定？我的经验是：

• 块大小：300 到 800 字之间，根据文档密度调整。技术文档可以小一点，叙述性文档可以大一点。
• 重叠比例：10% 到 20%。太低起不到保护作用，太高会引入大量冗余，影响检索精度。
• 切块边界：优先在段落结束、标题切换、列表项结束处切，避免在句子中间切。

4.3 方案三：混合检索，用关键词兜底

纯向量检索的一个大问题是，它对"低频但关键"的词不敏感。比如"为什么"这个词本身，在 embedding 空间里可能没有很强的区分度。但如果你用关键词检索（BM25 之类的），"为什么"就能直接命中那些包含原因说明的文档。

混合检索的思路是：同时跑向量检索和关键词检索，然后把两边的结果合并、去重、重排序。

我实测下来，混合检索对"为什么"类问题的召回率提升很明显。纯向量检索可能只能召回 40% 的相关内容，加上关键词检索之后能到 70% 以上。

实现上，可以用现成的混合检索框架，也可以自己写一个简单的合并逻辑：

def hybrid_search(query, vector_store, keyword_index, top_k=10): # 向量检索 vector_results = vector_store.search(query, top_k=top_k) # 关键词检索 keyword_results = keyword_index.search(query, top_k=top_k) # 合并去重 seen = set() merged = [] for doc in vector_results + keyword_results: if doc.id not in seen: seen.add(doc.id) merged.append(doc) # 重排序（可以用交叉编码器，也可以用简单的分数融合） reranked = rerank(query, merged) return reranked[:top_k]

重排序这一步很关键。向量检索和关键词检索的分数不在同一个量纲上，不能直接比较。要么用交叉编码器重新打分，要么做归一化之后加权融合。

4.4 方案四：查询改写，把"为什么"翻译成"是什么"

这个方案有点绕，但有时候很管用。思路是：用户问的是"为什么"，但知识库里存的是"是什么"。那就在检索之前，先把"为什么"改写成几个"是什么"的子查询。

比如用户问："为什么退款政策是七天？"

你可以改写成：

• "退款政策 七天 原因"
• "退款期限 设定 依据"
• "退款 七天 背景"

然后用这几个改写后的查询分别去检索，把结果合并。这样做的逻辑是：虽然知识库里没有直接写"为什么"，但可能写了"设定依据""背景说明"这类内容，用这些词去检索，命中率会更高。

查询改写可以用大模型来做，也可以预设一些模板。模板的好处是稳定、可控，坏处是覆盖不全。用大模型的好处是灵活，坏处是有时候会改得偏离原意。

我的做法是：先用模板做一轮，如果召回结果不理想，再用大模型做一轮。两轮结果合并。

4.5 方案五：在生成环节让模型"承认不知道"

前面四个方案都是在检索端做文章。但有时候，即使你做了所有能做的，检索回来的内容里还是没有"为什么"。这时候，最后一道防线是生成端的大模型。

你需要通过 prompt 告诉模型：如果材料里没有解释原因，就直接说"现有资料中没有说明原因"，不要自己编。

这个 prompt 大概长这样：

你是一个知识库问答助手。请基于以下材料回答用户问题。 规则： 1. 如果材料中明确包含问题的答案，直接回答。 2. 如果材料中只有结论没有原因，而用户问的是原因，请回答"现有资料中未说明原因"，并列出材料中与问题相关的结论性内容。 3. 不要基于材料之外的知识进行推测或编造。 材料： {context} 用户问题：{question}

这个方案不能让你"回答"为什么，但能让你"不错误地回答"为什么。在很多场景下，说"我不知道"比编一个答案要好得多。

5. 一个完整的排查流程：从提问到定位

5.1 第一步：确认知识库里有没有"为什么"

这是排查的起点。不要一上来就调参数、换模型，先确认数据里到底有没有你要的信息。

具体做法：把你认为可能包含原因的那份原始文档找出来，用肉眼读一遍，看里面有没有"因为""由于""考虑到""背景是"这类表述。如果没有，那就是数据缺失，后面所有工程手段都是白搭。

我踩过这个坑。有一次花了整整两天调检索参数，最后发现原始文档里压根没写原因。那两天纯属浪费。

5.2 第二步：检查切块是否切断了因果链

如果数据里有原因，那就检查切块。把检索命中的块和它前后的块都打印出来，看看原因是不是被切到了相邻的块里。

这个检查很简单，写个脚本把每个块的边界和内容打出来，人工扫一遍。重点看那些包含"因为""由于"的句子，看它们和前面的结论句是不是在同一个块里。

5.3 第三步：测试不同查询的召回效果

用不同的问法去测同一个问题，看召回结果有什么变化。

比如：

• "为什么退款政策是七天"
• "退款政策七天的原因"
• "退款期限设定依据"
• "退款 七天 背景"

如果某些问法能召回原因，某些不能，那说明是查询表述的问题，可以通过查询改写来缓解。如果所有问法都召回不了，那可能是 embedding 模型的问题，或者数据本身的问题。

5.4 第四步：对比纯向量和混合检索的效果

把纯向量检索和混合检索的结果并排对比，看关键词检索能不能补上向量检索漏掉的内容。

这个对比最好用一批测试问题来做，不要只看一两个案例。我一般会准备 20 到 30 个"为什么"类问题，跑一遍两种检索方式，统计召回率。

5.5 第五步：检查生成端的 prompt

最后检查大模型的 prompt，看它有没有被指示"不要编造"。如果 prompt 里没有这条规则，模型很可能会在材料不足的情况下自己编一个看起来合理的答案。这种答案比"我不知道"更危险，因为它会误导用户。

5.6 排查流程速查表

步骤	检查内容	判断标准	对应措施
1	原始文档是否有原因	有"因为/由于/背景"等表述	无则补数据
2	切块是否切断因果	结论和原因在同一块	否则调切块策略
3	不同问法召回对比	至少一种问法能召回	否则做查询改写
4	纯向量 vs 混合检索	混合检索召回率更高	否则上混合检索
5	生成端 prompt	有"不要编造"规则	无则加规则

这张表我贴在工位上，每次遇到"为什么"类问题答不好，就按这个顺序过一遍。大部分问题在前三步就能定位。

6. 几个容易踩的坑和我的实操心得

6.1 不要指望换 embedding 模型能解决因果问题

我见过不少团队，遇到检索效果不好就换 embedding 模型。从某个通用模型换到另一个，再换到某个领域微调模型。换了一圈，发现"为什么"类问题还是答不好。

原因很简单：embedding 模型的训练目标是"语义相似度"，不是"因果关联度"。再好的 embedding 模型，也不会把"为什么"和"因为"映射到同一个区域，除非训练数据里大量出现了这种配对。

所以，换模型可以提升"同义替换"的召回率，但解决不了"因果推理"的问题。这是两个不同维度的事。

6.2 切块大小不是越小越好

很多人觉得块切得越小，检索越精准。这话对"是什么"类问题成立，对"为什么"类问题恰恰相反。

块越小，因果关系被切断的概率越大。一个完整的因果链条可能需要 200 字才能说清楚，你切成 100 字的块，必然断链。

我的经验是：对于包含解释性内容的文档，块大小不要低于 300 字。如果文档本身写得很紧凑，可以适当放宽到 500 字。

6.3 关键词检索不是万能的，但没有它万万不能

混合检索里，关键词检索的角色是"兜底"。它不追求高精度，追求的是"不漏"。

向量检索漏掉的内容，关键词检索有机会补上。尤其是那些包含"因为""由于""原因""背景"的文档，关键词检索能直接命中。

但关键词检索也有它的局限：它不理解语义，只能做字面匹配。用户问"为啥"，它可能匹配不到"为什么"。所以查询改写还是要做。

6.4 让模型说"不知道"比让它编答案更重要

这一点我在多个项目里反复强调。用户问"为什么"，如果知识库里没有答案，模型编一个看起来合理的解释，用户信了，然后按照这个错误的解释去做决策——这个后果比"我不知道"严重得多。

所以在 prompt 里一定要加"不要编造"的规则。如果业务场景允许，还可以在回答里加上"建议咨询相关业务方"之类的引导。

6.5 因果类问题的评测集要单独建

大部分团队的 RAG 评测集都是"是什么"类问题，比如"退款政策是什么""怎么申请退款"。这些问题的评测指标不能反映"为什么"类问题的表现。

你需要单独建一个"为什么"类问题的评测集。每个问题都要标注：知识库里有没有答案、答案在哪个文档里、正确的召回结果应该是什么。然后单独统计这类问题的召回率和准确率。

这个评测集不用很大，20 到 50 个问题就够用了。关键是覆盖不同类型的"为什么"——有的是数据缺失，有的是切块问题，有的是语义距离问题。

7. 向量库的边界在哪里

7.1 它擅长什么，不擅长什么

把向量库的能力边界画清楚，对做 RAG 应用很重要。

它擅长的：

• 语义相似的内容召回。你问"退款"，它能找到"退货""返还"。
• 模糊匹配。你记不清具体措辞，它能凭大概意思找到相关内容。
• 跨语言检索。中英文混合的知识库，它能跨语言召回。

它不擅长的：

• 因果推理。它找不到"为什么"，除非"为什么"的答案以相似度高的形式存在于某个块里。
• 多跳推理。A 导致 B，B 导致 C，你问 A 和 C 的关系，它很难把中间那跳补上。
• 否定和排除。你问"除了七天还有哪些期限"，它可能把"七天"也召回回来。
• 数值比较。你问"哪个方案成本最低"，它不理解"最低"是什么意思。

7.2 什么时候该用向量库，什么时候不该用

向量库适合"找相关内容"的场景，不适合"做推理"的场景。

如果你的需求是"帮我在一堆文档里找到和这个问题相关的段落"，向量库是合适的。

如果你的需求是"帮我分析这些文档之间的逻辑关系"，向量库就不够了。你需要的是知识图谱、规则引擎、或者大模型的推理能力。

很多团队把这两个需求混在一起，用向量库去做推理，结果就是"为什么"类问题答不好。

7.3 一个务实的定位

我的建议是：把向量库定位成"召回层"，不要指望它做"推理层"。

召回层负责找到可能相关的内容，推理层负责从这些内容里推导出答案。推理层可以是大模型，可以是规则引擎，可以是人工。但不管是什么，它和召回层是两回事。

把这两层分开设计、分开优化、分开评测，很多问题会变得清晰。你不会再纠结"为什么向量库答不了为什么"，因为你知道那不是它的活。

8. 如果重新做一次，我会怎么设计

8.1 数据层：结论和原因成对存储

如果让我重新设计一个知识库，我会要求所有结论性内容都必须配一段"原因说明"。这两部分存在同一个块里，检索的时候一起召回。

格式上，可以用结构化的方式：

{ "conclusion": "退款期限为七天", "reason": "行业通行做法为七天；物流往返平均五天；支付通道结算周期 T+1 到 T+3", "source": "产品设计文档 v2.3", "owner": "产品部" }

这样存储的好处是，检索的时候可以针对 conclusion 和 reason 分别建索引，也可以合并建索引。查询"为什么"的时候，优先匹配 reason 字段。

8.2 检索层：向量 + 关键词 + 查询改写三件套

检索层不要只用向量。向量 + 关键词的混合检索是标配，查询改写是加分项。

查询改写的逻辑可以做成一个 pipeline：

1. 判断问题类型。如果是"为什么"类问题，触发改写。
2. 用模板生成多个子查询。
3. 分别检索，合并结果。
4. 重排序，取 top K。

这个 pipeline 不需要很复杂，但要有。没有它，"为什么"类问题的召回率会明显偏低。

8.3 生成层：严格的"不编造"约束

生成层的 prompt 要明确告诉模型：只基于给定材料回答，材料里没有的就说不确定。

同时，可以在生成结果里加上"信息来源"的标注。用户看到答案的同时，也能看到这个答案是从哪份文档里来的。这样即使答案不完整，用户也知道去哪里找更多信息。

8.4 评测层：分类型评测

评测集要按问题类型分开建。"是什么"类问题一套，"为什么"类问题一套，"怎么做"类问题一套。每套单独统计指标。

这样才能准确反映系统在不同类型问题上的表现，也才能有针对性地优化。

9. 最后分享几个小技巧

第一个技巧：在文档里显式地写"为什么"。很多写文档的人觉得原因不言自明，就不写了。但对检索系统来说，不写就等于不存在。所以我在团队里推了一个规矩：任何结论性描述，后面必须跟一句"原因/背景/依据"。这句话可能看起来冗余，但对检索效果提升很大。

第二个技巧：用"问答对"的形式补充数据。如果原始文档里没有原因，可以人工整理一批"为什么"的问答对，直接灌进知识库。这些问答对的 embedding 和用户的提问方式更接近，召回率更高。

第三个技巧：给"为什么"类问题单独设一个检索策略。比如提高关键词检索的权重，或者强制触发查询改写。不要和"是什么"类问题用同一套策略。

第四个技巧：定期 review 检索日志。看看用户都在问哪些"为什么"类问题，哪些答得好，哪些答不好。答不好的，回到数据层去看是不是缺内容。这个 review 我一般每个月做一次，每次都能发现几个可以补的数据缺口。

这几个技巧都不复杂，但坚持做下来，效果是实打实的。向量库答不了"为什么"这件事，短期内不会有根本性的改变，但通过数据、检索、生成、评测四个层面的配合，我们可以让它"答不了的时候说答不了"，而不是"答不了还硬答"。这个区别，在实际业务里就是靠谱和不靠谱的区别。