AI产品经理面试题-RAG篇
什么是RAG？它解决了大模型的哪些痛点？
RAG 是“检索增强生成”，简单说就是让大模型在回答前，先去外部知识库里检索相关资料，再结合资料生成答案。
它主要解决大模型三类痛点：第一是知识不够新，模型参数里的知识可能过时；第二是容易幻觉，模型会一本正经地编；第三是垂直场景不够准，像企业内部知识、售后规则、业务文档这类内容，大模型不一定天然知道。
所以 RAG 的价值就是把“会说话的大模型”变成“有依据、可更新、可追溯的大模型”。
在什么业务场景下，你会优先选择 RAG 而不是直接微调大模型或纯提示词工程？
我会优先选 RAG 的场景，一般有三个特征：
第一，知识更新快，比如政策、商品信息、售后规则。
第二，需要基于企业内部资料回答，而不是通用知识。
第三，要求可追溯、可解释，比如客服、法务、企业知识库。
纯提示词工程更适合做轻量优化，比如把输出格式调清楚；微调更适合让模型学会稳定的表达方式、固定任务风格，或者某种分类能力。
但如果核心问题是“知识从哪来”，那通常还是 RAG 更合适。
设计一个 RAG 功能时，你如何定义用户场景和核心需求？请以一个具体场景（如售后问答）为例说明。
我会先把场景拆成三件事：用户是谁、他想解决什么、为什么现在的方式不够好。
比如售后问答场景里，用户可能是买家，核心需求其实不是“问一句话”，而是快速得到一个准确、可执行、能解决问题的答案。
比如他可能问：“这个商品怎么退货？” “发票怎么开？” “保修期怎么算？”
我会先明确 RAG 在这个场景里要解决的不是聊天，而是三个目标：
第一，回答准确，不能乱编。
第二，回答够具体，最好能结合平台规则和商品信息。
第三，回答能落地，比如直接给操作步骤、入口链接、注意事项。
所以设计时我不会只看“能不能答”，而是会问：
用户答完之后，问题有没有被真正解决？需不需要再找人工？这才是核心需求。
如何设计知识库的结构和内容管理机制？如果文档中 30% 是过时信息，你的更新策略是什么？
知识库我一般会按 层级化 + 标签化 + 可追溯 来设计。
结构上会分几层，比如：
•
一级：业务域，比如售后、支付、物流
•
二级：具体主题，比如退货、开票、保修
•
三级：具体文档、规则、FAQ、案例
同时一定要加元数据，比如：生效时间、失效时间、来源部门、适用范围、权限级别
如果文档里有 30% 是过时信息，我不会直接全量重建，而是先做三步：
第一，识别高风险内容，比如政策类、价格类、规则类，这些过期影响最大。
第二，按优先级分批更新，先更新高频、高风险文档。
第三，建立版本机制，旧内容不要直接删掉，而是标记失效，避免历史检索混进来。
如果产品视角再说一句，就是：
知识库不是“存文档”，而是“管理可用知识”。更新策略的重点不是快，而是 准确、可控、可回溯。
当用户反馈“AI 回答感觉不对”但说不出具体问题，你会用怎样的流程快速定位是检索偏差、生成幻觉，还是知识本身冲突？
我会先把这个问题拆成一个排查链路。
第一步，先看用户到底问了什么，以及模型最后用了哪些知识。
第二步，检查检索出来的内容是不是相关。
第三步，检查模型有没有脱离检索内容自己补东西。
第四步，再看知识库本身是不是有冲突，或者版本不一致。
我一般会这样判断：
•
如果检索出来的内容就不对，那大概率是检索偏差；
•
如果检索是对的，但模型回答时自己发挥了，那就是生成幻觉；
•
如果检索到了两份相互冲突的资料，那可能是知识本身有冲突或版本问题。
作为产品经理，我不会直接去追算法细节，而是先通过日志、case 回放、用户输入、检索结果、最终输出这条链路，把问题定位到具体环节。
如果定位到是检索问题，你会如何拆解是 chunk 切分不当、embedding 质量差、还是排序策略失败？请给出产品侧的排查工具设计思路。
我会把检索问题分成三层来看：
第一层是 分块问题。
如果 chunk 切得太碎，语义不完整；切得太大，又容易掺噪声。
第二层是 向量表示问题。
如果 embedding 没把语义表达好，相关内容也可能召不回来。
第三层是 排序问题。
即使召回到了，排在前面的不一定是最相关的，最后还是会影响答案。
产品侧我会设计一套排查工具，至少包含这几个能力：
•
可以看用户问题对应召回了哪些 chunk
•
可以看到每个 chunk 的来源、命中分数、更新时间
•
可以对比“召回结果”和“最终答案”是否一致
•
可以人工标记：这个结果是切分问题、召回问题，还是排序问题
这样产品、算法、后端就能在同一套工具里看问题，而不是靠口头沟通猜原因。
设计一个 RAG 产品的离线 + 在线效果评估体系，你会看哪些核心指标？如何避免“指标好看但用户觉得不好用”？
我会把评估分成两部分：离线看能力，在线看体验。
离线指标主要看：检索命中率、召回率、topK 相关性、答案事实一致性、幻觉率
在线指标主要看：使用率、追问率、采纳率、一次解决率、用户满意度、转人工率
避免“指标好看但不好用”，关键是别只看模型分数。
因为模型分数高，不代表用户真的满意。比如答案虽然准确，但太长、太绕、太像机器，也可能不好用。
所以我会加一层 真实用户行为指标，比如：
•
用户有没有继续追问
•
有没有复制答案
•
有没有点“有帮助”
•
有没有最终完成任务
我觉得 AI 产品评价最怕“实验室很好，用户现场不好”，所以一定要把离线和在线结合起来看。
你认为 RAG 产品从0到1最容易踩的三个坑是什么？请按影响程度排序，并给出产品侧的规避措施。
我觉得最容易踩的三个坑，我会这样排：
第一，知识源不干净。
这是影响最大的。知识库本身如果乱，后面怎么调都很难好。
规避方式：先做知识治理，保证来源、版本、权限、时效都清楚。
第二，场景定义太泛。
很多项目一开始想做“万能问答”，结果什么都答，什么都答不好。
规避方式：先做高频、强需求、低风险场景，集中打穿一个场景。
第三，只看模型效果，不看用户体验。
模型回答可能正确，但用户还是觉得不好用。
规避方式：把交互、答案格式、引用展示、追问机制一起设计进去。
要实现 RAG 的持续迭代，你会重点运营哪些数据（如负反馈、检索失败case）？如何设计数据闭环机制？
我会重点运营四类数据：
第一，负反馈数据，比如“不准确”“没解决问题”“答非所问”。
第二，检索失败 case，就是没召回到正确知识。
第三，高频问题，看哪些问题用户最常问。
第四，追问路径，看用户在哪一步继续问，说明哪里没讲清楚。
闭环机制上，我会做成一个固定流程：
用户反馈收集 → case 归类 → 原因标注 → 优先级排序 → 推动知识/检索/生成优化 → 回看效果。
重点不是收数据，而是让数据真的流进迭代流程里。
否则数据看了很多，产品还是不会变。
从产品视角，将一个 RAG 能力从 Demo 推到规模化上线（日活 10 万+），你认为最关键的三件事是什么？
我觉得最关键的三件事是：
第一，知识体系要稳定。
规模化上线后，最怕知识不一致、更新不及时、版本混乱，所以知识治理必须先做好。
第二，效果要可观测。
上线不是结束，是开始。必须能看日志、看指标、看失败 case，知道问题出在哪。
第三，要控制成本和风险。
日活上来后，算力、延迟、调用成本、合规风险都会变成现实问题。
所以要考虑缓存、限流、灰度、降级和权限控制。
如果一句话总结，我会说：
Demo 解决“能不能用”，规模化解决“能不能稳、能不能省、能不能持续迭代”。