容量、SLA 与架构演进

• 理解 QPS、并发与延迟的关系
• 能否从 Token 吞吐推算模型调用容量
• 能否结合 Provider 配额推算实例规模

容量估算从业务峰值出发：先预估峰值 QPS（如大促 5000 QPS），结合单次模型调用的平均与尾部延迟（如平均 2s、P95 5s）推算并发数（并发 = QPS × 平均耗时，约 10000 并发）；Token 吞吐 = QPS × 平均输入/输出 Token 数，估算每秒 Token 消耗，据此推算模型调用量与成本。实例规模：网关按并发与 QPS 规划实例数（结合单实例吞吐），模型调用受 Provider 配额约束（每秒 Token/并发上限），需按峰值预留配额或采用多 Provider 分摊。关键是用"峰值 QPS × 耗时 = 并发"与"QPS × Token = 吞吐"两个公式，并预留缓冲（如 1.5~2 倍），同时考虑尾部延迟对排队的放大。

面试官考察"从业务指标推算资源"的数学能力。核心公式是并发 = QPS × 平均耗时，以及 Token 吞吐 = QPS × Token 数。回答强调"峰值 + 尾部延迟 + Provider 配额"汇总量，并预留缓冲。

• 理解 AI 应用 SLA 的四个维度
• 能否设定 SLO 目标
• 能否用错误预算驱动发布

AI 应用 SLA 包含四个维度：可用性（如 99.9%，网关、模型 Provider 整体可用）、P95 延迟（如首字 < 2s、总耗时 < 5s）、任务成功率（如 95% 任务成功返回有效结果）、成本上限（如单次调用成本预算、月成本上限）。SLO 设定要有可测量的指标与阈值，且区分"硬性"（可用性、成本上限）与"弹性"（延迟、成功率）。错误预算分配：定义一定周期内允许的 SLO 违背量（如每个月 0.1% 的可用性错误预算），把错误预算作为发布/变更的"预算"——错误预算耗尽则停止发布、优先稳定性。成本上限也是独立 SLO，超限触发告警与降级。

面试官关注"AI 独有的 SLA 维度"（成功率、成本）与"错误预算驱动发布"。在传统可用性/延迟之上，任务成功率与成本上限是 AI 特有的。回答强调 SLO 可测量 + 错误预算反哺发布门禁。

• 理解 PoC 与生产系统的差距
• 能否逐项补齐评测、安全、成本、可观测
• 能否设计评审关卡

从 PoC 到生产要逐项补齐差距：评测——建立评估集与评测流水线，量化质量指标，设置质量门禁；安全——补权限校验、注入防护、敏感数据脱敏、工具调用的权限与审计；成本——评估单次调用成本、做容量与预算规划、引入缓存与模型路由；可观测——接入质量/延迟/成本/安全指标与 Trace 回放。评审关卡设计为"阶段门禁"：PoC 通过技术验证 → 评测达标 → 安全合规评审 → 容量成本评审 → 灰度发布 → 全量。每道关卡有明确退出条件与负责人，未达标不得进入下一阶段。评审确保"从可用的 Demo 变成可运维、可放量、可负责的生产系统"。

面试官关注"将 PoC 工程化"的完整路径。核心是"评测、安全、成本、可观测"四项补齐 + 阶段门禁。回答强调"每个差距都有可验证的补齐标准"。

• 理解架构演进的不同阶段
• 能否识别各阶段的触发信号
• 能否界定重构边界

AI 应用架构演进分阶段：单 Prompt 直连——验证可行，但触发信号是"质量问题增多、知识过时"时引入 RAG（补充外部知识）；RAG 阶段——触发信号是"多轮记忆、工具调用需求"时引入 Memory 与 Tool，进而演进为 Agent；Agent 阶段——触发信号是"多 Provider、成本失控、复杂编排"时引入网关与编排框架。重构边界：每个阶段都有明确触发信号（质量问题、成本、复杂度、可观测性），避免过早过度设计（过早引入框架增加复杂度）与过晚重构（质量/成本失控）。演进原则是"按需演进、痛点驱动、保持可回滚"。

