构建持续评估流程
将 LLM-as-judge 评估集成到您的 CI/CD 流程中,使每次提示或模型变更都能在部署前,针对回归测试套件自动完成评估。
构建持续评估流程 是 CoddyKit 上的免费 AI Engineering Academy 课时。 这是第 4 节课,共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 AI Engineering Academy 学习路径的一部分,你的进度在网页和 CoddyKit 应用中同步。 AI Engineering Academy 课程共包含 4 节课。
为什么评估必须持续进行
仅在部署时进行一次评估是不够的。LLM 的质量可能在不易察觉的情况下下降:模型提供商会更新模型,系统提示可能被悄悄修改,随着文档语料库增长,检索质量会发生变化,用户问题的分布也会随时间改变。持续评估流程会在每次变更时以及按计划运行同一套评估,从而在几小时内而不是几周后发现质量回归。
流程的核心组成部分
持续评估流水线包含五个组件:测试数据集(经过整理且带有预期输出的问题)、系统运行器(针对每个测试问题调用您的 LLM 流水线)、评判器(为每个响应评分)、结果存储(用于保存历史指标的数据库或时序存储),以及报告层(仪表板和警报)。每个组件都可以独立升级。
# Pipeline architecture:
#
# test_dataset.json
# |
# v
# system_runner.py --> calls your LLM pipeline
# |
# v
# judge.py --> scores each (question, answer) pair
# |
# v
# results_db --> stores timestamped metric history
# |
# v
# dashboard + alert --> Grafana / Slack notification组织测试数据集
将评估测试集作为带版本管理的 JSON 或 YAML 文件存储在您的代码仓库中。每个条目包含一个问题、类别(事实性、程序性、超出范围),以及可选的参考答案。测试集应与代码分开进行版本管理——新增测试用例属于向后兼容的变更,而删除用例可能会掩盖回归问题。目标是覆盖所有相关类别,共准备 200–500 个用例。
# eval/test_set_v3.json
# {
# 'version': '3.0',
# 'created': '2026-06-01',
# 'cases': [
# {
# 'id': 'faq_001',
# 'category': 'factual',
# 'question': 'What is the cancellation policy?',
# 'reference': 'Cancellations must be made 24 hours in advance.',
# 'min_correctness': 4
# },
# ...
# ]
# }运行评估套件
评估运行器会针对每个测试用例调用您的生产系统(或预发布版本),并记录响应和元数据。为每次评估运行标记唯一的运行 ID、触发运行的提交 SHA、时间戳以及测试集版本。这样便可以准确比较不同运行,并诊断是哪次代码变更导致了回归。
import asyncio
import uuid
from datetime import datetime
async def run_eval_suite(system, test_set: list, commit_sha: str) -> dict:
run_id = str(uuid.uuid4())
results = []
for case in test_set:
response = await system.answer(case['question'])
score = await judge(case['question'], response, case.get('reference'))
results.append({
'run_id': run_id,
'commit_sha': commit_sha,
'case_id': case['id'],
'category': case['category'],
'response': response,
'score': score.model_dump(),
'evaluated_at': datetime.utcnow().isoformat()
})
return {'run_id': run_id, 'results': results}存储和查询历史指标
将每次评估运行的结果持久化到数据库中。一个包含 run_id、commit_sha、case_id 和 score 字段的简单 eval_results 表就足够了。按 run_id 查询聚合分数,以计算每次运行的指标。将当前运行与主分支上最近一次成功运行进行比较,以检测回归。InfluxDB 之类的时序数据库非常适合持续监控。
-- PostgreSQL schema
CREATE TABLE eval_runs (
run_id UUID PRIMARY KEY,
commit_sha TEXT NOT NULL,
test_set_version TEXT NOT NULL,
triggered_by TEXT, -- 'ci', 'scheduled', 'manual'
started_at TIMESTAMPTZ DEFAULT NOW()
);
CREATE TABLE eval_results (
id SERIAL PRIMARY KEY,
run_id UUID REFERENCES eval_runs(run_id),
case_id TEXT NOT NULL,
category TEXT,
correctness INT,
overall INT,
response TEXT
);
CREATE INDEX idx_run_id ON eval_results(run_id);自动检测回归
每次评估运行后,将聚合分数与基线(主分支上最近一次经过人工批准的运行)进行比较。回归的定义是:任一分数维度比基线下降超过 5%,或任一类别的平均分低于硬性最低值。出现回归时应阻止部署并向团队发出警报。改进则可以自动批准。
def detect_regression(current: dict, baseline: dict, threshold_pct: float = 5.0) -> dict:
regressions = []
for metric in ['correctness', 'helpfulness', 'clarity']:
delta_pct = (current[metric] - baseline[metric]) / baseline[metric] * 100
if delta_pct < -threshold_pct:
regressions.append({
'metric': metric,
'baseline': baseline[metric],
'current': current[metric],
'delta_pct': round(delta_pct, 1)
})
return {'has_regression': len(regressions) > 0, 'regressions': regressions}集成持续集成与持续交付
将评估套件添加为持续集成步骤,使其在每个拉取请求上运行。持续集成流水线会调用您的预发布系统、运行评判器、存储结果并检查回归。如果检测到回归,持续集成步骤将失败并阻止合并 PR。将其作为 GitHub 或 GitLab 中的必需状态检查,这样任何人都无法绕过它。对于 PR 检查,可使用 50–100 个用例的子集,将评估运行时间控制在 10 分钟以内。
# .github/workflows/eval.yml
# name: LLM Quality Evaluation
# on: [pull_request]
# jobs:
# eval:
# runs-on: ubuntu-latest
# steps:
# - uses: actions/checkout@v4
# - name: Run eval suite
# run: python eval/run_suite.py --commit $GITHUB_SHA --mode pr
# env:
# OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
# - name: Check for regressions
# run: python eval/check_regression.py --run-id $EVAL_RUN_ID计划执行完整评估运行
除了 PR 检查之外,还应每天针对生产系统运行完整评估套件(全部 300 多个用例)。这可以发现任何单次变更都不会直接引入的渐进式质量漂移——例如,随着添加更多文档,向量数据库的召回率逐渐下降,或者 LLM 提供商在未通知您的情况下更新了模型。每天执行完整运行,可以生成质量时间序列,使趋势清晰可见。
# Separate eval modes:
EVAL_CONFIGS = {
'pr_check': {
'test_cases': 'eval/test_set_core_100.json',
'target': 'staging',
'max_runtime_min': 8
},
'nightly': {
'test_cases': 'eval/test_set_full_350.json',
'target': 'production',
'max_runtime_min': 30
},
'weekly_deep': {
'test_cases': 'eval/test_set_full_350.json',
'target': 'production',
'include_pairwise': True,
'max_runtime_min': 90
}
}针对质量下降发出警报
当指标趋势越过警告阈值和严重阈值时配置警报。过去 7 天的平均正确率下降 3% 时触发警告。单次运行下降 10% 时立即触发警报。将警告发送到团队 Slack 频道,将严重警报发送到 PagerDuty。每条警报消息都应包含回归分析、评估仪表板链接,以及近期变更对应的 git blame 信息。
import httpx
def send_regression_alert(regression_report: dict, webhook_url: str):
regressions = regression_report['regressions']
blocks = [{
'type': 'section',
'text': {'type': 'mrkdwn', 'text': '*LLM Quality Regression Detected*'}
}]
for r in regressions:
blocks.append({
'type': 'section',
'text': {'type': 'mrkdwn',
'text': f'*{r["metric"]}*: {r["baseline"]} -> {r["current"]} ({r["delta_pct"]}%)'}
})
httpx.post(webhook_url, json={'blocks': blocks})管理测试集扩展
根据真实生产故障持续扩展测试集。当用户报告错误响应时,将该问题(必要时进行匿名化)及经过人工核验的预期答案添加到测试集中。这样可以确保评估套件反映真实的用户需求,而不是假设性用例。将测试集视为持续演进的文档,每季度进行审查并删除过时用例。
def add_to_test_set(question: str, reference_answer: str, category: str,
source: str, test_set_path: str):
import json, uuid
with open(test_set_path, 'r') as f:
test_set = json.load(f)
test_set['cases'].append({
'id': f'user_report_{uuid.uuid4().hex[:8]}',
'category': category,
'question': question,
'reference': reference_answer,
'source': source, # 'user_report', 'regression', 'manual'
'added': '2026-06-21'
})
with open(test_set_path, 'w') as f:
json.dump(test_set, f, indent=2)可视化随时间变化的质量趋势
构建一个简单的质量仪表板,绘制关键指标随时间的变化:平均正确率、缓存命中率、p95 延迟以及每次查询的成本。使用每周移动平均值,平滑小样本量带来的噪声。趋势图可以立即显示质量漂移——六周内逐渐下降 3% 的情况在单次运行报告中难以发现,但在时序图上却十分明显。Grafana,甚至简单的 Python matplotlib 脚本,都很适合完成这项工作。
import matplotlib.pyplot as plt
import pandas as pd
def plot_quality_trend(eval_history: list):
df = pd.DataFrame(eval_history)
df['date'] = pd.to_datetime(df['evaluated_at'])
df = df.sort_values('date')
# 7-day rolling average
df['score_ma7'] = df['mean_correctness'].rolling(window=7).mean()
plt.figure(figsize=(12, 4))
plt.plot(df['date'], df['mean_correctness'], alpha=0.3, label='Daily')
plt.plot(df['date'], df['score_ma7'], label='7-day avg', linewidth=2)
plt.axhline(y=4.0, color='r', linestyle='--', label='Min threshold')
plt.legend()
plt.title('LLM Answer Quality Over Time')
plt.savefig('quality_trend.png')快速检查
测试您对 LLM 应用持续评估流水线的理解。
课程回顾
本课中您学习了:持续评估流水线会在每个 PR 上以及每天按计划运行自动质量检查,以便及早发现回归;回归检测会将当前分数与基线进行比较,并在质量下降时阻止部署;而根据真实故障扩展测试集可以让评估套件始终立足于实际用户需求。接下来,我们将对智能体故障模式进行分类,并设计恢复策略。
用 AI 导师学习 Python — 免费
在浏览器中编写并运行真实代码,获得全天候 AI 导师的即时帮助,并在网页或应用中继续学习。
- 课程
- 30
- 课程
- 120
常见问题解答
「构建持续评估流程」课时是免费的吗?
是的 — 「构建持续评估流程」的完整文本可在网页上免费阅读。要进行交互式练习(内置代码编辑器和全天候 AI 导师)并解锁 AI Engineering Academy 课程的其余内容,请升级到 CoddyKit PRO。 AI Engineering Academy 课程共包含 4 节课。
「构建持续评估流程」这节课中我会学到什么?
将 LLM-as-judge 评估集成到您的 CI/CD 流程中,使每次提示或模型变更都能在部署前,针对回归测试套件自动完成评估。 你通过在浏览器中直接运行的动手代码来练习 AI Engineering Academy,全天候 AI 导师会在你学习这节课的过程中回答你的问题。
学习 AI Engineering Academy 需要有经验吗?
无需任何先前经验。CoddyKit 上的 AI Engineering Academy 课程适合初学者到高级学习者,你可以从这里开始或从头开始,按照自己的节奏学习。 这是第 4 节课,共 4 节。
「构建持续评估流程」课时需要多长时间?
大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动,所以你能稳步进步,并在网页和应用中从离开的地方继续。
我能在这节 AI Engineering Academy 课中编写并运行代码吗?
能。每节 AI Engineering Academy 课都包含内置代码编辑器,你可以在浏览器中直接编写并运行真实代码,并获得即时 AI 反馈 — 无需本地设置。
此课程中的所有课时
- LLM 作为评判者模式
- 逐项评估与成对评估
- 根据人工评估校准评判模型
- 构建持续评估流程