AI 开发与架构面试：六类案例和回答证据

面试准备围绕证据组织

先解释任务、约束和你负责的范围，再讲数据流、方案选择、实现、验证与失败。没有实施的设计可用来讨论架构，但应明确是设计；不能把课程阅读、模拟实验或团队成果都说成自己的生产经历。

应用开发通常要求写出接口、检索、工具、评估和测试；架构讨论还需要容量、边界、可靠性、交付和取舍的依据。具体岗位要求不同，本站没有核验某家公司当前招聘题目，也不保证学完通过面试。

六类案例

提问场景	回答应包含	追问与反例
企业资料更新很快，为什么选择 RAG？	数据更新、证据、检索基线、访问控制、成本；何时需要适配模型行为	RAG 漏召回怎么办？微调为何不保证最新事实？
同样问题的缓存泄露了另一用户资料	身份/租户/版本、缓存层、授权重新检查、撤权与删除的生效窗口	身份从哪里来？版本更新事件丢失怎么办？
流式响应开始后大量请求超时	首字与完整成功分开、deadline、取消、队列、限流、退避与降级	HTTP 200 能否计为成功？重试为何加重过载？
20 请求/秒，平均停留 5 秒，如何估容量？	稳态平均约 100 个在途请求，排队与执行分开；实测峰值和资源上限	p95 能否直接代入平均公式？存储为什么还有索引和副本？
工具写入后断线，agent 恢复又执行一次	操作 ID、持久状态、幂等、查询已有结果、权限和人工交接	checkpoint 是否足以阻止外部副作用重复？
候选方案比基线好，证据是什么？	同题集、版本、分母、逐题配对、切片、成本、失败与局限	换题/换模型/换切片同时发生，怎样归因？

案例中可以引用本站实际缓存实验，但要限定为离线 fixture。完整 RAG/agent 项目应有自己的输出、运行版本和失败记录。

统一的回答顺序

1. 澄清用户、数据规模、权限、时延/质量要求与不确定条件。
2. 画主要组件与两个流向：数据更新、用户请求。
3. 给一个可交付的简单方案，再说明扩容或复杂化的触发证据。
4. 估算单位、容量与费用，明确哪些是手算假设、哪些已实测。
5. 分析断线、超时、重复执行、越权、过期与回滚。
6. 用验证结果收尾，承认残余问题及下一步测量。

如果无法回答某项，不背一个架构名词代替；记录缺口并补实验或设计依据。

自评与练习

仓库内 docs/practice/interview-review.md 用四档记录：能解释、能实现、能复现验证、能说明真实生产取舍。四档是本站学习检查，不是行业认证。

先用 5 分钟说明自己的 RAG 项目，再用 10 分钟讨论一个故障和架构选择。复盘时核对代码、日志、数据版本与个人贡献。请另一位评审针对答案追问，也可自己逐项问反例。

复习问题

1. 你能指出自己的方案在哪些条件下会失败吗？
2. 架构中每增加一项组件，解决的已证实问题是什么？
3. 哪段项目经历已有可复核证据，哪段仍只是计划？

阅读依据与核验

• README.md
• 官方章节

2026-10-08：AI 助手协助原创组织与核对来源；案例、练习与手算的执行状态见正文；不把学习任务视为已完成的模型或线上实验。