RAG 评估工具

• 指标定义的跨工具差异
• 统一语义层
• 黄金样本的锚定作用

不同工具的同一指标名可能指不同计算逻辑（如 Faithfulness 在 A 工具是逐句断言语义蕴含，在 B 工具是整体相关性），直接横向比较会误导。建立统一语义：1) 在自己内部定义一个"指标字典"，明确每个指标的精确定义、计算方式、输入输出与判定标准，作为唯一真源；2) 为每个指标建立黄金样本（golden set）：人工标注一批"正例/反例"，作为该指标"应该给的分数"的锚定基准；3) 用这些黄金样本验证各工具实现是否与内部语义一致，偏差大的工具要么校准要么弃用；4) 跨工具比较时先做"指标对齐校验"，只比较语义一致的指标。

指标名相同不代表语义相同。统一语义 + 黄金样本是"校准"各工具的口径，保证评估结论可比、可信。

• 检索失败与生成失败的区分
• Judge 归因
• 分阶段评估

RAG 输出质量 = 检索质量 + 生成质量，两者失败要分开归因。防止 Judge 误判：评估时把"给定上下文是否足以回答"作为前置信息注入 Judge。做法：1) 分阶段评估：先单独评估检索质量（上下文是否相关、是否含答案所需信息），再评估生成质量（在给定上下文下，生成是否忠实、是否回答了问题）；2) 给 Judge 提供"检索上下文"与"生成答案"，让 Judge 判断"答案是否忠实于上下文"（Faithfulness）与"上下文是否相关"（Context Relevance）分离；3) 当检索结果不全时，good 生成也会不理想，此时归因于检索失败而非生成失败。用"上下文可回答性"作为中间信号来区分。

检索失败导致"巧妇难为无米之炊"，不是生成问题。分阶段评估 + 让 Judge 同时看到上下文与答案，才能正确归因是检索还是生成失败。

• 轨迹级评估
• 多步失败归因
• Agentic RAG 的评估指标

Agentic RAG 是多步交互（改写查询→检索→评估→再检索→生成），评估要"轨迹级"：记录每一步（查询改写、检索结果、上下文评估、最终答案），对每步单独评估。归因中间失败：1) 改写错误：查询改写后语义偏离原问题，导致检索偏差——对比改写前后查询的相关性；2) 召回缺失：改写正确但检索不到相关文档——检查检索结果的相关性/覆盖率；3) 证据弃用：检索到相关文档但生成时未使用——检查答案是否忠于全部上下文、是否遗漏关键证据。用这些中间信号区分失败发生在哪一步，再针对性优化（改改写 Prompt、调检索、改生成）。

Agentic RAG 的失败是链式的，必须轨迹级拆解。改写、召回、证据使用三个环节分别评估，才能定位并优化具体的失败环节。

• 数据污染类型
• 污染检测方法
• 隔离流程设计

数据污染类型：评测样本与训练/知识库数据重复（模型"见过答案"）、线上日志回流样本与评测集重复、评测题被混入生产知识库（导致检索直接命中）。检测方法：1) 用相似度/哈希对比评测集与生产数据、知识库、日志样本，检测重复或高度相似；2) 对评测样本做"泄漏扫描"（如 n-gram 匹配、嵌入相似度）；3) 监控"评测集内出现异常高分"的样本，疑似污染。隔离流程：评测集与生产数据分库存储、独立版本控制、评测集访问受控、评测样本不进入知识库与训练数据、回流流程去重比对。建立"评测集注册 + 污染扫描 + 隔离访问"的治理机制。

数据污染让评测"虚高"，掩盖真实能力。检测靠相似度扫描，隔离靠物理/逻辑分离 + 回流去重，两者结合才能保证评测可信。

• 引用准确性评估
• 断言-出处对齐
• 引用验证方法

引用准确性评估 = 每条断言（claim）都要能从引用来源中找到支撑。方法：1) 把答案拆解为断言（句子/事实单元）；2) 对每个断言定位其引用的来源文档片段；3) 验证"断言内容是否被该来源支持"（用 Judge 或蕴含判定），同时验证"来源是否被引用且相关内容存在"；4) 检查"无引用断言"（未标注来源的断言）的数量与占比，无引用断言通常是幻觉风险。指标：引用支持率（引用的断言被来源支持的比例）、引用召回率（关键断言是否有引用）、无来源断言率。用结构化输出（断言→引用映射）实现可审计。

引用准确性是"可信度"的核心。要同时检查"断言有出处"（引用召回）和"出处支持断言"（引用支持），两条缺一不可。

• 线上 vs 离线指标
• 指标对齐方法
• 线上监控信号

线上监控的 RAG 信号：引用支持率（用户可见答案的引用是否被支持）、零结果率（检索无结果的比例）、低分率（低置信度/无答案的比例）、用户反馈率。离线评估指标：Faithfulness、Context Precision、Answer Relevance 等。对齐方法：1) 定义"线上指标与离线指标的同构映射"，让同一语义在线上线下都有对应（如离线 Context Precision 对应线上零结果率与检索相关分布）；2) 用同一批样本在线上与离线分别计算，验证趋于一致；3) 线上监控主要用于"发现异常与漂移"，离线评估用于"定位与优化"，两者互补；4) 定期把线上 badcase 回流入离线评估集，保证离线指标趋势与线上一致。

线上监控"发现问题"（如零结果率升高），离线评估"定位原因"（如检索或生成哪步退化）。通过同构映射与 badcase 回流让两者对齐，避免只信一方。

• 困难样本的作用
• 困难样本比例
• 覆盖与代表性平衡

困难样本（拼写错误、模糊/多义问题、跨语言、长尾实体、多跳推理）用于暴露 RAG 在真实噪声下的弱点，应占评估集一定比例（经验上 10%-30%），并单独分层报告，不与正常样本混算。困难样本的作用是"压力测试"：测试查询改写容错、检索鲁棒性、歧义消解、跨语言能力。比例要平衡：过低则漏测真实用户困惑，过高则不代表真实分布。关键是"按风险类别覆盖"（每类困难至少若干样本），并单独看"困难子集通过率"这个指标。

