AI BA / AI PM / AI 架构师面试题库

适用岗位：AI Business Analyst、AI Product Manager、AI Solutions Architect。 重点场景：金融零售、AML/KYC、风控、客服运营、企业 AI 转型。 使用原则：不要背概念。每个回答都要落到证据、工作流、质量度量、控制和商业价值。

使用方法: STAR-T plus evidence, workflow, eval, control, ROI

STAR-T 是主线，ABPA 是证据层：

回答前先判断题目属于哪类：问题定义、流程需求、eval、数据架构、治理、adoption、ROI 或 capstone 深挖。 回答时优先引用自己的资产：Opportunity Canvas、Stakeholder Map、BPMN Pain Metrics、Requirements-to-Eval Matrix、Control Pack、Data Readiness、ADR、Operating Model、Adoption Dashboard、Business Case。 金融和 AML 场景中，不要把 AI 描述成无监督决策者。更强的表达是：AI 提供证据聚合、摘要、风险解释、下一步建议和草稿，最终高风险决定由授权人员批准并留下审计轨迹。

岗位差异速查

同一个案例要按岗位重心切换表达：

同一个 AML Copilot 故事可以这样改写：

面试证据包速查

准备面试时，至少带 8 类证据，而不是只带 PPT：

题型 1: AI 机会识别与问题定义

1. 你如何判断一个金融零售场景是否适合用 AI？ 答题结构：业务痛点 -> 基线指标 -> AI fit -> no-AI boundary -> first 30-day validation。举例用 AML alert triage：高频、文本密集、证据分散、人工判断重，但 SAR 提交不能自动化。

2. 如果业务方说“我们要一个 AML Copilot”，你第一周会问什么？ 答题结构：谁的流程 -> 当前 case volume/cycle time -> 痛点证据 -> 决策责任 -> 合规边界 -> 成功指标。强调先定义 decision support，不先选模型。

3. 如何区分“AI 机会”和“流程问题/数据问题/规则问题”？ 答题结构：用价值流和痛点指标拆解。如果瓶颈来自审批层级、字段缺失、名单接口慢，先改流程或数据；如果来自证据阅读和叙事归纳，再考虑 AI。

4. 你如何为一个 AI 转型项目写 business case？ 答题结构：volume x handle time x rework x risk exposure -> target impact -> implementation cost -> control cost -> funding gate。不要只写“提升效率 50%”。

5. 如何处理高管想追热点、但业务证据不足的 AI 项目？ 答题结构：承认战略意图 -> 提出 discovery-only -> 10 天证据包 -> stop rule。用小样本 case review、流程观察和数据 readiness 降低争论成本。

6. AML、信用审批、客服助手三个场景，AI 优先级怎么排？ 答题结构：价值、风险、数据、可控性、采纳难度。通常先做低自动化、高证据聚合的 copilot，再进入推荐或行动类 agent。

7. 如何定义 AI 项目的 non-goals？ 答题结构：列出不自动审批、不绕过规则、不替代合规签字、不使用未授权数据、不输出无出处结论。说明 non-goal 是控制范围和保护 ROI 的工具。

8. 你如何把“降低 AML 风险”转成可执行目标？ 答题结构：风险目标拆成 missed red flag rate、unsupported claim rate、case completeness、escalation precision、audit finding rate，并绑定 eval 和监控。

9. 如果没有历史标签，AI 项目还能开始吗？ 答题结构：可以 discovery，但不能直接规模化。先做专家标注、小样本 golden set、shadow review、规则基线对比，再决定是否进入 pilot。

10. 你如何向非技术高管解释 RAG/Agent 的业务边界？ 答题结构：RAG 是“带出处的知识检索和生成”，Agent 是“在权限内调用工具完成步骤”。金融场景要强调最小权限、审批点、审计和回退。

题型 2: 需求分析与流程建模

1. 你如何把 AML analyst 的日常工作转成需求？ 抓手：先观察 alert intake、CDD/EDD、交易证据、case notes、escalation、SAR draft，再把每一步的 pain、数据源、决策、异常路径写进 BPMN。

2. 如何识别 AI 需求中的用户角色？ 抓手：区分 analyst、team lead、compliance officer、model risk、data owner、IT security、audit、operations sponsor，每类人的验收标准不同。

3. 你如何从访谈中避免只收集“想要功能”？ 抓手：追问最近 5 个真实 case、等待时间、返工原因、证据缺口、谁批准、出了错谁负责，用 evidence map 记录来源和可信度。

4. 如何写一个好的 AI user story？ 抓手：As an AML analyst, I need evidence-backed alert summary, so that I can decide escalation faster。必须补充 acceptance criteria、eval data、control、owner。

