让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( modelgpt-4o, querycase.user_query, contextcase.context, outputagent_output, expectedcase.expected_keywords, ) overall statistics.mean(primary_scores.values()) human_needed False if overall case.min_score: # 低分触发仲裁验证 secondary_scores await self._call_judge( modelclaude-3-opus, querycase.user_query, contextcase.context, outputagent_output, expectedcase.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_idcase.case_id, actual_outputagent_output, dimension_scoresprimary_scores, overall_scoreround(overall, 3), judge_disagreementdisagreement, human_review_neededhuman_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_exceptionsTrue) 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至少由两人独立打分计算Cohens Kappa。当Kappa 0.6时需要统一评分标准后复评。用户反馈的样本偏差。主动反馈的用户往往是极端满意或极端不满的两端。沉默大多数约占70%的意见被忽略了。需要在产品中设计隐性信号采集——如任务完成率、回复后停留时长。成本问题。以每1000个Case计算自动化评测成本约$3按GPT-4o API价格人工评测成本约$120按每人每小时评20个计算。合理的策略是自动化跑全量人工只检低分和分歧Case。五、总结Agent评测体系的建设本质上是把灰度的质量感知变为白盒的量化度量。实施建议分三个里程碑。第一个里程碑建立50个核心评测Case和自动化评分脚本跑通从模型变更→自动评测→结果通知的闭环周期在一个迭代内。第二个里程碑引入人工评测抽样建立双盲打分机制。第三个里程碑接入用户反馈数据让真实用户需求驱动评测Case的持续丰富。记住一个核心原则自动化评测负责守住质量底线人工评测负责校准标准用户反馈负责发现质量上线。三者缺一不可。