LLMOps 模型评估与观测

LLM 应用上线后，最大的挑战是"怎么知道它答得好不好"。传统软件可以通过单元测试、集成测试验证正确性，但 LLM 的输出是概率性的，同样的输入可能产生不同的输出，需要专门的评估和观测体系。LLMOps 应运而生，借鉴 MLOps 的思路，针对 LLM 的特点提供评估、监控、调优工具。

评估框架

LLM 评估的核心难题是缺乏客观标准。对于翻译任务，可以用 BLEU、ROUGE 等指标计算与参考答案的重叠度；对于问答任务，可以用精确匹配、F1 score 评估事实准确性；但对于开放式生成（创意写作、代码建议、对话），没有标准答案，只能用近似方法。

基于规则的评估适合有明确预期的场景。比如"输出必须是 JSON 格式"可以解析验证，"代码必须能运行"可以执行测试，"敏感信息必须脱敏"可以用正则匹配。这些规则简单直接，但覆盖范围有限，无法评估语义质量。

基于 LLM 的评估（LLM-as-a-Judge）是新兴方向。用另一个 LLM（通常是更强的模型如 GPT-4）给待评估模型的输出打分。提示词给出评分标准和示例，让评估 LLM 分析回答的相关性、准确性、完整性。Ragas、TruLens、DeepEval 等框架封装了这个流程，支持 RAG、摘要、问答等任务的自动化评估。

Ragas 专注于 RAG 系统评估，从检索质量和生成质量两个维度打分。检索质量用 context_relevance（检索到的文档与问题的相关性）和 context_recall（标准答案是否能在检索文档中找到）衡量。生成质量用 faithfulness（回答是否忠实于检索文档，无幻觉）和 answer_relevance（回答与问题的相关性）衡量。这些指标的计算依赖 LLM 判断，需要设计细致的评分提示词。

TruLens 提供了更灵活的评估框架，支持自定义评估器和反馈函数。它的特色是可视化的评估结果，展示每轮对话的得分、问题分布、改进方向。TruLens 还支持成分分析（App），理解模型决策过程中哪些组件（Prompt、Embedding、检索）对最终结果影响最大。

评估数据集

高质量的评估数据集是可靠评估的前提。数据集应该覆盖典型场景和边界情况，数量在几十到几百条之间。太少无法全面评估，太多评估成本过高。数据来源包括真实用户对话（需要脱敏）、人工构造的测试用例、公开的基准数据集（如 MS MARCO 问答、CNN/DailyMail 摘要）。

构造数据集需要考虑多样性。简单问题（事实查询）、复杂问题（多跳推理）、模糊问题（歧义消解）、错误问题（无答案）都应该包含。对于 RAG 系统，还需要准备不同类型的文档：结构化（API 文档）、非结构化（新闻文章）、混合型（既有表格又有文本）。

标注成本是评估的瓶颈。人工标注准确但昂贵，需要领域专家参与。自动标注高效但可能引入噪声，需要采样人工校验。半自动标注是个折中，先用弱标注（规则或小模型）生成候选答案，再由人工审核修正。

评估指标

相关性评估回答是否针对问题。对于事实性问题，相关性意味着包含正确答案；对于开放性问题，相关性意味着逻辑连贯、切题。计算方式可以用余弦相似度（问题和回答的向量）、或者 LLM 打分。

准确性评估回答的事实正确性。幻觉是 LLM 的典型问题，评估时需要检查引用是否真实、数字是否正确、逻辑是否自洽。FactScore 是一个自动评估方法，将答案分解原子事实，每条事实用知识库验证，计算准确率。缺点是需要领域知识库，通用场景难以应用。

完整性评估回答是否充分回应问题。用户问"如何部署服务"，回答只说"用 Docker"就不完整，应该包含镜像构建、容器运行、端口映射等步骤。完整性可以用 LLM 评估，或者对比标准答案的信息点覆盖度。

流畅性评估回答的可读性。语法正确、用词恰当、逻辑通顺、格式规范（Markdown、代码块）。可以用语言模型计算困惑度（Perplexity），越低越流畅；或者用语法检查工具（LanguageTool）统计错误数。

安全性评估回答是否包含有害内容。仇恨言论、暴力煽动、色情内容、隐私泄露都需要检测。安全评估可以用分类模型（Llama Guard、Azure Content Safety），或者关键词匹配。对于企业应用，还需要评估是否泄露商业敏感信息。

可观测性工具

