LLM 评估框架与 CI/CD 集成

• 各框架的定位差异
• 在线/离线评估、数据集管理、协作
• 按团队规模与数据敏感度选型

核心差异：Braintrust 偏商业平台，强调数据集管理、评分器编排与团队协作；LangSmith 是 LangChain 生态，trace→dataset→experiment 闭环强，适合链式应用；DeepEval 开源库，提供 G-Eval、DAG 等指标与 pytest 集成，适合工程化断言；Promptfoo 开源 YAML 驱动，与 CI 集成好，适合 prompt 回归；Arize Phoenix 开源，侧重 trace 与在线/离线观测。选型：数据敏感/自部署优先开源（DeepEval、Promptfoo、Phoenix）；团队大需协作与在线反馈用商业平台（Braintrust、LangSmith）；深度绑定 LangChain 用 LangSmith；工程化 CI 断言用 Promptfoo/DeepEval。按团队规模、数据敏感度与生态集成综合取舍。

框架差异在"开源/商业、生态绑定、在线/离线、协作能力"；选型要匹配数据合规、团队协作与现有技术栈，而非跟风。

• 变更触发评估
• 质量门禁（通过率/回归阈值）
• 自动阻断与人工审批分级

设计：Prompt 变更提交即触发 CI 运行对应评估集（冒烟子集先跑、全量子集后跑或并行）。门禁分两级：自动判定（通过率是否达标、关键指标相对基线回归是否超阈值），通过则自动放行；不通过则自动阻断并进入人工审批队列。分级策略：低风险变更（纯文案、无行为变化）门禁较松；高风险变更（改系统提示、改工具、影响核心流程）门禁严，需人工审批+灰度。同时把评估结果按 prompt 版本归档，生成 diff 报告，便于审批决策与复盘。

Prompt CI/CD 的核心是"变更即检、分级门禁"；自动判定保效率、人工审批保兜底，按风险分级避免"一刀切"误伤或漏放。

• 基线定义与冻结
• 比较窗口
• 显著性判定与告警

基线：每个 prompt/模型版本上线时冻结其评估结果作为基线（含各指标均值与置信区间），并记录版本号。比较窗口：用"当前版本 vs 上一稳定版"或"滑动窗口 vs 冻结基线"对比，窗口要足够大以稳定统计、又足够短以早发现退化。显著性判定：用置信区间/显著性检验（如两版本差异是否显著超过阈值），只有统计显著且超过业务阈值才告警，避免日常噪声误报。同时设"静默退化检测"：周期性的自动回归测试 + 趋势监控（连续下降趋势），及时告警，防止数周后才通过人工发现。

静默退化源于"没有持续对比"；冻结基线+比较窗口+显著性判定+趋势告警四件套让退化在早期被自动捕获。

• 人工标注子集校准 judge
• judge 偏差（位置、长度、宽松/严格）校准
• 版本升级的重新校准与历史可比

校准流水线：用人工标注子集（带 ground truth 评分）对比 judge 打分，计算准确率、一致性（与人工的 Kappa）、偏差（宽松/严格、位置偏好、长度偏好），据此调整 judge 的 prompt、评分标准或加"校准说明"，直到 judge 与人工对齐。judge 版本升级时：在新 judge 上重跑同一人工标注子集与历史评测集，量化新旧 judge 的分差，建立映射/校准系数；历史结果保留旧 judge 版本标签，对比时说明"分差来源是 judge 而非模型"，或对历史分数做转换后再比较，保证跨版本可比。

judge 本身有偏差且版本会变，必须用人工标注子集持续校准；升级时用"重跑校准集+版本标签+系数映射"隔离 judge 变化，保住历史可比性。

• 数据集版本控制
• 分层采样
• 污染检测

版本控制：评估集用 Git/数据仓库管理，每次变更记录版本、变更说明与统计，结果绑定版本。分层采样：按难度（简单/中等/困难/对抗）、场景、意图分层采样，保证评测集覆盖度与区分度，避免全是简单样本虚高。标注一致性：双人标注+一致性校验（Kappa），对不一致样本复审，制定标注规范保证可复现。污染检测：定期用 embedding 相似度/近邻检查评估题与训练语料是否重合，剔除已污染样本或标记"已被污染"作参照，用时间切分防止评估题进入训练数据。