面试官关注"演进是痛点驱动的"而非"一上来就上全套"。回答强调每个阶段的触发信号（质量→RAG、记忆/工具→Agent、成本/多Provider→网关）与"避免过度设计"的边界。

• 理解各故障的降级路径
• 能否设计演练场景
• 能否验证降级路径有效性

故障演练要覆盖各故障源的降级路径：模型超时——演练重试、切备用模型、降级模板；限流（429）——演练令牌桶拒请求、排队、降级到缓存/快模型/FAQ；向量库故障——演练检索降级到关键词检索或直接返回"无知识"、拒答；工具失败——演练工具降级（返回错误、跳过该工具、提示用户）、重试与人工兜底。验证方式：在测试/影子环境注入故障（模拟超时、限流、服务不可用），检查降级路径是否正确触发、用户是否获得可接受响应、是否无雪崩（重试风暴、队列堆积）。演练后形成降级预案文档，并验证自动回滚与恢复。

面试官关注"故障→降级路径"的对应与验证。回答强调"每个故障源都有明确降级路径"且"通过故障注入验证"，防止"降级逻辑存在但没被验证"。

• 理解成本随流量增长的演变
• 能否识别引入缓存/路由/小模型的时机
• 能否设计成本优化手段

随流量增长，成本结构演变：初期流量小，推理成本占比低，可先不优化；流量增长后，推理成本线性上升成为大头，此时引入缓存（缓存重复查询与 FAQ 命中，减少重复调用）、模型路由（简单任务走快模型/小模型，复杂任务走强模型）、小模型（低频同质任务用专用小模型）。阶段判断：缓存命中率低时补 FAQ 与缓存；成本增速快于流量时引入路由与小模型；当单次调用成本成为瓶颈时，进一步用小模型蒸馏与降级。成本演进与容量演进同步，用"成本占营收/预算比例"决定优化优先级。

面试官关注"成本优化的时机"。回答强调"流量增长 → 成本线性上升 → 按阶段引入缓存/路由/小模型"，并说明每个手段解决什么问题、何时引入。

• 理解数据驻留、模型可用性、延迟的权衡
• 能否设计区域路由
• 能否处理跨区域访问

多区域部署需权衡三方面：数据驻留——合规要求用户数据存本地（GDPR 等），文档、会话、检索数据落在对应区域；模型可用性——某些模型在特定区域不可用或用不同 Provider，需按区域路由到可用模型；延迟优化——就近访问，用户请求路由到最近区域，降低网络延迟。路由设计：按用户所在区域（GeoIP/注册地）路由请求与数据，DNS/边缘路由就近接入；区域内的数据与模型就近组合；跨区域共享逻辑（如全局模型配置）但数据隔离。权衡：数据驻留是硬约束，延迟与模型可用性在合规内优化，必要时用"本地托管 + 区域模型"组合。

面试官关注"数据驻留是硬约束"基础上的权衡。回答强调"区域路由 + 数据本地 + 模型就近可用"，并说明合规优先于延迟。

• 理解旧系统通过工具封装接入的方式
• 能否设计工具适配层
• 能否控制改造边界

旧系统（工单、CRM、ERP）接入 Agent 通过工具封装：把旧系统的 API/能力封装为 Agent 可调用的工具（工具 Schema 声明输入输出、权限、幂等），Agent 通过工具调用读写旧系统，而不是直接改旧系统。改造边界控制：旧系统本体尽量不改，只在其上增加"工具适配层"（封装 API、鉴权、参数映射、错误处理），Agent 侧通过网关调用工具；对旧系统无 API 的能力，用集成中间件或消息/文件接口接入，避免侵入业务逻辑。工具封装要统一权限与审计（Agent 调用旧系统也要过权限与留痕），并控制工具暴露面（只暴露必要能力）。

