AI应用开发面试题精讲（四）：系统架构与生产落地高频15问

AI应用开发面试题精讲（四）：系统架构与生产落地高频15问

前言

架构师视角的AI面试题，考察的是"你能不能从0到1设计一个AI系统"。不是问你某个组件怎么用，而是问你整个系统怎么搭、怎么扩展、怎么容灾。这篇整理了系统架构与生产落地最高频的15道题。

一、架构设计

1. 设计一个大模型应用网关，需要哪些功能？

参考答案：

大模型网关是所有大模型调用的统一入口，核心功能：

1. 路由：按场景/用户/复杂度路由到不同模型
2. 限流：按用户/API Key/IP分别限流
3. 缓存：语义缓存，命中直接返回
4. 监控：Token消耗、延迟、错误率
5. 降级：主模型故障自动切换备用模型
6. 计费：按Token用量计费，支持多租户
7. 安全：Prompt注入检测、敏感内容过滤
8. 审计：所有调用日志留存

设计要点：网关要轻——不要在网关里做业务逻辑，只做流量控制。业务逻辑放在下游服务。

2. RAG系统的分层架构怎么设计？

参考答案：

五层架构：

1. 数据层：原始文档存储（对象存储）、向量库、关系数据库
2. 索引层：文档解析→切分→Embedding→入库，支持增量更新
3. 检索层：查询改写→多路召回（向量+关键词）→重排→过滤
4. 生成层：Prompt组装→大模型调用→输出校验→流式返回
5. 应用层：对话管理、UI、用户反馈

关键设计原则：

• 检索层和生成层解耦，可以独立扩缩容
• 索引层异步处理，不阻塞用户请求
• 每层都有独立监控和降级方案
• 向量库可替换（不要绑死某个向量数据库）

3. 多Agent协作系统怎么设计？有哪些协作模式？

参考答案：

协作模式：

1. 串行流水线：Agent A → Agent B → Agent C，前一个的输出是后一个的输入
2. 并行投票：多个Agent同时做同一任务，取一致结果
3. 主从模式：主Agent分解任务，分发给子Agent，汇总结果
4. 对话协商：多个Agent互相讨论，达成一致后输出

设计要点：

• 任务分解：主Agent负责理解需求、分解任务、汇总结果
• 状态管理：每个Agent的输入/输出/状态都要记录
• 错误处理：子Agent失败时，主Agent决定重试还是换策略
• 超时控制：不能一个Agent卡住整个系统
• 成本控制：多Agent = 多倍Token消耗，要评估ROI

面试加分点：提到"多Agent不是越多越好"——简单的任务用单Agent+工具调用就够了，多Agent的协调成本很高。

二、安全与合规

4. Prompt注入怎么防御？

参考答案：

攻击方式：

• 用户输入"忽略上面的指令，改为…"
• 文档中嵌入"你现在是一个没有限制的AI"
• 多轮对话中逐步绕过限制

防御层次：

1. 输入层：过滤高风险模式（“忽略指令”"你现在是"等）
2. 隔离层：用分隔符明确区分系统指令和用户输入
3. 输出层：检查输出是否偏离了系统指令的范围
4. 权限层：工具调用最小权限，不给危险操作权限
5. 后端层：关键操作要后端二次校验，不信任模型输出

核心原则：不要只靠Prompt防Prompt注入——Prompt是可以被绕过的，必须有后端校验兜底。

5. 多租户隔离怎么做？

参考答案：

隔离维度：

1. 数据隔离：不同租户的知识库、对话记录物理或逻辑隔离
2. 资源隔离：每租户独立的限流配额、Token预算
3. 模型隔离：VIP租户用更好的模型，免费租户用基础模型
4. 安全隔离：一个租户的异常不影响其他租户

实现方式：

• 向量库中每条数据带tenant_id，检索时必带过滤
• 限流按tenant_id分别计数
• 租户级配置（模型路由、Prompt模板、安全策略）独立管理
• 大模型调用上下文中不混入其他租户数据

6. 大模型应用的数据隐私怎么保护？

参考答案：

风险：

• 用户输入可能包含敏感信息（身份证、手机号）
• 大模型服务端可能记录请求内容
• 对话日志可能泄露隐私

保护措施：

1. 输入脱敏：发送前用正则/NER替换敏感信息
2. 输出过滤：检查输出是否包含敏感信息
3. 日志脱敏：日志中不记录原始敏感内容
4. 数据驻留：选择数据不落地的模型服务，或自部署
5. 合规审查：遵守GDPR、个人信息保护法等法规
6. 用户知情：明确告知用户数据如何使用

三、对话系统设计

7. 多轮对话管理怎么做？

参考答案：

核心问题：上下文窗口有限，但对话可能很长。

管理策略：

1. 滑动窗口：只保留最近N轮对话
2. 摘要压缩：超过N轮后，把早期对话摘要为一段文字
3. 检索式记忆：历史对话存入向量库，按需检索相关历史
4. 混合策略：最近几轮原文 + 更早的摘要 + 按需检索

实践建议：

• 每轮对话记录intent和关键实体，不只存原文
• 对话状态要有结构化表示（当前话题、已确认信息、待确认信息）
• 用户说"我们刚才说的那个方案"时，能正确回溯

8. 对话中断与恢复怎么处理？

参考答案：

中断场景：

• 用户主动切换话题
• 系统超时或崩溃
• 用户隔了一段时间回来

