11.4 评估监控与回归（Evaluation & Monitoring）

智能体系统的监控与回归测试是确保生产环境质量的关键机制。不同于传统软件会抛出明确错误，大语言模型智能体容易出现「静默退化」——输出看起来合理，实际质量已经下降。

11.4.1 自动化回归测试

回归测试的必要性

回归测试确保新版本不会破坏已有功能。LLM 系统的回归测试需要特别设计，因为 LLM 输出并非确定性的，难以用传统的字符串匹配验证。

测试流程

基线建立 用当前稳定版本运行全部测试用例，记录输出和指标
变更测试 每次修改提示词、模型或参数后重新运行
对比分析 将新结果与基线对比，识别退化
质量门禁 只有通过回归测试才允许部署

LLM-as-Judge 评估

LLM-as-Judge（大模型评判法）是用一个 LLM（通常是更强大的模型）来评判另一个 LLM 的输出质量。这类似让一位资深分析师审核初级分析师的报告。

它的优势在于：可扩展性（比人工评估快数百倍）、一致性（相同输入总是得到相同评分）、灵活性（可快速调整评估维度）。

LLM 评审的常见偏见

位置偏见：在多选项比较中倾向于选择特定位置的选项
冗长偏见：倾向于给更长的输出更高分数
自我偏好：评估自己生成的内容时倾向于给出更高分
形式偏见：倾向于给使用正式语言的输出更高分

缓解方法：随机打乱选项顺序、在评分标准中明确简洁性维度、使用不同模型作为评判者、采用盲测设计。

提示词版本控制与测试

提示词的微小改动可能导致输出巨变，必须严格控制。每个版本都应该：

记录修改原因和预期改进
在标准测试集上运行完整评估
与前一版本进行 A/B 对比
生产环境小流量灰度验证

序号	知识点	重要度
11.4.1	自动化回归测试	★★★

11.4.2 日志记录与趋势监控

多层次监控架构

现代 LLM 智能体监控系统采用四层架构，从数据输入到最终输出全程跟踪。

1. 数据流监控层

监控输入数据质量（用户查询的完整性、格式合规性）、Token 消耗追踪（每次请求的输入/输出 token 数量）、数据敏感性检测（自动识别可能包含 PII 的内容）。

2. 模型响应监控层

关键监控指标

响应质量评估（准确性、相关性、上下文一致性）
生成特征追踪（输出长度、结构化程度、语义连贯性）
异常模式识别（幻觉、拒绝回答、格式错误）

3. 系统性能监控层

监控延迟指标（首 token 时间、总响应时间）、资源利用（CPU、GPU、内存使用率）、吞吐量（每秒请求数、并发处理能力）。

4. 实时分析层

提供即时异常检测（响应时间激增、错误率突增）、趋势分析（性能退化趋势、成本增长轨迹）、自动预警（超过阈值自动触发告警）。

核心监控指标

指标类型	具体指标	说明
性能指标	延迟（Latency）	P50/P95/P99 响应时间
	吞吐量（Throughput）	每分钟处理请求数
	错误率（Error Rate）	失败请求占比
质量指标	准确性（Accuracy）	答案正确率
	一致性（Consistency）	相同输入的输出稳定性
	幻觉率（Hallucination Rate）	虚构内容比例
业务指标	用户满意度	点赞/点踩比率
	任务完成率	成功解决用户问题的比例
成本指标	Token 成本	API 调用费用
	缓存命中率	通过缓存节省的成本

结构化日志设计

日志需要记录完整的请求-响应信息，便于后续分析和问题排查。

字段说明：
- timestamp: 请求时间戳（UTC 格式）
- request_id: 唯一请求标识，用于链路追踪
- agent: 智能体类型
- model: 使用的模型
- input.query: 用户查询内容
- input.context_length: 上下文 token 数
- output.token_count: 输出 token 数
- output.finish_reason: 结束原因（stop=正常/length=截断/error=错误）
- metrics.latency_ms: 响应延迟（毫秒）
- metrics.cost_usd: 本次调用成本
- metrics.quality_score: 自动质量评分
- metadata.prompt_version: 当前提示词版本号

{
  "timestamp": "2026-01-18T14:35:22Z",
  "request_id": "req-abc123",
  "agent": "financial_qa",
  "model": "claude-3.5-sonnet",
  "input": {
    "query": "如何评估一家公司的估值？",
    "context_length": 1200
  },
  "output": {
    "response": "...",
    "token_count": 350,
    "finish_reason": "stop"
  },
  "metrics": {
    "latency_ms": 520,
    "cost_usd": 0.015,
    "quality_score": 8.5
  },
  "metadata": {
    "prompt_version": "v2.3",
    "retrieval_docs": 5,
    "cache_hit": false
  }
}

