Agent 评估工程化
Agent 评估工程化是系统性地衡量 Agent 质量的工程实践,包括 Eval Dataset、Golden Test、LLM-as-a-Judge、Human Feedback、回归评估和持续监控。
#type / concept
#status / evergreen
#tech / ai
#tech / architecture
[!info] related notes
- 所属 MOC: AI Agent Application MOC, Agent Evals MOC
- 相关概念: Observability Engineering MOC
- 实践: Agent 测试与评估, AI Eval Framework
Agent 评估工程化
一句话定义
Agent 评估工程化是系统性地衡量 Agent 质量的工程实践。它不是”跑几个例子看看效果”,而是建立可重复、可量化、可回归的评估体系,覆盖功能正确性、工具调用准确率、RAG 检索质量和用户满意度。
它解决什么问题
Agent 和传统软件不同,输出是非确定性的:
- 同一个问题问两次,可能得到不同回答
- 改了 Prompt 可能修好一个问题,引入另一个问题
- 换了模型版本,质量可能下降
- RAG 知识库更新后,检索结果可能变化
没有评估体系,你不知道 Agent 到底好不好、改了之后变好了还是变差了。
核心原理
评估维度
| 维度 | 衡量什么 | 方法 |
|---|---|---|
| 功能正确性 | 回答是否正确 | Golden Test、LLM-as-Judge |
| 工具调用准确率 | 是否选对了工具、参数是否正确 | 工具调用匹配 |
| RAG 检索质量 | 检索结果是否相关 | Recall@K、Precision@K |
| 回答忠实度 | 回答是否基于检索内容 | Faithfulness Check |
| 用户满意度 | 用户是否满意 | 人工评分、点赞/踩 |
| 安全性 | 是否拒绝不当请求 | Red Team 测试 |
| 延迟 | 响应是否够快 | P50/P95/P99 延迟 |
| 成本 | token 消耗是否合理 | 每次调用成本 |
评估体系分层
Level 1: 单元测试
- Prompt 模板测试
- 工具函数测试
- 输出解析测试
Level 2: 集成测试
- Golden Test(标准问答对)
- 工具调用链路测试
- RAG 检索质量测试
Level 3: 端到端评估
- Eval Dataset 批量评估
- LLM-as-a-Judge 自动评分
- Human Feedback 人工评分
Level 4: 生产监控
- 实时质量指标
- 回归检测
- 异常告警
Golden Test
Golden Test 是预先准备的标准问答对:
{
"test_id": "golden_001",
"query": "公司年假政策是什么?",
"expected_answer": "入职满一年享有 10 天年假...",
"expected_tools": ["search_knowledge_base"],
"expected_sources": ["员工手册 第3章"],
"tags": ["hr", "policy"]
}
每次 Prompt 或模型变更后,跑一遍 Golden Test,看通过率是否下降。
LLM-as-a-Judge
用一个更强的 LLM 来评估 Agent 的回答:
JUDGE_PROMPT = """
你是一个评估专家。请评估以下回答的质量。
用户问题: {query}
Agent 回答: {answer}
参考答案: {reference}
检索到的知识: {retrieved}
请从以下维度评分 (1-5):
1. 正确性: 回答是否事实正确
2. 完整性: 是否覆盖了问题的所有方面
3. 忠实度: 是否基于检索内容而非编造
4. 相关性: 回答是否与问题相关
输出 JSON: {"correctness": N, "completeness": N, "faithfulness": N, "relevance": N}
"""
典型工程实现
Eval Dataset 结构
@dataclass
class EvalCase:
id: str
query: str
expected_answer: str = ""
expected_tools: list[str] = field(default_factory=list)
expected_sources: list[str] = field(default_factory=list)
tags: list[str] = field(default_factory=list)
difficulty: str = "medium" # easy / medium / hard
class EvalDataset:
def __init__(self, cases: list[EvalCase]):
self.cases = cases
def filter(self, tag: str = None, difficulty: str = None) -> "EvalDataset":
"""按标签或难度筛选"""
...
def run(self, agent, judge) -> EvalReport:
"""批量运行评估"""
results = []
for case in self.cases:
answer = agent.run(case.query)
score = judge.evaluate(case, answer)
results.append(EvalResult(case=case, answer=answer, score=score))
return EvalReport(results)
评估 Pipeline
async def evaluate_agent(agent, eval_dataset):
results = []
for case in eval_dataset.cases:
# 1. 运行 Agent
response = await agent.run(case.query)
# 2. 自动评分
scores = await llm_judge.evaluate(
query=case.query,
answer=response.text,
reference=case.expected_answer,
)
# 3. 工具调用检查
tool_accuracy = check_tool_calls(
actual=response.tool_calls,
expected=case.expected_tools,
)
results.append({
"case_id": case.id,
"scores": scores,
"tool_accuracy": tool_accuracy,
"latency": response.latency,
"tokens": response.token_usage,
})
return EvalReport(results)
常见设计模式
1. 回归评估
每次代码/Prompt/模型变更后,自动跑 Eval Dataset,检测质量是否下降。
2. A/B 评估
同时运行两个版本的 Agent,比较质量差异。
3. Shadow 评估
生产流量复制到新版本 Agent,但不返回给用户,只记录评估结果。
4. 持续监控
生产环境中持续收集用户反馈(点赞/踩),作为评估信号。
常见坑
- 没有 Eval Dataset: 每次改完手动试几个例子就上线
- Eval Dataset 太小: 10 个例子无法覆盖边界情况
- 只看平均分: 平均分 4.5 可能掩盖了个别 1 分的严重问题
- 不做回归测试: 改了 Prompt A,Prompt B 的效果变差了
- LLM-as-Judge 不校准: Judge 模型本身可能有偏见
和其他概念的关系
- vs 可观测性: 可观测性看”发生了什么”,评估看”做得好不好”
- vs Trace: Trace 是评估的数据来源
- vs Faithfulness Check: Faithfulness 是评估的一个维度
- vs Agent Evals MOC: Evals MOC 是评估主题的知识地图
总结
Agent 评估工程化的核心是把”感觉还行”变成”数据说话”。没有评估体系的 Agent,改一次怕一次。