LLMOps 生产运营高频问答
LLMOps 考的不是“会不会调 API”，而是你能不能把一个大模型应用长期稳定地跑在生产环境里：上线前怎么评估，发布时怎么灰度，线上怎么监控，成本异常怎么止血，bad case 怎么回流，模型或 prompt 改坏了怎么回滚。工程原理可继续看 LLMOps 生产运营，网关侧治理可看 模型网关与多模型路由，上线的统一质量门禁可看 LLM 评测与发布门禁实战，在线实验、质量 SLO 与回滚演练见 LLM 线上评测、灰度实验与质量运营面试题，线上事故定位可看 大模型应用线上排障手册。
先给面试官的总览回答
LLMOps 是大模型应用的生产运营体系。它把 prompt、RAG 配置、工具 schema、模型版本、评测集、发布流程、监控告警、成本预算和 bad case 回流放到同一个闭环里管理。
可以用一条链路概括：
需求变更
-> prompt / RAG / 模型 / 工具配置变更
-> 离线评测和安全回归
-> 影子流量或灰度发布
-> 线上质量、成本、延迟监控
-> 告警、降级、回滚
-> bad case 标注和评测集回流高分回答要强调：
- prompt 也是代码：要版本化、评测、灰度、回滚。
- 评测是发布门禁：不能靠“感觉变好了”上线。
- 线上监控要分层：系统指标、模型质量指标、业务指标都要看。
- 成本是生产事故：token 暴涨、循环 Agent、缓存失效都可能烧钱。
- bad case 是资产：线上失败样本要进入评测集、prompt 修复或微调数据。
Q1：LLMOps 和传统 MLOps 有什么区别？
可以从迭代对象、评测方式、成本结构和失败模式四个角度回答。
| 维度 | MLOps | LLMOps |
|---|---|---|
| 主要变更 | 数据、特征、模型训练代码 | prompt、RAG、工具 schema、模型路由、模型版本 |
| 模型来源 | 常由团队训练 | 常用 API、开源模型或 MaaS 平台 |
| 评测方式 | AUC、F1、准确率等确定指标 | golden set、LLM judge、人评、业务指标组合 |
| 成本结构 | 训练成本和推理资源 | token 成本、上下文长度、重试、工具调用、judge 成本 |
| 失败模式 | 数据漂移、特征漂移、模型退化 | 幻觉、提示注入、格式失败、成本暴涨、工具越权 |
| 迭代频率 | 周期较长 | prompt 和配置可能每天变化 |
面试表达：
MLOps 管的是模型训练和部署全生命周期，LLMOps 更强调应用链路的变更治理。大模型应用里 prompt、检索参数、reranker、工具 schema 和路由策略都会改变系统行为，所以它们都要像代码一样进入版本、评测和发布流程。
Q2：上线一个 LLM 应用前要检查什么？
可以直接背这张清单：
| 检查项 | 关注点 |
|---|---|
| 评测集 | 是否覆盖高频问题、核心业务、bad case、高风险边界 |
| 质量基线 | 新版本是否优于或不低于旧版本 |
| 安全集 | 是否覆盖 prompt injection、越权、隐私、危险请求 |
| 成本预算 | 单次 token、日预算、租户配额、异常熔断 |
| 延迟指标 | TTFT、TPOT、P95/P99、超时率 |
| 观测链路 | prompt、检索结果、模型输出、工具调用是否可追踪 |
| 灰度策略 | 小流量、影子流量、A/B、回滚开关 |
| 降级链路 | 备用模型、缓存答案、规则模板、人工兜底 |
| 权限边界 | 工具调用、数据访问、租户隔离、审计日志 |
| 数据回流 | 用户反馈、投诉、转人工、bad case 标注流程 |
面试里可以说：
我不会只问“模型效果好不好”，还会问“出错能不能发现、能不能止血、能不能回滚、能不能复盘”。这是 demo 和生产系统的分水岭。
Q3：prompt 变更怎么安全上线？
prompt 变更可能引起全链路行为变化，不能直接发生产。
推荐流程：
prompt 修改
-> 代码评审 / prompt diff
-> 离线 golden set 回归
-> bad case 回归
-> 成本和延迟评估
-> 影子流量对比
-> 小比例灰度
-> 指标达标后全量
-> 异常一键回滚关键点：
- prompt 要版本化，记录作者、变更原因、适用场景。
- prompt 和模型版本、RAG 参数、工具 schema 要一起记录。
- 每次变更都要跑固定评测集，避免修好 A 场景却改坏 B 场景。
- 高风险业务先跑影子流量，只记录新版本输出，不影响用户。
- 灰度期间看质量、转人工率、投诉率、成本、延迟和安全告警。
高分回答：
prompt 不是文案，而是生产逻辑。prompt 发布要像代码发布一样，有评测门禁、灰度、回滚和审计。
Q4：什么是影子流量？和灰度有什么区别？
影子流量是把真实请求复制一份给新版本处理，但新版本结果不返回给用户，只用于离线对比。
灰度发布是让一小部分真实用户真正使用新版本。
| 方式 | 是否影响用户 | 主要用途 |
|---|---|---|
| 离线评测 | 不影响 | 固定评测集回归 |
| 影子流量 | 不影响 | 看真实输入下的新旧差异 |
| 灰度发布 | 影响少量用户 | 验证真实业务指标 |
| A/B 实验 | 影响实验用户 | 比较业务效果 |
LLM 应用特别适合影子流量，因为真实用户输入往往比评测集更脏、更长、更模糊。影子流量能发现：
- 新 prompt 在真实问题上是否跑偏。
- 新模型是否更爱拒答或更爱编。
- 成本是否因为输出变长而上涨。
- 结构化输出是否更容易解析失败。
- 工具调用是否参数不兼容。
面试表达：
高风险 LLM 变更我会先影子流量，再灰度。影子流量看行为差异，灰度看真实业务影响。
Q5：线上怎么发现“模型变笨了”？
不能只靠用户投诉，因为那已经太晚了。要分三层监控：
系统层
- 请求量、错误率、超时率。
- TTFT、TPOT、P95/P99 延迟。
- input/output token。
- 重试次数、fallback 次数。
- 缓存命中率。
- 工具调用成功率。
质量层
- LLM judge 抽样评分。
- 幻觉率、忠实度、引用准确率。
- 结构化输出 schema 通过率。
- 拒答率、误拒率。
- RAG 检索 Recall@K。
- Agent 任务完成率和工具参数准确率。
业务层
- 问题解决率。
- 转人工率。
- 用户点赞/点踩。
- 投诉率。
- 留存、转化、工单关闭率。
面试表达：
“模型变笨”通常不会只体现在一个指标上。我会把固定评测集的定时探针、线上抽样 judge、用户反馈和业务指标结合起来看趋势，而不是等投诉。
Q6：成本突然翻倍怎么排查？
按“调用量、单次成本、重试和路由”四条线排查。
总成本 = 请求量 × 单次平均 token × 模型单价 × 重试/工具调用放大系数排查顺序：
- 请求量是否上涨：是否有新业务接入、流量峰值、异常脚本、Agent 死循环。
- 输入 token 是否上涨：是否 prompt 变长、历史对话没裁剪、RAG top-k 过大、工具结果未截断。
- 输出 token 是否上涨：是否 prompt 要求变啰嗦、max_tokens 设置过高、模型开始重复。
- 模型单价是否上涨：是否路由失效，简单任务都走了旗舰模型。
- 重试是否上涨：上游超时、结构化输出失败、工具调用失败导致多次重试。
- 缓存是否失效：system prompt 改动导致前缀缓存失效，语义缓存命中率下降。
- judge 成本是否上涨：是否抽样比例过高，或者评测任务进入线上同步链路。
止血动作：
- 按租户和应用熔断高成本调用。
- 降低 max_tokens、RAG top-k、历史窗口长度。
- 简单任务强制走小模型。
- 暂停非核心 judge 和离线批任务。
- 启用缓存或模板兜底。
- 限制 Agent 最大步数和工具调用次数。
面试表达：
成本排查要能从 trace 里按应用、租户、模型、链路聚合 token 和重试。没有 trace，只看账单，很难定位。
Q7：LLM 应用的 trace 应该记录什么？
trace 是 LLMOps 的底座。一次请求至少要记录：
- request id、user id 或租户 id。
- 模型名称、模型版本、供应商。
- prompt 模板版本、system prompt hash。
- 输入 token、输出 token、总成本。
- TTFT、TPOT、总耗时。
- RAG 检索 query、召回文档 id、rerank 分数。
- 工具调用名称、参数、返回状态、耗时。
- 结构化输出 schema 版本和校验结果。
- fallback、重试、降级原因。
- guardrail 命中情况。
- 用户反馈和最终业务结果。
敏感信息要脱敏：
- PII、密钥、合同原文、内部文档片段不应明文长期保存。
- trace 应有访问权限和保留周期。
- 高风险行业要区分调试日志和审计日志。
面试表达：
trace 不是为了好看，而是为了回答“这次为什么答错、为什么变慢、为什么变贵、为什么调用了这个工具”。
Q8：如何设计发布门禁？
发布门禁是把模型变更拦在生产事故前。
常见门禁：
| 门禁 | 示例 |
|---|---|
| 质量门禁 | golden set 不低于旧版本，关键场景必须通过 |
| 安全门禁 | 越狱成功率、隐私泄露、危险请求拒答率达标 |
| 成本门禁 | 平均 token、P95 成本不超过预算 |
| 延迟门禁 | TTFT、P95 延迟不劣化超过阈值 |
| 格式门禁 | JSON/schema 通过率不下降 |
| RAG 门禁 | Recall@K、引用准确率、忠实度达标 |
| Agent 门禁 | 工具选择、参数正确率、任务完成率达标 |
| 回归门禁 | 历史 P0/P1 bad case 不允许复现 |
门禁不是越多越好，要按业务风险分级：
- 低风险问答：质量和成本门禁即可。
- 企业知识库：增加引用、忠实度和拒答门禁。
- Agent 工具：增加权限、幂等、轨迹安全门禁。
- 金融/医疗/法律：增加人工抽检和合规审批。
Q9：线上 bad case 怎么变成资产？
bad case 回流是 LLMOps 的核心飞轮。
线上失败
-> 收集原始问题、上下文、输出、trace、用户反馈
-> 归因：检索、prompt、模型、工具、权限、数据、评测缺口
-> 标注正确行为
-> 加入评测集或训练集
-> 修复 prompt / RAG / 工具 / 模型路由
-> 回归验证常见 bad case 分类：
- 检索没召回。
- 检索召回了但模型没用。
- prompt 指令冲突。
- 工具参数错误。
- 结构化输出解析失败。
- 模型幻觉事实。
- 不该拒答却拒答。
- 该拒答却执行。
- 成本或延迟超标。
- 用户意图识别错。
面试表达：
bad case 不能只存在客服工单或聊天记录里，必须进入评测集和缺陷库。否则同类问题会反复发生。
Q10：如何做多模型 fallback 和降级？
降级链路要考虑质量、成本、可用性和合规。
常见策略：
主模型失败
-> 同供应商备用模型
-> 跨供应商同等级模型
-> 小模型简化回答
-> 缓存答案 / 模板答案
-> 人工接管注意事项：
- 备用模型的 prompt 可能要单独适配。
- schema、Function Calling、工具参数要兼容。
- 安全策略不能因为 fallback 被绕过。
- fallback 可能改变回答风格和质量，要进入评测集。
- 降级命中率要监控，频繁降级说明主链路不稳定。
高风险任务不要自动降级到弱模型执行副作用操作。比如转账、发邮件、删数据、审批通过等，应转人工或只给建议不执行。
Q11：如何治理 prompt injection 和越权工具调用？
LLMOps 需要把安全作为运行时能力，而不是只靠模型自觉。
推荐防线：
- 输入侧检测 prompt injection 和敏感请求。
- RAG 文档做来源可信度和内容隔离。
- system prompt 与用户内容明确分层。
- 工具调用前做权限校验。
- 高风险工具需要审批。
- 工具参数做 schema 和业务规则校验。
- 限制 Agent 最大步数和可调用工具范围。
- 输出侧做敏感信息、合规和越权检查。
- 全部工具调用写审计日志。
面试表达：
模型可以生成调用意图，但不能决定自己有没有权限。权限判断必须在模型外部的确定性系统里做。
Q12：如何从零搭一个最小可用 LLMOps？
不需要一开始做大平台。最小可用版本可以包括：
- 评测集：50-200 条高频问题、核心场景和 bad case。
- 评测脚本：固定 prompt、模型、参数，输出质量和成本报告。
- Trace：记录 prompt、检索、模型输出、工具调用、token、延迟。
- Prompt 版本：prompt 放配置中心或仓库，支持 diff 和回滚。
- 成本日报：按应用、租户、模型统计 token 和费用。
- 告警：错误率、延迟、成本、转人工率、schema 失败率异常告警。
- Bad case 表：用户反馈和失败样本进入标注流程。
一周内可以搭出最小闭环，先解决“看不见、不可回归、不能回滚”的问题。后续再演进到模型网关、MaaS、自动路由、在线评测和数据飞轮。
Q13：LLMOps 系统设计题怎么答？
题目：
设计一个公司级 LLMOps 平台，支撑多个业务应用接入不同大模型，并保证质量、成本和安全可控。
可以按六层回答：
接入层
统一 SDK / API、鉴权、租户隔离
配置层
prompt 版本、RAG 参数、工具 schema、模型路由策略
执行层
模型网关、fallback、重试、限流、缓存、工具调用
评测层
golden set、LLM judge、人评、发布门禁、回归报告
观测层
trace、日志、指标、成本、质量抽样、告警
反馈层
用户反馈、bad case 标注、评测集回流、微调数据沉淀关键追问：
- 多租户预算如何控制？
- prompt 版本和模型版本如何绑定？
- 如何处理供应商故障？
- 如何防止 prompt injection？
- 如何证明新版本比旧版本好？
- 如何回滚已经灰度的问题版本？
- 如何保护 trace 中的敏感数据？
一句话总结：
LLMOps 平台不是单纯观测工具，而是把模型应用变更纳入可评测、可发布、可观测、可回滚的生产体系。
Q14：项目里怎么讲 LLMOps 亮点？
不要只说“我们接了 Langfuse 看日志”。更好的讲法是：
我们把 prompt、模型、RAG 参数和工具 schema 都做了版本化；上线前跑 golden set 和 bad case 回归；上线时先走影子流量和灰度；线上记录 trace、token 成本、延迟、工具调用和用户反馈；成本或质量异常会触发告警和降级；bad case 进入评测集，形成持续改进闭环。
如果是企业知识库：
我们监控检索 Recall@K、引用准确率、忠实度、拒答率和转人工率。每次调整 chunk、embedding、reranker 或 prompt 都必须跑回归，防止召回变差或幻觉上升。
如果是 Agent：
我们监控任务完成率、工具调用成功率、平均步数、越权拦截率和副作用操作审计。超过最大步数或高风险工具触发人工审批。
如果是多模型平台：
我们按租户统计成本，按场景做模型路由，简单任务走小模型，复杂任务走强模型；供应商故障时自动 fallback，但 fallback 版本也必须通过评测门禁。
Q15：常见反面回答
这些回答容易扣分：
- “模型效果不好就改 prompt。”
- “上线后看用户反馈就行。”
- “成本高就换便宜模型。”
- “多模型 fallback 就是换个 URL。”
- “只要接了日志平台就是 LLMOps。”
- “线上 bad case 手工看看就行。”
- “LLM 应用不需要像代码一样测试。”
- “安全交给模型自己拒答。”
修正思路：
- 改 prompt 前先归因，改后跑回归。
- 用户反馈太滞后，要有主动监控和探针。
- 降成本要看路由、缓存、上下文、重试和模型单价。
- fallback 要验证 prompt、schema、工具和安全兼容。
- LLMOps 的核心是变更治理和闭环，不是日志展示。
最后一页速记
| 追问 | 关键词 |
|---|---|
| LLMOps vs MLOps | prompt/RAG/工具 schema 也是变更对象 |
| 上线前检查 | 评测集、安全、成本、延迟、trace、回滚 |
| prompt 怎么发 | 版本化、评测、影子流量、灰度、回滚 |
| 模型变笨怎么发现 | 系统层、质量层、业务层三层监控 |
| 成本翻倍怎么排查 | 请求量、token、模型单价、重试、缓存 |
| trace 记什么 | prompt、检索、输出、工具、token、延迟、版本 |
| 发布门禁 | 质量、安全、成本、延迟、格式、bad case |
| bad case 怎么用 | 归因、标注、回流评测集和训练数据 |
| fallback 怎么做 | 同级备用、跨供应商、小模型、缓存、人工 |
| 安全怎么管 | 权限在模型外，工具调用要审批和审计 |
一句话收尾：
LLMOps 的本质，是把不可控的生成式系统放进可评测、可观测、可回滚、可持续改进的工程闭环里。