Appearance
AI 面试题
AI 系统设计模块：从模型选型、推理服务、成本优化到监控体系、灰度发布、私有化部署、AI+业务解决方案、Agent 平台，全面覆盖 AI 工程化和系统设计的高阶能力。这是中高级 AI 工程师/架构师的核心竞争力。
Q1: 做 AI 应用时如何选型大模型？考虑哪些因素？ 「🟡 中级」
考察点：技术选型的方法论。筛掉只会用 GPT、不会根据场景做选型的人。
参考答案：
大模型选型：根据业务需求、技术约束和成本预算，选择最合适的大模型（或模型组合），是 AI 应用成功的关键第一步。
核心原则：没有最好的模型，只有最合适的模型。选模型不是选最强的，而是选够用且性价比最高的。
选型考虑因素：
1. 模型能力
- 通用能力：综合理解、推理、生成能力（参考 MMLU、MT-Bench 等基准）。
- 特定能力：代码能力（HumanEval）、数学能力（GSM8K）、中文能力（CMMLU、C-Eval）。
- 长文本能力：支持的上下文窗口长度（4K、8K、32K、128K、1M+）。
- 多模态能力：是否支持图像、语音、视频。
- 工具调用能力：Function Calling 效果如何。
2. 价格成本
- 输入价格：每 1K token 的费用（Prompt Token）。
- 输出价格：每 1K token 的费用（Completion Token，通常更贵）。
- 总体成本估算：根据预估调用量计算月费用。
- 注意：输出 token 价格通常是输入的 2-3 倍。
3. 速度性能
- 首 Token 延迟（TTFT）：用户感受到的响应速度。
- 生成速度：每秒生成的 token 数（TPS）。
- 并发能力：同时支持多少请求。
- 对对话类应用，TTFT 很重要；对批处理，吞吐量更重要。
4. 上下文长度
- 短上下文（4K-8K）：简单问答、分类。
- 中上下文（32K）：文档摘要、中等长度对话。
- 长上下文（128K+）：长文档分析、代码库理解、完整书籍。
- 注意：上下文越长，通常价格越贵、速度越慢。
- 长上下文 ≠ 长上下文理解能力（需要验证实际效果）。
5. 多模态支持
- 是否需要图像理解、图像生成、语音交互。
- 多模态能力的质量和价格。
6. 私有化部署
- 是否需要本地部署（数据安全、合规要求）。
- 开源模型可选：LLaMA、Qwen、Mistral、DeepSeek 等。
- 部署成本：GPU 硬件、运维人力。
7. 数据安全与合规
- 数据是否会被用于模型训练（看服务商隐私政策）。
- 是否符合行业监管要求（金融、医疗、政务）。
- 数据驻留要求（数据不出境、不出省）。
8. 生态与成熟度
- API 稳定性和 SLA。
- SDK 和文档质量。
- 社区支持和案例丰富度。
- 服务商的技术支持能力。
9. 可扩展性
- 是否支持微调（定制化需求）。
- 是否有不同参数规模的版本（小、中、大）。
- 功能迭代速度。
主流模型概览：
模型 特点 适用场景 GPT-4 / GPT-4o 综合能力最强，多模态 高质量要求、复杂推理 Claude 3 长上下文好、安全性高 长文档、安全敏感场景 Gemini 多模态强、Google 生态 多模态、视频理解 DeepSeek 性价比高、中文好 中文场景、成本敏感 通义千问 / 文心一言 国内合规、中文优化 国内企业应用 LLaMA / Mistral 等开源 可私有化、成本低 数据敏感、定制化需求 选型策略：
分层调用策略（推荐）：
- 简单任务用小模型（快、便宜）。
- 复杂任务用大模型（准、贵）。
- 用路由模型或规则判断任务复杂度。
- 示例：分类、摘要用 7B 模型；推理、代码用 70B+ 模型。
主备策略：
- 一个主模型 + 一个备用模型。
- 防止单一服务商故障或涨价。
- 避免供应商锁定。
选型决策流程：
明确业务需求 → 确定核心指标 → 筛选候选模型 → 实际测试对比 → 成本评估 → 决策
│ │ │ │ │
任务类型 能力要求 能力初筛 效果测试 TCO 分析
用户量 延迟要求 价格筛选 速度测试 ROI 测算
预算 安全要求 合规筛选 稳定性追问延伸：
- 怎么评估模型在特定业务场景下的效果？
- 开源模型 vs 闭源 API，怎么选？
- 多模型路由怎么实现？有什么方案？
- 模型选型后，后期想换模型，怎么降低迁移成本？
- 怎么判断"模型能力足够"？有什么量化标准？
Q2: 如何设计一个高可用的 LLM 推理服务？ 「🔴 高级」
考察点：系统设计能力。筛掉只会调用 API、对服务端架构没有概念的人。
参考答案：
高可用 LLM 推理服务：能够稳定、高效、低延迟地提供大模型推理能力，满足业务的并发需求，同时具备容错和弹性伸缩能力。
核心设计目标：
- 高可用：服务不中断，故障自动恢复。
- 高性能：低延迟、高吞吐量。
- 高弹性：根据负载自动扩缩容。
- 可观测：全面的监控和告警。
整体架构：
用户请求 │ 负载均衡（LB / API Gateway） │ 路由层（模型路由、流量调度） │ ┌──┴──┬──────┬──────┐ 模型A 模型B 模型C ... 集群 集群 集群 │ │ │ GPU 实例池（vLLM / TGI / Ollama） │ 模型存储（模型文件、LoRA 权重）关键组件设计：
1. 模型服务框架
- vLLM：
- PagedAttention 技术，高吞吐量。
- 连续批处理（Continuous Batching）。
- 支持多种模型（LLaMA、Qwen、Mistral 等）。
- OpenAI 兼容 API。
- TGI（Text Generation Inference）：
- Hugging Face 官方。
- 支持 FlashAttention、量化、动态批处理。
- TensorRT-LLM：
- NVIDIA 官方，GPU 深度优化。
- 性能最高，但配置复杂。
- Ollama：
- 轻量级，本地部署友好。
- 适合开发测试和小规模场景。
- 选型建议：生产环境优先 vLLM 或 TensorRT-LLM。
2. 负载均衡与路由
- 请求级负载均衡：将请求分发到不同的推理实例。
- 模型路由：根据请求的模型参数，路由到对应的模型集群。
- 最少连接 / 最低延迟路由：选择负载最轻的实例。
- 健康检查：自动剔除异常实例。
3. 自动扩缩容
- 指标驱动：
- GPU 利用率（核心指标）。
- 请求队列长度。
- P99 延迟。
- 并发请求数。
- 扩容策略：
- 预热扩容：提前申请资源，避免冷启动。
- 快速扩容，缓慢缩容（防止抖动）。
- 弹性方案：
- K8s HPA（Horizontal Pod Autoscaler）。
- 基于自定义指标的扩缩容。
- 云厂商 GPU 实例弹性伸缩。
4. 多模型管理
- 模型隔离：不同模型部署在不同实例，互不影响。
- 模型热加载：动态加载/卸载模型，提高 GPU 利用率。
- LoRA 多租户：同一基座模型 + 多个 LoRA 权重，按需切换。
- 版本管理：模型版本化，支持灰度和回滚。
5. 缓存策略
- KV Cache：同一会话内缓存 K/V，加速生成。
- 前缀缓存（Prefix Caching）：相同 System Prompt 共享缓存。
- 语义缓存（Semantic Cache）：相似问题直接返回缓存结果。
- 用 Embedding 相似度匹配。
- 命中缓存可大幅降低成本和延迟。
- 响应缓存：完全相同的请求直接返回结果。
6. 降级策略
- 模型降级：大模型不可用时，切到小模型（效果稍差但可用）。
- 功能降级：关闭非核心功能（如图理解、工具调用）。
- 限流熔断：保护后端不被打垮。
- 兜底回复：极端情况下返回预设的友好提示。
7. 高可用保障
- 多可用区部署：单 AZ 故障不影响服务。
- 主备切换：主实例故障自动切到备实例。
- 故障自愈：实例异常自动重启或重建。
- 灰度发布：新版本先切少量流量验证。
- vLLM：
性能优化要点：
- 量化（INT4/INT8）：在可接受的精度损失下提升吞吐。
- 连续批处理：最大化 GPU 利用率。
- FlashAttention：加速注意力计算。
- 模型并行：张量并行 + 流水线并行（超大模型）。
- GPU 选型：A100 / A10 / L40 / L20 / H100，根据预算和性能需求选择。
追问延伸：
- vLLM 的 PagedAttention 原理是什么？相比传统 KV Cache 有什么优势？
- 怎么设计多模型的 GPU 资源调度？（多个模型共享 GPU）
- LLM 推理服务的瓶颈通常在哪里？（GPU 显存？算力？网络？）
- 怎么做推理服务的压力测试？
- 冷启动问题怎么解决？（大模型加载慢）
Q3: 大模型应用的成本优化有哪些方法？ 「🔴 高级」
考察点：成本意识。筛掉只看效果不看成本、缺乏工程思维的人。
参考答案：
LLM 应用成本：主要由 Token 消耗决定（API 调用费用或 GPU 算力费用），随着用户量增长，成本可能成为最大瓶颈。
成本优化目标：在保证效果的前提下，尽可能降低单位请求成本，提升 ROI。
成本优化方法：
1. 模型选型与分层调用
- 按需选择模型：不是所有任务都需要 GPT-4。
- 简单任务（分类、摘要、提取）：小模型即可。
- 复杂任务（推理、代码、创作）：大模型。
- 分层调用（级联策略）：
- 先尝试小模型/便宜模型。
- 小模型效果不好（置信度低）再调用大模型。
- 实现：基于规则、基于分类器、基于模型自我评估。
- 示例：
- 第一层：本地 7B 模型（成本最低）。
- 第二层：中等模型 API（成本中等）。
- 第三层：GPT-4（成本最高，效果最好）。
2. 缓存策略
- 精确缓存：完全相同的输入直接返回缓存结果。
- 适用：FAQ、固定模板生成。
- 语义缓存（Semantic Cache）：
- 用 Embedding 计算相似度，相似问题返回缓存答案。
- 相似度阈值可调节（平衡命中率和准确率）。
- 适用：用户经常重复问的问题。
- 前缀缓存：相同的 System Prompt / 文档上下文共享 KV Cache。
- 适用：RAG 场景、多轮对话。
- 缓存效果：命中率越高，成本越低。好的缓存可以节省 30%-70% 成本。
3. Prompt 优化
- 精简 Prompt：
- 去掉冗余的描述和示例。
- 用更简洁的表达达到同样的效果。
- System Prompt 反复迭代压缩。
- 减少 Few-shot 示例：
- 用最少的示例达到效果。
- 可以用动态示例（只选最相关的 1-2 个）。
- 控制输出长度：
- 限制最大输出 token 数。
- 明确要求"简洁回答"、"用一句话回答"。
- RAG 上下文优化：
- 只检索最相关的 Top-K 文档。
- 上下文压缩（去掉冗余内容）。
- 不要把整篇文档都塞进去。
4. 量化与压缩
- 模型量化：
- INT8 量化：精度损失小，显存减半。
- INT4 量化（GPTQ/AWQ）：显存减至 1/4，精度损失可控。
- 适用：私有化部署场景。
- 知识蒸馏：
- 用大模型蒸馏小模型，用小模型推理。
- 成本可降低 5-10 倍，但需要训练成本。
- 剪枝与稀疏化：
- 移除不重要的权重。
- 实际应用较少，效果有限。
5. 批处理（Batching）
- 批量处理：将多个请求合并处理，提高 GPU 利用率。
- 连续批处理（Continuous Batching）：
- 动态加入和移除请求，不用等一批凑齐。
- 大幅提升吞吐量（2-10 倍）。
- 适用：异步任务、离线处理、非实时场景。
6. 架构优化
- 小模型路由 + 大模型兜底：前面已述。
- 本地小模型 + 云端大模型：
- 简单请求本地处理，复杂请求上云。
- 数据敏感的本地处理，非敏感的上云。
- 专用模型替代通用模型：
- 特定任务用专用模型（如代码用 CodeLlama，数学用 MathLlama）。
- 专用小模型可能比通用大模型效果还好，还更便宜。
7. 使用模式优化
- 流式输出：降低首 Token 感知延迟，提升用户体验，但不直接降低成本。
- 请求合并：前端将多个小请求合并为一个大请求。
- 避免无效调用：
- 前端做输入校验，过滤无效请求。
- 限流策略，防止恶意刷接口。
- 防抖和节流。
8. 成本监控与治理
- 成本看板：按用户、按功能、按模型维度统计成本。
- 预算告警：设置成本阈值，超支告警。
- 配额管理：不同用户/部门有不同的调用额度。
- 成本归因：分析哪些功能、哪些用户消耗最多，针对性优化。
- 按需选择模型：不是所有任务都需要 GPT-4。
成本优化优先级：
| 方法 | 优化幅度 | 实现难度 | 效果影响 | 推荐优先级 |
|---|---|---|---|---|
| 语义缓存 | 30%-70% | 中 | 小 | ⭐⭐⭐⭐⭐ |
| 分层调用 | 30%-60% | 中 | 可控 | ⭐⭐⭐⭐⭐ |
| Prompt 精简 | 10%-30% | 低 | 小 | ⭐⭐⭐⭐ |
| 量化（私有化） | 40%-70% | 中 | 较小 | ⭐⭐⭐⭐ |
| 连续批处理 | 2-10x 吞吐 | 高 | 无 | ⭐⭐⭐⭐ |
| 输出长度控制 | 10%-40% | 低 | 可控 | ⭐⭐⭐ |
| 知识蒸馏 | 5-10x | 很高 | 较大 | ⭐⭐ |
追问延伸：
- 语义缓存的命中率一般能到多少？怎么提升命中率？
- 分层调用中，怎么判断"小模型效果不好"？有什么判断策略？
- 成本优化和效果优化怎么平衡？有什么决策框架？
- 怎么给 AI 应用做成本核算和 ROI 分析？
- 开源模型私有化部署 vs API 调用，哪个更划算？（怎么算这笔账）
Q4: 如何设计 LLM 应用的监控体系？ 「🔴 高级」
考察点：可观测性设计能力。筛掉没有线上运维经验、出了问题不知道怎么排查的人。
参考答案：
LLM 应用监控：对 LLM 应用的性能、效果、成本、安全进行全方位的监控和告警，保障服务稳定运行，及时发现和定位问题。
特殊性：LLM 应用不仅有传统的性能指标，还有"效果"和"成本"这两个独特的监控维度。
四大监控维度：
1. 性能监控（Performance）
- 延迟指标：
- 首 Token 延迟（Time To First Token, TTFT）：用户感知的响应速度。
- 总延迟（End-to-End Latency）：从请求到完整回答的时间。
- 每 Token 生成速度（Tokens/Second）。
- P50 / P95 / P99 延迟（关注长尾延迟）。
- 吞吐量：
- QPS（每秒请求数）。
- TPS（每秒处理 Token 数）。
- 并发请求数。
- 成功率：
- 接口调用成功率。
- 错误率（超时、限流、模型内部错误）。
- 错误分类统计。
- 资源利用率：
- GPU 利用率、显存使用率。
- CPU、内存、磁盘、网络。
- 队列长度（排队请求数）。
2. 效果监控（Quality）
- 用户反馈指标：
- 点赞率（👍 / 总对话数）。
- 点踩率（👎 / 总对话数）。
- 用户满意度评分。
- 纠错率（用户修改回答的比例）。
- 自动评估指标：
- 定期用测试集评估模型/Prompt 版本。
- LLM-as-Judge 自动打分（有用性、相关性、安全性）。
- 幻觉率监控（RAG 场景下的忠实度）。
- 业务指标：
- 任务完成率（如代码生成的编译通过率）。
- 转化率（AI 推荐的采纳率）。
- 留存率（使用 AI 功能的用户留存）。
- 异常检测：
- 输出长度异常（突然变得很长或很短）。
- 重复率异常（大量重复内容）。
- 负面反馈突增。
3. 成本监控（Cost）
- 总体成本：日/周/月总费用。
- 单位成本：
- 单次请求平均成本。
- 每千 Token 成本。
- 每用户平均成本（ARPU）。
- 成本分布：
- 按模型维度：各模型费用占比。
- 按功能维度：各功能模块费用占比。
- 按用户维度：Top N 高消费用户。
- 成本趋势：成本增长率、预测成本。
- 预算告警：接近预算阈值时告警。
4. 安全监控（Security）
- 注入攻击检测：
- Prompt 注入尝试次数。
- 可疑输入模式告警。
- 内容安全：
- 有害输出拦截率。
- 安全审核告警。
- 数据泄露风险：
- 敏感信息输出检测。
- 越权访问告警。
- 异常行为：
- 异常高频调用（可能被刷接口）。
- 非工作时间大量请求。
- 新用户异常高消耗。
- 延迟指标：
监控系统架构：
业务服务 → 日志采集 → 日志聚合（ELK / Loki）→ 可视化（Grafana） │ │ ├→ Metrics 采集 → Prometheus → 告警规则 ──────┘ │ ├→ Trace 链路 → Jaeger / Zipkin │ └→ 效果数据 → 评估服务 → 质量看板关键实践：
1. 全链路追踪（Tracing）
- 每次请求生成唯一 Trace ID。
- 追踪完整链路：入口 → 检索 → LLM 调用 → 后处理。
- 记录每个阶段的耗时、Token 消耗、错误信息。
- 便于定位瓶颈和排查问题。
2. 日志规范
- 每次调用记录：请求 ID、模型版本、Prompt 版本、输入 Token 数、输出 Token 数、延迟、状态码。
- 采样记录完整 Prompt 和输出（用于效果分析）。
- 敏感信息脱敏后再记录。
3. 告警体系
- 基础设施告警：GPU 利用率过高、显存不足、磁盘满。
- 性能告警：P99 延迟超阈值、错误率飙升。
- 效果告警：点踩率突增、用户满意度下降。
- 成本告警：日成本超预算、异常高消耗用户。
- 安全告警：注入攻击高频、异常访问模式。
- 分级告警：P0（电话/短信）、P1（企业微信/飞书）、P2（邮件）。
4. 看板设计
- 总览看板：核心指标（请求量、延迟、成功率、成本、满意度）。
- 性能看板：延迟分布、吞吐量、资源利用率。
- 效果看板：用户反馈趋势、自动评估结果。
- 成本看板：费用趋势、成本分布、预算使用。
- 安全看板：安全事件统计、攻击趋势。
监控维度对比：
| 维度 | 传统应用 | LLM 应用 | 特殊性 |
|---|---|---|---|
| 性能 | 延迟、QPS、错误率 | 同样 + Token 速度、TTFT | 生成式延迟特点 |
| 效果 | 业务指标为主 | 还需监控回答质量、幻觉率 | 效果难以量化 |
| 成本 | 服务器成本为主 | Token 费用占比高 | 调用即计费 |
| 安全 | 传统安全 | + Prompt 注入、内容安全 | 新型攻击面 |
追问延伸：
- 怎么监控"回答质量"？有什么自动化的方法？
- LLM 应用的告警阈值怎么定？（传统应用有历史数据，LLM 没有）
- Trace 中应该记录哪些关键字段？
- 怎么平衡监控的全面性和性能开销？
- 出了问题（如用户反馈回答不好），怎么排查和定位原因？
Q5: AI 应用怎么做 A/B 测试？和传统互联网有什么不同？ 「🟡 中级」
考察点：实验方法的理解。筛掉没有数据驱动思维、不知道怎么验证优化效果的人。
参考答案：
AI 应用 A/B 测试：将用户随机分成两组（或多组），分别使用不同版本的 AI 系统（不同模型、不同 Prompt、不同策略），对比关键指标，验证哪个版本更优。
核心目的：科学地验证每次优化是否真的带来了提升，避免"凭感觉"迭代。
A/B 测试的一般流程：
- 提出假设：这次优化要验证什么？预期什么指标会提升？
- 设计实验：
- 确定实验分组（对照组、实验组）。
- 选择核心指标和次要指标。
- 确定样本量和实验时长。
- 配置上线：
- 配置分流策略（按用户 ID 哈希，保证同一用户始终在同一组）。
- 埋点确保数据准确收集。
- 运行实验：
- 收集数据，监控实验进展。
- 检查两组是否均衡（避免辛普森悖论）。
- 分析结果：
- 计算指标差异。
- 统计显著性检验（p 值、置信区间）。
- 判断是否有显著提升。
- 决策：全量上线 / 回滚 / 继续优化。
AI 应用 vs 传统互联网 A/B 测试的不同：
维度 传统互联网 A/B 测试 AI 应用 A/B 测试 实验对象 UI 布局、文案、功能 模型版本、Prompt、RAG 策略、工具调用 核心指标 点击率、转化率、留存率 回答质量、用户满意度、任务完成率、成本 指标特点 客观、易量化 主观、难量化、需要人工评估 延迟敏感度 页面加载延迟 首 Token 延迟、生成速度 成本差异 不同版本成本基本相同 不同版本成本可能差好几倍 效果稳定性 相对稳定 输出有随机性，同一输入可能不同结果 样本量需求 根据转化率计算 主观评估需要更多样本或人工标注 安全风险 较低 高（新模型可能产生有害输出） AI 应用的实验设计要点：
1. 指标选择
- 业务指标：留存率、转化率、任务完成率（最终价值）。
- 体验指标：
- 主观：用户满意度、点赞率、点踩率。
- 客观：首 Token 延迟、回答长度、对话轮数。
- 质量指标：
- 自动评估：LLM-as-Judge 评分、忠实度、相关性。
- 人工评估：抽样标注质量评分。
- 成本指标：单次请求成本、Token 消耗量。
- 建议：选择 1-2 个核心指标（北极星指标）+ 多个辅助指标。
2. 评估方法
- 在线指标：用户行为数据 + 用户反馈（点赞/点踩）。
- 离线评估：
- 用标准测试集跑两个版本，对比效果。
- 先做离线评估，有提升再做线上 A/B。
- 人工评估：
- 从两组中抽样，让标注员盲评（不知道哪个是实验组）。
- 适合主观质量对比。
- LLM 自动评估：
- 用 GPT-4 等强模型给两组回答打分。
- 快速、低成本，但可能有偏差。
3. 分流策略
- 按用户随机分流：最常用，用户体验一致。
- 按请求分流：同一用户可能遇到不同版本，体验不一致。
- 不推荐用于用户可见的功能。
- 可用于后台处理、不直接影响用户的场景。
- 分层分流：先按用户属性分层（如新老用户、付费免费），再在层内随机。
- 保证两组用户构成一致。
- 注意：
- 分流要保证无偏（随机均匀）。
- 同一用户始终在同一组（稳定性）。
- 样本量要足够，统计才有意义。
4. 统计显著性
- AI 输出有随机性，需要更大的样本量。
- 主观指标（满意度）的方差更大，需要更多样本。
- 建议：提前做功效分析（Power Analysis），估算所需样本量。
5. 安全与灰度
- AI 模型变更风险较高，建议先小流量验证。
- 可以做 1% → 5% → 20% → 50% → 100% 的逐步放量。
- 密切监控安全指标（有害输出率、越狱成功率）。
常见陷阱：
- 过早下结论：实验还没跑够就判断胜负。
- 多重比较问题：看了太多指标，总能找到一个"显著"的。
- 辛普森悖论：总体和分层结论相反。
- 新奇效应：用户因为新鲜而互动多，长期效果未必好。
- 忽略成本：效果提升了，但成本涨了更多，不划算。
追问延伸：
- 怎么确定 A/B 测试需要的样本量？
- AI 应用的 A/B 测试周期一般多长？
- 当两个版本效果差不多（统计不显著）怎么办？
- 怎么同时测试多个变量？（多变量实验 vs A/B/n）
- LLM-as-Judge 可以替代人工评估做 A/B 测试吗？
Q6: LLM 应用怎么做灰度发布？ 「🟡 中级」
考察点：发布策略的掌握。筛掉只会全量上线、不知道风险控制的人。
参考答案：
灰度发布（Canary Release / Grayscale Release）：新版本先向一小部分用户开放，验证效果和稳定性后，逐步扩大范围，最终全量上线。
核心目的：降低发布风险，让问题只影响少数用户，及时发现和回滚。
为什么 AI 应用特别需要灰度发布：
- LLM 输出有不确定性，新版本可能引入意想不到的问题。
- 模型效果可能退化（Regression），新模型不一定在所有场景都更好。
- 安全风险（新模型可能更容易被越狱）。
- 成本变化（新模型可能更贵或更便宜）。
灰度发布的常用策略：
1. 按用户比例灰度
- 最常用的方式。
- 按用户 ID 哈希取模，决定用户进入哪个版本。
- 典型放量节奏：1% → 5% → 20% → 50% → 100%。
- 每个阶段观察一段时间（几小时到几天），确认没问题再放量。
- 优点：简单直观，用户体验一致。
- 缺点：可能漏掉某些特定用户群体的问题。
2. 按用户分层灰度
- 先从特定用户群体开始：
- 内部员工（内测）。
- VIP 用户 / 付费用户。
- 白名单用户。
- 新用户（对老用户无影响）。
- 特定地域、特定设备的用户。
- 优点：风险更可控，可以针对性验证。
- 缺点：样本可能有偏，不能完全代表全量用户。
3. 按功能场景灰度
- 不同功能模块独立灰度。
- 例如：先在简单问答场景上线新模型，验证没问题再推广到复杂推理场景。
- 优点：影响面更小，定位问题更精准。
- 缺点：管理复杂度高。
灰度发布的关键能力：
1. Prompt 版本管理
- 每个 Prompt 模板有版本号。
- 灰度时可以按比例分配不同 Prompt 版本。
- 支持快速切换和回滚。
- 建议：Prompt 变更也走灰度，不要直接全量改。
2. 模型版本管理
- 支持多模型版本同时在线。
- 灰度流量切到新版本模型。
- 模型版本与代码版本解耦。
3. 配置中心
- 灰度比例、分流规则、开关配置等集中管理。
- 动态调整，不需要发版。
- 实时生效。
4. 数据埋点与监控
- 每个请求带上版本标识（版本号、灰度组）。
- 按版本维度统计所有指标。
- 实时对比灰度组和对照组的差异。
- 核心监控指标：
- 性能指标（延迟、错误率）。
- 效果指标（点赞率、满意度）。
- 成本指标（单次请求成本）。
- 安全指标（有害输出率）。
5. 回滚机制
- 一键回滚：发现问题立即切回旧版本。
- 回滚要快（秒级），最大限度减少影响。
- 回滚后保留现场数据，便于事后分析。
灰度发布流程：
1. 准备阶段 ├── 新版本开发完成 ├── 离线评估通过 ├── 确定灰度策略（比例、人群、节奏） └── 配置监控和告警 2. 小流量验证（1% - 5%） ├── 观察核心指标是否正常 ├── 检查错误和异常 ├── 收集用户反馈 └── 确认无明显问题 → 进入下一阶段 有问题 → 回滚 → 修复 → 重新开始 3. 逐步放量（20% → 50%） ├── 扩大样本量 ├── 统计显著性检验 ├── 对比各维度指标 └── 效果符合预期 → 继续放量 效果不及预期 → 分析原因 → 决策 4. 全量上线（100%） ├── 全量切换到新版本 ├── 持续观察一段时间 └── 旧版本保留一段时间（用于回滚兜底）最佳实践：
- 每次灰度只变更一个变量，便于归因。
- 灰度期间不要做其他变更。
- 设定明确的准入准出标准（什么情况下放量，什么情况下回滚）。
- 做好用户预期管理（内测用户提前沟通）。
- 灰度数据要保留，用于后续分析和复盘。
追问延伸：
- 灰度发布和 A/B 测试有什么区别和联系？
- 怎么确定每个灰度阶段的观察时长？
- 灰度过程中发现问题，怎么快速定位原因？
- 多地区、多语言的应用怎么做灰度？
- 灰度比例怎么动态调整？（根据指标自动扩缩）
Q7: 大模型私有化部署需要考虑什么？ 「🔴 高级」
考察点：部署方案的全面性。筛掉对私有化部署没有实战经验、只懂 API 调用的人。
参考答案：
大模型私有化部署：将大模型部署在企业自己的服务器或私有云环境中，数据不出企业，模型完全可控。
适用场景：数据安全要求高、合规限制、需要定制化、调用量很大（成本考虑）等。
私有化部署的核心考量：
1. 硬件选型（GPU / 显存）
- 显存需求估算：
- FP16/BF16：参数量 × 2 字节（如 7B 模型约需 14GB 显存）。
- INT8 量化：参数量 × 1 字节（7B 约 7GB）。
- INT4 量化：参数量 × 0.5 字节（7B 约 3.5GB）。
- 注意：还要留显存给 KV Cache 和计算中间结果（通常需要额外 20%-50%）。
- 常见 GPU 选择：
GPU 显存 适用模型（INT4） 适用场景 RTX 4090 24GB 7B-13B 开发、测试、小流量 A10 24GB 7B-13B 生产小模型 L40S 48GB 13B-34B 生产中模型 A100 40GB/80GB 13B-70B 生产大模型 H100 80GB 34B-70B+ 高端生产 - 多卡方案：
- 大模型需要多张 GPU：张量并行、流水线并行。
- 如 70B 模型 INT4 量化约需 35GB + KV Cache，单张 A100 可跑；FP16 需要 140GB+，至少 2 张 A100。
- CPU + 内存：
- CPU 也可以推理，但速度极慢，只适合调试。
- 足够的内存用于加载模型和数据预处理。
- 成本估算：
- GPU 硬件采购成本（A100 约数万元~十几万元/张）。
- 服务器、机房、电力、制冷。
- 运维人力成本。
- 对比 API 调用成本，看多久能回本。
2. 模型选型与量化
- 开源模型选择：
- 中文能力强：Qwen（通义千问）、DeepSeek、Baichuan、ChatGLM。
- 英文能力强：LLaMA、Mistral、Gemma。
- 综合性价比：Mistral、Qwen 系列。
- 许可证：商用需要注意协议（LLaMA 需申请，Qwen/Mistral 宽松）。
- 量化方案：
- GPTQ：4-bit 量化，精度损失小，需要校准数据。
- AWQ：4-bit 量化，保留重要权重，精度更好。
- GGUF：llama.cpp 格式，支持 CPU/GPU 混合推理。
- 选型建议：生产环境优先 GPTQ 或 AWQ，开发调试可用 GGUF。
3. 推理框架
- vLLM：高吞吐量，PagedAttention，生产首选。
- TGI：Hugging Face 官方，生态好。
- TensorRT-LLM：NVIDIA 官方，性能最优，配置复杂。
- Ollama：简单易用，适合开发和小规模。
- llama.cpp：轻量级，支持 CPU 推理，适合边缘设备。
- Text Generation WebUI：功能全，适合测试和 demo。
4. 性能优化
- 量化：前面已述。
- 连续批处理：提升吞吐量。
- FlashAttention：加速注意力计算。
- KV Cache 优化：PagedAttention、量化 KV Cache。
- 投机采样：用小模型加速大模型解码。
- 模型并行：多卡张量并行 + 流水线并行。
- 算子优化：Fused kernel、CUDA Graph。
5. 数据安全
- 模型安全：
- 模型文件的权限控制。
- 模型水印（防止被盗）。
- 访问鉴权（API Key、用户认证）。
- 数据安全：
- 数据不出内网。
- 输入输出日志的加密和访问控制。
- 敏感数据脱敏。
- 安全防护：
- Prompt 注入检测。
- 输出内容安全审核。
- 访问频率限制。
6. 运维监控
- 基础设施监控：GPU 利用率、显存、温度、功耗。
- 服务监控：QPS、延迟、错误率、Token 消耗。
- 日志系统：请求日志、错误日志、审计日志。
- 告警体系：性能告警、资源告警、安全告警。
- 高可用：多实例、负载均衡、故障自动恢复。
- 备份与恢复：模型文件、配置数据备份。
7. 成本与 ROI
- 成本构成：硬件采购 + 机房 + 电力 + 运维 + 模型授权。
- 对比 API 成本：
- 调用量小时，API 更划算。
- 调用量大时，私有化可能更便宜。
- 需要做 TCO（总拥有成本）测算。
- 回本周期估算：硬件成本 ÷ 每月节省的 API 费用。
- 隐性成本：运维复杂度、人才招聘、故障风险。
- 显存需求估算：
私有化部署 vs API 调用决策：
数据安全要求极高？ → 私有化
↓ 否
调用量很大（月消耗 > 硬件成本/12）？ → 私有化
↓ 否
需要深度定制（微调 + 专属能力）？ → 私有化
↓ 否
快速上线、团队小？ → API 调用追问延伸：
- 7B / 13B / 70B 模型分别需要什么硬件配置？
- 怎么评估私有化部署的性能是否达标？（压测方法）
- 多模型共享 GPU 资源怎么调度？
- 大模型推理服务的 SLA 怎么定？（可用性、延迟承诺）
- 混合部署（部分用 API，部分私有化）怎么设计？
Q8: 如何设计一个 AI + 业务的场景解决方案？ 「⭐ 专家」
考察点：产品思维和解决方案能力。筛掉只会技术、不懂业务、无法从 0 到 1 设计方案的人。
参考答案：
AI + 业务场景设计：将 AI 技术与具体业务问题结合，设计出有价值、可落地、可规模化的解决方案。这是 AI 工程师从技术走向业务的核心能力。
核心原则：从业务出发，而不是从技术出发。AI 是手段，解决业务问题才是目的。
方法论：六步法
第一步：业务痛点分析
- 深入理解业务：
- 业务流程是什么？关键环节有哪些？
- 各环节的人效、成本、痛点是什么？
- 业务的核心指标（KPI）是什么？
- 识别高价值痛点：
- 痛点影响面大（涉及很多人、很多钱）。
- 痛点发生频率高（天天发生，而不是偶尔）。
- 现有解决方案效果差或成本高。
- 常用方法：
- 用户访谈（一线员工、管理者、客户）。
- 业务流程梳理和价值流分析。
- 数据分析：哪个环节瓶颈最严重。
- 反例：为了用 AI 而用 AI，找伪需求。
第二步：AI 可行性评估
- 技术可行性：
- 这个问题 AI 能解决吗？
- 当前大模型能做到什么程度？准确率/效果如何？
- 有没有类似的成功案例？
- 需要哪些数据？数据是否可得？
- 效果基线：
- 人工处理的准确率、效率、成本是多少？
- AI 能达到多少？超过人工了吗？
- 最低可用标准是什么？（60 分还是 90 分？）
- 风险评估：
- 技术风险：效果不达标怎么办？
- 数据风险：数据不够、数据质量差怎么办？
- 合规风险：是否涉及隐私、监管问题？
- 快速验证（PoC）：
- 不要上来就做完整系统。
- 用最小成本做原型，验证核心效果。
- 1-2 周出 demo，验证可行性。
第三步：ROI 测算
- 成本估算：
- 研发成本（人力、时间）。
- 基础设施成本（GPU、服务器、API 费用）。
- 运营成本（数据标注、维护、迭代）。
- 培训和推广成本。
- 收益估算：
- 降本：减少人力、提高效率带来的成本节约。
- 增效：提升产能、增加收入。
- 提质：减少错误、提升质量。
- 创新：创造新的业务模式和收入来源。
- ROI 计算：
- 投资回收期（多久回本）。
- 年 ROI 比例。
- 净现值（NPV）。
- 决策标准：
- ROI > 阈值 → 值得做。
- 战略价值高但 ROI 不明确 → 小步快跑，试点验证。
- ROI 为负 → 不做或换方案。
第四步：方案设计
- 整体架构：
- 技术架构（前端、后端、AI 服务、数据层）。
- 业务流程再造（AI 介入后流程怎么变）。
- 人机协作模式（AI 做什么，人做什么）。
- 核心功能模块：
- AI 能力模块（对话、生成、分析、决策）。
- 业务系统集成（对接现有系统）。
- 数据管道（数据采集、清洗、标注、反馈）。
- 管理后台（配置、监控、评估）。
- 技术选型：
- 模型选型（参考 Q1）。
- 框架选型（LangChain / LlamaIndex / 自研）。
- 部署方案（云 API / 私有化）。
- 安全与合规：
- 数据安全、内容安全、隐私保护。
- 行业监管要求（金融、医疗、教育）。
第五步：试点验证
- 选择试点场景：
- 选择相对独立、影响面可控的业务场景。
- 痛点明确、易于衡量效果。
- 有愿意配合的业务团队。
- 试点范围：
- 限定用户群体（一个团队、一个部门）。
- 限定使用时间（1-3 个月）。
- 限定功能范围（核心功能）。
- 验证指标：
- 业务指标：效率提升、成本节约、质量改善。
- 用户指标：满意度、接受度、使用率。
- 技术指标：准确率、稳定性、性能。
- 试点复盘：
- 效果是否达到预期？
- 遇到了什么问题？
- 用户反馈如何？
- ROI 是否符合预期？
第六步：规模化推广
- 推广策略：
- 从一个团队 → 一个部门 → 全公司。
- 从一个场景 → 多个场景 → 平台化。
- 组织保障：
- 跨部门项目组。
- 业务方深度参与。
- 培训和支持体系。
- 持续迭代：
- 数据飞轮：用得越多，效果越好。
- 定期评估和优化。
- 新场景拓展。
- 平台化：
- 将通用能力沉淀为 AI 平台。
- 赋能更多业务场景。
- 深入理解业务：
方案设计框架图：
业务痛点 → 可行性评估 → ROI 测算 → 方案设计 → 试点验证 → 规模化
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
找对问题 技术可行 值得投入 怎么实现 验证效果 放大价值追问延伸：
- 怎么说服业务方用 AI？（技术推业务经常遇到的问题）
- PoC 阶段怎么控制范围和时间？（避免 PoC 变成完整项目）
- AI 项目失败的常见原因有哪些？怎么避免？
- 怎么衡量一个 AI 业务应用的"成功"？有哪些标准？
- 从"做一个 AI 功能"到"做一个 AI 产品"，有什么本质区别？
Q9: 什么是 AI Agent 平台？核心架构是什么？ 「⭐ 专家」
考察点：平台化思维和架构设计能力。筛掉只会做单点应用、没有平台化和系统化思维的人。
参考答案：
AI Agent 平台：提供 Agent 的开发、部署、管理、运维一体化能力的平台，让开发者可以快速构建、配置和发布 AI Agent 应用，而不需要从零搭建。
核心价值：降低 Agent 开发门槛，提高复用性，统一管理和治理，加速 AI 应用落地。
为什么需要 Agent 平台：
- 单个 Agent 应用容易做，但做多个就会有大量重复工作。
- 企业内多个团队都在做 Agent，需要统一的基础设施。
- Agent 的工具、知识、记忆、权限需要统一管理。
- Agent 的监控、安全、合规需要统一治理。
核心架构（八大模块）：
┌─────────────────────────────────────────────────────────┐ │ 应用层（前端 / API） │ │ Web 控制台、移动端、API 网关、开发者 SDK │ ├─────────────────────────────────────────────────────────┤ │ Agent 编排层 │ │ 可视化编排、工作流引擎、Agent 模板、版本管理 │ ├─────────────────────────────────────────────────────────┤ │ 能力层 │ │ ┌─────────┬─────────┬─────────┬─────────┐ │ │ │ 大模型 │ 工具市场 │ 知识库 │ 记忆系统 │ │ │ │ 管理层 │ │ 管理 │ │ │ │ └─────────┴─────────┴─────────┴─────────┘ │ ├─────────────────────────────────────────────────────────┤ │ 运行时层 │ │ Agent 运行时、调度引擎、执行器、消息总线 │ ├─────────────────────────────────────────────────────────┤ │ 治理层 │ │ 权限管理、安全审核、监控运维、计费计量 │ └─────────────────────────────────────────────────────────┘1. 大模型管理层（LLM Management）
- 模型接入：支持多家模型服务商（OpenAI、Anthropic、国内厂商、开源模型）。
- 模型路由：自动选择最优模型、故障自动切换。
- 模型配置：温度、最大 Token、Top-p 等参数配置。
- 模型版本管理：模型升级、回滚、A/B 测试。
- 统一 API：封装不同厂商的差异，提供统一接口。
2. Agent 编排层（Agent Orchestration）
- 可视化编排：拖拽式搭建 Agent 流程，低代码/无代码。
- 工作流引擎：
- 支持顺序、分支、并行、循环等流程控制。
- DAG 调度引擎。
- 状态管理和持久化。
- Agent 模板：
- 预置常用 Agent 模板（客服、助手、分析师、程序员等）。
- 模板市场，分享和复用。
- Prompt 管理：
- Prompt 模板版本管理。
- Prompt 调试和测试。
- Prompt A/B 测试。
3. 工具市场（Tool Marketplace）
- 内置工具：搜索、代码执行、计算器、文件读写等。
- 自定义工具：用户可以接入自己的 API、数据库、内部系统。
- 工具注册：工具描述、参数定义、权限配置。
- 工具分类和搜索：便于发现和使用。
- 工具调用审计：谁调用了什么工具、什么时候、结果如何。
4. 知识库管理（Knowledge Base）
- 数据接入：支持文档、网页、数据库、API 等多种数据源。
- 文档处理：解析、分块、清洗、向量化。
- 向量检索：集成向量数据库，支持相似度搜索。
- 知识管理：知识分类、标签、权限、版本。
- 检索优化：混合检索、重排序、查询改写。
5. 记忆系统（Memory System）
- 短期记忆：对话历史，会话内记忆。
- 长期记忆：
- 用户画像（偏好、历史行为）。
- Agent 经验（从交互中学习）。
- 向量存储的知识记忆。
- 记忆管理：
- 记忆提取（相关度、时效性）。
- 记忆遗忘（不重要的逐渐淡忘）。
- 记忆总结（对话摘要）。
6. 运行时层（Runtime）
- Agent 运行时：执行 Agent 逻辑的容器。
- 调度引擎：任务调度、并发控制、队列管理。
- 执行器：工具调用、模型调用、代码执行的具体执行。
- 消息总线：各模块之间的通信和事件驱动。
- 弹性伸缩：根据负载自动扩缩容。
7. 权限与安全（Governance）
- 用户管理：用户、角色、组织架构。
- 权限控制：
- Agent 级别的访问权限。
- 工具级别的调用权限。
- 知识库的读写权限。
- 安全审核：
- Prompt 注入检测。
- 输出内容安全审核。
- 敏感数据脱敏。
- 审计日志：所有操作和调用的完整记录。
8. 监控运维（Observability）
- 性能监控：延迟、吞吐量、成功率。
- 效果监控：回答质量、用户反馈、任务完成率。
- 成本监控：Token 消耗、费用统计、预算管理。
- 日志与追踪：全链路 Trace，问题排查。
- 告警系统：异常检测和告警通知。
- 数据分析：使用分析、行为分析、效果分析。
平台 vs 单点应用的区别：
维度 单点 Agent 应用 AI Agent 平台 目标 解决一个具体问题 支撑多个 Agent 应用 用户 终端用户 开发者 + 终端用户 复用性 低，每个应用独立开发 高，能力模块可复用 扩展性 差，新增功能需要改代码 好，配置化 + 插件化 治理能力 弱，分散管理 强，统一管理和审计 建设成本 低（短期） 高（短期） 长期价值 有限 可规模化，价值大 建设路径建议：
- 先做 1-2 个具体的 Agent 应用，验证价值。
- 提炼通用能力，沉淀为平台组件。
- 逐步完善平台能力，开放给更多团队使用。
- 形成生态，内外部开发者共建。
追问延伸：
- 怎么判断一个团队/公司需要做 Agent 平台，还是直接用现有框架？
- Agent 平台和 Dify / Coze 这类产品有什么区别？
- Agent 平台的技术难点在哪里？（调度、状态管理、多租户、安全）
- 怎么设计 Agent 平台的多租户架构？
- 未来 Agent 平台会朝着什么方向发展？