AI系统设计面试：如何在大厂面试中展示AI架构能力
2026/8/3大约 23 分钟系统设计AI面试架构设计大厂面试Java工程师
AI系统设计面试：如何在大厂面试中展示AI架构能力
刷了100道算法题，却被第一道系统设计题问懵了
2025年11月，小王拿到了字节跳动AI基础设施团队的面试邀请。
他准备了3个月：LeetCode刷了312题，包含所有高频Hard题；Java并发、JVM、Spring都背得滚瓜烂熟；甚至把Redis、Kafka的源码翻了一遍。
面试的前两轮很顺利。第三轮到了系统设计环节，面试官说了一句话：
"给你45分钟，设计一个支持百万用户的AI对话系统，类似ChatGPT。从需求分析开始讲。"
小王脑子里一片空白。
他知道ChatGPT是什么，他也用过LangChain，他甚至读过Transformer的论文——但他不知道从哪里开始，不知道面试官想听什么，不知道如何把"AI"和"系统设计"结合起来，有条理地讲出来。
他停顿了20秒后，磕磕绊绊地从"用户发消息给服务器"开始讲，越讲越乱，越乱越慌，最终这轮系统设计是全部环节里最弱的一环。
他没有收到offer。
这篇文章，就是为像小王这样的人写的。
AI系统设计面试的核心框架
面试官不是在考你背答案，而是在考你解决未知问题的结构化思维。
五步答题框架
每步的核心目标：
| 步骤 | 你要做什么 | 面试官看什么 |
|---|---|---|
| 需求澄清 | 主动问问题，确认范围 | 是否能识别关键约束 |
| 规模估算 | 估算QPS、存储、带宽 | 是否有量化思维 |
| 高层架构 | 画出主要组件和数据流 | 是否对AI系统有整体认知 |
| 深入细节 | 展开最关键的1-2个模块 | 是否有技术深度 |
| 优化演进 | 谈扩展性、容错、成本 | 是否有工程经验 |
需求澄清的必问5个问题
遇到任何AI系统设计题，先问这5个问题：
1. "这个系统的核心用户场景是什么？"
→ 对话？问答？推荐？生成？场景决定架构
2. "预期的日活用户规模是多少？"
→ 1万还是1亿，架构复杂度完全不同
3. "对延迟有什么要求？"
→ 实时流式 vs 异步批处理，影响技术选型
4. "有没有特殊的合规或安全要求？"
→ 数据不出境？内容审核？这些会影响架构
5. "是新建系统还是在现有系统上扩展？"
→ 绿地项目 vs 遗留系统改造，策略不同经典题1：设计类ChatGPT的对话系统（完整解答）
第一步：需求澄清
面试官："设计一个类ChatGPT的对话系统"
你应该问：
Q: 目标日活用户规模？
A: 100万DAU
Q: 对话延迟要求？
A: 首字延迟 < 1秒，支持流式输出
Q: 是否支持多轮对话？
A: 支持，上下文保持最近20轮
Q: 是否自研LLM还是调用第三方API？
A: 先假设调用第三方（OpenAI/Claude）
Q: 需要支持多模态（图片/语音）吗？
A: 暂时只考虑文本
[面试技巧：把假设明确说出来，别自己猜]第二步：规模估算
日活用户：100万
假设每用户每天发10条消息
→ 总消息数：1000万条/天
→ 平均QPS：1000万 / 86400 ≈ 116 QPS
→ 峰值QPS（峰均比3倍）：约350 QPS
消息平均长度：200 Token（Input） + 500 Token（Output）
→ 每秒Token消耗：350 × 700 = 245,000 Token/s
对话历史存储：
每次对话平均20轮 × 700 Token = 14,000 Token ≈ 56KB
100万用户 × 100次活跃对话 × 56KB ≈ 5.6TB
[需要分层存储：热数据Redis，冷数据MySQL/S3]
成本估算（仅供参考，面试中展示思维过程比数字准确更重要）：
日均1000万次调用 × $0.005/次 ≈ $50,000/天
[这个数字说明：成本优化是架构设计的重要约束！]第三步：高层架构
第四步：深入细节
流式输出实现（重点！）
package com.laozhang.interview.chatgpt;
import org.springframework.ai.chat.client.ChatClient;
import org.springframework.stereotype.Service;
import org.springframework.web.servlet.mvc.method.annotation.SseEmitter;
import reactor.core.publisher.Flux;
import java.io.IOException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
/**
* 流式对话服务
* 使用SSE（Server-Sent Events）实现类ChatGPT的打字机效果
*
* 面试要点：
* 1. 为什么用SSE不用WebSocket？
* - SSE是单向流，更简单，适合服务端推送场景
* - WebSocket是双向的，适合实时交互（如在线游戏）
* - 对话场景只需要服务端→客户端的流，SSE足够
*
* 2. 如何保证消息顺序？
* - LLM输出是顺序的，不需要额外保序
* - 网络重传后SSE有event ID机制支持断点续传
*/
@Service
public class StreamingChatService {
private final ChatClient chatClient;
private final ContextManager contextManager;
private final PromptBuilder promptBuilder;
private final ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();
public StreamingChatService(ChatClient chatClient, ContextManager contextManager,
PromptBuilder promptBuilder) {
this.chatClient = chatClient;
this.contextManager = contextManager;
this.promptBuilder = promptBuilder;
}
/**
* 流式对话接口
* 返回SseEmitter，Spring MVC会自动管理流
*/
public SseEmitter chat(String userId, String sessionId, String userMessage) {
SseEmitter emitter = new SseEmitter(120_000L); // 2分钟超时
executor.submit(() -> {
try {
// 1. 加载对话上下文（最近20轮）
List<Message> history = contextManager.loadHistory(sessionId, 20);
// 2. 构建带上下文的Prompt
String fullPrompt = promptBuilder.build(history, userMessage);
// 3. 调用AI，流式接收输出
StringBuilder fullResponse = new StringBuilder();
chatClient.prompt()
.user(fullPrompt)
.stream()
.content()
.doOnNext(token -> {
try {
// 每个Token立即推送给客户端
emitter.send(SseEmitter.event()
.data(token)
.id(String.valueOf(System.currentTimeMillis())));
fullResponse.append(token);
} catch (IOException e) {
emitter.completeWithError(e);
}
})
.doOnComplete(() -> {
try {
// 流结束标志
emitter.send(SseEmitter.event()
.data("[DONE]")
.name("done"));
emitter.complete();
// 异步保存完整对话到历史
contextManager.saveMessage(sessionId, userMessage,
fullResponse.toString());
} catch (IOException e) {
emitter.completeWithError(e);
}
})
.doOnError(emitter::completeWithError)
.subscribe();
} catch (Exception e) {
emitter.completeWithError(e);
}
});
return emitter;
}
}上下文管理（关键组件）
package com.laozhang.interview.chatgpt;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Service;
import java.time.Duration;
import java.util.*;
/**
* 对话上下文管理器
*
* 面试要点：
* 1. 为什么上下文存Redis？
* - 活跃对话需要低延迟访问（<10ms）
* - 对话有自然的生命周期（用完即弃）
* - Redis List结构天然适合滑动窗口
*
* 2. Token窗口如何管理？
* - LLM有上下文长度限制（如128K Token）
* - 历史消息可能超出限制，需要截断策略
* - 常见策略：保留最近N轮 / 超出时摘要压缩
*
* 3. 上下文一致性如何保证？
* - 同一用户同时多设备聊天（会话隔离）
* - 分布式部署下的会话路由
*/
@Service
public class ContextManager {
private static final String KEY_PREFIX = "chat:context:";
private static final int MAX_HISTORY = 40; // 最大保留消息数（20轮×2）
private static final Duration SESSION_TTL = Duration.ofHours(24);
private final RedisTemplate<String, Message> redisTemplate;
private final ConversationRepository convRepository; // MySQL持久化
public ContextManager(RedisTemplate<String, Message> redisTemplate,
ConversationRepository convRepository) {
this.redisTemplate = redisTemplate;
this.convRepository = convRepository;
}
/**
* 加载最近N轮历史（从Redis热缓存）
*/
public List<Message> loadHistory(String sessionId, int maxTurns) {
String key = KEY_PREFIX + sessionId;
List<Message> messages = redisTemplate.opsForList()
.range(key, -maxTurns * 2L, -1); // 取最近N轮（每轮2条）
return messages != null ? messages : Collections.emptyList();
}
/**
* 保存消息（Redis + 异步MySQL）
*/
public void saveMessage(String sessionId, String userMsg, String assistantMsg) {
String key = KEY_PREFIX + sessionId;
// Redis滑动窗口
redisTemplate.opsForList().rightPushAll(key,
new Message("user", userMsg),
new Message("assistant", assistantMsg));
// 超出最大长度时，删除最旧的消息
long listSize = redisTemplate.opsForList().size(key);
if (listSize > MAX_HISTORY) {
redisTemplate.opsForList().trim(key, -MAX_HISTORY, -1);
}
// 刷新TTL
redisTemplate.expire(key, SESSION_TTL);
// 异步持久化到MySQL（失败不影响主流程）
CompletableFuture.runAsync(() ->
convRepository.saveMessages(sessionId, userMsg, assistantMsg));
}
/**
* 上下文Token压缩策略
* 当历史超出模型上下文窗口时，对早期历史做摘要
*/
public List<Message> compressHistory(List<Message> history, int maxTokens) {
int totalTokens = history.stream()
.mapToInt(m -> estimateTokens(m.content()))
.sum();
if (totalTokens <= maxTokens) return history;
// 保留最近6轮（12条），对更早的历史做摘要
int recentSize = Math.min(12, history.size());
List<Message> recent = history.subList(history.size() - recentSize, history.size());
List<Message> older = history.subList(0, history.size() - recentSize);
// 摘要旧对话
String summary = summarizeHistory(older);
List<Message> compressed = new ArrayList<>();
compressed.add(new Message("system", "早期对话摘要：" + summary));
compressed.addAll(recent);
return compressed;
}
private String summarizeHistory(List<Message> history) {
// 简单拼接，实际可以用LLM做智能摘要
return history.stream()
.map(m -> m.role() + ": " + m.content().substring(0,
Math.min(50, m.content().length())))
.reduce("", (a, b) -> a + "\n" + b);
}
private int estimateTokens(String text) {
return text.length() / 3;
}
public record Message(String role, String content) {}
}第五步：优化与演进
面试官最爱问的追问：
Q：如何从1万用户扩展到1亿用户？
阶段1（1万用户）：
单机部署 + MySQL + Redis单节点
代码简单，快速上线，日均成本低
阶段2（10万用户）：
水平扩展服务节点（无状态设计）
Redis Cluster（3主3从）
MySQL读写分离
引入Nginx负载均衡
阶段3（100万用户）：
引入消息队列（Kafka）解耦
对话历史分库分表（按userId取模）
CDN加速静态资源
模型路由（降低AI成本）
阶段4（1亿用户）：
多地域部署（就近接入）
实时/离线数据分离（Flink流处理）
自研LLM推理集群（降低API依赖）
精细化成本管控体系Q：如何保证系统高可用？
| 故障场景 | 解决方案 | 恢复时间 |
|---|---|---|
| 单个服务节点宕机 | 多实例 + 健康检查自动摘流 | <30秒 |
| Redis单节点故障 | Redis Sentinel/Cluster | <1分钟 |
| OpenAI API限流 | 多Provider自动切换（Claude/Gemini） | 秒级 |
| 数据库故障 | 主从自动切换（MHA/Orchestrator） | 1-3分钟 |
| 机房级故障 | 多活部署 + DNS故障切换 | 5-10分钟 |
经典题2：设计企业知识库问答系统（RAG架构）
快速框架
面试必讲的三个技术选型
技术选型1：分块策略
固定大小分块（512字符）:
优点：简单快速
缺点：可能切断语义
语义分块（按段落/标题）:
优点：语义完整
缺点：长度不均
滑动窗口（512字符，128字符重叠）:
优点：减少边界信息丢失
适用：长文档
[面试技巧：说出trade-off，不要只说优点]技术选型2：向量数据库选择
| 数据库 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| Milvus | 大规模（>1亿向量） | 高性能，分布式 | 部署复杂 |
| Pinecone | 云服务，快速上线 | 托管免运维 | 成本较高，数据出境 |
| Qdrant | 中小规模 | Rust实现，低资源 | 生态相对小 |
| pgvector | 已有PostgreSQL | 无额外组件 | 超大规模性能一般 |
技术选型3：Reranker的作用
/**
* 面试中解释为什么需要Reranker
*
* 问题：向量检索返回的top-10结果，排序不一定是最优的
* 原因：Embedding模型是为"粗粒度相似"优化的，
* Reranker是为"精细相关性"优化的
*
* 效果：加了Reranker后，答案准确率通常提升8-15%
*/
@Service
public class RerankerService {
private final CrossEncoderClient crossEncoder; // 交叉编码器（精排）
/**
* 重排序：从粗排结果中精选最相关的Top-K
*/
public List<RankedChunk> rerank(String query, List<String> candidates, int topK) {
// 计算query和每个候选的交叉得分（更精确但更慢）
List<RankedChunk> ranked = new ArrayList<>();
for (int i = 0; i < candidates.size(); i++) {
double score = crossEncoder.score(query, candidates.get(i));
ranked.add(new RankedChunk(candidates.get(i), score, i));
}
return ranked.stream()
.sorted(Comparator.comparingDouble(RankedChunk::score).reversed())
.limit(topK)
.toList();
}
public record RankedChunk(String content, double score, int originalRank) {}
}经典题3：设计推荐系统（实时+离线架构）
推荐系统是AI系统中最经典的大规模架构题，面试中出现频率极高。
核心架构
面试答题要点
召回层（Recall）：
多路召回是标配，面试要提到至少3路：
1. 协同过滤召回（CF）：
你喜欢A，与你相似的用户也喜欢B → 推荐B
实现：ItemCF矩阵预计算存Redis
2. 向量召回（DSSM）：
用户向量 和 物品向量的相似度检索
实现：User/Item双塔模型 + Faiss/Milvus
3. 热门物品召回：
全局热门/区域热门/新品热门
兜底策略，保证推荐不为空
4. 规则召回（业务特定）：
付费内容优先/本地化内容优先排序层特征工程：
面试官最关心：特征穿越（Feature Leakage）问题！
错误做法：用"点击时的特征"训练，会引入未来信息
正确做法：严格按照请求时刻的特征值训练
关键特征分类：
用户特征：年龄、地区、历史偏好（来自用户画像）
物品特征：类别、标签、发布时间（来自物品库）
上下文特征：时间、设备、网络（来自请求）
交叉特征：用户-物品历史交互（来自行为日志）经典题4：设计AI代码审查系统
这道题越来越高频，因为AI代码审查是很多大厂正在做的事。
系统架构
核心代码实现
package com.laozhang.interview.codereview;
import org.springframework.ai.chat.client.ChatClient;
import org.springframework.stereotype.Service;
import java.util.*;
/**
* AI代码审查服务
* 面试中展示：如何设计可扩展、低成本的AI代码审查系统
*/
@Service
public class AiCodeReviewService {
private final ChatClient chatClient;
private final ModelRouter modelRouter; // 根据diff大小选模型
public AiCodeReviewService(ChatClient chatClient, ModelRouter modelRouter) {
this.chatClient = chatClient;
this.modelRouter = modelRouter;
}
/**
* 执行AI代码审查
* 面试要点：
* 1. 大PR如何处理？（分片+并行）
* 2. 如何控制成本？（先静态分析过滤，再AI深度分析）
* 3. 如何保证审查质量？（Few-shot示例+结构化输出）
*/
public CodeReviewResult review(PullRequest pr) {
List<FileDiff> diffs = pr.getFileDiffs();
// 策略1：过滤无意义变更（如格式化、注释）
List<FileDiff> meaningfulDiffs = diffs.stream()
.filter(d -> d.linesChanged() > 0)
.filter(d -> !isAutoGenerated(d.filename()))
.toList();
// 策略2：按文件大小分组，大文件分片分析
List<ReviewComment> allComments = new ArrayList<>();
for (FileDiff diff : meaningfulDiffs) {
if (diff.linesChanged() > 200) {
// 大文件：分片并行分析
allComments.addAll(reviewLargeFile(diff));
} else {
// 小文件：直接分析
allComments.addAll(reviewFile(diff, pr.getContext()));
}
}
// 生成整体摘要
String summary = generatePrSummary(pr, allComments);
return new CodeReviewResult(pr.getPrId(), summary, allComments,
calculateRiskScore(allComments));
}
/**
* 单文件审查
*/
private List<ReviewComment> reviewFile(FileDiff diff, ReviewContext context) {
String prompt = buildReviewPrompt(diff, context);
// 根据diff大小选择模型（成本优化）
String model = diff.linesChanged() < 50 ? "gpt-4o-mini" : "gpt-4o";
String response = chatClient.prompt()
.system(REVIEW_SYSTEM_PROMPT)
.user(prompt)
.call()
.content();
return parseReviewComments(response, diff.filename());
}
private static final String REVIEW_SYSTEM_PROMPT = """
你是一位资深Java架构师，请对以下代码变更进行代码审查。
重点关注：
1. 安全漏洞（SQL注入、XSS、权限绕过）
2. 并发问题（竞态条件、死锁、内存可见性）
3. 性能问题（N+1查询、内存泄漏、不必要的全表扫描）
4. 设计问题（违反SOLID原则、代码重复）
5. 错误处理（异常处理不当、资源未关闭）
对每个问题，请指出：
- 问题所在的代码行
- 严重级别（CRITICAL/HIGH/MEDIUM/LOW）
- 具体问题描述
- 修复建议（包含代码示例）
如果代码质量良好，只需说"LGTM，无明显问题"。
""";
private String buildReviewPrompt(FileDiff diff, ReviewContext context) {
return String.format("""
文件：%s
PR背景：%s
代码变更（diff格式，+新增，-删除）：
```diff
%s
```
请提供代码审查意见。
""",
diff.filename(),
context.prDescription(),
diff.diffContent()
);
}
private boolean isAutoGenerated(String filename) {
return filename.endsWith(".lock") ||
filename.contains("generated") ||
filename.endsWith(".min.js");
}
private List<ReviewComment> reviewLargeFile(FileDiff diff) {
// 按函数/类边界分片，并行审查
List<String> chunks = splitByFunctionBoundary(diff.diffContent());
return chunks.stream()
.flatMap(chunk -> reviewFile(
new FileDiff(diff.filename(), chunk, chunk.lines().count()),
new ReviewContext("大文件分片审查")
).stream())
.toList();
}
private List<String> splitByFunctionBoundary(String code) {
// 按方法签名分割（简化实现）
List<String> chunks = new ArrayList<>();
String[] lines = code.split("\n");
StringBuilder current = new StringBuilder();
for (String line : lines) {
current.append(line).append("\n");
// 检测方法结束（简化：遇到空行+方法签名时分割）
if (current.length() > 3000 && line.trim().isEmpty()) {
chunks.add(current.toString());
current = new StringBuilder();
}
}
if (!current.isEmpty()) chunks.add(current.toString());
return chunks;
}
private String generatePrSummary(PullRequest pr,
List<ReviewComment> comments) {
long critical = comments.stream()
.filter(c -> c.severity() == Severity.CRITICAL).count();
long high = comments.stream()
.filter(c -> c.severity() == Severity.HIGH).count();
if (critical > 0) {
return String.format("⚠️ 发现 %d 个严重问题，需要立即处理后才能合并。", critical);
} else if (high > 0) {
return String.format("⚡ 发现 %d 个高优先级问题，建议修复后合并。", high);
} else {
return "✅ 代码质量良好，无严重问题。";
}
}
private int calculateRiskScore(List<ReviewComment> comments) {
return comments.stream()
.mapToInt(c -> switch (c.severity()) {
case CRITICAL -> 10;
case HIGH -> 5;
case MEDIUM -> 2;
case LOW -> 1;
})
.sum();
}
private List<ReviewComment> parseReviewComments(String response, String filename) {
// 实际需要解析LLM返回的结构化结果
// 建议让LLM返回JSON格式，便于解析
return List.of(); // 简化
}
public enum Severity { CRITICAL, HIGH, MEDIUM, LOW }
public record ReviewComment(String filename, int line, Severity severity,
String issue, String suggestion) {}
public record CodeReviewResult(String prId, String summary,
List<ReviewComment> comments, int riskScore) {}
public record FileDiff(String filename, String diffContent, long linesChanged) {}
public record ReviewContext(String prDescription) {}
public record PullRequest(String prId, List<FileDiff> fileDiffs, ReviewContext context) {
public ReviewContext getContext() { return context; }
public List<FileDiff> getFileDiffs() { return fileDiffs; }
public String getPrId() { return prId; }
}
}容量估算：快速估算的心算公式
面试中快速估算是加分项，记住这些数字：
基础数字（记住这些！）：
1秒 = 86,400 ≈ 10^5 秒/天
1亿用户 = 10^8
1KB = 10^3 字节
1MB = 10^6 字节
1GB = 10^9 字节
1TB = 10^12 字节
常见换算：
日活100万，每人每天10次操作
→ QPS = 100万 × 10 / 86400 ≈ 116 QPS
→ 峰值QPS（3倍峰均比）≈ 350 QPS
存储估算：
1条微博（140字）≈ 500字节
1张高清图片 ≈ 2MB
1分钟视频（1080p）≈ 150MB
1条AI对话（500Token）≈ 2KB
LLM特定：
1000 Token ≈ 750个英文单词 ≈ 500个中文汉字
GPT-4o推理速度 ≈ 50 Token/秒
Embedding维度：1536维（text-embedding-3-small）
1536维float32向量 ≈ 6KB实战演练：估算知识库系统
题目：设计一个10万企业用户的知识库问答系统
估算过程（展示给面试官的思维链）：
1. QPS估算：
10万用户，假设高峰时10%同时在线 = 1万在线
每人每分钟2次提问
QPS = 1万 × 2 / 60 ≈ 333 QPS
2. 向量数据库规模：
每个企业平均1000个文档，每文档切成100个chunks
= 10万 × 1000 × 100 = 100亿个chunks
每个chunk的1536维向量 = 6KB
总存储 = 100亿 × 6KB = 60TB
[这个数字表明：需要分布式向量数据库，如Milvus集群]
3. Embedding计算量：
333 QPS × 1次向量化/次请求 = 333次/秒
每次Embedding约10ms
→ 需要约4台Embedding服务器（每台处理100 QPS）
4. LLM调用量：
333 QPS，假设缓存命中率30%
实际LLM调用 ≈ 233 次/秒
GPT-4o限速约3000 次/分钟 = 50次/秒
→ 需要配置5个不同的API Key或企业级限速协议扩展性设计：从1万到1亿用户的演进路径
面试技巧：别一开始就设计1亿用户的架构，先从简单开始，再说演进路径。这样才能展示你对工程复杂度的理解，也暗示你不会过度设计。
常见加分项：可观测性、容错、成本优化
可观测性（Golden Signals）
/**
* AI系统的四个黄金信号
* 面试中主动提到可观测性，是非常大的加分项
*/
public class GoldenSignalsMetrics {
// 1. 延迟（Latency）- 区分正常请求和失败请求
@Gauge
double p50Latency; // 中位延迟
@Gauge
double p99Latency; // 长尾延迟（最重要）
// 2. 流量（Traffic）
@Counter
long requestsPerSecond;
@Counter
long tokensPerSecond; // AI系统特有
// 3. 错误率（Errors）
@Counter
double errorRate; // API错误率
@Counter
double hallucination; // AI幻觉率（AI系统特有）
// 4. 饱和度（Saturation）
@Gauge
double gpuUtilization; // GPU利用率
@Gauge
double modelQueueDepth; // 推理队列深度
@Gauge
double contextWindowUsage; // 上下文窗口使用率
}AI系统特有的容错设计
/**
* 面试中必提：AI系统的降级策略
* 区别于普通系统：AI有更多不确定性（幻觉、超时、限流）
*/
@Service
public class AiFaultToleranceService {
/**
* AI调用的容错链：
* 主模型 → 备用模型 → 静态回复 → 转人工
*/
public String callWithFallback(String prompt, String userId) {
try {
// 1. 首选：GPT-4o（最强）
return primaryModel.call(prompt);
} catch (RateLimitException e) {
try {
// 2. 限流时：切换到Claude
return backupModel.call(prompt);
} catch (Exception e2) {
try {
// 3. 两者都失败：尝试本地模型
return localModel.call(prompt);
} catch (Exception e3) {
// 4. 全部失败：返回降级回复
return getFallbackResponse(prompt);
}
}
} catch (TimeoutException e) {
// 超时：直接降级，不等待
return getFallbackResponse(prompt);
} catch (HallucinationDetectedException e) {
// 检测到幻觉：标记并重试一次
return retryWithHallucinationGuard(prompt);
}
}
private String getFallbackResponse(String prompt) {
// 返回预置的降级回复，或基于规则的简单回复
return "抱歉，AI助手当前繁忙，请稍后重试。如需紧急帮助，请联系人工客服。";
}
private String retryWithHallucinationGuard(String prompt) {
// 加入幻觉防护指令重试
String guardedPrompt = "请仅基于确定的事实回答，不确定的信息请明确说明：\n" + prompt;
return primaryModel.call(guardedPrompt);
}
}面试技巧：与面试官的互动策略
关键互动技巧
技巧1：Think Out Loud（大声思考）
不要沉默后给答案，要把思考过程说出来：
差的回答："我的设计是... [沉默2分钟] ...用Redis缓存，用MySQL存储"
好的回答："我先考虑一下存储选型。对话历史需要低延迟读写，
用Redis是合理的。但Redis内存有限，所以热数据在Redis，
冷数据用MySQL做归档。我们来估算一下需要多少Redis内存..."技巧2：主动暴露trade-off
面试官最喜欢听你说"这样做的代价是什么"：
"我选择向量数据库做语义搜索，这样召回质量更好，
但代价是：1）引入了新的技术栈，运维复杂度增加；
2）相比Elasticsearch，部署成本更高；
3）不支持精确的关键词搜索。
所以我会同时保留Elasticsearch做混合搜索。"技巧3：主动对齐优先级
"我接下来准备深入讲解上下文管理这个模块，
因为我觉得它是这个系统最核心的挑战。
你觉得OK吗，还是你更想听某个其他部分？"技巧4：承认不确定性
"我不确定Milvus在这个规模下的具体配置参数，
但我知道它支持水平扩展，可以通过增加节点来提升容量。
具体的调优参数我会在实际项目中根据压测结果来定。"AI系统设计面试的评分维度
常见失分点：
- 只说"用AI就行了"，没有具体技术方案
- 不谈成本（面试官非常在意AI成本）
- 只讲Happy Path，不讲容错
- 所有问题都用最贵最复杂的方案
- 不主动澄清需求就开始画架构
FAQ
Q1：没有大厂AI项目经验，怎么答系统设计？
用你做过的项目的架构思维来类比。讲清楚你的思维框架比背答案更重要。你可以说："虽然我没有百万级用户的经验，但我会用以下方式思考扩展性问题..."
Q2：面试官追问很细怎么办？
如果不知道，直接说："这个细节我不太确定，但我的思路是...，我会通过压测/查文档/请教专家来确认具体参数。"诚实 > 蒙混。
Q3：同一道题，每次面试的答案应该不同吗？
框架相同，细节可以随需求不同而变化。在开始时问清楚约束条件（QPS、延迟、成本），这些约束会影响每个技术决策。
Q4：面试中是否要写代码？
系统设计面通常不写完整代码，但写关键接口/伪代码会加分。展示你能把架构转化为代码的能力。
Q5：如何评估自己的系统设计水平？
用这道题自测：你能在45分钟内把今天ChatGPT系统设计题完整讲出来吗？能讲清楚各个组件的选型理由和trade-off吗？如果能，恭喜你已经达到中级水平。
面试前的冲刺清单
基础概念（必须掌握）：
□ RAG的检索流程（向量化→搜索→重排→生成）
□ LLM推理的基本原理（自回归、KV Cache）
□ Token计费和成本估算方法
□ 流式输出（SSE vs WebSocket）的区别和适用场景
架构设计（熟练度）：
□ AI对话系统（ChatGPT-like）
□ 企业知识库（RAG）
□ 推荐系统（召回+排序）
□ AI代码审查系统
深度话题（加分项）：
□ 上下文窗口管理和压缩策略
□ 模型路由和成本优化
□ AI系统的可观测性（四个黄金信号）
□ 从1万扩展到1亿的演进路径
面试软技能：
□ 先澄清需求，再开始设计
□ Think Out Loud，暴露思维过程
□ 主动提trade-off，不只讲优点
□ 承认不确定性，给出解决思路总结
小王的问题，不是技术不够，而是没有系统化的表达框架。
AI系统设计面试考察的不是你能背多少知识点，而是：
- 看到一个新问题，你是否能快速识别关键约束（需求澄清）
- 你是否能用量化思维来验证方案的合理性（容量估算）
- 你是否知道不同技术选型背后的trade-off（架构决策）
- 你是否了解真实工程挑战（成本、容错、可观测性）
用本文的五步框架练习3-5道经典题，你就能在AI系统设计面试中游刃有余。