模型选择实用指南

陈琳2026-07-02约 6 分钟主编

模型选择是所有 AI 应用开发中最关键的环节之一——选错模型通常意味着耗费更多计算资源、推理时间，或者无法满足业务对准确率、延迟和成本的具体要求。这份指南提供一套可复用的筛选流程，覆盖模型能力、上下文长度、输出速度、成本、合规性和生态支持六个维度，并指出最常见的三个错误：跳过需求边界定义、只看跑分不看业务场景、忽略上下文长度对结果的影响。

开始之前

在开始评估具体模型之前，需要先确认以下前提：

业务场景的输入输出类型：纯文本、代码、多模态（图像+文本）、结构化数据？
延迟与吞吐量的硬性约束：单次推理允许的最大耗时是多少？每秒需要处理多少请求？
上下文窗口的最低需求：模型需要处理的单次输入最长是多少 token？后续是否可能增长？
数据安全与合规要求：数据能否离开本地网络？是否需要私有化部署？
预算上限：按 token 计费还是按实例/API 调用计费？预算只覆盖推理还是包括微调？

如果以上任何一个前提没有明确记录，不要急于下载模型列表或跑 benchmark。写下这几项，它们会直接决定后续的筛选范围。

Steps

Step 1: 根据任务类型确定模型类别

根据任务类型确定模型类别：箭头连接任务类型与三个分类图标

将任务归入以下三类之一，每类对应不同的筛选侧重点：

生成式任务（对话、写作、代码生成）：优先关注模型的知识广度、推理连贯性和指令遵循能力。
分析式任务（分类、抽取、情感分析、摘要）：优先关注模型对结构化指令的稳定性和输出格式的一致性。
检索增强任务（RAG、问答系统）：优先关注模型对长上下文的处理能力，以及能否正确引用源文档中的事实。

Step 2: 在同类模型中筛选可用选项

在同类模型中筛选可用选项：六个维度图标围绕模型图标

打开你的模型库或 API 提供商列表，按以下六个维度逐个检查。建议用表格记录，方便横向比较：

| 维度 | 具体考察点 | 典型检查方法 | |------|-----------|-------------| | 上下文窗口 | 最大 token 数、实际有效长度（过长上下文后性能退化情况） | 提供 5000+ token 的文档，检查末尾内容是否被准确理解 | | 输出速度 | 首 token 延迟、生成速率（token/s） | 在官方 API 或本地部署时用同一 prompt 测试三次取中位数 | | 成本 | 输入/输出 token 单价、是否支持 tokens 池或批量折扣 | 查阅官方定价页或 API 控制台 | | 能力 | 在相关 benchmark 上的表现（MMLU、HumanEval、GSM8K 等） | 用一份内部测试集运行同 prompt 三份，对比输出质量 | | 生态 | 第三方工具链支持（LangChain、LlamaIndex、HuggingFace）、指令格式兼容性 | 查看对应组件是否在官方文档中被明确列出 | | 合规 | 数据训练来源、法规认证（是否满足 GDPR、等保要求） | 查阅供应商的数据处理协议或合规页面 |

Step 3: 用具体任务 prompt 做实测

在完成以上表格筛选后，保留 2-3 个候选模型，进入实测阶段。实测不要只用通用问题（如“写一首诗”），要用真实业务场景的 prompt。

示例：假设你的业务场景是抽取合同中的关键条款：

``` 从以下合同中抽取以下字段：签约方、合同金额（含币种）、签约日期、生效条件。

如果字段不存在，输出"未发现"。

合同文本： [粘贴 2000-3000 字的真实合同样本] ```

将同一条 prompt 对每个候选模型运行一次，注意：

所有模型使用相同的系统指令和温度设置（建议温度设为 0，减少随机性）
记录每个模型的输出格式、字段正确率、是否产生幻觉（输出不存在的信息）
在移动设备浏览器视口下也测试一次，确认输出是否适配移动端展示

Step 4: 对胜出模型做压力测试

将候选范围缩小到 1-2 个模型后，增加三个压力维度：

长输入测试：将输入内容增加到模型上下文窗口上限的 80%，检查输出质量是否下降
并发压力测试：模拟业务峰值流量，观察 API 响应时间是否会超出延迟红线
边界条件测试：故意提供缺失字段的输入，检查模型是否会补充不存在的信息（常见陷阱：模型倾向于“猜测”而非承认未知）

Checks

模型选择完成后需要验证——很多问题会在上线后才暴露。按以下顺序逐项检查：

输出格式一致性检查：对 100 条测试数据运行模型，统计输出与期望格式的匹配率。如果低于 95%，需要增加指令约束或改用输出格式化工具。
上下文退化边界检查：将测试案例的输入长度逐步从 20% 增加到 90%，记录每次生成结果中是否出现遗漏或逻辑断裂。退化通常发生在上下文长度达到模型声称最大值的 50-70% 之间，不同模型差异明显。
多轮对话中的状态保持检查：如果场景涉及多轮交互，用连续 5 轮以上的对话测试模型是否能正确引用前文信息。常见错误是模型在第三轮后开始“遗忘”用户在前面给出的关键指令。
回滚预案检查：确认供应商支持切换模型版本（或回退到旧版），以及切换后是否会影响已部署的生产环境。这一步在 API 版本迭代频繁的供应商（如 OpenAI、Anthropic）尤为重要。

Troubleshooting

症状：模型输出内容看似合理但事实错误

原因：模型本身的知识截止日期较早，或者 prompt 中没有明确要求“只依据提供的内容作答”。
修复方法：在系统指令中加入“如果知识库中无相关事实，回答‘未找到’”并启用检索增强（RAG）。
验证方法：用一个包含虚构专有名词的 prompt 测试，检查模型是否会承认不知道。

症状：相同 prompt 每次输出差异极大

原因：temperature 设置过高（常见：设置为 0.8-1.0 未根据任务类型调整）。
修复方法：对分类、抽取等确定性任务设置 temperature 为 0；对创意写作任务可以保留 0.5-0.7。
验证方法：用 temperature=0 运行三次同一 prompt，输出应几乎一致。

症状：模型在长文本中丢失中间部分的信息

原因：模型对长上下文的处理机制存在“中间遗忘”。
修复方法：调整 prompt 结构，将最关键的指令放在输入的开头或结尾；或者换一个有更大有效上下文窗口的模型（如 Claude 系列）。
验证方法：在文档中间位置嵌入一条明显信息（如“正确的答案是金色”），看模型是否能准确提取。

FAQ