之前给客户做一个报告生成项目。测试环境用云厂商的大模型，效果不错，客户也认可；正式交付按要求换成客户集团私有化部署的模型，准确率掉了很多。
模型的更换，对于写代码的人，可能无感，甚至有时候是生产力提升——这个新出的模型实在夯，之前的都弱爆了！但是对于业务来说可能情况就相反了。过去两年给 AI 攒的业务知识：几千条数据字典，一条条核对出来的业务规则，调了几百遍才顺手的提示词。这些东西全是照着现在这个模型的脾气磨出来的。模型一换，还作数吗？
这个其实是两种不同的需求。写代码更多关注模型能力差距，谁强换谁，唯一需要考虑的是价格、成本。另一种是：项目里那套提示词、示范样例、输出格式的约定，全是照着一个模型的脾气磨了几个月的，搬到新模型上，这些调校能不能保持。但现实情况就是这样，同样一句指令，原来的模型懂，新的模型不懂。当时我们管这叫兼容性问题，靠重新调参硬磨了回来，磨到什么程度算恢复，其实也没有裁判，全凭人看着像。
后来读到人民大学 EvoOntology 项目（arXiv 2609.15779）的一组实验，才发现这不是我们项目特有的事故，是有数字的规律。而且实验回答了一个我们当时没顾上想的问题：项目里攒下的那些业务知识——报告怎么组织、数据口径怎么取、哪些数字该进哪张表——换模型的时候，哪些是真的作废了，哪些根本没动过？
上一篇文章里我核过这个项目的评测模块源码，谈的是它怎么让知识库自己长大；这篇只谈迁移——模型换了，长出来的东西还剩多少。


----
## 一、同一份业务，四个模型养出四份不一样的知识库

实验设计很干净。GPT 家两款、Claude 家两款，四个模型从同一份初始知识库出发，面对同一份企业数据，各自跑任务、各自积累，互不通信。若干轮之后，把四份知识库放在一起比。
长歪了，而且歪得很明显。两两比较各自沉淀下来的概念集合，重合度最高的一对只有 0.62。交叉使用也一律掉分：把 GPT 养的那本交给 Claude 用，成绩至少掉 6.6 个百分点，最惨的一档平均掉 10.9；每一列都是自己养的那份得分最高，没有例外。
有个细节容易被略过：**两款 Claude 之间的重合度（0.55）比两款 GPT 之间（0.61）还低。**同一家厂商的模型，互相之间也没养出多少默契。说明这个印记不在「厂商风格」这么粗的层面上，它长在具体模型的行为习惯里——它怎么查知识库、习惯什么粒度的回答、到什么时候觉得信息够了。指望「都选同一家」来躲开迁移成本的团队，这条路走不通。
直觉反应是：攒的东西随模型报废，攒了也白攒。先别急着下这个结论，得先搞清楚一件事——这四个模型各自改来改去的，改的到底是什么。


----
## 二、改来改去，改的大半是怎么喂

把四个模型演化中被接受的修改按内容拆开：改「知识怎么喂给模型」的占 57%——入口说明怎么写、查询接口按什么粒度返回、提示词怎么措辞。这一整套安排，下文简称喂法。改业务内容本身的占 34%；剩下 9% 动的是底层结构。
也就是说，超过一半的收益不是往库里补了新的业务知识，而是把知识的喂法调得越来越合这个模型的脾气。论文里有个例子：GPT-5.5 在演化中长出了一套常用查询片段的收藏，它发现存几段验证过的查询、下次直接拿来用，比自己每次现写顺手；Claude-Opus-4.8 完全没长这个，它长出来的是分档更细的入口说明。同一个业务，同一份数据，两个模型给自己配了两套不同的餐具。
餐具随模型作废，天经地义。麻烦的是账没这么干净——第一节里连概念的重合度都只有 0.62，概念总不能算餐具，那是知识本身。
乍看矛盾，拆开不是。概念重合度低，不必然说明两个模型对业务的理解有冲突，它们可能只是给相近的东西起了不同名字、切了不同粒度，论文作者自己也承认，标识符对不上不能判定语义不等价。但交叉使用实打实掉分，说明差别也不只是叫法：概念该切多细、挂在哪个上级概念底下、跟哪些字段映射打包在一起，这些选择都是被模型的行为一轮轮筛出来的。表达什么和怎么表达，在演化里是揉在一起长的，揉进去的那部分就是迁移成本。
所以第一节的实验真正说的是：不是知识作废了，是知识和喂法记在了同一个账本上，换模型时被一起扔掉了。想保住点什么，得先把账本拆成两本。