评测集是工程资产，版本化保证可追溯、分层保证代表性、一致性保证质量、污染检测保证可信度，四者缺一不可。

• 样本量与置信区间
• 多指标冲突处理
• 统计显著性与业务显著性区分

样本量：用功效分析确定，保证能检出期望差别的置信区间宽度。置信区间：报告各指标的均值差与置信区间，不只看 p 值。多指标冲突：质量提升但成本/延迟上升时，用"综合决策"而非单一指标——定义主指标（用户可感知质量）与次指标（成本、延迟），冲突时按业务优先级权衡，或设成本上限约束。统计显著性（差异是否由随机引起）与业务显著性（差异是否值得上线）分开：统计显著但提升微小（如 0.1%）不值得上线，业务显著但统计不显著还要扩大样本确认。最终决策 = 主指标统计显著 + 业务收益超过成本。

A/B 评估要防"样本不足假阴性"与"多指标矛盾"，核心是区分"统计上成立"与"业务上值得"，用主指标+成本约束做综合决策。

• 各指标含义
• 指标组合与优先级
• 发布决策规则

指标体系：任务成功率（端到端是否达成目标）、事实一致性（生成是否忠于上下文）、答案相关性（是否答所问）、幻觉率（是否编造）、延迟 P95（体验）、成本/请求（经济性）。单一发布决策：设定主指标（任务成功率或用户核心转化）与硬性约束（幻觉率上限、延迟 P95 上限、成本上限），用"主指标达标 + 约束不突破"的组合判定。例如：任务成功率提升但幻觉率超阈值则阻断；延迟/成本上升但主指标显著提升且不超预算则可放行。用加权或规则打分综合，但约束类指标用"一票否决"。

质量与成本/延迟往往冲突，单一指标无法决策；用"主指标+硬约束+规则"组合，把多维指标压缩成可执行的是/否判定。

• 生产流量回放机制
• 离线指标与在线行为对齐
• 验证与上线

影子评估：把线上真实流量（请求、上下文、用户意图）复制一份，发到新 Prompt/模型版本（影子环境），不返回给用户、不影响线上，同时记录新旧版本输出。对比离线指标（任务成功率、事实一致性、相关性）与在线行为（用户点击、满意度、错误率），验证"离线评测能否预测在线行为"。对齐验证：若离线高分与在线行为一致，说明评测可信；若不一致，说明评测集或指标口径有偏差，需修正。通过在影子层安全对比，确认新版本无退化后再灰度上线。

影子评估用真实流量验证评测的可信度，把"离线高分"与"线上表现"对齐；是降低上线风险、校准评测的关键手段。

• 分布漂移检测
• 发现评估集过时
• 增量补充样本

检测漂移：定期对比线上输入分布（意图、长度、语言、主题、难度）与评估集分布，用嵌入向量分布、PSI（人群稳定指数）、意图比例等指标检测差异；同时监控"评估集分数与线上指标偏差"是否扩大。发现过时：当线上出现评估集未覆盖的新意图/新格式/新难度，或评估指标与线上失联时，判定评估集过时。增量补充：从线上新增样本（按新分布分层采样）补充进评估集，人工标注后回流，重跑评估集验证代表性，并控制增量比例避免震荡，保持与线上分布对齐。

业务输入会漂移，静态评估集会过时；持续检测分布差异并按新分布增量补充样本，才能让评估集代表当前线上。

• G-Eval/DAG/Hallucination 指标
• 自定义业务指标组合
• CI 可消费的 pass/fail 输出

DeepEval 提供 G-Eval（LLM 按 rubric 打分）、DAG（基于 DAG 的复杂评估流程）、Hallucination（检测生成是否忠于上下文）等指标，可组合评估质量。同时可自定义业务指标（如 FAQ 命中率、业务规则符合度），用评估器把多个指标聚合。输出为 CI 信号：把各指标与阈值比较，生成 pass/fail 结果，DeepEval 的 pytest 集成让评估作为测试用例运行，失败即产生非零退出码，或者输出 JSON 报告供 CI 解析；按"关键指标必须 pass + 次要指标加权"合成最终门禁判定。