真实用户查询并不规范（拼写错、模糊、多语言）。困难样本是"贴近真实噪声"的探查，单独分层才能解读系统在极端输入下的鲁棒性。

• 工具版本演进
• 官方文档核查
• 指标定义漂移

评估工具（Ragas、DeepEval 等）迭代快，指标定义、默认设置、API、底层 Judge 模型都可能随版本变化：旧教程里的指标名现在可能语义不同、API 已废弃、默认阈值已改。因此必须：1) 以官方文档为准核查当前版本的能力与指标定义；2) 核对所使用指标的确切计算逻辑与版本；3) 检查 deprecation 与 changelog；4) 记录所用工具版本，保证可复现。依赖旧教程会导致用错指标、结果不可比、甚至误判。

评估工具是"活"的，版本差异会改变评估语义。以官方文档为准 + 记录版本，才能保证评估正确与可复现。

• 失败样本归档
• 失败聚类
• 回归用例转化

流程：1) 归档：评估运行时自动把失败样本（含输入、输出、分数、上下文、失败维度）写入失败库，附带元数据；2) 聚类：按失败类型（检索失败/生成失败/格式失败）、主题、嵌入相似度、错误模式自动聚类，形成"失败簇"；3) 去重：对每簇去重，保留代表性样本；4) 转化：把去重后的代表性失败样本打标、补 golden 后，加入回归评测集，形成"可回归"用例；5) 审查：每簇生成失败报告供人工审查，确认失败原因并决定优化方向。这样失败样本从"一次性事件"转化为"可持续的回归资产"。

失败样本是宝贵资产。自动归档 + 聚类把散乱的失败变成可分类、可审查、可回归的结构化资产，驱动持续改进。

• 评估工具分数的局限
• 人工抽样与业务指标的作用
• 多信号验证

评估工具分数是"代理指标"，局限：1) 依赖 Judge/规则，可能带偏差、与真实用户感知脱节；2) 评估集覆盖有限，不代表线上全部分布；3) 分数可能对工具实现细节敏感；4) 无法捕捉长尾/安全/业务特有风险。因此必须配合：人工抽样（对关键样本人工资深评审，验证工具分数是否与真实质量一致，校准工具）与业务指标（线上真实行为：解决率、用户反馈、成本，作为最终真值）。多信号交叉验证：工具分数提示问题，人工确认原因，业务指标验证是否真影响业务。

工具分数是"快速但有偏差"的代理，人工抽样是"准确但贵"的校准，业务指标是"真实但噪"的真值。三者缺一不可，防止被工具分数误导。

• 失败聚类分析
• 失败模式到优化方向的映射
• 归因决策

聚类后按失败模式映射优化方向：1) 若失败集中在"检索不相关/零结果"→ 优化检索（改 embedding、重排序、chunk 策略、查询改写）；2) 若失败集中在"忠实度差/幻觉/未用证据"→ 优化生成（改 Prompt 约束、加引用要求、降低 temperature）；3) 若失败集中在"格式/结构/工具调用"→ 优化 Prompt 与 Schema；4) 若失败集中在特定主题/领域→ 补领域知识库或领域 Prompt；5) 若失败集中在特定长度/复杂查询→ 优化多步推理或改写。用聚类报告（主题、错误类型、来源分布）自动标注"哪类错误最多 → 建议改哪个环节"，形成优化决策辅助。

聚类结果的价值在于"定位优化杠杆"。不同的失败模式对应不同的优化环节（Prompt/检索/模型），把聚类映射到优化方向，评估才真正驱动改进。

• 评估可视化的设计
• 周会与发布评审的用法
• 数据驱动决策

可视化帮助团队理解评估：1) 指标雷达图：展示多维度（忠实度、相关性、安全、延迟）在同一版本上的表现，直观对比版本间增减；2) 错误分布图：按错误类型/主题/业务域展示失败分布，让团队知道"问题集中在哪"；3) 趋势图：展示指标随时间/版本变化，发现漂移。使用场景：团队周会用于"看趋势、分优先级"（哪些指标退化、哪个错误簇优先处理）；发布评审用于"门禁决策"（硬指标是否达标、风险是否可控、变更是否可合入）。用可视化把"评估结论"转化为团队共识与决策依据。

可视化是"评估结论 → 团队决策"的桥梁。雷达图看整体、错误分布看焦点、趋势图看漂移，分别服务于周会排期与发布评审门禁。

• 污染后结论重估
• 基线重建
• 评估治理

处理分几步：1) 定位污染范围：用相似度扫描找出被污染的样本，评估污染对整体分数的贡献（去掉污染样本后分数变化多大）；2) 重估历史结论：对受影响的历史评估，标注"结论可能失真"，对关键结论用"排除污染样本后的干净集"重跑；3) 重建基线：清理污染样本，冻结一份"干净基线集"作为新基准，重新计算基线分数；4) 建立防污染机制：隔离评测集、回流去重、定期扫描、版本控制。历史结论不能直接删除，要"标注失真 + 重算 + 重建基线"。

污染让历史分数虚高，重估要"量化污染影响 + 用干净集重算 + 重建有效基线"。真正重要的是建立防污染机制，防止再犯。

• 各 RAG 指标的不同含义
• 指标组合解读
• 故障模式归因

