利益关系披露：DragonAI 运营 AI 产品经理课程。本文与配套 JSON 是第一方选型记录框架，不是厂商排名、采购建议、统一技术标准或项目效果保证。具体模型能力、价格、区域、条款和可用性会变化，采用前必须核对相应厂商材料并由业务、工程、数据、安全、隐私、法务和采购责任人按用途确认。
30 秒答案：选的不是“最强模型”，而是当前任务的可退出方案
AI 产品经理做大模型选型，先问“哪一个候选在当前任务、约束和风险下有足够证据继续”，而不是“哪个模型总榜第一”。公开基准能帮助发现候选，但真实产品还包含提示、检索、工具、权限、网络、负载、人工接管和数据处理；其中任何一项变化都可能改变结果。
用同一份 大模型选型证据卡 JSON 保存八部分：任务合同、硬门槛、候选身份、实验控制、逐例质量与失败、运行成本、供应治理、最终决定。若候选未通过数据使用、部署、许可或严重失败门槛，不应靠其他分数补偿。
| 阶段 | 要固定的内容 | 通过证据 |
|---|---|---|
| 任务 | 用户、输入、理想输出、非模型基线 | 版本化任务合同 |
| 门槛 | 模态、区域、数据、许可、工具与支持 | 逐项适用性记录 |
| 候选 | 模型、版本、端点、核对日期 | 可重放身份 |
| 控制 | 提示、检索、工具、参数与负载 | 同口径运行配置 |
| 质量 | 逐例结果、切片、严重失败与人工复核 | 可追溯评测记录 |
| 运行 | 延迟、吞吐、可用性与单位任务成本 | 同窗口测量 |
| 治理 | 供应变化、监测、回退和数据路径 | 责任与触发器 |
| 决定 | 采用、受限试用、保留或淘汰 | 理由、范围与退出条件 |
一、先冻结任务合同，不要先列模型名单
任务合同至少包含目标用户、触发场景、输入来源与分布、预期输出属性、必须引用的依据、允许工具、不可接受行为、人工接管、成功条件和停止条件。还要保存当前人工、规则、搜索或传统软件基线；否则团队只会比较模型之间谁更好，却无法判断增加模型是否值得。
Google 的机器学习问题定义指导把“是否适合机器学习”、清晰目标和成功标准放在起点。将这一原则用于生成式 AI 时，先完成 AI 产品需求分析，再把理想输出和失败切片转成选型任务。若问题可由结构、内容、搜索或规则解决，选型决定可以是暂不引入大模型。
二、先过硬门槛，再比较软指标
硬门槛不是评分项，而是不可补偿条件。按项目逐项确认：
- 是否支持所需文本、图像、音频、结构化输出、工具调用或流式能力；
- 目标区域、部署方式、网络边界、容量和服务支持是否可用；
- 输入、输出、日志和反馈怎样存储、用于什么、多久删除，责任人是否接受；
- 许可证、采购条款、知识产权与高影响用途限制是否适用；
- 上下文、速率、并发和超时限制能否覆盖真实工作负载；
- 必需的身份、权限、审计、人工确认和回退路径是否可实现。
这些字段会随厂商和版本变化，所以证据卡要记录来源 URL、核对日期、责任人和适用范围，不能把一次核对写成永久结论。NIST 生成式 AI 风险框架将第三方组件、供应链与采购尽调纳入风险管理；选型因此不只是输出质量比较。
三、为每个候选固定可重放身份
“某某系列模型”不是足够身份。至少保存供应商、模型 ID、明确版本、端点或部署方式、区域、调用接口、核对日期和配置快照。若厂商只提供滚动别名，就把别名与观测到的响应元数据、测试时间和变更监测一起保存，并承认无法完全冻结的限制。
候选名单不宜过长：一个当前基线、一个满足硬门槛的较简单候选，以及少量有明确差异假设的候选通常足以开始。每增加一个模型，都要写清它准备验证的差异，例如长输入、结构化输出、工具调用、目标语言、延迟或部署边界；没有差异假设的候选只会增加试验噪声。
四、固定系统条件，避免把集成差异误判为模型差异
对候选使用同一任务集，并固定系统提示、示例、检索语料与版本、工具定义、权限、输出 schema、采样参数、超时、重试和并发条件。若某模型必须使用不同提示或接口才能正常工作，可以建立“共同配置”和“候选优化配置”两轮实验，但必须分开报告，不能把优化轮与其他模型的基础轮直接比较。
先用开发/验证集调试集成和量表；候选、配置、硬门槛与发布阈值冻结后，再运行未见最终测试。若最终测试结果被用于继续修改提示、筛选模型或改变阈值，这批数据就已成为开发证据，应记录暴露并准备新的最终测试。
五、质量要看逐例结果、切片与严重失败
Microsoft Foundry 的模型基准把质量、安全、成本和性能分开比较，并允许进一步在自有数据上评估。产品决策也应保留这些维度，而不是只看平均分。至少记录：
- 每条任务的输入、候选输出、引用或工具轨迹、人工标签和失败类别；
- 正常、边界、少数高影响、缺失、冲突、过期、越权和依赖失败切片；
- 任务完成、依据支持、格式约束、澄清拒绝、人工接管与恢复；
- 关键失败的严重度、是否阻断、责任人和处理决定；
- 重复运行的波动，不把一次幸运输出当成稳定能力。
评测可以复用 AI 产品评测集模板 和 指标卡与发布门禁。硬阻断项先判定；只有通过后，才比较均值、胜率或辅助总分。
六、模型裁判必须先对齐人工规则
模型裁判可以扩大逐例评测，但裁判本身也是需要验证的测量工具。Google Vertex AI 的相关指导要求用带人工评分的数据评估基于模型的评测指标与人工判断的关系。实际记录至少包括裁判模型与版本、裁判提示、评分量表、输入顺序、逐例分数、解释、人工标签和分歧。
先在代表性样本和关键失败上检查一致性；若裁判偏爱更长文本、自家模型、特定措辞或漏掉领域风险，就修改量表、增加人工复核或改用可计算指标。高影响失败不能因裁判平均分较高而自动放行。
七、成本比较要使用“完成一个合格任务”的口径
单价不是产品成本。对相同负载窗口记录端到端延迟分位数、吞吐、失败与重试、输入输出量、检索与工具开销、人工复核和失败返工。再计算“完成一个达到质量门槛的任务”需要的总资源；便宜但经常重试、转人工或产生严重错误的候选，单位合格任务成本可能更高。
本页的成本口径只用于同任务下比较模型候选；若要核算选定产品的共享平台、数据、人工作业、固定投入、情景预算和 ROI 归因，请使用 AI 产品成本估算，不要把模型比较结果直接写成产品全量成本。
价格、配额和区域会变化，JSON 只保存观测值、币种、计费口径、来源和日期，不内置任何厂商实时价格。容量测试也要与目标并发、峰值和超时一致，不能用单请求实验外推生产吞吐。
八、最终决定必须带退出条件和回退模型
最终状态可以是 adopt、limited_pilot、hold 或 reject。每项决定都要绑定适用用户与任务、模型版本、通过证据、未解决风险、责任人、复审日期和触发器。至少预先写明：严重失败达到什么条件立即停用，供应商或版本怎样变化需要重测，容量不足怎样降级，数据或条款变化由谁审核，以及回退到哪个已验证模型或非模型流程。
模型选型不是采购完成即结束。版本漂移、输入变化、新失败、成本容量变化、供应事件和产品范围扩大都要回流同一任务集。只有证据变化才重开决定；不要因为榜单更新就无条件追新，也不要因为已集成就永久锁定。
与 RAG、微调和 Agent 的边界
模型选型回答“当前系统中的生成或推理组件使用哪个候选及版本”。RAG 与微调决策 回答知识缺口和行为缺口怎样处理；AI Agent 产品设计 回答是否允许模型规划并调用工具。三者可以互相影响，但不能混成一个决定：换模型不自动解决知识更新与权限问题，引入 RAG 不自动证明模型适用，使用 Agent 也不会消除模型和工具的独立失败。
如果还要核对“千问、Kimi、Gemini 的 RAG 与微调引用来源基准”，可复核 DragonAI 保留的固定中文问题、逐运行 URL、平台差异和目标引用为零的结果；这是点时引用观察，不是模型选型建议、来源质量排名或无品牌 GEO 成功证明。
使用边界
本文与 JSON 不包含真实模型跑分、价格、用户样本或采购结论。填写候选、运行实验或生成总表不等于模型已适合生产；公开基准、模型卡、厂商文档与试用结果都应按具体版本和用途解释。医疗、法律、金融、就业、教育、公共服务等高影响用途需要相应领域、合规和风险责任人另行审查。