大语言模型评估实战：构建可信、可归因、可迭代的LLM量化评估体系

1. 这不是“打分考试”，而是给大模型做一次深度体检

你手头刚跑完一个微调后的Qwen2-7B，或者刚部署好本地版的Llama3-8B，又或者正纠结要不要把公司客服系统从规则引擎切换到 RAG+LLM 架构——这时候，老板甩来一句：“模型效果到底怎么样？给个量化结论。”你心里一紧：是直接拿测试集 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-70B，GPU 显存爆满还得出一堆矛盾结论；要么用规则引擎硬匹配关键词，把“我理解您的焦虑”误判为“情绪不稳定”。真相是：没有银弹，只有组合拳。我们最终落地的评估框架是三层嵌套结构，每层解决不同问题：

第一层：自动化评估（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.85（Pearson）。

这套系统将人工评估量降低 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 个月）：

• OS：Ubuntu 22.04 LTS（内核 5.15，避免新版内核的 cgroup v2 兼容问题）
• Python：3.10.12（避开 3.11 的 GC 机制变更对长文本处理的影响）
• 关键依赖：
  • transformers==4.38.2（4.39+ 版本对 Qwen2 的 attention mask 处理有 bug）
  • spacy==3.7.4（3.7.x 系列对中文依存分析准确率最高）
  • layoutparser==0.3.4（PDF 表格提取稳定性最佳）
• 硬件：单节点 2×A10（24GB VRAM），非必须 GPU，Auto-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 2：Bad Case 自动标注
用规则引擎扫描：

• user_sentiment_score < 0.2（VADER 情感分析）
• agent_handoff_count >= 2（转人工次数）
• user_message_contains("没用"|"重说"|"再说一遍")（用户显性否定）

标记出 12,437 条候选 bad case。

Step 3：聚类去重
用 Sentence-BERT 计算 query embedding，DBSCAN 聚类（eps=0.45, min_samples=3），合并语义重复样本，剩余 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-Q3）

Section 1：现象摘要（给老板看）

• 核心指标：Factuality 平均分从 4.2 → 3.7（下降 0.5，P<0.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 条样本打分，结果如下：