各指标含义：Faithfulness（答案是否忠于上下文）、Answer Relevance（答案是否贴合问题）、Context Precision（上下文是否全部相关）、Citation Correctness（引用是否准确）。当 Faithfulness 上升而 Context Precision 下降，常见故障模式：1) 检索改写导致上下文更短、更聚焦，模型"自信"地只基于这小段上下文作答，忠实度上升但遗漏了其他相关细节（Context Precision 下降说明检索到的相关上下文中混入不相关或召回变窄）；2) 模型对简洁上下文"过度自信"，生成更凝练但缺失细节的答案，忠实但局部；3) 上下文被压缩/重排后精确度下降但内容更聚焦。结论：单一指标升降无法判定好坏，要联合解读——Faithfulness 上升可能只是"上下文变短好忠实"，而 Context Precision 下降说明检索质量/覆盖退化。

这些指标是"相关但不同"的信号，组合解读才能发现真正的故障。Faithfulness 上升 + Context Precision 下降，通常指向"检索变窄/覆盖下降"而非生成变好。

• 在线反馈回归定位
• trace 采样与流量切片
• evaluator 时效性

定位分三维度：1) trace 采样：从线上 trace 中抽样 thumbs-down 样本，分析其输入分布、检索结果、Prompt、模型版本，看是否与离线样本不同（线上流量的新问题没进离线集）；2) 流量切片：把流量按用户群、地域、业务、模型版本、时间切片，看 thumbs-down 是否集中在特定切片（如新用户、新流量、新模型），定位是流量结构变化还是特定切片退化；3) evaluator 时效性：离线评估集可能过时，未覆盖线上新问题，或 Judge 模型已过期、评分标准漂移。修正：把线上新 badcase 回流入离线集，更新 judge，验证离线集是否还代表当前线上分布。

在线反馈变差但离线不变，通常因为"离线集与线上分布脱节"或"问题集中在特定流量切片"。从 trace 找样本、切片定位、评估时效性校准，三管齐下定位根因。

• golden dataset 版本化
• embedding 升级迁移
• 基准可比性

版本化 golden dataset 绑定 commit：保证评估集内容可追溯、可复现、可审计，每次评估结果能与"哪个版本的数据集"对应，避免数据集悄悄变化导致历史不可比。embedding 升级迁移：底层 embedding 变化会改变检索结果，从而改变评估：1) 重新嵌入（re-embed）所有文档与查询到新 embedding；2) 对齐验证：在新 embedding 下重跑关键样本，确认检索质量；3) 人工 spot-check 重标：对检索结果变化的样本人工复核，更新 golden 标注；4) 保留旧版本作为可比基线：旧 embedding + 旧 golden 保留，用于对比新旧效果（A/B 对比），新版本另立一套基线。这样既迁移又保持可比。

golden dataset 版本化 + commit 绑定是评估可复现的根基。embedding 升级是"破坏性变更"，迁移要 re-embed + 重标 + 保留旧基线对比，量化升级影响。

• 影子流量原理
• 输入可比与无副作用
• 候选版本评估

影子流量：把真实流量同时发送给候选版本（影子），但影子只记录不返回给用户，保证输入可比（同一份真实输入同时跑线上与候选）。无副作用保证：影子请求必须"只读"——不执行有副作用的工具调用、不写库、不真正执行业务动作，只生成回答用于对比；有副作用的步骤要 mock 或跳过。评估：对比影子与线上对同一输入的输出质量（用 Judge/人工评分），并分别测量延迟（影子请求单独计时，不阻塞线上）。影子流量能无风险评估候选版本，但要注意成本与"只读"约束。

影子流量的价值是"真实输入 + 无副作用 + 平行对比"。输入可比来自同一份真实流量，无副作用来自"只读运行"，评估用质量对比 + 延迟测量。

• 硬门槛指标的选取
• 阻断 vs 非阻断
• 发布门禁设计

硬门槛（不达标即阻止发布）：1) 安全类：有害内容拦截率、注入拦截率、敏感信息泄露率、合规通过率——安全红线必须阻断；2) 格式类：输出合法率（JSON/Schema 解析通过率）、工具调用参数合法率——格式错误导致下游崩溃必须阻断；3) 任务成功类：任务成功率、关键业务路径成功率——主功能不达标必须阻断；4) 延迟类：P95 延迟、TTFT 超时率、超时率——性能不可用必须阻断。这些是"不可妥协"的底线；软指标（语气、详略）作为非阻断持续优化。硬门槛设阈值并纳入发布 pipeline，任一不达标即 block。

硬门槛是"发布底线"，覆盖安全、格式、任务成功、延迟四类硬性约束。它们是"不能妥协"的，不达标就不允许上线，软指标另行优化。

• 人工抽检的必要性
• 风险分层采样
• 采样设计

关键业务仍需人工抽检，因为自动化评估（Judge/规则）可能带偏差、漏掉长尾与安全风险、无法捕捉业务特有的复杂语义。人工抽检提供"高质量真值"来校准与覆盖。风险分层采样：按风险把样本分层（高风险/中风险/低风险），高风险样本全量或高比例抽检，低风险样本低比例抽检，而不是均匀随机。分层依据：业务风险（医疗/金融/安全相关）、样本复杂度、错误概率、用户价值。这样把有限的人工预算集中在"高影响、高风险"样本上，比均匀随机更有效。

人工抽检的价值是"真值校准 + 风险覆盖"，均匀随机浪费预算在低风险样本。风险分层采样让人工预算聚焦高风险，提升性价比。

• CUPED 原理
• 协变量调整
• 流量结构偏差修正

灰度对比时若新旧用户群体协变量分布不一致（如新用户占比不同、活跃度不同），直接对比会混淆。CUPED（Controlled-experiment Using Pre-experiment Data）用"实验前协变量"来校正实验组效应：先用协变量（如实验前指标、用户特征）对结果做回归，再用残差估计处理效应，从而剥离协变量差异带来的偏倚，降低方差、提高显著性。实现：在实验前采样每个用户的历史表现作为协变量，实验后计算"调整后的指标 = 观测指标 - 协变量回归系数 × 协变量偏差"，再比较两组调整指标。这样即使流量结构不一致，也能得到更公平的对比。

灰度流量结构不一致会混淆"真实效果"与"群体差异"。CUPED 用实验前协变量做回归校正，消除群体差异、降低方差，提高对比可信度。