5. 如何处理业务流程中的例外和边界？ 抓手：把 PEP、高风险国家、现金密集行业、关联账户、缺失 KYC、制裁名单命中作为异常路径，不把它们藏在 happy path 后面。

6. 你会如何建模“人机协同”的流程？ 抓手：标出 AI suggest、human review、human approve、AI cannot act、escalate、override、audit log。说明每个节点的责任人和证据要求。

7. AI 需求评审会上，你会带什么材料？ 抓手：流程图、痛点指标、样本 case、需求到 eval 矩阵、控制包草案、数据缺口、pilot 范围和 stop rule。

8. 如何避免需求范围膨胀？ 抓手：按 workflow step 分期，不按模型能力分期。先做 evidence retrieval 和 summary，再做 recommendation，最后再考虑工具调用。

9. AI BA 和传统 BA 最大差异是什么？ 抓手：传统 BA 关注流程和系统需求；AI BA 还必须把需求转成可评测的数据、阈值、失效模式、人工控制和生产反馈。

10. 如果合规团队和运营团队目标冲突，你怎么推进？ 抓手：用双指标治理：运营看 cycle time、backlog、touch time；合规看 case completeness、unsupported claim、override、audit finding。用 RACI 明确 veto 权。

题型 3: Requirements-to-Eval 与质量度量

1. 什么是 Requirements-to-Eval？ 抓手：每条重要需求都要有 acceptance criteria、eval data、grader、threshold、production signal、review cadence，否则只是愿望清单。

2. AML Copilot 的核心 eval 指标有哪些？ 抓手：citation accuracy、evidence coverage、red flag recall、unsupported claim rate、summary completeness、case priority consistency、latency、cost per case。

3. 如何设计 golden dataset？ 抓手：抽样覆盖高风险、普通、误报、缺字段、跨账户、PEP、制裁、历史已升级 case；由 SME 双人标注并记录分歧。

4. 什么时候用 LLM judge，什么时候不用？ 抓手：格式、引用、确定性字段用代码或规则；摘要质量可用 LLM judge 加人工抽检；高风险合规结论不能只靠 LLM judge。

5. 你如何定义 hallucination 在金融场景中的失败？ 抓手：无出处事实、引用错 case、夸大风险、遗漏反证、生成不存在政策、把建议说成决定。每类失败要有检测和处置。

6. 如果模型整体准确率高，但关键风险漏掉了怎么办？ 抓手：不用 overall accuracy 作为唯一指标。按风险类别设 red flag recall 和 critical miss zero tolerance，失败进入 release gate。

7. 如何把生产监控接回需求？ 抓手：上线后跟踪 override rate、edit distance、citation invalid rate、escalation reversal、user feedback、latency、cost，并定期刷新 eval set。

8. 如何向面试官解释“eval 是产品能力”？ 抓手：eval 决定能不能发布、能不能扩场景、能不能通过审计。AI PM 不能只排功能，还要排质量门槛和学习闭环。

9. 如何评估 RAG 输出是否可信？ 抓手：retrieval hit rate、source freshness、citation span validity、answer groundedness、conflict handling、no-answer behavior。

10. 如果业务要求快速上线，你如何设置最低质量门槛？ 抓手：限定 pilot 人群和 case 类型，设置 must-pass eval、人工审批、禁止外发、监控告警、回滚条件和每日 review。

题型 4: 数据 readiness 与 RAG/Agent 架构

1. 做 AML Copilot 前，数据 readiness 要看什么？ 抓手：数据源、字段完整性、标签质量、权限、PII、血缘、刷新频率、历史 case notes、一致性、可审计性和保留策略。

2. RAG 在金融知识场景的关键设计是什么？ 抓手：知识源授权、chunk 策略、metadata、hybrid retrieval、rerank、引用范围、版本控制、过期处理和 no-answer。

3. 什么时候 RAG 不够，需要 agent？ 抓手：当任务跨多系统、多步骤、需要查 case、取交易、生成草稿、创建任务时可考虑 bounded agent，但必须有工具权限和审批边界。

4. Agent 在 AML 中可以做什么，不能做什么？ 抓手：可以检索证据、生成摘要、建议下一步、创建待办；不能单独关闭 case、提交 SAR、改客户风险等级或绕过四眼审批。

5. 如何设计模型和供应商策略？ 抓手：按质量、延迟、成本、数据控制、可用性、合规、fallback 打分。敏感场景优先考虑私有化、区域合规和可审计日志。

6. 如何处理数据权限和最小可见原则？ 抓手：按角色过滤检索、按 case scope 限定上下文、脱敏、字段级权限、工具调用授权、审计每次访问。

7. 如何降低 prompt injection 风险？ 抓手：隔离系统指令和检索内容、工具白名单、输入输出过滤、引用验证、敏感操作二次确认、注入检测监控。

