在写第一个提示词之前，如何选对 LLM

大多数团队选择 LLM 的方式，和十年前选数据库一样：看一张对比表，挑出最关心那一列得分最高的，然后开始构建。六个月后，他们要么在迁移，要么疑惑为什么评估结果和用户实际体验截然不同。基准没有错——只是模型选错了。

错误不在于选了错误的模型，而在于还没搞清楚自己的生产任务分布就急着选模型。基准测试的是别人认为重要的东西；你的生产系统有完全不同的分布。这两件事根本不是一回事。

为什么公开基准无法替你做这个决定

最广泛引用的 LLM 基准——MMLU、HumanEval、GPQA——在前沿模型上已经饱和。到 2024 年中，每个主要模型家族在 MMLU 上的得分都超过了 90%。Claude 和 GPT-4o 在该基准上相差零点几个百分点，那是统计噪声，不是可操作的信号。有研究者对 MMLU 进行人工审核，发现约 6.5% 的题目存在标准答案错误——也就是说，你优化的指标本身就有部分是错的。

HumanEval 的问题恰恰相反：它测试的是封闭的算法谜题，而不是调试一个 3000 行 TypeScript 代码库或为文档混乱的 API 编写迁移脚本这类真实场景。在 HumanEval 上名列前茅的模型，在实际开发团队真正关心的代码生成任务上经常翻车。

还有数据污染的问题。每个用大规模互联网爬取数据训练的模型，都有相当大的概率在训练数据中见过基准题目。从一个发布的分数里，你根本无法判断看到的是能力还是记忆。

这不是反对使用基准，而是要清楚它们测的是什么。只有当基准的任务分布与你的生产任务分布相似时，基准才能预测生产表现。两者分布差距越大，分数对你的参考价值就越低。

那些从未出现在排行榜上的生产关键维度

以下这些变量，往往决定了一个 LLM 集成是稳定上线还是需要持续人工介入。在任何公开基准表格里，你都找不到它们。

函数调用可靠性。 如果你的系统使用工具调用、结构化提取或 Agent 循环，这很可能是你最重要的维度。伯克利函数调用排行榜显示，顶尖和末尾模型在函数调用准确率上相差 4-5 个百分点——从约 95% 到 99.9%。每天 1000 次工具调用，这个差距意味着 15 次额外失败对比 1 次。失败模式也各不相同：有些模型生成语法无效的 JSON，有些输出能解析但不符合 schema，有些在特定条件下直接漏掉必填字段。

结构化输出合规性。 JSON 模式和结构化输出不是同一回事。标准 JSON 模式通常有 2-5% 的 schema 不匹配失败率——输出能解析，但必填字段缺失或类型错误。约束解码（只允许模型生成符合 schema 的 token）能把这个比率降到 0.1% 以下。关键问题不是"这个模型支持 JSON 模式吗？"，而是"我会遇到哪种失败模式，频率有多高？"

你所在领域的拒绝率。 安全过滤器是针对通用伤害类别校准的，而不是你的领域。过滤器激进的模型，对合理的法律、医疗或金融查询的拒绝率，会高到让它在专业应用中根本无法使用。拒绝行为因模型和提供商而异，还取决于你的请求措辞——不只是你问了什么。不在你的实际内容上测试，你无法预测。一个模型可能拒绝 0.2% 的医疗查询，另一个可能拒绝 8%。

上下文窗口边界处的行为。 200k 上下文窗口不意味着放在窗口任意位置的信息都会被平等利用。关于"迷失在中间"问题的研究表明，当相关信息位于长上下文的中间位置时，LLM 的表现比放在开头或结尾时差 30% 以上。注意力机制对边缘 token 有 U 形偏好。这意味着一个上下文窗口更小、但配合检索谨慎使用的模型，可能胜过一个上下文窗口更大、但文档被随意堆砌的模型。

你的并发级别下的延迟。 基准延迟几乎都是单请求、缓存预热的数字。你的系统运行并发请求，通常是冷缓存，在特定上下文长度下。首 token 时间和吞吐量在高负载下会大幅分化——测试时感觉很快的模型，在生产中 50 个并发请求排队时可能变得很慢。在你的预期并发级别下测试延迟，而不是隔离测试。

跨长系统提示的指令遵循。 如果你的系统提示有 1000 字以上且包含多个约束，模型在一致遵循所有约束方面差异显著。有些模型会"遗忘"早期出现的约束，尤其在上下文压力下。这种失败模式在基准中几乎不可见，但在复杂 Agent 系统中会成为主要失败模式。

48 小时对抗性评估冲刺

与其依赖公开基准，最具生产准备度的团队会在确定模型之前进行一次专注评估。48 小时就足以获得可操作的数据。

