聊模型选型这事儿，我踩过的坑比走过的路还多。早几年团队一上来就问“哪个模型最强”，大家翻榜单、比参数，折腾一圈儿上线，结果发现自己要的根本不是那个能力。有次做智能客服，我们拿了个推理能力爆表的模型，推理链一长，响应慢到用户直接关窗，那个月的投诉翻了三倍。后来我才明白，选型的第一步根本不是看模型，是看自己——你到底想让AI替你干什么活。
1.1 从业务目标到模型任务：明确能力边界
我习惯把业务目标先翻译成模型任务。想清楚这句话：用户输入什么，模型输出什么，中间需要的核心能力落在哪儿。生成、理解、推理、多模态，这四类能力看着抽象，落到具体场景里区别特别大。写营销文案偏生成，做合同审阅偏理解加抽取，做复杂工单分诊就要一点推理，而图片质检、视频内容审核这类活，绕不开多模态。
能力边界这事儿，我的经验是别贪心。一个模型样样都行，往往样样都只是及格。我们做过一个知识库问答项目，起初想用一个通用大模型包打天下，既要它读懂长文档，又要它精准回答，还得顺手生成摘要。上线后问题暴露得很清楚：长文档理解还行，精确引用就开始飘。后来拆成两段，检索增强负责找证据，生成模块只负责组织语言，效果反而稳了。
说白了，先写清楚业务目标，再把它拆成一个个能力需求，给每个需求标上“必须有”和“有了更好”。这张清单，后面做评估矩阵时你会反复用到。没有它，选型就是凭感觉。
1.2 AI模型选择需要考虑哪些因素
准确性当然排前面，可它的定义得跟业务对齐。客服问答的准确性是答对率，内容生成的准确性更接近事实一致性和风格匹配。我见过团队拿通用考试分数当准确性指标，上线后发现在自己的垂直领域里错得离谱。领域测试集，得自己攒。
响应时延这一点，很多技术出身的同学容易低估。人机对话里超过两三秒，用户就开始怀疑人生；批处理任务里几十秒都能忍。上下文长度也别光看宣传数字，模型宣称支持三十二万token，真正在长文中间找信息时，召回质量会掉。我一般会拿自己业务里最长的真实输入去测，测出来的才算数。
稳定性、合规与数据安全、可集成性、生态与支持，这几项看起来不性感，出事时最要命。供应商限流策略一变，你的产品可能直接瘫半天。数据条款里那句“用于服务改进”，法务看了会皱眉。SDK好不好接、文档全不全、社区活不活跃，决定了你后面几个月的开发速度。我现在的习惯是，把这些非功能因素单独列一栏，跟能力指标一起打分，别让它们在技术讨论里被一句“问题不大”带过去。
1.3 建立权重化评估矩阵
评估矩阵这东西，写出来像表格，用起来像过滤器。我的做法是先划硬性约束，再谈优化目标。硬约束就是不满足直接出局的项，比如数据不能出境、必须支持私有化部署、响应时延必须低于一秒。这些条件先筛一遍，候选名单一下子能砍掉大半。剩下的再按权重打分。
权重怎么定，我通常拉上业务、研发、运维三拨人各打一轮，吵一架比一个人闷头定靠谱。准确性给多少分，成本给多少分，稳定性给多少分，背后其实是业务阶段在说话。冷启动阶段我会把成本和迭代速度权重调高，成熟期再往稳定性和合规上压。
可量化验收指标是矩阵的灵魂。别写“响应较快”“准确性良好”这种话，写成“P95时延低于800毫秒”“领域测试集准确率不低于92%”“单次调用平均成本低于0.01元”。指标写不出来，说明需求还没想清楚。这一步偷懒，后面灰度上线时你会付出双倍代价。
1.4 常见选型误区
唯参数规模论是我见过最普遍的误区。参数大不等于适合你，一个大模型在小任务上可能又贵又慢，还容易过度发挥。我们测过一个七百亿参数的模型做短文本分类，效果跟一个几十亿的专用小模型打平，成本差了十几倍。参数规模是个参考，不是结论。
只看榜单分数同样危险。公开榜单的题目跟你的业务分布往往差很远，榜单前十的模型在你自己的测试集上未必排得进前五。我现在基本把榜单当“初筛工具”，用来排除明显不行的，绝不用来定胜负。
忽视推理成本和运维复杂度，这个坑特别隐蔽。API单价看着便宜，token消耗一上去，账单能吓人一跳。开源自部署省了调用费，可GPU集群、模型更新、故障排查这些隐性成本，很多团队算漏了。我的建议是把总账算清楚，把未来一年的量级估进去，再对比方案。选型选的不只是模型，是一整套你要长期养着的东西。
每次有人问我“这个模型和那个模型到底哪个好”，我都先回一句：看你要比什么。性能这事儿特别有意思，同一批模型放在不同人手里，测出来的结论能彻底相反。我们组去年做过一次内部横评，三个模型五个任务，跑了整整两周，最后发现没有一个模型在所有维度上都赢。那张对比表到现在还在我电脑桌面上，每次有新项目我就翻出来重新看一遍。比模型这件事，方法比结论重要得多。
2.1 性能对比维度
通用基准我现在只看两样东西，一样是它能不能把明显不该丢的分丢掉，另一样是它跟榜单上其他模型的差距是不是稳定。MMLU这类考试分数参考价值有限，我拿它做粗筛，筛完就扔。真正花时间的是领域任务测试集，我自己攒了几百条业务真实数据，从用户原话里捞出来的那种，错别字和口语都在里面。拿这个测出来的数字，我敢拿去跟老板汇报。
鲁棒性这块我吃过亏。有个模型在我们干净测试集上准确率九十二，上线第二天用户输入里夹了点emoji和繁体字，掉到七十多。后来我养成了一个习惯，拿同一批问题做各种扰动，加噪声、改语序、混语言、砍掉一半上下文，看它掉多少分。掉得少的模型，运维半夜被叫起来的概率也小。
幻觉率我没法给一个绝对数字，我的做法是抽样人工标。每批生成两百条，让人去核事实，标出无中生有、张冠李戴、过度外推这几类。长文本这边，我重点测中间位置的信息召回，把关键事实埋在长文的三分之一处，看模型还能不能捞出来。多模态就测图文对齐的精度，尤其是表格截图里的数字识别，这块各模型差距挺明显。
2.2 成本对比维度
API单价是最容易看的那一项，也最容易把人骗进去。我现在算成本一律按“完成一个业务任务要花多少钱”来算，不按每千token多少钱来算。原因很简单，有的模型单价低但话痨，同一个任务消耗的token是别人的三倍。我们做过一个摘要任务，单价便宜的那个模型总账反而贵了四成。账单这东西，得按任务算，按天算，按月算。
推理时延得拆开看，首token时间和整段输出时间完全是两回事。流式输出的场景里，用户感知最强烈的是第一个字什么时候出来。我们测过一个模型首token快、但后面吐字慢，体验反而比一个整体慢一点但匀速的模型差。批量任务里我更关心吞吐，单次慢没关系，并行跑起来总时长能接受就行。
微调成本经常被漏算。训练本身的费用看得见，数据标注、清洗、多轮实验的GPU占用、评估的人力，这些加起来往往比训练费高好几倍。部署成本里头的显存占用、并发能力、冷启动时间，这些在POC阶段不显眼，上量之后全变成真金白银。
2.3 总拥有成本与性价比分析
总拥有成本我习惯拉一张十二个月的表，把调用费、基础设施、人力、迁移风险全摊进去。云端API前期最省事，适合验证期和流量波动大的场景。我见过一个团队业务量没起来先自建集群，GPU闲了半年，那笔钱够买两年API还有富余。开源自部署的边界在哪儿，我的判断标准是调用量是否稳定超过某个阈值，以及数据是否绝对不能出内网。两条都满足，自建的账才算得过来。
混合方案是我们目前用得最多的。核心敏感数据走私有部署的小模型，非敏感的高难度任务走云端大模型，路由层做一个简单的分流。这套架构的好处是灵活，坏处是运维复杂度上来了。两套系统的监控、日志、版本更新都得管，没有专职运维的团队要慎重。
性价比这事儿不能只看单点。有的方案单次成本高一倍，但省掉两个人力，总账反而更划算。我倾向于把成本折算成一个业务指标，比如“每解决一个用户问题花多少分钱”，这样跟业务方沟通的时候不用解释token是什么东西。
2.4 构建对比实验
小样本A/B测试是我的起手式，几十条到一两百条真实case，两三个候选模型并行跑，人工盲评。这个阶段不追求统计显著，追求的是快速排除明显不行的。我们有一次测下来，一个候选模型在三十条样本里就暴露了严重的格式问题，直接省掉后面两周的完整评测。
离线评测我会做得细一些，固定测试集，固定prompt模板，固定的评分脚本加人工抽检。跑完出一张表，每个模型在每个维度上的分数、成本、时延，一栏一栏摆着。在线灰度的阶段我通常放百分之五到十的流量，跑一周左右，盯住质量指标和成本曲线。灰度期间最怕的是指标看着好但样本太少，我的经验是至少积累几百次真实交互再下结论。
性能、成本、风险这三样永远在打架。我的做法是先把风险项列成否决条件，比如数据出境、输出不可控，这些一票否决。剩下的在性能和成本之间找平衡，把结论写成一句话：“在满足合规和时延要求的前提下，A方案每任务成本低百分之多少，质量差距在可接受范围内。”这句话比一张密密麻麻的表更容易推动决策。
2.5 供应商与模型生态评估
版本迭代节奏这件事我特别在意。有的供应商两周一个小版本，行为漂移你没跟上，线上效果就悄悄变了。我们现在要求供应商提供版本变更说明，重大更新前给我们留出回归测试的时间。遇到那种不打招呼直接热更新的，我心里会打个问号。
服务SLA得看细节，不能只看那个百分之九十九点九的数字。限流策略是按分钟还是按天，超限之后是排队还是直接报错，这些决定了你的产品在高峰期是变慢还是直接挂掉。数据使用条款我每次都会让法务过一遍，尤其是“用于服务改进”和“人工审核”这两个条款，能不能关掉、怎么关，关系到你敢不敢把用户数据喂进去。
可替换性是我这两年新增的一个评估项。模型这行变化太快，今天的第一名明年可能就掉队了。我在架构上会留一层抽象，把模型调用封装成统一接口，换供应商的时候改配置而不是改代码。评估一个供应商的时候，我会问自己一个问题：如果明天要换掉它，我需要多少人天？这个数字越小，我越安心。
说实话，前两章讲的那些框架和方法，落到实际项目里还得过一道坎：你选的那个模型，到底配不配你那个场景。我见过太多团队拿着一份通用评测报告就拍板，上线之后才发现模型在自家业务上水土不服。模型这东西没有绝对的好坏，只有合不合适。这一章我想把我踩过的坑和总结出来的流程摊开讲，五个小节，每一个都是真金白银换来的。
3.1 典型场景选型策略
客服问答这个场景我做得最多。它的特点是用户问题短、意图集中、对响应速度和稳定性要求高，但对创造性几乎没要求。我一般会优先考虑小参数模型或者经过领域微调的模型，先把意图识别和标准答案命中率做上去。大模型不是不能用，用法是放在兜底位置，处理那些小模型搞不定的长尾问题。我们有一套客服系统就是这么搭的，小模型扛了八成流量，大模型只在置信度低的时候被调用，成本压下来一大截，用户体验反而更稳。
内容生成场景完全是另一套逻辑。营销文案、商品描述、社交媒体帖子，这些任务对语言风格和多样性要求高，对事实准确性的容忍度反而没那么苛刻。我选模型的时候会重点看它的表达丰富度和指令遵循能力，尤其是能不能按照给定的品牌调性写东西。有个细节我特别在意：同一个prompt跑十次，输出之间有多大差异。差异太小的模型写出来的东西千篇一律，差异太大的又不好控制。这个平衡点得靠实际跑样本去感受，榜单上看不出来。
代码辅助场景我个人的经验是，模型之间的差距比想象中大。补全、解释、重构、找bug，这几个子任务对模型能力的要求不一样。补全要求低时延高准确，重构要求对代码结构的理解深度。我测评的时候会拿自己项目里的真实代码去喂，不用那种LeetCode题。真实代码里有历史包袱、有奇怪的命名、有框架特定的写法，这些才是试金石。另外代码场景对上下文长度特别敏感，一个文件动辄上千行，模型能不能把相关依赖都装进去，直接决定它有没有用。
知识检索增强这个场景，模型选型的核心矛盾在“忠实度”和“表达力”之间。RAG系统里模型的任务是把检索到的片段组织成通顺的回答，它得老老实实基于给定材料说话，不能自己发挥。我测这类模型的时候会故意在检索结果里塞几条干扰信息，看它会不会被带偏。有的模型特别“聪明”，检索片段里没有的东西它也能给你编出来，这种在RAG场景里是负分项。我宁可选一个稍微笨一点但听话的模型，也不要一个爱自由发挥的。
多模态应用这两年需求涨得快，但选型难度也大。图片理解、表格识别、视频摘要，每个子场景对模型的要求差别很大。我做过一个票据识别的项目，试了四个模型，有的对印刷体识别率很高但手写体一塌糊涂，有的整体识别率一般但对模糊图片特别鲁棒。多模态这块我的建议是一定要拿自己业务里的真实图片去测，公开数据集里的图和用户拍的图，质量差距不是一点半点。光线、角度、遮挡、拍摄抖动，这些因素在benchmark里根本体现不出来。
3.2 AI模型怎么选择：形成闭环流程
每次有人问我“AI模型怎么选择”，我都想先反问一句：你的需求写清楚了吗。我见过太多项目一上来就开始比模型，比了两周才发现大家连要解决什么问题都没对齐。我现在带项目，第一步一定是拉上业务方、产品、技术坐在一起，把需求写成一句话：“让模型在什么场景下，把什么输入，变成什么输出，达到什么标准。”这句话写不出来，后面所有的评测都是白费功夫。
需求定义清楚之后，候选筛选反而快。我会列一个长名单，把市面上主流模型都放进去，然后用硬性条件砍一刀。数据能不能出境、支不支持私有化、上下文长度够不够、有没有多模态能力，这几个问题过一遍，名单通常能砍掉一半以上。剩下的进入评测对比环节，这一步我在第二章讲得很细了，小样本A/B测试先跑起来，快速排除明显不行的，再上完整评测集做精细对比。
灰度上线是我最看重的环节。离线评测跑得再好，跟真实流量之间也隔着一条河。我一般放百分之五左右的流量，跑一周，重点盯三个东西：质量指标有没有明显下滑、成本曲线符不符合预期、用户反馈有没有异常。灰度期间我要求团队每天出一份简报，不用长，三五行就行，但必须每天看。有一回我们灰度到第三天，发现某个意图的失败率突然往上跳，查下来是模型对一种新出现的用户表达方式不适应，及时加了规则兜底，没酿成事故。
监控复盘这个环节很多团队做得敷衍，上线之后就不管了。我的做法是每个月做一次模型健康度复盘，把质量、成本、时延三张曲线摆在一起看。有一次我们发现某个模型的调用成本连续三周缓慢上涨，查下来是用户输入越来越长，token消耗自然水涨船高。这个趋势在单日数据里根本看不出来，必须拉长周期看。复盘的目的不是追责，是让团队对模型的真实表现保持手感。
3.3 上线后的监控与迭代
质量指标的监控我分两层。一层是自动指标，比如格式合规率、拒答率、平均响应长度，这些可以实时算。另一层是人工抽检，每周抽一百条真实对话，让人去标好坏。自动指标能发现突变，人工抽检能发现渐变。我遇到过一次模型输出质量缓慢下降的情况，自动指标一切正常，人工抽检的时候标注同学说“最近回答怎么感觉变啰嗦了”，一查果然是供应商那边做了静默更新。这件事之后我在监控面板上加了一个输出长度趋势图，跟股票K线似的天天看。
成本指标我的习惯是拆到意图级别。整体成本看着平稳，可能底下某个意图的成本已经翻倍了，只是被其他意图稀释了。我们做过一个功能，用户问天气和问股票走的是同一个模型，后来股票那边的流量涨了三倍，整体成本才微微动了一点，差点没发现。拆开看之后我们给股票查询单独路由到了一个更便宜的模型，一个月省下来的钱够买好几张显卡。
用户反馈这块我特别看重负反馈的归因。用户点踩的原因五花八门，有的是回答错了，有的是回答对了但语气不好，有的是等太久了。我要求产品经理每周把负反馈样本过一遍，分成模型能力问题、prompt问题、产品交互问题三类。分完之后发现，真正需要换模型来解决的其实只占一小部分，大部分是prompt和交互能优化的。这个认知帮我省了很多不必要的模型迁移成本。
模型路由和降级机制是我现在架构里的标配。主模型挂了或者超时了，自动切到备用模型，备用模型也挂了，切到规则兜底。这套机制平时看不出价值，出事的时候能救命。有一次某个供应商区域机房故障，我们的服务几乎没受影响，因为路由层在两百毫秒内就切走了。降级策略得提前设计好，不能等出事的时候现想。我一般会定义三档：正常、降级、兜底，每一档对应不同的模型组合和用户体验预期，写进运维手册里。
3.4 风险与治理
数据隐私这件事我态度很明确：用户数据能不能给模型看，得让法务和安全团队签字，不能由技术团队自己判断。我们内部有一条线，个人身份信息、财务数据、健康数据，这三类绝对不进第三方API。需要用到这些数据的功能，一律走私有化部署的模型。这条线画清楚之后，很多选型决策反而简单了，因为可选范围直接缩小了。
合规审查我经历过一次比较惊险的。有个功能上线三个月，法务突然通知我们说某个条款更新了，我们传给供应商的数据可能被用于服务改进，需要重新评估。那次之后我养成了一个习惯，每个季度让法务把在用供应商的数据条款过一遍，有变化及时通知。供应商的条款更新往往藏在邮件角落或者官网的小字里，不主动盯很容易漏掉。
输出可控性这个事，我的经验是别指望模型自己管住自己。系统提示词、输出格式约束、敏感词过滤、事实核查，这四层得叠着用。我见过有的团队只在prompt里写一句“请确保输出准确”，然后就指望模型不出错，这不现实。我们现在的做法是模型输出之后过一道规则引擎，格式不对的重试，敏感内容拦截，关键实体做交叉验证。这套东西会增加一点时延，但比出事之后擦屁股便宜多了。
供应商锁定是我这两年越来越在意的事。模型这行变化太快，今天最好的不一定明年还好。我在架构上坚持做一层抽象，所有模型调用走统一接口，换供应商的时候改配置不改代码。评估新供应商的时候我会问团队一个问题：如果明天要换掉它，需要多少人天？超过五个人天我就觉得风险偏高，得再想想。应急预案也得有，至少准备一个备选供应商，平时跑着少量流量保持连通性，真出事的时候能顶上来。
3.5 选型决策清单
我把前面这些年的经验沉淀成了一张清单，每次有新项目就拿出来过一遍。清单不长，一页纸，分三块：硬性条件、评测结论、场景验证。硬性条件那块是勾选式的，数据合规、上下文长度、多模态支持、部署方式，符合就勾，不符合直接淘汰。这块不掺感情，也不看供应商关系。
评测结论那块我会把关键数字填进去，准确率、时延、每任务成本、幻觉率抽检结果，每个数字后面注明测试集大小和测试日期。我特别要求写上测试日期，因为模型版本变得快，半年前的评测数据参考价值有限。这张表填完，几个候选模型摆在一起，差距一目了然。
场景验证那块是最个性化的，每个项目不一样。我会写上灰度期间的观察结论、用户反馈摘要、运维团队的意见。有一回技术评测第一名的模型在灰度期间被运维团队否了，原因是它的错误日志太简略，出了问题排查困难。这个理由在评测表上看不出来，但实际用起来很要命。清单最后留一栏叫“决策备忘”，写一句话总结为什么选这个不选那个，半年后回头看，这句话往往比整张表都有价值。
这张清单我存在团队的共享文档里，每次项目结束更新一版。现在回头看第一版，很多当时觉得重要的评估项已经删掉了，也加了不少新东西。选型这件事没有一劳永逸的模板，清单本身也得跟着业务一起迭代。
