AI 项目面试如何应对深挖？架构、评估、成本、故障与取舍框架
AI 项目深挖不应靠背诵标准答案。准备时要围绕架构、评估、成本、故障和取舍五条线，把每个结论还原为“约束—选择—证据—边界—改进”；不知道或没有做过的部分应明确说明，而不是补造生产经历。
先说结论
面试官持续追问，通常是在验证三件事：项目是否真实参与、技术选择是否有依据、遇到失败时能否控制风险。一个稳定的回答结构是：
- 约束：当时的问题、输入、目标和非目标；
- 选择：你采用了什么方案，为什么；
- 证据：测试、评估、日志或设计记录说明了什么；
- 边界：在哪些条件下不成立，有哪些未完成项；
- 改进：如果规模、风险或资源变化，下一步怎么验证。
适合谁，不适合谁
本文适合已经有可讲项目，并准备 RAG、Agent、AI 应用或平台工程相关面试的开发者。它也适合用来做项目自审。
它不是面试题答案库。没有亲自实现的模块、没有运行过的评估、没有经历过的故障，都不能用模板包装成真实经历。
先准备一张项目事实卡
面试前把以下事实写在一页内：
- 项目性质、用户和核心问题；
- 本人负责与未负责的模块；
- 一张索引/数据流和一张在线请求流；
- 两个关键技术选择及备选方案；
- 评估集、指标定义和实际记录；
- 一个真实失败样例及处理过程；
- 成本、延迟和安全边界；
- 当前限制与下一步。
事实卡的作用是保持口径一致。回答深入后仍应能回到同一组事实，不因问题变化而新增未经证实的结果。
架构追问：链路为什么这样拆
常见追问
- 请求从入口到模型返回经历哪些步骤？
- 索引链路与查询链路为什么分开？
- 哪些状态需要持久化，哪些可以重算？
- 为什么选择 Workflow、Agent 或多 Agent？
- 模型、检索、工具和业务服务的信任边界在哪里？
回答重点
先画主链路，再讲一个关键边界。RAG 项目可区分文档导入、切片、索引、查询、检索、重排、生成与引用；Agent 项目可区分计划、工具选择、参数校验、鉴权、执行、观察和停止。
不要从框架名开始。先说明约束，再解释框架承载了哪一部分；服务端鉴权、数据版本、幂等和审计等确定性控制不应交给模型决定。
自查证据
- 能否给出每个模块的输入输出；
- 能否说明一次请求的 ID、版本和状态如何传递；
- 能否指出第三方框架负责什么、自己扩展了什么；
- 能否删除一个模块并说明影响。
评估追问：你怎么知道它有效
常见追问
- “准确率”具体指什么？
- 评估集从哪里来，覆盖了哪些失败类型？
- RAG 如何区分检索问题和生成问题？
- Agent 的任务完成如何判定？
- 改 Prompt、模型或检索参数后如何防回归？
回答重点
定义指标再报结果。RAG 至少区分检索阶段与回答阶段；Agent 要区分任务完成、工具参数有效、越权拦截、步数或预算耗尽等状态。说明样例范围、标注方式、允许差异和运行条件。
如果只有本地固定样例，就如实说“该结果只适用于当前评估集”，不要外推为线上成功率。没有测过的指标，回答“目前缺少数据，我会先这样建立基线”比猜数字可靠。
成本追问：资源消耗如何受控
常见追问
- 一次请求的 Token 和工具调用由什么决定？
- 为什么不用更大模型或更长上下文？
- 重试、并发和 Agent 循环如何限制？
- 缓存是否会跨用户泄漏或返回旧结果？
- 供应商不可用时如何路由或降级？
回答重点
把成本拆成输入、输出、检索、重排、模型调用、工具调用和重试。说明预算守卫在哪一层生效，以及超限后是拒绝、缩小上下文、换路由还是转人工。
不必背固定价格。价格会随供应商、模型和时间变化；面试中更重要的是测量口径、预算上限、质量约束和核验过的账单或用量记录。
故障追问：失败时系统会怎样
常见追问
- 模型超时、限流或流式中断怎么办？
- 文档解析成功但索引失败怎么办？
- 工具执行一半失败，是否会重复产生副作用？
- 检索不到证据时是否仍会回答？
- 如何定位 Prompt、模型、数据还是代码导致的回归？
回答重点
使用一条真实或明确标注为演练的故障路径回答：如何发现、如何止损、如何恢复、如何防止再次发生。重点说明总超时、有限重试、幂等、补偿、降级、版本追踪和审计。
如果项目没有生产事故，可以讲你实际执行的故障注入或测试，但必须称为“演练/测试”，不能包装成线上事故复盘。
取舍追问：为什么不选另一种方案
常见追问
- 为什么用混合检索而不是只用向量检索？
- 为什么用固定 Workflow 而不是开放 Agent？
- 为什么自建适配层而不是直接调用 SDK？
- 为什么没有上多 Agent、知识图谱或微调？
- 如果数据量或团队规模扩大，方案会怎么变？
回答重点
用“约束—候选—决策标准—验证结果—重选条件”回答。没有比较过的方案不要说成“经过充分对比”；可以说当时基于范围做了简化，并说明什么信号出现时会重新评估。
好的取舍不是证明当前方案永远最好，而是说明它在当时约束下足够、可验证且保留演进路径。
一次完整的回答模板
当时的约束是【真实约束】，目标是【可验收目标】，不包含【非目标】。我比较/考虑了【实际考虑过的候选】，最终选择【方案】，主要因为【决策标准】。我负责【本人动作】，通过【评估或测试】观察到【真实结果】。它的边界是【限制或失败条件】；如果【重选条件】出现，我会先用【下一步验证】决定是否调整。
使用时保留事实，不必追求每次都说满六句。被追问哪个环节，就展开对应证据。
不知道答案时怎么处理
可以明确区分三种情况：
- 没负责：“该模块由其他成员负责，我能说明接口边界，但不把实现算作个人成果。”
- 没测过：“目前没有可靠数据；我会先定义指标和基线，再比较候选方案。”
- 没做到：“当前版本未覆盖该生产要求，现有风险是……，下一步会先补……”
诚实边界不会削弱真实能力；相反，编造细节会让后续追问迅速失去一致性。
常见误区与失败边界
- 背架构名词，不讲数据流：无法验证是否理解运行过程。
- 把一个准确率代表全部质量：检索、生成、工具执行需要分开判断。
- 成本只报单价：没有请求构成、预算和质量约束。
- 故障只说重试：不可重试错误和副作用需要不同处理。
- 每个选择都说“性能更好”：没有比较条件和证据。
- 遇到空白就补生产故事：个人 Demo、测试和线上经历必须明确区分。
可执行检查清单
- [ ] 已准备项目事实卡，并与简历口径一致
- [ ] 能画出主链路，说明模块输入输出和信任边界
- [ ] 能定义评估指标、样例范围、基线和限制
- [ ] 能拆解 Token、工具、重试与缓存的成本来源
- [ ] 能讲一个真实失败或明确标注的故障演练
- [ ] 能解释两个关键取舍及重新选择的条件
- [ ] 能区分本人工作、团队工作和第三方能力
- [ ] 对未负责、未测量和未完成的部分准备了诚实回答
- [ ] 没有虚构案例、Offer、薪资、成功率或生产规模
下一步
先回到 AI 求职与面试 Hub 对照完整准备路径。如果五条追问线中出现明显空白，下一步阅读 AI 转型失败模式与修正动作，判断问题来自项目深度、工程证据还是表达方式，并安排一次针对性复盘。