----
## 三、哪种知识不随模型作废

拆账的标准就一条：换一个模型，这条知识会不会变。
业务定义不会变。「收入」按回款算还是按开票算，是业务定的，跟模型无关。字段映射不会变。某个概念对应数据库里哪一列，这是数据库的事实。探针证据不会变。某一列的取值分布长什么样，是发真实查询核对过的，记录的是观测结果，不是谁的看法。人工核定过的标准答案也不会变。历史任务的对错，不随答题的人换人而改变。
这四样的共同点是，它们是对世界的记录，不是模型的生成。EvoOntology 有一条纪律，我在上一篇里说它最值得抄：每条进库的语义，必须由一次可执行的探针查询作凭证。判断某个字段可能是「收入」，不能只写一句「我认为这个字段像收入」，必须真发查询，看字段类型、看真实取值、看关联关系，核对通过才许写入，并且把这次观察一并存档。观测，不随观测者换人而改变。
这个区分在另一篇文章《向量库为什么回答不了「为什么」》里讲得最透：让模型解释一个决策，它给你的是照着结果圆出来的事后叙事，换个模型，叙事就换个样子；而在决策发生那一刻记录下来的证据，不随解释者改变。生成的东西随模型作废，记录的东西不会。
这不是纸上推演，有团队真的完整换过一遍模型。淘天商家财务团队把同一套知识库和决策函数先跑在 opus 上，后来模型换成 gpt5.5、glm5.2、qwen，平台整个换了一遍，真实需求的输出稳定性没有变。活下来的正是记录的那一半——红冲工单要取哪些证据、哪条路绝对不能走，这些判断写在本体和决策函数里，不写在哪个模型的提示词里。
这还能回答一个常见问题：AI 生成的知识文档算不算资产？大部分不算。自动总结出来、没人核对过的业务说明和字段描述是生成物，不等换模型就开始腐化。只有经过探针核对、留下观测凭证、或者人工核定过的那部分，才算完成了从生成到记录的转化。


----
## 四、标准答案是唯一中立的资产