• 门禁硬指标构成
• 各指标的门禁阈值
• 门禁 pipeline

上线门禁硬指标：1) 任务成功率：关键任务达成率高于阈值（如 >90%），不达标阻断；2) P95 延迟：在阈值内（如 <2s），超时影响可用性阻断；3) 引用支持率：RAG 场景断言被来源支持的比例（如 >95%），保证可信度；4) 安全分类通过率：安全/合规分类通过率（如 >99%），防止有害内容上线。这些指标在灰度/发布 pipeline 中自动计算，任一不达标即 block 发布，并给出失败归因。门禁区分"硬门槛"（上述）与"软指标"（语气等，仅预警）。

门禁是"发布红线"，用硬指标把质量、性能、可信、安全四条底线自动化。任务成功率、P95 延迟、引用支持率、安全通过率是典型四类。

• 用户反馈降噪
• 反馈与评估对齐
• 偏好 vs 正确性

用户反馈降噪：过滤 spam/机器人、异常行为、重复反馈；对点踩看是否伴随"编辑/二次追问"（强信号）；对反馈做"来源校验"（是否真实用户、是否情绪化）。与评估指标对齐：把降噪后的反馈与离线评估指标关联，验证"用户点踩的样本"在评估指标上是否分数低（对齐验证），并回流入评估集。避免"多数人偏好不等于正确"：区分"偏好"与"正确性"——用户可能偏好简洁但简洁包含错误，或偏好迎合但迎合是错的。用权威人工标注/golden 判断"正确性"，用户反馈只作"体验信号"，两者结合而非完全采信用户偏好。

用户反馈是"体验信号"而非"正确性真值"。降噪 + 与评估对齐 + 用权威标注判断正确性，防止"多数人偏好"掩盖事实错误。

• 流量结构校正
• 质量/成本对比
• 分层对比方法

灰度期间若新旧用户群、流量结构不一致，直接对比质量与成本会偏差。校正方法：1) 分层对比：按用户画像/流量类型分层，在每层内对比新旧版本，避免"整体差异"混淆；2) 协变量调整（CUPED）：用实验前协变量校正，剥离群体差异；3) 标准化/加权：按统一流量结构加权后再比较，消除结构差异；4) 同质对比：只对比"同一用户/同一会话"的在线与影子结果，保证输入可比；5) 成本对比同理：按请求类型/Token 分布归一化后再比较每请求成本。目的是让"质量与成本差异"反映"版本差异"而非"群体差异"。

灰度对比的难点是"流量结构差异"伪装成"版本差异"。分层、协变量调整、标准化、影子同质对比都是校正手段，保证公平对比。

• 回流样本治理
• 噪声过滤
• 标签可信度

回流流程：投诉、编辑、人工接管样本先采集，然后"治理"而非直接当标签：1) 过滤噪声：去掉 spam、误操作、无意义反馈、情绪化非真实反馈；2) 去重与聚类：把相似反馈归簇，避免重复加权；3) 人工复核：对聚类样本人工确认"是否确为问题、正确标签是什么"，再用复核后的样本作为标签；4) 分信号强度：人工接管、明确编辑是强信号，投诉需验证，点赞是弱信号。只有经过复核的样本才作为 golden 回流入评估集，避免把噪声当真相。

噪声不能直接当标签。回流必须"采集 → 过滤 → 聚类 → 人工复核 → 才作为标签"，否则垃圾进垃圾出，污染评估集。

• 正向指标的局限
• 反向指标的作用
• 护栏指标设计

正向指标（如满意度、任务完成率）可能被优化而掩盖真实问题：模型可能更会"迎合"用户、更冗长、更表面正确，导致正向指标好看但真实体验变差。反向指标（guardrail）：用户主动取消会话、客服投诉、用户编辑纠错、负面情绪、成本飙升、延迟恶化——这些"越少越好"的指标能暴露被正向指标掩盖的问题。设置反向指标：作为护栏持续监控，若主指标变好但反向指标恶化，说明"变好"可能是假象或掩盖了代价。反向指标与正向指标联合判断，才能确认真实改善。

"看上去变好"可能是正向指标被优化而代价被掩盖。反向指标（取消、投诉、编辑、成本、延迟）是护栏，防止单看正向指标误判。

• 影子流量对比指标
• 质量指标的选择
• 影子对比评估

影子流量对比应使用：1) 任务成功率：判断候选版本是否达成用户任务（用 Judge/规则）；2) 引用准确率：RAG 场景断言是否有准确引用；3) 用户满意度代理：用 Judge/人工对候选回答的满意度打分（因为影子不返回给用户，用户不会真实反馈，用自动/人工评分替代）；4) 辅助指标：忠实度、相关性、延迟、成本。因为影子不面向真实用户，满意度需用 Judge 或人工抽样评估。对比"候选 vs 线上"在同一输入上的指标差，判断候选是否更优。

影子流量不接触真实用户，满意度用 Judge/人工代理。任务成功率、引用准确率、满意度代理指标共同评估候选版本质量。

• 流量切换粒度
• 各粒度的适用场景
• 权衡与一致性

三种流量切换粒度：1) 按用户（user-based）：同一用户始终进同一版本，适合需要"会话一致性/用户体验一致"的场景（如对话类），避免用户来回切换体验断裂；2) 按请求（request-based）：每个请求独立路由，适合"无状态、可混流"的场景（如纯检索、批量），流量切换最灵活、可快速放量，但可能同一用户不同请求体验不同；3) 按租户（tenant-based）：按业务租户整体切换，适合"多租户隔离、租户级 SLA/合规"的场景（如企业版），不同租户可分批灰度。选择取决于"状态一致性需求 + 隔离需求 + 放量灵活性"。

流量粒度是"一致性 vs 灵活性"的权衡。对话类要按用户保一致，批量无状态可按请求，多租户隔离按租户。粒度决定灰度的可控性与副作用。

