十、评估与质量保障
评估是 LLM 应用最被低估、也最能区分工程成熟度的模块。这一章考的是体系感：能不能分层设计指标、能不能让评估和迭代形成闭环、拿到 Bad Case 能不能归因到正确的层。
103. LLM 应用的评估体系怎么搭？离线评估和在线评估各测什么、怎么闭环？
必刷·中等
参考答案
结论先行：分三层搭——组件级、端到端离线、在线业务指标，用 Bad Case 流转把三层串成闭环。只搭其中一层都是残缺的。
离线评估（发布前，测质量）：
- 组件级：把链路拆开单独测。检索层测召回率@k、MRR、上下文命中率；生成层测忠实度、相关性、格式合法率；Agent 组件测工具选择准确率、参数合法率。组件级评估的价值是定位问题在哪个环节，端到端分数差没法告诉你该改哪；
- 端到端：完整链路跑真实请求，产出"这个回答好不好"的综合判断。手段按成本递进：规则指标（可全自动化）→ LLM as Judge（规模化打分）→ 人工抽检（校准金标准）；
- 载体是版本化评估集：线上采样 + 边界 case + 历史 bad case 沉淀，随业务持续演化（详见第 105 题）。
在线评估（上线后，测效果）：
- 业务结果指标：问题解决率、答案采纳率、用户点踩率、转人工率、重试/重新生成率——这才是产品质量的最终裁判；
- 过程监控指标：延迟（TTFT/整体）、Token 成本、错误率、安全拒绝率、缓存命中率——保障运行质量。
闭环机制（体系的核心）：
- 线上监控发现异常（点踩率上升）/ 用户反馈进 bad case 池；
- 归因分析（第 110 题的流程）定位到检索 / Prompt / 模型层；
- 修复方案先过离线评估集做回归（第 108 题），确认"改好一处没改坏别处"；
- 修复上线后，该 bad case 固化进评估集，防止同类问题复发；
- 定期把线上新流量采样进评估集，保持分布同步。
一句话：离线评估决定"能不能发"，在线评估验证"发得对不对"，Bad Case 流转决定"体系会不会越来越好"。
面试官可能追问
- 评估的频率和自动化程度怎么定？（评估集进 CI，改 Prompt/模型/检索参数的 MR 自动触发，人工只看报告和边界 case）
- 组件好但端到端差，可能是什么原因？（组件指标没对齐业务目标——比如召回率高但召回的不是用户问的那部分；或生成层没利用好检索结果）
- 资源有限时优先搭哪层？（先建一个 100~300 条的端到端评估集 + 最关键的在线指标，有闭环再逐步细化组件级）
104. LLM as Judge 是什么？有哪些坑？（位置偏差、长度偏差、自我偏好）怎么缓解？
必刷·中等
参考答案
是什么：用一个强 LLM 按评分标准（rubric）给被评模型的输出打分（pointwise）或比较优劣（pairwise），让"没有标准答案的开放任务"可以规模化评估。MT-Bench、G-Eval 等工作验证了强模型裁判与人工判断的一致率能达到 80% 上下的量级，足以支撑迭代，但前提是把坑管住。
三个经典偏差及对策：
- 位置偏差：pairwise 比较时裁判偏爱特定位置（通常是第一个）的答案。对策：同一对交换 A/B 位置评两次，结论一致才采信，不一致记平局；
- 长度偏差：偏爱更长、更"详细"的答案，哪怕信息量相同甚至啰嗦。对策：rubric 显式写明"简洁不是缺点，冗长不加分"；对长度做归一或设上限；比较时同侧截断对齐；
- 自我偏好：裁判偏爱自己（同家族）模型生成的答案风格。对策：换用异源 judge、多 judge 投票取多数、或至少知道自家 judge 有这个偏，解读分数时打折扣。
其他常见的坑：
- 分数塌缩：rubric 太粗时清一色 7/8 分，没有区分度——细化到逐维度打分（正确性、完整性、格式、安全各一项）再加权；
- 打分漂移：同一 judge 不同批次分数不可比——固定 judge 模型版本和 Prompt，评估都对着基线做相对比较；
- rubric 腔调过软：judge 想当好人，给分松——加"严苛模式"指令和带分数锚点的 few-shot 示例（什么样的答案值 3 分、什么值 8 分）。
校准纪律（能不能信 judge 的分水岭）：定期抽样人工复评，算 judge 与人工的一致率；一致率掉到 80% 以下就修 rubric 或换 judge。judge 只做初筛和规模化，关键决策（发版门禁）必须有人工抽检背书。
面试官可能追问
- pointwise 和 pairwise 怎么选？（pairwise 对偏差更鲁棒、区分度高，但成本翻倍且不能跨对比较；大规模筛查用 pointwise，重点对比用 pairwise + 位置交换）
- 能用被评模型自己当 judge 吗？（不能直接用——自我偏好必然虚高；但可以让它参与"找错"类辅助分析，结论交给独立 judge 复核）
- judge 的输出除了分数还能要什么？（要求输出扣分理由和证据定位，理由可审计、可发现 rubric 漏洞，也方便人工复核）
105. 怎么构建评估集（Eval Set）？业务迭代后评估集怎么跟着演化和去污？
高频·中等
参考答案
构建方法：
- 来源三合一：线上真实日志采样（主力，分布与实际流量对齐）+ 人工构造边界与对抗 case（该拒答的、错误前提的、注入攻击的）+ 历史 bad case 沉淀（最有价值的部分）；
- 规模：起步 100~300 条即可跑通闭环，逐步长到 500~1000+；扩大时要按场景、难度、用户类型分层抽样，而不是无脑随机堆量；
- 结构化存储：每条包含 input（完整上下文）、期望输出（要点式评分点优于唯一标准答案）、场景标签、难度标签、来源与添加日期。标签是后续分层看分的基础——总分不降不代表某个场景没崩。
演化机制（评估集是活资产）：
- 进：每个线上 bad case 修复后必须固化进评估集；新功能上线前预先补该场景的 case；
- 出：业务下线、知识过时的 case 定期淘汰（否则旧题拖累新版本分数）；被淘汰的归档留痕，保证历史分数可追溯；
- 版本化：评估集每次变更打版本号，所有评估报告绑定"代码版本 + Prompt 版本 + 评估集版本"，分数才能跨时间可比。
去污（防"背过题"的虚高）：
- 新模型训练前：训练数据与评估集做精确匹配 + n-gram 重叠（如 13-gram）+ embedding 高相似度三重检查，命中即从训练侧剔除；
- 新评估集入库前：反向检查与已有训练数据的重叠，防评估题泄漏进历史训练语料；
- 蒸馏/合成数据尤其要查——强模型生成时很容易复现公开评测题；
- 定期用"新鲜题"（近期线上新采样、从未参与任何训练）复测，和评估集分数对比，分差大说明有记忆污染。
面试官可能追问
- 评估集被"训过"了怎么办？（换新鲜采样重建，旧集降级为开发调试用，不再作为发版门禁）
- 期望答案允许开放性吗？（允许：存评分点而非唯一答案，judge 按点给分；但格式类、事实类场景要求强一致）
- 怎么防止评估集偏离真实流量？（定期按线上最新分布重采样比对，场景占比偏了就调权重或补采样）
106. 了解 RAGAS 吗？忠实度、答案相关性、上下文精确率 / 召回率分别怎么算？
中频·中等
参考答案
RAGAS 是面向 RAG 的评估框架，核心思路是用 LLM as Judge 做无参考评估（多数指标不需要人工标准答案），把端到端质量拆成可归因到链路环节的四个指标：
- Faithfulness（忠实度）：答案是否忠于检索上下文、有没有编。算法：先用 LLM 把答案分解成一组原子 claim，再逐条判断能否由 context 推出，得分 = 被支持的 claim 数 / 总 claim 数。定位生成层的幻觉；
- Answer Relevancy（答案相关性）：有没有答非所问、跑题注水。算法：让 LLM 从答案反向生成若干个"它像在回答什么问题"，算这些问题与原始问题的 embedding 相似度均值。定位生成层跑题（或检索内容把模型带偏）；
- Context Precision（上下文精确率）：检索回来的内容里，相关的部分有没有排在前面。算法：让 LLM 逐条判断每个检索片段与问题是否相关，再按"相关片段的排名位置"加权（排名越靠前贡献越大），衡量排序质量——灌了一堆无关内容即使全召回，这项也会低；
- Context Recall（上下文召回率）：回答所需的知识有多少被检索覆盖。需要参考答案：把参考答案拆成句，逐句判断能否由 context 支持，得分 = 可归因句占比。定位检索层的漏召回。
怎么用于诊断（这是 RAGAS 的真正价值）：
| 症状 | 归因 | 方向 |
|---|---|---|
| Context Recall 低 | 检索没找到该找的 | 切分、召回、补索引 |
| Context Precision 低 | 找到了但混入噪声、排序差 | rerank、top-k、混合检索权重 |
| Faithfulness 低 | 上下文是对的但答案编了 | Prompt 约束"仅根据资料"、换模型 |
| Answer Relevancy 低 | 答非所问 | query 理解/改写、Prompt |
注意事项：RAGAS 依赖 judge 模型质量，中文场景要验证 judge 的可靠性；分数是相对指标，用于版本间对比和归因，不要当绝对质量分；样本量建议数百条起步，否则 LLM 判断的方差会淹没差异。
面试官可能追问
- 哪个指标必须人工提供参考答案？（Context Recall 需要参考答案，其余三个可无参考运行）
- Faithfulness 高就一定没有错吗？（它只校验"是否忠于上下文"，上下文本身是错的（知识库过期）时检不出来，需要知识库侧的数据质量治理）
- RAGAS 和自建 judge 评估怎么选？（RAGAS 适合快速起量和链路归因；产品特有维度（话术风格、业务规则符合度）仍要自建 rubric 补充）
107. 线上生成内容没有标准答案，质量怎么评估？人工抽检和模型评估怎么配比？
高频·中等
参考答案
分层评估漏斗（按成本递增、覆盖率递减）：
- 规则/统计层（全量、实时）：格式合法率、长度分布、敏感词命中、引用命中率、空答/拒答率——便宜、确定、可告警，但测不出"内容好不好"；
- LLM as Judge 层（抽样、离线/准实时）：按业务 rubric 多维打分（有用性、忠实度、风格符合度、安全），规模化覆盖长尾；成本约为人工的百分之一量级；
- 人工抽检层（小样本、金标准）：抽 judge 打分中的边界样本和随机样本复评，校准 judge 一致率，同时发现 rubric 覆盖不到的新问题模式。
配比建议（经验值）：
- 规则层 100% 全量；
- Judge 层按风险分层抽样：稳定期抽 1%~5%，新版本上线首周提到 10%~20%，高风险场景（医疗、金融、法律）上调；
- 人工复评 judge 样本的 5%~10%，保证 judge 与人工一致率维持在 80% 以上——一致率不达标时先修 rubric，而不是加人工；
- 用户行为信号（点踩、重新生成、编辑、转人工）作为第四层免费的全量反馈，与抽检结果交叉验证。
关键纪律：人工抽检的目标不是"多看几条"，而是校准和发现新模式——人工结果要回流去修 rubric、补 judge 的 few-shot 锚点；judge 的分数要定期与线上业务指标对齐，发现"judge 说好但用户点踩"的系统性错位就是 rubric 出了问题。
面试官可能追问
- 抽样怎么抽才不被流量分布骗？（按场景/用户类型/输出长度分层抽样，另加对低分尾部、新场景的定向超采样）
- judge 评估的延迟成本能接受在线做吗？（离线为主；在线实时 judge 只用于高风险决策点（发布前审核），普通质量监控走异步批处理）
- 用户点踩信号噪声大怎么办？（点踩原因结构化收集、与抽检交叉验证、只看趋势和相对对比，不当绝对质量分）
108. Prompt 或模型升级后怎么做回归测试？怎么防止"改好一处、改坏三处"？
中频·中等
参考答案
核心机制：版本化评估集做门禁 + 分维度记分 + diff 级复盘，让每一次改动都过同一把尺子。
标准流程：
- 建基线：当前线上版本在评估集上跑一遍，总分 + 分场景分 + 分维度分全部落档，作为对照基准；
- 改动过评估集：任何变更——Prompt、模型、检索参数（top-k、切分粒度）、温度——统一触发全量评估集回归，进 CI 自动执行；
- 门禁判定：总体分不降 且 每个场景分跌幅不超过阈值（如 2%）；任何场景跌破阈值即阻断发布；
- diff 级复盘：不只看分数，逐条 diff 出新引入的失败 case（之前对现在错），人工确认每一条是可接受的行为变化还是真退化；
- 灰度收尾：过门禁后小流量灰度，盯在线指标（点踩率、采纳率）做最终确认。
防"改好一处、改坏三处"的具体手段：
- 分维度记分：只看一个总分必然掩盖局部退化——正确性、格式、拒答策略、安全各记一列，场景标签再切一层；
- 敏感场景加权：核心业务场景和高风险场景在总分中加权，普通场景的波动不至于淹没关键退化；
- Prompt 与评估报告绑定：每个 Prompt 版本存档对应的评估报告，可追溯、可回滚、可对比；
- 单变量原则：一次 MR 只改一处（只换模型 or 只改 Prompt），多处混改时退化无法归因；
- bad case 回归保障：历史上每个 bad case 都固化在评估集里，旧病复发会在门禁直接暴露。
面试官可能追问
- 模型输出有随机性，分数波动怎么判？（固定温度/种子能固定的先固定；不能固定的跑多次取均值并给置信区间，差异小于置信区间不轻易下结论）
- 评估集只有几百条，小退化测得出来吗？（对格式类确定性指标几百条够；开放任务的小幅差异本来就不该指望离线测出，交给灰度和在线指标）
- Prompt 改动太频繁，全量回归跑不过来怎么办？（分级回归：日常小改动过核心子集（几十条快筛），发版节点过全量）
109. A/B 测试在 LLM 应用里怎么做？核心指标怎么定？怎么隔离网络效应？
中频·较难
参考答案
和传统 A/B 的差异：LLM 应用输出是随机生成的、质量是多维的、且改动通常"没有严格更优"只有 trade-off，所以指标设计比实验本身更难。
核心指标怎么定：
- 主指标（OEC）必须选业务结果，不能选模型分：问题解决率、答案采纳率、7 日留存、转人工率、点踩率——judge 打分只能做辅助参考，"judge 说新版本好"不等于"用户觉得好"；
- 护栏指标：延迟（TTFT、P95 总时长）、单次会话成本（Token 用量）、安全拒绝率、错误率——主指标涨但护栏崩了照样不能全量；
- 样本量与周期：按主指标的最小可检测效应（MDE）估算——线上噪声大的指标（采纳率 1~2 个百分点的差异）通常需要周级时长和可观流量；实验前先跑 A/A 测试验证分流均匀和指标方差。
LLM 特有的坑：
- 输出随机性：同一用户同一请求两次结果不同，会稀释组间差异，需要按用户聚合而不是按请求统计；
- 同用户体验一致性：按用户分流并固定实验组（不能一会儿 A 一会儿 B），否则污染体验和行为数据；
- 共享状态的交叉污染：多用户共享的知识库、语义缓存、Few-shot 池如果按全局生效，实验组的新行为会"漏"给对照组——缓存和检索配置必须按实验组隔离。
网络效应的隔离：用户之间会互相影响（社交传播、推荐内容、共享协作文档），请求级随机分桶会导致两组互相污染。对策：
- 按用户/账号为单位分流（默认做法），影响通过社交关系扩散时升级为按社区/集群随机（把互相影响的用户整体分到同组）；
- 地理/区域级分桶（区域间影响小的业务）；
- 双侧市场类（供需两端都受影响）对供需两侧同时分组。
流程纪律：离线评估预筛（明显差的方案不进 A/B，浪费流量）→ 小流量灰度看护栏 → 正式实验看主指标 → 显著才全量。实验结论（无论成败）沉淀进团队知识库。
面试官可能追问
- 样本量不足（低流量产品）怎么做实验？（退而求其次用 interleaving 穿插实验（更灵敏）或序贯检验设计；或积累更长时间）
- 新模型成本更低但质量略降，怎么决策？（把成本折算成货币和主指标放一起算净收益，LLM 应用常见"质量降 1% 换成本降 30%"的合理 trade，要业务方拍板）
- 怎么防止团队"只发对自己有利的实验结果"？（实验平台统一登记 hypothesis 和主指标，实验开始后锁定，结束自动出报告）
110. 一个 Bad Case 进来，你的分析和归因流程是什么？怎么判断该改检索、改 Prompt 还是改模型？
必刷·中等
参考答案
核心思路：先固定现场，再沿链路二分定位，最后按"共性还是个例"决定修的层级。
第一步：固定现场（可复现是前提）
- 记录完整上下文：原始 query、检索到的片段（top-k 原文和分数）、完整 Prompt、模型版本、采样参数、时间戳——线上一切要能重放；
- 确认复现：多次重跑看是否稳定复现（随机性 case 和确定性 case 的处理路径不同）。
第二步：分层二分定位（关键动作——看"标准答案"在检索结果里在不在）
- 输入层：query 本身歧义、错别字、超范围请求？→ 属于用户侧问题，考虑 query 改写或拒答策略；
- 检索层：人工判断"回答这个问题需要的知识块"，查它有没有被召回：
- 没召回 → 检索问题。细分：库里没有（补数据/扩索引）→ 有但切分切碎（调 chunk 策略）→ 召回但排在 top-k 外（加 rerank、调混合检索权重）→ embedding 理解不了口语化 query（加 query 改写）；
- 召回了 → 往下走；
- 生成层：正确上下文就摆在眼前，看模型错在哪：
- 答案与上下文矛盾/编造 → 不忠实，先收紧 Prompt（"仅根据以下资料回答，无依据明确说不知道"）、降温度；批量出现才考虑换模型或微调；
- 答非所问、风格不符、格式错 → Prompt 问题，加约束和 few-shot；
- 理解/推理本身不行（给了资料也读不懂）→ 模型能力上限，换更强模型；
- 后处理层：截断、解析、拼接模板把对的改错——最容易被忽略，优先排除。
第三步：个例 vs 共性（决定修的层级）
- 统计同类 case 在评估集/近期日志中的出现率和场景分布：个例（偶发、场景边缘）优先最小成本修复（Prompt 补一条规则、知识库补一条数据）；
- 共性（同场景成批出现）才值得系统性改：调检索参数、重构切分、甚至立项微调——微调永远是最后一个选项，前提是"Prompt 已到上限 + 该模式批量出现 + 有足够数据"。
第四步：闭环
- 修复后该 case 进评估集回归，确认修复且不引入新退化（跑全量回归，见第 108 题）；
- 归因结论落档（什么层、什么根因、怎么修的），积累成团队的归因知识库。
一句话判据：知识缺了改检索，行为不对改 Prompt，能力不行换模型，批量模式才微调。
面试官可能追问
- 检索层怎么快速区分"切分问题"还是"排序问题"？（看 gold chunk 在不在候选池：在池里排不进 top-k 是排序问题，压根不在池里是召回/切分/索引覆盖问题）
- 为什么修好了这个 case 却经常弄坏别的？（没有回归门禁，单点优化牺牲了全局——所以任何修复必须过评估集全量回归）
- 用户报的 Bad Case 和监控发现的 Bad Case 有什么不同？（用户报的偏向"显性错误"，监控（低分、点踩、重试）能抓到"用户不满意但说不出哪错"的隐性退化，两路都要进归因池）