生产级 AI 应用架构与答题框架

共 20 题
📑 题目列表 20 题
#
★★★

1. 从 Prompt Demo 到生产系统最大的差距是什么,完整架构应包含哪些层次(入口、编排、上下文、RAG/Memory/Tool、网关、评测观测)

从 Prompt Demo 到生产系统最大的差距是什么,完整架构应包含哪些层次(入口、编排、上下文、RAG/Memory/Tool、网关、评测观测)?

  • 理解 Demo 与生产环境的本质差异(质量、安全、成本、可观测)
  • 能否完整、分层地描述生产级 AI 应用架构
  • 对每个层次职责边界的清晰认知

从 Prompt Demo 到生产系统的最大差距在于 Demo 只解决了"单次、单用户、无约束、无治理"的可行性验证,而生产系统必须同时满足质量稳定、权限安全、成本可控与可观测可回滚。一个完整的生产级架构通常划分为六层:入口层(API 网关/鉴权/租户识别/限流降级)、编排层(意图路由、任务逻辑、状态机)、上下文层(Prompt 组装、指令、历史会话、业务数据注入)、能力层(RAG 检索、Memory 记忆、Tool 工具调用)、模型网关层(统一 Provider 接入、模型路由、重试、限流、成本统计)以及评测观测层(离线评测、影子流量、在线监控、Trace 回放)。各层职责清晰、可独立演进,才能支撑灰度发布与故障定位。

重点在于"分层"而非"堆框架"。Demo 的核心缺陷是缺少治理设施——没有权限、没有配额、没有评测、没有监控。回答时把一次请求拆成"入口→编排→上下文→能力→网关→模型→校验→观测"的链路,既体现架构视野,又为后续的容量、安全、评测等子问题提供了讨论框架。

// 生产请求链路的简化示意(Java 侧流程编排)
public class AiRequestPipeline {
    public AiResponse handle(AiRequest req) {
        Tenant ctx = auth.resolveTenant(req);          // 入口:鉴权+租户
        TaskType type = router.classify(req);           // 编排:任务分类
        List<ContextItem> ctxItems = contextBuilder.build(req, ctx); // 上下文组装
        Prompt prompt = promptAssembler.compose(type, ctxItems);
        ModelResult res = gateway.call(type, prompt, ctx); // 网关:路由+重试+限流
        res = outputValidator.check(res, ctx);           // 输出校验(安全/合规)
        observer.trace(req, prompt, res);                // 观测:Trace 记录
        return res;
    }
}
#
★★★

2. 一次 AI 请求从入口到模型返回的完整链路应如何拆解,鉴权、租户隔离、任务分类、上下文组装、模型调用、输出校验与 Trace 记录各由谁负责

一次 AI 请求从入口到模型返回的完整链路应如何拆解,鉴权、租户隔离、任务分类、上下文组装、模型调用、输出校验与 Trace 记录各由谁负责?

  • 是否能把一次请求拆成职责清晰的环节
  • 每环节归属的组件/层是否合理
  • 能否说明各环节之间的依赖顺序与数据流

一次请求可拆解为七个环节:入口网关负责鉴权与租户隔离(识别调用方身份、判定可用租户与配额);编排层负责任务分类(判断是问答、推理还是工具调用任务);上下文组装负责把用户问题、历史会话、业务数据与 RAG 检索结果组装为 Prompt;模型网关负责模型调用(路由、重试、限流、成本统计);输出校验负责安全与合规检查(过滤注入、敏感信息、越权工具调用);Trace 记录在请求全链路埋点,负责观测与回放。各环节由不同组件负责,但共享同一 TraceId,保证端到端可追踪。

关键是把"鉴权/租户"放在最前面,因为后续所有环节都依赖租户上下文;"输出校验"放在模型调用之后,用于拦截模型返回的非法内容;"Trace 记录"贯穿全程而非作为一个独立阶段。这种按数据流拆解的方式,能体现对系统边界的清晰理解。

#
★★★

3. 设计 AI 应用时,如何先明确业务目标与约束(用户规模、延迟、成本、数据、权限、质量目标),再决定架构取舍

设计 AI 应用时,如何先明确业务目标与约束(用户规模、延迟、成本、数据、权限、质量目标),再决定架构取舍?

  • 是否具备先定义约束、后做设计的工程思维
  • 能否从用户规模、延迟、成本、数据、权限、质量目标等维度量化约束
  • 能否根据约束推导合理的架构取舍