• 长任务验证难点
• 对照实验设计
• 长任务评估

长任务灰度验证难点：1) 任务时长长、多步、有副作用，失败难以快速暴露；2) 结果评估复杂（代码是否可编译/测试通过、调研是否完整），无法用单一答案分数；3) 副作用（写代码、发消息）不能轻易在灰度中执行；4) 成功率低导致样本量需求大、实验周期长。对照实验设计：1) 用"影子 + 离线评估"先在无副作用环境评估长任务质量；2) 用"任务级指标"（完成率、正确性、效率）而非短对话指标；3) 用"可控子任务"先验证（如先测单步工具调用）；4) 用真实任务但 mock 副作用（只读/沙箱）；5) 用长周期 A/B + 人工/自动化对完整任务结果评分。降低难度：先验证组件、再验证端到端。

长任务验证难在"结果复杂 + 副作用 + 周期长"。用影子/沙箱防副作用、任务级指标评估、组件先验、长周期对照，是长任务灰度验证的关键。

• 接管率归因
• 分类定位
• 端到端分析

用户接管率（用户从 AI 转人工客服/自助操作）上升，归因需分层分析：1) 工具/能力问题：AI 无法完成任务（缺数据、工具不好用、检索失败）→ 看接管会话中"任务是否超出 AI 能力/检索失败"；2) Prompt 问题：AI 有能力但回答不清晰、误导、不解决问题 → 看接管会话的"回答质量/是否答非所问"；3) UI 问题：用户没找到 AI 入口、操作繁琐、被引导到人工 → 看接管前的"用户行为路径与 UI 交互"。归因方法：对接管轨迹做 trace 分析，结合"会话内容 + 用户操作 + 前序 UI 路径"，用聚类与人工复核定位主导因素，再针对性优化（增强工具、改 Prompt、改 UI）。

接管率是"体验失败"的结果，但根因可能是工具、Prompt 或 UI。用轨迹分析 + 会话内容 + 用户路径分层归因，才能找准优化点。

• eval gate 阈值设定
• flaky 评估处理
• 重跑与统计阈值

eval gate 阈值设定：基于"基线分数 + 可接受下降容差"设定，如"主指标相对基线下降不超过 X%（如 2%）即阻断"，且设置"绝对下限"（不容低于某分）。放行需达标，下降超阈值阻断。flaky 处理：1) 重跑策略：失败时自动重跑 N 次，仅当多次均失败才阻断（re-run-on-fail），过滤单次随机波动；2) 统计阈值：用"置信区间/统计显著性"判断分数下降是否显著，而非单次差异；3) 用"多轮评估取稳健统计量"（如中位数、多次均值）降低单次噪声；4) 区分"确定性回归"与"随机波动"：对大的、稳定的下降才阻断，小波动放行。这样既不放过真实回归，又不因 flaky 阻塞合法 PR。

eval gate 的难点是"阈值适中、抗 flaky"。用"相对基线容差 + 绝对下限 + 重跑 + 统计显著性"组合，既守住回归又不误伤合法合并。

• 粘性路由
• 版本快照
• 版本过渡处理

保证版本一致性：1) 粘性路由（sticky routing）：把用户绑定到固定版本，同一用户跨会话始终命中同一模型版本，亲身体验一致；2) 版本快照：用户会话开始时记录其命中的版本快照，后续请求沿用该版本，避免中途切换导致不一致。版本过渡期命中旧版本的用户：1) 允许旧版本继续服务到会话结束（平滑过渡），或设置"强制升级窗口"后自动迁移；2) 对旧版本用户做补偿（如体验引导、说明）；3) 用"版本过渡计划"：先让新版本接收新用户，旧用户逐步迁移，并监控迁移后的反馈。核心是"一致性优先，过渡平滑"。

多模型并存时，同一用户跨会话若被随机切换版本会体验断裂。粘性路由 + 版本快照保一致，过渡期用"平滑迁移 + 监控反馈"处理旧版本用户。

• 副作用补偿
• 回滚后的补偿策略
• 幂等与撤销

回滚后已执行的副作用不能"自动撤销"，需补偿策略：1) 预判副作用：对有副作用工具（写库、发消息、下单）在调用前记录日志与幂等键，回滚后能定位"哪些副作用已执行"；2) 补偿动作：对可逆操作执行反向补偿（如删除写入、回滚事务、发送更正消息）；对不可逆操作（已发出的消息）执行"更正/道歉"或人工介入；3) 幂等设计：副作用调用带幂等键，重试不重复执行；4) 补偿队列：把补偿动作投递到队列异步执行，保证最终一致；5) 人工审批：高风险副作用由人工确认补偿。回滚的语义是"停止新副作用 + 补偿已执行副作用"。

回滚无法"撤销已发生的事"，只能"停止 + 补偿"。通过幂等键定位副作用、补偿队列执行反向动作、人工介入不可逆操作，实现安全的回滚补偿。

• 路由规则灰度
• 效果隔离
• 防频繁切换

粘性路由规则本身的灰度：把"路由规则变更"当作版本，先灰度到小比例用户，验证后再放量；规则变更与模型变更分开评估（效果隔离），避免混淆。防止同一用户频繁切换：1) 粘性绑定：用户绑定版本后，除非规则明确变更，否则不切换；2) 切换阈值：只有"当前版本明显劣化"才切换，避免微小波动就切换；3) 切换冷却：设定同用户的最短切换间隔（冷却期），防止抖动；4) 会话内一致性：同一会话内绝不切换版本；5) 路由规则变更时，对新用户生效新规则，旧用户用"过渡窗口"平滑迁移。效果隔离用"路由规则版本 + 一对一对照"评估。

路由规则切换本身若不稳，会频繁切换破坏体验。需要粘性绑定、切换阈值、冷却期、会话内一致，并让规则变更灰度化、效果隔离。

