本轮 AI 产品经理面试题库（带答案）
生成时间：2026-05-22 22:37
【面试题】1. 请解释RAG技术的基本原理，以及为什么纯大模型无法替代RAG？
【标准答案】RAG的核心思路是"检索增强生成"，分三步走：第一步，把知识库文档切成片段，通过Embedding模型转成向量存进向量库；第二步，用户提问时，同样把问题转成向量，在向量库里做相似度检索，召回最相关的文档片段；第三步，把这些片段作为上下文拼进Prompt，让大模型基于检索到的内容生成回答。
为什么纯大模型替代不了？三个关键原因：第一，大模型的知识有训练截止日期，无法获取最新信息，而RAG可以实时检索更新；第二，大模型会"幻觉"，在专业领域容易编造答案，RAG通过提供事实依据大幅降低幻觉率；第三，企业私有数据大模型没见过，RAG能让模型访问内部知识库，实现知识可控。简单说，大模型是"脑子"，RAG是给脑子装了"搜索引擎"，两者配合才是完整方案。
【面试题】2. 你负责一个AI客服产品，用户反馈"回答经常跑题"，你怎么排查和优化？
【标准答案】我会分三层排查：
第一层，看Prompt设计。检查系统提示词有没有明确角色定位和回答边界，很多跑题是因为提示词太宽泛，模型不知道该聚焦什么。加上"仅基于以下知识回答，不确定时说不知道"这类约束。
第二层，看检索质量。跑一批用户问题，看召回的文档片段是否相关。常见问题是：文档切片太大导致噪声多、Embedding模型对业务术语理解差、没有做Query改写导致用户口语化提问检索不到。对应的优化方案是：调小切片粒度、换更强的Embedding模型或做微调、加Query改写模块。
第三层，看生成阶段。检索内容是对的但回答还是跑题，说明模型没遵守上下文，需要在Prompt里强化引用要求，或者调低temperature减少发散。
最后，建立评估闭环：标注一批case作为测试集，每次优化后跑评测看跑题率变化，用数据驱动迭代。
【面试题】3. 什么是Prompt Engineering？请举例说明你在产品中如何应用提示词工程提升效果。
【标准答案】Prompt Engineering就是通过设计和优化输入提示词，让大模型输出更符合预期结果的技术。它不是"写一句话"那么简单，而是一套系统方法。
我在产品中的应用有三个层面：第一，角色设定。比如做AI写作助手，提示词里明确"你是一位10年经验的科技领域编辑"，比单纯说"帮我写"输出质量高很多。第二，Few-shot示例。在提示词里放2-3个标准问答样例，模型就能理解输出格式和风格要求，比写一堆描述性规则更直接有效。第三，思维链引导。对于复杂推理任务，加"请一步步思考"，让模型展示中间推理过程，准确率能提升20-30%。
产品层面要注意的是：提示词不能只在实验室调优，要建立版本管理，做A/B测试看不同提示词在真实用户场景下的效果差异，用数据选择最优版本。提示词是AI产品的"隐性代码"，必须像管理代码一样管理提示词。
【面试题】4. 请从0到1描述一个AI功能的落地流程，结合你做过的项目说明。
【标准答案】我以之前做的"智能简历筛选"功能为例，分五步走：
第一步，需求定义。跟HR团队深度访谈，明确痛点：每天收500+简历，人工初筛耗时4小时，核心需求是自动标注匹配度。定义MVP目标：Top20%简历识别准确率>85%。
第二步，方案设计。不是直接上大模型，而是拆解为：简历解析（结构化提取）+ 岗位画像生成（JD关键词提取）+ 匹配打分（向量相似度+规则加权）。技术选型上，解析用GPT-4做Few-shot抽取，匹配用Embedding向量+余弦相似度。
第三步，原型验证。先拿200份历史简历做离线测试，跟HR标注结果对比，准确率78%，没达目标。分析发现"软技能"匹配判断差，加了规则引擎补充，准确率提到87%。
第四步，灰度上线。先在3个岗位开放，HR可覆盖AI结果，收集反馈。两周后发现误判集中在跨行业简历，优化了岗位画像的泛化表达。
第五步，全量推广+数据监控。上线看板监控匹配准确率、HR覆盖率、筛选耗时，从4小时降到40分钟，HR覆盖率稳定在12%以下。
核心心得：AI产品0到1的关键是"先窄后宽"，选一个最痛的点做透，而不是一上来就想做全流程自动化。
【面试题】5. 向量数据库和传统数据库有什么区别？产品经理为什么需要了解向量库？
【标准答案】核心区别在于检索方式不同：传统数据库是精确匹配，你查"价格>100"就返回精确结果；向量数据库是相似度匹配，你查一段语义，它返回"意思最接近"的结果。
技术上，向量库存的是高维向量（比如1536维的Embedding），检索用的是余弦相似度、ANN近似最近邻这类算法，适合模糊匹配和语义搜索。传统库存的是结构化数据，检索用B树索引，适合精确查询。
产品经理必须了解向量库，原因有三：第一，它直接影响RAG效果——向量库选型、索引算法、维度设定都影响召回率和延迟，这些是你做技术方案评审时必须能判断的。第二，它影响成本结构——向量库的存储成本和检索成本跟传统库完全不同，你需要据此做ROI测算。第三，它决定产品边界——比如FAISS是内存级方案，适合小规模快速验证；Milvus/Pinecone支持分布式，适合生产级大规模部署。产品经理要知道什么阶段用什么方案，而不是被技术牵着走。
【面试题】6. 面试官问：你如何判断一个功能该不该用AI？什么场景不适合用AI？
【标准答案】我有一个判断框架，三个维度：
第一，任务是否有"标准答案"？如果有确定性的正确答案且规则明确，比如价格计算、库存查询，传统规则引擎更可靠更高效，没必要用AI。AI适合的是没有唯一标准答案、需要理解和生成的场景，比如内容创作、意图理解。
第二，容错空间有多大？AI本质上是非确定性的，同样的输入可能产出不同结果。如果错误成本很高，比如医疗诊断、法律判案，AI只能做辅助不能做决策。容错空间大的场景，比如推荐、草稿生成，AI就很合适。
第三，数据是否充分？AI效果依赖数据，如果训练数据或上下文不足，硬上AI反而比规则差。比如一个新业务没有历史数据积累，做个性化推荐就不现实。
总结一句话：AI用在"需要理解+容错可控+数据支撑"的场景，避开"确定性要求高+错误成本大+数据不足"的场景。产品经理的价值不是追AI，而是在对的场景用AI。
【面试题】7. 你如何做AI产品的竞品分析？跟传统产品竞品分析有什么不同？
【标准答案】传统竞品分析看的是功能矩阵、交互体验、运营数据，AI产品要多看三个维度：
第一，模型能力对比。不光看"有没有这个功能"，要看底层用的什么模型、效果差多少。比如同样做AI写作，A产品用GPT-4，B产品用开源7B模型，生成质量就有代差。要做横向评测：同一批输入，对比输出质量、延迟、成本。
第二，数据飞轮效应。AI产品有"越用越好"的特性，要看竞品用户量是否已经形成数据壁垒。比如竞品有百万级对话数据在持续优化模型，你从零开始，光靠提示词工程可能追不上。这时候要找差异化切入点，而不是正面硬刚。
第三，技术架构差异。看竞品是纯API调用还是自研模型，是通用方案还是行业垂直方案。通用方案易被复制，垂直方案有壁垒但市场窄。这些决定了你的产品定位策略。
实操上，我会做一张表：功能维度×技术维度×体验维度，每个竞品填完再做差异化定位。AI竞品分析的核心不是"他有什么我也要有什么"，而是"他做不到的我能不能做到，他做到的我能不能换条路做得更好"。
【面试题】8. 请解释大模型的"幻觉"问题，产品层面怎么应对？
【标准答案】大模型幻觉就是模型"一本正经地胡说八道"——生成的内容看起来很合理，但事实是错的。本质原因是：大模型是在做"下一个token的概率预测"，不是在做"事实检索"，所以当训练数据里没有相关事实时，模型会根据语言模式编造内容。
产品层面的应对，我分四层：第一层，源头控制——用RAG提供事实依据，让模型基于检索内容回答，减少编造空间。第二层，Prompt约束——在提示词里加"仅基于给定内容回答，不要编造信息，不确定时明确说不知道"。第三层，输出审核——对高敏感场景（如医疗、金融），加后置校验，用另一个模型或规则引擎检查输出的事实一致性。第四层，用户教育——在产品UI上明确标注"AI生成内容仅供参考"，降低用户对AI输出的绝对信任。
关键原则是：不追求零幻觉（做不到），而是把幻觉控制在可接受范围内，同时让用户知道边界在哪里。产品经理要做的是"管理预期"而不仅是"消灭幻觉"。
【面试题】9. 你负责的AI功能上线后，核心指标下降，你怎么做数据复盘？
【标准答案】我会按照"定界-归因-验证-修复"四步来做：
第一步，定界。先确认下降的幅度和时间点，是缓慢下滑还是断崖式下跌？是不是跟某次发版时间吻合？看是不是大盘问题还是特定场景问题。比如准确率从90%降到82%，是所有场景都降还是只有某类问题降？
第二步，归因。分几条线排查：数据线——训练数据有没有变化？新数据引入了噪声？模型线——有没有更换模型版本或调整参数？用户线——用户意图分布有没有变化？比如突然来了大量新类型的问题，原有方案覆盖不了。我做过一个案例，指标下降是因为运营推了一波新用户，他们的使用场景和老用户完全不同，模型没见过这类输入。
第三步，验证。定位到原因后，用历史数据回放验证。比如怀疑是某类问题导致的，单独筛出来看指标，确认归因正确。
第四步，修复。根据根因制定方案：数据问题就清洗数据，模型问题就微调或换版本，场景问题就加规则补充或扩展训练集。
复盘后必须沉淀：建立监控预警机制，指标波动超阈值自动告警，别等问题大了才发现。
【面试题】10. 面试官给你一个场景：公司要做AI辅助合同审查功能，目标用户是法务团队，你怎么设计MVP？
【标准答案】我的思路是"最小可用+最快验证"：
首先，明确核心价值。法务审查合同最痛的不是"看不懂"，而是"看得慢+容易漏"。所以MVP聚焦一个点：风险条款自动识别与标注，不做全文审查。
然后，定义MVP范围。输入：用户上传合同PDF；处理：AI识别风险条款并标注风险等级（高/中/低）；输出：风险条款清单+修改建议。不做：合同起草、条款自动修改、多合同对比——这些都是后续迭代。
技术方案上，分三步：第一步，合同解析，用OCR+大模型提取结构化条款；第二步，风险识别，构建风险条款知识库（常见风险点100+条），用RAG+大模型做匹配识别；第三步，建议生成，基于风险类型给出标准化修改建议。
关键设计决策：为什么不用纯大模型直接审？因为法务场景容错率极低，纯模型幻觉风险不可接受。用RAG+规则兜底，高风险条款必须命中知识库才报出，宁可漏报不误报，这是法务场景的产品原则。
MVP验证指标：风险条款召回率>80%、误报率<10%、单份合同审查时间从2小时降到15分钟。先找3位法务同事内测，确认可用后再扩大范围。