尧图网站建设 
问题背景这是《LLM Ops 评测与可观测实战》系列的第一篇之后十篇的评测、门禁、追踪、灰度都会站在今天这块地基上。先说一个大多数团队都经历过的场景客服团队上线了一个基于 RAG 的售后政策问答机器人演示会上负责人连问五个问题四个答得漂亮于是宣布效果不错上线。两周后投诉堆积退款时效问题答错、把不支持七天无理由的商品说成支持、遇到方言输入直接胡编。回头复盘没有人能说清上线那天的机器人到底行不行——因为根本没人系统地量过。传统软件有单元测试和断言输入确定输出确定LLM 应用输出的是一条概率分布感觉不错本质上是拿五六个样本去猜一个分布的形状这种验收方式在统计学上就不成立。本篇回答三个问题评测集到底在工程上扮演什么角色一个小到一周就能建起来的评测体系长什么样不建评测集时你实际在用什么替代品以及那个替代品坏在哪里。核心原理第一层评测集是效果的版本控制。代码有 git配置的每一次变更有 diff 可查而 prompt、模型版本、检索参数这三样东西的变更在传统流程里完全没有 diff改了 prompt 的第三行措辞你不知道它对多轮追问类问题造成了什么影响因为没有任何基线可以对照。评测集做的事情就是把效果变成一个可以对两次变更做差分的标量或一组标量。没有它回滚都无法决策——你想退回旧版本却拿不出旧版本到底差在哪、差多少的证据。第二层LLM 的非确定性让小样本彻底失真。同一输入温度不为零时输出会变于是单次问答结果带有采样噪声当你只凭十来个案例判断版本好坏噪声经常比真实效应大。把这件事模拟出来最直观假设新版本真实通过率 0.75、旧版本 0.72新版本确实更好用固定随机种子按不同样本量各做 400 次抽样评测统计把更好的新版误判成持平或退步的比例。第三层不建评测集不等于没有评测只是评测标准劣化了。团队会自发找到代理指标演示时的通过率、产品经理的手工抽测、上线后前几条用户反馈、竞对 demo 的对比印象。这些代理有三个共同病灶——样本小且偏专挑能打的问、标准漂移每个人心里好的定义不同同一条回答两个人给出相反结论、不可累积人的印象无法参与下一次版本比较。评测集工程的全部动机就是把这套劣化的隐式评测换成可复现、可累积、可审计的显式评测。第四层评测集的最小可行形态。不需要一步到位三样东西凑齐就算立起来了一个 200 到 500 条、按业务意图分层抽样的用例集意图如政策问答、订单查询、边界拒答、多轮追问每条带参考答案或评分标准一套自动打分流程下一篇建数据集第三篇讲打分一条 CI 里的回归基线——每次 prompt 或模型变更跑一遍出分对比。先有粗糙但稳定的尺子再谈精细的尺子。实验一凭感觉验收在统计上为什么会翻车本机无第三方依赖以下用 Python 标准库做确定性模拟固定种子演示抽样规模与结论稳定性的关系生产环境请用真实评测平台跑真实用例。importrandom TRUE_A0.72# 旧版本真实通过率TRUE_B0.75# 新版本真实通过率(确实更好)TRIALS400deftrial(n,seed):rngrandom.Random(seed)flips0gaps[]for_inrange(TRIALS):asum(1for_inrange(n)ifrng.random()TRUE_A)/n bsum(1for_inrange(n)ifrng.random()TRUE_B)/nifba:flips1gaps.append(abs(b-a))returnflips,sum(gaps)/len(gaps)print(评测集样本量对结论稳定性的影响(每档 400 次重复实验, 种子42):)print(样本量 n | 误判率(把更好的新版判成持平或退步) | 平均表观差距)fornin(20,50,100,300,1000):flips,mean_gaptrial(n,seed42)print(n%4d | %5.1f%% | %.3f%(n,flips/TRIALS*100,mean_gap))运行输出评测集样本量对结论稳定性的影响(每档 400 次重复实验, 种子42): 样本量 n | 误判率(把更好的新版判成持平或退步) | 平均表观差距 n 20 | 47.0% | 0.114 n 50 | 40.2% | 0.077 n 100 | 32.8% | 0.059 n 300 | 24.2% | 0.038 n1000 | 6.5% | 0.031这组数字值得裱起来贴在评审会上两个版本真实差距 3 个百分点时20 条用例的评测有 47% 的概率得出反向结论——和抛硬币一样哪怕 100 条仍有近三分之一的误判率。注意 3 个百分点本就是勉强值得切换的差距如果你的真实提升只有 1 个点需要上千条用例才看得见。这也解释了为什么演示会式的验收总能成功演示者挑的案例、挑的轮次相当于在 47% 误判率之上再做一轮对己有利的筛选。实验二要多大的尺子才配说提升了换一个角度用正态近似算置信区间半宽纯标准库 math 即可回答n 条用例的通过率估计误差到底有多大。importmath BASE0.72Z1.96defhalf_width(p,n):returnZ*math.sqrt(p*(1-p)/n)print(通过率 0.72 的点估计, 不同样本量下的 95% 置信区间(正态近似):)fornin(20,50,100,200,400,800):hhalf_width(BASE,n)print(n%4d 半宽%.3f 区间[%.3f, %.3f]%(n,h,BASE-h,BASEh))target0.03n1whilehalf_width(BASE,n)target:n1print(要把置信区间半宽压到 0.03 以内, 单版本最少需要 %d 个用例%n)print(两个版本各自独立评测时, 比较的有效差距约为半宽的 sqrt(2) 倍)print(可分辨差距下限约 %.3f%(target*math.sqrt(2)))运行输出通过率 0.72 的点估计, 不同样本量下的 95% 置信区间(正态近似): n 20 半宽0.197 区间[0.523, 0.917] n 50 半宽0.124 区间[0.596, 0.844] n 100 半宽0.088 区间[0.632, 0.808] n 200 半宽0.062 区间[0.658, 0.782] n 400 半宽0.044 区间[0.676, 0.764] n 800 半宽0.031 区间[0.689, 0.751] 要把置信区间半宽压到 0.03 以内, 单版本最少需要 861 个用例 两个版本各自独立评测时, 比较的有效差距约为半宽的 sqrt(2) 倍 可分辨差距下限约 0.04220 条用例测出的通过率 72%真实区间是 [52%, 92%]——这个分数除了自我安慰毫无信息量。要把不确定度压到 ±3 个点单版本需要近 900 条两版对比时可分辨差距进一步放大到 4 个点上下。工程上从中得到两条硬结论其一评测集规模是按你想分辨多大的差距倒推出来的不是拍脑袋定 100 条其二同一批用例要打在两个版本上做配对比较比两个独立样本比较灵敏得多——这正是第四篇回归测试采用同案例集逐条 diff而不是只看总分的原因。工程落地路径第一步从线上日志冷启动。没有评测集的团队几乎一定有对话日志客服系统、API 请求记录、反馈表。按业务意图分桶抽样 300 条人工过一遍挑出答错的、可疑的、典型的三类标注预期行为应该引用哪条政策、应该拒答、应该追问什么。两三个人工日就能立起第一版先跑通链路再追求规模。第二步评分标准写到字符串级。每条用例除了参考答案还要写判分要点必须包含退款时效三个字、必须不承诺具体到账日、出现电话号码即判错。要点式标准让不同标注员结论趋于一致也是第三篇 LLM-as-judge 提示词的原料。第三步分数进 CI基线进档案。每次 prompt/模型/检索参数变更自动跑评测分数与变更号绑定存档。评测集本身也是代码进版本库、有 owner、有 review被业务方投诉答非所问的案例先进监控名单、季度评审后晋升为用例——数据集要随业务生长否则半年后它就测不到真实分布了。常见陷阱其一用通用 benchmarkMMLU、GSM8K 这类代替业务评测榜上分数与你的售后问答质量几乎不相关模型选型必须以自己的评测集为准。其二评测集与训练/提示示例同源把调 prompt 时用过的案例留在评测集里等于开卷考试分数虚高且掩盖真问题——调 prompt 用的案例和评测案例要物理隔离。其三只测单轮真实用户大量追问、改口、夹带方言单轮通过率漂亮的多轮一塌糊涂评测集中多轮对话用例占比建议不低于三成。其四把评测当一次性活动为选型建完集就扔之后 prompt 改了七版没人重跑评测集最大的价值恰恰在持续两个字。其五评分标准口头化回答要自然这种形容词无法复核两个人打出的分差到 0.4 以上满分 1 分制尺子本身就是噪声源。落地清单盘点线上对话日志按意图分层挑 300 条起步标注预期行为 判分要点评测集与 prompt 调优用例物理隔离版本化管理并指定 owner用置信区间倒推规模想分辨几个点的差距就要近千条同集配对的用例每次变更自动跑评测分数与变更号一同归档可差分、可回滚投诉与线上坏案例进入候选池季度评审晋升为正式用例尺子立起来了接下来的问题是这把尺子上的刻度从哪来评测集不能靠几个人坐在工位上编造问题它必须采样自真实的线上分布并经过一套能控制一致性的标注流程。下一篇《LLM Ops 评测与可观测实战2golden dataset 构建线上数据的采样与标注流程》把从十万条日志到三百条金标准的流水线走一遍。参考来源OpenAI Evaluation guideshttps://platform.openai.com/docs/guides/evalsStanford HELMHolistic Evaluation of Language Modelshttps://arxiv.org/abs/2211.09110WikipediaBinomial proportion confidence intervalhttps://en.wikipedia.org/wiki/Binomial_proportion_confidence_intervalWikipediaCohen’s kappahttps://en.wikipedia.org/wiki/Cohen%27s_kappaLangfuse 文档评测与数据集https://langfuse.com/docs LLM Ops 评测与可观测实战（1）：LLM 应用为什么必须有评测集：告别凭感觉验收
问题背景这是《LLM Ops 评测与可观测实战》系列的第一篇之后十篇的评测、门禁、追踪、灰度都会站在今天这块地基上。先说一个大多数团队都经历过的场景客服团队上线了一个基于 RAG 的售后政策问答机器人演示会上负责人连问五个问题四个答得漂亮于是宣布效果不错上线。两周后投诉堆积退款时效问题答错、把不支持七天无理由的商品说成支持、遇到方言输入直接胡编。回头复盘没有人能说清上线那天的机器人到底行不行——因为根本没人系统地量过。传统软件有单元测试和断言输入确定输出确定LLM 应用输出的是一条概率分布感觉不错本质上是拿五六个样本去猜一个分布的形状这种验收方式在统计学上就不成立。本篇回答三个问题评测集到底在工程上扮演什么角色一个小到一周就能建起来的评测体系长什么样不建评测集时你实际在用什么替代品以及那个替代品坏在哪里。核心原理第一层评测集是效果的版本控制。代码有 git配置的每一次变更有 diff 可查而 prompt、模型版本、检索参数这三样东西的变更在传统流程里完全没有 diff改了 prompt 的第三行措辞你不知道它对多轮追问类问题造成了什么影响因为没有任何基线可以对照。评测集做的事情就是把效果变成一个可以对两次变更做差分的标量或一组标量。没有它回滚都无法决策——你想退回旧版本却拿不出旧版本到底差在哪、差多少的证据。第二层LLM 的非确定性让小样本彻底失真。同一输入温度不为零时输出会变于是单次问答结果带有采样噪声当你只凭十来个案例判断版本好坏噪声经常比真实效应大。把这件事模拟出来最直观假设新版本真实通过率 0.75、旧版本 0.72新版本确实更好用固定随机种子按不同样本量各做 400 次抽样评测统计把更好的新版误判成持平或退步的比例。第三层不建评测集不等于没有评测只是评测标准劣化了。团队会自发找到代理指标演示时的通过率、产品经理的手工抽测、上线后前几条用户反馈、竞对 demo 的对比印象。这些代理有三个共同病灶——样本小且偏专挑能打的问、标准漂移每个人心里好的定义不同同一条回答两个人给出相反结论、不可累积人的印象无法参与下一次版本比较。评测集工程的全部动机就是把这套劣化的隐式评测换成可复现、可累积、可审计的显式评测。第四层评测集的最小可行形态。不需要一步到位三样东西凑齐就算立起来了一个 200 到 500 条、按业务意图分层抽样的用例集意图如政策问答、订单查询、边界拒答、多轮追问每条带参考答案或评分标准一套自动打分流程下一篇建数据集第三篇讲打分一条 CI 里的回归基线——每次 prompt 或模型变更跑一遍出分对比。先有粗糙但稳定的尺子再谈精细的尺子。实验一凭感觉验收在统计上为什么会翻车本机无第三方依赖以下用 Python 标准库做确定性模拟固定种子演示抽样规模与结论稳定性的关系生产环境请用真实评测平台跑真实用例。importrandom TRUE_A0.72# 旧版本真实通过率TRUE_B0.75# 新版本真实通过率(确实更好)TRIALS400deftrial(n,seed):rngrandom.Random(seed)flips0gaps[]for_inrange(TRIALS):asum(1for_inrange(n)ifrng.random()TRUE_A)/n bsum(1for_inrange(n)ifrng.random()TRUE_B)/nifba:flips1gaps.append(abs(b-a))returnflips,sum(gaps)/len(gaps)print(评测集样本量对结论稳定性的影响(每档 400 次重复实验, 种子42):)print(样本量 n | 误判率(把更好的新版判成持平或退步) | 平均表观差距)fornin(20,50,100,300,1000):flips,mean_gaptrial(n,seed42)print(n%4d | %5.1f%% | %.3f%(n,flips/TRIALS*100,mean_gap))运行输出评测集样本量对结论稳定性的影响(每档 400 次重复实验, 种子42): 样本量 n | 误判率(把更好的新版判成持平或退步) | 平均表观差距 n 20 | 47.0% | 0.114 n 50 | 40.2% | 0.077 n 100 | 32.8% | 0.059 n 300 | 24.2% | 0.038 n1000 | 6.5% | 0.031这组数字值得裱起来贴在评审会上两个版本真实差距 3 个百分点时20 条用例的评测有 47% 的概率得出反向结论——和抛硬币一样哪怕 100 条仍有近三分之一的误判率。注意 3 个百分点本就是勉强值得切换的差距如果你的真实提升只有 1 个点需要上千条用例才看得见。这也解释了为什么演示会式的验收总能成功演示者挑的案例、挑的轮次相当于在 47% 误判率之上再做一轮对己有利的筛选。实验二要多大的尺子才配说提升了换一个角度用正态近似算置信区间半宽纯标准库 math 即可回答n 条用例的通过率估计误差到底有多大。importmath BASE0.72Z1.96defhalf_width(p,n):returnZ*math.sqrt(p*(1-p)/n)print(通过率 0.72 的点估计, 不同样本量下的 95% 置信区间(正态近似):)fornin(20,50,100,200,400,800):hhalf_width(BASE,n)print(n%4d 半宽%.3f 区间[%.3f, %.3f]%(n,h,BASE-h,BASEh))target0.03n1whilehalf_width(BASE,n)target:n1print(要把置信区间半宽压到 0.03 以内, 单版本最少需要 %d 个用例%n)print(两个版本各自独立评测时, 比较的有效差距约为半宽的 sqrt(2) 倍)print(可分辨差距下限约 %.3f%(target*math.sqrt(2)))运行输出通过率 0.72 的点估计, 不同样本量下的 95% 置信区间(正态近似): n 20 半宽0.197 区间[0.523, 0.917] n 50 半宽0.124 区间[0.596, 0.844] n 100 半宽0.088 区间[0.632, 0.808] n 200 半宽0.062 区间[0.658, 0.782] n 400 半宽0.044 区间[0.676, 0.764] n 800 半宽0.031 区间[0.689, 0.751] 要把置信区间半宽压到 0.03 以内, 单版本最少需要 861 个用例 两个版本各自独立评测时, 比较的有效差距约为半宽的 sqrt(2) 倍 可分辨差距下限约 0.04220 条用例测出的通过率 72%真实区间是 [52%, 92%]——这个分数除了自我安慰毫无信息量。要把不确定度压到 ±3 个点单版本需要近 900 条两版对比时可分辨差距进一步放大到 4 个点上下。工程上从中得到两条硬结论其一评测集规模是按你想分辨多大的差距倒推出来的不是拍脑袋定 100 条其二同一批用例要打在两个版本上做配对比较比两个独立样本比较灵敏得多——这正是第四篇回归测试采用同案例集逐条 diff而不是只看总分的原因。工程落地路径第一步从线上日志冷启动。没有评测集的团队几乎一定有对话日志客服系统、API 请求记录、反馈表。按业务意图分桶抽样 300 条人工过一遍挑出答错的、可疑的、典型的三类标注预期行为应该引用哪条政策、应该拒答、应该追问什么。两三个人工日就能立起第一版先跑通链路再追求规模。第二步评分标准写到字符串级。每条用例除了参考答案还要写判分要点必须包含退款时效三个字、必须不承诺具体到账日、出现电话号码即判错。要点式标准让不同标注员结论趋于一致也是第三篇 LLM-as-judge 提示词的原料。第三步分数进 CI基线进档案。每次 prompt/模型/检索参数变更自动跑评测分数与变更号绑定存档。评测集本身也是代码进版本库、有 owner、有 review被业务方投诉答非所问的案例先进监控名单、季度评审后晋升为用例——数据集要随业务生长否则半年后它就测不到真实分布了。常见陷阱其一用通用 benchmarkMMLU、GSM8K 这类代替业务评测榜上分数与你的售后问答质量几乎不相关模型选型必须以自己的评测集为准。其二评测集与训练/提示示例同源把调 prompt 时用过的案例留在评测集里等于开卷考试分数虚高且掩盖真问题——调 prompt 用的案例和评测案例要物理隔离。其三只测单轮真实用户大量追问、改口、夹带方言单轮通过率漂亮的多轮一塌糊涂评测集中多轮对话用例占比建议不低于三成。其四把评测当一次性活动为选型建完集就扔之后 prompt 改了七版没人重跑评测集最大的价值恰恰在持续两个字。其五评分标准口头化回答要自然这种形容词无法复核两个人打出的分差到 0.4 以上满分 1 分制尺子本身就是噪声源。落地清单盘点线上对话日志按意图分层挑 300 条起步标注预期行为 判分要点评测集与 prompt 调优用例物理隔离版本化管理并指定 owner用置信区间倒推规模想分辨几个点的差距就要近千条同集配对的用例每次变更自动跑评测分数与变更号一同归档可差分、可回滚投诉与线上坏案例进入候选池季度评审晋升为正式用例尺子立起来了接下来的问题是这把尺子上的刻度从哪来评测集不能靠几个人坐在工位上编造问题它必须采样自真实的线上分布并经过一套能控制一致性的标注流程。下一篇《LLM Ops 评测与可观测实战2golden dataset 构建线上数据的采样与标注流程》把从十万条日志到三百条金标准的流水线走一遍。参考来源OpenAI Evaluation guideshttps://platform.openai.com/docs/guides/evalsStanford HELMHolistic Evaluation of Language Modelshttps://arxiv.org/abs/2211.09110WikipediaBinomial proportion confidence intervalhttps://en.wikipedia.org/wiki/Binomial_proportion_confidence_intervalWikipediaCohen’s kappahttps://en.wikipedia.org/wiki/Cohen%27s_kappaLangfuse 文档评测与数据集https://langfuse.com/docs