• Ragas 各指标含义
• 指标定位问题
• 指标组合使用

Ragas 四个指标定位不同：1) Faithfulness（忠实度）：答案是否忠于检索上下文，是否幻觉/编造——定位"生成幻觉"；2) Answer Relevancy（答案相关性）：答案是否贴合问题，是否答非所问——定位"相关性"；3) Context Precision（上下文精确度）：检索到的上下文是否相关、是否混入噪声——定位"检索噪声"；4) Context Recall（上下文召回率）：检索是否涵盖所有需要的信息，是否遗漏关键文档——定位"检索遗漏"。组合：Recall 高但 Precision 低说明检索粗（召回全但噪声多），Precision 高但 Recall 低说明检索窄（精确但遗漏），Faithfulness 低说明生成幻觉。

四个指标分别覆盖"检索精确、检索召回、生成忠实、答案相关"四个环节。联合解读才能定位是检索还是生成问题。

• TruLens 指标与 trace 关联
• 可观测性集成
• RAG 运行追踪

TruLens 的 groundedness（接地性/忠实度）与 context relevance（上下文相关性）评估 RAG 质量，OpenTelemetry trace 记录一次 RAG 运行的完整链路（检索、Prompt 组装、模型调用、生成）。关联方式：1) 用同一 trace ID 把评估结果与 trace 绑定：评估时记录 trace ID，评估分数与 trace 关联存储；2) trace 中记录评估所需的输入（question、context、answer），评估时从 trace 提取；3) 在 trace 上附加评估 span（groundedness/context relevance 打分结果），实现"一次运行 + 质量评估"一体化；4) 用 OpenInference 语义约定记录检索与 LLM 调用，TruLens 读取这些 span 计算指标。关联后，Trace 不仅看"发生了什么"，还能看"质量如何"。

评估与可观测性结合：trace 记录"发生了什么"，评估指标标注"质量如何"，用 trace ID 与评估 span 关联，实现可观测 + 可评估一体化。

• DeepEval CI 集成
• 指标类型
• Judge 波动控制

DeepEval 以 pytest 方式集成：把评估写成 pytest 用例，用 assert 断言指标是否达阈值（如 assert_metric threshold），CI 中运行 pytest 即可作为 gate。G-Eval 是 LLM 打分（带 rubric 的 Judge 评分）、DAG 是判别式问题（binary 判定）、QAG 是问答生成评估。控制 Judge 波动：1) 固定温度（低温度）与模型版本；2) 设置阈值容差（而非精确分）；3) 重跑策略（re-run-on-fail，多次失败才阻断）；4) 用统计阈值判断显著下降；5) 对 G-Eval 这类非确定性指标用多轮取均值或中位数；6) 用 guardrail metric（如结构合法、安全）兜底，避免只依赖 Judge 分数。这样既进 CI 又不被波动阻塞。

DeepEval 的 pytest 集成让评估进入 CI 门禁。G-Eval 等非确定性指标需用温度固定、阈值容差、重跑、统计阈值控制波动。

• 指标联合解读
• 单一指标局限
• 生产监控

联合解读：一组指标形成"检索-生成"链条诊断。如 Recall 高 + Precision 低 → 检索召回全但噪声多（检索不精）；Recall 低 + Precision 高 → 检索窄但精确（自欺）；Faithfulness 低 → 生成幻觉（不忠于上下文）；Relevancy 低 → 答非所问。单一指标不可信的原因：1) 单一指标高分可能掩盖其他环节退化（如 Faithfulness 高但 Recall 低，说明"忠实但没召回到关键信息"，答案仍不完整）；2) 指标间有耦合，只看一个无法定位；3) 单一指标可能被 Judge 偏差/工具实现对特定维度敏感。生产中用"指标组合 + 趋势 + 与线上反馈对齐"综合判断，而非单指标。

RAG 指标构成"检索 vs 生成"的完整体检。单一指标会掩盖其他环节问题，联合解读才能定位故障环节并决定优化方向。

• G-Eval/DAG/QAG 适用任务
• 与人工评分相关性验证
• 指标有效性

G-Eval（生成式分步评估）：适合开放、主观质量评估（总结、生成质量），用 LLM 按 rubric 打分；DAG（判别式）：适合二分类/判定任务（是否相关、是否含幻觉、是否是垃圾），用 LLM 做 yes/no；QAG（问答生成）：适合从上下文生成问答用于评估数据集，或用其验证问答质量。与人工评分相关性验证：1) 用一批人工标注的 golden 样本，计算自动指标与人工分数的一致性（Spearman 相关、Kappa、AUC）；2) 相关性越高说明指标越能代表人工判断；3) 对相关性低的指标做校准或换用更适合的指标；4) 定期重验（人工与自动一致性会随数据/模型漂移）。验证后才知道该指标是否可信。

不同指标适合不同任务（G-Eval 主观评分、DAG 判定、QAG 问答）。有效性验证靠与人工评分的相关性，相关性低则指标不可信。

• Phoenix 与 OpenInference
• 可观测性集成
• bad case 探索

OpenInference 是基于 OpenTelemetry 的 GenAI 可观测性标准/语义约定，定义 LLM、检索、Agent 等 span 的语义（注入、参数、输出）；Phoenix Evals 是构建在 OpenInference 之上的评估工具，读取 OpenInference trace 进行 Embedding 可视化、聚类、评估与 bad case 探索。关系：OpenInference 提供"数据规范"，Phoenix 消费这些数据做评估。适合在 notebook 中探索 bad case 的场景：分析阶段、需要交互式可视化聚类、需要快速试错、评估集规模中等、需要人机协同深度分析检索失败/幻觉模式。notebook 适合探索，不适合生产自动化（生产用 pipeline）。

OpenInference 是标准、Phoenix 是消费该标准的评估工具。notebook 适合交互式 bad case 探索（聚类、可视化、试错），生产自动化另行设计。