面试官关注"不改旧系统、只加工具层"的集成边界。工具封装是 Agent 接入旧系统的标准方式，改造边界是"新增适配层而非改核心"。回答强调"最小侵入 + 权限审计统一"。

• 理解流式连接与并发的资源模型
• 能否联合规划线程池、连接池与 Provider 配额
• 能否避免资源耗尽

后端容量模型需联合规划：流式连接数——每个流式请求占用一个长连接（SSE/WebSocket），需估算并发连接数并据此规划连接池与网关连接上限；并发模型调用——并发 = QPS × 平均耗时，需与线程池/虚拟线程匹配，避免线程耗尽；线程池——按并发设置线程池大小，阻塞组（模型调用区）与 IO 组分离，避免互相拖累；连接池——上游（向 Provider 的 HTTP 连接）与下游（客户端连接）池分别规划，池大小随并发预留；Provider 配额——模型调用受 Provider 并发/Token 配额约束，是硬顶，后端容量不能超过 Provider 配额。联合规划的核心是"以 Provider 配额为顶，向下匹配线程池、连接池与网关"。

面试官关注"资源联合规划而非单点"。回答强调"Provider 配额是瓶颈，流式长连接、线程池、连接池都要围绕它规划，并预留缓冲"。阻塞/IO 分离线程池是加分项。

• 理解模型/Prompt 变更的不可控性
• 能否设计灰度放量
• 能否设计快速回滚

模型/Prompt 变更质量波动是 AI 发布的主要风险，用灰度与回滚控制爆炸半径：灰度放量——按 1%→5%→10%→50% 逐步放量，每阶段监控质量/延迟/成本/用户反馈指标，达标才继续放量；可控子集——灰度时把流量按用户/租户/渠道分桶，先在低风险桶（内部用户、小租户）验证；回滚——变更版本化，灰度阶段发现质量回退立即回滚到上一稳定版本（切回旧 Prompt/模型/参数），回滚要快速（配置/版本切换，非重部署）；对比——灰度期间用新旧版本并存对比，用评估集与线上指标量化差异。核心是"增量放量 + 快速回滚 + 版本可追溯"。

面试官关注"AI 变更的爆炸半径控制"。相比普通发布，AI 变更输出不可控，必须"高灰度、快回滚"。回答强调"分桶放量 + 版本化回滚 + 新旧对比"。

• 理解各类数据的存储特征
• 能否选择合适的存储引擎
• 能否划分数据存储边界

AI 应用数据存储选型：会话状态——Redis（快、TTL 自动回收、多实例共享），需要持久化/审计时落关系库；记忆——长短期记忆，短期用 Redis，长期/用户画像用关系库或向量库；缓存——Prompt 结果缓存、检索结果缓存用 Redis（带 TTL 与权限维度）；向量——文档/记忆的向量索引用向量库（Milvus/Pinecone/ES 向量），支持相似度检索；日志——Trace、审计、运营日志用对象存储/日志平台（低成本、海量、可查询）。划分原则：按"读写频率、一致性、生命周期、成本"选型——高频低延迟用 Redis，结构化持久用关系库，非结构化相似检索用向量库，海量日志用对象存储。

面试官考察"存储选型"的合理性。回答强调"按数据特征选型"，并说明各存储的边界与职责。Redis 管会话/缓存，关系库管结构化，向量库管语义检索，对象存储管日志。

• 理解评测基础设施的组成
• 能否设计评估集与流水线
• 能否优化评测成本

评测基础设施：评估集——建设覆盖核心场景、边界、回归样本的评估集（含标准答案与标注），持续扩充与回流；评测流水线——对评估集批量跑评测（质量、延迟、成本、安全指标），产出评分报告，可自动化触发；回归门禁——每次 Prompt/模型/检索变更都跑评测，低于基线阈值则阻断发布，防止质量回退；人工标注平台——对抽样会话/bad case 做人工标注（正确性、错误类型），标注回流评估集与知识库。成本控制：评测耗 Token 大，用"分层评测"——先用小评估集/规则做快速筛查，通过后再用全量评估集；评测用小模型/抽样可测、缓存复用；控制评测频率与样本量，避免每次全量重跑。