DeepEval 提供通用质量指标，自定义指标补业务维度；通过 pytest 集成与 JSON/退出码输出，把评估变成 CI 门禁可执行、可解析的信号。

• YAML 配置驱动评估
• 嵌入 GitHub Actions/GitLab CI
• 失败时生成 diff 报告

Promptfoo 用 YAML 定义评测（prompt 变体、测试用例、断言阈值），可用 promptfoo eval 命令行运行。嵌入 CI：在 GitHub Actions/GitLab CI 的 workflow 中安装 promptfoo，运行 eval，根据断言失败生成退出码，失败即阻断流水线。diff 报告：promptfoo 会把新旧 prompt 变体在相同测试集上的输出与断言结果对比，生成 diff 报告（哪个用例从前过变后挂、输出变化），输出为 HTML/view 供人在 CI 中查看，辅助定位是哪个 prompt 改动导致哪个用例退化。

YAML 让评估可版本化、可复现，CI 集成把"prompt 变更"变成自动化门禁；diff 报告让失败可定位到具体用例与输出变化，加速调试。

• Trace→Dataset→Experiment 闭环
• 生产失败案例自动回流
• 脱敏与去重

LangSmith 记录每次生产调用的 Trace（输入、输出、上下文、元数据），可筛选出失败案例（用户点踩、质量低、错误率高的 trace）自动加入 Dataset，作为新增评估样本；再对 Dataset 跑 Experiment（新 prompt/模型版本），验证是否修复了这些案例。回流时脱敏：对 trace 中的敏感信息（PII、密钥、隐私字段）做脱敏（替换、掩码、删除）后再入库，避免敏感数据进入评估集/训练数据。去重：用输入哈希/embedding 相似度去重，避免重复样本污染分布与统计。

Trace→Dataset→Experiment 让生产失败自动成为回归样本，形成闭环；脱敏与去重保证回流样本安全、干净、不污染统计。

• 多维度切片
• 质量趋势图
• 归因与迭代决策

可视化：把评估结果按多维度切片展示——按 Prompt 版本看质量趋势、按模型版本看对比、按输入类别（意图、语言、难度）看细分质量。趋势图驱动决策：发现某输入类别质量下降，定位到对应 Prompt/模型版本，归因到具体改动；发现某版本整体提升但某类别退化，做针对性优化（该类别加样本、调 prompt）。实践：用"切片下钻+版本对比"回答问题"哪个改动、对哪类输入、影响了什么指标"，据此排序迭代优先级，避免盲目优化。

聚合分数掩盖了"哪类输入、哪个版本"的问题；多维切片趋势图让归因精确到版本与类别，是驱动迭代决策的关键。

• Prompt 一致性控制
• 随机性与位置偏差控制
• 结果转选型决策

控制：Prompt 一致性——同一任务对所有模型用完全相同的 prompt（或按各模型口径微调但保持任务等价），避免 prompt 差异污染对比；随机性——固定 temperature/seed，多次运行取均值或变更区间，消除采样噪声；位置偏差——在排序/多选对比中交换候选顺序（对调 A/B 位置），消除位置偏好。转化决策：不只是给出排名，而是结合各模型在指标、成本、延迟、供应商风险、可控性上的综合表现构建决策矩阵（质量 vs 成本 vs 延迟 vs 合规），按业务约束选型而非选"最高分"。同时做多模型冗余与切换预案。

对比评估要消除 prompt/随机/位置三类偏差，否则排名失真；选型决策要综合质量、成本、延迟与合规，而非唯分数论。

• 评估超时处理
• judge 服务不可用降级
• 数据集损坏与告警

可靠性设计：评估超时——给每个评估任务与 judge 调用设超时与重试，超时标记为失败或跳过，避免单条卡死整批；judge 服务不可用——降级到备用 judge 模型或缓存结果，或延迟执行并告警，避免评估静默失败；数据集损坏——校验集完整性（数量、格式、schema），损坏时用最近可用版本并告警，防止脏数据跑出假分数。告警：评估失败率、超时率、judge 错误率、数据集校验异常都上报监控，触发告警。保证评估结果"可信、可用、可追溯"。

评估流水线也可能故障，且故障会让门禁误判或漏判；超时/降级/校验+告警保证评估自身可靠，是质量门禁可信的前提。

