LLM 应用工程（LLMOps）
目录
1. 概述
LLMOps 是将 LLM 应用从原型推向生产的工程实践。与传统 MLOps 相比，LLM 应用有其特殊性：
- 非确定性：相同输入可能产生不同输出，测试和调试更困难。
- Prompt 即代码：Prompt 模板是核心”程序”，需要版本管理和测试。
- 模型即外部依赖：依赖第三方 API（OpenAI、Anthropic），模型版本变化可能导致行为退化。
- 评估困难：输出质量常需语义判断，不能用精确匹配。
- 成本与延迟不可预测：Token 数波动大，长响应成本高。
LLMOps 覆盖开发→评估→部署→监控→迭代的完整生命周期。
2. Prompt 工程化管理
2.1 Prompt 版本控制
- 将 Prompt 模板纳入版本控制（Git），与代码一起管理。
- 每次修改记录变更原因和评估结果。
- 使用变量插值（Jinja2 等模板引擎），避免硬编码。
- 生产环境锁定 Prompt 版本，不随意变更。
2.2 Prompt 注册表
维护 Prompt 注册表记录：
- Prompt 用途、版本号、创建/修改时间。
- 关联的模型、温度和其他采样参数。
- 预期输入输出格式。
- 评估分数和已知失败案例。
2.3 Prompt 测试
- 黄金集（Golden Set）：维护一组代表性输入和期望输出，每次 Prompt 修改后回归测试。
- 对抗测试：测试边界 case、注入攻击、超长输入、异常字符。
- 快照测试：记录输出快照，检测意外变化。
- LLM-as-Judge：用强模型批量评估输出质量（见
llm-mllm/evaluation.md）。
3. 评估流水线
3.1 离线评估
在部署前建立自动化评估流水线：
- 准备评估集：覆盖典型场景、边界 case、历史故障样本。
- 自动指标：事实正确率、格式合规率、拒答率、Token 数。
- LLM 评判：用 GPT-4/Claude 对输出打分（相关性、正确性、安全性）。
- 人工抽检：定期人工复核，校准自动评估。
- 对比测试：新旧版本在同一评估集上 A/B 对比。
3.2 在线评估
部署后持续收集反馈：
- 显式反馈：用户点赞/点踩、评分、评论。
- 隐式反馈：用户是否复制、改写、重新生成、停留时间。
- 业务指标：任务完成率、转化率、留存。
- 对话级指标：轮次、解决率、人工升级率。
3.3 评估维度
| 维度 | 方法 |
|---|---|
| 正确性 | 事实核查、参考答案对比、代码执行 |
| 相关性 | 用户意图匹配度、LLM-as-Judge |
| 安全性 | 有害内容分类器、红队测试 |
| 延迟 | TTFT、总响应时间 |
| 成本 | 每请求 Token 消耗和费用 |
| 稳定性 | 输出格式一致性、JSON 解析成功率 |
4. 可观测性
4.1 Tracing
LLM 应用的调用链通常包含多次 LLM 调用、检索、工具调用。分布式追踪（Tracing）记录完整执行路径：
- 每次调用：输入、输出、延迟、Token 数、成本。
- 检索调用：查询、返回片段、相关性分数。
- 工具调用：函数名、参数、返回值、执行时间。
- Agent 多步推理：每步的思考、行动、观察。
开源工具：LangSmith、Langfuse、Helicone、Phoenix（Arize）、OpenLLMetry。
4.2 关键指标监控
- 延迟指标：TTFT（首 Token 延迟）、TPS（每秒 Token）、端到端延迟 P50/P95/P99。
- 成本指标：每日/每用户成本、平均每请求成本、Token 缓存命中率。
- 质量指标：用户负反馈率、拒答率、重试率。
- 错误指标：API 错误率、超时率、限流率、JSON 解析失败率。
- 安全指标：有害内容拦截率、越狱尝试次数。
4.3 日志与调试
- 记录完整请求/响应用于问题排查，但需脱敏 PII。
- 按会话和 Trace ID 组织日志，支持端到端重放。
- 标记异常输出（如被安全过滤器拦截的响应）。
- 建立”失败样本库”：收集线上 bad case 纳入评估集。
5. 成本与延迟优化
5.1 成本优化
- 模型路由：简单任务用小模型/便宜模型，复杂任务升级到大模型。
- Prompt 缓存：对重复的系统提示和上下文启用 Prompt Caching（如 Anthropic、OpenAI）。
- 压缩上下文：RAG 结果去重和截断，避免无关内容占用 Token。
- 批量处理：非实时任务用 Batch API（半价）。
- 自托管模型：高流量场景部署开源模型（vLLM + 量化），降低单位成本。
- Token 预算控制：设置最大输出 Token 和上下文长度上限。
5.2 延迟优化
- 流式输出：首 Token 后逐字返回，大幅改善感知延迟。
- 并行调用：独立的 LLM 调用或检索并行执行。
- 投机解码：小模型草稿 + 大模型验证（见
llm-mllm/non-autoregressive.md）。 - 模型选择与部署区域：选择地理上最近的 API endpoint。
- 预计算和缓存：高频查询的结果缓存。
5.3 成本-质量权衡
建立成本-质量曲线，对不同质量要求的场景选择最优配置：
\[\text{目标} = \min \text{成本}, \quad \text{s.t. 质量} \geq \text{阈值}\]6. 灰度发布与回滚
6.1 发布策略
- Canary 发布：先向 1%-5% 用户开放新版本，观察指标。
- A/B 测试：新旧版本同时服务，对比核心指标。
- 影子模式（Shadow Mode）：新版本接收生产流量但不返回用户，仅记录和对比。
- 按用户群分阶段：先内部用户，再早期采用者，最后全量。
6.2 回滚机制
- Prompt 和模型配置支持秒级回滚到上一版本。
- 监控核心指标（错误率、负反馈率、延迟），超过阈值自动回滚。
- 模型提供商 API 版本变化时，锁定版本号（如
gpt-4o-2024-08-06），不盲目使用latest。 - 保留至少前两个稳定版本的配置和评估结果。
6.3 模型变更管理
第三方模型更新可能导致静默退化：
- 模型提供商发布新版本时，在评估集上重新测试。
- 关注模型废弃公告，提前迁移。
- 多供应商策略：抽象模型层，支持在 OpenAI/Anthropic/自托管模型间切换。
7. RAG 运维
7.1 索引管理
- 文档更新时自动增量更新索引，支持版本追踪。
- 定期全量重建索引，防止碎片化和质量退化。
- 监控索引大小、文档数量和覆盖率。
7.2 检索质量监控
- 记录每次查询的检索结果和相关性分数。
- 监控空召回率和低相关性比例。
- 定期人工标注检索质量，调优 embedding 模型和 chunking 策略。
- 设置检索失败的回退策略（如放宽过滤条件、多查询改写）。
7.3 RAG 评估
- 检索指标：Hit Rate、MRR、NDCG、Context Precision。
- 生成指标：Faithfulness（忠于检索内容）、Answer Relevance、引用准确率。
- 端到端评估：最终回答是否正确解决用户问题。
- 工具：RAGAS、TruLens、DeepEval。
详见 llm-mllm/long-context-rag.md。
8. 实践建议
- 将 Prompt、评估集、配置全部纳入 Git 版本控制，实现变更可追溯。
- 建立”评估先行”文化：任何 Prompt/模型变更必须通过评估集回归。
- 从第一天就接入 Tracing 和监控，不要等出问题才补。
- 用配置驱动模型选择，避免在代码中硬编码模型名称，便于快速切换和回滚。
- 维护”失败样本库”并持续扩充——每个线上问题都应转化为评估用例。
- 安全和成本监控与质量监控同等重要，设置预算告警和异常检测。
9. 参考文献
[1] Chip Huyen, Building LLM Applications for Production, 2023.
[2] LangChain, LangSmith Documentation, 2024.
[3] Arize AI, Phoenix: AI Observability, 2024.
[4] S. Es, J. James, L. Espinosa-Anke, S. Schockaert, RAGAS: Automated Evaluation of Retrieval Augmented Generation, arXiv preprint, 2023.
[5] D. Amodei, et al., Concrete Problems in AI Safety, arXiv preprint, 2016.
[6] E. Libkind, et al., A Practical Guide to LLM Operations, arXiv preprint, 2024.
[7] OpenAI, Production Best Practices, 2024.
[8] Anthropic, Prompt Engineering Guide, 2024.
[9] C. M. Bishop, Pattern Recognition and Machine Learning, Springer, 2006.
[10] Google Cloud, MLOps: Continuous Delivery and Automation Pipelines in ML, 2023.
留下评论