LangSmith 是 LangChain 官方的调试平台，提供全链路追踪能力。每次 LLM 调用、工具调用、Prompt 变更都被记录，可以查看每一步的输入输出、执行时间、Token 消耗。LangSmith 的优势是可视化强，能够快速定位"哪个环节出错"、"哪个 Prompt 版本效果更好"。它还支持标注和评估，人工给回答打分，积累评估数据集。

LangFuse 是开源的可观测性方案，支持 LangChain、LlamaIndex、直接 API 调用等多种集成方式。它的特色是成本追踪，详细记录每次调用的 Token 消耗和费用，帮助优化成本控制策略。LangFuse 还支持用户反馈采集，在应用中嵌入点赞/点踩按钮，将用户满意度与系统指标关联分析。

Arize Phoenix 专注于 LLM 应用的性能监控和故障排查。它自动构建调用链的依赖图，可视化展示请求从入口到 LLM、到向量数据库、到外部 API 的完整路径。当延迟升高或错误率上升时，Phoenix 能快速定位瓶颈节点（是 Embedding 慢还是 LLM 慢）。

Weights & Biases (W&B) 的 Weave 模块提供实验跟踪和模型对比。开发阶段可以记录不同 Prompt、不同参数的实验结果，对比评估指标。生产阶段可以监控模型漂移（数据分布变化）、性能退化。W&B 还支持超参数调优，自动搜索最优配置。

实验管理

A/B 测试是验证改进效果的黄金标准。同时部署两个版本，分别处理 50% 流量，收集评估指标（延迟、成本、用户满意度），判断新版本是否显著优于旧版本。关键是要做好流量隔离和随机分流，确保两个版本面对相似的数据分布。对于 LLM 应用，还需要考虑版本切换的连贯性，用户在对话中突然切换模型可能导致体验断裂。

渐进式发布降低风险。先给 5% 流量用新版本，观察一周无问题后扩大到 20%，再逐步到 100%。每个阶段都设置回滚阈值（错误率超过 5% 立即回滚），确保问题能快速恢复。渐进式发布需要配置管理系统支持，如 FlagSmith、LaunchDarkly。

提示词版本管理是不可忽视的实践。Prompt 是 LLM 应用的"代码"，需要像代码一样版本控制。每次修改都应该记录变更原因、效果对比、回滚方案。LangSmith、PromptLayer 提供了专门的 Prompt 管理 UI，可视化对比不同版本，一键切换。对于团队协作，还需要审批流程，防止未经测试的 Prompt 上线。

成本优化

Token 消耗直接影响运营成本。评估指标中应该包含每次请求的平均 Token 数、每美元能处理的请求数。优化方向包括：使用更小的模型（简单任务用 7B 而非 70B）、优化 Prompt 长度（去除冗余指令）、压缩上下文（用摘要替代原始历史）、缓存重复请求（相同输入直接返回结果）。

模型选择需要权衡成本和质量。不是所有任务都需要最强的模型，分类、摘要、改写等任务可以用小模型完成，只有复杂推理、创意生成才需要大模型。可以设计级联策略，先用小模型尝试，置信度低时再调用大模型。这种方式在保证质量的前提下能降低 50%-70% 的成本。

批量处理提升吞吐量。对于离线任务（文档摘要、批量翻译），可以批量处理多个请求，共享固定成本（模型加载、系统开销）。vLLM、TGI 等推理引擎支持连续批处理，动态组合不同长度的请求，提升 GPU 利用率。实时任务也可以考虑请求合并，多个用户的相似查询合并处理，结果复用。

故障排查

LLM 应用的故障排查比传统应用更困难。输出质量差可能来自多个环节：Prompt 设计不当、Embedding 模型选择错误、检索结果不相关、模型能力不足。可观测性工具的作用就是缩小问题范围，逐一排查。

常见的故障模式包括：幻觉率上升（检索质量下降或 Prompt 约束不足）、延迟升高（模型切换或网络问题）、格式错误（Prompt 指令不清晰）、拒绝回答（安全策略过于敏感）。排查时应该先确认问题范围（所有用户还是特定用户、所有问题还是特定类型），然后复现问题，再针对性修改。

监控告警是主动发现问题的关键。需要设置的告警包括：错误率超过阈值（可能是模型崩溃）、延迟超过 P95（性能退化）、成本突增（可能的滥用或配置错误）、负面反馈增加（质量问题）。告警应该分级别，紧急问题（服务不可用）需要立即响应，性能下降可以次日分析。

LLMOps 是 LLM 应用落地的保障，它让不可概率的模型输出变得可观测、可评估、可优化。随着技术成熟，LLMOps 工具会越来越自动化，从被动监控到主动优化，让 AI 应用的运维成本持续降低。