错误答案 vs 正确答案：RAG 系统设计

一句话总结

RAG系统的核心竞争力不是检索的召回率，而是对噪声的过滤能力。大多数人的错误判断是试图通过增加数据量来提升效果，而正确判断是通过精细化切片和重排来降低干扰。成功的RAG设计不是在构建一个知识库，而是在构建一个精准的上下文过滤器。

适合谁看

这篇文章只写给那些正在设计企业级AI产品、被困在评估指标陷阱中、或者准备冲击硅谷大厂AI PM职位的研发人员和产品负责人。如果你还在纠结用哪个向量数据库，或者试图通过微调模型来解决幻觉问题，这篇文章能帮你停止在错误方向上的资源浪费。

为什么大多数RAG系统在Demo后就死了？

大多数团队在做RAG时的思维误区在于，他们把RAG当成一个搜索问题，而不是一个信息压缩问题。在早期的Demo阶段，输入一个简单问题，系统召回三段相关的文本，LLM能给出正确答案，这给了很多PM一种错觉：系统已经跑通了。但当进入生产环境，面对海量非结构化文档时，系统会迅速崩溃。

一个典型的错误场景是在debrief会议上，工程师会说：我们已经把召回率提升到了95%，但用户依然反馈答案不准确。这时，产品负责人的错误判断通常是：我们需要更强的Embedding模型。而正确的判断是：召回率越高，噪声越多，LLM在面对大量无关但看似相关的片段时，注意力会被稀释，从而产生幻觉。

RAG的本质不是A（增加信息的覆盖面），而是B（减少干扰信息的占比）。在硅谷的实际工程实践中，一个能够稳定交付的系统，其逻辑不是追求把所有相关文档都塞进上下文，而是通过一个极高标准的Rerank（重排）机制，将100个召回片段精简到3个最高质量片段。这意味着，RAG的瓶颈不在于向量检索的效率，而在于对上下文相关性的裁决能力。

如果你在设计文档中写的是提高Recall，那么你大概率在走死胡同；如果你写的是优化Precision，你才在做正确的事。

> 📖 延伸阅读：ServiceNow产品经理行为面试STAR回答范例2026

为什么Chunking（切片）决定了系统的生死？

大多数人在处理数据清洗时，习惯使用固定长度切片（Fixed-size Chunking），比如每512个token切一段，并设置10%的重叠度。这种做法的逻辑是基于工程的便利，而非基于知识的结构。这种错误判断会导致一个致命结果：一个核心结论被切断在两个片段中，导致模型在检索时只能拿到一半的逻辑，最终输出一个似是而非的答案。

正确的判断是：切片策略必须基于文档的语义结构，而不是字符数。这意味着你不能使用简单的分割函数，而应该使用基于Markdown标题或语义边界的递归切片。

在实际的hiring committee讨论中，一个资深PM会向候选人追问：如果你的文档中包含复杂的表格和层级标题，你如何确保检索回来的片段包含完整的上下文？如果候选人回答是增加Overlap（重叠度），这通常是一个负面信号。

正确的答案是构建一个父子索引结构（Parent-Document Retrieval）。检索时使用小的子片段（Child Chunk）来保证匹配的精准度，但喂给LLM的是包含该子片段的完整父片段（Parent Chunk）。

这种设计实现了不是A（用单一粒度覆盖所有场景），而是B（用检索粒度保证精度，用生成粒度保证完整性）。一个成熟的RAG系统，其切片策略应该是根据文档类型定制的：法律合同需要按条款切，技术手册需要按步骤切，而营销文案则可以按段落切。

检索阶段的真伪命题：向量检索足够吗？

很多团队在设计架构时，会对向量检索（Vector Search）产生过度依赖。他们认为只要Embedding模型足够强，语义搜索就能解决所有问题。这在处理模糊概念时有效，但在处理特定术语或唯一标识符时极其低效。例如，当用户搜索一个具体的订单号或特定的产品型号时，向量检索可能会召回一个语义相近但完全无关的型号。

