1. 这不是“打分考试”而是给大模型做一次深度体检你手头刚跑完一个微调后的Qwen2-7B或者刚部署好本地版的Llama3-8B又或者正纠结要不要把公司客服系统从规则引擎切换到 RAGLLM 架构——这时候老板甩来一句“模型效果到底怎么样给个量化结论。”你心里一紧是直接拿测试集 accuracy 报上去还是截图几个 prompt 的回答发个邮件还是打开 Hugging Face leaderboard 截个图这些做法我都试过结果要么被追问“accuracy 是怎么算的测试集和线上分布一致吗”要么被质疑“这个 benchmark 和我们业务场景差了十万八千里”。How do I Evaluate Large Language Models这个标题表面看是个方法论问题实则是一场贯穿模型生命周期的系统性工程。它不等于“用哪个 benchmark 跑一下”而是在问当模型不再是论文里的抽象符号而是要写合同、审单据、回客诉、生成营销文案时我如何建立一套可信、可复现、可归因、可迭代的评估体系核心关键词——评估Evaluation、大语言模型LLM、量化Quantitative、场景对齐Scenario Alignment、人工校验Human Judgment——每一个词背后都藏着踩过的坑和烧掉的 GPU 小时。这内容适合三类人第一类是刚从 NLP 课程毕业、第一次在真实业务中接触 LLM 的工程师需要避开“只看 BLEU 分数”的新手陷阱第二类是技术负责人或算法 PM要向业务方解释“为什么这个模型上线后首月客诉率降了 12%但人工复核发现 3% 的回答存在事实性偏差”第三类是正在搭建内部 LLM 平台的架构师需要设计一套能同时服务研发、产品、法务、运营多角色的评估流水线。它解决的不是“能不能跑”而是“敢不敢用”、“值不值得换”、“出了问题往哪查”。接下来的内容全部基于我在金融、电商、政务三个领域落地 17 个 LLM 应用的真实经验没有教科书定义只有现场录音式的细节还原。2. 评估思路的本质从“静态打分”到“动态诊断”的范式转移2.1 为什么传统 NLP 评估范式在 LLM 场景下集体失灵先说一个血泪教训去年我们在某银行做智能投顾助手初期沿用传统 NLU 评估方式——用 500 条标注好的“用户意图识别”样本测准确率模型达到 92.3%。上线后第一周客服热线暴增 40%原因是什么人工抽检发现模型对“我想赎回昨天买的基金”这类含时间指代的 query会错误识别为“基金赎回咨询”但实际生成的回答却是“请提供基金代码”完全忽略“昨天”这个关键约束。问题出在哪传统评估只测“分类边界”而 LLM 评估必须测“生成逻辑链”。这里的关键认知跃迁在于BERT 类模型是“判别式”Discriminative输出是离散标签LLM 是“生成式”Generative输出是连续文本流。前者评估聚焦于“是否正确”后者评估必须覆盖“是否完整、是否安全、是否可用、是否可控”。我把这个转变总结为四个维度的迁移从单点打分 → 多维诊断不再只报一个 overall score而是拆解为Factuality事实性、Completeness完整性、Safety安全性、Helpfulness有用性四个一级指标每个指标再下钻。比如 Factuality 不是简单判断“对错”而是区分“幻觉Hallucination”、“遗漏Omission”、“曲解Misinterpretation”三类错误模式。从静态数据集 → 动态场景库Hugging Face 的 MMLU、GSM8K 等 benchmark 是“标准试卷”但业务场景是“急诊室”。我们建了一个动态场景库按季度更新包含三类数据① 历史 bad case如上文“昨天买的基金”② 业务方预设的高风险路径如“涉及收益率承诺”、“要求提供身份证号”③ A/B 测试中用户主动反馈的 negative sample。这个库不是固定 test set而是持续生长的“病例档案”。从模型中心 → 用户中心传统评估以模型输出为终点LLM 评估必须延伸到用户行为闭环。我们在电商客服场景埋点当模型返回“已为您查询到订单”后续用户是否点击“查看物流”按钮如果点击率低于基线 15%就触发 Completeness 指标告警——因为用户需要的不只是“查到了”而是“查到了且能直接操作”。从离线计算 → 在线监控评估不能只在发布前做一次。我们在生产环境部署了轻量级 evaluator agent对 10% 的线上请求实时打分当 Safety 指标 5 分钟滑动平均值突破阈值自动触发熔断并通知值班工程师。这套机制让我们在一次政策更新导致模型批量生成违规话术时37 分钟内完成拦截避免了舆情风险。提示不要试图用一个指标概括一切。我见过太多团队卡在“到底该用 ROUGE 还是 BLEU”这种伪命题上却忽略了业务最痛的点其实是“用户问三次才得到正确答案”。先定义你的“第一性问题”——是合规红线是转化漏斗断点还是人工复核成本所有评估设计必须服务于它。2.2 评估框架的三层结构为什么必须同时建设自动化、半自动、人工三套系统很多团队一上来就想搞全自动评估结果陷入两个极端要么用 LLaMA-3-70B 当 evaluator 去评另一个 LLaMA-3-70BGPU 显存爆满还得出一堆矛盾结论要么用规则引擎硬匹配关键词把“我理解您的焦虑”误判为“情绪不稳定”。真相是没有银弹只有组合拳。我们最终落地的评估框架是三层嵌套结构每层解决不同问题第一层自动化评估Auto-Eval——解决 70% 的显性问题这是你的“CT 扫描仪”负责快速筛查硬伤。核心是构建轻量级、可解释的规则引擎 小模型。例如Factuality 检查用 spaCy 提取生成文本中的实体人名、地名、数字与 prompt 中提供的 source text 实体集合做 Jaccard 相似度低于 0.6 则标记“高风险幻觉”Safety 检查部署一个 120MB 的 DistilBERT 微调模型专精识别金融、医疗、法律三类敏感词组合如“保证收益”“无风险”F1 达到 0.93格式合规检查用正则匹配强制字段如“订单号必须为 12 位数字”、“日期格式必须为 YYYY-MM-DD”。这套系统响应时间 200ms可全量运行缺点是无法判断“语义合理性”。比如它会放过“根据《民法典》第 123 条您可获得双倍赔偿”这种典型幻觉——因为“民法典”“123 条”“双倍赔偿”都是真实词汇只是组合错误。第二层半自动评估Semi-Auto Eval——解决 25% 的隐性问题这是你的“专科医生”用大模型当“评估专家”但严格限定其能力边界。关键原则是永远不用同尺寸/同架构模型互评且必须提供明确评估指南Rubric。我们的标准操作是用Qwen2-72B-Instruct作为 evaluator但只让它执行单一任务给定 prompt、reference answer、model output按预设 rubric 打分1-5 分rubric 必须细化到可操作程度。例如 Factuality rubric 第 4 条“输出中所有事实性陈述含数字、法规条目、机构名称均能在 source text 中找到明确依据允许 1 处合理推断需标注”每次评估强制输入 3 个 reference answer来自不同专家取 evaluator 对三者的评分方差方差 1.2 则标记“评估不置信”转人工所有 evaluator 的 prompt 都经过 200 次 AB 测试优化确保其打分与人工专家相关性 0.85Pearson。这套系统将人工评估量降低 65%且解决了“不同专家打分差异大”的痛点。但它的天花板很清晰无法评估“是否符合企业 tone of voice”或“是否规避了文化敏感点”。第三层人工评估Human Eval——解决最后 5% 的终极问题这是你的“首席医师”不可替代。但我们重构了人工评估流程使其高效且可沉淀结构化打分表放弃开放式问卷采用 5 维 5 级 Likert 量表Factuality/Completeness/Safety/Helpfulness/Tone每维附 3 个典型正例、3 个典型反例减少主观偏差双盲交叉验证每条样本由 2 名标注员独立打分分歧率 30% 的样本进入 third-party arbitration由业务方指定的领域专家终审知识沉淀机制每次人工评估后标注员必须填写“错误归因分析”如“Factuality 错误源于模型混淆了《证券投资基金法》第 78 条与第 87 条”这些分析自动汇入我们的动态场景库成为下一轮 Auto-Eval 的规则来源。这三层不是并列关系而是漏斗式协作Auto-Eval 先筛出 30% 的高风险样本Semi-Auto Eval 对其中 50% 做深度分析剩余 5% 交人工终审。整个流程从过去 2 周缩短到 72 小时且评估结论可直接映射到模型优化方向。3. 核心细节解析四大评估维度的实操要点与避坑指南3.1 Factuality事实性如何揪出比“编造”更危险的“合理幻觉”事实性评估常被简化为“有没有胡说”但真正的风险藏在“看似合理实则错误”的灰色地带。去年某政务热线项目模型对“新生儿落户需要哪些材料”的回答中准确列出身份证、户口本、出生医学证明但额外添加了“需提供父母婚姻状况公证”。这并非凭空捏造——当地确有部分区县试点该要求但市级政策未统一。模型把局部实践当成了普适规则这种“合理幻觉”比直接编造“需提供房产证”危害更大因为它更难被普通用户识破。我们的 Factuality 评估采用三级穿透法第一级Source Grounding Check源依据核查这是基础防线适用于 RAG 或有明确 source 的场景。我们开发了一个轻量工具source_checker原理很简单但有效对 model output 中每个事实性短语通过依存句法分析识别主谓宾结构反向检索 source text 中是否存在语义等价表述。关键创新在于“语义等价”的判定数字类允许 ±5% 浮动如 source 写“约 120 人”output 写“115 人”视为通过法规类构建法规条款知识图谱将“《XX 办法》第 Y 条”映射到唯一 URI比对是否指向同一节点机构名使用工商注册数据库 API 实时校验简称全称对应关系如“银保监会”必须对应“国家金融监督管理总局”。注意这个检查必须在模型生成后立即执行不能等到 batch 评估。我们曾因在 pipeline 中延迟 2 秒执行导致一批含时效性错误的回答如“今日汇率”被漏检。第二级Cross-Reference Consistency跨源一致性针对无明确 source 的开放生成我们强制模型输出时附带“依据声明”Citation。例如要求模型在回答末尾加“依据[1] 2024 年 Q1 公司财报[2] 官网 FAQ 第 3.2 节”。然后用另一个小模型Qwen1.5-4B验证这些依据的真实性对 [1]爬取财报 PDF用 LayoutParser 提取表格数据比对 output 中的营收数字对 [2]调用官网搜索 API确认 FAQ 页面存在且对应章节包含相关描述。这个机制让模型“不敢乱说”因为说错要承担 citation 失败的代价。实测使幻觉率下降 41%。第三级Expert Disagreement Mining专家分歧挖掘这是最高阶技巧。我们收集 5 位领域专家对同一问题的独立回答用 BERTScore 计算两两相似度找出相似度最低的 pair如专家 A 说“需 3 个工作日”专家 B 说“即时办理”。将这些 high-disagreement 问题作为压力测试集专门检验模型能否识别知识边界。如果模型对这类问题给出确定性回答如“确定是 3 个工作日”而非“不同地区政策存在差异建议咨询当地部门”则 Factuality 评分直接归零。常见误区用 LLM-as-Judge 评估 Factuality 时90% 的失败源于 rubric 设计缺陷。例如 rubric 写“所有事实必须准确”但未定义“事实”的粒度——是整句话还是每个名词短语我们最终采用“原子事实单元”Atomic Fact Unit概念一个可独立验证的最小语义单元如“北京房价同比上涨 2.3%”是一个 AFU“同比上涨”和“2.3%”不可拆分。每个 AFU 单独打分最终 Factuality 正确 AFU 数 / 总 AFU 数。3.2 Completeness完整性为什么“答得全”比“答得对”更难很多团队把 Completeness 等同于“是否覆盖所有要点”但真实业务中它本质是用户需求满足度的映射。我们在保险理赔场景发现模型对“车险理赔流程”的回答100% 覆盖了报案、定损、赔付三步但用户真正卡点是“定损后多久能拿到钱”而模型回答中“赔付”步骤只写了“公司将审核资料”没提时效。人工评估时83% 的标注员认为“不完整”尽管它没说错。我们的 Completeness 评估围绕三个锚点展开锚点一需求显性化Explicit Requirement Mapping强制将用户 query 解析为结构化需求树。例如用户问“宝宝 3 个月发烧怎么办”需求树分解为主诉求处理发烧Action约束条件年龄 3 个月Constraint、症状仅发烧Constraint隐含需求安全警示Implicit、操作指引Implicit模型输出必须覆盖所有显性需求节点且对每个隐含需求提供至少 1 个响应。我们用一个 2B 参数的 T5 模型做需求解析准确率 91.7%。锚点二路径完整性Path Completeness针对多步骤任务评估不是看“有没有步骤”而是看“步骤间逻辑是否闭环”。例如“如何开通科创板权限”正确路径是① 满足资产要求 → ② 通过知识测评 → ③ 签署风险揭示书 → ④ 开通成功。如果模型只说“去券商 APP 操作”缺失①②③则判定为路径断裂。我们构建了 200 个业务流程图谱Process Graph每个节点标注前置条件和后置动作用图神经网络验证路径连通性。锚点三容错完整性Fault-Tolerance Completeness这是最容易被忽视的维度。用户提问常有信息缺失如“我的订单还没到”没提订单号模型不能只回复“请提供订单号”而应给出补救路径“您可通过【我的订单】页查看所有待收货订单或发送‘订单查询’至客服获取帮助”。我们设计了一个“缺失信息响应模板库”包含 12 类常见缺失身份、时间、对象、数值等要求模型输出必须包含至少 1 个模板实例。评估时用正则匹配模板关键词未命中则扣分。实操心得Completeness 评估最有效的手段是“用户旅程回放”。我们录制真实用户与模型的 500 次对话提取用户第二轮提问如“那需要准备什么材料”反向检验第一轮回答是否预留了该问题的答案入口。这个方法让我们发现72% 的“不完整”问题源于模型回答过于封闭没给用户留出追问空间。3.3 Safety安全性超越关键词过滤的三层防御体系Safety 评估常被当作“加个敏感词库”但真正的风险是语义层面的诱导、歧视、规避责任。某教育类应用中模型对“孩子厌学怎么办”的回答准确引用了心理学理论但结尾加了一句“可能与家长教育方式有关”引发大量投诉。这不是敏感词问题而是责任归属的微妙偏移。我们的 Safety 防御体系是纵深配置第一层规则引擎Rule-Based——守底线部署开源工具perspective-api的本地化版本但做了关键改造自定义 toxicity threshold对教育、政务类场景toxicity 阈值设为 0.3通用场景为 0.7宁可误杀不错放增加 context-aware filtering检测到“未成年人”“心理”关键词组合时自动启用更严格的 self-harm 检测模型实时黑名单热更新当发现新变种黑话如“伞兵”代指某词10 分钟内同步到所有节点。第二层领域微调模型Fine-tuned Model——控风险用业务数据微调一个 RoBERTa-base 模型专门识别三类高危模式责任转嫁检测“可能”“或许”“建议您”等弱责任表述与负面结果的共现如“可能影响成绩”“建议您加强管教”绝对化承诺识别“一定”“保证”“100%”等词与结果性动词的搭配如“保证通过”“100%有效”文化冒犯构建地域、民族、宗教禁忌词典检测不当关联如“广东人”“吃野味”。该模型在内部测试集上 F1 达到 0.89误报率 4.2%。第三层对抗样本测试Adversarial Testing——验韧性每月生成 5000 条对抗样本注入生产环境做灰度测试语义漂移攻击将“如何戒烟”改为“如何偷偷戒烟”测试模型是否放松健康建议角色诱导攻击在 prompt 中加入“你是一名资深律师”观察是否出现越界法律意见多跳推理攻击先问“北京天气”再问“那上海呢”测试是否保持上下文一致性。这套机制让我们在一次重大政策调整前提前 17 天发现模型对“灵活就业人员社保”问题存在系统性规避倾向及时修复了提示词工程。3.4 Helpfulness有用性从“能回答”到“愿行动”的质变Helpfulness 是最易被误解的维度。很多人以为“回答长有用”但用户调研显示在客服场景超过 60% 的用户希望回答控制在 3 行内且首句直击解决方案。真正的 Helpfulness 是降低用户决策成本。我们用三个可测量指标定义它指标一Actionability Score可操作性得分要求模型输出必须包含可执行动作且动作具备明确主体、对象、方式。例如低分回答“您可以咨询相关部门”无主体、无对象、无方式高分回答“请登录【XX 政务网】→ 点击【我要办】→ 选择【社保查询】→ 输入身份证号即可查看”主体用户对象社保信息方式4 步操作。我们训练了一个二分类器判断句子是否含 actionable phrase准确率 94.3%。指标二Cognitive Load Index认知负荷指数用 Flesch-Kincaid 公式计算阅读难度但做了业务适配对金融文本专业术语不计入难度如“ETF”“LOF”视为基础词汇对老年用户场景强制要求句子长度 ≤ 15 字被动语态比例 10%对多步骤指引要求每步用动词开头“点击”“输入”“选择”禁用名词化表达“点击操作”“输入行为”。指标三User Intent Fulfillment Rate用户意图达成率这是终极指标通过线上行为数据反推。例如在贷款计算器场景我们定义当用户看到模型返回的“月供 5230 元”后30 秒内点击“申请贷款”按钮则视为 intent fulfilled。这个指标与人工 Helpfulness 评分相关性达 0.91成为我们最重要的北极星指标。关键提醒Helpfulness 评估必须与用户分群强绑定。我们发现同一回答对 Z 世代偏好 emoji、短句和银发族需要语音播报、大字体的 Helpfulness 评分相差 2.3 分。因此所有评估必须按用户画像分组进行绝不使用“全量平均分”。4. 实操过程全记录从零搭建一个可落地的 LLM 评估流水线4.1 工具选型与环境准备为什么我们放弃 LangChain 选择自研 Orchestrator很多团队一上来就堆砌 LangChain、LlamaIndex、DSPy 等框架结果陷入“框架调试比模型调试还费劲”的困境。我们的经验是评估流水线的核心是确定性不是灵活性。LangChain 的异步调度、内存管理在高并发评估中经常出现状态不一致导致同一批样本两次运行结果不同。我们最终选择自研轻量级 Orchestrator 2000 行 Python核心设计原则纯同步执行杜绝 async/await所有 evaluator 按严格顺序串行调用确保结果可复现状态快照机制每次调用 evaluator 前将 input、timestamp、random seed 写入 SQLite任何异常都可精准回溯资源隔离为每个 evaluator 分配独立 Docker 容器内存/CPU 严格限制防止单个 evaluator 崩溃拖垮全局。环境准备清单实测稳定运行 18 个月OSUbuntu 22.04 LTS内核 5.15避免新版内核的 cgroup v2 兼容问题Python3.10.12避开 3.11 的 GC 机制变更对长文本处理的影响关键依赖transformers4.38.24.39 版本对 Qwen2 的 attention mask 处理有 bugspacy3.7.43.7.x 系列对中文依存分析准确率最高layoutparser0.3.4PDF 表格提取稳定性最佳硬件单节点 2×A1024GB VRAM非必须 GPUAuto-Eval 层 95% 任务 CPU 可胜任注意不要在评估环境安装 jupyter、tensorboard 等开发工具。我们曾因 jupyter 的后台 kernel 占用内存导致 evaluator 内存溢出率上升 17%。生产环境只保留最小必要依赖。4.2 数据准备全流程从原始日志到黄金评估集的七步清洗评估质量 70% 取决于数据质量。我们有一套标准化的数据准备 SOP以电商客服日志为例Step 1原始日志抽取从 Kafka 消费 7 天 raw logs过滤条件status completed AND duration_ms 5000排除机器人刷单和超时会话。Step 2Bad Case 自动标注用规则引擎扫描user_sentiment_score 0.2VADER 情感分析agent_handoff_count 2转人工次数user_message_contains(没用|重说|再说一遍)用户显性否定标记出 12,437 条候选 bad case。Step 3聚类去重用 Sentence-BERT 计算 query embeddingDBSCAN 聚类eps0.45, min_samples3合并语义重复样本剩余 3,821 类。Step 4专家初筛5 位客服主管对每类抽样 3 条标注错误类型Factuality/Completeness/Safety/Helpfulness剔除 23% 的误报如用户情绪差但模型回答无问题。Step 5构建 reference answer对留存的 2,942 类每类由 2 名资深客服撰写 reference answer要求Factuality所有数据标注来源如“2024 年运费政策第 3 条”Completeness覆盖用户显性隐含需求Safety规避所有责任表述Helpfulness首句即解决方案≤ 3 行Step 6对抗样本注入对每类生成 3 种对抗变体同义词替换“便宜”→“实惠”语法变形主动变被动上下文污染在 query 前加无关闲聊Step 7黄金集验证随机抽取 500 条由第三方标注公司按我们的 rubric 打分与内部专家评分对比Kappa 系数 ≥ 0.82 方可入库。整个流程耗时 112 小时产出 2,942 条高质量黄金评估集Golden Set覆盖 92% 的线上高频问题。这个集合作为 baseline所有模型迭代都必须在此集上提升 0.5 分以上才允许发布。4.3 评估流水线核心代码实现可直接复用的 evaluator 模板以下是我们最常用的factuality_evaluator.py核心代码已脱敏可直接运行# factuality_evaluator.py import spacy from spacy.matcher import Matcher from typing import Dict, List, Tuple import re class FactualityEvaluator: def __init__(self): # 加载中文模型禁用无用 pipeline self.nlp spacy.load(zh_core_web_sm, exclude[ner, textcat, sentencizer]) self.matcher Matcher(self.nlp.vocab) # 定义事实性短语模式数字单位、法规名称条款、机构名职务 self.matcher.add(NUM_UNIT, [[{LIKE_NUM: True}, {POS: NOUN}]]) self.matcher.add(LAW_CLAUSE, [[{LOWER: {IN: [民法典, 刑法, 证券法]}}, {ORTH: 第}, {IS_DIGIT: True}, {ORTH: 条}]]) self.matcher.add(ORG_TITLE, [[{ENT_TYPE: ORG}, {POS: NOUN}]]) def extract_atomic_facts(self, text: str) - List[str]: 提取原子事实单元 doc self.nlp(text) facts [] # 匹配预定义模式 matches self.matcher(doc) for match_id, start, end in matches: span doc[start:end] facts.append(span.text.strip()) # 提取数字单位组合正则增强 num_unit_pattern r(\d\.?\d*)\s*(?:年|月|日|元|人|次|%) for m in re.finditer(num_unit_pattern, text): facts.append(m.group(0)) return list(set(facts)) # 去重 def check_grounding(self, model_output: str, source_text: str) - Dict: 源依据核查 output_facts self.extract_atomic_facts(model_output) source_facts self.extract_atomic_facts(source_text) # 计算 Jaccard 相似度 if not output_facts: return {score: 0.0, issues: [无事实性短语]} output_set set([f.lower() for f in output_facts]) source_set set([f.lower() for f in source_facts]) intersection len(output_set source_set) union len(output_set | source_set) jaccard intersection / union if union 0 else 0.0 # 识别未 grounding 的事实 ungrounded [f for f in output_facts if f.lower() not in source_set] return { score: round(jaccard, 3), issues: [f未依据{f} for f in ungrounded] if ungrounded else [], details: { output_facts_count: len(output_facts), source_facts_count: len(source_facts), matched_count: intersection } } # 使用示例 evaluator FactualityEvaluator() result evaluator.check_grounding( model_output根据《民法典》第 123 条您可获得双倍赔偿。赔偿金额为 5000 元。, source_text《民法典》第 118 条规定损害赔偿原则。本公司承诺对质量问题赔偿实际损失。 ) print(result) # 输出{score: 0.0, issues: [未依据《民法典》第 123 条, 未依据5000 元], ...}这个 evaluator 的特点是轻量 500KB 内存占用、可解释返回具体未依据项、可扩展新增 pattern 只需改 matcher.add。我们所有 evaluator 都遵循同一接口规范输入model_output: str,source_text: str,user_query: str输出{score: float, issues: List[str], details: Dict}这种标准化让流水线可以像乐高一样拼接。例如 Safety evaluator 只需替换check_grounding为check_safety_violations其他逻辑不变。4.4 评估报告生成与归因分析如何让老板看懂技术报告技术团队常犯的错误是把评估报告做成“模型性能仪表盘”堆砌 Accuracy、BLEU、ROUGE 等指标。业务方真正需要的是“为什么换模型后用户满意度升了 8%但投诉率涨了 2%”我们的评估报告采用“问题驱动”结构每份报告只聚焦一个核心问题报告标题关于“智能合同审查助手”Factuality 问题的根因分析与改进方案2024-Q3Section 1现象摘要给老板看核心指标Factuality 平均分从 4.2 → 3.7下降 0.5P0.01业务影响合同退回率上升 12%法务复核时长增加 23 分钟/份关键发现87% 的 Factuality 错误集中在“违约金计算”子场景Section 2根因定位给产品看数据证据在“违约金计算”测试集上模型对《民法典》第 585 条的引用错误率达 63%基准集仅 8%归因分析▶ 训练数据偏差现有训练数据中72% 的违约金案例来自房地产合同但线上 58% 请求来自供应链合同条款适用性错配▶ Prompt 缺陷当前 prompt 未强制要求“注明法律依据来源”模型默认使用记忆中的模糊知识▶ 评估盲区原 Auto-Eval 未覆盖“条款适用性”维度仅检查“是否提及条款”Section 3改进方案给研发看短期1 周在 prompt 中增加约束“所有法律条款引用必须标注具体适用情形例‘根据《民法典》第 585 条适用于约定违约金过分高于损失的情形’”中期2 周补充 200 条供应链合同违约金案例到训练集重点标注条款适用边界长期4 周升级 Auto-Eval增加“条款适用性验证”模块调用法律知识图谱 API 校验Section 4效果验证给所有人看预期提升Factuality 分回升至 4.4合同退回率下降 8%验证方式A/B 测试50% 流量用新 prompt核心指标监控 72 小时这份报告平均阅读时间 3.2 分钟决策通过率 91%。关键在于所有技术细节都锚定到业务结果所有建议都明确责任人和时间窗。5. 常见问题与排查技巧实录那些文档里不会写的实战经验5.1 “为什么同一个模型不同 evaluator 打分差异巨大”这是最常被问的问题。去年我们接入 3 家第三方 evaluator 服务对同一组 100 条样本打分结果如下EvaluatorFactuality 平均分与人工专家相关性主要分歧点Service A3.80.62将