系统设计与工程化面试速查
本文对应 AI应用工程化与系统设计 模块全部文档的面试考点提炼。系统设计题面试中通常以开放性问题出现，考察全局视野。
架构演进
Q1：AI应用从Demo到生产，架构上差在哪？
Demo是"直连模型一问一答"，生产级至少需要五层：
接入层：身份认证、限速、内容安全过滤（敏感词检测、Prompt注入防护）。
网关层：多模型路由、fallback降级、成本归因、配额管理。
编排层：多步骤流程管理（RAG检索→Prompt拼接→模型调用→输出解析）、流式/同步/异步三种交互模式调度。
存储层：对话历史（关系型DB）、向量索引（向量DB）、操作日志（时序DB）。
监控层：端到端Trace、Token消耗趋势、回答质量指标、成本告警。
面试时常见追问："你们生产中遇到过什么Demo阶段不会出现的问题？"——准备好并发限流、成本爆炸、恶意输入这几个场景的故事。
Q2：同步/流式/异步三种交互模式分别什么时候用？
同步：请求发出后等响应再返回。适合后台任务（批量文档分析、数据处理）。用户感知是"提交任务→等结果"。
流式（SSE）：Token逐个推送给前端。适合实时对话场景，让用户看到"AI正在打字"的效果。这是目前最主流的方式。
异步：请求提交后立即返回task_id，后续轮询或webhook通知结果。适合耗时特别长的任务（生成长报告、多步Agent执行）。
有些场景会混用：Agent执行过程用异步（防止超时），每一步的中间结果用流式推送给前端展示进度。
大模型网关
Q3：为什么传统API网关不适合大模型场景？需要专门的网关？
核心差异：传统网关按"请求数"限流和计费，大模型需要按"Token数"做这些事。一个请求可能100 Token也可能10000 Token，按请求数限流既不公平也不准确。
大模型网关额外需要处理的事情：
Token级配额：预估请求Token数 → 实时追踪消耗 → 接近配额预警 → 超额拒绝。
语义缓存：传统缓存URL完全一致才命中。语义缓存"意思差不多"就命中——对query做Embedding找缓存中的相似条目。
多模型路由：简单问题发便宜小模型，复杂问题发贵的大模型。主模型挂了自动切备用。A/B测试按比例分流。
流式协议适配：上游SSE下游可能WebSocket，网关要做协议转换。
📖 大模型网关详解
Q4：语义缓存跟传统缓存比，实现上有什么不同？命中率怎么样？
传统缓存的key是URL或请求体的哈希——必须完全一致才命中。
语义缓存的key是问题的Embedding向量——对新问题做Embedding后在缓存中做相似度检索，超过阈值（比如0.95）就命中。
"北京天气怎么样"和"北京今天天气如何"在传统缓存中是两个不同的key，语义缓存中会命中同一条。
实现：缓存条目存{query_embedding, response, timestamp}。新请求来了 → 算Embedding → 相似度搜索 → 超阈值返回缓存结果 → 未命中才调模型。
注意：阈值设太低误命中多（问题不同但回答一样的情况），设太高几乎不命中白搭了。通常0.93-0.97之间调。
📖 大模型网关详解
API调用工程
Q5：调用大模型API的完整链路是什么？有哪些需要工程化处理的地方？
完整链路：鉴权（API Key验证）→ 配额检查（Token余额够不够）→ 缓存查询（有没有命中语义缓存）→ 模型路由（发给哪个模型）→ 请求发出 → 流式接收 → 响应解析 → 结果校验 → 日志记录 → 返回。
工程化要处理的点：
- 超时和重试：模型响应可能很慢（30秒+），需要区分"还在生成"和"真的挂了"
- 流式中断恢复：SSE连接断了，已收到的部分要保留，尝试断点续传
- 结构化输出校验：JSON解析失败时自动重试（最多3次）
- 速率限制应对：收到429后指数退避重试
- 成本追踪：记录每次调用的input/output Token数，归因到具体业务/用户
Q6：AI应用的可观测性跟传统微服务有什么不同？
除了传统的延迟/吞吐/错误率，AI应用还需要：
AI特有指标：
- TTFT（Time To First Token）：流式场景用户感知到的响应速度
- Token吞吐量（TPM）
- 每次回答成本（input + output Token费）
- 缓存命中率
质量监控（传统微服务没有）：
- 回答准确率趋势（定期跑Golden Set）
- 幻觉率检测
- 用户满意度评分
Trace粒度细化： 一次AI请求的Trace要细化到：内容过滤(20ms) → Query Rewrite(500ms) → 向量检索(80ms) → Rerank(200ms) → Prompt组装(5ms) → LLM生成(3000ms) → 解析(10ms)。出问题能精确定位是哪一环节。
语音Agent
Q7：语音AI Agent的技术链路是什么？跟文本Agent的核心差异？
链路：VAD（端点检测，判断用户说完没）→ ASR（语音转文字）→ LLM（理解和生成）→ TTS（文字转语音）→ 播放。
跟文本Agent的核心差异在延迟要求：
- 文本场景：用户等3-5秒可以接受
- 语音场景：超过1秒就明显感觉"卡"，用户体验断崖式下降
这个延迟约束倒逼了整条链路的优化：
- VAD要准确快速（误判"说完了"会截断用户发言）
- ASR用流式识别（边说边转，不等说完）
- LLM选小模型或用流式生成
- TTS做到chunk级合成（收到一句话就开始转语音，不等全部生成完）
还有一个特殊问题：打断处理。用户在AI说话途中插嘴，系统要能检测到并立即停止当前播放，切换到处理新输入。
Q8：Prompt注入攻击是什么？AI应用怎么做安全防护？
Prompt注入：用户通过精心构造的输入绕过System Prompt的安全约束。类比SQL注入——"数据"和"指令"的边界被混淆。
防护多层叠加：
输入层：模式检测（"忽略之前指令""你现在是"等关键词）+ 意图分类（用小模型判断是否包含攻击）。
Prompt层：用户输入用分隔符隔离（XML标签等）+ System Prompt末尾重复关键约束。
输出层：扫描输出是否泄露System Prompt内容、是否包含不该输出的信息。
架构层：LLM不直接拥有数据库/文件操作权限，工具调用需要独立的权限校验。