在模型选型这件事上最常遇到的不是“某个模型怎么调用”而是 grok4.6、gpt5.6、kimi-k3、glm5.2 这些模型同时摆在面前时到底该把哪一个接入业务。版本号更新得越来越快技术社区和热搜词里经常出现这些名字但真正决定选型的不是厂商发布时的宣传截图而是这些模型在你自己任务上的真实表现。很多人把横评理解成打开网页聊天框把同一道题分别问一遍然后凭体感打分。这种方式在闲聊场景下勉强能用一旦要决定生产环境接入哪个模型误差就会被放大到不可接受的程度。这篇文章要做的事是给出一个可复现的横评方法从测试维度设计、用例集构造、批量脚本执行到结果统计、常见坑排查和选型决策每一步都给出具体操作和检查点。1. 为什么模型横评不能只靠聊天界面体感打分1.1 版本号快速迭代横评要先锁定“当前可调用版本”grok4.6、gpt5.6、kimi-k3、glm5.2 这类名字看起来是确定的但实际做评测时首先要确认一件事你现在能调用的 API 版本是不是和被测名字完全一致。模型厂商对版本号的管理方式并不统一有的把同一代内部的小步升级也用新版本号发布有的则在后台静默替换服务端模型。直接对比版本号没有意义真正要比的是“当前时刻、线上真实提供服务的那一个模型”。实际操作中建议先通过各平台的模型列表接口或控制台确认可用模型标识再用一个最简单的 prompt 做冒烟测试确认返回内容确实来自目标模型。如果平台同时存在“旗舰版”“Lite 版”“快照版”等多个档位要保证四个模型都取同一档位否则横评结果会被档位差异污染。1.2 公开跑分不能代替业务场景测试公开榜单上的指标通常来自静态数据集题目固定、评分规则固定厂商可以对这类数据做针对性优化。真实业务任务的形态完全不同它包含私有数据、特定指令风格、特定编程语言版本、特定领域的专业术语还可能要求结构化输出、遵循复杂约束、在长上下文里定位信息。这些内容都不在公开榜单覆盖范围内。因此横评必须建立在业务任务样本上而不是直接引用别人的评测报告。一个模型在公开榜上领先不代表它在你的日志分析、SQL 生成、客服问答场景里同样领先。横评的最终目的不是评出“谁最强”而是找出“谁最适合当前业务”。1.3 横评开始前先确认三个基础前提在写任何脚本之前先确认三件事API 是否已开通当前密钥是否有足够配额。被测模型名称是否是线上可调用的准确标识。四个模型的最大上下文长度、计费单位、并发限制是否一致。这三个前提不解决后续所有数据都可能无效。比如一个模型上下文是 128K另一个是 32K同样的长文档测试就会测出完全不同结果但这里的差异来自产品限制并不代表模型能力差距。横评要区分“模型能力”和“产品限制”至少要在结果表里标注这些前提。2. 先把测试框架定下来再动模型调用2.1 评测维度按业务目标拆分给这四个模型做横评维度划分不能拍脑袋要回看业务目标。如果业务是代码辅助重点就是代码生成、代码调试和格式约束如果业务是中文客服重点就是中文理解、指令遵循和多轮一致性。常用维度如下评测维度说明建议测试内容代码生成能否产出可运行、语义正确的代码算法题、工具函数、SQL 生成代码调试能否根据报错定位问题并修改给定报错日志让模型修复代码逻辑推理能否完成多步骤推理数学题、逻辑题、规划类问题中文理解对中文语境、成语、专业术语的理解成语解释、古文翻译、领域术语回答长文本处理能否在超长文档中检索和归纳摘要、抽取、跨段落问答指令遵循是否严格按照格式和约束输出JSON 输出、字数限制、步骤约束稳定性同一问题多次调用结果是否一致相同 prompt 重复 5 到 10 次成本与时延每次调用的价格和响应时间记录 token 消耗、首字延迟、总延迟实际项目不需要每个维度都做选 4 到 6 个与业务强相关的维度即可。维度越多用例集越大评测成本也越高。2.2 测试用例要可复现、有答案、有区分度测试集要满足三个条件可复现、有答案、有区分度。可复现指每条用例的 prompt 完全固定不能靠模型发挥改题有答案指每条用例都有参考答案或明确评分要点有区分度指题目不能太简单不能让四个模型全都答对也不能全都答错。用例建议用 JSON 保存包含 id、类别、prompt、参考答案和评分要点。下面是一个最小示例[ { id: code-001, category: 代码生成, prompt: 写一个 Python 函数接收字符串列表返回按字符串长度升序排序后的新列表不要修改原列表。, reference: sorted(names, keylen), check: 代码可运行返回新列表不改变原列表 }, { id: reason-001, category: 逻辑推理, prompt: 有 8 个外观相同的球其中 1 个偏重使用天平最少称几次能找出偏重的球并说明步骤。, reference: 2 次两轮三分法, check: 次数正确步骤可执行 }, { id: cn-001, category: 中文理解, prompt: 解释成语“不刊之论”中“刊”的含义并用它写一个应用场景。, reference: “刊”指删改, check: 含义准确场景通顺 } ]每条用例的分类要能对应到评测维度这样统计时可以按维度聚合知道哪个模型在哪个维度掉链子。2.3 评分规则要提前说清楚评分规则越早确定后面越不容易扯皮。建议分两类处理客观题和主观题。客观题只看结果比如代码能否运行、输出 JSON 是否符合 schema、数学题答案是否正确主观题用 1 到 5 分制量表由至少两人独立评分后取平均避免个人口味影响结论。还要提前定义“失败”和“平局”的判定标准。模型返回空内容、抛异常、拒绝回答都算失败两者分数差在 0.5 分以内建议视为平局不要强行拉开差距。这些规则写在一个 README 里和测试用例放在一起保证评测可审计。3. 搭建四个模型的批量横评脚本3.1 环境准备与统一调用封装本地评测环境建议使用 Python 3.10 以上版本。四个模型如果都提供 OpenAI 兼容接口可以用统一的 SDK 封装如果某个模型只有独立 SDK也需要在外层封装成同样的函数签名让上层逻辑无感知。下面是一个统一调用示例from openai import OpenAI def call_model(api_key: str, base_url: str, model: str, prompt: str, temperature: float 0.0, max_tokens: int 2048) - str: 统一封装模型调用不同厂商的 API 差异在这一层屏蔽。 client OpenAI(api_keyapi_key, base_urlbase_url) resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperaturetemperature, max_tokensmax_tokens, ) return resp.choices[0].message.content这里要注意base_url 和 api_key 不要硬编码在脚本里建议通过环境变量或本地配置文件传入。四个模型的超时时间、最大 token 数、温度参数要保持一致否则后面对比时延和输出长度没有意义。3.2 批量执行测试用例批量执行的核心目标是自动化读取 JSON 测试集逐条调用每个模型把输出和耗时保存下来。下面是一个批量执行示例import json import time def batch_evaluate(test_cases: list[dict], runner_fn, model_name: str) - list[dict]: 对单个模型执行完整测试集返回带耗时和错误信息的结果列表。 results [] for case in test_cases: start time.time() try: output runner_fn(model_namemodel_name, promptcase[prompt]) results.append({ case_id: case[id], category: case[category], model: model_name, output: output, latency: round(time.time() - start, 2), error: None, }) except Exception as exc: results.append({ case_id: case[id], category: case[category], model: model_name, output: None, latency: round(time.time() - start, 2), error: str(exc), }) # 避免触发平台的单账号并发限制每条之间加小间隔 time.sleep(0.5) return results if __name__ __main__: with open(test_cases.json, encodingutf-8) as f: cases json.load(f) models [ {name: grok4.6, api_key: ..., base_url: ...}, {name: gpt5.6, api_key: ..., base_url: ...}, {name: kimi-k3, api_key: ..., base_url: ...}, {name: glm5.2, api_key: ..., base_url: ...}, ] all_results [] for model in models: runner lambda prompt, model_namemodel[name]: call_model( api_keymodel[api_key], base_urlmodel[base_url], modelmodel_name, promptprompt, ) all_results.extend(batch_evaluate(cases, runner, model[name])) with open(results.json, w, encodingutf-8) as f: json.dump(all_results, f, ensure_asciiFalse, indent2)脚本运行后会生成一个 results.json。建议一次只跑一个模型四个模型串行跑完避免多个模型共享同一密钥时出现额度竞争。实际项目如果用例数量很大可以改成异步并发但要先确认各平台的 QPS 配额。3.3 结果回收与汇总统计原始结果不能直接用于对比需要先做汇总统计。至少要统计失败率、平均时延、P95 时延这几个指标再结合人工评分生成维度分数。汇总示例import json import statistics def summarize(results: list[dict]) - dict: total len(results) failed sum(1 for r in results if r[error] or not r[output]) latencies [r[latency] for r in results if r[latency] is not None] latencies.sort() p95 latencies[int(len(latencies) * 0.95) - 1] if latencies else None return { total: total, failed: failed, failed_rate: round(failed / total, 3) if total else 0, avg_latency: round(statistics.mean(latencies), 2) if latencies else None, p95_latency: p95, } with open(results.json, encodingutf-8) as f: data json.load(f) for model_name in {grok4.6, gpt5.6, kimi-k3, glm5.2}: model_results [r for r in data if r[model] model_name] print(model_name, summarize(model_results))这里尤其要注意 P95 时延它比平均时延更能反映线上真实体验。平均时延会被大多数正常请求拉低而 P95 能体现最差请求对用户的伤害。4. 核心维度怎么看结果4.1 代码生成与调试要的是可运行而不是像代码类题目的评分标准只有一个核心能不能运行、是否满足约束。在初筛阶段可以把所有模型生成的代码统一放进同一套测试用例里执行统计通过率。比如四个模型都生成同一个排序函数用同一组输入做断言通过数量就是客观分。代码调试类题目则要关注模型能否从报错日志中定位根因。建议在 prompt 中给出一段带 bug 的代码和对应的堆栈信息要求模型指出问题并给出修复版本。评分时不仅要看修复对不对还要看解释是否落到根因上。很多模型能修出正确代码但解释完全是套话这种在真实开发中价值有限。4.2 中文理解和长文本注意截断和上下文策略中文理解类题目要覆盖常见的中文语言现象包括成语、古文、领域术语和歧义句。评分要点是准确性不是文采。比如解释成语时核心字义错了即使语境句子写得很漂亮也应该扣分。长文本测试最容易出现“假失败”。如果某个模型的最大上下文只有 32K而测试文档有 50K那么它答不好并不是能力问题而是产品限制。建议在测试前先确认四个模型各自的上下文上限把测试文档控制在所有被测模型都能完整接收的长度内如果业务确实需要超长文本处理就单独记录哪些模型能接收、哪些不能作为选型因素而非能力分数。4.3 推理能力看步骤质量而不仅是最终答案推理类题目如果只看最终答案会漏掉关键信息。一个模型可能答案对了但推理过程跳步严重另一个模型答案错但步骤基本正确只是最后一步计算失误。两类问题在真实生产中的性质完全不同后者通常更容易通过二次提示修正。评分时建议同时记录最终答案得分和步骤得分。比如二分查找找次品这道题步骤分要看是否说明分组方式和最坏情况次数。这类评分最好由人完成不要完全依赖模型评模型否则会引入模型偏好。4.4 成本、速度与稳定性生产环境不能忽略的指标能力只是选型的一个维度。线上真实运行时成本、速度、稳定性在很多时候比单题得分更关键。建议在批量脚本中记录每次调用的 token 数结合各平台定价估算单次成本。同时记录失败率和重试触发次数一个偶尔返回无用内容的模型哪怕答得很好也会消耗大量工程精力。稳定性测评最简单的方式是选取 10 到 20 条代表性 prompt对每个模型重复调用 5 次检查输出差异。对于要求确定性输出的场景比如 JSON 抽取和 SQL 生成建议统一使用 temperature0并统计 schema 校验通过率。5. 横评中最容易踩的五个坑5.1 温度参数不一致导致结果失真如果四个模型一个用 temperature0、一个用 temperature0.7同一道开放题的结果几乎没有可比性。高温会让输出多样化低温会让输出更确定。横评时如果不测多样性就统一用 temperature0如果专门测多样性要保证四个模型用同一组温度档位并多次采样。5.2 对每个模型用不同 prompt有人习惯给推理弱的模型加“请一步步思考”给推理强的模型直接问这会让结果不公平。缓解推理强弱的正确方式不是改 prompt而是保持同一个 prompt让各模型自己判断是否需要推理步骤。如果确实要为所有模型加链式思考提示也必须是同一个模板不允许单独优待某个模型。5.3 超长输入被静默截断部分平台的 API 在输入超过上下文限制时会报错但也有平台选择静默截断。截断后的长文本测试结果没有任何参考价值。检查方式是查看返回内容是否包含截断标识或对比输出中是否缺失文档尾部信息。建议在长文本用例里埋一个只有文档末尾才出现的关键信息要求模型抽取以此判断内容是否完整进入上下文。5.4 并发限流让时延数据失去参考价值批量脚本如果并发度过高会触发平台限流返回 429 或出现排队等待导致时延数据被严重拉高。这不代表模型本身慢而是测试方式造成的问题。处理办法是控制并发数、在每次请求之间加间隔并把限流错误单独记录不要计入正常时延统计。5.5 统计口径不一致评分无法复现四个模型分别由四个人打分标准各不相同最后的分数无法合并。更常见的错误是只记录了评分结果没有保存模型原始输出后续想复核时无从看起。建议每条用例的评分都绑定原始输出、模型名、温度参数和调用时间保证任何一条评分都能追溯到原始数据。以下是常见坑的速查表问题现象常见原因检查方式处理建议同一题目结果差异很大温度参数不一致或采样次数不足检查调用参数重复采样看分布统一 temperature0关键题采样 5 次以上某模型长文题总答不好输入被截断或上下文上限不同对比四个模型的上下文上限检查截断标识统一输入长度分别记录限制差异某个模型时延特别高并发过高触发限流或账号配额不足查看 429 错误码和重试日志降低并发增加退避重试单独统计限流评分后无法复核只存分数没存原始输出检查结果文件结构每条结果保存完整 prompt、output、参数、时间结果不能复现用例被人工修改过或没有版本管理检查用例文件是否被改动测试用例进 Gitprompt 不允许运行时修改6. 从横评结果到最终选型6.1 按业务场景给指标加权综合评分不是简单求平均。不同业务对同一个指标权重完全不同。代码助手场景里代码生成正确率权重可以到 40%中文理解可能只占 10%客服问答场景里中文理解、指令遵循的权重要显著提高批量数据处理场景里P95 时延和成本权重会更高。建议先列业务的核心指标再为每个指标分配权重最后用加权平均算出每个模型的总分。权重分配必须有业务依据最好由产品、后端、算法三方共同确认而不是一个人说了算。6.2 综合评分表怎么填下面是一个综合评分表模板实际使用时要根据业务替换权重评测维度权重grok4.6gpt5.6kimi-k3glm5.2代码生成20%待填待填待填待填代码调试15%待填待填待填待填逻辑推理15%待填待填待填待填中文理解20%待填待填待填待填长文本处理10%待填待填待填待填指令遵循10%待填待填待填待填稳定性10%待填待填待填待填加权总分100%待填待填待填待填权重确定后评测脚本可以直接把模型原始结果和人工评分合并计算出加权总分避免手工填表出错。6.3 横评只是起点灰度验证才是终点横评得到的是“静态快照”真实业务还有更多变量真实用户提问方式、多轮对话、工具调用、上下文累积、接口稳定性、安全合规要求。这些无法在一次性横评里完全覆盖。正确做法是先用横评缩小候选范围从四个模型选两个进入灰度在真实流量上观察 1 到 2 周再定最终方案。灰度阶段要关注横评里测不到的指标包括请求成功率、错误率、用户反馈、平均对话轮数、人工介入率。生产环境接入还要额外考虑日志记录、监控告警、配置外置、异常处理和回滚方案这些都需要在选型确定后同步建设。7. 横评检查清单与版本更新后的重跑建议一次完整横评的检查清单如下可以直接复制到项目文档里逐项确认模型名称已通过平台控制台确认不是凭记忆填写。四个模型的档位一致都是旗舰或都是 Lite。测试用例已进 Git包含 id、类别、prompt、参考答案、评分要点。测试脚本统一了 temperature、max_tokens、超时时间。长文本用例考虑了四个模型的上下文上限并单独记录产品限制。批量执行记录了原始输出、错误信息、latency 和调用时间。客观题有自动判分主观题至少两人独立评分。结果统计包含失败率、平均时延、P95 时延、token 消耗和成本估算。综合评分表按业务权重加权权重有业务依据。横评结论限定了“当前版本”和“当前测试集”不无限外推。模型版本更新很快。今天测出的 grok4.6、gpt5.6、kimi-k3、glm5.2 的优势分布在下一次版本发布后可能完全变化。建议把测试集和脚本作为固定资产保留每次新版本发布后重跑一遍对比分数变化趋势。选型给业务带来的收益恰恰来自这套持续更新的横评机制而不是某一次评测的静态结论。