AI 产品经理面试题库
生成时间：2026-05-23 15:18 | 第59744c23轮
【面试题】1. RAG系统中chunk切分策略对召回质量有什么影响？你怎么确定最优切分方案？
【标准答案】chunk切分是RAG效果的第一道关，切不好后面全白搭。核心影响有三个：第一，chunk太大，检索时噪声多——一个chunk塞了五六个主题，embedding被稀释，查什么都是"中等相关"；chunk太小，语义断裂——一句话切两半，关键信息丢了上下文就理解不了。第二，切分粒度直接影响召回率和精确率的平衡——大chunk召回率高但精确率低（答案混在无关内容里），小chunk精确率高但召回率低（可能漏掉跨段的信息）。第三，不同业务的最优粒度不同，没有万能参数。我确定切分方案分三步：第一步，先按语义单元切——段落级优于固定token数，比如按标题/章节/条款切，保证每个chunk语义完整；第二步，做overlap处理——相邻chunk重叠10-20%的内容，避免跨chunk信息丢失；第三步，建立评估集，用业务真实query跑召回率测试，调整chunk大小和overlap直到命中率达到目标。实操中我见过最多的坑是"拍脑袋定512 token"，结果切得稀碎。正确做法是先分析你的文档结构，合同按条款、论文按章节、FAQ按问答对，结构化切分永远优于暴力定长切。
【面试题】2. 大模型的Function Calling（函数调用）机制是什么？产品经理怎么利用它设计AI功能？
【标准答案】Function Calling是大模型根据用户意图自动决定调用哪个外部工具的能力。模型本身不会执行函数，它输出的是"我想调哪个函数、传什么参数"，由你的代码层去执行并把结果返回给模型继续生成。产品价值在于三点：第一，突破模型的能力边界——模型不知道实时天气、查不了库存、下不了订单，但通过Function Calling可以让AI调用对应API完成这些操作。第二，提升可靠性——让模型输出结构化的JSON参数而非自由文本，比prompt硬压格式靠谱得多，因为Function Calling是模型原生支持的能力，不是靠提示词"骗"出来的。第三，产品设计上我用的策略是：先列出AI需要完成的动作（查数据、发通知、写数据库），每个动作封装成一个function描述，注册给模型。用户说"帮我订明天飞北京的机票"，模型识别意图后调用flight_search函数查航班，再把结果格式化呈现给用户。关键注意点：function描述要写清楚入参类型和含义，模糊的描述会导致模型传错参数；同时要设兜底——模型可能在不该调用时调用，需要代码层做校验拦截。
【面试题】3. AI产品的token成本怎么估算和优化？举一个实际项目的例子。
【标准答案】token成本是AI产品能否跑通商业模式的关键。估算方式：先算单次请求成本 = 输入token数×输入单价 + 输出token数×输出单价，再乘以日均请求量就是日成本。我做过一个AI文档摘要产品，GPT-4定价下，平均每篇文档输入8000 token、输出500 token，单次成本约0.15元，日活用户500人每人用3次，日成本225元，月成本6750元——这个数必须算清楚，否则上线就是亏钱。优化我分四层做：第一层，模型选择——不是所有场景都要GPT-4，简单分类和提取用GPT-4o-mini或国产模型，成本降90%以上，效果够用。第二层，prompt精简——砍掉prompt里的冗余描述和重复指令，输入token少了钱直接省。第三层，缓存策略——相同或相似的query做语义缓存，命中缓存直接返回不走模型，我们项目中缓存命中率做到35%，成本直接砍三分之一。第四层，输出控制——设定max_tokens上限，避免模型"话多"，摘要任务限制200 token输出就够了，别让它写小作文。核心原则：成本优化不是用最便宜的模型，而是让每个请求用最合适的模型，同时从全链路找省钱的机会。
【面试题】4. 什么是大模型的"上下文窗口"？产品设计中有哪些常见的坑？
【标准答案】上下文窗口（Context Window）就是模型一次能处理的最大token数，包括输入和输出。GPT-4是128K，Claude是200K，国产模型通常在8K到128K不等。常见坑有四个：第一，"窗口很大≠效果很好"——虽然窗口大到128K，但模型对中间位置的信息注意力显著下降（lost in the middle问题），你塞了10万字进去，模型未必真能"看到"所有内容。第二，窗口用满成本爆炸——输入token是按量计费的，10万字输入一次就好几块钱，高频场景下费用很恐怖。第三，多轮对话的窗口消耗是累积的——聊天历史、system prompt、检索内容、用户输入全占窗口，聊着聊着就溢出了，需要设计对话历史的裁剪策略（比如只保留最近5轮+摘要）。第四，产品设计上要主动管理窗口分配——我通常的分配策略是：system prompt占10-15%，RAG检索内容占30-40%，对话历史占20-30%，留30%给用户输入和模型输出。千万别让检索内容把窗口撑满，模型没空间"思考"了。
【面试题】5. 面试官问：你如何设计AI产品中的"人在回路"（Human-in-the-Loop）机制？
【标准答案】人在回路不是"AI不行就让人来"，而是一个系统性的产品设计策略。我按风险等级分三层设计：第一层，低风险场景——AI自动执行，人做抽检。比如AI生成营销文案，直接发布，运营同学每周抽检10%，看是否有质量问题，有问题再调优prompt。第二层，中风险场景——AI生成，人审核确认。比如AI生成客服回复，先给客服看一遍，确认后发送。关键是降低人的审核负担——设计上让审核动作极简（一键确认/修改），不要让审核变成"重新写一遍"。第三层，高风险场景——AI辅助，人决策。比如AI做医疗辅助诊断或金融风控，AI只出建议和依据，最终决策必须人来签。设计上的关键细节：一是审核时效——AI生成后多久必须有人处理，超时怎么办（自动降级还是转人工队列）；二是反馈闭环——人修改了AI的输出，这个修改数据要回流到模型优化中，否则人在回路只是挡问题，不是修问题；三是效率指标——审核通过率、平均审核时长、审核后修改率，这些指标告诉我们人在回路到底是在"审核"还是在"重写"，如果修改率超过50%说明AI质量根本不够，该优化模型而不是靠人兜底。
【面试题】6. Embedding模型在RAG中的作用是什么？选型时看哪些指标？
【标准答案】Embedding模型的作用是把文本转成向量，向量之间的距离代表语义相似度——距离越近越相关。在RAG里，它是检索质量的根基：用户的query被embedding成一个向量，再去向量库里找最近的文档向量，找回来的文档喂给大模型生成答案。如果embedding模型不行，检索回来的全是无关内容，后面模型再强也没用。选型我看四个维度：第一，embedding维度——768维、1024维、1536维，维度越高表达力越强但存储和计算成本也越高，不是越高越好。第二，领域适配——通用embedding模型（如text-embedding-3-small）在英文和通用领域表现好，但中文业务场景看bge-large-zh或M3E，差距可能很大。验证方法是用你的业务query+文档跑召回率对比，不要只看benchmark。第三，跨语言能力——如果你的产品需要中英混合检索，要选多语言模型，单语言模型会翻车。第四，吞吐和延迟——embedding要实时做（用户输入的query），如果模型推理太慢直接影响响应时间，一般要求单条query embedding在50ms以内。我的选型策略是：先跑一个离线召回率评测，用业务数据比3-5个候选模型，选出性价比最优的，而不是盲追最新最大。
【面试题】7. AI产品的流式输出（Streaming）为什么重要？实现时要注意什么？
【标准答案】流式输出就是模型生成一个token就立刻推给前端，而不是等全部生成完再返回。它的重要性来自一个核心体验问题：大模型生成一条完整回复可能需要5-15秒，如果用户盯着空白屏幕等10秒，体感就是"卡死了"，而流式输出让用户看到文字逐字出现，心理等待时间大幅缩短——虽然总时间一样，但感知延迟从10秒降到了0.5秒（第一个token到达的时间）。这对产品留存率影响巨大，我们实测过，启用流式输出后用户中途取消请求的比例下降了40%。实现注意点：第一，前端要做打字机效果的节流控制——不能每个token都触发一次渲染，太频繁会卡UI，通常攒几个token或每50ms刷新一次。第二，错误处理——流式传输中途如果模型报错或超时，要能优雅地显示已输出的部分并提示中断，不能整个消息消失。第三，token计量——流式模式下要累计所有token用于计费统计，不能只记最后一个chunk。第四，对需要结构化输出的场景（JSON、表格），流式输出比较尴尬——用户看到的是半成品，体验反而差，这时候可以考虑先内部完整生成再一次性展示，或者在流式输出完成后做一次格式化渲染刷新。
【面试题】8. 面试官问：AI产品的PRD和传统产品PRD有什么区别？你写过哪些AI特有的模块？
【标准答案】核心区别在于AI产品的输出具有不确定性和非确定性，传统产品PRD写"点击按钮弹出弹窗"是确定行为，AI产品PRD写"生成摘要"——生成的质量、长度、风格都可能不同。所以AI产品PRD必须多写三个模块：第一，Prompt规范模块——明确system prompt、用户输入模板、输出格式要求、角色设定、护栏规则。这不是开发自己调的东西，是产品经理定义的，因为prompt直接影响用户体验。第二，效果评估模块——定义"好"的标准是什么。不能用"生成合理"这种模糊描述，要量化：摘要任务定义ROUGE分数基线、问答任务定义准确率和引用命中率、对话任务定义意图识别F1。同时定义bad case的容忍阈值——比如"错误率<5%"，超过就触发优化流程。第三，降级和兜底模块——AI服务挂了怎么办、模型超时怎么办、输出内容触发安全审核被拦截了怎么给用户反馈。传统产品挂了是bug，AI产品挂了是日常，必须设计降级策略。另外，AI产品的PRD要特别写清楚"数据飞轮"——用户使用产生的数据如何回流优化模型，形成闭环。没有飞轮的AI产品只是在消耗模型能力，没有积累。
【面试题】9. AI产品如何做A/B测试？和传统功能A/B测试有什么不同？
【标准答案】最大的不同是AI产品的输出每次都不一样，传统A/B是确定性的（按钮红色vs蓝色），AI的A/B是非确定性的（同一用户同一输入，两次输出可能不同）。这带来三个实操差异：第一，样本量要更大——因为输出方差大，需要更多样本才能达到统计显著性，通常比传统A/B多2-3倍。第二，指标设计要分层——不能只看点击率和转化率这种结果指标，还要看过程指标：生成质量（人工/自动评估分数）、用户编辑率（采纳后修改了多少）、重试率（用户对结果不满意重新生成）。第三，要控制混淆变量——模型版本、prompt版本、采样参数（temperature）都会影响输出，A/B测试必须只改一个变量，其他全部锁定，否则你根本不知道是哪个改动导致了数据变化。我的实操框架：先跑3天看趋势（方向对不对），再跑7天看显著性（p值<0.05），同时监控成本指标（token消耗有没有暴涨）。还有一个特殊点：AI的A/B可能有"时间效应"——用户第一天对AI输出感到新鲜用得多，第三天新鲜感过了数据回落，所以短期测试容易误判，至少跑一个完整周期能看到真实水平。
【面试题】10. 如何判断一个业务场景该不该用AI？什么场景不适合用AI？
【标准答案】我用一个三问判断框架：第一问，这个任务是否需要"理解+生成"能力？如果只是规则匹配、数据搬运、流程自动化，传统代码就够了，用AI是杀鸡用牛刀——又贵又不稳。第二问，输出是否允许不确定性？如果业务要求100%准确（如财务报表计算、法律文书归档），AI不适合做主输出，只能做辅助——因为模型本质上就是概率性的，不存在绝对准确。第三问，有没有足够的数据和反馈闭环？AI需要数据喂、需要用户反馈优化，如果场景低频到一个月才用一次、没有持续数据回流，AI模型无法迭代，上线即巅峰然后衰退。不适合用AI的典型场景：一是确定性要求高的规则执行（审批流程、合规检查），二是数据极度稀缺的冷启动场景（新业务没有历史数据），三是成本敏感且容错低的场景（如低价高频的自动回复，AI的token成本可能超过人工）。适合用AI的信号：任务需要理解自然语言/图像、输出可以有多样性、有持续数据可以优化。总结一句话：AI是解决"模糊输入、灵活输出"问题的，确定性任务别碰AI，让代码干它该干的事。