8. 如何解释 AI 架构 ADR？ 抓手：每个关键选择写 context、options、decision、consequence、reversal trigger。面试中展示你能管理可逆决策。

9. 如何设计可观测性？ 抓手：记录 request、retrieval、prompt version、model、tool call、citation、latency、cost、error、override、user feedback，但注意 PII 最小化。

10. 架构师如何避免过度设计？ 抓手：以风险和证据定复杂度。低风险 FAQ 用 RAG；AML 高风险建议用 copilot + HITL；只有明确业务价值时才上 agent 编排。

题型 5: 风险、合规、治理与人机协同

1. AI 在 AML 场景的主要风险是什么？ 抓手：错误结论、遗漏红旗、隐私泄露、偏见、过度依赖、审计不可追溯、模型漂移、供应商故障、成本失控。

2. 你如何设计 AI Control Pack？ 抓手：每个风险对应 preventive、detective、corrective control，并指定 evidence、owner、threshold、response。

3. 什么是 human-in-the-loop 的好设计？ 抓手：不是让人“看一眼”。要定义人审什么、何时审、凭什么审、如何 override、如何记录、如何反馈到 eval。

4. 如何满足金融审计要求？ 抓手：保留输入、证据来源、模型版本、prompt version、输出、人工修改、审批、时间戳、权限和数据保留策略。

5. 如何处理模型偏见和不公平结果？ 抓手：避免把敏感属性直接用于决策，做分群质量监控，保留人工复核，记录 adverse impact，并让合规参与阈值选择。

6. 如何定义 stop rule？ 抓手：critical miss、invalid citation、privacy incident、latency breach、cost spike、用户误用、audit finding 触发暂停或回滚。

7. 如果 AI 输出和规则引擎冲突怎么办？ 抓手：规则和政策优先；AI 提供解释和证据，不覆盖硬性规则。冲突进入人工复核，并作为 eval case 保存。

8. 如何向 Model Risk Management 解释方案？ 抓手：说明用途、限制、数据、验证、监控、变更管理、人工监督、残余风险和退场机制。

9. AI 治理委员会应该看什么？ 抓手：release gate、eval trend、incident、override、adoption、cost、模型/提示词变更、数据源变更和合规例外。

10. 你如何防止用户过度信任 AI？ 抓手：显示证据和置信边界，要求引用，保留人工决定，设计 challenge prompt，监控低编辑率但高错误率的风险。

题型 6: Adoption、ROI、Operating Model

1. AI 项目上线后，如何判断真的被采用？ 抓手：active users、case coverage、repeat usage、task completion、edit/override、time saved、workflow step adoption，而不是只看登录次数。

2. 如何设计 adoption dashboard？ 抓手：采纳、信任、质量、风险、效率、成本六类指标，按团队、case 类型、时间趋势切片。

3. ROI 怎么算才可信？ 抓手：以基线为起点：case volume x touch time x loaded cost + rework + risk exposure，再扣除模型、集成、治理、培训和运营成本。

4. 如何处理“节省时间但不省钱”的质疑？ 抓手：说明节省时间转化为 backlog 下降、SLA 改善、同人力覆盖更多 case、降低 overtime 或提升高风险 case 深审质量。

5. Operating Model 里必须有哪些角色？ 抓手：product owner、business process owner、SME、data owner、eval owner、risk/control owner、engineering、support、audit liaison。

6. AI 产品的持续运营和普通软件有什么不同？ 抓手：需要 eval refresh、prompt/model change review、数据漂移监控、知识库刷新、incident drill、用户反馈闭环。

7. 如何推动一线 analyst 从不用到愿意用？ 抓手：从高痛点步骤切入，让用户看到证据可追溯，允许编辑和反馈，用 champions 试点，避免把 AI 做成额外录入负担。

8. 如果 adoption 低，你怎么诊断？ 抓手：看流程嵌入、输出质量、信任、速度、权限、培训、经理激励、误报成本。不要只归因“用户抗拒变化”。

9. 如何做分阶段 rollout？ 抓手：shadow mode -> pilot team -> limited case types -> expanded teams -> governance review -> scale。每阶段有门槛和回滚。

10. 面试中如何展示你既懂产品又懂架构？ 抓手：用同一个故事串起业务痛点、流程、需求、eval、数据架构、控制、adoption、ROI。不要把 PM 和 Architect 分成两套话术。

题型 7: AML Copilot capstone 深挖追问

