大模型进台站，大家最先想到的问题是「能不能接进来」。但真正决定这套系统能不能长期用下去的，是另一个更朴素的问题：它答得准不准。
通用榜单上分数很高，落到台站场景未必好用。规程检索到了却不给出处、给出的结论和现场规程版本对不上、把「天线调谐」和「馈线驻波」混作一谈——这些在演示环节看不到，在值班台上却天天遇到。
所以广电场景需要一套自己的评测指标体系和基准集。这篇聊清楚三件事：评什么、怎么建、怎么让它在日常迭代中真正跑起来。
■ 通用榜单与台站场景的错位
公开评测基准大多来自通用问答、代码生成、数学推理，而台站关心的完全是另一类能力：从几百页运维规程里定位到正确条款、结合设备台账和历史告警给出可执行建议、在信息不足时明确说明需要现场确认。这些能力在通用榜单上几乎不出现，也就无从度量。
还有一个更现实的差异：台站的「正确答案」本身是活的。规程会修订、设备会更换、流程会调整，同一个问题在不同台站、不同年份答案可能不同。用一套静态标准答案去评测，测出来的分数只能反映背题能力，反映不了现场可用性。
常见误区拿公开基准微调后跑出一串漂亮分数，就认为系统可用。公开基准不含台站术语、规程结构和本地设备信息，分数高只说明模型通用能力尚可，与台站是否好用没有必然联系。
■ 1.准确性：检索层与生成层分开看
准确性至少要拆成两层。检索层看有没有找对依据——召回了哪几条规程、排序是否正确、关键条款是否命中；生成层看有没有忠实于依据——有没有编造规程里不存在的条款、有没有张冠李戴。检索错了，后面全错；检索对了但生成加戏，同样是错。分开度量才能定位问题。
术语准确率需要单独看。台站术语比如驻波比、载波功率、互调、调谐，拼写或含义错一个，值班员就得重新核一遍，效率收益直接归零。
■ 2.场景适配：答案能不能落到台站
拒答率与越界率是台站场景的生死线。不确定的时候模型是否会明确说「需现场确认」，而不是硬凑一个看起来专业的答案——这决定了系统是帮忙还是添乱。
可溯源性同样关键。答案必须给出规程名称、章节号、版本日期。没有出处的结论没法写进正式工单，也没法在事后复盘时追责。
指标设计要点每个指标都要对应一种可自动执行的判定方式；能用规则或字符串匹配的，不要用人工评分；人工评分只保留语义正确性和现场可用性两类，并同时把双人盲评的一致性作为评分质量本身的指标来监控。
■ 3.工程侧：决定能不能上生产
响应时延、单次问答的算力成本、并发能力、私有化部署下的显存占用，这些指标不进评测报告的核心，却直接决定方案能不能在台站长期跑下去。台站服务器资源有限，一套时延三秒、显存占用爆满的系统，评测再漂亮也落不了地。
■ 1.三个互补的来源
第一类是真实问句。从值班日志、故障工单、答疑记录里抽取，这部分最贴近现场。抽取时必须脱敏，并按时间严格切片，避免近期答案泄进训练集造成数据泄漏——否则评测分数会虚高。
第二类是专家构造与标注。由台站专家按规程撰写标准答案和判定要点，需要逐条给出「命中点」和「错误点」。这部分成本最高，但它是整套评测的标尺，没有它，前两类素材都无法判分。
第三类是对抗样本。同义不同问法、错别字、口语化提问、跨规程的复合问题，以及规程中确实查不到答案的问题。最后这一类尤其重要，它是检验拒答能力的唯一手段。
■ 2.分层与配比
基准集要分层组织：常规类占大头，覆盖日常高频问法；边界类与对抗类必须占到一定比例，否则模型只要会说话就能拿高分。另外要单独设一组无答案样本，规模不需要大，但必须覆盖常见的不确定场景。
样本量上，两三百条小而精的集合往往比几千条宽泛的集合更有用。集合小，便于逐条人工核对标注质量；分布准，能真正区分模型优劣。相反，一份靠批量拼凑出来的庞大集合，标注错误率高，跑出来的分数反而会误导决策。
还有一个容易被忽略的细节：基准集必须版本化。每轮修订都要记录新增、删除、修改了哪些样本以及原因，否则不同轮次之间的分数变化就无法归因——到底是模型进步了，还是题目变简单了，混在一起就说不清。
评测集的难度分布比总量更重要。一个全是简单问题的评测集，只会告诉你模型会说话，不会告诉你它能不能上岗。
■ 1.离线批量评测
固定模型版本、固定提示词模板、固定检索配置，批量跑完，输出一组指标：检索命中率、答案正确率、拒答率、溯源完整率、时延、成本。这组结果按版本入库，和代码提交记录对齐，形成可追溯的演进曲线。
关键动作是把评测变成流水线里的一道关，而不是出问题时才想起来做的一次抽查。每次改模型、改提示词、改检索策略，都跑一遍回归，看哪些指标动了、动了多少。
■ 2.上线前的影子模式
新版本上线建议先用影子模式——模型在真实流量上给出建议但不推送给值班员，由人工复核一段时间，达标后再放开给全员使用。这个阶段能暴露出离线评测覆盖不到的问题，比如用户真实提问里那些不规范的表述方式。
往后保留小比例的人工抽检通道，把线上错误样本自动归类补进基准集。评测集随真实错误一起增长，避免出现只测自己会做的题、越测越好的循环。
评测的真正意义不在于一个总分，而在于能定位问题。分数下降时，能回溯到是检索召回退步、还是生成不够忠实、还是模型本身能力下降；能在版本对比中看清哪些指标在改善、哪些在用别的指标换分。
落地建议先建两三百条小而准的基准集跑通全流程，再逐步扩到千条级；每次上线都保留评测报告并与版本号绑定；评测不达标不发布，把它作为发布流程的硬性卡点而不是参考意见。
评测集也需要有明确的责任人，通常由业务主管部门牵头，而不是纯技术团队。判定「这个答案在台站算不算对」，需要既懂规程又懂现场的人拍板，技术团队定不了这个标准。
大模型在台站落地，评测是环节里最容易被跳过、又最不该跳过的一环。
它不产出炫目的演示效果，却决定了系统能不能从「试点能用」走到「长期敢用」。把自己的评测指标和基准集建起来，是台站AI从能演示走向能上岗的必经之路。