• 各 Scorer 适用任务
• 按任务类型编排
• 多 Scorer 冲突加权

编排：按任务类型选 Scorer——精确匹配（代码、ID、确定性输出）、语义相似度（开放问答、摘要）、LLM judge（主观质量、相关性、事实性）、自定义函数（业务规则、格式校验）。复杂任务可组合多个 Scorer（如"语义相似度+LLM judge"）。多 Scorer 冲突时：给每个 Scorer 设权重（按可靠性与任务相关性），加权合成总分；或设"关键 Scorer 一票否决"（如事实一致性失败则判 fail）。冲突时优先可信的 Scorer（如业务规则高于 LLM judge），并记录各 Scorer 明细便于归因。

Scorer 各有适用任务，组合覆盖不同质量维度；冲突时用加权或关键一票否决合成，保证最终判定一致且可解释。

• token 成本估算
• 采样降本
• 批处理与增量评估

估算：单条评估成本 = 输入 token（被评输出+上下文）× 单价 + 输出 token（judge 打分）× 单价，乘以全量样本数即总成本，可先小样本实测单价再外推。降本：一是采样，用代表性抽样替代全量（分层采样保证覆盖），误差可控；二是批处理，把多条样本合并进一个 judge 请求批量打分，摊薄每条的输入与请求开销；三是增量评估，只跑变更影响的样本（回归集），复用已通过的结果，避免全量重跑；四是选更便宜的 judge 模型或缓存。评估预算与质量权衡，用采样把成本控制在预算内。

LLM-as-Judge 成本随样本量线性增长；采样、批处理、增量评估分别从"减样本数、摊请求开销、减少重跑"降本，是评估成本可控的关键。

• 开源框架的合规/可扩展/支持成本
• 商业平台对比
• 取舍

开源框架（RAGAS 专注 RAG 指标、TruLens 侧重反馈与归因、OpenAI Evals 灵活）自部署、数据不出域、合规可控、可自由扩展，但需自建运维、无官方支持、文档与维护成本自担；商业平台开箱即用、有 SLA 与支持、功能全，但数据可能出域（合规风险）、按量付费、受供应商锁定。取舍：数据敏感/合规严格/强自研能力用开源；小团队快速上线/需托管支持用商业平台。可"开源自建核心 + 商业补充"混合，按数据敏感度与工程能力决策。

开源与商业的核心取舍是"合规可控 vs 省心支持"；按数据敏感度与自研能力决定，必要时混合使用。

• 先写评估用例再写 Prompt
• 评估驱动开发流程
• 评估覆盖率衡量完成度

工作流：先定义任务场景与验收标准，写出评估用例（输入、期望行为、断言），再据此设计 Prompt，用评估驱动 Prompt 迭代。做法：先"用例先行"——把关键场景（正常、边界、对抗、长尾）写成测试用例作为契约，再写或改 Prompt 使其通过用例，凡新增功能先补用例、再改 Prompt。评估覆盖率衡量完成度：覆盖率 = 用例覆盖的场景数/需覆盖的场景数，覆盖了正常/边界/对抗/长尾才算完成；同时看"用例通过率"确保质量。覆盖率越高说明 Prompt 工程越完整，避免只覆盖主路径而漏边界。

评估驱动开发让"需求→用例→Prompt→验证"闭环，用例先行保证行为可测；覆盖率衡量"覆盖面"，通过率衡量"正确性"，两者共同衡量完成度。

• 区分数据/judge/模型问题
• 复核流程
• 结论回流修正评估集

复核时区分三类问题：一、数据问题——评估用例本身有误（标注错误、答案错误、歧义），人工复核发现用例无效；二、judge 问题——judge 打分偏差（误判、错标），对比参考后确认 judge 不可靠；三、模型问题——数据与 judge 都对，模型输出确实不达标。区分方法：人工看具体失败用例，用"数据正确性→judge 一致性→模型输出质量"逐层排查。回流修正：数据问题修正确认用例后更正或移除；judge 问题调整 judge 配置并重测；模型问题作为真实 badcase 保留并用于优化。复核结论回流到评估集，保证评估集持续可信。

门禁失败不等于模型差，可能是数据或 judge 的锅；逐层排查区分来源，再把结论回流修正评估集，才能让门禁可信且持续改进。