面试官关注"评测基建 + 成本控制"。评测是 AI 发布的质量门禁，但成本高，需"分层评测 + 抽样 + 缓存"。回答强调"评估集-流水线-门禁-标注"闭环与成本优化。

• 理解压测负载的维度构造
• 能否设计覆盖 Prompt 长度、并发、输出长度的压测
• 能否定位瓶颈与退化行为

容量压测构造覆盖多维度：Prompt 长度——构造不同输入长度（短/中/长）负载，验证上下文组装与网关处理；并发数——按不同并发梯度（如 10/50/100/200）压测，观察延迟与吞吐变化；输出长度——构造不同 max_tokens 输出负载，测流式与 Token 吞吐。压测同时监控网关（吞吐、限流触发、错误率）、模型（Provider 延迟、限流、配额）、向量库（检索延迟、QPS、内存）。瓶颈定位：观察各组件在并发升高时的延迟/错误/资源变化，找到瓶颈（如网关线程池、Provider 配额、向量库连接）。退化行为：观察过载时是否优雅降级（排队、限流、降级）而非雪崩（重试风暴、连接耗尽）。

面试官关注"压测负载的多维构造 + 瓶颈定位 + 退化行为"。回答强调"覆盖 Prompt 长度/并发/输出长度三维度"并"监控各组件、定位瓶颈、验证过载优雅退化"。

• 理解多 Provider 冗余规避单点
• 能否设计按比例分流
• 能否设计配额耗尽的降级切换

多 Provider 冗余规避单点：把同一业务流量按比例分配到多家模型厂商（如 70/30），避免单 Provider 故障或配额耗尽导致全挂；路由按比例 + 健康状态动态调整（故障 Provider 自动摘除流量）。配额耗尽降级：当某 Provider 配额耗尽（429/配额用尽）时，把流量切换到备用 Provider，或降级到小模型/缓存/FAQ；切换要平滑（先小比例试探备用 Provider 健康再全量切），避免切换风暴。同时统一抽象（网关）屏蔽 Provider 差异，使切换行为与业务代码解耦。多 Provider 的成本与质量也在网关统一统计，按比例分配可结合质量与成本动态调整。

面试官关注"多 Provider 冗余 + 动态切换"。回答强调"按比例 + 健康探测分流，配额耗尽平滑切换，网关抽象隔离差异"。防单点与防切换风暴是重点。

• 理解 AI 成本预算的 FinOps 实践
• 能否把 Token 成本、缓存命中、路由节省纳入看板
• 能否设计异常成本告警

AI 成本 FinOps：把 Token 成本纳入月度预算——按"Token 单价 × 用量 + 缓存 + 向量库 + 人工"估算，设定分团队/分租户/分场景预算；看板纳入成本指标——Token 消耗、单次调用成本、缓存命中率（命中率高则推理成本低）、模型路由节省（走快模型省下的成本）、按租户/渠道/模型分布的成本。异常成本告警：识别爬虫（无身份/高频调用）与重试风暴（重试导致 Token 翻倍），用实时成本监控 + 阈值告警（如单租户成本超预算 x%、Token 消耗突增 n 倍），触发后自动限流、阻断异常来源、降级。异常成本是 AI 特有的风险，需在网关层统计与限流联动。

面试官关注"AI 成本的可视化与异常防护"。回答强调"Token 成本/缓存命中率/路由节省入看板 + 异常成本（爬虫/重试风暴）实时告警与限流联动"。

• 理解架构演进的量化触发信号
• 能否设定指标阈值
• 能否界定评审与责任