设计应遵循"约束先行"原则:先量化业务目标的六个维度——用户规模(预估 QPS、并发)、延迟(P95 可接受值)、成本(单次调用成本预算、月预算上限)、数据(数据量、来源、更新频率、是否含敏感数据)、权限(角色、租户、字段级权限)、质量目标(准确率、拒答率、可接受误答率)。每个约束都影响架构取舍:例如用户规模大且延迟敏感,则优先引入缓存与模型路由;成本敏感,则用快模型兜底、慢模型做高价值任务;权限复杂,则必须做索引层与生成层的双重过滤;数据涉密,则需私有化部署或数据脱敏。回答时先列约束,再给取舍,体现"先算账再设计"。

面试官最警惕"上来就报框架名"。先明确约束能证明你理解业务大于技术,并能把约束映射到具体架构决策。例如"后端延迟 P95<2s 且调用量大"直接推导出"必须流式返回 + 缓存 + 模型路由";"多租户且权限细粒度"则推导出"检索层权限过滤 + 输出二次校验"。

#
★★★

4. 同步、流式、异步三种响应模式在对话、报表、批处理等场景如何选型,各自的状态管理与取消传播如何设计

同步、流式、异步三种响应模式在对话、报表、批处理等场景如何选型,各自的状态管理与取消传播如何设计?

  • 理解三种响应模式各自的适用场景
  • 能否说明状态的存储位置与生命周期
  • 能否设计取消传播(客户端断开、超时、主动取消)

三种模式各有适用场景:同步模式适合快速、低延迟、结果简短的请求(如单次 QA、简单查询),请求阻塞等待结果,状态内聚在请求上下文;流式模式适合对话与长文本生成(SSE/WebSocket),首字延迟关键,状态分片推进,取消传播通过客户端断开或 AbortController 触发;异步模式适合报表、批处理、长耗时任务,任务立即返回 taskId,前端轮询或 WebSocket 推送结果,状态持久化在任务表(pending/running/success/failed),支持结果缓存与重试。三种模式的状态管理差异在于:同步状态在内存、流式在连接期、异步在持久化存储。取消传播都要提供统一取消接口,并保证下游(模型调用、工具执行)能感知取消。

选型依据是"延迟敏感度 + 任务时长 + 并发"。对话选流式(用户感知快),报表选异步(耗时且可复用),简单查询选同步。取消传播是易被忽略的点:流式要处理客户端中途断开,异步要区别"取消队列"与"取消已执行任务",且取消要沿调用链传播,避免模型调用继续计费。

#
★★★

5. RAG、Memory 与 Tool 在系统设计中为何必须分开治理,混在一起会带来哪些质量、权限与成本问题

RAG、Memory 与 Tool 在系统设计中为何必须分开治理,混在一起会带来哪些质量、权限与成本问题?

  • 理解 RAG、Memory、Tool 三种能力的本质差异
  • 能否说明混合治理带来的质量、权限、成本风险
  • 能否给出分层治理的方案

RAG、Memory、Tool 三者本质不同,必须分开治理:RAG 是"外部知识检索",需要索引、权限过滤、引用溯源与版本更新;Memory 是"会话记忆",需要状态裁剪、超时回收与隐私保护;Tool 是"外部动作执行",需要权限校验、参数校验、审计留痕与幂等控制。若混在一起,会产生三类问题:质量上,工具返回与检索结果混入上下文导致 Prompt 混乱、引用无源;权限上,检索知识与工具执行没有独立的权限边界,可能诱发越权工具调用;成本上,无法分别统计检索、记忆与工具调用的开销,也无法单独缓存与限流,导致成本失控。因此设计上应把三类能力作为独立模块,分别有数据模型、权限模型与缓存策略。

回答的核心是"职责单一"与"治理边界"。面试官希望通过此题考察你是否理解这三类能力在数据来源、权限模型与生命周期上的本质差异。分开治理后,RAG 的检索可命中率独立观测、Memory 的裁剪独立、Tool 的审计独立,运维与安全都能更清晰。

#
★★★

6. AI 应用的可观测性设计,需要采集哪些指标(质量、延迟、成本、安全)与执行轨迹,如何支撑事后回放与归因

