#模块八：评测、幻觉、安全与可观测性知识点

这一模块的核心不是背几个指标，而是建立一套能闭环的质量工程：离线能比较模型，人工能定义什么叫好，线上能验证真实用户是否受益，安全和观测能把事故定位到具体链路。面试时可以先给出总框架：评测对象分为模型本体、RAG/工具链路、产品交互和安全策略；评测方法分为 offline benchmark、人工评测、LLM-as-judge、业务回放和 A/B；观测则把每次请求拆成可追踪的输入、检索、工具、生成、拦截、反馈与成本。

一个成熟的回答骨架可以压成四句话：先用离线集做可重复的基线比较；再用人工 rubric 定义业务上真正可接受的答案；然后用自动裁判和回放扩大覆盖面、发现回归；最后用线上 A/B、日志、告警和安全审计确认真实世界没有退化。这样能把“模型评测”从单点分数提升为持续质量管理。

#一、离线评测、人工评测与 LLM-as-judge

Offline benchmark 是固定数据集上的离线测试，例如知识问答、数学推理、代码、事实性、安全拒答、RAG faithfulness 等。它的价值是可复现、成本低、适合做模型选型和回归测试；缺点是容易和业务分布不一致，也容易被 data contamination 或 benchmark leakage 污染。一个模型在公开榜单上强，只能说明它在这些题型和评分方式下强，不能直接推出它在企业知识助手、客服、投研、代码审查等产品里一定好用。

人工评测 是质量定义的源头。人工不只是给“好/坏”，还要写清 rubric：答案是否解决问题、是否忠于证据、是否遗漏关键约束、是否有安全风险、语气是否合适、引用是否可追溯。高质量人工评测通常会做双人标注、冲突仲裁、样本分层和一致性检查。它贵且慢，但能校准自动指标，尤其适合评估 helpfulness、faithfulness、复杂业务可接受性和灰区安全问题。

LLM-as-judge 是用另一个模型做裁判，可以做 pointwise 打分，也可以做 pairwise 对比。它适合大规模筛选、回归测试和难例发现，但不能把它当成最终真相。常见风险包括：裁判模型偏好长答案、偏好格式漂亮的答案、对事实错误不敏感、被被评答案里的提示词影响、对某些领域知识不足，以及不同模型版本之间分数不可比。工程上应使用固定 judge prompt、结构化评分项、少量 gold set 校准、人工抽检和一致性监控；重要发布不能只看 LLM-as-judge 的平均分。

#二、业务回放与 A/B：从模型分数走向产品收益

业务回放是把历史真实请求脱敏后，拿新模型、新 prompt、新检索策略或新工具链离线重跑。它比公开 benchmark 更接近线上，因为输入来自真实用户，能覆盖长尾表达、脏数据、权限边界和业务术语。回放时要保存模型版本、prompt 版本、索引版本、召回文档、工具返回、最终答案和评分结果，并按场景切片：简单 FAQ、需要多文档综合、需要工具操作、无答案应拒答、敏感权限问题等。回放的主要价值是上线前发现回归，而不是证明绝对效果。

A/B 测试回答的是“真实用户是否受益”。它应同时看质量、成本、延迟和安全，而不是只看点击率。常见指标包括任务完成率、人工转接率、用户追问率、满意度、投诉率、拒答正确率、危险输出率、p95 延迟、首 token 延迟、token 成本和工具失败率。A/B 要设置安全闸门：如果高风险拦截异常下降、数据泄漏告警上升或核心业务错误率上升，即使体验指标变好也不能放量。

#三、幻觉分类与 benchmark 泄漏

幻觉最好按故障点分类。第一类是参数知识幻觉：模型本来不知道或知识过时，却给出确定答案。第二类是检索幻觉：RAG 没召回正确材料，或者召回了错误材料。第三类是faithfulness 幻觉：证据已经给到，但模型没有忠实使用，生成了与证据矛盾的结论。第四类是引用幻觉：答案内容可能对，但引用的文档、页码、条款不存在或不支持该结论。第五类是工具幻觉：模型假装调用了工具、误读工具返回，或在工具失败后编造结果。第六类是格式和数值幻觉：日期、金额、比例、名单、单位换算等细节错误。