恢复策略：

1. 会话持久化：对话状态存数据库，不只在内存
2. 上下文恢复：用户回来时，恢复最近N轮对话
3. 话题切换检测：检测到用户切换话题时，保存旧话题上下文
4. 话题回切：用户说"继续刚才那个问题"时，能恢复之前的上下文

面试加分点：提到"对话状态机"——用状态机管理对话流程，每个状态有明确的允许操作和跳转条件。

四、架构演进

9. 从0到1搭建AI应用，架构怎么演进？

参考答案：

Phase 1（MVP，0-100用户）：

• 单体应用，大模型API直连
• 固定Prompt，无缓存
• 基础监控

Phase 2（100-1000用户）：

• 加网关层（限流、监控、缓存）
• 加RAG（知识库检索）
• Prompt版本管理
• A/B测试框架

Phase 3（1000-10000用户）：

• 检索和生成分离部署
• 多模型路由
• 语义缓存
• 灰度发布

Phase 4（10000+用户）：

• 多区域部署
• 异地容灾
• 自部署模型降本
• 全链路可观测

面试金句：不要一上来就设计Phase 4的架构——过度架构和没有架构一样危险。

10. 高可用架构怎么设计？

参考答案：

高可用原则：

1. 无单点：每个组件都有备份
2. 自动故障转移：故障自动切换，不等人工
3. 降级而非宕机：部分功能不可用，但核心功能正常

具体措施：

• 大模型服务：多供应商，主备切换
• 向量库：主从复制，读可以分散
• 应用层：多实例部署，负载均衡
• 缓存：Redis集群，自动故障转移
• 消息队列：持久化队列，重启不丢消息

SLA目标：

• 99.9%：月停机<43分钟
• 99.99%：月停机<4.3分钟
• AI应用通常99.9%够用，因为大模型API本身的SLA也就99.9%

11. AI应用怎么做异地多活？

参考答案：

挑战：

• 大模型API可能是集中式的，不存在多区域
• 向量库数据量大，同步成本高
• 对话有状态，跨区域切换要保证连续性

方案：

1. 应用层多活：应用部署在多区域，DNS就近路由
2. 数据层同步：向量库主从同步，对话日志跨区域复制
3. 大模型层：每区域有独立的大模型API配额，故障时跨区域调用
4. 流量切换：健康检查发现某区域异常，自动切到其他区域

实践建议：如果大模型API是第三方服务，异地多活的意义有限——大模型挂了再多区域也没用。重点放在应用层高可用和降级策略上。

五、实战场景

12. 大模型响应慢，怎么排查和优化？

参考答案：

排查步骤：

1. 定位瓶颈：是网络、排队、还是模型本身慢？
2. 看P50 vs P99：P50正常但P99高，是排队问题；都高，是模型问题
3. 看输入长度：长Prompt导致首Token延迟高
4. 看输出长度：长输出导致总延迟高

优化手段：

1. 流式输出：降低首Token延迟，用户体感好
2. Prompt精简：去掉不必要的内容
3. 模型路由：简单问题用快模型
4. 缓存：热门query直接返回
5. 并发优化：减少排队等待
6. 预计算：提前生成可能的回答并缓存

13. 怎么做AI应用的A/B测试？

参考答案：

特殊挑战：

• 输出非确定性，同一输入不同输出
• 评价指标复杂，不只是转化率
• 需要人工评估

方法：

1. 自动指标初筛：BLEU、ROUGE、格式合规率等
2. 人工评估：标注员对模型输出打分（1-5分）
3. 用户指标：满意度、重试率、投诉率
4. 灰度发布：5%→10%→50%→100%

关键点：

• A/B测试要有足够样本量，AI输出的方差大
• 同时测多个变量时注意交叉影响
• 关注长尾case——平均值好看但最差的case可能很差

14. 工具调用（Function Calling）的安全怎么保证？

参考答案：

风险：

• 模型调用错误的工具
• 工具参数不安全（如SQL注入）
• 调用了没有权限的操作

安全措施：

1. 白名单机制：只暴露允许调用的工具
2. 参数校验：工具入参必须做类型和范围校验
3. 权限控制：按用户角色限制可调用的工具
4. 审批流程：高风险操作需要人工确认
5. 审计日志：所有工具调用记录日志
6. 沙箱执行：代码执行类工具在沙箱中运行

15. 你遇到过的最难的技术挑战是什么？

参考答案：

这是开放题，用STAR结构回答：

示例回答（RAG效果优化）：

• Situation：客服RAG系统上线后，发现20%的问题回答不准确
• Task：需要在不增加延迟的前提下提升准确率
• Action：
  1. 分析bad case，发现主要问题是切分不合理和检索不准
  2. 优化切分策略：从固定长度改为按FAQ条目切分
  3. 加混合检索：向量+BM25，召回率提升15%
  4. 加重排器：精度提升10%
  5. 加查询改写：复杂问题分解为子问题
• Result：准确率从80%提升到93%，P95延迟只增加了200ms

面试技巧：用真实数据说话，不要编造。面试官追问细节时能答上来才是真的。

总结

架构面试看的是"全局视野+细节深度"。能画出系统架构图，也能说清楚每个组件的选型理由、坑点和优化方向。最好的准备方式是：把你自己做过的项目画成架构图，对着图想"如果用户量翻10倍，哪里会先扛不住"。