Sunqy 文档库

主题

05 工程化与 LLMOps ​

从"跑通 Demo"到"稳定上线"之间的鸿沟，决定了 AI 项目是玩具还是产品。

速览卡 ​

项内容
一句话定位从"跑通 Demo"到"稳定上线"之间的鸿沟，决定了 AI 项目是玩具还是产品
核心内容评测体系、可观测性、成本与性能、网关与容灾、从 POC 到生产的四个跨越
现状判断这一层是当前 AI 落地失败最集中的地方，也是最容易被低估投入的部分
读完能回答怎么知道我的 AI 系统变好还是变坏了？上线前该准备什么？成本怎么控？
相关板块02 增强技术 ｜ 03 Agent ｜ 08 行业落地

一、为什么需要 LLMOps ​

传统软件 vs LLM 系统的根本差异 ​

维度传统软件LLM 系统
行为依据确定性逻辑概率分布
相同输入相同输出可能不同输出
正确性可证明只能评估
失败表现崩溃、报错看似正常地输出错误（最危险）
变更来源只有你的代码你的代码 + 提示词 + 模型版本 + 外部数据
测试方式单元/集成测试评测集 + 打分器 + 回归基线

由此产生的三大难题 ​

1. 无法用测试证明正确，只能评估

你需要一个可重复、可量化的评测机制，否则任何改动都是盲改。

2. 失败是静默的

模型不会抛异常，它会自信地给出错误答案。没有监控就无法发现。

3. 变更来源多且互相耦合

改了提示词、换了模型、更新了知识库、调整了检索参数——任何一个都可能让效果变化，且难以归因。

LLMOps 就是围绕这三个难题建立的工程体系。

二、评测体系（最核心的一环） ​

如果没有评测，你对系统的所有判断都是猜测。

评测的三个层次 ​

层次做法成本可靠性适用
确定性检查格式校验、正则、Schema 验证、代码执行极低高结构化输出场景，优先使用
程序化指标与标准答案比对（精确匹配、BLEU、ROUGE、语义相似度）低中有参考答案的场景
模型评判（LLM-as-Judge）用更强的模型按评分标准打分中中开放式生成，无标准答案

建立评测集的步骤 ​

1. 收集真实样本     从线上日志、用户反馈、业务专家处收集 50～200 条
2. 标注期望输出     人工给出标准答案或评分标准
3. 覆盖边界情况     包括难例、易错例、需要拒答的例
4. 自动化运行       每次改动后自动跑全量
5. 建立基线         记录当前分数作为比较基准
6. 持续扩充         线上发现的新失败案例补充进评测集

关键：评测集必须来自真实业务分布，而不是自己想象的用例。线上 bad case 是扩充评测集的最佳来源。

LLM-as-Judge 的正确用法 ​

要点说明
给明确的评分标准模糊的"判断好不好"不可靠，要有具体的评分维度与锚点
用强模型评判弱模型评判模型应强于被评模型
做人工校准抽样人工复核，验证评判与人工的一致性
注意位置偏差模型常偏好第一个选项，A/B 对比要交换顺序
多次取平均降低单次评判的随机性

[有争议] LLM-as-Judge 的可靠性仍有争议，尤其是对细微质量差异的判别。它适合发现大幅退化，不适合做精细排序。

回归评测（最重要） ​

每次以下改动前，都必须跑回归：

  • 换模型或模型版本
  • 改提示词
  • 改 RAG 的检索/分块/重排配置
  • 更新知识库
  • 微调后上线新版本

没有回归评测就上线，等于闭着眼睛改生产系统。

三、可观测性 ​

需要记录什么 ​

层次内容用途
请求层输入、输出、耗时、Token 数、成本、模型版本成本分析、性能优化
链路层RAG 检索了哪些片段、Agent 调用了哪些工具、每步结果定位问题出在哪个环节
提示层最终发给模型的完整上下文复现问题（最重要）
用户层用户反馈、点赞点踩、重试率、人工接管率真实质量信号

Trace（链路追踪）是必需品：尤其对 Agent 与 RAG 系统，出问题时没有 trace 就无法定位是检索错了、上下文组装错了，还是模型生成错了。

关键指标 ​

类别指标
质量用户满意度、人工接管率、重试率、拒答率、评测集分数
性能首 Token 延迟（TTFT）、总耗时、P95/P99 延迟
成本日均 Token、单次请求成本、单位业务量成本
稳定性错误率、超时率、供应商可用性、降级触发次数
安全敏感内容拦截率、提示注入检测数、越权尝试

用户反馈闭环 ​

最重要的质量信号来源是真实用户反馈，而不是评测集。

用户反馈（点踩 / 投诉 / 人工接管）
    ↓
人工分析归类
    ↓
补充进评测集（作为回归用例）
    ↓
针对性优化（提示词 / 检索 / 微调 / 规则）
    ↓
