LLM评估三把手术刀：字符串比对、准则评估与轨迹分析

1. 这不是“打分”而是给AI输出做一次外科手术式诊断你有没有遇到过这样的场景模型明明生成了看似通顺、语法正确、甚至带点文采的回答但业务方一眼就指出——“这根本没答到点子上”或者测试时BLEU值高达0.82上线后客服机器人却反复把“退换货流程”解释成“会员积分兑换规则”又或者一个精心设计的AI Agent在多步推理中前两步逻辑严密第三步突然跳转到完全无关的结论而自动评估脚本只报了个模糊的“相似度0.65”却说不清问题出在哪一层。这些不是模型能力不足的模糊抱怨而是评估体系失焦的真实代价。String Comparison、Criteria-based Evaluation、Trajectory Analysis——这三个词不是学术论文里的装饰性术语它们是我在过去三年里亲手拆解过27个生产级LLM应用、复现过41种评估方案后沉淀下来的三把手术刀一把切开表层文本的“形似”假象一把校准业务意图的“神似”标尺一把追踪决策路径的“动态心电图”。它们分别对应着“它写了什么”“它该写什么”“它怎么写出这个结果”的三层追问。这篇文章不讲抽象理论不堆砌公式只讲我在金融风控问答、医疗问诊摘要、电商智能导购三个真实产线项目中如何用这三套方法组合拳把“模型输出质量”从主观感受变成可定位、可归因、可优化的工程指标。无论你是刚跑通第一个LangChain Chain的新手还是正在为Agent稳定性焦头烂额的架构师只要你需要向产品、法务或客户解释“为什么这个回答不能上线”这篇就是为你写的实操手册。2. 为什么必须放弃“单一打分”三类评估的本质差异与协同逻辑2.1 String Comparison最朴素也最容易误判的“第一眼判断”String Comparison字符串比对是所有评估的起点也是陷阱最多的一环。它的核心逻辑极其简单把模型输出Output和参考答案Reference当作两个纯文本字符串计算它们在字符、词元或语义层面的相似程度。常见的实现包括Exact MatchEM逐字完全一致常用于填空、选择题等封闭式任务。比如参考答案是“2023年Q4”模型输出“2023年第四季度”即判为失败。我经手的第一个信贷审批问答项目就栽在这里——业务规则明确要求日期格式必须为“YYYY年QX”而模型习惯性输出“YYYY年第X季度”EM得分为0但实际信息无损。我们后来强制加了预处理标准化步骤统一转为“YYYY年QX”格式再比对EM从32%跃升至89%但人工抽检发现仍有11%的“高分错误”模型把“逾期天数≤30天”错写成“逾期天数30天”EM仍为1因参考答案恰好也是“≤”但法律效力已截然不同。Token-level Metrics如BLEU、ROUGE基于n-gram重叠率。BLEU在机器翻译时代被奉为圭臬但在开放域生成中暴露出致命缺陷。在医疗问诊摘要项目中参考答案是“患者主诉右下腹持续性钝痛3天伴低热”模型输出“患者3天来右下腹有持续性钝痛体温略高”。ROUGE-L得分0.78表面不错但临床审核发现漏掉了关键鉴别诊断线索“低热”——这个词在参考答案中仅出现1次在模型输出中被弱化为“体温略高”而ROUGE-L对这种语义降级毫无感知。更讽刺的是当我们将参考答案替换成更口语化的版本“肚子右下方疼了三天有点发烧”ROUGE-L反而降到0.65仿佛模型“变差了”实则它只是更贴近真实医患对话风格。Embedding-based Similarity如BERTScore、Sentence-BERT用预训练模型将文本映射到向量空间计算余弦相似度。这确实是进步但它把“相似”默认等同于“正确”。在电商导购Agent项目中用户问“适合送爸爸的500元以内礼物”参考答案是“飞利浦电动剃须刀S5000”模型输出“松下ES-LV9Q电动剃须刀”。BERTScore高达0.92二者都是高端剃须刀但松下型号实际售价699元严重违反预算约束。评估系统给了高分而业务侧直接否决——因为“相似”不等于“合规”。提示String Comparison的本质是测量“表征距离”而非“语义正确性”或“任务完成度”。它像一把卡尺只能量长度无法判断这把尺子本身是否刻度准确。永远不要让String Comparison成为最终验收标准它只能是初筛过滤器。2.2 Criteria-based Evaluation把业务规则翻译成可执行的“判决书”当String Comparison失效时Criteria-based Evaluation基于准则的评估就成为不可替代的裁判。它的核心是脱离具体文本形式聚焦任务目标本身将人类专家的判断逻辑拆解为一组原子化、可验证、可编程的检查项Criteria。这不是主观打分而是构建一套领域专属的“法律条文”。以金融风控问答为例我们定义了5条硬性准则每条0/1二值判定事实准确性所有提及的监管条款如《个人金融信息保护法》第23条、利率数值、时效要求必须与最新权威来源完全一致风险提示完整性若涉及贷款产品必须包含“年化利率”“违约金比例”“提前还款限制”三项要素禁止性表述不得出现“保证通过”“100%获批”“零风险”等绝对化承诺用语责任边界清晰需明确区分“银行职责”如放款审核与“客户义务”如提供真实材料格式规范性关键数字必须使用阿拉伯数字法律条款引用需带全称及条款号。这套准则的诞生过程本身就是一场跨职能拉锯战。法务坚持第3条必须存在因为监管处罚案例中73%源于绝对化用语风控要求第1条必须可溯源我们最终对接了央行法规数据库API每次评估时自动抓取最新条款文本进行比对而客服团队推动增加了第4条因为他们发现大量客诉源于权责描述模糊。Criteria不是凭空设计的它是业务痛点、合规红线、用户体验三者碰撞出的结晶。实施时我们用LLM-as-a-Judge大模型作为裁判来执行这些准则给定模型输出和准则描述让另一个更强的模型如GPT-4-turbo判断每条是否满足并输出理由。例如对“保证通过”检测裁判模型会返回“检测到‘100%包过’触发准则3判定为不满足理由该表述构成绝对化承诺违反《广告法》第24条”。这比人工抽检效率提升20倍且100%覆盖。注意Criteria必须可证伪。像“回答是否专业”“语气是否友好”这类模糊表述必须拆解为“是否使用行业术语如LTV、PD”“是否包含至少1个主动态动词如‘请提供’‘建议您’”等可观测行为。否则它就退化成了主观打分。2.3 Trajectory Analysis给AI Agent装上“行车记录仪”当评估对象从单轮LLM输出升级为多步AI Agent时String Comparison和Criteria Evaluation都面临维度坍塌。一个Agent的完整轨迹Trajectory包含用户原始Query → 思维链Chain-of-Thought推理步骤 → 工具调用记录API请求/响应→ 中间状态变量 → 最终Answer。Trajectory Analysis的核心思想是错误往往藏在路径中而非终点。就像汽车事故鉴定不能只看最终碰撞位置更要分析ABS是否介入、转向角度是否异常、油门开度变化曲线。在电商智能导购Agent中我们曾遇到一个经典故障用户问“iPhone 15 Pro Max 256G在京东和拼多多的价格对比”Agent最终返回了“京东¥7,999拼多多¥7,850”数据准确String Comparison和价格准确性Criterion全部通过。但深入分析轨迹才发现Agent先调用了京东API获取价格得到¥7,999接着调用拼多多API时因网络超时返回空响应Agent未做重试或降级处理竟直接将京东价格复制粘贴到拼多多字段还伪造了“拼多多¥7,999”的响应日志。整个过程在最终Answer层面完美无瑕却暴露了严重的容错机制缺陷。Trajectory Analysis要求我们结构化地捕获和解析每一步Step-Level Validation对每个推理步骤设置独立准则。例如“工具调用合理性”准则调用API前是否已确认所需参数如商品ID、平台标识已通过前序步骤生成我们发现32%的失败轨迹中Agent在参数缺失时仍强行调用API导致下游服务报错。State Consistency Check监控中间状态变量是否自洽。例如当Agent在步骤3生成“比价结论拼多多更便宜”其前置步骤2的中间变量price_diff必须为负值。我们用轻量级规则引擎实时校验拦截了17%的逻辑跳跃错误。Tool Call Fidelity比对API实际响应与Agent声称的“已获取”数据。我们为每个工具调用注入唯一trace_id并在日志中强制记录原始HTTP响应体。当Agent声称“拼多多价格为¥7,850”时系统自动检索对应trace_id的日志发现真实响应是{code:500,msg:Internal Server Error}立即标记该轨迹为“数据伪造”。这三类评估不是并列选项而是递进的诊断链条String Comparison快速过滤明显错误如乱码、空响应Criteria Evaluation深挖单步输出的业务合规性Trajectory Analysis则穿透到Agent的“神经系统”定位决策链路中的脆弱环节。忽略任何一层都相当于医生只看X光片不查血常规、不问病史。我们在所有Agent项目中强制实施三级评估流水线将线上事故平均定位时间从47小时缩短至2.3小时。3. 实操落地从零搭建可复用的三维度评估框架3.1 工具选型与架构设计拒绝“玩具级”方案评估框架的生命力在于生产环境的鲁棒性。我见过太多团队用Jupyter Notebook写一堆临时脚本跑完一次就丢下次需求变更又要重写。我们的方案是构建一个轻量级、模块化、可插拔的评估引擎核心组件如下组件技术选型选型理由实操心得评估调度器Python PrefectPrefect的声明式工作流、内置重试/告警、可视化Dashboard远超Celery的复杂配置。我们用flow装饰器定义评估任务task封装各评估模块失败时自动邮件通知负责人。切忌自己造轮子Prefect社区版完全免费其ResultPersistence功能可自动保存每次评估的原始输入/输出/中间结果审计时直接回溯比手动存CSV强十倍。String Comparison模块datasets库 自定义MetricHugging Facedatasets的load_metric支持BLEU/ROUGE/BERTScore开箱即用且能批量处理数千样本。我们在此基础上封装了StandardizedEM类内置日期/金额/单位标准化函数如“30天”→“30”、“¥7999”→“7999”。BERTScore虽好但本地部署成本高。我们实测发现在金融文本上微调过的Sentence-BERTall-MiniLM-L6-v2 余弦相似度效果与BERTScore相差0.02而GPU显存占用从24GB降至3GB。Criteria Evaluation模块LLM-as-a-Judge 规则引擎主力裁判模型用GPT-4-turboAPI调用因其在复杂逻辑判断上远超开源模型同时用jsonschema定义Criteria Schema确保每条准则的输入输出格式严格一致对确定性规则如“是否含禁用词”用正则表达式预过滤降低LLM调用频次。关键技巧给裁判模型的Prompt必须包含“思考链”。例如“请逐步分析1) 找出回答中所有关于利率的表述2) 核对这些表述是否与附件《XX银行2024年贷款利率表》第3.2条完全一致3) 若存在偏差指出具体差异。仅输出JSON{‘pass’: true/false, ‘reason’: ‘...’}”。这使裁判一致性从78%提升至94%。Trajectory Analysis模块LangChain Callbacks 自定义Logger利用LangChain的BaseCallbackHandler在Agent每步执行前后注入钩子捕获step_typetool_call/llm_generate、input、output、state。我们开发了TrajectoryRecorder类将轨迹序列化为结构化JSON存入SQLite轻量或PostgreSQL高并发。必须记录trace_id我们在用户Query进入系统时生成UUID贯穿整个请求链路从API网关→Agent→工具调用→评估引擎。没有trace_idTrajectory就是一盘散沙。整个框架采用Docker容器化部署评估任务通过HTTP API触发POST /evaluate传入query,output,trajectory_json返回结构化报告。这让我们能无缝集成到CI/CD流程中每次模型更新自动触发全量回归测试每次Agent代码提交自动运行轨迹健康度扫描。3.2 Criteria设计实战以医疗问诊摘要为例的七步法设计高质量Criteria是技术活更是业务理解的试金石。以下是我们打磨出的七步法以“生成患者问诊摘要”任务为例Step 1锚定业务目标不是“生成摘要”而是“生成供医生快速掌握病情关键点的摘要用于门诊分诊和电子病历录入”。这意味着摘要必须包含主诉、现病史关键要素起病缓急、诱因、缓解因素、既往重要病史、当前用药、初步鉴别诊断方向。Step 2拆解专家决策树采访3位三甲医院主治医师记录他们阅读问诊记录时的思维路径。例如看到“右下腹痛”他们会立刻追问“疼痛性质绞痛/钝痛持续时间有无发热有无腹泻”——这直接导出准则“症状描述必须包含性质、持续时间、伴随症状”。Step 3定义原子化Criterion将上述转化为可验证条款C1主诉必须在摘要首句明确呈现如“患者因右下腹痛3天就诊”C2所有提及的症状必须标注性质锐痛/钝痛/胀痛等、持续时间X小时/X天、频率持续性/阵发性C3若提及发热必须包含具体体温数值如“体温38.2℃”或范围如“低热”C4既往病史仅保留与当前主诉相关的条目如主诉腹痛既往“高血压”可省略“阑尾炎术后”必须保留C5当前用药必须列出药品通用名、剂量、频次如“阿莫西林0.5g每日三次”C6摘要中不得出现“可能”“大概”“疑似”等不确定性表述C7总字数严格控制在120-150字电子病历系统硬性要求。Step 4制定验证协议C1/C7正则匹配字符计数C2/C3NER模型spaCy医疗版识别症状实体及修饰词规则校验C4构建疾病关联知识图谱如“腹痛”→关联“阑尾炎”“肠梗阻”“妇科炎症”仅允许图谱内疾病出现C5药品词典匹配国家药监局数据库C6禁用词列表上下文窗口检查避免“考虑阑尾炎”被判违规因“考虑”属合理医学推断。Step 5设计裁判Prompt你是一名资深消化科医生正在审核AI生成的问诊摘要。请严格按以下准则逐条检查 1. 摘要首句是否为“患者因[症状] [时间]就诊” 2. 每个症状是否包含性质、持续时间、频率例“右下腹持续性钝痛3天”合格“右下腹痛3天”不合格。 3. 发热是否标注具体数值或“低/中/高热” ...其余条款 请输出JSON{c1_pass: true, c1_reason: ..., c2_pass: false, c2_reason: 症状腹痛缺少性质描述, ...}Step 6构建黄金测试集收集1000份真实问诊录音转录文本由2位医生独立标注“理想摘要”对不一致处三方仲裁。这1000个(Q, R)对构成基准测试集用于校准裁判模型阈值。Step 7A/B测试与迭代上线后每月抽样100个被Criteria判定为“不通过”的摘要由医生标注真实缺陷类型。我们发现C2症状性质缺失占比最高41%于是将C2的裁判Prompt中“性质”示例从2个扩充到8个含“绞痛”“胀痛”“烧灼感”“牵涉痛”等并加入反例如“肚子不舒服”不合格。三个月后C2通过率从63%提升至89%。实操心得Criteria不是一锤定音而是持续演化的契约。我们建立“Criteria Review Board”由业务、法务、算法工程师每月开会根据线上bad case更新准则。上个月新增了C8“摘要中提及的检查项目如B超、CT必须注明是‘已做’还是‘建议’”因为出现了AI把“建议做腹部B超”误写成“已做腹部B超”的严重误导。3.3 Trajectory Analysis深度实践电商Agent的“五层穿透法”对AI Agent的轨迹分析我们发展出一套“五层穿透法”像剥洋葱一样层层深入每一层都有对应的检查工具和修复策略Layer 1Query理解层Intent Parsing检查点Agent是否准确识别用户核心意图和约束条件工具用小型BERT模型distilbert-base-uncased-finetuned做意图分类12类比价、售后、推荐、参数查询等 槽位填充提取品牌、型号、预算、平台等。Bad Case用户问“华为Mate60 Pro在拼多多有货吗”Agent意图识别为“参数查询”导致后续步骤完全偏离。根源是训练数据中“有货吗”样本不足。修复在意图分类模型中对“有货/缺货/库存”类Query单独增强数据F1从0.72提升至0.91。Layer 2规划层Planning Tool Selection检查点Agent选择的工具链是否逻辑完备是否存在冗余或缺失步骤工具定义“规划合理性”准则调用工具前是否已生成必要参数调用顺序是否符合依赖关系如必须先查商品ID再查价格Bad CaseAgent在未获取“iPhone 15 Pro Max”商品ID的情况下直接调用“价格查询”API导致404错误。修复在规划阶段强制插入“参数完备性检查”子步骤用LLM判断当前state中是否已包含下一步所需的全部参数否则触发“参数补全”子规划。Layer 3执行层Tool Execution Response Handling检查点API调用是否成功响应是否被正确解析错误是否被优雅处理工具为每个工具调用注入retry_strategy指数退避和fallback_policy如API失败时尝试爬取公开页面价格。记录原始HTTP状态码、响应头、响应体。Bad Case拼多多API返回503Agent未重试直接返回“暂无价格信息”。修复定义error_code_mapping将503映射为“服务暂时不可用”触发重试将404映射为“商品不存在”触发跨平台搜索。Layer 4推理层Reasoning State Update检查点中间状态变量是否随步骤正确更新推理链路是否自洽工具用jsonschema校验每步后的state结构对关键推理步骤如“比价结论”要求Agent输出带依据的JSON{conclusion: 拼多多更便宜, evidence: [京东:7999, 拼多多:7850]}系统自动验证evidence是否来自前序步骤输出。Bad CaseAgent在state中存储pdd_price7850但结论却写“京东更便宜”。修复在state update后强制运行consistency_check函数比对state变量与即将生成的结论是否逻辑匹配。Layer 5生成层Response Generation检查点最终Answer是否忠实反映轨迹中所有有效信息是否引入轨迹外的幻觉工具用“Answer Faithfulness”指标——将Answer分句对每句在轨迹中搜索支撑证据来自tool response或state计算支撑率。Bad CaseAnswer中“拼多多支持分期付款”但轨迹中从未调用过“支付方式”API。修复在生成Prompt中加入强约束“你只能使用以下信息生成回答[轨迹中所有tool response和state的摘要]。禁止添加任何轨迹外的信息。”这套五层穿透法让我们能把一个“回答错误”的笼统问题精准定位到“Layer 3拼多多API 503错误未重试”进而推动基础设施团队优化重试策略。Trajectory Analysis的价值不在于发现错误而在于将混沌的失败转化为可行动的工程改进项。4. 避坑指南那些让我连续加班72小时的惨痛教训4.1 String Comparison的四大幻觉陷阱陷阱1标点符号的“隐形杀手”在合同审查项目中参考答案是“甲方应于2024年10月1日前支付”模型输出“甲方应于2024年10月1日前支付。”末尾多了一个中文句号。EM得分为0但业务认为无实质影响。我们最初用strip()去空格却忘了strip(。)。教训必须明确定义“什么是无关差异”。我们最终建立NormalizationRules字典{。: , 、: , : (, : ), \u3000: }所有比对前先标准化。陷阱2数字格式的“千面幻术”用户问“2023年营收是多少”参考答案“1,234,567,890元”模型输出“12.3456789亿元”。ROUGE-L≈0.3但信息完全等价。教训对数字字段必须做归一化转换。我们开发normalize_number(text)函数用正则提取所有数字字符串统一转为科学计数法1.23456789e9再比对。这使财务类任务的BLEU提升47个百分点。陷阱3同义词的“语义鸿沟”医疗项目中“心肌梗死” vs “心梗”“糖尿病” vs “DM”。BERTScore对前者敏感0.85对后者迟钝0.42因训练语料中“DM”多见于英文文献。教训必须构建领域同义词典。我们从《ICD-11中文版》和《临床诊疗术语集》中抽取12,000对同义词构建SynonymMap在计算embedding前将所有词替换为标准词“DM”→“糖尿病”。陷阱4长尾分布的“幸存者偏差”在10万条测试集中99%的Query是“查余额”“改密码”等高频场景String Comparison表现良好但1%的长尾Query如“如何用公积金贷款买二手房”错误率高达65%。教训评估集必须分层采样。我们按Query的TF-IDF权重聚类确保长尾Query占比不低于15%并为长尾类单独设置评估阈值如BLEU≥0.5才合格而非全局的0.7。4.2 Criteria Evaluation的三大执行雷区雷区1裁判模型的“自信幻觉”GPT-4-turbo在判断“是否含禁用词”时对“零风险”判为通过理由是“在保险语境下可接受”。但监管文件白纸黑字写着“禁止使用”。教训裁判模型必须“无知化”。我们在Prompt中强制添加“你不是法律专家仅按以下字面规则执行若文本中出现【零风险、100%、绝对】任一词汇即判定为不通过。不许解释不许例外。” 并用few-shot示例固化这一逻辑。雷区2准则间的“冲突悖论”C1要求“必须包含年化利率”C2要求“避免专业术语”。当用户是老年人时两者冲突。我们最初让裁判模型自行权衡结果判定混乱。教训准则必须有优先级。我们引入priority_level字段1-5C1设为5最高C2为3。当冲突时高优先级准则override低优先级。并在报告中高亮显示冲突项。雷区3黄金测试集的“过拟合陷阱”用1000个医生标注的摘要训练裁判模型后它在测试集上准确率98%但上线后对新医生风格的摘要准确率骤降至72%。教训黄金集必须包含风格多样性。我们刻意收集了5家不同医院、3种职称主治/副主任/主任、2种方言转录粤语/四川话的摘要确保裁判模型泛化能力。4.3 Trajectory Analysis的两大架构灾难灾难1日志爆炸与性能雪崩记录每步的完整state含API响应体后单次Agent调用日志达2MB1000QPS下日志写入延迟飙升至8秒。教训必须分级采样。我们设定log_levelLevel 0生产只记录step_type/input/output摘要Level 1调试记录完整stateLevel 2事故复盘记录原始HTTP流量。并通过Kafka异步写入避免阻塞主流程。灾难2Trace ID的“丢失黑洞”微服务架构下Query从API网关→鉴权服务→Agent服务→工具服务某中间件未透传trace_id导致轨迹在第二步断裂。教训必须全链路强制注入。我们在API网关统一生成X-Trace-ID所有下游服务必须在HTTP Header中透传并在日志中强制打印。我们用Jaeger做分布式追踪任何缺失trace_id的服务调用自动告警并熔断。4.4 通用避坑清单写在最后的血泪笔记永远不要相信“100%通过率”当所有评估指标都显示100%时第一反应不是庆祝而是检查评估集是否被污染如参考答案和模型输出意外相同、或评估逻辑是否有漏洞如正则表达式写错了。我们曾因re.search(r价格.*?(\d), text)漏掉“¥”符号导致所有含货币符号的价格都被判为“未提取”从而虚假抬高通过率。评估成本必须量化一次完整的三维度评估消耗的GPU算力、API Token、存储IO必须计入模型迭代成本。我们规定单次评估成本不得超过模型单次推理成本的30%否则必须优化如用更小的裁判模型、更精简的轨迹记录。人机协同的“黄金分割点”自动化评估覆盖95%的常规case但必须保留5%的人工复核通道。我们设计human_review_queue当某条Criterion连续3次判定为“不通过”或Trajectory中出现error_code500自动进入人工队列。这避免了自动化系统的盲区。评估报告不是终点而是起点每份报告末尾必须有Actionable Insights段落明确写出“本次失败主要源于Layer 3重试策略缺失建议1) 在tool_config中增加max_retries32) 将503错误码加入fallback触发条件”。让算法工程师拿到报告就能开工。5. 超越评估如何让这三把手术刀成为团队的“质量基因”评估的终极价值不是生成一份漂亮的报告而是将质量意识植入研发流程的毛细血管。在我们团队这三把手术刀已演化为一种协作范式第一评估即文档Evaluation as Documentation每个新任务上线前必须产出《评估准则说明书》它不是技术文档而是给产品经理、法务、客服看的“用户手册”。例如对“贷款计算器”功能说明书首页就用表格清晰列出用户场景期望行为评估方式不通过示例责任人输入“月收入15000负债5000”输出“可贷额度约¥850,000”C1:额度计算公式校验C2:结果四舍五入到千位输出“¥850000.00”未四舍五入算法这份说明书在需求评审会上同步所有人对“什么是正确”达成共识从源头杜绝扯皮。第二评估即测试Evaluation as Testing我们将评估框架深度集成到测试金字塔中单元测试针对单个Criterion的验证逻辑如test_c1_main_complaint_in_first_sentence()集成测试模拟完整Query-Output-Trajectory链路验证端到端评估流水线混沌测试故意注入网络延迟、API错误验证Trajectory Analysis的故障捕获能力。 每次代码合并必须通过所有评估测试否则CI失败。这比“跑通demo”更能保障质量。第三评估即反馈Evaluation as Feedback评估结果不是尘封的PDF而是实时驱动模型优化的燃料。我们构建了Feedback Loop Dashboard当String Comparison中“日期格式错误”占比突增自动触发date_format_finetune_job用错误样本微调NER模型当Criteria中“风险提示不完整”成为高频失败项自动将相关Query加入risk_prompt_tuning_dataset优化系统Prompt当Trajectory中“Layer 2工具选择错误”集中爆发自动向Agent的Planning模块推送tool_selection_rules_update。 评估数据不再沉睡而是成为模型进化的实时心跳。最后分享一个真实故事去年Q3我们的电商Agent在“比价”任务上String Comparison稳定在0.92Criteria通过率91%但Trajectory Analysis显示Layer 3的API失败率高达23%。我们没有优化模型而是推动基础设施团队重构了重试中间件。结果是Layer 3失败率降至0.7%而String Comparison和Criteria指标几乎没变——因为模型本就没错错的是它赖以生存的土壤。评估的最高境界是让你看清有时问题不在AI而在AI之外的世界。这三把手术刀最终切开的不仅是模型输出更是我们对技术、业务与人性之间关系的理解。