跳转至

LLMOps综述

1. LLMOps vs 传统MLOps

1.1 什么是LLMOps

LLMOps（Large Language Model Operations）是MLOps在大语��模型时代的演进，专注于LLM应用���开发、部署和维护。

1.2 核心差异

维度 传统MLOps LLMOps
模型开发 从头训练/微调 Prompt工程/RAG/微调
数据管理 训练数据+特征 Prompt模板+知识库+对话历史
版本控制 模型权重+代码 +Prompt版本+上下文配置
评估方式 固定指标（准确率等） +主观质量+安全性+幻觉检测
成本结构 训练为主 推理成本显著（按token计费）
部署方式 模型文件部署 API调用/自部署模型服务
监控重点 数据漂移/模型退化 +幻觉监控+Prompt注入检测+成本追踪
迭代速度 周/月级别 分钟/小时级别（Prompt修改）

1.3 LLMOps的新增挑战

  • Prompt管理: 如何版本化、测试、优化Prompt
  • 上下文管理: RAG知识库维护、上下文窗口优化
  • 成本控制: Token使用追踪、模型选择策略
  • 评估困难: 开放式生成难以自动评估
  • 安全治理: Prompt注入防御、输出安全过滤

2. LLM应用开发生命周期

2.1 生命周期概览

graph LR
    A[原型开发] --> B[评估测试]
    B --> C[部署上线]
    C --> D[监控运维]
    D --> E[迭代优化]
    E --> A

    A --> |Prompt设计| A1[System Prompt]
    A --> |RAG构建| A2[知识库]
    A --> |模型选择| A3[API/开源模型]

    B --> |自动评估| B1[基准测试]
    B --> |人工评估| B2[标注团队]
    B --> |安全测试| B3[���队测试]

    C --> |策略| C1[A/B测试]
    C --> |策略| C2[金丝雀发布]

    D --> |指���| D1[质量/延迟/成本]
    D --> |告警| D2[幻觉/注入/异常]

2.2 阶段一：原型开发

关键活动:

  1. 问题分析和方案选择
  2. Prompt设计和迭代
  3. RAG系统构建（如需要）
  4. 模型选择（API vs 开源）
  5. 功能验证

工具选择:

  • Playground: OpenAI Playground, Anthropic Console
  • 开发框架: LangChain, LlamaIndex
  • 快速原型: Streamlit, Gradio

2.3 阶段二：评估测试

评估维度:

  • 功能正确性
  • 输出质量（流畅性、相关性）
  • 安全性（幻觉、偏见、有害内容）
  • 性能（延迟、吞吐量）
  • 成本

评估方法:

  • 自动评估: RAGAS, DeepEval, Promptfoo
  • LLM-as-Judge: 用强模型评估弱模型输出
  • 人工评估: 标注团队打分
  • 红队测试: 安全专家攻击测试

2.4 阶段三：部署上线

部署策略:

2.5 阶段四：监控运维

监控指标:

  • 质��指标: 用户满意度、回答准确性
  • 性能指标: 延迟（TTFT、总延迟）、吞吐量
  • 成本指标: Token用量、API调用费用
  • 安全指标: 幻觉率、注入攻击检测

2.6 阶段五：迭代优化

优化方向:

  • Prompt优��: 根据失败案例改进Prompt
  • 知识库更新: 添加/更新RAG文档
  • 模型升级: 切换到更新/更好的模型
  • 架构优���: 调整Pipeline各环节

3. 关键差异详解

3.1 Prompt管理

传统ML没有"Prompt"的概念，而LLMOps中Prompt是核心资产：

Prompt版本管理:
v1.0: 基础版Prompt → 质量: 72%
v1.1: 添加Few-shot示例 → 质量: 78%
v1.2: 优化System Prompt → 质量: 82%
v1.3: 添加输出格式约束 → 质量: 85%

3.2 上下文管理

上下文窗口优化：
- 系统Prompt: ~500 tokens（固定）
- Few-shot示例: ~1000 tokens（根据任务动态）
- RAG上下文: ~2000 tokens（检索结���）
- 对话历史: ~1000 tokens（滑动窗口）
- 用户输入: ~500 tokens
- 留给输出: ~3000 tokens
总计: ~8000 tokens

3.3 成本控制

# Token用量追踪
class TokenTracker:
    def track_usage(self, request_id, model, prompt_tokens, completion_tokens):
        cost = self.calculate_cost(model, prompt_tokens, completion_tokens)
        self.db.insert({
            "request_id": request_id,
            "model": model,
            "prompt_tokens": prompt_tokens,
            "completion_tokens": completion_tokens,
            "cost": cost,
            "timestamp": datetime.now(),
        })

    def calculate_cost(self, model, prompt_tokens, completion_tokens):
        rates = {
            "gpt-4": {"input": 0.03/1000, "output": 0.06/1000},
            "gpt-3.5-turbo": {"input": 0.0005/1000, "output": 0.0015/1000},
        }
        rate = rates[model]
        return prompt_tokens * rate["input"] + completion_tokens * rate["output"]

3.4 评估挑战

传统ML可以用准确率、F1等明确指标评估，LLM应用的评估更加复杂：

评估类型 方法 优点 缺点
基准测试 MMLU, HumanEval等 标准化、可复现 不反映实际应用
自动指标 BLEU, ROUGE 快速、低成本 与人类判断相关性低
LLM-as-Judge GPT-4评分 可扩展、较准确 成本、偏差
人工评估 标注团队 最准确 慢、贵、不可扩展
用户反馈 点赞/踩 真实信号 稀疏、有偏差

4. LLMOps工具生态

4.1 开发框架

  • LangChain: 最流行的LLM应用开发框架
  • LlamaIndex: 专��于RAG的框架
  • Semantic Kernel: 微软的LLM编排框架
  • Haystack: 端到端NLP/LLM框架

4.2 评估工具

  • RAGAS: RAG系统评估
  • DeepEval: 通用LLM评估
  • Promptfoo: Prompt测试和评估
  • Trulens: 反馈驱动的评估

4.3 监控平台

  • Langfuse: 开源LLM可观测性
  • LangSmith: LangChain生态监控
  • Helicone: LLM API代理和监控
  • Phoenix: Arize出品的LLM可观测性

4.4 ��署工具

  • vLLM: 高性能LLM推理
  • TGI: Hugging Face推理服务
  • Ollama: 本地LLM运行
  • LiteLLM: 统一LLM API网关

5. 总结

LLMOps的核心理念：

  1. Prompt即代码: Prompt需要像代码一样管理
  2. 评估驱动: 建立持续评估机制
  3. 成本意识: 从第一天就追踪成本
  4. 安全优先: 在每个环节嵌入安全检查
  5. 快速迭代: 利用Prompt修改的低成本快速实验
graph TD
    subgraph LLMOps核心循环
        P[Prompt/RAG开发] --> E[评估]
        E --> D[部署]
        D --> M[监控]
        M --> O[优化]
        O --> P
    end

参考资料

评论 #