一个资深架构师在设计方案时会明确指出：纯向量检索是错误的，正确的判断是必须采用混合检索（Hybrid Search）。这意味着你必须同时运行向量检索（处理语义）和BM25关键词检索（处理精确匹配），然后通过RRF（Reciprocal Rank Fusion）算法进行加权融合。

这种设计逻辑不是A（选择一种最强的检索方式），而是B（用互补的检索方式覆盖所有检索意图）。

在实际的生产环境中，一个高可用RAG系统的检索流应该是：Query $\rightarrow$ Query Expansion（查询扩展） $\rightarrow$ Hybrid Search $\rightarrow$ Reranking $\rightarrow$ LLM。其中最关键的环节是Reranking。

向量检索只能告诉你哪些片段在空间上靠近，而Rerank模型（如Cohere Rerank）能告诉你哪些片段真正能回答问题。如果你的架构中没有Rerank这一环，你的系统在面对复杂查询时，其准确率会比有Rerank的系统低至少30%。

> 📖 延伸阅读：Betterment产品经理行为面试STAR回答范例2026

如何定义RAG的评估指标？不要被整体准确率欺骗

很多PM在汇报时会说：我们的系统在测试集上的准确率达到了80%。这是一个极其危险的信号，因为它掩盖了最核心的问题：模型是在哪个环节出错的？是检索没找到（Retrieval Failure），还是找到了但模型没总结对（Generation Failure）？

正确的评估框架必须是解耦的。你需要分别衡量：

  1. Context Precision（上下文精准度）：检索回来的东西里，有多少是真正有用的？
  2. Context Recall（上下文召回率）：所有能回答问题的片段，被检索出来了多少？
  3. Faithfulness（忠实度）：答案是否完全来自检索到的上下文，有没有凭空捏造？
  4. Answer Relevance（答案相关性）：答案是否直接回答了用户的问题？

在内部的debrief会议中，我们最关注的是Faithfulness。如果一个系统Recall很高但Faithfulness低，这意味着模型在用自己的预训练知识覆盖检索结果，这会导致严重的合规风险。正确的判断是：宁可让模型回答我不知道，也不允许它在检索结果之外进行推演。这种裁决逻辑将RAG从一个聊天机器人转变为一个可靠的知识检索工具。

评估不是为了给出一个分数，而是为了定位故障点。如果Precision低，就去优化Embedding或增加Rerank；如果Faithfulness低，就去优化Prompt或调整Temperature。

硅谷AI PM的面试实战与职级对齐

在硅谷大厂（如Google, OpenAI, Meta）的AI PM面试中，RAG设计是考察核心能力的高频考点。面试官并不在乎你是否知道RAG这个词，他们在乎的是你对权衡（Trade-off）的掌控力。

面试流程通常分为四轮：

第一轮：产品定义（45min）。重点考察如何定义Success Metric。错误回答是说提高用户满意度，正确回答是定义上述的四维度评估指标，并量化每个指标的阈值。

第二轮：系统设计（60min）。重点考察端到端流程。考察点在于你是否意识到Query的噪声问题。正确判断是引入Query Rewrite（查询重写）步骤，将用户的口语化提问转化为适合检索的关键词。

第三轮：执行与迭代（45min）。重点考察如何处理Bad Cases。正确判断是建立一个Bad Case库，通过对比不同Chunking策略的输出结果进行A/B Test，而不是盲目升级模型。

第四轮：跨部门协作（45min）。重点考察如何与算法工程师沟通。考察点在于你是否能将产品需求转化为具体的算法指标（例如：将准确率提升5%转化为将Rerank的Top-3 Precision提升到0.8）。

对于一个L5/L6级别的AI PM，其薪资结构通常为：Base $180K - $240K，RSU $200K - $500K/year，Bonus $30K - $60K。在这个职级，你被要求做出的判断不再是功能实现，而是资源分配。

