我做AI模型版本对比，最怕两种场面。一种是会议室里只放一张榜单，大家盯着分数吵“谁更强”。另一种是业务同事说“先升级再说”，工程同事沉默，安全同事皱眉。版本对比看起来是技术活，落到工作里是决策活。它帮我们少拍脑袋，也帮我们控制成本、风险和迁移代价。它的边界同样清楚：一次评测说明不了所有场景，供应商宣传页更说明不了。
这一章我想把框架搭起来。目标怎么定，版本演进看哪几类变化，对比结论怎么用。后面章节会展开维度、方法、迁移和治理。你先记住一句话：AI模型版本对比不是为了选出一个永远正确的模型，是为了在具体场景里做出可解释、可回滚、可复评的选择。
1.1 版本对比的目标：能力、成本、风险与场景适配
我判断一次AI模型版本对比有没有价值，先看它要支持什么决策。新产品选型，关注能力上限和场景适配。已有系统升级，关注能力回退、接口兼容和迁移成本。采购谈判，关注单位Token成本、资源占用和供应商依赖。安全评审，关注幻觉率、有害输出、隐私条款和审计能力。同一个新版本发布，产品经理看到的是回答更顺，工程团队看到的是延迟和吞吐，法务同事看到的是数据处理条款变了。多角度摆在一起，对比才不容易偏。
我习惯把对比目标写成四栏：能力、成本、风险、场景适配。能力栏写任务通过率、长尾表现、格式稳定性。成本栏写延迟、吞吐、上下文窗口和单位Token成本。风险栏写幻觉、内容安全、隐私和合规。场景适配栏写语言、输入长度、工具调用、部署环境。四个栏位不是平均用力，场景会决定权重。客服问答对延迟敏感，合同审阅对准确和可追溯敏感，营销文案对风格和成本敏感。拿一套权重打天下，结论很容易失真。
我会先问一句：这次对比要支持哪个决策？这句话很土，能省很多争论。决策清楚，评测集、评分量表、验收标准才有落点。
1.2 版本演进的常见类型：参数规模、架构、训练数据、对齐策略与推理优化
我跟踪模型版本更新，会把它拆成五类变化：参数规模、架构、训练数据、对齐策略、推理优化。参数规模变化影响容量和成本，大模型能处理更复杂的任务，资源占用也会上去。架构变化常带来上下文窗口、推理效率和工具调用能力的变化。训练数据变化影响领域知识和语言覆盖。对齐策略变化影响拒答尺度、回答风格和格式遵循。推理优化影响延迟、吞吐和部署成本，量化、蒸馏、缓存策略都在这一类里。
同一场版本发布会上，不同角色关注点不一样。产品同事会问“回答是不是更自然，长文总结是不是更稳”。工程同事会问“吞吐有没有提升，显存占用降没降，流式输出还稳不稳”。安全同事会问“拒答边界有没有变，系统提示词被绕过的概率有没有变”。我坐在中间，会把这些问题收进同一张对比表。版本号相同，部署形态也可能不同。API版、私有化权重版、量化版，能力表现和成本结构会拉开差距。对比时我盯真正要上线的形态，不拿演示环境替代生产环境。
我判断版本类型决定评测侧重点。参数和架构升级，多看通用能力、长上下文和吞吐。训练数据和对齐策略变化，多看领域任务、安全边界和输出格式。推理优化版本，多压测延迟、并发和单位成本。这个判断不绝对，能帮我把评测资源花在刀刃上。
1.3 对比结论的使用原则：基准测试不替代业务验证，关注版本差异与适用边界
我对基准测试的态度很明确：拿它当筛子，不拿它当判决书。公开榜单能帮我缩小候选范围，能暴露明显短板。它也有局限，评测污染、提示词敏感、任务分布偏通用，业务里的长尾输入未必覆盖。我的做法是先用基准测试做初筛，再拿业务样本做验证。业务样本不必多，要真实，要包含难例、边界输入和失败案例。客服记录、工单、合同片段、用户追问，这些材料比漂亮榜单更接近日常。
我要求对比报告写清适用边界。任务类型是什么，输入长度在哪个区间，语言覆盖哪些，是否依赖工具调用，部署环境是API还是私有化，评测时间窗口是哪一段。版本差异也要写透：能力有没有回退，输出格式有没有变化，拒答策略有没有收紧，价格和条款有没有调整。报告里不写这些，读者会把一次结论当成万能结论。研发看报告找风险，采购看报告算成本，法务看报告核条款，三种视角都需要边界信息。
我常对团队说，AI模型版本对比的落点不是“谁更强”，是“在哪个场景、哪套约束下更合适”。边界写清楚，结论才可复用。选型、迁移、持续评测和治理机制，后面章节会一项项展开。
我做过几次模型版本选型，发现一个挺有意思的现象：同一份评测报告，产品同事先翻“效果”，工程同事先翻“延迟”，安全同事先翻“拒答”，采购同事先翻“价格”。每个人都在找自己关心的那一页。AI模型版本性能对比的核心维度，如果只写一个总分，会议室里一定会吵起来。我的做法是把对比拆成四组指标：效果能力、效率与成本、安全与合规、工程可用性。四组指标像四张底片，叠在一起才能看清一个版本的真实轮廓。
这四组指标不是平均分。场景不同，权重差得很远。客服机器人对延迟和成本敏感，合同审阅对准确率和可追溯敏感，内容生成对风格稳定和内容安全敏感。指标体系要能调权重，也要能解释为什么这样调。下面我把四组维度拆开讲，讲的是我实际看什么、怎么记、怎么避免被单一指标带偏。
2.1 效果能力对比：通用基准、领域任务、长尾场景与鲁棒性
我看效果能力，会先过一遍通用基准。公开榜单、行业评测集、多任务总分，这些材料能帮我快速筛掉明显不合适的版本。通用基准有它的价值，它覆盖语言理解、推理、代码、数学这些基础能力，适合做初筛。我也会提醒自己：榜单分数高，不等于我的业务任务就稳。榜单题目和客服工单、合同条款、商品描述之间隔着一段距离。通用基准是筛子，不是判决书。
领域任务是我花时间最多的地方。我会从真实业务里抽样本，按任务类型分组：意图识别、信息抽取、摘要、问答、改写、代码生成。每组样本里放一些难例，放一些边界输入，放一些历史上失败过的案例。产品同事看回答是否自然、格式是否稳定，业务同事看是否解决实际问题，我则看通过率、错误类型和失败集中在哪里。领域任务对比最怕样本太干净，干净样本测不出版本差异，也测不出回退风险。
长尾场景和鲁棒性，我通常会单独拉一张表。长尾场景包括低频意图、超长输入、混合语言、含错别字的口语、带表格的文档。鲁棒性看版本在输入扰动下的表现：换一种问法、加一段无关信息、调整标点、插入干扰句，回答是否还稳。我会做小规模扰动测试，记录输出漂移和格式崩溃的比例。长尾场景不需要很多样本，需要真实和刁钻。一个版本在通用榜单上涨了两分，在长尾场景里掉了一截，这种差异比总分更有决策价值。
2.2 效率与成本对比：延迟、吞吐、上下文窗口、单位Token成本与资源占用
效率与成本这组指标，工程同事最有发言权。我一般会拉上他们一起看延迟分布，不只看平均延迟。平均延迟好看，尾延迟可能很难看。线上用户体验往往被P95、P99延迟影响。流式输出场景还要看首Token延迟，用户等首字的时间和等完整回答的时间，感受完全不一样。吞吐量也要看并发下的表现，单请求测出来的数字，放到生产流量里会变形。
上下文窗口是另一个容易被忽略的维度。窗口变大，能塞进更多文档和对话历史，听起来很美。窗口变大也会带来成本上升和注意力稀释。我会测不同输入长度下的效果和延迟：短输入、中等输入、接近窗口上限的输入。长上下文任务里，关键信息放在开头、中间、结尾，回答质量有没有差别。单位Token成本要按输入和输出分开算，有的版本输入便宜、输出贵，有的版本反过来。资源占用看显存、CPU、内存和部署形态，API版和私有化版的成本结构不一样。
我还会把成本拆成“看得见的账单”和“看不见的账单”。看得见的是Token费用、服务器费用。看不见的是重试成本、人工复核成本、迁移适配成本。一个版本单价低，输出格式老要修，重试率一高，总成本就上去了。采购同事喜欢问“每百万Token多少钱”，我会补一句“按我们的任务分布和重试率算，实际单任务成本是多少”。这句话能把讨论拉回业务口径。
2.3 安全与合规对比：幻觉率、有害输出、隐私保护、内容安全与审计能力
安全与合规这组指标，我通常请安全同事一起定测试集。幻觉率要看任务类型，开放问答、事实核验、合同条款引用，幻觉的代价不一样。我会准备一组带标准答案的事实性问题，也准备一组没有标准答案的开放问题，看版本是“不知道就说不知道”，还是硬编一个答案。有害输出测试覆盖歧视、暴力、违法引导、诱导性内容这些类别。拒答尺度也要看，拒得太松有风险，拒得太紧业务没法用。
隐私保护看输入数据怎么处理，是否用于训练，日志保留多久，缓存策略是什么。内容安全看版本对敏感话题的边界是否稳定，系统提示词被绕过时的表现。审计能力看调用日志、内容审核记录、版本变更记录能不能追溯。法务同事会盯供应商条款变化，数据处理协议、跨境传输、责任边界，这些内容在版本升级时经常被忽略。安全对比报告里，我会把“测试结果”和“条款变化”分开写，前者是技术表现，后者是合规约束。
我见过一种误区：安全测试只测一轮，测完就盖章。版本迭代后，对齐策略可能调整，拒答边界可能变化，安全表现会漂移。我的做法是每次版本对比都跑同一套安全回归集，记录通过率和失败样本。失败样本要人工复核，区分真风险和误判。安全指标不适合只看一个总分，它需要分类看、看趋势、看边界。安全同事常说“这个版本更听话了”，我会追问“听话的边界在哪里，越界时会不会拒”。这句话有点较真，能问出真东西。
2.4 工程可用性对比：稳定性、可观测性、工具调用、生态兼容与部署约束
工程可用性这组指标，决定一个版本能不能顺利上线。稳定性看错误率、超时率、限流表现、长连接保持能力。我会做一段时间的压测和浸泡测试，看版本在持续流量下会不会性能衰减。可观测性看日志字段、指标暴露、追踪链路、错误码是否清晰。一个版本效果再好，出了故障查不到原因，工程团队会很痛苦。工具调用看函数调用准确率、参数格式稳定性、多工具编排能力。生态兼容看SDK、框架、向量数据库、监控系统的适配程度。
部署约束经常被放到很晚才讨论，我习惯提前问。模型能不能私有化部署，显存要求多少，支不支持量化，支不支持国产芯片，网络隔离环境能不能跑。API版要关注区域可用性、配额限制、供应商锁定风险。私有化版要关注镜像大小、启动时间、升级路径。工具调用和生态兼容这两项，在版本升级时特别容易出问题。参数名改一个，输出格式变一下，上游业务就可能报错。
我会把工程可用性指标做成一张检查表，每项打“通过、有条件通过、不通过”。有条件通过的要写清条件：需要改适配层、需要加缓存、需要调整超时设置。这张表交给研发负责人和运维负责人一起看。工程可用性不是“能用就行”，它关系到上线后的维护成本和故障恢复速度。一个版本在效果上赢两分，在工程可用性上多三个坑，我的选择通常会偏向后者。
我把这四组指标放在一张看板上，每次版本对比按场景调权重。效果能力看任务通过率和失败类型，效率与成本看延迟分布和单任务成本，安全与合规看回归集和条款变化，工程可用性看检查表和部署约束。指标是工具，决策还是人来拍。拍之前，我会问一句：这次对比要支持哪个决策，失败了我们能不能回滚。问完这两句，指标体系才不会变成一堆漂亮数字。
前面把指标维度拆完了，接下来要面对一个更实际的问题：怎么测。我见过不少团队，指标列得挺全，真到跑评测的时候，东拼西凑，数据口径对不上，结论也没法复现。评测方法这件事，说白了就是把“我觉得新版本更好”变成“有证据表明新版本在哪些场景更好，好多少，值不值得换”。这套东西不复杂，但每个环节都有坑。
我自己的习惯是先想清楚这次评测要回答什么问题，再去搭评测集。问题没想清楚，数据集越大越浪费。下面按评测设计、自动化与人工怎么配合、统计上怎么站得住、怎么从离线走到在线这四块，讲我踩过的坑和攒下来的做法。
3.1 评测设计：场景拆解、数据集构建、评分量表与盲测机制
评测设计最容易犯的错，是一上来就建数据集。我一般先做场景拆解。把业务链路摊开，找出模型真正参与决策的环节：是意图分类，是信息抽取，是生成回复，还是多轮对话里的追问。每个环节再拆输入类型和输出要求。这一步做完，评测集的骨架就有了。场景拆得细，后面评分量表才好定，不然一群人对“好回答”的理解都不一样，测出来的分数没法比。
数据集构建我会遵循两个原则：真实优先，难例优先。真实样本从线上日志里抽，脱敏后按任务类型分组。难例单独标出来，包括历史失败样本、边界输入、格式要求复杂的任务。每个版本跑同一套数据，数据版本也要打标签，方便回溯。样本量我一般按任务类型分配，核心任务多放，长尾任务少而精。评测集不是越大越好，覆盖到位、难易搭配合理，比堆几万条普通样本有用得多。
评分量表要提前定，而且要定得具体。通用维度比如准确性、完整性、格式合规、语气适配，每个维度给三到五档描述，每一档都有例子。主观维度尽量拆成可观察的行为，比如“是否引用原文”“是否给出处”“是否承认不知道”。盲测机制我也会加上：把版本信息隐掉，让评测人员不知道自己在评哪个版本。人一旦知道是“新版本”，打分容易手松。盲测能压掉一部分这种偏差。
3.2 自动化评测与人工评估结合：LLM-as-Judge、A/B测试与专家复核
纯人工评测跑不快，纯自动评测信不过，我一般两条腿走路。自动化这块，规则类指标先上：格式对不对、字段全不全、JSON能不能解析、关键词命中没有。这些用脚本就能跑，成本低，结果稳。开放式回答用LLM-as-Judge做初筛，让一个裁判模型按评分量表打分，再抽一部分人工复核。裁判模型要固定版本、固定提示词、固定评分标准，不然今天用A模型当裁判，明天换B模型，分数就没法横向比。我还会做裁判一致性检查，同一批样本让裁判跑两遍，看分数波动大不大。
人工评估我分两层。一层是业务同事做快速标注，看回答能不能用、解不解决问题。另一层是专家复核，针对争议样本和高风险样本。专家复核不追求量大，追求判得准。A/B测试放在有真实流量的场景里做，用户随机分组，看点击、采纳、追问率这些行为指标。A/B测试的好处是贴近真实使用，坏处是周期长、干扰因素多，短期指标不一定反映长期体验。
我的经验是自动化负责覆盖面和一致性，人工负责判断力和边界。LLM-as-Judge适合做大批量初筛和回归测试，专家复核适合定标准和校准。两边的结果对不上时，我会拉出分歧样本逐条看，往往能发现评分量表里没写清楚的地方。这种分歧本身就是改进评测体系的好材料。
3.3 统计显著性与可复现性：样本量、置信区间、版本回放与评测环境控制
分数差两分，是真的好两分，还是随机波动，这个问题不搞清楚，版本对比就是玄学。我一般会先估样本量。核心任务至少几百条，重要场景上千条，长尾场景可以少一些，但要记录样本量，方便后面算置信区间。两个版本对比，我会看差异的置信区间是否跨零，跨零就说明差异不够稳，不能拿来做决策依据。小样本上的大差距，尤其要谨慎，很可能只是抽样运气。
可复现性是评测的底线。我会把评测环境固定下来：模型版本号、推理参数、提示词版本、数据集版本、评测脚本版本，全部打标签存档。温度、top_p这些参数统一设置，能设随机种子的尽量设。版本回放这件事我特别看重，任何一个历史评测结果，要能拿当时的配置重新跑出来。做不到回放，后面出了争议只能靠记忆吵架。评测环境也要控制，网络波动、限流、缓存命中都会影响延迟和结果，跑评测时尽量隔离这些干扰。
我还会做重复评测。同一个版本，同一套数据，隔几天再跑一遍，看分数稳不稳。稳定说明评测体系可靠，波动大说明有隐藏变量没控制住。有的版本在特定提示词下表现很好，换个提示词就掉下来，这种敏感性也要记录。统计显著性是给决策用的，不是给报告好看的。样本量不够就老实说不够，置信区间宽就老实说宽，别硬下结论。
3.4 从离线评测到在线实验：灰度验证、指标看板与业务收益归因
离线评测跑完，分数漂亮，不代表上线就顺。我一般会安排灰度验证。先放一小部分流量给新版本，观察错误率、延迟、用户反馈这些线上指标。灰度期间双跑对比很有用：同一批请求同时打给新旧版本，对比输出差异和下游影响。差异大的样本人工看一遍，确认是改进还是回退。灰度比例逐步放大，每一步都设观察窗口和回滚条件。
指标看板要跟着灰度一起上。技术指标看延迟分布、错误率、超时率、Token消耗；业务指标看任务完成率、人工介入率、用户满意度、投诉量。看板上的指标要和离线评测的维度对得上，不然两边结论打架，没人知道信哪个。业务收益归因这件事比较难，我一般用分组对比加时间窗口的方式估算，把版本切换的影响和其他运营动作尽量分开。归因不追求精确到小数点，追求方向对、量级合理。
离线评测和在线实验的关系，我理解成“离线找方向，在线验结果”。离线评测适合快速筛版本、做回归、压边界，在线实验适合验证真实流量下的综合表现。两边结论不一致时，我会优先相信在线数据，同时回头检查离线评测集是不是偏了。灰度跑完、指标达标、回滚预案就位，这个版本才算真正通过评测。评测方法的价值不在于跑出多少分数，而在于让每次版本决策都有据可查、有路可退。
评测分数出来，团队里有人拍桌子说换，有人摇头说再等等。这种场面我经历过好几次。真到了要动手迁的时候，事情比评测阶段复杂得多。评测是在一个受控环境里比高低，迁移是把新版本塞进一套已经跑起来的生产系统里，中间牵扯接口、提示词、缓存、日志、合规条款、监控告警，哪一环没对上，都可能出事故。我见过迁移当天响应格式全乱的，也见过上线三天才发现某个低频场景答得一塌糊涂的。这章讲讲迁移这件事我会怎么安排。
4.1 迁移前评估：兼容性、能力回退风险、成本收益与供应商依赖
迁移动手之前，我会先做一轮务实的评估，不是再看一遍评测报告，是把注意力放到“换过去会碎什么”上。兼容性排第一个。接口签名有没有变，请求参数有没有废字段，返回结构是不是还一样，流式输出和分块格式有没有差异。这些看起来是工程细节，实际最容易在迁移当天炸。我一般会拉一个接口对照表，把新旧版本的入参、出参、错误码、限流规则逐项列出来，标出差异点。
能力回退风险要单独拎出来说。新版本平均分高，不代表每个场景都好。评测里看到的提升往往集中在少数重点任务上，长尾场景反而可能悄悄变差。我会把历史失败样本翻出来，专挑新版本跑一遍，看有没有变糟的。那种“整体提升、局部倒退”的情况特别常见，尤其是格式严格、逻辑链条长的任务。能力回退的代价有时候比收益大，上线后用户投诉一批，再解释就晚了。
成本收益得算清楚。单价便宜不等于总成本便宜。新版本可能绕更多弯才给出答案，Token消耗涨了，或者延迟上去了要加机器。我会按真实流量换算单位成本，把推理费用、缓存开销、重试成本都算进去，再和研发投入、迁移工期放一起看。供应商依赖这块我越来越看重。模型版本更新节奏、弃用政策、区域可用性、合同里关于停服的条款，都得提前问清楚。绑死在一个随时可能变策略的供应商身上，迁移成本会越积越高。
4.2 提示词与接口适配：版本差异、参数变化、输出格式与工具调用兼容
提示词这件事，很多人以为改个模型名就行了，其实没那么轻松。不同版本对提示词长度、系统消息权重、指令跟随的敏感度都不一样。旧版本管用的那套措辞，放到新版本上可能失效，也可能过度执行。我一般会在迁移前把核心提示词做一轮适配测试：同样的提示词分别打给新旧版本，比输出结构、比遵循度、比冗余度。发现有差异的地方，逐条改，改完再跑一轮回归。
参数变化要盯紧。温度、top_p、max_tokens、停止词、频率惩罚这些，新版本不一定行为一致。有些版本对温度调低之后的确定性表现更好，有些版本温度设太高就开始跑偏。输出格式更是个大坑。旧版本稳定吐JSON，新版本偶尔带一段解释在前头，解析脚本当场崩掉。我会在迁移时加一层输出校验和修复逻辑，能解析就直通，解析失败走兜底或者重试。JSON模式、结构化输出这些能力如果有，尽量用上。
工具调用和函数调用这块，版本之间差异经常被低估。参数Schema、多工具并发调用、返回结果的嵌套层级，都可能变。我吃过的亏是一次升级之后，工具调用的入参类型从字符串变成了对象，下游全报错。后来我养成了习惯：迁移前把每个工具的调用样本跑一遍，比对入参出参，写一组自动化断言。工具调用一旦出问题，链路是断的，不是降级那种软性影响，而是直接报错停摆。
4.3 数据与安全合规迁移：缓存、日志、隐私处理与供应商条款变化
数据这块最容易被当成“技术之后再说”的事，我会把它提到迁移前。缓存先看。提示词缓存、结果缓存、语义缓存的键值设计是不是还对得上新版本。有个细节很多人忽略：换了模型版本，旧缓存里的结果是不是还该继续返回，返回的话质量口径就混了。我的做法是迁移时给缓存键加上版本标识，新旧缓存隔离，避免串味。
日志和隐私处理要重新过一遍。新版本可能默认开启某些日志留存或者遥测，也可能对输入长度、敏感字段处理有变化。日志里存了什么、存多久、谁有权限看，这些都值得核对。涉及用户数据脱敏的规则，要确认新链路每个环节都走同一条脱敏通道。我见过升级后多了一个中间代理，把未脱敏的原始请求又记了一遍。合规上这种漏洞很难补，一旦被发现就很被动。
供应商条款的变化也要看。隐私政策、数据使用范围、训练用途、跨境传输限制，版本升级有时候会顺带触发条款更新。法务和采购要提前看过，别等上线了才发现新版本在某些地区不可用，或者某些数据类型不允许传输。这一块我一般会拉个清单：涉及哪些数据类型、存在哪个区域、有没有出境、供应商承诺是什么。清单过完，心里才有底。
4.4 灰度发布与回滚机制：监控告警、双跑对比、应急预案与迁移验收
迁移落地我坚持灰度。全量切换风险太大，一次事故可能就是整条业务线瘫掉。灰度我会分层放：先是内部环境全量，再是低风险业务线，再是核心业务线的少量流量，一步步放大。每一步都设观察窗口，比如半天到一天，看错误率、延迟分布、Token消耗、任务完成率这些指标有没有异常波动。观察窗口内指标不稳定，就不往上放。
双跑对比在灰度阶段特别值钱。同一批真实请求同时打给新旧版本，对比输出差异。差异里有一类是“新版本答得不一样但也可以”，有一类是“新版本明显错了”。我会让业务同事看差异样本，把回退型差异单独列出来，作为是否继续放量的判断依据。监控告警要覆盖技术指标和业务指标两头。技术侧看错误率、超时、限流触发；业务侧看人工介入率、用户反馈、投诉量。阈值提前定好，触发就停或者降级。
回滚机制必须在上线前验证过，不能写个预案就完事。旧版本服务保持可用，流量切换开关能秒级生效，缓存和数据库的状态能兼容两个版本。我一般会做一次真实回滚演练，把流量切回旧版本，看系统是否正常。迁移验收也别只看技术指标。业务方签字确认核心场景表现达标，安全合规确认数据链路没问题，运维确认监控告警到位，这几条都过了，迁移才算结束。验收清单我会写得很具体，避免“感觉差不多就上线”这种情况。
迁移做完，系统跑稳了，很多团队这时候就松一口气，把评测报告往共享盘一扔，这事算翻篇。我吃过这个亏。半年后供应商推新版本、业务场景悄悄变了、当初选型的理由没人记得，又要从头论证一遍，重复踩坑。评测的价值不在报告本身，在于能不能沉淀成决策依据和长期机制。这章讲怎么把一堆对比结论真正落到地上。
5.1 分场景选型矩阵：质量优先、成本优先、合规优先与混合部署策略
我越来越不信“全局最优模型”这个说法。同一个模型，在客服问答上表现稳，放到代码补全就平庸；便宜的那个跑简单分类绰绰有余，一碰长文档摘要就开始漏要点。选型不能一刀切，得把业务拆成场景，按场景定权重。我一般会拉一张矩阵：行是业务场景，列是质量、成本、延迟、合规、工程可用性几个维度，每个场景给各维度打分并标权重，跑出来的不是单一冠军，是一组“这个场景适合谁”的答案。
质量优先的场景，比如对外客服、合同审阅、医疗辅助问答，我会把准确率和鲁棒性的权重压到最高，成本往后放。这类场景一次答错的代价远高于推理费用的差价。成本优先的场景，比如海量日志分类、标签打标、简单意图识别，我会先设一条质量及格线，过线的模型里挑最便宜的，甚至考虑小模型加规则兜底。合规优先的场景更直接，数据不能出境、不能进第三方训练的，先把不满足的模型剔掉，剩下的再比。这条剔除线要提前划，别等选完了才发现某版本在合规上根本走不通。
混合部署是我现在更常用的打法。核心链路用质量最好的那一档，边缘的、量大的、容错的场景用便宜档，中间加一层路由。路由规则可以按请求类型、按用户等级、按实时负载来切。我做过一个项目，主力模型负责复杂推理，简单查询走小模型，整体成本降了快一半，用户几乎没感知。混合部署的代价是运维复杂度上去了，路由层要做监控、要做降级兜底，版本管理也从管一个变成管一组。这套东西得有工程能力兜着，团队小、人力紧的时候别硬上，老老实实选一个均衡档跑稳更划算。
5.2 建立版本档案与评测基线：可复用评测资产、对比报告与知识库
每次评测都从零开始搭数据集、写评分脚本，这种事干两回我就受不了了。后来我强制要求把评测资产沉淀下来。数据集按场景归档，标注规范写清楚，评分量表和判定标准存成文档，自动化脚本进代码仓库，跟着版本走。这套东西建起来费点劲，用起来省事太多。新版本来了，数据集直接复用，跑一遍就能和历史结果横向比，不用再花两周重新造轮子。
版本档案我会做得比较细。每个用过的模型版本建一条记录：版本号、接入时间、在哪些场景用、当时的评测分数、选它的理由、已知的短板、供应商的支持周期。这份档案的价值在半年后体现得最明显。有人问“为什么当初选这个不选那个”，档案一翻就有答案，不用靠回忆吵架。对比报告我也要求留档，不光是最终结论，中间的分歧、被否掉的方案、当时的假设条件都记下来。结论会过时，假设和推理过程往往还有参考价值。
知识库这块我倾向于轻量起步。一个共享文档加一套目录规范就能跑起来，别一上来搞重型平台，维护成本压死人。关键是养成习惯：每次选型、每次迁移、每次复评，产出的结论和踩过的坑都往里放。我见过最有效的做法是让写报告的人顺手写三条“下次遇到类似情况要注意什么”，几句话就行，比长篇大论管用。积累半年，这个库就成了团队自己的经验池，新人接手也能少走弯路。
5.3 持续监控与定期复评：模型漂移、供应商更新、生命周期管理与治理闭环
模型上线不是终点。我见过跑得好好的系统，三个月后效果慢慢往下掉，查来查去是业务数据分布变了，用户问的东西和当初评测时不一样了。这就是模型漂移，跟模型本身没关系，是场景在动。监控得盯住这个。我会在线上采样一部分真实请求，定期跑人工抽检或者用评测集回测，看质量指标有没有下滑趋势。输入分布的变化也要看，新出现的问法类型、长度分布、语言混杂情况，这些是漂移的早期信号。
供应商那边也不能撒手。模型版本会更新，旧版本会弃用，定价会调，条款会改。我一般会跟供应商的支持周期表对齐，提前把弃用日期记进日历，留足迁移窗口。新版本发布后不急着上，先拿自己的评测集跑一遍，和历史基线比，差异大的话看差异在哪些场景，再决定跟不跟。这条流程固化成制度，比靠个人盯邮件靠谱得多。生命周期管理说白了就是给每个在用版本标好“什么时候该评估、什么时候该换”，到期自动触发复评，别等到服务突然停掉才手忙脚乱。
治理闭环是我最看重的一环。选型、评测、上线、监控、复评，这几步得串成一个圈，每一圈的结果回流到下一圈的决策里。谁负责评测、谁拍板选型、谁盯线上指标、谁触发复评，角色要清楚，不然出了问题互相推。我习惯每季度拉一次复盘，把这一季的版本表现、漂移情况、供应商动态过一遍，该调的调，该换的换。这套机制跑顺了，模型管理就从救火变成了例行维护，团队也不会每次都被版本更新打个措手不及。