回归评测验证
    ↓
上线并持续观察

这个闭环跑起来，系统才会持续变好。

四、成本管理 ​

成本的构成 ​

部分说明
输入 Token长上下文、大量检索片段会推高
输出 Token通常单价高于输入
重试与循环Agent 的成本大头，容易失控
缓存未命中重复计算
工程与人力常被忽略，实际往往超过 API 费用
人工审核人工兜底的人力成本

降本手段（按性价比排序） ​

手段收益风险
模型路由高（可降 50%+）需要任务分类机制
提示词精简中高需验证不损失效果
缓存高（前缀缓存、语义缓存）需处理缓存一致性
控制上下文长度中高需平衡信息完整性
减少 Agent 步数高需优化规划质量
批量处理中（部分 API 有折扣）牺牲实时性
小模型替代高需验证质量达标
输出长度约束中可能影响完整性

成本监控 ​

必须做到：

  • 按业务线/功能/用户维度统计成本（而非只有一个总数）
  • 设置预算告警
  • 单次请求与单用户级别的硬上限（防止被刷或死循环）

五、性能与延迟优化 ​

手段说明适用
流式输出边生成边显示，大幅降低感知延迟几乎所有交互场景，强烈建议
前缀缓存复用固定提示部分的 KV Cache系统提示长的场景
选更小的模型直接降低延迟任务简单时
并行化多路检索、多工具并行调用Agent、RAG
减少上下文直接影响 TTFT通用
预计算常见查询预先生成高频固定查询
边缘部署靠近用户对延迟极敏感

感知延迟往往比真实延迟更重要：流式输出 + 进度提示，能让用户容忍更长的等待。

六、网关与稳定性 ​

LLM 网关的价值 ​

在应用与多个模型供应商之间加一层，统一处理：

能力说明
统一接口屏蔽不同供应商的 API 差异
路由与降级主模型不可用时自动切备用
限流与配额按用户/业务线控制用量
缓存减少重复调用
成本归因统一计量
审计日志合规与追溯必需
敏感信息过滤统一的输入输出护栏

在多模型并存的生产系统里，网关几乎是必需品。

稳定性设计 ​

风险应对
供应商故障多供应商备份 + 自动切换
限流排队、退避重试、降级
超时设置超时、部分结果返回
模型行为突变锁定版本 + 灰度发布
成本异常硬上限 + 实时告警
提示注入攻击输入输出过滤

七、从 POC 到生产的四个跨越 ​

这是 AI 项目最容易卡住的地方。

跨越一：从"能用"到"稳定可用" ​

POC 阶段生产要求
挑几个样例跑通全量分布上的稳定表现
人工挑好的输入容忍用户的各种奇怪输入
慢一点没关系有延迟预算与 SLA
出错重跑就行有错误处理与降级

关键动作：用真实全量数据测试，而不是精选样例。

跨越二：从"单次调用"到"长时任务" ​

Agent 类应用特有：

挑战应对
上下文爆炸摘要压缩、状态外置
错误累积关键步骤校验、可回滚
成本失控硬性预算与步数上限
中途失败断点续跑、幂等设计

跨越三：从"单实例"到"规模化" ​

挑战应对
并发与限流队列、退避、配额管理
成本线性增长缓存、路由、批处理
弹性伸缩尤其是自部署场景的 GPU 调度
多租户隔离数据与权限隔离

跨越四：从"能用"到"可维护" ​

挑战应对
无法判断改动是好是坏评测体系
出问题无法定位全链路 trace
知识过期知识库更新流程与责任人
人员依赖文档化、自动化

八、上线前检查清单 ​

类别检查项
质量有评测集与基线分数；边界情况已覆盖；有拒答机制
评测回归评测已自动化；改动有验证流程
可观测完整 trace；关键指标有监控与告警
成本成本可归因；有预算告警；有硬上限
性能延迟达标（关注 P95/P99）；已启用流式输出
稳定性有降级方案；供应商故障有备份；超时已配置
安全输入输出过滤；提示注入防护；敏感数据处理符合政策
合规已确认数据出网合规；用户告知到位；日志留存符合规定
人工兜底有转人工通道；有人工审核机制
回滚能快速回滚到上一版本

九、常见误区 ​

误区事实
"Demo 跑通了，上线就是工作量问题"从 POC 到生产的工程量通常是 POC 的 5～10 倍
"先上线，评测以后补"没有评测就无法迭代，系统会停滞在初始水平
"监控就是看有没有报错"LLM 系统失败是静默的，需要质量指标而非仅技术指标
"成本就是 API 账单"人力、审核、重试、工程投入常常超过 API 费用
"上线后就不用管了"数据分布漂移、知识过期、模型更新都需要持续维护
"评测集分数高 = 用户满意"评测集只是代理指标，必须结合真实用户反馈

十、延伸方向 ​