AI 应用的可观测性设计,需要采集哪些指标(质量、延迟、成本、安全)与执行轨迹,如何支撑事后回放与归因?

  • 是否知道 AI 应用可观测性与传统系统的差异
  • 能否完整列出质量、延迟、成本、安全四类指标
  • 能否设计 Trace 轨迹与回放归因机制

AI 应用的可观测性在传统指标之上,还需增加"质量"与"成本"维度。质量指标包括准确率、拒答率、引用正确率、用户反馈(点赞/踩)、采纳率;延迟指标包括首字延迟(TTFT)、总延迟(P50/P95)、模型调用耗时、检索耗时;成本指标包括 Token 消耗、单次调用成本、模型分布、缓存命中率;安全指标包括注入探测命中、敏感信息泄露、越权工具调用。执行轨迹(Trace)需记录完整链路:输入/输出、Prompt 版本、模型版本、参数、检索结果、工具调用参数与结果、重试与降级事件。配合全局 TraceId 存入 Trace 存储,即可实现事后回放(还原一次请求的完整上下文)与归因(定位是检索、Prompt 还是模型导致的错误)。

传统 APM 只关注延迟与错误,AI 应用还要关注"输出质量"与"成本"这两个业务维度。回答的关键是强调"Trace 要能回放",即所有影响输出的因素(Prompt、模型、检索、工具)都要落库,否则事后无法定位问题。这也要求在 Trace 中一并记录 Prompt 等版本信息,确保回放时可还原当时的上下文。

#
★★★

7. AI 应用的成本结构如何预估(推理、向量库、人工审核、重试),上线前如何做容量与预算规划

AI 应用的成本结构如何预估(推理、向量库、人工审核、重试),上线前如何做容量与预算规划?

  • 能否拆解 AI 应用的成本构成
  • 能否依据 QPS、Token 量、模型单价估算推理成本
  • 能否把向量库、人工审核、重试等隐性成本纳入预算

AI 应用的成本主要由四部分构成:推理成本(Token 消耗 × 模型单价,取决于输入/输出 Token 量与 QPS,是最大头)、向量库成本(存储与检索量,随文档量与查询量增长)、人工审核成本(AI 输出复核、转人工处理的时长与人力)、重试与降级成本(超时重试、降级到更强模型带来的额外 Token)。预算规划应自上而下:先估业务峰值与平均 QPS,估算输入/输出 Token 量,按"输入 Token 单价 × 输入量 + 输出 Token 单价 × 输出量"与缓存命中率推算推理成本;再叠加向量库按吞吐付费、人工审核按工时、重试按比例预留缓冲。最后设定成本上限与告警阈值。

成本估算的关键是"把 Token 当作计费单位"并按公式计算,而非笼统说"选便宜模型"。面试时给出估算公式与示例参数(如"日均 100 万请求、平均 2K 输入/1K 输出 Token、命中率 30%")能显著加分。同时要强调缓存、模型路由、小模型是降低成本的主要手段。

#
★★★

8. AI 应用的发布流程,离线评测、影子流量、灰度放量、自动回滚如何串联成发布门禁

AI 应用的发布流程中,离线评测、影子流量、灰度放量、自动回滚如何串联成发布门禁?

  • 理解 AI 应用发布与普通发布的核心差异(依赖评测)
  • 能否描述离线评测→影子→灰度→回滚的完整门禁链路
  • 能否设计自动回滚的触发条件

AI 应用发布因模型与 Prompt 输出不确定,必须用"评测门禁"串联整个流程。流程为:离线评测——先在评测集上对新版本(Prompt/模型/参数)跑全量指标(准确率、拒答率、引用正确率),达到阈值才允许进入下一步;影子流量——把线上真实流量复制一份打到新版本,不返回给用户,用于对比新旧输出质量与成本;灰度放量——按 1%→5%→10%→50% 逐步放量,每个阶段同时监控质量、延迟、成本与用户反馈指标;自动回滚——当观测指标(错误率、P95 延迟、拒答率、成本)超过阈值时自动回滚到上一稳定版本。门禁的核心是"每个阶段都有可验证的退出条件",未达标即阻断。

类比普通软件的 CI/CD 但强调"评测"这个特殊环节。普通发布验证的是功能正确性,AI 发布验证的是输出质量,因此"离线评测集 + 影子对比 + 灰度观测"构成了 AI 特有的发布门禁。自动回滚需建立在"旧版本可随时恢复 + 版本可追溯"之上,即发布时保留上一稳定版本并支持随时切换。

