企业落地 AI，选型会是第一个月的第一场硬仗，也是最后一季度复盘时最常被骂的决策。选错的代价不是”效果差一点”，是整个团队花了两个月为一个不适配的架构做适配，最后发现里面最关键的接口根本不支持自己的数据类型。
我们公司在 2026 年做了 6 类核心场景的选型，从 23 个候选中筛到 6 个上线，前后花了 11 周。这篇文章不写”哪个工具最好”——那个问题没有答案；写的是一套可以复用的选型方法：怎么把选型从玄学变成有截止条件的工程决策。
一、第一原则：不用 demo 做决策，用一份自己的验收题做决策
我们最初的做法是看各家公开评测、看 demo 演示，两次都失败了。公开 benchmark 的问题是无法迁移：某家在通用问答上高 4 个点，不代表它在你的结构化抽取上高；demo 演示的问题是有人精心准备了问题。后来我们固定成一条：先写验收题，再让厂商做题，用同一份题横向比。
| 选型误区 | 我们踩过的坑 | 正确的替代做法 |
|---|---|---|
| 看公开榜单排名 | 选了榜单第一，上自己的数据掉 9 个点 | 榜单只用来建候选池，不用来定结论 |
| 要求厂商给案例报告 | 案例是真的，但和我们数据类型不匹配 | 要求厂商用我们的样本数据跑给我们看 |
| 内部 demo 演示 | 演示流畅，上线后接口不支持批量异步 | 验收清单里必须有”接口能力”一栏，且一票否决 |
| 用平均价格比成本 | 平均价低，P95 场景超长，实际贵 2 倍 | 用自己流量的长度分布做加权成本，不看标价 |
一份可用的验收题至少四块。第一块是核心能力：从生产日志里抽 200 条真实请求，人工标注期望输出，这部分占 50% 权重。第二块是边缘场景：故意放进去一些刁钻的、罕见的、超出典型分布的请求，占 20%——这部分最能拉开差距，一个工具的底色在这里才看得清。第三块是接口与工程能力：批量并发、流式、超时重试、数据驻留、审计日志，占 20%，且有单项否决权。第四块是总拥有成本：不是单价，是含集成、运维、兜底、迁移的总账，占 10%。
二、23 到 6：我们实际用的四轮筛法
11 周筛 23 个候选，不算快，但每一步都留了决策记录，复盘时能说清楚”为什么当时否了它”——这比选对更重要，因为一年后你会忘记当时的约束条件。
| 轮次 | 周期 | 筛掉标准 | 剩余数量 | 关键产出 |
|---|---|---|---|---|
| 1. 资格审查 | 3 天 | 数据驻留地、合规资质、SLA 明确性、是否支持私有化 | 23 → 17 | 一份尽调清单，行政先跑 |
| 2. 纸张评测 | 1 周 | 拿验收题跑离线评测，低于 70 分的淘汰 | 17 → 11 | 同一份题，统一口径的分数 |
| 3. 极限测试 | 2 周 | 边缘场景、并发峰值、故障注入、成本压力 | 11 → 8 | P95 延迟、失败率、单任务成本三项硬数据 |
| 4. 灰度上线 | 5 周 | 5% 流量跑四周，看线上质量与投诉 | 8 → 6 | 真实工作流下的验收结论 |
第三轮最残酷，也最省时间。我们做的极限测试有三项：故意把日志里最长的 1% 请求（是平均长度的 40 倍）打进去看吞吐和成本；把下游服务随机杀掉 10% 的连接看重试和降级；用生产流量做 3 倍并发压测。这一轮筛掉的两个候选，都是在纸张评测上分数最高的。分数高不代表能在你的负载下活着。
第四轮灰度是唯一能替代”拍脑袋信任”的一轮。纸张评测和极限测试都是我们的视角，灰度才是用户视角。有一个候选在极限测试拿了第一，但灰度两周后业务方集体反对——原因是它的不确定输出让前端要做大量兜底交互，技术指标好但体验成本高。这条教训：把”集成成本”和”体验成本”也算进总账，不然你会选到一个技术上正确、产品上错误的方案。
三、六类场景的差异化标准：不要用同一把尺子量所有场景
选型最容易犯的错，是六个场景用同一个评价表。不同场景的失败代价完全不同，选型标准必须跟着场景的风险走。
| 场景 | 失败代价 | 选型权重最高的一项 | 可接受的替代方案 |
|---|---|---|---|
| 客服 / 对话 | 用户体验下降，可快速回滚 | 延迟 & 转人工率 | 质量换速度可以接受 |
| 内容审核 | 漏审即合规事故 | 召回率优先于精确率 | 宁可误杀，不可漏过 |
| 结构化抽取 | 错字段即数据事故 | 字段级准确率 + 可解释 | 不接受”黑盒高置信” |
| 代码辅助 | 错误代码造成返工 | 补全准确率 + 误报率 | 可搭配本地小模型离线兜底 |
| 内部知识问答 | 误导员工，信任损耗 | 引用可追溯 | 可以慢，不能编 |
| 营销内容生成 | 品牌调性偏差 | 风格一致性 + 人工兜底程度 | 质量换成本空间大 |
最值得单独讲的是内容审核和结构化抽取这两个场景，因为它们是我们最后放弃”最强模型”、改用”中等模型 + 严格约束”的场景。审核场景要的是召回头部风险（漏放一条违规是处罚，多拦十条正常是人工复核成本），一个我们调高了召回阈值的中等模型比一个默认配置的强模型更合适。抽取场景要的是每个字段都能给出来源和置信度，很多强模型给不出字段级的可解释性，而这是我们验收的一票否决项。
四、写在合同和复盘里的三件事：让选型可逆、可退、可复盘
选型不是签完合同就结束的，我们把它当成一次有退出机制的实验。最后稳定下来的三条，价值超过前面所有评测：第一，抽象层。我们内部统一走一层自己的调用封装，上游模型或供应商可替换。这次改造花了 8 个工程师周，换来的是后续两次供应商切换只花了 2 周——2026 年上半年行业价格战里，我们换了两次供应商，没有这一层就是两次重写。
第二，写进合同的验收条款。不是笼统的 SLA，是我们验收题上的具体指标：抽取字段准确率不低于 92%、P95 延迟不高于 2.4 秒、连续两周不达标可以无责退出。没有数字条款的合同，出问题的时候你没有办法说话。第三，每季度一次的复盘表：把上线时的预期指标和现在的实际指标列在一起。我们有一条工作流上线时 89.6% 的可用率，六个月后掉到 76.3%——因为上游悄悄改了模型版本。没有这张表，这件事永远没人发现。
总结
11 周选型的结论可以压成三句话：选型的本质是用自己的数据做决策，公开榜单和 demo 都只能建候选池，不能定结论；筛选应该分四轮，从资格审查到灰度上线，其中极限测试最能筛掉”分数高但活不下来”的候选；选型标准必须按场景的风险定制——审核看召回、抽取看可解释、生成看可控，用同一把尺子一定会选错。
更普适的认知是：选型的目的不是找到最好的那个，是找到”三个月后你敢复盘、一年后你能换掉”的那个。为此付出的抽象层成本和条款成本，会在行业每次洗牌时连本带利回来。一个留了退出机制的决策，才是真正低风险的决策。
互动提问：你们选型时最常用什么方法——看榜单、问同行、还是自己搭一套题来跑？
互动提问：有没有遇到过”上线时是最好的方案，半年后变成最差的”？当时是什么变了——是需求、供应商，还是你自己的流量结构？
— IMAI 编辑部 | 2026-11-05