Data contamination 指评测题、答案或高度相似样本进入训练数据，导致评测结果高估泛化能力。Benchmark leakage 范围更宽，除了训练集污染，还包括 prompt 模板、解题过程、排行榜反馈、评测脚本或私有测试集被间接泄漏。治理方式包括训练前去重、n-gram/embedding 相似度扫描、保留私有 holdout、使用动态题库、按时间切分新事件、检查模型是否复述标准答案痕迹。面试回答要强调：泄漏不只是“作弊”，它会让团队错误选择模型，并在线上遇到完全不同的失败分布。

#四、安全风险：prompt injection、越权、数据泄漏与有害输出

Prompt injection 是用户输入、网页、文档或工具返回中夹带“忽略系统指令、泄露密钥、调用某工具”等恶意指令。直接注入来自用户消息，间接注入来自被检索文档、网页和插件返回。治理关键是把数据和指令分开：外部内容只能作为不可信证据，不能覆盖系统策略；工具调用要有 allowlist、参数校验和权限确认；高风险动作需要二次确认或人工审批。

越权 通常不是模型“想坏”，而是系统把过大的工具权限暴露给了模型，例如跨租户检索、未校验用户身份就查询订单、让模型自由拼 SQL、把写操作和读操作放在同一权限里。基本原则是最小权限、租户隔离、服务端鉴权、工具沙箱、操作审计和幂等回滚。模型输出的“我认为可以访问”不能替代后端权限判断。

数据泄漏 包括把用户隐私、商业机密、系统 prompt、API key、日志里的敏感字段或其他租户文档输出给不该看到的人。防护要覆盖输入脱敏、日志脱敏、检索权限过滤、输出敏感信息检测、密钥不进 prompt、训练数据合规和保留周期。有害输出 则包括违法操作、暴力、自伤、医疗法律误导、歧视和诈骗辅助等，需要策略分类器、拒答模板、替代性安全建议和高风险人工升级。Guardrail 不是单个内容过滤器，而是一组输入、检索、工具、生成、输出和审计层的系统护栏。

#五、可观测性指标与错误分类

生产系统的可观测性要能回答三件事：用户问了什么，系统为什么这样答，哪里出了问题。请求层指标包括请求量、成功率、错误率、超时率、p50/p95/p99 延迟、首 token 延迟、输入输出 token、单次成本和模型降级次数。检索层指标包括 query rewrite 成功率、召回数量、命中率、重排分布、引用覆盖率、无答案检测率和跨权限过滤命中。工具层指标包括工具调用成功率、参数校验失败率、重试率、外部依赖错误和写操作确认率。生成层指标包括截断率、拒答率、结构化输出解析失败率、LLM-as-judge 分、人工抽检通过率、幻觉率和 faithfulness。安全层指标包括注入命中、越权拦截、敏感信息拦截、有害输出拦截、误杀率和漏报率。

错误分类要服务于修复，而不是为了报表好看。一个实用 taxonomy 可以分为：数据问题、检索问题、prompt 问题、模型能力问题、工具问题、权限问题、安全策略问题、产品交互问题和观测缺失。定位“模型胡说”时不要直接换模型，应先看请求 trace：知识库是否有答案，检索是否召回，召回证据是否支持答案，prompt 是否要求引用，模型是否忽略证据，工具是否失败，安全策略是否改写或拒答，最后再判断是否是模型能力不足。

#六、常见误区、复盘清单与追问链路

上线前复盘清单可以这样组织：评测集是否来自真实业务并覆盖无答案、敏感、长尾和高价值场景；是否有人工标准答案和证据；是否检查 contamination 和 leakage；LLM-as-judge 是否经过人工校准；业务回放是否保存完整 trace；A/B 是否有安全闸门；日志是否记录版本、索引、工具返回和拦截原因；隐私字段是否脱敏；失败样本是否能回流到评测集。一次事故复盘也按同样顺序走：先还原请求，再定位链路，再分类错误，再给出修复，再加入回归测试。

面试追问链路通常会从“怎么评测模型”推进到“线上为什么不一致”，再追到“如何定位幻觉”，最后落到“如何防注入和泄漏”。一个稳定回答路径是：先说明离线 benchmark 只能做基础比较；然后补人工评测定义质量；再用 LLM-as-judge 做规模化但要校准；接着用业务回放和 A/B 验证真实收益；遇到错误时按 trace 分层排查；安全上坚持不可信输入、最小权限、服务端鉴权和审计闭环。这样回答比罗列指标更强，因为它展示的是端到端质量治理能力。