#
★★★

9. 模型网关在架构中的位置与职责,业务代码为何不应直连 Provider,网关与 BFF 的边界如何划分

模型网关在架构中的位置与职责,业务代码为何不应直连 Provider,网关与 BFF 的边界如何划分?

  • 理解模型网关的职责(统一接入、路由、重试、限流、成本、观测)
  • 能否说明业务代码直连 Provider 的风险
  • 能否清晰划分网关与 BFF 的边界

模型网关位于业务层与模型 Provider 之间,职责包括:统一 Provider 接入(隔离各家 API 差异)、模型路由(按任务/成本/质量选模型)、重试与容错(限流、超时、故障切换)、限流与配额、成本统计、安全审计与观测埋点。业务代码不应直连 Provider,因为直连会导致:多家厂商 API 差异侵入业务代码、重试/限流/降级逻辑重复实现、成本无法统一统计、变换 Provider 时改动面大。网关与 BFF 的边界:BFF 面向客户端做业务编排与数据适配(聚合多个后端、裁剪返回字段),网关面向模型做底层能力抽象(模型调用、路由、容错),二者不在同一层,BFF 调用网关而非直接调用 Provider。

网关是"模型接入的稳定层",BFF 是"面向客户端的适配层"。回答时强调网关把"模型这一外部不稳定依赖"变成内部稳定抽象,使业务代码只依赖自己的接口契约,从而支持多 Provider、灰度与成本治理。这也是架构演进题中"引入网关"的触发点。

#
★★★

10. Prompt 与上下文版本管理,如何保证一次线上输出可追溯到 Prompt、模型、参数、检索与工具版本

Prompt 与上下文版本管理,如何保证一次线上输出可追溯到 Prompt、模型、参数、检索与工具版本?

  • 理解版本管理对可观测与归因的意义
  • 能否设计包含 Prompt/模型/参数/检索/工具版本的完整版本上下文
  • 能否把版本信息写入 Trace 支持事后追溯

要保证一次输出可追溯,需把影响输出的所有因素版本化并随请求一起记录。具体做法:Prompt 模板版本化(存于配置中心,变更即生成新版本号),模型与参数版本化(模型名、temperature、max_tokens 等),检索版本化(索引版本、embedding 模型版本、检索参数),工具版本化(工具实现版本、参数 Schema 版本)。每次请求在 Trace 中记录一份完整的"版本快照"(promptVersion、modelVersion、params、retrievalVersion、toolVersion),与输入输出一起落库。事后回放时,只需按版本快照重新加载即可还原当时的上下文,从而定位是 Prompt、模型还是检索变化导致的质量波动。

核心是"把版本作为 Trace 的一部分,而非事后追溯"。类比"代码可回滚到 commit",AI 输出也要能"回滚到版本快照"。回答时强调版本快照由请求组装阶段统一生成并随 TraceId 落库,离线评测时也可用同一版本快照在评测集上复算,打通"线上→评测"闭环。

#
★★★

11. AI 应用的安全设计,Prompt 注入、越权工具调用、敏感数据泄露在架构层面如何用代码强制而非提示词防御

AI 应用的安全设计,Prompt 注入、越权工具调用、敏感数据泄露在架构层面如何用代码强制而非提示词防御?

  • 理解"提示词防御不可靠,需代码强制"的安全原则
  • 能否针对三类攻击给出架构级防御
  • 能否把权限校验下沉到引擎/执行层

安全设计必须用代码强制而非依赖提示词。针对 Prompt 注入:在入口层做输入清洗与可疑模式检测,在输出层对模型输出做校验(检测是否试图执行未授权操作),对工具参数做白名单校验,并用"系统指令与用户输入隔离"的提示结构。针对越权工具调用:在工具执行层做强制权限校验(工具不在用户可调用白名单内直接拒绝),对模型请求的工具调用参数做二次校验,关键操作(改单、退款)需二次确认与审计。针对敏感数据泄露:在检索层用权限过滤决定返回哪些文档,在输出层做敏感信息脱敏与检测(手机号、身份证、密钥),并对数据做租户级隔离。核心原则是"安全校验发生在执行引擎层,模型既不能越权也拿不到无权数据"。