序号	知识点	重要度
11.4.2	日志记录与趋势监控	★★

11.4.3 基准线对比方法

建立性能基线

性能基线是评估改进效果的参照物。基线应包含多个维度：

生产基线配置

模型基线：
- 主模型：Claude 3.5 Sonnet
- 备用模型：GPT-4
- 切换条件：主模型延迟 > 3s 或错误率 > 5%

性能基线（过去30天 P95）：
- 端到端延迟：850ms
- 首 token 时间：180ms
- 吞吐量：120 req/min

质量基线（周平均）：
- 用户满意度：4.2/5.0
- 任务完成率：87%
- 幻觉检出率：3.1%

成本基线（每日）：
- API 调用费用：$145
- 平均单次成本：$0.012

A/B 测试框架

同时运行两个版本，科学对比效果。

ab_test_config = {
    # 实验标识：用于追踪和区分不同实验
    "experiment_id": "prompt-v2.4-test",

    # 流量分配：将用户随机分为两组
    "traffic_split": {
        "control": 0.5,    # 50% 用户使用 v2.3（对照组）
        "treatment": 0.5   # 50% 用户使用 v2.4（实验组）
    },

    # 实验时长：至少运行 7 天以覆盖周内/周末差异
    "duration_days": 7,

    # 主要指标：实验成功的核心判断依据
    "primary_metric": "task_completion_rate",

    # 次要指标：观察是否有意外副作用
    "secondary_metrics": ["latency_p95", "cost_per_request"],

    # 最小样本量：保证统计显著性
    "minimum_sample_size": 1000
}

使用统计显著性检验（如 t 检验）判断差异是否显著。只有 p 值 < 0.05 时，才能认为实验组与对照组存在显著差异。

模型漂移监测

模型性能会随时间退化，需要持续监测：

输入分布漂移：用户查询的主题分布是否改变？新出现的查询类型占比？
输出分布漂移：模型生成的答案长度是否异常？特定词汇的使用频率是否变化？
概念漂移：输入-输出关系是否改变？

监测方法包括 KS 检验检测分布差异、监测新类别占比、定期人工审核样本。

序号	知识点	重要度
11.4.3	基准线对比方法	★★

11.4.4 质量门禁设置

质量门禁的定义

质量门禁是一组标准，只有达到这些标准才能进入下一阶段（如从开发到生产）。

持续评估管道

将回归测试集成到 CI/CD 流程：

代码提交
    ↓
自动触发评估
    ↓
[阶段1] 快速冒烟测试（10个核心用例，2分钟）
    ↓ 通过
[阶段2] 完整回归测试（200+用例，15分钟）
    ↓ 通过
[阶段3] 性能基准测试（延迟、成本、吞吐量）
    ↓ 通过
质量门禁检查
    ↓ 达标
灰度发布（5%流量）
    ↓ 监控24小时
全量发布

质量门禁配置示例

quality_gates:
  regression_test:
    threshold: 0.95  # 至少95%的测试用例不能退化
    critical_tests_pass_rate: 1.0  # 核心用例必须100%通过

  performance:
    p95_latency_increase: 0.15  # P95延迟增长不超过15%
    cost_per_request_increase: 0.20  # 单次成本增长不超过20%

  quality:
    min_accuracy: 0.82  # 最低准确率
    max_hallucination_rate: 0.05  # 幻觉率上限5%

分层告警机制

不同严重程度触发不同响应：

Critical（P0） 系统不可用或核心功能失效，错误率 > 50%、延迟 > 10 秒。触发：立即通知值班工程师，自动启动应急预案
High（P1） 性能显著下降但系统仍可用，幻觉率 > 15%、成本激增 > 3 倍。触发：30 分钟内通知负责人，记录详细日志
Medium（P2） 轻微退化或趋势性问题，准确率下降 5-10%。触发：每日汇总邮件，纳入下次迭代优化
Low（P3） 信息性通知，新用例类型出现。触发：记录到日志，定期回顾

序号	知识点	重要度
11.4.4	质量门禁设置	★★

