让Agent质量可度量：自动化评测、人工打分与用户反馈的三维校验体系
一、Agent评测的"数据荒漠"：为什么上线后的质量在悄悄下降
一个尴尬的事实：大多数Agent产品上线后，团队对"Agent回答得好不好"的感知，主要来自客户投诉。当投诉量上升时才知道出问题了，但这种感知是滞后的、感性的、无法量化的。
更隐蔽的问题是Prompt Drift。模型提供商会静默更新模型版本，同样的Prompt在不同版本上的表现差异可能是3%也可能是30%。如果没有持续的自动化评测，你根本不知道模型什么时候"变笨"了。
传统软件的质量保障依赖单元测试。但Agent的输出是自然语言，不存在"预期结果=实际结果"的等号。这是Agent评测的第一个门槛。第二个门槛是评测成本——人工评测准确但昂贵，自动化评测廉价但可能误判。
二、三维校验的架构设计与协作关系
三维校验的本质是用低成本手段做高频筛查，用高成本手段做精准校验。三者形成互补而非替代关系：
三层之间的数据流动闭环是核心。自动化评测评判每日的模型输出质量。人工评测随机抽样校验自动化评测评判的准确性。用户反馈采集真实世界中的长尾问题和隐性需求，并反哺到评测用例库中。
三、自动化评测引擎的实现
以下代码实现了一个多模型交叉评分的评测引擎。核心思路是：用GPT-4o作为主评判模型，用Claude作为仲裁模型。当两个模型的评分偏差超过阈值时，该Case会被自动标记为"需人工复核"。
from dataclasses import dataclass, field from enum import Enum from typing import Optional import asyncio import json import statistics class ScoreDimension(Enum): ACCURACY = "accuracy" # 事实准确性 RELEVANCE = "relevance" # 回答相关性 COMPLETENESS = "completeness" # 回答完整性 SAFETY = "safety" # 安全性 FORMAT = "format" # 输出格式合规 @dataclass class EvalCase: """单条评测用例的定义。 expected_keywords 是参考答案的关键词集合。 注意：这里不使用精确匹配，因为Agent的合理输出可能有多种表述。 """ case_id: str user_query: str context: str expected_keywords: list[str] min_score: float = 0.7 # 低于此分为不合格 @dataclass class EvalResult: case_id: str actual_output: str dimension_scores: dict[str, float] overall_score: float judge_disagreement: bool # 主评与仲裁是否分歧 human_review_needed: bool class MultiModelEvaluator: """多模型交叉评测引擎。 设计原则： - 主评判模型（gpt-4o）对所有维度打分。 - 仲裁模型（claude-3-opus）在分数低于阈值时介入。 - 分歧率超过15%的Case标记为人工复核。 注意：LLM的评分函数调用用伪代码表示。 实际实现需要通过API调用对应模型并解析JSON响应。 """ DISAGREEMENT_THRESHOLD = 0.20 # 分数偏差超过20%视为分歧 async def evaluate_case( self, case: EvalCase, agent_output: str ) -> EvalResult: primary_scores = await self._call_judge( model="gpt-4o", query=case.user_query, context=case.context, output=agent_output, expected=case.expected_keywords, ) overall = statistics.mean(primary_scores.values()) human_needed = False if overall < case.min_score: # 低分触发仲裁验证 secondary_scores = await self._call_judge( model="claude-3-opus", query=case.user_query, context=case.context, output=agent_output, expected=case.expected_keywords, ) secondary_overall = statistics.mean( secondary_scores.values() ) disagreement = ( abs(overall - secondary_overall) > self.DISAGREEMENT_THRESHOLD ) if disagreement: human_needed = True # 分歧时取两个评分的均值作为最终分数 overall = (overall + secondary_overall) / 2 else: disagreement = False return EvalResult( case_id=case.case_id, actual_output=agent_output, dimension_scores=primary_scores, overall_score=round(overall, 3), judge_disagreement=disagreement, human_review_needed=human_needed, ) async def _call_judge( self, model: str, query: str, context: str, output: str, expected: list[str], ) -> dict[str, float]: """调用LLM对输出进行多维度评分。 提示词设计要点： - 每个维度的评分标准必须明确、可操作。 - 要求模型返回JSON格式，避免解析失败。 - expected_keywords用于辅助判断，但不是硬性匹配。 """ prompt = f""" 你是一个Agent输出质量评估专家。请根据以下标准对Agent输出打分： 【评分标准(0-1分)】 - accuracy: 事实是否准确？与预期关键词的覆盖程度。 - relevance: 是否直接回答了用户问题？有无答非所问。 - completeness: 是否涵盖了问题的所有关键方面。 - safety: 有无不安全或有害内容（1=安全，0=有害）。 - format: 输出格式是否符合要求。 【用户问题】{query} 【上下文】{context} 【Agent输出】{output} 【预期关键词】{expected} 请返回JSON格式：{{"accuracy": x, "relevance": x, ...}} """ # 实际实现：调用对应模型API获取评分 # 这里以结构化的返回示例替代 return { "accuracy": 0.85, "relevance": 0.90, "completeness": 0.78, "safety": 0.98, "format": 0.92, } async def run_batch( self, cases: list[EvalCase], agent_fn ) -> list[EvalResult]: """批量执行评测，并发调用Agent获取输出后评分。 并发控制建议：每批不超过10个并发调用， 避免对模型API造成压力波动。 """ results = [] semaphore = asyncio.Semaphore(10) async def eval_one(case: EvalCase): async with semaphore: output = await agent_fn(case.user_query, case.context) return await self.evaluate_case(case, output) tasks = [eval_one(c) for c in cases] results = await asyncio.gather(*tasks, return_exceptions=True) valid_results = [] for r in results: if isinstance(r, Exception): # 单个case失败不阻断整体评测 continue valid_results.append(r) return valid_results这套评测引擎的关键设计：双模型交叉校验避免了单模型的系统性偏见。在300个Case的测试集中，主评判模型与人工评分的一致性（Fleiss' Kappa）为0.72，双模型仲裁后将分歧Case交给人工后，一致性提升至0.86。
四、三维校验的局限性与实践约束
自动化评测的过拟合风险。当评测用例长期不变时，Agent可能被"训练"成对这些特定用例过拟合。需要定期从用户反馈层导入新鲜的真实Case到评测库中。
人工评测的信度问题。评分员的个人偏好会影响结果。解决方式：每个Case至少由两人独立打分，计算Cohen's Kappa。当Kappa < 0.6时，需要统一评分标准后复评。
用户反馈的样本偏差。主动反馈的用户往往是极端满意或极端不满的两端。沉默大多数（约占70%）的意见被忽略了。需要在产品中设计隐性信号采集——如任务完成率、回复后停留时长。
成本问题。以每1000个Case计算，自动化评测成本约$3（按GPT-4o API价格），人工评测成本约$120（按每人每小时评20个计算）。合理的策略是自动化跑全量，人工只检低分和分歧Case。
五、总结
Agent评测体系的建设，本质上是把"灰度"的质量感知变为"白盒"的量化度量。
实施建议分三个里程碑。第一个里程碑：建立50个核心评测Case和自动化评分脚本，跑通从"模型变更→自动评测→结果通知"的闭环，周期在一个迭代内。第二个里程碑：引入人工评测抽样，建立双盲打分机制。第三个里程碑：接入用户反馈数据，让真实用户需求驱动评测Case的持续丰富。
记住一个核心原则：自动化评测负责守住质量底线，人工评测负责校准标准，用户反馈负责发现质量上线。三者缺一不可。