架构演进由量化指标触发：调用量——日调用量达到某阈值（如 10 万）时，单点直连不可维护，需引入网关/编排；错误率——错误率持续超阈值（如 >1%）时，需引入重试/限流/多 Provider；成本占比——成本占营收/预算比例超阈值（如 >5%）时，需引入缓存/模型路由/小模型；延迟——P95 超阈值时需引入流式/缓存/模型路由。评审与责任界定：设定"演进触发会议"——当任一指标连续超阈值，触发架构评审，由架构/业务/成本负责人共同决策，明确演进目标、预算与责任人；演进后设置回滚与观测指标，未达标追责。指标阈值要动态校准，避免过早或过晚演进。

面试官关注"用数据驱动演进决策"。回答强调"调用量/错误率/成本占比等指标设阈值触发评审，评审明确责任与目标"。这体现"演进是数据驱动的组织决策"。

• 理解技术选型的驱动因素
• 能否按团队能力与业务规模取舍
• 能否说明自研 vs 开源框架

技术选型按"团队能力 + 业务规模 + 复杂度"取舍：框架——小团队/快速验证用 LangChain/LangGraph（生态全、上手快）；业务复杂、对可控性与稳定性要求高、团队有能力时自研/定制编排（避免框架黑盒与锁死）；网关——规模大、多 Provider 时用成熟网关（如 LiteLLM/自研），规模小可简化；向量库——数据量小用轻量方案（如 ES 向量/内存），数据量大用专用向量库（Milvus/Pinecone）；观测平台——用成熟可观测/LLM 观测平台（LangSmith/自研），复杂场景自研 Trace 与回放。选型原则是"够用即可、避免过度设计、避免框架锁死"——业务可随时迁移，关键能力（网关、评测）尽量自研或抽象。

面试官关注"选型不是拍脑袋，而是按团队与规模"。回答强调"小团队快速 → 开源框架，大业务可控 → 自研/抽象"，并给出网关、向量库、观测的选型依据。

• 理解迁移的三类内容（Provider/向量库/框架）
• 能否设计数据迁移与契约测试
• 能否设计灰度切换

AI 应用迁移设计：数据迁移——向量库迁移需重建索引（re-embedding）并校验向量一致性；Provider 迁移无数据迁移但需适配差异；框架迁移需迁移编排逻辑与评估回归。契约测试——定义稳定契约（请求/响应 Schema、工具/模型接口），新旧实现都必须通过契约测试，保证切换不破坏业务；对模型输出做质量对比（同一请求在新旧 Provider 上对比）。灰度切换——新 Provider/向量库/框架先小流量灰度，对比质量、延迟、成本，达标再逐步放量；保留旧实现可回滚，切换用"双写/双读"或"按比例分流"平滑过渡。整体是"契约先行 + 灰度切换 + 可回滚"。

面试官关注"迁移的工程化"。回答强调"契约测试保证兼容、数据迁移保证一致性、灰度切换保证安全、可回滚保证容错"。这体现"避免供应商锁死"的工程意识。

• 理解"一次请求"叙事的框架
• 能否用数据支撑架构取舍
• 能否把技术与业务结合讲述

答辩技巧是把一次请求讲成完整故事：从入口（鉴权、租户、限流）→ 编排（意图路由、任务分类）→ 上下文（Prompt 组装、历史、检索注入）→ 模型（网关调用、路由、重试）→ 校验（输出安全、内容校验）→ 观测（Trace、指标、成本），把一次请求的完整生命周期串起来，体现系统观。用数据支撑取舍：每个关键决策给量化依据，如"峰值 5000 QPS、单次 2s，故并发约 1 万，需网关限流 + 队列"、"FAQ 命中率 60%，降低推理成本 40%，故分层编排"。技巧：先说约束与数据，再说架构，最后说验证，避免空洞罗列框架；用具体数字与场景让回答更有说服力。

面试官考察"结构化表达"与"数据支撑"。把请求讲成完整链路体现系统观，用数据支撑取舍体现工程理性。回答强调"一次请求串全链路 + 量化依据 + 场景-约束-架构-验证"。