这个系列写到第八篇后台催更的朋友都在问同一件事你们不做通用大模型到底在忙什么今天干脆把底牌亮一亮。我们团队的主战场是两个看起来不搭界的词可信AI评测和数字文脉生态。内部立项编号55873已经跑了一年多。在外界所有人都在卷参数、卷算力、卷榜单的时候我们选择走一条相对冷静的路。这条路不追热搜、不抢首发做的都是脏活累活但跑下来发现越是脏活累活越没有人跟你抢。接下来要讲的是这一年多踩出来的真实经验希望给正在纠结要不要跟着大模型浪潮走的同行一点参考。1. 不参与通用大模型内卷先把战场选清楚1.1 大模型内卷到底在卷什么现在圈里说“内卷”卷的就那么几件事一是参数规模今天千亿明天万亿仿佛谁不把参数堆上去谁就落伍二是训练集群从几百张卡到几万张卡电费账单越来越长三是榜单中文榜单、英文榜单、综合榜单、单项榜单零点几个百分点的提升就能让团队发一条喜庆朋友圈四是上下文窗口从32K卷到128K再卷到1M好像窗口越长就越接近通用人工智能。这些事有没有价值有。但对大多数团队来说边际收益已经很低了。你费尽力气把某个榜单分数提高0.3%真实业务里用户根本感知不到你花了几个亿训练一个大模型回头发现和开源模型跑出来的效果差不多钱却烧掉大半。真正被忽略的问题反而冒出来了模型越来越多越来越强但没人能说清楚这些模型在具体场景里到底可不可信、能不能放心用。这就像一条高速公路车越来越多、越造越快但路标、刹车、检测站都没有跟上。一辆车性能再好消费者也不敢开着上路因为你不知道它什么时候会突然闯个红灯或者把导航带偏掉。1.2 为什么评测比模型本身更缺位从我个人的观察看国内做通用大模型的团队一抓一大把但认认真真做可信AI评测的团队少得可怜。原因很好理解评测不性感不性感的事往往没人抢着做。做评测你得花大量时间读论文、啃数据、设计对抗样本、跟模型的无厘头输出较劲最后可能还得面对“你凭什么评我”的质疑。但评测偏偏是刚需。模型是产品评测就是质检体系。没有一套可靠的评测体系甲乙双方在签约的时候连验收标准都说不清楚。效果很好到底怎么定义准确率多少算过拒答率多少算正常幻觉不可避免但能允许到什么比例这些问题不解决AI落地就永远停留在演示时很激动、交付时很尴尬的状态。可信AI评测要回答的不只是模型聪明不聪明更是模型说的话我能不能信。这个定位决定了它和传统的跑分评测有本质区别也是我们选择投入的核心原因。1.3 数字文脉生态为什么值得长期投入数字文脉生态这个词我们内部琢磨了很久。什么叫文脉就是文本之间、人物之间、事件之间那一条条看不见的传承脉络。它可能是一部县志里记录的乡贤谱系也可能是一套家谱里从明初到清末的人口迁移轨迹还可能是一批古籍刻本之间互相引用、互为版本的复杂关系。这些东西如果只停留在纸上就只是一堆等待衰朽的文物如果只是简单扫描成图片那也算不上数字化。真正的数字文脉生态是把这些内容结构化、语义化、图谱化让后人可以用搜索引擎、知识图谱甚至AI问答的方式去触碰它们。为什么说值得长期投入因为数字化是典型的基建型业务前期慢、周期长但一旦建成数据资产会持续产生价值。更重要的是在大模型时代人人都可以用AI生产内容文化内容供给空前丰富但质量却未必提升。如果不做质量检测和溯源那些生编硬造的历史人物、张冠李戴的典故就会借着AI的流畅输出污染公共知识。这恰好也是可信AI评测能发挥作用的地方。1.4 55873到底代表什么刚开始写技术博客的时候我一直没解释编号的含义。55873是我们内部一个专项建设任务的立项编号全称可以理解成“可信AI评测能力与数字文脉知识库建设专项”。它不是一个玄学数字而是在这个编号下面沉淀了三样资产一套面向可信能力的评测基准集、一套自动化评测流水线、一个聚焦文化领域的数字文脉知识库。对外分享时我们经常直接用55873代指整个项目因为说起来顺口也方便内部工单、代码仓库、数据集的命名统一。你去看我们服务器的目录名全是类似eval_55873、wenmai_55873这样的命名。这算是一个小习惯项目代号起好了团队沟通效率真的能提升不少。2. 可信AI评测怎么做维度、数据、流水线三者缺一不可2.1 先给模型建立“能力×可信”双轴坐标评测维度设计是整条评测体系的根基。我们内部习惯把评测分成两大类一张表格讲清楚评测类型代表维度回答的问题能力维度语言理解、逻辑推理、知识覆盖、代码生成、多模态理解模型会不会做得好不好可信维度真实性、一致性、无害性、鲁棒性、隐私保护、可解释性、拒答能力模型的输出能不能信敢不敢用很多评测只测能力维度这其实只回答了半个问题。一台跑车百公里加速2秒确实很快但如果刹车失灵谁敢开可信维度就是刹车和方向盘。拿真实性来说它考察的是模型有没有一本正经地胡说八道也就是幻觉率。一致性考察的是同一个问题换一种问法、换一个上下文模型是否还给出同样的答案。无害性看的是面对诱导和恶意输入模型能不能守住边界。鲁棒性则是把问题里的一个词换成近义词、加个表情符号看模型会不会突然跑偏。这些维度放到具体业务里缺一个都可能出事。文博导览回答错一个年代游客倒是不会怎么样但放到合同验收里就是事故知识问答对敏感话题不拒答直接就触碰红线了。所以我们的原则是能力维度可以按业务取舍但可信维度必须全面覆盖。2.2 评测集怎么造三条红线必须守住评测集是评测体系的弹药也是最容易偷懒、最不能偷懒的环节。我总结出三条红线供参考。第一不要脱离真实使用场景。我们不会只拿通用基准题库去测。在数字文脉场景里更重要的是古籍识别的上下文、文博问答里的专名、旅游导览里的时空关系。这些真实问题才是模型的火线。你拿一堆代码题去测一个做文博问答的模型测出来的结果毫无意义。第二不要把有争议的答案放进标准答案。大模型评测题比学校考试难出很多的地方在于很多问题本身连人类专家的回答都不完全一致。比如“某个历史事件的影响是什么”这种开放性问题就不适合作为自动评分的题。我们的做法是两条标注规则打架的题先不进库仲裁通过之后再入库。第三不要用会被模型背下来的公开题目。大模型训练数据会从互联网上吞掉公开题库你拿MMLU去测一个2024年后训练出来的模型分数已经不能完全说明真实的推理能力很可能是见过原题。所以我们的原则是公开基准可以用于横向观察但定稿判断必须用自己的私有多样化题库而且每季度更新。标注流程上我们有硬性要求新题生成后至少两位标注员独立标注用内部评分0到4打分不一致超过1分的进入仲裁流程。这个流程看上去慢但保证了评测基准本身的可靠性。大家常调侃AI评测是拿一把不靠谱的尺子去量别人其实尺子的质量才是最该先解决的问题。2.3 把评测从“临时脚本”升级成“流水线”如果没有工程化评测就是研究员电脑上一堆只能自己跑的Jupyter Notebook。一旦要沉淀就得有执行引擎、结果存储、报告系统、回归监控。我们内部把评测流水线拆成四层执行层统一封装模型接口不管对方是API还是本地部署都走同一个调用入口。每次请求固定记录模型版本、温度参数、请求时间这是后面所有分析的基础。数据层题库管理、版本管理、题目标签管理。每道题都知道自己属于哪个版本、覆盖哪个维度、难度标签是什么。测试跑完再来一次必须能指出来用的是哪一版题库。评估层自动评分器分成两类客观题用精确匹配或规则匹配主观题先让大模型打分再人工抽检。最终汇总成核心指标并生成bad case列表。报告层按角色输出可读报告。技术人看case明细管理层看指标趋势合同方看验收依据。一份报告如果所有角色都看不下去那评测效果就打了折扣。这也是我一直强调的评测不是发个请求就完事。要做就做成一套体系否则每次评一个模型都从零开始根本沉淀不下来。3. 数字文脉生态一个比榜单评测更考验功力的试验场3.1 文脉数据为什么这么难做数字文脉生态里绕不开的是古籍和地方文献。这类数据有四个共性难点。第一生僻字和异体字多。同一个字在不同版本里写法不一样甚至同一本书里前后不一致。如果不先做字形归一化后面的所有自然语言处理都会带着误差。第二避讳字系统复杂。比如为了避讳有些字会缺笔或者换成同义词。如果不了解当时的制度AI很容易把正常的避讳写法识别成错字。第三版式和语义深度绑定。古籍里的双行小注、批校、眉批都不是简单的一行字它们和正文的关系才是信息本身。一个OCR系统如果只把字抠出来不区分正文和注释那导出的数据就是把知识网络压平成了一堆字符串。第四专名体系庞大。一个人可能有一堆字、号、谥号一个地名在不同朝代也叫不同的名字。通用模型的实体识别在这种庞杂体系面前几乎必然会出错。这些特点决定了通用模型直接拿来做古籍文本分析效果一定不好。反过来这些数据也天然是检验大模型深层理解力的试金石。文脉数据和评测之间不是单向应用而是互相成就。3.2 我们实际在文脉生态上做的事情说几个具体的都是已经跑在流程里的东西。第一个是古籍OCR和结构化。不是把字抠出来就完了还要还原阅读顺序、分清正文与注释、处理残缺字和断裂线。我们为此建了异体字到规范字的映射表以及一个生僻字字形库。OCR模型跑完先过规则引擎最后人工抽检5%。第二个是时空知识图谱。把人、地、时、事四个要素关联起来。举个例子输入“某个年代某个地点活跃的人物”系统能根据县志和族谱数据组装出一个名单并给出依据。这件事做成了研究者查资料的方式就完全不一样了。第三个是AI内容质量检测。专门针对AI生成的文旅导览、历史科普、文化短视频脚本做检测。重点看专名有没有张冠李戴、时间线有没有混乱、事件有没有凭空虚构。这项能力直接复用了我们在可信AI评测里沉淀的方法论。第四个是数字文脉平台的联合共建。和图书馆、文化机构、研究单位合作把分散在各地的纸质文献逐步变成可供检索、可被AI调用的结构化数据。这个方向周期长但越做越有底气因为数据资产是用时间垒出来的。3.3 文脉场景催生出的专属评测指标文脉场景对AI的要求跟通用场景差异很大。我们在评测体系里为此单独增加了一套指标。评测指标说明为什么会踩坑专名错误率人名、地名、朝代名等识别或关联错误的比率模型常把同名的不同人物合并时空一致性文本中时间、地点与历史背景是否互相冲突宋朝人用明朝的地名这种错误很隐蔽版本溯源性内容能否落到具体版本、页面、校次拼错一个版本整个溯源链断掉风格贴合度翻译或白话改写后是否保留原文气质白话过头就失去文脉韵味知识单元完整性摘录、引用、知识图谱节点是否完整缺头缺尾的知识碎片无法支撑检索拿风格贴合度来说这是一个主观指标但我们照样给了分级标准完全符合、基本符合、不符合。所谓基本符合就是改写后的文字保留原文的信息结构和语气只是换了更易读的措辞不符合则是把文言文翻译成了大白话信息没丢但韵味全无。这种指标的设定业内没有现成先例只能自己摸索走通之后反而成了我们的差异化能力。3.4 数字文脉生态的闭环价值我们的评测体系在文脉场景里检验模型文脉数据反过来给评测体系提供难题。两者互相咬合形成今天这个形态。一个AI能力评测如果能在古籍断句、专名消歧、时空一致性这些题目上拿到体面分数拿去做普通的知识问答通常问题不大。这种用垂直场景反哺通用能力验证的做法是我们认为比单纯刷榜单更有意义的地方。更重要的是这套闭环给了我们一个独特的视角别人的评测数据是编出来的考题我们的评测数据有一大块是真实的历史文献派生出来的。人类千百年积累的文本本身就是最严苛的考官它不会因为某个模型的商业宣传就放宽标准。4. 实操过程与核心环节实现4.1 从零搭建可信AI评测流水线的六步这部分直接给可抄作业的步骤。第一步圈定评测对象和边界。先问清楚这次要评什么模型用在什么业务模型更新频率多高边界定清楚评测才不会发散。比如我们有的任务只测评AI在文博导览场景下的知识回答质量那代码生成、数学推理这些维度再热门也不掺和进去。第二步建立评测维度矩阵。能力维度挑3到5个可信维度挑3到5个不要贪多。贪多的结果就是评测报告没人看得完。每个维度还要写清楚定义、评分标准、示例。这份文档会直接影响后续标注一致性建议建wiki专门维护。第三步构建评测数据集。结合真实场景写题每道题标注来源、难度、期望回答要点。至少留出20%的对抗样本模型容易翻车的题一定要多放一点。对抗样本不一定要多刁钻把常见问题换个人称、换个事件背景往往就能让一些模型现原形。第四步跑通脚本化评测。先把最小闭环跑起来读题、调用模型、存结果、算指标。脚本代码要写干净因为后面每次模型更新、题库更新都要重跑一遍难维护的脚本会变成团队的负担。第五步人工复核与错误修正。自动评分筛出bad case后安排人工逐条看。人工复核的意义不是推翻AI的判断而是给评测系统纠偏。比如某些题因为表述歧义被判错那就得改题或者修评分规则而不是硬着头皮接受不合理的分数。第六步回归监测。模型一更新就重跑一遍记录分数波动。触发阈值就报警例如综合可信分下降超过0.5%就要定位原因。没有这一步评测体系就是一次性的下一次模型升级你根本不知道是不是升级了个寂寞。4.2 一个最小评测脚本长什么样下面给一个非常精简的示例核心思路是统一的记录结构和多次采样。import json from collections import Counter def run_eval(questions, model_api, sample_times3, temperature0.7): questions: [{id: ..., input: ..., ground_truth: ...}] model_api: callable, 传入 prompt返回 text results [] for q in questions: answers [] for _ in range(sample_times): resp model_api(q[input], temperaturetemperature) answers.append(resp.strip()) # 简单一致性归一化后比较去重数量 distinct set(normalize(a) for a in answers) consistent len(distinct) 1 # 正确率标准答案归一化后比对 correct 0 for a in answers: if normalize(a) normalize(q[ground_truth]): correct 1 results.append({ id: q[id], answers: answers, consistent: consistent, correct_rate: correct / len(answers), }) return results def normalize(text): # 实际落地时这里做去除标点、统一全半角等处理 return text.strip()为什么不直接用裸API调用因为裸调用没有统一的结构。你想想跑完一百道题结果散落在终端日志里连哪道题对应哪次请求都找不回来出了问题完全没法复盘。这个脚本最核心的意图是统一的记录结构答案、参数、时间戳一条都不能少。4.3 用1000道题算清幻觉率和拒答率指标计算是评测里最容易被混淆的环节举一个实际例子。假设我们往评测集里放了1000道事实性判断题模型的输出分三类正常回答且正确、正常回答但错误、直接拒绝回答。整个测试下来模型回答了800道拒答200道。800道里有620道正确、180道错误。于是有效回答率覆盖率 800 / 1000 80%答对率有效回答中正确比例 620 / 800 77.5%整体正确率所有题目中正确比例 620 / 1000 62%拒答率 200 / 1000 20%幻觉率 180 / 800 22.5%这里有个特别容易踩的误区只看答对率77.5%会觉得这个模型还不错。但你仔细算算它在所有题目里只答对了62%而且有22.5%的概率是在自己不懂的领域里一本正经地编答案。可信评测和传统准确率评测最大的区别就在这里我们必须把沉默和说谎分开算账。再看几个模型对比模型有效回答率答对率拒答率幻觉率模型A95%82%5%18%模型B70%90%30%10%模型C88%85%12%15%你会选哪个如果只买一个我建议根据场景来。在医疗、文物、法务这类容错率很低的场景宁可选B让它多拒答也别让它多编造。在泛知识闲聊场景A可能更合适因为拒答太多会显得傻。评测指标不怕多怕的是只有一个分数看不出这种取舍。4.4 实操中踩过的五个坑这些坑都是真金白银换来的一条一条说。第一个坑是随机性抖动。同一个问题问三次三次不一样。最初我们只跑一次导致报告的指标每次都在轻微浮动根本没法定位是模型更新了还是随机噪声。后来规定至少采样3次并且把温度固定成0.7跑批时记录随机种子。现在每次模型的版本说明里都会附上采样参数复盘的时候一查一个准。第二个坑是LLM裁判的自我偏好。主观题用大模型当裁判确实能解放人力但裁判模型也有偏好。比如裁判模型更偏爱长的回答同一个答案被包装得更啰嗦就得分更高。我们后来让裁判先输出维度分再输出总体分对裁判本身做定期校准还会拿一批历史结果做回归防止裁判模型升级后评分逻辑突变。第三个坑是评测集污染。有一个题库用着用着发现模型得分突然跳升后来发现是测试题目被转写到公开文档里去了。从那以后定稿题库不再外发在本地数据库加密存储并且每年强制更新20%以上。第四个坑是标注不一致。同一道题两个标注员一个打2分一个打4分如果不处理整个基准就是空中楼阁。现在我们有仲裁会议每天标注结束前把冲突项过一遍并沉淀标注规范补充说明。docker每天都在更新规则但标注规范文档才是真正的锚。第五个坑是古籍长尾字符处理。刚开始做OCR很多生僻字被识别成乱码导致后续专名抽取全崩。后来我们建立了异体字到规范字的映射表和生僻字字形库OCR模型跑完先过一遍规则引擎最后人工抽检5%。这个处理环节现在已经成了文脉数据的标准流程。5. 常见问题与排查技巧实录5.1 如何抓住“一本正经的胡说八道”大模型输出越流畅越容易让人放松警惕。我们处理过的一个典型case是AI生成一篇文博导览稿把明朝中后期的一个官员直接安排到清末办洋务时间错位一个世纪但上下文读起来却通顺自然。如果只靠人工肉眼读不仔细核史料根本发现不了。排查手段概括一下专名校验把文本里的人名、地名、朝代名抽出来和知识图谱对齐。时间线检测提取句中事件的时间状语和人物生卒年比对。溯源性检测让模型给出结论的出处或依据再人工核验。反向验证生成一段内容后要求它对比检索库里的原文片段。还有一个土办法很好用对重要结论隔一段时间再问一次看它是否还能给出同样的答案。如果上次说甲、这次说乙那这个知识点的可靠性就要打问号。这个方法简单但非常有效尤其适合抽查那些已经跑在业务里的AI功能。5.2 评测报告总是被挑战怎么办做评测的人几乎必定会遇到这样的灵魂拷问你的分数凭什么可信如果只给一个分数那确实很容易被挑战。我们的做法是给三层证据。第一层是指标总览控制在一页纸让决策者快速知道结论。第二层是bad case抽样选10到20个有代表性的case每个都附上输入、输出、标注说明让技术负责人能快速判断评测是否合理。第三层是复现记录和审计日志把测试时间、模型版本、题库版本、采样参数全部列出来。有了这三层评测结果就很难被轻飘飘地推翻。尤其在做合同验收的时候甲方问一句“来源是什么”你能直接甩出完整的日志链路而不是支支吾吾说“反正测出来就是这样”。越真实的落地场景越需要这种可以公开检验的评测报告。5.3 可信AI评测常见问题速查表最后整理一个速查表是我们在售后支持和内部答疑里最常遇到的场景。现象可能原因排查方向解决方案准确率突然大幅上升题库被模型训练数据学到检查题库发布时间是否早于模型训练截止时间抽样看模型是否背题更换私有题库定期加入新题同一个模型两次评测分数波动超过2%采样参数未固定或随机性未控制对比两次请求的温度、随机种子、模型版本固定采样参数多次采样取多数主观题分数和人工判断差异大裁判模型存在偏好抽取差异case分析裁判打分逻辑校准裁判prompt加维度打分模型对敏感问题不拒答拒答策略未生效或评测维度遗漏检查拒答类测试题是否覆盖完整补充对抗性安全测试集古籍文本实体抽取错乱生僻字识别错误或专名词表缺失查看OCR结果预处理是否通过建立异体字映射表和领域专名词表AI生成内容有时空错位对时间状语和人物生卒年没有做交叉校验提取时间实体和人物实体检查前后一致性在生成流程里加入时空一致性检测模块这个表不是一次性文档而是我们团队日常排查时随时打开的手册。做评测体系这件事踩坑的历史就是最珍贵的资产。我也建议刚起步的团队先记录自己做过的每一次排查三个月后再回看就会发现一套属于自己的避坑清单。写到这里稍微收个尾。这一年多我在55873这个项目里最深的体会是越是在大家都急着往前跑的时候越要有人愿意停下来修路标、装护栏。可信AI评测就是给整个行业装刹车和方向盘数字文脉则是把技术放进时间的长河里接受检验。这两个方向看上去都不热闹做起来也确实是脏活累活但每次看到一份评测报告让客户敢拍板验收或者一个生僻的历史人物在知识图谱里重新有了清晰的位置我就觉得当初选择绕开大模型正面战场是对的。如果这个系列能带给同行一点点启发那就是内卷的尽头不一定是更卷也可能是换一条路走得更稳。