面试官强调"代码强制而非提示词"是因为提示词可被注入绕过。回答的关键是把三类攻击分别落到"执行层校验":注入靠输入输出双向校验、越权靠工具层权限校验、泄露靠检索层权限过滤 + 输出脱敏。三层都发生在代码层,与模型无关,因此不可被提示词绕过。

#
★★★

12. AI 应用的容量与限流设计,模型并发与 QPS 峰值的关系,网关层的令牌桶/排队如何设计,过载时如何优雅降级?

AI 应用的容量与限流设计,模型并发与 QPS 峰值的关系,网关层的令牌桶/排队如何设计,过载时如何优雅降级?

  • 理解 QPS、并发与平均/尾部延迟的关系
  • 能否设计令牌桶/排队限流
  • 能否设计过载时的优雅降级策略

容量设计的关键是理解"QPS 峰值 ≠ 并发",因为模型调用是长耗时操作,并发数 = QPS × 平均耗时。例如单次模型调用 2s、QPS 峰值 100,则并发需约 200,且要按拓扑公式预留 Provider 配额。限流在网关层用令牌桶实现:按 QPS 与租户配额发放令牌,平滑突发流量;当令牌耗尽时进入排队(队列设长度与超时),排队超时则拒绝。过载时优雅降级:优先保证高价值任务(如人工客服高优先级),将低价值任务降级为缓存命中、快模型、模板回复或转人工;对已排队的请求可返回"排队中"提示。降级要分级且有明确触发条件,避免降级风暴。

面试官常考"并发与 QPS 的关系",这是容量题的核心公式。令牌桶解决突发平滑,排队解决峰值吸收,降级解决过载保护。回答时强调"峰值 + 平均耗时 → 并发"的推算,以及"重试风暴"的防范(限流 + 指数退避),体现对 Provider 配额与客户端重试的联合考虑。

#
★★

13. AI 应用的高可用设计,模型 Provider 故障、限流与降级时,用户体验如何保持(降级模板、排队、转人工)

AI 应用的高可用设计,模型 Provider 故障、限流与降级时,用户体验如何保持(降级模板、排队、转人工)?

  • 理解 Provider 故障时的容错路径
  • 能否设计降级模板、排队、转人工等体验兜底
  • 能否说明降级的触发与恢复

高可用设计的目标是 Provider 故障时用户仍能获得可接受的服务。故障时采用多级兜底:故障转移(切到备用 Provider 或小模型);降级模板(返回预设的友好文案,如"当前服务繁忙,请稍后再试",或给出 FAQ 兜底答案);排队(高峰期让用户排队并提示预估等待);转人工(对话场景自动转人工客服)。触发条件要明确(连续超时/限流/错误率达阈值),降级要分级(先降配置、再降模型、最后转人工),且要防止重试风暴(指数退避与熔断)。恢复时自动探测 Provider 健康并逐步回切。

高可用关键是"降级仍保体验"。面试官想听的不只是"有备用",而是"降级路径的分级设计"——从轻微降级(缓存命中)到重度降级(转人工)。同时要强调熔断(快速失败)避免故障 Provider 拖垮网关,以及降级动作的可观测与可回切。

#
★★

14. 多租户 AI 应用的隔离设计,上下文、缓存、记忆、检索与成本的租户隔离分别在哪些层实现

多租户 AI 应用的隔离设计,上下文、缓存、记忆、检索与成本的租户隔离分别在哪些层实现?

  • 理解多租户隔离的多个维度
  • 能否在正确的层实现各维度的隔离
  • 能否防止跨租户数据泄漏与成本串扰

多租户隔离要在多个层分别实现:上下文隔离在请求组装层(每个请求注入租户 ID,Prompt 只含本租户数据);缓存隔离在缓存层(缓存 key 带租户维度,避免跨租户命中);记忆隔离在会话存储层(Memory 按租户+会话分桶,互不可见);检索隔离在索引层(每个租户维护独立文档集合或带租户过滤的倒排/向量索引,检索时强制带租户条件);成本隔离在网关层(按租户统计 Token 与配额,独立限流与预算)。隔离的核心原则是"租户 ID 贯穿全链路,每层都强制校验",防止只靠前端显示或一人误传租户 ID 导致数据泄漏。