例如，在决定是花三个月时间微调一个领域模型，还是花两周时间优化Rerank管线时，正确的判断通常是后者，因为RAG的边际收益在数据质量优化上远高于模型微调。

准备清单

  1. 建立一个包含100个典型Bad Case的黄金数据集，覆盖检索失败和生成失败两种场景。
  2. 重新审查切片策略，将Fixed-size Chunking替换为基于语义结构的递归切片。
  3. 在检索管线中强制加入Rerank环节，并对比引入前后的Precision提升数据。
  4. 设计一套解耦的评估指标体系，分别监控Context Precision和Faithfulness。
  5. 实施Query Rewrite机制，将模糊查询转化为结构化检索词。
  6. 系统性拆解面试结构（PM面试手册里有完整的RAG系统设计实战复盘可以参考）。
  7. 定义严格的拒答机制，当检索得分低于阈值时，直接输出我无法在文档中找到答案。

常见错误

案例一：过度依赖向量检索

BAD: 用户输入订单号，系统通过向量检索召回了三个相似订单的描述，LLM根据这些描述给出了错误的订单状态。

GOOD: 引入混合检索。订单号命中关键词检索 $\rightarrow$ 精确匹配到唯一文档 $\rightarrow$ LLM输出正确状态。

判断：不是所有查询都需要语义理解，精确匹配在企业级场景中优先级更高。

案例二：盲目增加上下文长度

BAD: 为了防止信息丢失，将Top-20个片段全部喂给LLM，导致模型在长文本中迷失（Lost in the Middle），忽略了中间的关键信息。

GOOD: 使用Rerank将Top-20精简为Top-3，确保每个片段都是高相关度，降低模型处理噪声的压力。

判断：不是上下文越多越好，而是信息密度越高越好。

案例三：试图通过Prompt解决幻觉

BAD: 在Prompt中写大量指令要求模型不要胡说八道，结果模型变得极其保守，即使答案在文档中也回答不知道。

GOOD: 优化数据清洗和切片质量，确保输入给模型的Context是纯净且完整的，并在Prompt中规定答案必须引用文档原句。

判断：幻觉问题的根源不是Prompt写得不好，而是输入的数据质量太差。

FAQ

Q: RAG和微调（Fine-tuning）哪个更优先？

A: 在知识更新频率高、对准确率要求极高的场景下，RAG绝对优先。微调是改变模型的行为模式（怎么说话），而RAG是提供外部知识（说什么）。如果你想让模型学会某种特定的专业语气，用微调；

如果你想让模型回答最新的产品文档，用RAG。在大多数企业场景中，先构建一个高性能RAG系统，其投资回报率远高于微调。例如，在法律咨询产品中，法律条文的实时更新决定了必须用RAG，而微调只能让模型看起来像个律师。

Q: 向量数据库的选择会对最终效果产生决定性影响吗？

A: 几乎没有。大多数人过度关注Pinecone, Milvus或Weaviate的性能差异，但这在实际业务中是次要的。决定效果的是Embedding模型的质量、切片策略和Rerank算法。

在实际的生产环境下，检索延迟的瓶颈通常在网络传输和LLM生成速度，而非向量数据库的查询速度。正确的判断是：不要在数据库选型上浪费超过一周的时间，而应该把时间花在构建评估集上。

Q: 如何处理文档中相互矛盾的信息？

A: 这是一个典型的冲突解决问题。正确的处理方式不是让LLM自行判断，而是在检索阶段引入元数据过滤（Metadata Filtering）。为文档增加版本号、时间戳或权重标签。

在检索时，优先召回最新版本或权重最高的文档。如果依然存在矛盾，正确的设计是让模型在答案中明确指出：文档A认为X，而文档B认为Y，请用户确认。这不是一个技术问题，而是一个产品信任问题，诚实比伪造的统一答案更重要。

准备好系统化备战PM面试了吗？

获取完整面试准备系统 →

也可在 Gumroad 获取完整手册。

相关阅读