• Phoenix 与 Ragas 定位差异
• 可视化与聚类能力
• bad case 探索

Phoenix 相比纯 Ragas 的优势在于"可观测性 + 探索"：1) Embedding 可视化：Phoenix 内置 UMAP/PCA 降维可视化，可直观看到检索结果/文档向量的分布，发现"相似但不相关"的聚类；2) 聚类分析：自动把 Embedding 相近的样本聚类，发现失败模式（如某类主题集中失败）；3) bad case 探索：提供交互式 UI 查看 trace、聚类、逐样本分析，支持人机协同找根因；4) 与 OpenInference 集成：可关联完整 trace。Ragas 更偏"指标计算"（给定数据集算指标），Phoenix 更偏"可视化 + 探索 + 可观测"。生产上两者可互补：Ragas 算指标，Phoenix 探索解释。

Ragas 是"指标计算器"，Phoenix 是"可观测探索平台"。Phoenix 在可视化、聚类、bad case 探索上更强，适合找根因；Ragas 强在标准指标。

• 工具升级指标漂移
• 历史可比性
• 双轨与桥接

工具升级导致指标定义变化、数值漂移，历史分数不可直接比较。保持可比：1) 双轨运行：新旧工具版本并行跑同一批样本，量化差异，建立"桥接映射"关联新旧分数；2) 版本标注：所有历史分数标注所用工具版本，跨版本比较时先做映射；3) golden 样本锚定：用固定 golden 集在新旧版本上跑，确认漂移方向与幅度，校准阈值；4) 用相对排名/相对比较而非绝对分数作为跨版本可比信号；5) 升级时同步重算基线并重新设定门槛。核心是"评估版本与分数绑定，跨版本用桥接/黄金校准"。

工具版本升级是"评估尺度变化"，会造成虚假涨跌。双轨桥接、版本标注、golden 锚定、相对比较，保证历史结论跨版本可比。

• 评估运行成本
• CI 预算管理
• 成本优化

评估的 Judge 调用与向量检索都消耗 Token/计算资源，需纳入 CI 预算管理：1) 成本预估：估算每次评估的 Judge 调用数 × 每调用 Token 成本 + 向量检索成本，作为基线预算；2) 分级预算：全量评估（贵）留到发布前，日常 CI 用"抽样评估 + 轻量 Judge"控制成本；3) 缓存与复用：评估结果缓存（相同输入不重复评估）、样本复用，降低重复费用；4) 效率优化：用快模型做粗筛、慢模型做精排，控制 Judge 使用量；5) 预算监控：CI 流水线记录评估成本，超预算告警，防止测试成本失控。评估成本是"质量的必要投入"，但需显式预算与优化。

评估不是免费的，Judge 调用与检索都有成本。分级预算、缓存复用、快慢模型分层、成本监控，保证质量验证的同时控制 CI 成本。

• 指标解释文档
• 指标定义清晰化
• 团队共识

指标解释文档应让团队"理解指标究竟是什么、怎么算、何时用、怎么解读"。以 Ragas Faithfulness 为例：定义（答案是否忠于检索上下文，逐句判断是否被来源支持）、计算方式（LLM 判断每个断言是否可被上下文支持）、范围（0-1，越高越忠实）、适用场景（生成质量、幻觉检测）、局限（依赖 Judge、对上下文敏感）、解读（低分 = 生成幻觉/未用证据）。每个指标都应有：定义、计算、输入输出、量纲、阈值参考、常见误区、与相关指标的区别。文档作为团队共识，避免"指标名人人理解不同"。

指标解释文档是"评估语义的共享契约"。清晰定义 + 计算方式 + 解读 + 局限，让团队对指标有一致理解，评估结论才可信。

• G-Eval 非确定性
• gate 设计
• 防 flaky 与防漏检

G-Eval 非确定性导致 gate 难设计。策略：1) 固定 Judge 温度与版本，降低随机性；2) re-run-on-fail：失败自动重跑 N 次，仅多次均失败才阻断，过滤单次波动；3) 统计阈值：用"平均分或中位数 + 置信区间"判断显著下降，而非单次绝对分；4) guardrail metric 兜底：除 G-Eval 分数外，加确定性指标（结构合法、安全、工具参数合法）作为硬门槛，防止纯 Judge 分数被随机性掩盖；5) 阈值容差：设下降容差，小幅波动放行，大幅下降阻断；6) 分级：G-Eval 作预警，确定性强指标作阻断。这样既过滤 flaky 又抓住真实回归。

G-Eval 的 flaky 需"重跑 + 统计阈值 + 确定性兜底"组合。重跑滤单次波动、统计阈值判显著、guardrail 兜底防随机性掩盖，兼顾防漏检与防阻塞。

• 变更发布流程
• 渐进式发布
• 自动回滚

变更发布走"漏斗式"渐进流程：1) 离线门禁：先在离线评测集上跑，硬指标（质量、安全、格式）达标才进入下一步；2) Canary：小比例灰度（如 1%-5% 用户），监控关键指标与报错，无异常再放量；3) A/B：对候选与基线做严谨对比（显著性、护栏指标），确认候选更优；4) 逐步放量：按 10%→25%→50%→100% 逐步扩大，每步监控；5) 自动回滚：设护栏指标（错误率、延迟、用户负反馈、安全），任一触发即自动回滚到上一版本，并记录回滚原因。每步都有"继续/回退"决策，保证变更安全可控。

变更发布是"渐进 + 监控 + 门禁"的漏斗。离线门禁把关、Canary/A/B 验证、逐步放量控制风险、自动回滚兜底，是安全发布的标准流程。

• 影子流量隔离
• 无副作用保证
• 质量对比

