当前位置：首页 > news >正文

大模型 A/B 评测前端——双盲渲染、多维评分与一致性校验

news 2026/7/31 21:25:00

大模型 A/B 评测前端——双盲渲染、多维评分与一致性校验

一、从「拍脑袋选模型」到「双盲可复现」：评测前端的工程化痛点

某团队模型迭代到第三版，算法侧说新版更好，产品侧说用户反馈没变化。复盘发现此前的评测是群里贴两条输出，大家凭感觉投票。位置偏好让先出现的版本天然占优，身份偏好让「自家模型」自带光环。这事我见过太多团队栽进去——把模型评测当朋友圈投票，没有协议、没有维度、没有显著性校验。

模型迭代周期缩短后，评测本身成了瓶颈。算法每周出一个候选版本，到底比线上版本好多少，必须用可复现的方法回答。靠主观感受无法排期，也无法向业务方交代「这次升级带来了什么」。

A/B 评测前端的职责，是把「人判断哪个更好」这件事工程化。它要解决三件事：第一，消除位置与身份偏好（双盲渲染）；第二，把「更好」拆成可量化的多维评分；第三，聚合多人评分并校验一致性，给出统计显著性结论。三者缺一，评测结论都站不住脚。

盲测是消除偏好的核心手段。两条输出随机分配到左右位，模型身份对评分者隐藏，评分完成后才揭示。即便如此仍不够，因为单次评分带有主观随机性，必须多人交叉并校验一致性。

二、盲测协议与评分聚合：A/B 评测的底层机制

盲测协议的关键是随机化与隔离。每次评测任务包含一个 prompt 与两条候选输出（A 与 B）。前端在渲染前随机决定 A 在左还是 B 在左，并把模型标识与输出绑定后存到服务端，前端只拿到一个不含身份的渲染句柄。评分者看到的是「左 vs 右」，不知道哪条对应哪个模型。

评分维度（rubric）把「更好」拆解为可量化的轴。常见维度包括：准确性（事实是否正确）、连贯性（逻辑与衔接）、有用性（是否切题并解决问题）、安全性（是否有害或越界）。每个维度按 1-5 分或成对比较（A 优于 B、平手、B 优于 A）打分。多维评分比单一「哪个好」更稳定，也更能定位差异来源。

一致性校验是过滤噪声的关键。同一任务由多名评分者独立打分，用 Cohen's Kappa（两人）或 Fleiss' Kappa（多人）衡量一致性。Kappa 低于 0.4 视为一致性不足，该任务需返工或重新设计 rubric。统计显著性上，成对比较常用二项检验或 Bootstrap 置信区间，样本量不足时结论不可下。

综上，A/B 评测链路把主观判断变成可复现的工程流程：随机化消除偏好、多维评分稳定结论、一致性校验过滤噪声、统计检验把关显著性。四步串起来，对比结论才站得住脚。

三、生产级 A/B 评测工作台核心实现

下面给出一个评测工作台核心。它做双盲分配、多维评分收集、本地暂存防丢失，以及多人一致性校验。