面试官关注"隔离落在哪一层"而非笼统说"做隔离"。检索层隔离是防泄漏的关键,缓存层隔离是防成本/数据串扰的关键,成本层隔离是防单一租户拖垮成本的关键。回答时强调"租户 ID 是强制上下文,各层注入与校验"。

#
★★

15. AI 应用的需求评审,哪些功能适合 AI、哪些应走规则或数据库,如何用“确定性优先”原则划分边界

AI 应用的需求评审,哪些功能适合 AI、哪些应走规则或数据库,如何用"确定性优先"原则划分边界?

  • 理解"确定性优先"的需求划分原则
  • 能否判断功能适合 AI 还是规则/数据库
  • 能否给出 AI 与规则混合的边界方案

"确定性优先"原则是指:凡能用规则、数据库查询、确定性算法可靠实现的功能,就优先用确定性方案,只有规则/数据库无法覆盖、需要开放理解或生成的场景才用 AI。例如:订单状态查询、库存查询、金额计算走数据库与规则;FAQ 精确匹配走检索;而语义理解、开放问答、摘要、意图模糊的对话才用 AI。对适合 AI 的功能,还要评估其风险(误答成本、合规要求),高风险功能即使能用 AI 也要加规则兜底或人工复核。边界划分的产出是一个"决策矩阵":功能类型 × 确定性 → 方案(规则/检索/AI/混合)。

"确定性优先"是 AI 需求评审的核心原则,能避免"什么都用 AI"的过度设计。面试官考察你是否能理性判断 AI 的边界——AI 适合"模糊、开放、生成"型任务,确定性任务用 AI 既不省成本也不可靠。回答时给出"规则/检索/AI/混合"的划分逻辑,并强调高风险功能的人工兜底。

#
★★

16. AI 应用的错误处理与重试策略,超时、限流(429)、内容审查拦截等错误如何分类,重试的幂等与指数退避如何设计?

AI 应用的错误处理与重试策略,超时、限流(429)、内容审查拦截等错误如何分类,重试的幂等与指数退避如何设计?

  • 理解 AI 错误的分类(可重试/不可重试)
  • 能否设计指数退避与抖动
  • 能否保证重试幂等与防止重试风暴

AI 错误应按可重试性分类:可重试错误包括超时(timeout)、限流(429 Too Many Requests)、瞬时网络错误(5xx/连接断开),这类重试可能成功;不可重试错误包括参数错误(4xx 非限流)、内容审查拦截(模型输出被安全策略拒绝)、鉴权失败、上下文超长,重试无意义。重试策略用指数退避(base 增加重试次数幂次 + 随机抖动),并设置最大重试次数与总超时预算。幂等性通过给每次请求生成唯一 requestId,重试时复用同一 ID,避免重复执行副作用(如工具调用重复扣费)。客户端要配合限流(令牌桶)防止重试风暴,Provider 侧 429/Retry-After 要尊重。

面试官考察"错误分类 + 重试策略"。关键是区分"可重试"与"不可重试"——429 与超时可重试,内容审查拦截与上下文超长不可重试。重试附带的幂等与防风暴是加分点,尤其工具调用重复执行会产生副作用,必须幂等。

#
★★

17. 有状态对话与无状态设计的取舍,会话状态存储(内存/Redis/DB)如何选择,上下文窗口限制下长会话的状态裁剪与超时回收?

有状态对话与无状态设计的取舍,会话状态存储(内存/Redis/DB)如何选择,上下文窗口限制下长会话的状态裁剪与超时回收?

  • 理解有状态与无状态设计的取舍
  • 能否按规模选择内存/Redis/DB 存储
  • 能否设计上下文裁剪与超时回收

有状态对话需要保存会话状态,取舍在于"状态存储位置"与"一致性":单机 demo 可用内存,但多实例部署时内存态无法水平扩展且会丢失;生产环境用 Redis 保存会话上下文(快、支持 TTL 自动回收),需要持久化/审计/跨会话分析时再落 DB。上下文窗口限制下,长会话需状态裁剪:可采用滑动窗口(保留最近 N 轮)、摘要压缩(把历史压缩成摘要)、关键信息抽取(只保留订单号、意图等槽位),裁剪策略按业务需要。状态超时回收:Redis 设置 TTL(如 30 分钟无交互即回收),超时后提示用户重新开始;有状态业务(如订单流转)需与状态机结合,超时可能触发会话终结或人工介入。