记录那一半里，哪种最值钱？这决定了迁移那天手里有没有牌。
把知识库内容层的组件逐个屏掉、重跑同一批任务，账是这样的：去掉字段映射，掉 13.4 分；去掉探针证据，掉 8.7 分。两根最承重的墙，恰好都在记录那一半里。知识库最值钱的部分，正是最不怕模型换代的部分——这是整组实验里我认为最让人安心的结论。
但迁移那天真正决定成败的是第四样：标准答案，也就是验证任务集。原因在演化循环的工作机制里。它敢自动修改知识库，靠的是每次修改都要在同一批验证任务上、同参数同预算地跟旧版本成对比较，赢了才发布——上一篇我核过这道门控的实现，也核过拆掉它的代价：去掉门控，掉 11.2 分，整个系统退化成让模型自由改知识库。
验证任务不依赖任何一版知识库，也不依赖任何一个模型，它是整个系统里唯一中立的资产。迁移那天，知识库可以重长，喂法可以重调，只要标准答案还在，重长就是有裁判、有方向、会收敛的过程；标准答案丢了，迁移就退化成把所有东西凭感觉重调一遍，而且没有任何办法证明调完比原来好——开头报告生成项目里那场「磨到什么程度算恢复、全凭人看着像」的调参，就是这个状态。
拆出来的账本长这样：
![image.png](https://developer.qcloudimg.com/http-save/yehe-5938488/3c933c5a1f331a115b07adf5a19d2503.png)
账本对着实验算是算清了。但它管不管用，得拿一个真项目的账来对一对。


----
## 五、拿一个真项目的账本来对

我们建筑工程这边有一个本体数据平台，管着元素分类、空间分类和属性字典。它一直在开发基于大模型的语义匹配：设计师的模型里写「砼柱」，物料系统里叫「RC柱」，验收记录里是「结构柱」，让模型判断这些是不是同一个东西。喂法进了生产环境，就是这个样子——一堆照着某个模型的脾气调出来的判断逻辑。
拿账本逐项对。
业务语义已经有了。属性字典的表里躺着 name、definition、unit、data_type、value_limit，这就是业务定义和值域该有的样子。C30 混凝土是什么、强度值域多少，换任何模型都不会变。这部分可以直接入账，而且它已经是以数据库表的形式存在的，比大多数团队「写在文档里」的语义层硬得多。
喂法那本账也很清楚。匹配的提示词、候选项的组织方式、接口返回的粒度，都是照现在这个模型调的，换模型就得重调。这属于正常损耗，不用心疼。
真正的问题在中间地带。「结构柱＝砼柱＝RC柱」这类判断，现在既不在字典里，也不在任何表里，它活在模型的隐式理解里——每次匹配成功，这个判断就随会话消失了，下次遇到同样的写法再判一遍。按第三节那条标准，这是最典型的生成物：干着记录该干的活，却没留下任何记录。模型明天停服，这些判断全部清零，而且没人说得清清零的到底是哪些。
补法也是照账本来的。每次匹配成功，把表面写法、归一到的概念、来源样本、置信度、有没有人工复核过，存成一条证据；等价关系从反复出现的证据里定期提炼，落进数据库，别再让模型每次现场重判；历史项目的验收台账、算量表这些人工核定过的结果，收进标准答案集。这三样补齐，平台就有了完整的语义和裁判。
到那天再换匹配模型，迁移就是照流程走：字典和证据表冻结不动，旧的提示词和接口配置整份归档（别删，回滚要用，它还是研究「不同模型要不同喂法」的第一手样本），让新模型在真实任务上重新调出它的匹配策略，然后拿历史台账回放验收——新策略算出来的结果跟当年人工核定的对得上、确实更好，才发布。重长也不是从零开始，EvoOntology 的收敛曲线给过参照：概念数从 61 长到 80 就不怎么长了，语义缺口的大头早被已有知识填掉，新模型要长的主要是喂法，收敛得快。这么走下来，迁移从一场事故演练变成一次普通发版。
这里还有个转机。喂法原本最让人沮丧的地方是「随模型作废」，但证据一旦入账，它反而成了语义的原料产地——每一次匹配都在沉淀证据，每一次人工复核都在加厚标准答案集。两者之间不是一堵墙，是一条能修通的转化通道。修不修，取决于第一天记账的时候有没有给证据留位置。


----
## 六、多模型并行，和行业标准的形态

迁移是一次性事件，更日常的状态是多个模型同时在跑：不同任务路由到不同模型，或者新旧模型灰度并行。这时候账怎么记？
三条路线摆在一起。每个模型养一份完整的知识库，性能最优——自己养的永远最高——代价是 N 份运维，而且业务定义被复制了 N 份，哪天口径变更，N 份要同步改。所有模型共用一份，运维最省，代价是实测每个模型至少损失 6.6 分。第三条：语义基础共享一份，喂法每个模型各配一套。
我取第三条。理由不是它居中，而是前两条各违反了资产的一半本性：定义和证据本来就不随模型变，就该只有一份；接口粒度本来就模型相关，就该各配各的。
把这个结论再放大一层，就是跨组织行业标准的唯一现实形态：只统一事实的格式，放开事实的用法。行业标准能要求的是每条语义必须带来源、带凭证、带核定记录；不能要求的是所有人用同一种方式建模、组织、暴露——迁移实验已经证明连一个模型家族内部都对不齐，跨组织更不可能。


----
## 七、发布之前，三件事说清楚

0.62 是个代理指标，别当精确刻度用。概念标识符的重合度判定不了语义等价，重合度低未必等于知识冲突；但交叉使用的掉分是硬证据，喂法的差异真实存在、真实花钱。我的读法是：知识资产完全可移植被证伪了，完全不可共享没有被证明。哪些能共享，拿第三节那句话逐项过，不能打包下结论。
实验跑在数据智能体基准上，不是真实企业。权限控制、多人修改、规则冲突、审计、长期版本治理，都不在范围内。第五节给建筑平台开的方子是在论文机制上做的工程外推，落地时每一步都会撞上论文没碰的组织问题——人工核定谁来做、按什么节奏做、核错了谁负责，这些比技术难。
「随模型作废」不能当成放弃治理喂法的借口。它会作废，但作废前的每一天都在生产环境里服役，它的每次修改同样要过门控、要能回滚——EvoOntology 对喂法的编辑用的是和业务内容同一套配对验证，没有因为这层是模型相关的就放任自由改。会过期的资产也是资产，过期之前它得是对的。


----
## 结语

这篇文章说到底是一个记账原则：知识资产分两种，记录下来的和生成出来的。探针观测、人工核定、标准答案是记录，跟着业务走；调好的提示词、演化出的接口形态是生成，跟着模型走。资产的保值率，等于其中记录的比例。
换模型不是重建，是重长。冻结事实，归档旧的那套喂法，让新模型在标准答案的裁判下重新长出它自己的喂法，迁移就不是一件心里没底的事，而是一件有流程、有验收、能做完的事。
好在最值钱的资产恰好最保值。两根最承重的墙是字段映射和探针证据，都在业务语义里；唯一的裁判是标准答案，换几代模型它都坐在那里。往证据和标准答案里投的每一分钱，都不会给下一款模型陪葬。
模型是公用的，一代代地换；记录是自己的，一寸寸地攒。换模型那天，账本上一眼看得清哪些带得走。语义基础设施做到这一步，才算数。

之前给客户做一个报告生成项目。测试环境用云厂商的大模型，效果不错，客户也认可；正式交付按要求换成客户集团私有化部署的模型，准确率掉了很多。模型的更换，对于写代码的人，可能无感，甚至有时候是生产力提升——这个新出的模型实在夯，之前的都弱爆了！但是对于业务来说可能情况就相反了。过去两年给 AI 攒的业务知识：几千条数据字典，一条条核对出来的业务规则，调了几百遍才顺手的提示词。这些东西全是照着现在这个模型的脾气磨出来的。模型一换，还作数吗？这个其实是两种不同的需求。写代码更多关注模型能力差距，谁强换谁，唯一需要考虑的是价格、成本。另一种是：项目里那套提示词、示范样例、输出格式的约定，全是照着一个模型的脾气磨了几个月的，搬到新模型上，这些调校能不能保持。但现实情况就是这样，同样一句指令，原来的模型懂，新的模型不懂。当时我们管这叫兼容性问题，靠重新调参硬磨了回来，磨到什么程度算恢复，其实也没有裁判，全凭人看着像。后来读到人民大学 EvoOntology 项目（arXiv 2609.15779）的一组实验，才发现这不是我们项目特有的事故，是有数字的规律。而且实验回答了一个我们当时没顾上想的问题：项目里攒下的那些业务知识——报告怎么组织、数据口径怎么取、哪些数字该进哪张表——换模型的时候，哪些是真的作废了，哪些根本没动过？上一篇文章里我核过这个项目的评测模块源码，谈的是它怎么让知识库自己长大；这篇只谈迁移——模型换了，长出来的东西还剩多少。

换个模型，知识资产作废一半

四个大模型养同一份知识库，最后重合度不到 0.62；交叉使用，成绩至少掉 6.6 分。换个模型，你攒的知识资产作废一半——但最值钱的那部分，恰恰最不怕模型换代。一篇讲清哪些带得走、哪些带不走。

人工智能

模型更换导致知识库迁移成本高，但实验表明：字段映射、探针证据、标准答案等记录型资产不随模型作废，提示词等生成型资产才受影响。通过拆分账本、多模型并行策略，可让迁移从事故演练变成普通发版，保值率取决于记录比例。

数据库

智能体

路由

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

换个模型，知识资产作废一半-腾讯云开发者社区-腾讯云

换个模型，知识资产作废一半

换个模型，知识资产作废一半

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