1. AML Copilot 的目标用户是谁？他们每天最痛的 3 个步骤是什么？
2. 你如何证明 alert triage 是高价值问题，而不是“看起来适合 AI”？
3. 你会选哪些 AML case 类型作为 pilot，哪些暂时排除？
4. 你如何定义 false positive、false negative、unsupported claim 和 missed red flag？
5. 你的 golden dataset 如何抽样？谁标注？如何处理标注分歧？
6. 如果 analyst 的 case notes 本身质量很差，Copilot 怎么办？
7. RAG 检索哪些知识源：政策、KYC、交易、历史 case、名单结果还是外部新闻？
8. 哪些数据不能进入 prompt？哪些需要脱敏或按角色过滤？
9. Copilot 输出必须带哪些引用，引用粒度到文档、段落还是字段？
10. 如果检索结果互相冲突，Copilot 应该怎么回答？
11. 如果没有足够证据，系统应该沉默、提示缺口，还是生成低置信答案？
12. AML analyst 能否一键关闭 alert？为什么？
13. 哪些操作需要 team lead 或 compliance officer 批准？
14. SAR narrative draft 是否属于可交付范围？上线第一版要不要做？
15. 你如何防止 Copilot 把建议说成最终合规判断？
16. 如何设计 prompt injection 和 malicious document 的防护？
17. 如果模型延迟 20 秒，业务是否还能接受？你怎么设计 fallback？
18. 如何衡量 Copilot 减少了 analyst 的 touch time，而不是把工作转移到复核？
19. 如果 override rate 很高，可能说明什么？下一步怎么做？
20. 如果 adoption 很高但 audit finding 增加，你怎么处理？
21. 如果合规要求所有输出可复现，你如何设计版本和日志？
22. 如果模型供应商更换，哪些 eval 和 ADR 必须重跑？
23. 你如何把 AML Copilot 从一个团队扩展到多个国家或业务线？
24. 多语言 case、不同地区监管政策、数据驻留要求如何影响架构？
25. AML Copilot 的第一版 business case 你会怎么写？
26. 你会如何向 CTO、CRO、合规负责人分别汇报同一个方案？
27. 这个 capstone 最容易被面试官质疑的点是什么？
28. 如果面试官问“这和普通搜索有什么区别”，你怎么回答？
29. 如果面试官问“为什么不用全自动规则引擎”，你怎么回答？
30. 如果面试官问“你本人实际贡献是什么”，你如何用证据回答？

回答模板: 30秒, 2分钟, 深挖版

30秒模板

我会先把这个 AI 需求还原成业务流程问题。以 AML alert triage 为例，目标不是“做一个聊天机器人”，而是缩短 case review 周期、提升证据完整性，并降低 unsupported claim 和 missed red flag。我的做法是先建立 baseline，再用 BPMN 定位痛点，把关键需求映射到 eval 和控制，最后用 pilot 的 adoption、质量、风险和成本数据决定是否扩大。

2分钟模板

背景是金融零售 AML 团队面对大量 alert，证据分散在 KYC、交易、名单筛查、历史 case 和政策文档中。任务是帮助 analyst 更快形成有证据的判断，但不能让 AI 自动做高风险合规决定。

我会先做 Opportunity Canvas 和 Stakeholder Evidence Map，确认 case volume、touch time、backlog、返工率和审计痛点。然后画 BPMN，把 alert intake、证据收集、case note、升级、复核、SAR draft 拆成节点，并标出 AI 可以辅助和必须人工审批的位置。

需求层面，我会用 Requirements-to-Eval Matrix，把“生成摘要”改写成“摘要必须覆盖关键交易、客户风险、红旗和引用来源，unsupported claim rate 低于阈值”。架构上，第一版通常选择 RAG copilot，而不是 fully autonomous agent。控制上，必须有引用、权限过滤、override logging、stop rule 和人工审批。商业价值用 cycle time、backlog、case completeness、audit finding、cost per case 和 adoption 来验证。

深挖版模板

如果深入到方案设计，我会从 5 个层面展开。第一，业务层：定义目标 case 类型、baseline、用户角色和 no-AI boundary。第二，数据层：盘点 KYC、交易、名单、政策、历史 case notes，检查字段完整性、权限、标签和刷新频率。第三，架构层：选择 hybrid retrieval + rerank + citation validation，必要时加入受限工具调用，但不允许 AI 单独关闭 case 或提交 SAR。第四，eval 层：建立 golden set，覆盖高风险、误报、缺字段和跨账户场景，设置 red flag recall、citation validity、unsupported claim、latency 和 cost 阈值。第五，运营治理层：用 RACI 指定 product、SME、eval、data、risk、support owner，并通过 adoption dashboard 和 control review 持续管理。

常见失败回答与改法

面试结尾可以补一句：我不会把 AI 项目包装成模型演示，而会把它做成一个可评估、可审计、可运营、能证明业务价值的工作流改造。