--- title: "11.4 评估监控与回归（Evaluation & Monitoring）" --- 智能体系统的监控与回归测试是确保生产环境质量的关键机制。不同于传统软件会抛出明确错误，大语言模型智能体容易出现「静默退化」——输出看起来合理，实际质量已经下降。 ### 11.4.1 自动化回归测试 **回归测试的必要性** 回归测试确保新版本不会破坏已有功能。LLM 系统的回归测试需要特别设计，因为 LLM 输出并非确定性的，难以用传统的字符串匹配验证。 **测试流程** 1. **基线建立** 用当前稳定版本运行全部测试用例，记录输出和指标 2. **变更测试** 每次修改提示词、模型或参数后重新运行 3. **对比分析** 将新结果与基线对比，识别退化 4. **质量门禁** 只有通过回归测试才允许部署 **LLM-as-Judge 评估** LLM-as-Judge（大模型评判法）是用一个 LLM（通常是更强大的模型）来评判另一个 LLM 的输出质量。这类似让一位资深分析师审核初级分析师的报告。它的优势在于：可扩展性（比人工评估快数百倍）、一致性（相同输入总是得到相同评分）、灵活性（可快速调整评估维度）。 ::: {.callout-warning} ## LLM 评审的常见偏见 - **位置偏见**：在多选项比较中倾向于选择特定位置的选项 - **冗长偏见**：倾向于给更长的输出更高分数 - **自我偏好**：评估自己生成的内容时倾向于给出更高分 - **形式偏见**：倾向于给使用正式语言的输出更高分 **缓解方法**：随机打乱选项顺序、在评分标准中明确简洁性维度、使用不同模型作为评判者、采用盲测设计。 ::: **提示词版本控制与测试** 提示词的微小改动可能导致输出巨变，必须严格控制。每个版本都应该： - 记录修改原因和预期改进 - 在标准测试集上运行完整评估 - 与前一版本进行 A/B 对比 - 生产环境小流量灰度验证 | 序号 | 知识点 | 重要度 | |:----:|--------|:------:| | 11.4.1 | 自动化回归测试 | ★★★ | ### 11.4.2 日志记录与趋势监控 **多层次监控架构** 现代 LLM 智能体监控系统采用四层架构，从数据输入到最终输出全程跟踪。 **1. 数据流监控层** 监控输入数据质量（用户查询的完整性、格式合规性）、Token 消耗追踪（每次请求的输入/输出 token 数量）、数据敏感性检测（自动识别可能包含 PII 的内容）。 **2. 模型响应监控层** ::: {.callout-note} ## 关键监控指标 - 响应质量评估（准确性、相关性、上下文一致性） - 生成特征追踪（输出长度、结构化程度、语义连贯性） - 异常模式识别（幻觉、拒绝回答、格式错误） ::: **3. 系统性能监控层** 监控延迟指标（首 token 时间、总响应时间）、资源利用（CPU、GPU、内存使用率）、吞吐量（每秒请求数、并发处理能力）。 **4. 实时分析层** 提供即时异常检测（响应时间激增、错误率突增）、趋势分析（性能退化趋势、成本增长轨迹）、自动预警（超过阈值自动触发告警）。 **核心监控指标** | 指标类型 | 具体指标 | 说明 | |---------|---------|------| | 性能指标 | 延迟（Latency） | P50/P95/P99 响应时间 | | | 吞吐量（Throughput） | 每分钟处理请求数 | | | 错误率（Error Rate） | 失败请求占比 | | 质量指标 | 准确性（Accuracy） | 答案正确率 | | | 一致性（Consistency） | 相同输入的输出稳定性 | | | 幻觉率（Hallucination Rate） | 虚构内容比例 | | 业务指标 | 用户满意度 | 点赞/点踩比率 | | | 任务完成率 | 成功解决用户问题的比例 | | 成本指标 | Token 成本 | API 调用费用 | | | 缓存命中率 | 通过缓存节省的成本 | **结构化日志设计** 日志需要记录完整的请求-响应信息，便于后续分析和问题排查。 ```txt 字段说明： - timestamp: 请求时间戳（UTC 格式） - request_id: 唯一请求标识，用于链路追踪 - agent: 智能体类型 - model: 使用的模型 - input.query: 用户查询内容 - input.context_length: 上下文 token 数 - output.token_count: 输出 token 数 - output.finish_reason: 结束原因（stop=正常/length=截断/error=错误） - metrics.latency_ms: 响应延迟（毫秒） - metrics.cost_usd: 本次调用成本 - metrics.quality_score: 自动质量评分 - metadata.prompt_version: 当前提示词版本号 ``` ```json { "timestamp": "2026-01-18T14:35:22Z", "request_id": "req-abc123", "agent": "financial_qa", "model": "claude-3.5-sonnet", "input": { "query": "如何评估一家公司的估值？", "context_length": 1200 }, "output": { "response": "...", "token_count": 350, "finish_reason": "stop" }, "metrics": { "latency_ms": 520, "cost_usd": 0.015, "quality_score": 8.5 }, "metadata": { "prompt_version": "v2.3", "retrieval_docs": 5, "cache_hit": false } } ``` | 序号 | 知识点 | 重要度 | |:----:|--------|:------:| | 11.4.2 | 日志记录与趋势监控 | ★★ | ![多层次监控架构](images/img_05_monitoring_architecture.png) ### 11.4.3 基准线对比方法 **建立性能基线** 性能基线是评估改进效果的参照物。基线应包含多个维度： ```txt 生产基线配置模型基线： - 主模型：Claude 3.5 Sonnet - 备用模型：GPT-4 - 切换条件：主模型延迟 > 3s 或错误率 > 5% 性能基线（过去30天 P95）： - 端到端延迟：850ms - 首 token 时间：180ms - 吞吐量：120 req/min 质量基线（周平均）： - 用户满意度：4.2/5.0 - 任务完成率：87% - 幻觉检出率：3.1% 成本基线（每日）： - API 调用费用：$145 - 平均单次成本：$0.012 ``` **A/B 测试框架** 同时运行两个版本，科学对比效果。 ```python ab_test_config = { # 实验标识：用于追踪和区分不同实验 "experiment_id": "prompt-v2.4-test", # 流量分配：将用户随机分为两组 "traffic_split": { "control": 0.5, # 50% 用户使用 v2.3（对照组） "treatment": 0.5 # 50% 用户使用 v2.4（实验组） }, # 实验时长：至少运行 7 天以覆盖周内/周末差异 "duration_days": 7, # 主要指标：实验成功的核心判断依据 "primary_metric": "task_completion_rate", # 次要指标：观察是否有意外副作用 "secondary_metrics": ["latency_p95", "cost_per_request"], # 最小样本量：保证统计显著性 "minimum_sample_size": 1000 } ``` 使用统计显著性检验（如 t 检验）判断差异是否显著。只有 p 值 < 0.05 时，才能认为实验组与对照组存在显著差异。 **模型漂移监测** 模型性能会随时间退化，需要持续监测： - **输入分布漂移**：用户查询的主题分布是否改变？新出现的查询类型占比？ - **输出分布漂移**：模型生成的答案长度是否异常？特定词汇的使用频率是否变化？ - **概念漂移**：输入-输出关系是否改变？监测方法包括 KS 检验检测分布差异、监测新类别占比、定期人工审核样本。 | 序号 | 知识点 | 重要度 | |:----:|--------|:------:| | 11.4.3 | 基准线对比方法 | ★★ | ### 11.4.4 质量门禁设置 **质量门禁的定义** 质量门禁是一组标准，只有达到这些标准才能进入下一阶段（如从开发到生产）。 **持续评估管道** 将回归测试集成到 CI/CD 流程： ```txt 代码提交 ↓ 自动触发评估 ↓ [阶段1] 快速冒烟测试（10个核心用例，2分钟） ↓ 通过 [阶段2] 完整回归测试（200+用例，15分钟） ↓ 通过 [阶段3] 性能基准测试（延迟、成本、吞吐量） ↓ 通过质量门禁检查 ↓ 达标灰度发布（5%流量） ↓ 监控24小时全量发布 ``` **质量门禁配置示例** ```yaml quality_gates: regression_test: threshold: 0.95 # 至少95%的测试用例不能退化 critical_tests_pass_rate: 1.0 # 核心用例必须100%通过 performance: p95_latency_increase: 0.15 # P95延迟增长不超过15% cost_per_request_increase: 0.20 # 单次成本增长不超过20% quality: min_accuracy: 0.82 # 最低准确率 max_hallucination_rate: 0.05 # 幻觉率上限5% ``` **分层告警机制** 不同严重程度触发不同响应： - **Critical（P0）** 系统不可用或核心功能失效，错误率 > 50%、延迟 > 10 秒。触发：立即通知值班工程师，自动启动应急预案 - **High（P1）** 性能显著下降但系统仍可用，幻觉率 > 15%、成本激增 > 3 倍。触发：30 分钟内通知负责人，记录详细日志 - **Medium（P2）** 轻微退化或趋势性问题，准确率下降 5-10%。触发：每日汇总邮件，纳入下次迭代优化 - **Low（P3）** 信息性通知，新用例类型出现。触发：记录到日志，定期回顾 | 序号 | 知识点 | 重要度 | |:----:|--------|:------:| | 11.4.4 | 质量门禁设置 | ★★ | ![评估工作流与质量门禁](images/img_06_quality_gate_flow.png)