关键取舍是"无状态便于水平扩展,有状态需要外部存储"。回答强调:真正常态放 Redis(带 TTL),需要审计/跨设备才落 DB;裁剪要与上下文窗口联动,避免超长截断;超时回收要区分"可丢弃的临时上下文"与"需持久化的业务状态"。

#
★★

18. 模型路由与分级,如何按任务复杂度、成本与质量把请求路由到不同模型(快模型/强模型),路由策略如何用评估数据校准?

模型路由与分级,如何按任务复杂度、成本与质量把请求路由到不同模型(快模型/强模型),路由策略如何用评估数据校准?

  • 理解模型分级(快/慢/强/弱)与路由维度
  • 能否设计任务分类路由规则
  • 能否用评估数据校准路由阈值

模型路由按任务复杂度、成本与质量把请求分派到不同模型:简单任务(FAQ、短问答、分类)走快模型(低延迟低成本),复杂任务(推理、长文生成、代码)走强模型(高质量高成本)。路由的输入是任务特征(任务类型、上下文长度、意图置信度、用户等级),输出是模型选择。路由规则可静态(按任务类型映射)或动态(按输入复杂度打分)。路由策略需用评估数据进行校准:对真实请求样本,衡量"走快模型是否达质量阈值",统计各模型在同一任务上的质量分与成本,据此调整路由阈值;同时建立回归集,防止路由调整导致质量回退。路由也可做"级联兜底"——先快模型,置信度不足再升级强模型。

模型路由是"成本与质量权衡"的核心手段。面试官考察你是否知道"路由要校准"——不能拍脑袋定阈值,而要用评估集对比各模型质量分与成本,动态调整分界。级联兜底(快模型置信度不足升级)是常见且有效的路由策略。

#

19. AI 系统设计常见扣分点,上来就报框架名、不定义约束、不画数据流、不聊治理,应如何避免

AI 系统设计常见扣分点,上来就报框架名、不定义约束、不画数据流、不聊治理,应如何避免?

  • 知道 AI 系统设计面试的常见扣分点
  • 能否用规范的回答结构规避
  • 理解"约束→数据流→治理"的答题顺序

常见扣分点有四类:一是上来就报框架名("用 LangChain")而不讲业务与约束,显得只堆技术;二是不定义约束(用户规模、延迟、成本、权限、质量目标),导致设计无依据;三是不画数据流,答不出"一次请求怎么走",无法体现系统观;四是不聊治理(评测、版本、灰度、可观测、成本),漏掉生产系统最关键的环节。避免方法:用规范结构回答——先「场景与约束」(量化目标),再「架构与数据流」(一次请求从入口到模型的完整链路),再「关键设计」(RAG/记忆/工具/网关/安全等),最后「治理与演进」(评测、发布、可观测、成本)。整个过程若有数据用数据支撑取舍。

这道题考察的是"答题方法论"。面试官明确指出扣分点,意在考察你是否具备系统化设计思维。回答结构"场景-约束-架构-验证"正是规避这些扣分点的标准打法,框架名只作为实现细节在后半段提及。

#

20. AI 应用架构的答题框架,如何用"场景-约束-架构-验证"四段式组织系统设计回答,避免只罗列框架名?

AI 应用架构的答题框架,如何用"场景-约束-架构-验证"四段式组织系统设计回答,避免只罗列框架名?

  • 掌握四段式答题结构的完整内容
  • 能否把每段落到具体设计内容
  • 理解"验证"环节对 AI 系统的重要性

四段式答题框架把回答组织为四个阶段:场景——明确系统要解决的问题、目标用户与核心功能;约束——量化用户规模、延迟、成本、数据、权限、质量目标等设计约束;架构——给出分层架构与数据流,说明一次请求如何从入口经编排、上下文、能力、网关到模型再回到用户,并展开关键设计(RAG、记忆、工具、安全、限流);验证——说明如何评测、灰度、监控与回滚,证明方案在质量、安全、成本上达标。该结构避免"只罗列框架名",因为框架名只在"架构"阶段作为实现细节出现,且每个设计决策都由"约束"与"验证"支撑。

四段式是结构化表达,核心是"约束驱动设计、验证闭环"。面试官要的是"先想清楚为什么,再决定怎么做",而不是"用什么框架"。把"验证"作为独立一段,体现了 AI 应用"输出不确定、必须评测"的独特治理要求。