1.1 概念边界、评测对象与核心问题
我经常被问到一个问题：结构化输出评测到底在评什么？这个问题看着简单，真要说清楚得先划清边界。结构化输出指的是模型生成的响应必须遵循某种预先定义的数据组织方式，比如JSON Schema、SQL表结构、XML标签树、表格行列关系，或者是业务系统里约定的字段列表。它跟普通文本生成的核心差异在于，输出结果不只是要“读起来合理”，还得“解析得通、字段填得对、关系接得上”。评测对象既包括大语言模型本身在这类任务上的表现，也涵盖围绕模型搭建的提示词策略、解码约束工具、后处理校验链路。我见过不少团队把评测窄化成“跑一遍测试集看准确率”，结果上线后才发现字段类型不对、嵌套层级缺失、枚举值超范围，这些问题在单点指标上根本看不出来。
核心问题可以拆成三层。第一层是格式层，模型有没有按照Schema输出合法结构，这是底线。第二层是内容层，填进去的值是不是事实正确的、跟输入信息匹配的。第三层是语义关系层，字段之间的依赖约束有没有被满足，比如订单总额要等于明细之和、开始时间不能晚于结束时间。这三层之间不是简单叠加的关系，实际操作中经常出现格式合法但内容胡编、内容对但结构错位的情况。我在项目里就碰到过模型把整段JSON塞进一个字符串字段里，外层结构完全合法，解析器不报错，下游业务逻辑却直接崩掉。评测如果不把这三层拆开看，很容易得出“模型表现不错”的错误结论。
还有一个容易被忽略的点：评测对象到底是谁。同一份评测集在裸模型、加Few-shot提示、加约束解码、加校验重试这四种配置下跑出来的结果可能差出一大截。我的习惯是把评测配置当作评测结论的一部分来记录，不然过两个月回头看报告，根本分不清那个92%的Schema符合率是在什么条件下测出来的。
1.2 结构化输出的典型形态与任务谱系
结构化输出在实际场景里的长相五花八门，我一般按“结构复杂度”和“语义耦合度”两个维度来梳理。低复杂度低耦合的典型是扁平键值对，比如从一段客服对话里抽取姓名、电话、订单号，字段少、关系简单，评测重点放在字段召回和值准确率上。中等复杂度的常见形态是嵌套JSON和表格，像商品信息抽取要处理规格参数的多层嵌套，财务报表解析要还原行列之间的对应关系，这时候评测就得关注层级完整性和跨字段一致性。高复杂度高耦合的那一类，比如知识图谱三元组生成、业务流程状态机描述、多表关联的SQL查询，输出结构本身就是业务逻辑的载体，错一个外键关系整条链路就废了。
任务谱系上我习惯分成四类。第一类是抽取型任务，从非结构化文本里把实体、属性、关系拎出来填进Schema，评测看的是信息覆盖度和边界判断。第二类是转换型任务，把一种结构转成另一种结构，比如自然语言查询转SQL、XML转JSON，评测看的是映射规则的正确性和结构保真度。第三类是生成型任务，模型要根据约束条件从零构造完整结构，像根据接口文档生成请求体、根据业务规则生成配置清单，这类任务对约束满足的要求最高。第四类是校验修正型任务，给一段有问题的结构化数据让模型找错并修复，评测看的是错误定位精度和修复后的合法性。这四类任务对模型能力的要求差别很大，用同一套指标去衡量容易失真。
我在实际评测里会先把任务归到某个形态和谱系交叉的位置上，再去选数据集和指标。比如“嵌套JSON抽取”和“SQL生成”虽然都叫结构化输出，前者更依赖信息定位能力，后者更依赖逻辑推理和语法正确性，指标权重设计上就得区别对待。不把形态和谱系理清楚，后面的评测框架就是空中楼阁。
1.3 评测总体框架：数据集、指标、流程与结论
我搭评测框架的习惯是从结论倒推。先想清楚这份评测报告要回答什么问题，是选型对比、上线准入、版本回归还是失效归因，不同目的对应的框架重心完全不一样。选型对比看重区分度和稳定性，上线准入看重底线指标的硬约束，版本回归看重指标波动的敏感度，失效归因看重细粒度错误分类。框架的四个支柱——数据集、指标、流程、结论——得围绕这个目的来组织，不能反过来被现成的工具和数据集牵着走。
数据集这一块我关注三件事：覆盖面、难度梯度和泄漏风险。覆盖面不是越大越好，得跟目标任务谱系对齐，抽取出问题和SQL生成问题要分开建集。难度梯度要显式设计，简单样本保证基线可跑通，中等样本拉开模型差距，困难样本和对抗样本探测能力边界。泄漏风险是很多团队踩过的坑，公开数据集里的样本可能已经进了模型训练语料，测出来的分数虚高，我一般会用时间切分和改写扰动来做泄漏检测。指标设计上我倾向分层组织：格式合法性作为门禁指标，不达标直接判负；内容准确性作为核心指标，按字段级和记录级分别统计；结构一致性和约束满足作为质量指标；鲁棒性和效率成本作为工程指标。每层指标之间要有明确的优先级和组合规则，不能把所有指标简单平均成一个总分，那样会掩盖关键失效。
流程设计上自动化校验器承担大部分重复工作，Schema校验、类型检查、约束验证这些能规则化的部分尽量交给工具。人工复核聚焦在自动化覆盖不到的地方，比如语义合理性、边界案例的判断、错误归因的定性分析。结论输出我坚持“总分+分项+典型失效案例”的结构，总分给决策者看，分项给技术团队定位问题，失效案例给后续迭代提供具体靶子。三个部分缺一不可，只给总分的报告基本没法用。
1.4 评测价值、适用场景与总分式组织逻辑
结构化输出评测的价值不在于打出一个漂亮分数，而在于把“模型能不能可靠地接入业务系统”这个问题变成可量化、可追踪、可复现的判断。我经历过好几次这样的场景：业务方觉得模型效果挺好，因为人工看几条输出都像模像样，结果批量跑一遍评测，字段缺失率18%、枚举越界率7%、嵌套结构错误率12%，这些数字一摆出来，讨论焦点立刻从“感觉行不行”转到“哪类错误优先修”。评测的另一层价值是建立团队内部的共同语言，大家对着同一套指标和同一批案例讨论问题，沟通成本会低很多。
适用场景上我划分成三类。研发迭代场景下评测是探针，关注的是细粒度指标变化和失效模式迁移，报告频率高、颗粒度细。上线准入场景下评测是闸门，关注的是底线指标是否达标、关键场景是否覆盖、极端输入下是否稳定，结论要给出明确的通过或不通过。运营监控场景下评测是仪表盘，关注的是线上分布漂移、回归风险和成本波动，通常跟持续评测和版本追踪机制配合使用。三类场景共用一套框架但用不同的配置和阈值，混在一起做容易两头不讨好。
总分式组织逻辑是我比较推荐的一种报告结构，但得分清楚“总”和“分”各自承担什么职责。总分用来回答“整体处于什么水平、跟基线比有没有进步”，适合放在报告开头给决策层快速浏览。分项用来回答“强在哪、弱在哪、哪类任务拖了后腿”，通常按任务类型、结构复杂度、错误类别三个维度展开。我还会在分项里保留一组“门禁指标”单独展示，比如Schema合法率和关键字段准确率，这两项不参与总分加权，直接以硬性红线的方式呈现。这么组织的好处是既有一个可比较的整体分，又不会让关键底线问题被平均分稀释掉。实际操作中总分和分项偶尔会出现背离，比如总分涨了但门禁指标掉了，这种情况恰恰是最需要深挖的信号，报告里得把它标出来而不是藏起来。
2.1 数据集类型、任务覆盖与场景分层
我做结构化输出模型评测数据集，习惯先按任务类型切一刀。抽取型数据集最常见，给一段客服对话或者商品描述，让模型把姓名、电话、订单号、规格参数填进指定Schema，评的是信息定位和字段召回。转换型数据集处理的是结构到结构的映射，自然语言转SQL、XML转JSON、表格转实体关系，这类样本对语法正确性和映射规则要求高。生成型数据集更考验约束满足，模型得从接口文档或者业务规则出发，从零构造完整请求体、配置清单。校验修正型数据集给的是带缺陷的结构化数据，模型要定位错误并修复，错误类型覆盖字段缺失、类型错位、枚举越界、关系断裂。四类数据集我一般分开建，混在一起测出来的分数没法解释。
任务覆盖上我不追求大而全，更看重覆盖矩阵跟目标场景对齐。矩阵横轴放Schema复杂度，从扁平键值对到多层嵌套再到多表关联；纵轴放领域，通用、电商、金融、政务、医疗各占一块。每个格子里的样本量不要求平均，业务重心在哪就多放一些。我通常会配三套集：核心能力集用来横向比模型，规模中等、难度均匀；扩展场景集贴着业务线走，样本更真实也更脏；红线集只放底线案例，比如空输入、超长文本、特殊字符、枚举边界，数量不多但每次评测必跑。三套集职责分清，报告里才不会把能力问题和场景问题搅成一锅粥。
场景分层是我踩过坑之后才重视起来的。实验室基准集追求可复现，输入输出都经过清洗，适合做模型选型；上线准入集要带真实分布，噪声、缺失、格式混乱都得保留，判断的是能不能扛住生产环境；线上回归集跟着版本走，样本随业务变化滚动更新，关注的是指标漂移和失效模式迁移。三层数据集共用一套Schema规范，标注口径保持一致，版本号独立管理。我见过团队拿实验室集的数据去评估线上稳定性，结论偏乐观，上线后被打脸。场景分层这件事，偷懒省下来的时间后面都得加倍还回去。
2.2 数据构建流程、标注规范与Schema设计
数据构建我一般从需求拆解开始，先把业务方嘴里的“结构化输出”翻译成字段清单、类型约束、枚举范围、字段依赖关系。这一步偷懒，后面标注和校验全是返工。种子样本来源有三路：真实业务日志脱敏、公开数据改写、大模型合成加人工校验。真实日志最贴分布，脱敏成本高；公开数据省事，领域匹配度经常不够；合成数据灵活，容易带模型自身偏差。我的配比通常是真实为主、公开为辅、合成做长尾补充，合成样本必须过人工复核才能进正式集。
标注规范得写到字段级。每个字段要有明确定义、取值边界、多值处理规则、空值语义、单位约定。举个例子，“金额”字段要写清楚含税还是不含税、币种怎么标、小数保留几位；“时间”字段要约定时区和格式。标注员拿到的不能只是一份Schema文件，还得有正例、反例、边界案例对照表。一致性检验我习惯抽10%到15%做双人标注，算字段级一致率，低于阈值就回炉重训标注员。Schema设计上我倾向“收敛但不僵硬”：字段名语义清晰、类型尽量收窄、枚举能封闭就封闭、嵌套深度控制在三层以内、跨字段约束显式写出来。Schema太宽松，模型随便填都能过格式校验，评测就失去了区分度；Schema太死板，真实场景里的合理变体全被判错，结论又会偏悲观。
流程走到Schema冻结这一步，我会拉一次小规模试标，拿二十来条样本跑通标注、校验、入库全链路，确认工具链没问题再放量。版本管理用“主版本+修订号”，Schema变更、标注规则变更、样本增删都得留记录。我吃过亏，两版评测集混着用，分数涨了三个点，查了半天发现是新版把最难的那批样本删了。数据构建这事没有捷径，流程里的每个检查点都是用来兜底的。
2.3 难度分层、对抗样本与边界案例设计
难度分层我按四个档位来设计。L1是结构清晰、字段少、无干扰的基础样本，保证基线模型能跑通，主要看格式合法性。L2加干扰项，同名字段、近义枚举、多值并列，看模型能不能准确对应。L3上复杂度，长文本、多层嵌套、跨字段约束，比如订单总额等于明细之和、开始时间早于结束时间。L4是对抗档，专门设计容易让模型犯错的陷阱。每档样本量按金字塔配，L1和L2占大头，L3适度，L4少量但每一条都有明确的失效假设。难度不显式分层，评测报告只能给出一个平均分，看不出模型到底卡在哪一级。
对抗样本的设计我总结了几类常用手法。字段名撞车，输入里同时出现“收货人电话”和“下单人电话”，看模型会不会串字段。单位混用，金额有的写“元”有的写“万元”，时间有的带时区有的不带。枚举陷阱，放几个语义相近但不在枚举列表里的值，测模型会不会硬填。嵌套错位，把本应放在明细层的字段提到外层，看结构还原能力。长尾实体，生僻地名、特殊符号、超长编号，测鲁棒性。每类对抗样本我都要求标注预期错误类型，评测时不仅能统计错多少，还能归因到错在哪类机制上。
边界案例是另一条线。空输入、全空白、超长文本、多语言混排、特殊字符、重复键、循环引用、Schema本身有歧义，这些样本平时遇不到，生产环境里一出就是事故。我一般单独建一个边界集，规模控制在总样本量的5%到10%，不参与总分加权，作为门禁项单独报告。边界案例的设计原则是可解释，每条样本都要写清楚“这条在测什么”“什么样的输出算通过”“失败对应什么风险”。写完自己跑一遍，如果连人工标注都拿不准通过标准，这条样本就该回炉重造。
2.4 数据质量、版权合规与泄漏控制
数据质量我盯几个硬指标：标注一致率、Schema合法率、字段覆盖率、重复率、分布偏差。标注一致率靠双标抽样，低于0.85就停下来查规则。Schema合法率是拿校验器把全量样本过一遍，确保参考答案本身不违规。字段覆盖率看每个字段在样本里的出现频次，长期为空或者长期满值的字段要单独审查。重复率用精确匹配加语义相似度两道筛，近重复样本对评测区分度伤害很大。分布偏差拿业务真实分布做对比，领域、长度、难度三个维度都要看。质量检查我倾向做成流水线，每次数据集版本发布自动跑，报告存档。
版权合规这块不能等法务找上门才想起来。公开数据集先看License，商用限制、署名要求、衍生作品条款都得读清楚。真实业务数据脱敏要彻底，姓名、电话、身份证、地址这些直接标识符替换掉，准标识符做泛化处理。合成数据注意别把训练语料原样吐出来，生成后过得检。采购的数据要留合同和授权范围记录。我自己的习惯是每个数据集配一份“数据卡片”，写清楚来源、许可、脱敏方式、使用限制、联系人，团队内部谁用谁查得到。
泄漏控制是结构化输出评测里特别容易被低估的环节。公开数据集里的样本很可能已经进了模型预训练语料，测出来的分数虚高。我一般做三重检测：时间切分，用模型训练截止日期之后发布的样本；n-gram重叠检测，看评测样本和已知训练语料的重合度；语义相似度检索，拿评测样本去模型侧做近邻查询。还可以埋canary字符串，看模型会不会原样复现。评测集本身也要做访问控制，核心集不公开、不进共享盘、不贴到聊天工具里。版本发布走审批，谁能看、谁能下载、谁能改，权限分清。泄漏这事一旦发生，整份评测报告的公信力就没了，防的成本远低于事后补救。
2.5 典型公开数据集盘点与选型建议
公开数据集我平时会维护一个清单，按任务类型归档。信息抽取类常看CoNLL、ACE、FewNERD，实体和关系标注比较规范，适合做抽取型基线。表格理解类看WikiTableQuestions、TabFact，表格结构还原和事实验证都能用上。Text-to-SQL方向Spider和BIRD是绕不开的，Spider的Schema复杂度适中，BIRD的数据库更贴近真实业务，难度也更高。函数调用和工具调用方向可以看BFCL、API-Bank、ToolBench，这几套集对参数结构、调用顺序、嵌套对象的覆盖比较全。知识图谱生成方向WebNLG用得比较多，三元组到自然语言的映射关系清晰。JSON生成方向专门的公开集不算多，我一般拿函数调用集和API描述集改造，或者用JSONSchemaBench这类较新的基准做补充。清单不是固定的，新集出来我会先小样本试跑，看任务定义和标注质量再决定要不要纳入。
选型的时候我看五件事。任务匹配度排在最前，数据集的输出形态跟我目标Schema差太远，迁移成本会很高。Schema可迁移性看字段命名习惯、嵌套风格、约束表达方式，越接近业务规范越好用。难度分布要能拉开模型差距，全是简单样本的集测不出能力边界。许可和维护活跃度也得看，没人维护的集很快会过时，License不清的集不敢商用。污染风险前面说过，训练截止日期早、网上流传广的集要格外小心。
我的组合策略是“公开集做横向、自建集做纵向”。公开集用来跟外部结果对齐，看看模型在社区基准上处于什么位置；自建集贴着业务场景，用来做版本回归和上线准入。公开集分数高不代表业务能用，自建集分数稳才敢往生产推。选型时别只盯榜单排名，榜单前列的模型在自己的Schema上翻车是常事。拿三到五套公开集做初筛，再用自建核心集做复筛，两轮下来基本能筛掉大部分不合适的选项。数据集选对了，后面的指标和流程才有意义。
3.1 格式合法性与Schema符合度指标
格式合法性听起来是最基础的一关，我实际搭评测指标时发现它比想象中细。最粗的一层是解析通过率，拿JSON.parse或者对应的Schema解析器跑一遍，能解析就算过。这一层看着简单，生产环境里模型输出带markdown代码块标记、前后加解释性文字、转义字符没处理干净的情况不要太多。我一般会把这个指标拆成三个递进的档：解析成功率、Schema校验通过率、严格模式通过率。严格模式要求没有额外字段、没有类型漂移、没有空值滥用，三档分开报，才能看出模型到底是完全不会还是只差最后一公里。
Schema符合度指标我通常按字段维度展开。字段存在率看该出现的字段有没有出现，字段类型正确率看值类型对不对，枚举命中率看模型有没有在给定列表里选，必填字段完整率看有没有漏填。这几个指标我习惯做成一张表，每个字段一行，模型一列，一眼就能看出薄弱环节在哪。有的模型整体格式合法率能到95%以上，拆到字段级发现枚举命中率只有七成，问题就暴露出来了。
嵌套结构的符合度要单独拎出来测。我见过不少模型扁平结构填得漂漂亮亮，一遇到两层以上的嵌套就开始丢层级、错放字段、把数组写成对象。嵌套深度指标我按层级分别统计，第二层字段完整率、第三层字段完整率分开看。还有一个我比较在意的指标是“结构漂移率”，对比模型输出和参考结构的树形骨架，计算节点路径的编辑距离，能捕捉到那种格式合法但结构走形的情况。这种错最隐蔽，光看解析通过率根本发现不了。
3.2 内容准确性与字段级匹配指标
内容准确性这块我分两个视角来评。一个是字段级的精确匹配，参考答案是什么，模型输出就得是什么，适合枚举、编号、日期这类有标准答案的字段。另一个是语义级匹配，用规则或者小模型判断模型填的内容和参考答案是不是一个意思，适合描述性字段、地址、名称这类允许合理变体的场景。两个视角的指标我分开报，精确匹配率给业务方看底线，语义匹配率给自己看模型的上限。
字段级匹配我一般按字段类型配不同的判定方法。字符串精确匹配、数值容差匹配、日期格式归一后匹配、枚举集合包含匹配、多值字段用集合的精确率召回率F1。金额字段我还会加一个数值误差分布，看看错的是小数点位置还是四舍五入。时间字段看时区处理对不对、格式归一后差多少。这些细分指标让报告从“准确率87%”变成“准确率87%，主要错在金额单位换算和时间时区偏移”，后者才对排查有用。
我特别看重的一个指标是“字段级错误分布”。把错误按字段归类，算每个字段的错误占比，再跟字段在样本里的出现频率做交叉。高频字段错误率高，说明模型基础能力有问题；低频字段错误率高，可能是长尾覆盖不够。还有一类错误值得单独统计：字段串位。模型把A字段的值填到了B字段里，这类错误在字段名相似的时候特别常见。我会在评测集里专门放一批字段名相近的样本，统计串位率，这个指标比整体准确率更能反映模型对Schema语义的理解深度。
语义匹配这块我踩过坑。早期用BERT相似度做判定，阈值定在0.85，结果模型把“北京市朝阳区”写成“北京朝阳”被判错，人工一看明明是对的。后来改成规则加人工抽检双轨，规则覆盖格式归一、缩写展开、同义词表，剩下拿不准的走人工。语义匹配的指标我不追求全自动，宁可慢一点也要保证结论可信。评测报告里我会标明语义匹配的人工复核比例，透明比好看重要。
3.3 结构一致性、关系完整性与约束满足指标
结构一致性评的是模型输出作为一棵树或者一张图，形态对不对。我常用的指标包括父子关系正确率、兄弟节点顺序正确率、数组元素类型一致率、空节点处理正确率。父子关系正确率看的是该挂在父节点下的子节点有没有挂对位置，这个指标在多层嵌套里特别能暴露问题。兄弟节点顺序有些Schema有明确要求，比如明细行按时间排序，顺序不对就算结构错。空节点处理看模型面对可选字段是全填null、直接省略、还是填个空字符串，不同Schema要求不一样，模型得跟着Schema走。
关系完整性是结构化输出里容易被忽视的一维。单条记录填得再准，记录之间的引用关系断了，整体还是废的。我一般会在Schema里显式定义外键或者引用字段，评测时检查引用目标是否存在、引用方向对不对、一对多关系里子记录数量是否匹配。举个例子，订单和订单明细，明细里的订单号必须能在订单头里找到，明细条数要和订单头里的统计字段对得上。这类跨记录约束我在评测集里会专门构造样本，指标上算“关系完整率”和“引用有效率”。
约束满足指标我按约束类型分开统计。数值范围约束、字符串长度约束、正则模式约束、枚举封闭约束、跨字段逻辑约束，每类算一个满足率。跨字段逻辑约束最考验模型，比如开始时间必须早于结束时间、折扣后价格不能高于原价、子分类必须属于父分类的枚举范围。我会在评测集里放一批故意带逻辑陷阱的样本，看模型是只顾填不管逻辑，还是能主动做一致性检查。约束满足率这个指标我一般不跟格式合法率混在一起加权，它更像是质量门禁，格式过了约束没过，输出照样不可用。
还有一类指标我管它叫“结构稳定性”，同一个输入换个提示词措辞或者换个温度参数，输出结构会不会大幅波动。具体做法是对每条样本跑三到五次，比较结构骨架的相似度，算结构一致率。这个指标对评估模型能不能上生产特别关键，业务系统对接的是稳定的Schema，模型每次输出结构都在漂移，下游根本没法解析。结构稳定性差的模型，格式合法率再高我也不敢推荐。
3.4 鲁棒性、稳定性、效率与成本指标
鲁棒性指标我围绕“扰动下的表现保持率”来设计。输入侧加噪声，错别字、多余空格、中英文混排、特殊符号、超长文本，看模型输出质量下降多少。Schema侧做扰动，字段顺序打乱、可选字段增删、枚举顺序变化，看模型能不能稳住。提示词侧换措辞、换语言、加干扰指令，看模型对指令变化的敏感度。每个扰动维度算一个保持率，跟基线分数比，掉分幅度超过阈值的模型在鲁棒性这一栏就要标红。
稳定性我分短期和长期两个口径。短期稳定性看同一版本模型在相同输入上的输出波动，跑多次算方差。长期稳定性看模型版本迭代过程中指标漂移，这需要持续评测机制配合，每次发版跑同一套核心集，画趋势线。我见过模型升级后整体分数涨了，但某个关键字段的准确率悄悄掉了五个点，没有版本追踪根本发现不了。稳定性指标我建议至少按月出一次报告，波动超过两个标准差就得触发排查。
效率指标在结构化输出场景里权重比通用任务高。首Token延迟、完整输出耗时、每秒输出token数，这三个是基础项。结构化输出还有几个特有指标：有效输出率，就是输出里真正符合Schema的部分占多少，模型如果前半段合规后半段跑飞，有效输出率会很低；重试率，格式不合法需要重新请求的比例；截断率，输出超过长度限制被截断的比例。这几个指标直接关系到业务系统的可用性，我一般会把它们放在跟准确率同等重要的位置。
成本指标我按“每条有效结构化输出成本”来算。把token消耗、重试消耗、人工复核成本加在一起，除以成功产出合规输出的条数。这个指标比单看token单价有意义得多，一个便宜但老要重试的模型，单位成本可能比贵但一次过的模型还高。我还会算一个“成本效率比”，用准确率除以单位成本，用来做模型选型的排序参考。业务方对成本敏感的时候，这个指标比纯准确率更有说服力。
3.5 指标组合、权重设计与统计显著性分析
指标组合这件事没有标准答案，我的原则是分层加权、场景定权。基础层放格式合法率和Schema符合度，这两项不达标后面不用看，我一般设成门禁项，不参与加权直接卡通过。能力层放内容准确性和结构一致性，这两项按业务场景调权重，抽取型任务准确性权重大，生成型任务结构一致性权重大。保障层放鲁棒性、稳定性和效率成本，权重相对低但不可省略。三层分开算分再汇总，比把所有指标扔进一个公式里更可控。
权重设计我习惯拉业务方一起定，不自己拍脑袋。做法是把指标清单摆出来，让业务方做两两比较，导出权重向量，再跟自己预设的权重对一遍，差异大的地方重点讨论。有一次业务方把枚举命中率的权重定得特别高，聊下来才知道他们下游系统对枚举值做硬校验，枚举错一个整条数据就废了。这种信息不问根本不知道。权重定完我会写进评测协议，版本化管理，改权重得走变更记录，不然两版报告没法比。
统计显著性分析是很多评测报告缺失的一环。两个模型准确率差一个点，样本量只有两百条，这个差异很可能就是噪声。我一般会算置信区间，比例类指标用Wilson区间，连续类指标用bootstrap重采样。模型对比的时候做配对检验，同一批样本上跑两个模型，用McNemar检验看差异是否显著。样本量规划我也会提前做，根据预期效应量和显著性水平反推需要多少条样本，避免测完了才发现样本不够、结论站不住。
多重比较的问题我也遇到过。一次评测比了八个模型、十五个指标，挑最高的那个报出去，看着很漂亮，实际上有一半的“显著”是碰运气碰出来的。后来我改成对p值做校正，或者干脆在报告里明确标注哪些对比是探索性的、哪些是验证性的。评测报告的公信力靠这些细节撑着，指标算得再花哨，统计上不严谨，结论就经不起推敲。我现在的习惯是每份报告附一个统计附录，写清楚样本量、检验方法、置信区间和校正方式，谁想复核都能照着来。
4.1 评测目标拆解与评测协议设计
我拿到一个结构化输出评测需求，从来不急着跑模型。先坐下来把问题拆清楚：这次评测到底要回答什么。是选型，看哪个模型能接住业务场景；是验收，确认某模型版本达标了没有；还是诊断，搞清楚现有系统到底烂在哪个环节。三种目标对应的评测协议完全不一样。选型要宽覆盖、比多个模型、指标全；验收要窄口径、对准业务SLA、门禁清晰；诊断要深挖特定字段和失效模式，样本可以少但要精。目标没拆清楚就开测，最后跑出一堆数字，没人知道该拿它干什么。
拆完目标我会写一份评测协议，这东西像实验的操作手册。里面固定几件事：评测对象是谁、数据集版本和抽样方法、每个指标的定义和计算口径、通过阈值和门禁项、实验分组和对照方案、报告模板和统计附录要求。协议写完先拉相关方过一遍，特别是业务方和下游系统的负责人。我吃过亏，评测做完才发现下游对某个字段的格式有硬性要求，评测集里压根没覆盖，整轮白跑。协议里我还会写清楚“不测什么”，边界划明白，后面扯皮少。
协议版本化了再动手。每改一次评测集、每调一次权重、每换一个校验器实现，都记一笔变更日志。这件事听着官僚，真到两版报告数字对不上时，变更日志就是救命的东西。我现在的习惯是评测协议和数据集版本号绑在一起，报告抬头写明“基于协议v2.3、数据集v1.7”，任何人拿着这两个版本号都能复现我的评测结果。
4.2 提示词、解码约束、基线模型与对照设置
提示词在结构化输出评测里是个巨大的变量。同一个模型，系统提示词写“请输出JSON”和写“输出必须严格遵循以下Schema，不得包含任何额外字段和解释文字”，格式合法率能差十几个点。我做评测时的做法是固定一套提示词模板，模板分三块：角色和任务说明、Schema内联描述、输出格式约束。Schema描述我用机器可读的形式直接贴进去，字段名、类型、枚举值、必填性全带上，不让模型去猜。提示词模板也版本化，换模板等于换实验条件，得单独记一笔。
解码约束这块我分两种实验设置来跑。一种叫“裸跑”，什么约束都不加，看模型原生能力；另一种叫“约束跑”，开JSON mode、开语法引导解码、开Schema校验重试。两种设置各跑一套结果，报告里并列呈现。裸跑看模型上限，约束跑看工程可用性。有些模型裸跑格式合法率才七成，开了约束能到九成九，那它的差距就在工程配套上，不在模型本身。我把这个差异叫“约束增益”，选型时会把它当独立指标看。
基线模型和对照设置我按三层来配。第一层是“地板基线”，拿一个规则模板或者最简单的prompt工程方案跑一遍，确保任何模型都得比它强，不然上模型没意义。第二层是“同代对照”，选两到三个同量级的主流模型，同数据集同提示词同解码设置跑，做横向比较。第三层是“历史对照”，把上一版生产模型的结果拉进来，看新版本到底涨没涨。三层对照的结论分开放，不混着说。我见过报告只跟地板基线比，显得提升巨大，跟同代模型一比其实平平无奇，这种报告拿去做决策就是误导。
温度参数和采样策略我固定成两组。确定性评测用temperature=0，保证可复现，这是主报告用的设置。鲁棒性评测用temperature=0.7跑多次，看输出波动，这是稳定性分析的设置。两组设置分开报，不混。解码约束和采样策略的组合我一般控制在四到六种实验条件以内，条件太多样本量摊薄，统计上撑不住。实验矩阵设计我遵循“主效应优先”的原则，先把每个因素的单独影响测清楚，交互效应留到第二轮再挖。
4.3 自动化评测工具、校验器与人工复核机制
自动化评测工具链我一般搭三层。最底层是解析和校验层，JSON解析器、JSON Schema校验器、正则校验器、类型检查器，这一层用现成的库就行，不自己造轮子。中间层是指标计算层，字段级匹配、结构比对、约束检查这些逻辑自己写，每个指标一个独立函数，输入是模型输出和参考答案，输出是结构化结果。最上层是调度和报告层，负责批量跑模型、汇总结果、生成报告。三层解耦的好处是换模型不用动指标逻辑，加指标不用动调度。
校验器这块我得多说两句。JSON Schema校验器有不同实现，对同一份Schema的严格程度不一样，有的对additionalProperties默认放行，有的默认拦截。我踩过这个坑，两个校验器跑同一批输出，通过率差五个点。后来我把校验器实现也写进评测协议，固定版本、固定配置，报告里注明用的哪个库哪个版本。对Schema本身的写法我也统一规范，必填项显式声明、枚举封闭、类型不允许联合类型模糊处理，Schema写松了，校验器再严也白搭。
人工复核机制我按“抽检加仲裁”来设计。自动化指标跑完，按比例随机抽一批样本人工过一遍，抽检比例一般百分之五到百分之十，关键字段和争议样本提高比例。抽检的作用有两个：一是校准自动化指标，看机器判的对不对；二是发现自动化没覆盖的失效模式。我还会设一个仲裁流程，自动化判定和人工判定不一致的样本进仲裁池，由第二个人独立判，两个人不一致就拉第三人。仲裁结果回流到评测集，变成新的标注样本，下一轮评测用。这个闭环跑起来，评测集的标注质量会一轮比一轮高。
语义匹配这块我坚持人工兜底。规则能覆盖的走规则，规则拿不准的走人工，人工判完的结果反哺规则库。我不追求语义匹配全自动，追求的是每个自动判定都能追溯到依据。报告里我会标每个指标的自动化覆盖率，覆盖率低的指标旁边加星号，提醒读者谨慎采信。透明比好看重要，这句话我在上一章说过，这里还得再说一遍。
4.4 实验分组、误差分析、失效归因与报告规范
实验分组我按“场景×模型×设置”三维来切。场景维度按业务任务类型分，抽取型、生成型、转换型各一组，每组样本独立抽样，互不重叠。模型维度按参评模型分，每个模型一个组。设置维度按提示词模板和解码约束的组合分，主设置一组，鲁棒性设置若干组。分组切完算样本量，每个格子至少保证统计上能看出中等效应，样本不够就合并格子或者砍设置，不硬撑。
误差分析我从三个角度看。第一个是错误类型分布，把错误按格式错、字段错、结构错、约束错、语义错分类统计，看主要矛盾在哪。第二个是错误集中度，看错误是不是集中在少数几个字段或者少数几类样本上，集中度高说明问题局部化，好修；分散说明模型基础能力有短板。第三个是错误与样本特征的交叉分析，按输入长度、嵌套深度、字段数量、枚举规模分组算错误率，画出来看趋势。这三张图放在报告里，比一张总准确率表信息量大得多。
失效归因我分四层往下钻。第一层看是不是提示词问题，换一版更明确的提示词重跑，如果好了就是提示词背锅。第二层看是不是解码约束问题，开约束重跑，好了就是工程配套没跟上。第三层看是不是模型能力问题，同类任务换个模型跑，都差就是任务本身难，个别差就是模型短板。第四层看是不是数据问题，把错例拿出来人工看，参考答案本身有没有标错、Schema有没有歧义、样本有没有对抗性过强。归因到第四层还找不到原因，我就把这批样本挂起来，进“未解释失效池”，下一轮评测重点盯。
报告规范我定了几条硬规矩。报告开头必须写清楚评测目标、数据集版本、协议版本、参评模型版本和实验设置。主结论放最前面，一段话说清楚谁赢了、赢多少、统计上显不显著。指标表格按分层组织，门禁项、能力项、保障项分开列，不混排。每个指标后面附置信区间和样本量。失效分析单独一章，图放前面、解释放后面。统计附录必须有，写清楚检验方法、多重比较校正方式、效应量。报告末尾附可复现性说明，任何读者拿着版本号和协议都能重跑。这几条规矩执行下来，报告从“看着挺专业”变成“经得起审”。
4.5 持续评测、版本追踪与回归测试机制
持续评测这件事我从第一天搭评测体系就规划进去。一次性评测像体检，持续评测像戴手环。我的做法是维护一套“核心评测集”，规模不大但覆盖关键场景和关键字段，每次模型版本迭代、提示词改动、校验器升级都跑一遍，结果进趋势库。核心集之外再维护“扩展评测集”，规模大、覆盖全，按月或者按季度跑一次。核心集保频率，扩展集保广度，两套配合着用。
版本追踪我追三个东西：模型版本、评测集版本、协议版本。三个版本号绑在一起形成一个“评测快照”，每次跑完存一份快照。快照之间的指标差异自动算出来，涨了跌了都标出来。我还会给每个指标设一个“波动带”，历史均值上下两个标准差，新结果掉出波动带就触发告警。告警分两级，轻度告警进周报观察，重度告警拉相关人排查。这套机制跑起来之后，模型升级悄悄掉点的情况基本藏不住。
回归测试我从软件测试那边借了个思路，建“黄金样本集”。挑一批输出稳定、判定明确的样本，每条样本固定参考答案和判定逻辑，任何改动之后跑这批样本，结果必须跟基线完全一致，不一致就说明改动引入了非预期变化。黄金集覆盖格式合法性、字段匹配、结构一致性、约束满足这四类判定，每类至少几十条。回归测试我放在CI流程里，模型或者评测代码合入主干之前自动跑，不过不合并。这件事前期投入大，跑顺了之后省下的排查时间远超投入。
版本对比报告我做成固定模板，新旧两版并排，每个指标一行，涨跌用颜色标，统计显著性用星号标。报告自动生成，人只需要写一段解读。解读里我会重点看三件事：门禁项有没有退化、核心字段准确率有没有漂移、成本效率比有没有恶化。这三件事任何一件出问题，版本就不能直接上，得走人工评审。持续评测的价值不在数字本身，在于让每个版本变更都有据可查、有迹可循。评测体系建到这一步，才算是从“做一次评测”变成“有评测能力”。
5.1 主要挑战、常见失效模式与评测陷阱
结构化输出评测这件事，坑比我想的多。最大的挑战是Schema漂移。业务方改需求，Schema跟着变，评测集里的参考答案还是旧的，跑出来的准确率全是假的。我见过一个项目，模型输出跟Schema完全对得上，业务方验收也过了，上线三个月后发现字段语义变了，下游系统天天报错。Schema不只是字段名和类型，字段背后的业务含义才是关键。评测集里的参考答案得跟Schema版本绑死，Schema一改，参考答案全量复核，该重标的重新标。
失效模式里最隐蔽的是“格式合法但内容错位”。JSON解析没问题，Schema校验也过，每个字段都有值，但值填错了字段。比如订单场景里“收货地址”和“账单地址”搞混了，两个字段都是字符串，格式全对，内容全错。自动化校验器抓不到这种错，得靠字段级语义匹配。我现在的做法是对关键字段建“值域约束”，地址字段得匹配地址格式，金额字段得在合理区间，日期字段得符合业务逻辑。值域约束一加，字段错位能捞出来一大半。
评测陷阱里排名第一的是“评测集过拟合”。模型迭代几轮之后，评测集里每条样本都被“见过”了，指标蹭蹭涨，换个新数据集原形毕露。我防这件事的办法是维护一个“暗评测集”，不参与任何调优，只在版本验收时跑一次。暗评测集规模不用大，覆盖关键场景就行。另一个陷阱是“指标好看但业务不可用”。格式合法率百分之九十九，但剩下那百分之一的失败样本全是关键业务字段，上线照样出事。评测指标得跟业务SLA对齐，关键字段的失效率单独设门禁，不跟全局指标混着看。
还有个坑是“评测环境跟生产环境不一致”。评测时用的提示词、解码参数、后处理逻辑，跟生产环境差一截，评测结果压根迁移不过去。我现在做评测，提示词模板直接从生产配置里拉，解码参数跟生产对齐，后处理逻辑用同一套代码。评测环境跟生产环境的一致性得写进协议，每次评测前核对一遍。
5.2 多模态输出、复杂Schema与长结构评测扩展
多模态结构化输出这块，评测方法还很不成熟。文本加表格加图片的混合输出，Schema里得定义跨模态的引用关系，比如“表格第三行对应的图片区域”。这种Schema的合法性校验本身就复杂，更别说内容准确性了。我现在的做法是把多模态输出拆成单模态分别评，文本部分按常规Schema评，表格部分按单元格级匹配评，图片区域按坐标IoU评，拆完再算一个跨模态一致性得分。拆着评的好处是每个模态的失效模式看得清楚，坏处是跨模态的交互错误容易漏。跨模态引用错误得单独建一套校验规则，比如文本里提到“见下图”但输出里没有图片，这种错只能靠规则抓。
复杂Schema的评测难度随嵌套深度指数上升。三层嵌套的对象数组，每层都有必填字段和枚举约束，模型输出一长就容易丢字段或者层级错乱。我测过几个主流模型，两层嵌套的Schema符合率普遍在九成以上，到四层嵌套直接掉到六成。复杂Schema评测得按嵌套深度分层出样本，每层单独算指标，不然一个全局数字把深层的问题全盖住了。枚举规模也是个变量，字段枚举值从五个涨到五十个，格式合法率能掉十几个点。评测集里枚举规模得拉开分布，别全挤在小枚举上。
长结构输出是另一个硬骨头。几千个token的JSON数组，模型输出到后半段容易“忘了”开头的约束，字段名漂移、类型突变、括号不匹配全来了。长结构评测我按输出长度分桶，短中长三档分别算指标。长度超过一定阈值之后，我还会检查“结构衰减点”，就是输出从哪个位置开始出错率陡增。这个位置跟模型上下文窗口、训练数据分布都有关系，测出来对业务选型很有参考价值。长结构评测的解码约束也得特殊处理，有些语法引导解码器在长输出上性能断崖下跌，评测时得把解码器版本和配置一并记录。
层级关系的一致性评测在复杂Schema里权重得调高。父子节点的引用关系、数组元素的顺序约束、条件必填字段的依赖逻辑，这些结构约束错了，内容再对也没用。我现在的评测框架里，结构一致性指标单独算一个分，跟内容准确性并列报，不混成一个总分。混成一个总分之后，结构错和内容错互相稀释，看不出问题在哪。
5.3 评测基准、排行榜与社区协作建设
公开评测基准我用得不少，但从来不盲信。基准的价值在于横向比较和快速摸底，局限在于跟业务场景的匹配度。一个在通用JSON抽取基准上刷到九十五分的模型，放到金融报表结构化场景里可能连八十分都不到。我用公开基准的方式是“两段式”：先用公开基准筛一轮，把明显不行的模型淘汰掉；再用自建业务评测集做精细比较。公开基准的分数只做参考，不做决策依据。选型报告里我会写清楚“公开基准排名第几、业务评测集排名第几”，两个数字并列，让读者自己判断。
排行榜这件事我有自己的看法。排行榜能推动社区进步，但也容易催生“刷榜”行为。模型在榜上分数高，拆开看可能是在特定题型上过拟合了。我看排行榜的习惯是看“分项指标”和“失败案例”，不看总分排名。分项指标的分布比总分更能说明模型的能力结构，失败案例比成功案例更能暴露模型的短板。社区要是能把失败案例库建起来，价值比排行榜本身大得多。
社区协作建设这块，我参与过几个开源评测项目的共建，感受挺深。数据标注的规范统一是最难的事，不同团队标出来的参考答案口径不一致，拼在一起没法用。后来我们定了一套标注指南，每个字段的判定标准写清楚，边界案例给示例，标注员先培训再上岗，标完抽检，一致性系数低于阈值就打回重标。这套流程跑顺之后，跨团队拼数据集才成为可能。Schema定义的标准化也得靠社区推，各家自定义Schema的写法五花八门，互操作成本极高。要是能出一个Schema描述的最佳实践规范，评测工具的复用性会上一个大台阶。
开源评测工具链的共建我觉得比数据集共建更容易见效。校验器、指标计算库、报告模板这些东西，各家需求差不多，重复造轮子浪费。社区集中力量维护一套高质量的工具链，各家在上面做业务适配层，效率高很多。我现在用的校验器和指标库就是从开源项目里拿的，自己只写了业务特定的那部分逻辑。工具链的版本管理得跟上，开源项目发版节奏快，评测协议里得锁死工具链版本，不然复现性没法保证。
5.4 面向业务落地的评测策略与治理建议
业务落地场景的评测，跟学术评测完全两个思路。学术评测追求指标全面、对比公平，业务评测追求“能不能上线、上线后会不会出事”。我现在做业务评测，第一件事是跟业务方一起定“上线门禁”。门禁项一般三到五条，每条都是硬指标，比如“关键字段准确率不低于百分之九十五”“格式合法率不低于百分之九十九”“P99延迟不超过两秒”。门禁项之外的能力指标作为参考，不卡上线。门禁项定完写进验收文档，评测报告直接对照门禁项打勾打叉，决策链条短、争议少。
分层评测策略在业务场景里特别管用。我把评测分三层：第一层是“冒烟评测”，几十条核心样本，几分钟跑完，每次改动都跑，看有没有崩；第二层是“版本评测”，几百到上千条样本，覆盖主要场景，版本发布前跑；第三层是“全量评测”，几千条样本，覆盖长尾和对抗场景，季度跑一次。三层评测的频率和粒度不一样，冒烟评测保底线，版本评测保质量，全量评测保方向。三层配合着用，评测成本可控，覆盖面也够。
治理建议里我最想强调的是“评测资产归属”。评测集、评测协议、评测工具链，这些资产得有明确的责任人。没人负责的评测集，半年后就没人敢用了，因为不知道标得对不对、版本对不对。我的做法是设一个“评测Owner”角色，负责评测集的版本管理、标注质量、协议更新。Owner不一定是全职，但得有明确的职责和考核。评测资产跟代码资产一样，得有版本控制、变更记录、Review机制。这件事听着重，但评测资产烂掉之后重建的成本更高。
跨团队评测结果的互认也是个治理问题。A团队评出来模型甲比乙好，B团队评出来反过来，两边打起来了。根子在于评测集、协议、环境不一致。治理层面得推“评测基准对齐”，至少在同一业务域内，核心评测集和协议统一，各团队在上面做扩展。对齐之后，跨团队的评测结论才有可比性，选型决策才不会打架。
5.5 未来趋势、研究议程与标准化方向
结构化输出评测的未来，我觉得有三个方向值得押注。第一个是“动态Schema评测”。现在的评测集Schema是固定的，真实业务里Schema经常带条件逻辑，字段A填了才要求字段B，这种动态约束的评测方法还很粗糙。第二个是“多轮交互下的结构化输出评测”。单轮生成JSON是一回事，多轮对话里逐步补全结构是另一回事，后者更接近真实业务场景，评测方法基本空白。第三个是“结构化输出的可解释性评测”。模型输出一个字段值，能不能给出依据来源，这个能力在金融、医疗场景里是刚需，评测方法还没成形。
标准化方向我盯两件事。一件是Schema描述标准的统一。现在JSON Schema、OpenAPI Schema、各家自定义的Prompt内嵌Schema，写法互不兼容，评测工具得为每种写法单独适配。要是能出一个评测场景下的Schema描述规范，工具链的复用性会好很多。另一件是评测报告的标准化。现在各家报告格式五花八门，读者得花时间找关键信息。我理想中的标准报告模板得包含：评测目标、数据集版本、协议版本、模型版本、门禁项结果、分项指标及置信区间、失效分析、可复现性说明。模板统一之后，横向对比和审计都方便。
研究议程上，我最想看到的是“评测指标的效度研究”。现在用的格式合法率、字段准确率这些指标，跟业务实际效果的相关性到底多强，没人系统研究过。指标涨了五个点，业务故障率降了多少，这个映射关系不清楚，评测的决策价值就打折扣。效度研究得靠学界和业界一起做，拿真实业务数据跑长期跟踪，把指标和业务结果的相关性量化出来。这件事做成了，评测从“技术指标”变成“业务预言”，价值完全不一样。
自动化评测的可靠性提升也是个重要议程。现在语义匹配还得靠人工兜底，大模型当裁判的可靠性时好时坏。我期待看到更可靠的自动化判定方法，比如用多个裁判模型投票加不确定性量化，判不准的样本自动进人工池。自动化覆盖率上去了，评测成本才能降下来，高频持续评测才跑得动。标准化和自动化这两条线并进，结构化输出评测才能从“手工作坊”变成“工业流水线”。
