大模型应用工程化面试模块
大模型应用工程化考察的是把不稳定模型接入稳定业务系统的能力。面试官会关注你是否理解模型能力边界，以及你如何用工程手段控制质量、成本和风险。
核心链路
- 请求接入：鉴权、参数校验、业务上下文组装。
- Prompt 构造：系统指令、用户问题、检索资料、工具说明、输出格式约束。
- 模型调用：模型选择、温度、最大 Token、超时、重试、流式。
- 结构化输出：JSON Schema、字段校验、解析失败修复。
- 后处理：敏感词、事实校验、格式化、引用补齐。
- 交付：同步返回、异步任务、消息推送或文件生成。
- 观测：日志、Trace、Token、延迟、失败类型、用户反馈。
- 评测：离线样例集、线上抽检、A/B、人工审核。
高频问题与参考回答
Prompt 工程是不是就是写提示词？
不是。Prompt 工程包括输入变量设计、上下文压缩、输出约束、示例选择、版本管理和评测。生产系统里的 Prompt 应该像代码一样管理版本，变更后用样例集回归，避免某次改词影响线上质量。
结构化输出不稳定怎么办？
先用模型支持的结构化输出或函数调用能力；再用 Schema 校验；解析失败时可以做一次修复请求；仍失败则返回可解释错误或进入人工处理。不要让坏 JSON 直接进入业务库。
流式响应有什么工程问题？
流式能提升体感速度，但要处理断连、取消、部分输出、前端增量渲染、日志聚合和最终结果落库。还要区分“流式展示内容”和“最终可信结果”，有些业务必须等后处理完成后才能确认。
如何做模型选择？
按任务分层。简单分类、改写、摘要可以用小模型或便宜模型；复杂推理、代码、长上下文任务使用强模型；高并发场景要考虑延迟和成本。最好把模型调用封装成可配置策略，支持按场景切换和灰度。
工程追问
- 如何做超时和重试，重试会不会造成重复扣费或重复写入？
- 如何记录一次模型调用的输入、输出、Token 和耗时？
- 用户隐私数据是否会进入第三方模型，如何脱敏？
- 如何防止 Prompt Injection？
- 如何做缓存，缓存粒度是问题、检索结果还是最终答案？
- 如果模型服务不可用，业务如何降级？
- 如何控制单用户预算和全局预算？
项目亮点怎么讲
不要只说“接入了大模型”。可以强调：我把模型调用封装成统一网关，支持不同模型配置；Prompt 有版本号和回归集；所有输出经过 Schema 校验；线上记录 Token 和错误类型；高风险结果必须人工确认；通过缓存和模型分层把成本降低到可接受范围。
面试回答中的指标
| 指标 | 说明 |
|---|---|
| P95 延迟 | 用户体验和系统容量核心指标 |
| Token 成本 | 每次请求、每个用户、每个业务流程的成本 |
| 解析成功率 | 结构化输出是否稳定 |
| 人工通过率 | 生成内容是否满足业务要求 |
| 失败恢复率 | 超时、限流、模型错误后系统是否可恢复 |
| 用户采纳率 | 用户是否真的使用和接受结果 |
Prompt 版本管理
生产 Prompt 应该有版本号、适用场景、输入变量、输出 Schema、变更记录和回归样例。每次改 Prompt 都要知道改了什么、为什么改、影响哪些任务。不要把 Prompt 散落在代码里，也不要让运营随意改线上 Prompt 而没有评测。更稳的方式是把 Prompt 存成配置，发布时经过评测集和灰度。
结构化输出闭环
如果业务需要 JSON、表格、表单字段或动作参数，必须把结构化输出当成接口契约处理。模型返回后先做 JSON parse，再做 Schema 校验，再做业务校验。缺字段、类型错误、枚举不合法、数值越界都不能直接入库。必要时允许一次“修复格式”的模型调用，但不能无限循环。
模型网关设计
成熟团队通常会封装模型网关，而不是业务代码直接调用某个模型。网关负责模型路由、Key 管理、超时、重试、限流、Token 统计、日志脱敏、成本归因和降级。这样换模型、加缓存、做 A/B 或统一监控都更容易。
| 能力 | 设计要点 |
|---|---|
| 路由 | 按任务类型、成本、延迟和质量选择模型 |
| 限流 | 单用户、单业务、全局预算都要控制 |
| 观测 | 记录模型、Prompt 版本、Token、耗时、错误 |
| 降级 | 强模型失败时切换小模型、模板或人工 |
| 安全 | 脱敏、权限、敏感词、Prompt Injection 防护 |
流式与异步任务
聊天类场景适合流式返回，能降低用户体感等待时间；报告生成、文件处理、批量分析更适合异步任务。流式场景要处理用户取消、网络断开、部分输出和最终落库；异步场景要处理任务状态、进度、重试、通知和结果过期。面试中能区分这两类交付方式，会显得更工程化。
线上问题定位
当用户说“AI 回答不对”，不要只看最终答案。要追踪请求参数、Prompt 版本、检索上下文、模型响应、后处理结果和前端展示。很多问题并不是模型能力不足，而是上下文拼错、旧缓存命中、Prompt 变量为空、结构化解析失败或前端展示截断。
结构化输出和函数调用边界
如果模型是在“回答用户”，优先考虑结构化输出，要求结果符合 JSON Schema；如果模型是在“决定调用系统能力”，优先使用函数调用或工具调用。两者都需要 Schema，但语义不同：结构化输出约束最终答案，函数调用约束动作参数。面试时能区分这点，会比泛泛说“让模型输出 JSON”更专业。
Eval-Driven Development
大模型应用应该像软件一样有回归测试。评测集可以包含正常样例、边界样例、攻击样例、拒答样例和业务高价值样例。指标不只看“回答好不好”，还要看结构化字段准确率、工具参数准确率、引用支持率、敏感信息误泄漏率、成本和延迟。每次换模型、改 Prompt、改检索策略，都要跑回归。
LLM 可观测性
生产系统建议按 Trace 记录完整链路。一个 Trace 对应一次用户请求，下面包含检索 span、模型 span、工具 span、后处理 span。每个模型 span 记录模型名、Prompt 模板版本、输入输出 Token、延迟、错误类型和截断状态；每个工具 span 记录工具名、参数摘要、返回状态和耗时。这样才能比较不同 Prompt、模型和 RAG 策略的效果。
安全与隐私设计
大模型应用要默认把用户输入、检索文档和工具返回都视为不可信。安全设计包括输入脱敏、敏感数据分类、Prompt Injection 检测、工具最小权限、输出内容过滤、日志脱敏和数据保留周期。模型网关不应该记录完整敏感原文，至少要支持字段级脱敏和按租户隔离。
发布和灰度
Prompt、模型、检索参数都应该可灰度。发布时先在离线评测集通过，再按小流量用户或内部用户放量，观察错误率、人工接管率、Token 成本和用户反馈。出现问题时能回滚到上一个 Prompt 版本或模型配置，而不是只能临时改代码。
候选人自检清单
- 能否在 2 分钟内讲清楚这个模块解决什么业务问题、为什么不是简单调用模型 API。
- 能否说清输入、处理、模型调用、后处理、评测、监控、回滚的完整链路。
- 能否给出至少一个真实项目指标，例如召回率、命中率、延迟、Token 成本、人工复核通过率或线上失败率。
- 能否解释一个失败案例：问题如何发现、如何定位、怎么修复、修复后用什么指标验证。
- 能否区分“学习过概念”和“真正落地过系统”，面试回答要用具体约束、权衡和数据支撑。