第一天：基线与分层。 整理 100-200 个代表你实际任务分布的样本。如果有生产流量，从中采样；如果没有，构建匹配预期使用场景的样本。按难度分层：简单（任何像样的模型都应该能通过）、中等（预期有差异）、困难（真正有挑战性的边缘情况和领域特定查询）。对所有候选模型运行这个数据集，记录准确率、延迟和每次成功输出的成本。

第二天：对抗性测试。 一旦掌握基线，就开始压测。引入真实扰动：用户输入中的错别字、同一意图的不同表述、上下文窗口边缘的边界情况、并发请求以衡量延迟退化。测试你领域特有的拒绝风险：模型是否能处理你的合理用例而不产生误拒绝？使用 PromptBench 风格的扰动（同义词替换、改写等小变化）——研究表明这些简单扰动会导致模型平均性能下降 33%，暴露基线隐藏的脆弱性。

这次冲刺的产出应该是一张表格，在真正重要的维度上对比候选模型：函数调用准确率、JSON schema 合规率、你的内容拒绝率、预期并发下的 p95 延迟，以及每次成功输出的成本。这才是你真正的决策矩阵。

你真正在做的决定

完成评估后，通常不是"哪个模型最好"的问题——而是"哪种模型组合适合哪类请求"。

没有任何单一模型能在所有维度同时胜出。推理深度最好的模型很少是最快的。最便宜的模型很少在结构化输出上最可靠。指令遵循最好的模型很少在专业内容上拒绝率最低。

生产中效率最高的团队按请求类型路由，而不是把所有东西发给同一个模型：

• 面向用户、延迟敏感的交互：优先考虑首 token 时间而非推理深度
• 复杂多步推理或长周期规划：花钱买推理算力，用针对扩展推理优化的模型
• 大批量处理（摘要、分类、提取）：优化每次成功输出的成本，测试小模型是否达到质量要求
• 隐私敏感或受监管的数据：路由决策根本不是能力问题——而是数据能否离开你的基础设施

这个框架——按任务类型路由而不是选冠军——才是真正重要的架构决策。你今天选的具体模型，六个月后未必还是你在用的模型。提供商定价、新模型发布、你自己的微调都会改变最优路由。先构建路由层；把模型选择当作参数，而不是承诺。

真正让团队在生产中翻车的事

回顾有文档记录的生产 LLM 失败案例，呈现出一致的规律：团队低估了"通过评估"和"对用户有效"之间的差距。

最常见的失败模式不是模型质量问题——而是选型错配：

• Token 成本意外：每 token 便宜 40% 的模型，如果失败率达到 30% 需要重试或人工审核，实际每次成功输出成本可能贵 3 倍
• 速率限制错配：团队基于能力选了模型，然后发现生产吞吐量超过了该层级的 TPM 限制，在流量高峰时导致队列积压和延迟尖峰
• 拒绝率悄然上升：在测试中正常工作的模型，在提供商进行安全更新后开始拒绝更多查询。没有通知，没有版本号变化——拒绝率就是变了
• 结构化输出悄然漂移：当模型收到略微超出其训练分布的输入时，JSON schema 合规性会悄然下降，导致下游解析失败被记录为应用错误而非模型错误

这些失败有一个共同的根本原因：团队在与生产不同的条件下评估了模型。他们在低并发、精心挑选的输入、提供商更新改变行为之前的某个时间点进行了测试。

应该驱动模型选择的指标

正确的衡量单位不是每美元 token 数——而是每次成功输出的成本。

这包括模型 API 成本，以及：重试开销（模型失败需要重试的频率？）、错误修正时间（工程师需要调试模型失败的频率？）、延迟成本（模型速度如何影响用户转化或满意度？）以及迁移风险（如果切换模型，你的提示需要改多少？）。

每 token 便宜 30% 但输出需要多 20% 工程精力处理边缘情况的模型，实际上未必更便宜。LLM 系统的总拥有成本，对高吞吐量应用而言由推理成本主导，对复杂应用而言由工程成本主导。"最佳"模型的基准，取决于你的系统哪种成本更大。

选模型之前，先确定约束

模型选择是一个约束满足问题。在评估任何模型之前，先写下你的硬约束：

• 数据驻留：推理调用能否离开你的司法管辖区？
• 延迟预算：端到端响应时间的 p95 目标是多少？
• 成本上限：在预期量级下，每次请求最多能承受多少成本？
• 质量下限：什么样的准确率能让这个功能可用，而不只是技术上能跑通？
• 合规要求：HIPAA、PCI、SOC2——哪些适用，哪些提供商有对应认证？

不满足硬约束的模型无需评估即可排除。剩余候选者进行 48 小时冲刺。冲刺结果对应你的决策矩阵，给出可辩护的、有证据支撑的模型选择。

跳过这个流程的团队不是没有理由更快上线——他们只是在承担日后迁移的风险。那次迁移的成本，会超过这次评估冲刺。好好规划。