// 评测工作台核心 —— 双盲分配与评分聚合逻辑 interface ModelOutput { modelId: string; // 真实模型标识，评分阶段对前端不可见 content: string; } interface EvalTask { taskId: string; prompt: string; outputs: [ModelOutput, ModelOutput]; } // 评分维度，每个维度独立打分 1-5 interface Rubric { accuracy: number; // 准确性 coherence: number; // 连贯性 helpfulness: number; // 有用性 safety: number; // 安全性 } interface BlindAssignment { left: { handle: string; content: string }; // handle 是不含模型身份的渲染句柄 right: { handle: string; content: string }; mapping: Record<'left' | 'right', string>; // 句柄到模型标识，仅随评分回传服务端 } // 双盲分配：随机决定左右位，剥离模型身份 function assignBlind(task: EvalTask): BlindAssignment { // 用加密随机数而非 Math.random，避免可预测性破坏盲测可信度 const swap = crypto.getRandomValues(new Uint8Array(1))[0] % 2 === 0; const [a, b] = task.outputs; const left = swap ? b : a; const right = swap ? a : b; return { left: { handle: 'L', content: left.content }, right: { handle: 'R', content: right.content }, mapping: { left: left.modelId, right: right.modelId }, }; } // 评分收集：先写本地暂存再提交网络，弱网下不丢数据 const STORAGE_KEY = 'eval-drafts'; async function submitScore( taskId: string, assignment: BlindAssignment, leftScore: Rubric, rightScore: Rubric ): Promise<void> { const payload = { taskId, mapping: assignment.mapping, // 服务端据此还原模型与位次 leftScore, rightScore, submittedAt: Date.now(), }; // 先入 localStorage 兜底，网络失败也不丢评分 const drafts = JSON.parse(localStorage.getItem(STORAGE_KEY) ?? '[]'); drafts.push(payload); localStorage.setItem(STORAGE_KEY, JSON.stringify(drafts)); try { const res = await fetch('/api/eval/score', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(payload), signal: AbortSignal.timeout(5000), // 5 秒超时，避免弱网挂起 }); if (!res.ok) throw new Error(`提交失败: ${res.status}`); // 成功后从暂存队列移除 const remaining = drafts.filter((d: any) => d.taskId !== taskId); localStorage.setItem(STORAGE_KEY, JSON.stringify(remaining)); } catch { // 失败保留在暂存队列，下次进入页面时重试 console.warn('评分提交失败，已暂存等待重试'); } } // Cohen's Kappa：衡量两名评分者的一致性 // 输入为两人在同一批任务上的成对偏好（0=A优 1=平 2=B优） function cohenKappa(raterA: number[], raterB: number[]): number { if (raterA.length !== raterB.length || raterA.length === 0) return 0; const n = raterA.length; const categories = [0, 1, 2]; // 观察一致率：两人打分相同的比例 let po = 0; for (let i = 0; i < n; i++) if (raterA[i] === raterB[i]) po++; po /= n; // 期望一致率：按边缘概率随机配对时的预期一致 let pe = 0; for (const c of categories) { const pa = raterA.filter((v) => v === c).length / n; const pb = raterB.filter((v) => v === c).length / n; pe += pa * pb; } if (pe === 1) return 1; // 完全一致时避免除零 return (po - pe) / (1 - pe); } // 二项检验：A 胜出次数是否显著高于随机水平 // wins 为 A 胜出次数，total 为有效任务数（排除平手） function binomialTest(wins: number, total: number): { pValue: number; significant: boolean } { if (total === 0) return { pValue: 1, significant: false }; // 零假设下 A 胜出概率为 0.5，计算胜出次数 >= wins 的累积概率 const p = 0.5; let tail = 0; // 用对数避免阶乘溢出 for (let k = wins; k <= total; k++) { let logC = 0; for (let i = 1; i <= k; i++) logC += Math.log(total - i + 1) - Math.log(i); tail += Math.exp(logC + k * Math.log(p) + (total - k) * Math.log(1 - p)); } // 双侧检验，显著性阈值 0.05 return { pValue: Math.min(2 * tail, 1), significant: 2 * tail < 0.05 }; }

关键点在于四处。其一，双盲分配用crypto.getRandomValues而非Math.random，避免可预测性破坏盲测可信度。其二，评分先写 localStorage 再提交网络，弱网下不丢数据。其三，Cohen's Kappa 校验两人一致性，低于阈值返工。其四，二项检验判断胜出是否显著高于随机水平，小样本不轻易下结论。

四、评测的代价：标注成本、主观偏差与适用边界

A/B 评测不是免费午餐。

人工标注成本高昂。每个任务需多人独立评分，rubric 维度越多成本越高。一个百任务评测若三人交叉、四维评分，就是 1200 次打分。盲目扩大维度会让评测周期拖到模型迭代周期之外，本末倒置。维度应聚焦差异来源，而非求全。

主观偏差无法完全消除。即便双盲，评分者对「连贯性」的理解仍有差异。rubric 定义模糊时，同一输出在不同评分者间得分迥异。需为每个维度配锚点样例（1 分与 5 分各给一例），把抽象标准具象化。某团队曾因「有用性」无锚点，Kappa 长期低于 0.3，结论无法采信。

统计显著性受样本量约束。二项检验在 30 个有效样本以下几乎无法拒绝零假设。小样本下「无显著差异」不等于「真的无差异」，可能是统计功效不足。需预先做功效分析估算所需样本量，避免无效评测。

盲测揭示延迟带来工程复杂度。模型身份必须在评分完成后才能揭示，前端不能持久化映射表，否则刷新页面就泄露。映射表只随评分一起回传服务端，前端只保留渲染句柄。这套隔离增加了状态管理复杂度，但不可省略。

适用边界：模型迭代决策、prompting 方案对比、安全策略回归收益最高。探索性实验、强主观任务（创意写作）、极低频场景，应简化流程或依赖自动化指标。

五、总结

大模型 A/B 评测前端的核心是「盲测」与「统计」两套机制。落地建议：第一，双盲分配用加密随机数，剥离模型身份，消除位置与身份偏好。第二，多维 rubric 配锚点样例，把抽象标准具象化，稳定评分者理解。第三，评分先写本地再提交网络，弱网下不丢数据。第四，用 Cohen's Kappa 校验一致性，二项检验判断显著性，小样本不轻易下结论。最终在主观判断与统计严谨之间取得平衡。这条路在模型迭代与安全回归场景下能跑通，回报是值得的。