影子流量保证不影响线上：1) 影子请求返回结果丢弃/不返回给用户，线上响应仍来自生产版本；2) 影子请求"只读"，不执行有副作用动作（不写库、不发消息、不产生真实业务影响），副作用步骤 mock 或跳过；3) 影子独立于生产链路，故障不影响线上。可对比输出质量：同一输入同时发给线上与影子，比对两个响应的质量差异（Judge/人工评分、任务成功率、引用准确率），并分别测延迟。影子流量提供"真实输入 + 无副作用 + 平行对比"，是评估候选版本的安全方式。

影子流量核心是"双轨：线上真实响应 + 影子只读评估"。隔离副作用保线上稳定，平行对比供质量评估。

• Canary 用户群选择
• 选择策略权衡
• 灰度代表性

Canary 用户群选择策略：1) 随机：按随机比例抽取用户，代表性最好、无偏，但可能影响任意用户；2) 按地域：先在某地域灰度，适合"地域性合规/监管/时区"需求或"故障影响局部化"，便于隔离；3) 按租户：先让部分租户（如测试租户、小租户）灰度，适合"多租户隔离、租户级 SLA"场景，风险可控。选择权衡：随机偏"代表性"，地域偏"隔离与合规"，租户偏"隔离与商务"。通常选"代表性强 + 风险可控"的组合，如先小比例随机 + 特定地域/租户试点，并保证 Canary 用户群能反映真实分布。

Canary 用户群要"代表实际流量 + 风险可控"。随机最无偏，地域/租户便于隔离，实际常组合使用，并监控 Canary 群指标。

• 护栏指标定义
• 护栏指标选取
• 防误判

护栏指标（guardrail metrics）是"在 A/B 中必须同时监控、不能因主指标变好而恶化"的次要指标，防止"主指标提升但整体变差"。例如：A/B 提升"点击率"但"用户流失率"上升、成本飙升、延迟恶化、用户负反馈增加——这些就是护栏。选取：与主指标相关的、能反映代价与风险的指标（成本、延迟、取消率、投诉、安全、其他业务指标）。使用：主指标显著提升时，检查护栏指标是否显著恶化；若护栏恶化，则 A/B 结论不可采信，需权衡。护栏指标让"看主指标"升级为"看整体健康度"。

护栏指标是"代价与风险的探测器"。没有护栏，A/B 可能因"主指标提升但代价巨大"而误判。主指标与护栏联合判断才稳健。

• 显著性检验方法
• 多重比较校正
• 统计检验选型

显著性检验方法：1) t-test：适用于"近似正态、样本量足够"的均值比较，简单常用，但依赖正态假设；2) bootstrap：对分布无假设，通过重采样估计置信区间，适合"非正态、小样本、不规则分布"（如延迟、成本这类偏态指标），更稳健；3) BH 校正（Benjamini-Hochberg）：当同时检验多个指标时，控制 FDR（错误发现率），防多重比较导致的假阳性。实践中：正态指标用 t-test，偏态/非正态用 bootstrap，多指标同时检验用 BH 校正控制整体假阳性率。结合"样本量充足 + 显著性达标 + 护栏未恶化"才下结论。

不同指标形态选不同检验：t-test 适合正态均值、bootstrap 适合非正态、BH 用于多指标假阳性控制。组合使用避免显著性误判。

• 外部平台指标校准
• 与人工标注对齐
• 校准流程

外部平台（Patronus、Galileo）的幻觉/RAG 指标是通用模型，需与自有人工标注校准：1) 建立自有 golden 样本：人工标注一批"幻觉/正确"及 RAG 质量样本；2) 对比：在 golden 样本上跑平台指标，计算与人工标注的一致性（Kappa、AUC、准确率）；3) 校准：若平台指标系统性偏差（阈值不当、与业务定义不符），调整阈值或做映射；4) 适用性评估：平台指标适用通用场景，但业务特有定义（如"什么算幻觉"）需人工校准；5) 定期复校：平台指标模型升级后重新校准。校准后平台指标才能作为"贴近业务人工判断"的代理。

外部平台指标是"通用代理"，必须用自有人工标注校准，确认其与业务定义一致。校准通过才能替代或辅助人工评估。

• 工具差异维度
• 选型考量
• 指标/Judge/可导出性

选型需评估三方面：1) 指标定义：各工具指标计算逻辑不同（如 Faithfulness 定义），需确认是否匹配业务语义；2) Judge 模型：各工具底层 Judge 不同（可指定、可维护、是否可替换），影响成本与偏差可控性，是否能自配 Judge 模型决定可定制性；3) 可导出性：指标结果、trace、评估数据能否导出（API/导出字段），影响数据主权、与自建系统集成、可复现性。选型：指标匹配业务 + Judge 可控可替换 + 可导出到自有平台，三者兼顾。若需深度定制与数据主权，选可导出、可自定义 Judge 的工具；若快速起步，选开箱即用平台。

工具选型看"指标是否匹配、Judge 是否可控、数据是否可导出"。三者决定工具能否真正融入业务、保持数据主权与可复现。

• 各平台 CI 集成差异
• evaluator agreement suite
• judge 漂移检测

三平台集成差异：Braintrust 以 Eval() 为中心（显式评估调用）、LangSmith 强绑 dataset+experiment（dataset 与实验一对一对齐）、DeepEval 走 pytest（断言式）。设计 evaluator agreement suite：1) 建立一套"黄金 judge 评估样本"（固定输入 + 期望分数类别）；2) 定期用该套样本跑各平台评估，记录分数分布；3) 监控"同一套样本的分数漂移"——若某平台分数显著变化（而输入未变），说明平台默认 judge 被静默升级/行为漂移；4) 用"双平台 agreement"：同一任务用两平台评估，观察一致性是否下降，下降即提示某一方 judge 漂移；5) 漂移检出后：冻结评估版本、重校准、或换成可控的自家 judge。agreement suite 是"评估器自身的监控"，防止评估器悄悄变化污染结论。

平台静默升级 judge 会污染评估结论。agreement suite 用固定样本 + 多平台一致性 + 分数漂移监控，及时检测评估器变化，保证评估尺度稳定。