1. 当我们在聊"厂商AI能力对比"时，到底在比什么第一次看到"厂商AI能力对比"这个题目，很多人脑子里蹦出来的第一反应是跑分——把几家的大模型拉出来，喂同一套题，看谁答得准、答得快、答得便宜。我一开始也是这么想的，直到真正把这件事当成一个持续性的项目来做，才发现跑分只是冰山露出水面的那一角。水面之下，是模型能力、工程能力、生态能力、成本结构、合规边界这五根柱子撑起来的整套评估体系。你只比跑分，就像只凭百米冲刺成绩去判断一个运动员的综合素质，短跑冠军未必能跑马拉松，更未必能带队打比赛。这篇内容适合三类人看。第一类是做技术选型的工程师，手里攥着一个具体需求，要在几家厂商之间做决定，需要一套可落地的评估方法而不是拍脑袋。第二类是做产品规划的人，想知道当前各家AI能力的真实边界在哪里，哪些需求现在能接、哪些还得等。第三类是纯粹对这个领域好奇的从业者，想搞清楚"对比"这件事本身的方法论，避免被各种营销话术带偏。我会把整个评估框架拆开，讲清楚每一层比什么、怎么比、比出来的结果怎么解读，再补上我自己在实操中踩过的坑和总结出来的经验。需要先说明一点：这篇内容不会给出"某某厂商第一"这种结论。原因很简单，AI能力的对比高度依赖场景。一个在代码生成上表现突出的模型，放到长文档摘要任务里可能平平无奇；一个响应速度极快的轻量模型，遇到复杂推理就露怯。脱离场景谈排名，基本等于耍流氓。所以我要给你的不是一份排行榜，而是一套你自己就能用的评估方法论，以及我在搭建这套方法论过程中积累的具体操作细节。2. 评估框架的五个维度：从"能答对"到"能落地"的完整链路2.1 基础模型能力：不只是准确率这一个数字基础模型能力是整个评估的地基。很多人一上来就看准确率，但准确率这个指标本身就有很多种算法——是严格匹配还是语义匹配？是单轮还是多轮？是开放问答还是选择题？不同的算法算出来的数字能差出十几个百分点。我在实操中的做法是，把基础能力拆成四个可独立测量的子项：知识准确性、推理深度、指令遵循度、输出稳定性。知识准确性测的是模型对事实性问题的回答质量。这里有个坑：很多评测集里的题目在训练数据里可能已经出现过了，模型答对不代表它真的"会"，可能只是"背过"。我的应对办法是自建一套时效性强的测试题，比如用最近三个月内发生的行业事件来提问，这样能有效规避数据污染的问题。推理深度测的是多步逻辑链条的保持能力，典型做法是给一道需要三到五步推导的数学应用题或逻辑题，看模型在哪一步开始出错。指令遵循度测的是模型对格式要求、角色设定、约束条件的遵守情况，比如要求"用JSON格式输出且字段名必须为小写下划线风格"，看它是否严格执行。输出稳定性则是同一个问题问五遍，看答案的方差有多大——方差大的模型在生产环境里是灾难，因为你没法保证用户体验的一致性。这四个子项的权重怎么分配，完全取决于你的场景。做客服机器人的，指令遵循度和输出稳定性权重最高；做研究辅助的，推理深度和知识准确性更关键。我一般会做一个加权评分表，把每个子项的得分乘以场景权重，最后得出一个综合分。这个表长什么样，后面会给出具体模板。2.2 工程化能力：决定"能用"和"好用"的分水岭基础能力过关之后，下一个要看的维度是工程化能力。这一层最容易被忽视，但它恰恰是决定一个AI能力能不能真正落地到生产环境的关键。我见过太多团队在Demo阶段被模型的基础能力惊艳到，结果一上生产就发现各种问题：并发一高就超时、长文本一多就截断、流式输出断断续续、错误码返回得莫名其妙。工程化能力我主要看五个指标。第一是接口响应延迟，注意要区分首Token延迟和整体完成延迟，前者影响用户的"等待感"，后者影响任务的"完成效率"。第二是并发承载能力，这个不能只看官方文档写的QPS数字，要自己压测，而且要在不同输入长度下分别压测——很多服务在短输入下QPS很高，输入一长就断崖式下跌。第三是长文本处理能力，包括最大上下文窗口的实际可用长度（有些标称128K但实际到64K就开始丢信息）、长文本下的注意力保持质量、以及长文本处理的计费方式。第四是流式输出的稳定性，这个在交互式应用里特别重要，流式输出如果经常卡顿或断流，用户体验会非常糟糕。第五是错误处理机制，包括错误码的清晰度、限流策略的合理性、以及重试机制的支持情况。这里分享一个我踩过的坑。早期做选型时，我只测了单次请求的延迟，觉得各家都差不多。结果上线后发现，某家服务在并发超过20路之后，延迟直接从800毫秒飙到8秒以上，而另一家在同样并发下只涨到1.5秒。后来才知道，前者用的是共享推理集群，后者给的是独享配额。这个差异在官方文档里根本不会写，只能靠实际压测才能发现。所以我的建议是，工程化能力的评估一定要在接近真实生产环境的条件下做压测，不要只看文档参数。2.3 生态与工具链：模型之外的竞争力第三个维度是生态与工具链。这一层比的是模型之外的东西：有没有好用的SDK、有没有完善的文档、有没有活跃的开发者社区、有没有配套的微调工具、有没有现成的插件市场。这些东西不直接决定模型能力，但极大影响你的开发效率和长期维护成本。我评估生态时最看重三样东西。第一是文档质量，具体看文档的更新频率、示例代码的可运行性、以及API变更时的迁移指南是否清晰。我遇到过某家厂商的文档，示例代码里的参数名和实际API对不上，照着抄都跑不通，这种文档还不如没有。第二是SDK的成熟度，包括支持的语言种类、版本迭代频率、以及是否有类型定义（TypeScript的.d.ts文件、Python的type hints等）。第三是社区活跃度，这个可以看官方论坛的提问量和回复速度、GitHub上相关仓库的issue处理情况、以及第三方教程的数量和质量。还有一个容易被忽视的点是微调与定制能力。有些厂商提供完整的微调工具链，从数据标注到训练到部署一站式搞定；有些只提供API，微调得自己想办法。如果你的场景需要深度定制，这个差异会非常关键。我一般会做一个生态能力对照表，把各家在文档、SDK、社区、微调、插件这几个子项上的表现列出来，用星级评分，一目了然。2.4 成本结构：不只看单价，要看总拥有成本成本是选型时绕不开的话题，但很多人只看API的单价——每百万Token多少钱。这个看法太片面了。真实的成本结构要复杂得多，我把它拆成四块：直接调用成本、隐性工程成本、迁移成本和机会成本。直接调用成本就是API账单，但要注意计费方式的差异。有的按输入输出分别计价，有的统一计价，有的对缓存命中打折，有的对批量调用优惠。这些差异在用量大的时候能差出好几倍。隐性工程成本包括为了适配某家API而额外写的代码、为了处理它的限流而搭的队列系统、为了监控它的调用质量而建的日志体系。这些成本不会出现在账单上，但会实实在在消耗团队的人力。迁移成本是你从一家换到另一家时需要付出的代价，包括代码改造、数据迁移、重新测试等。机会成本则是因为选了某家而错过的其他可能性——比如选了不支持微调的，就失去了深度定制的机会。我一般会算一个"总拥有成本"（TCO），把上面四块都折算成钱，再除以预期的调用量，得出一个"有效单价"。这个有效单价才是做决策时真正该看的数字。很多时候，单价最低的那家，算上隐性工程成本后反而最贵。2.5 合规与安全：不能妥协的底线最后一个维度是合规与安全。这一层平时不显山露水，但一旦出问题就是大问题。我主要看四个方面：数据使用政策是否清晰、内容安全机制是否完善、服务等级协议是否可靠、以及是否有相关的资质认证。数据使用政策要重点看两点：你的数据会不会被用于模型训练、数据存储在哪里、保留多久。有些厂商默认会用客户数据做训练，需要手动申请才能关闭；有些则默认不用于训练。这个差异对处理敏感数据的企业来说非常关键。内容安全机制包括输入输出的过滤能力、敏感信息的识别与脱敏、以及是否支持自定义安全策略。服务等级协议要看可用性承诺、故障赔偿条款、以及历史可用性记录。资质认证则包括各类安全认证和行业合规认证，这些在特定行业（如金融、医疗）是硬性门槛。我的经验是，合规与安全这一层不要等到最后才看，要在选型初期就作为筛选条件。如果某家厂商在数据政策上不能满足你的合规要求，那它的模型能力再强也不能用，早筛掉早省事。3. 搭建可复现的评测流水线：从手工测试到自动化跑批3.1 评测集的设计：覆盖度比数量更重要要对比厂商AI能力，第一件事是设计一套评测集。很多人觉得评测集越大越好，其实不然。一套设计良好的小评测集（比如200道题），比一套随意拼凑的大评测集（比如2000道题）更有价值。关键在于覆盖度——你的评测集要能覆盖你实际场景中会遇到的各类任务。我的评测集设计方法是"三层金字塔"。底层是通用能力题，覆盖知识问答、逻辑推理、数学计算、代码生成、文本摘要、翻译、创意写作等基础任务，每类10到20题，用来测基础能力的广度。中层是场景题，完全模拟你的真实业务场景，比如如果你是做法律咨询的，就放合同审查、法条检索、案例分析这类题目，用来测场景适配度。顶层是压力题，专门挑那些容易出错的边界情况，比如超长输入、多轮复杂指令、包含陷阱的推理题，用来测能力上限和稳定性。每道题都要有明确的评分标准。我一般用三级评分：完全正确得2分，部分正确得1分，错误得0分。对于开放式题目（如创意写作），则用人工评分或模型评分（用另一个模型来打分），评分维度包括相关性、完整性、流畅度、创意性等。评分标准要提前定好，不能边测边改，否则结果不可比。这里有个实操细节：评测集里的题目要定期更新。我一般每季度换掉20%的题目，把那些已经被模型"学会"的题目替换成新的。这样才能持续测出模型的真实能力边界，而不是在测它的记忆力。3.2 自动化跑批框架：用代码代替手工手工测试只能做小样本，要做大规模对比必须自动化。我搭的跑批框架核心就三样东西：统一的调用接口、并行的执行引擎、结构化的结果存储。统一调用接口的作用是把不同厂商的API差异屏蔽掉。每家API的请求格式、认证方式、返回结构都不一样，如果每测一家就改一次测试代码，效率太低。我的做法是写一个适配层，对外暴露统一的call_model(prompt, params)接口，内部根据厂商类型路由到不同的实现。这样测试代码只需要写一遍，换厂商时只改适配层。并行执行引擎用来加速跑批。200道题如果串行跑，每道题平均3秒，就是10分钟；如果并发10路，1分钟就跑完了。但并发要注意控制速率，别把人家API打限流了。我一般会根据厂商的限流策略设置并发数，并在代码里加上指数退避的重试逻辑。结果存储用结构化的格式，我习惯用JSON Lines，每行一条记录，包含题目ID、厂商、模型版本、输入、输出、耗时、Token用量、评分等字段。这样后续做统计分析非常方便，用pandas一读就能出各种对比图表。import json import time from concurrent.futures import ThreadPoolExecutor, as_completed def run_evaluation(test_cases, model_adapter, max_workers=10): results = [] with ThreadPoolExecutor(max_workers=max_workers) as executor: future_to_case = { executor.submit(evaluate_single, case, model_adapter): case for case in test_cases } for future in as_completed(future_to_case): case = future_to_case[future] try: result = future.result() results.append(result) except Exception as e: results.append({ "case_id": case["id"], "error": str(e), "score": 0 }) return results def evaluate_single(case, adapter): start = time.time() response = adapter.call_model(case["prompt"], case.get("params", {})) elapsed = time.time() - start score = auto_score(response, case["expected"]) return { "case_id": case["id"], "output": response, "elapsed": elapsed, "score": score }这段代码的核心逻辑很直白：把测试用例分发给线程池，每个线程独立调用模型并评分，最后汇总结果。实际使用时还要加上重试、限流、日志等逻辑，但骨架就是这样。3.3 评分环节的自动化与人工校准自动评分能覆盖大部分客观题，但主观题还是需要人工校准。我的做法是"自动评分打底，人工抽检校准"。具体来说，客观题（选择题、填空题、有标准答案的计算题）用规则匹配或语义相似度自动评分；主观题先用模型评分，然后人工抽检10%到20%的样本，看模型评分和人工评分的一致性。如果一致性低于90%，就调整评分提示词或评分标准，直到一致性达标。模型评分本身也有讲究。我一般会用比被测模型更强的一个模型来做评分，并且给评分模型提供详细的评分标准和示例。评分提示词里要明确告诉它：从哪几个维度评、每个维度的分值范围、什么样的回答得高分、什么样的得低分。评分提示词的质量直接决定评分结果的可靠性，这个环节值得多花时间打磨。还有一个细节：评分时要隐藏模型的来源。也就是说，评分模型不知道这个回答是哪个厂商生成的，避免品牌偏见影响评分。我一般会把所有模型的回答混在一起，随机排序后再送去评分。4. 实测中的意外发现：那些跑分看不出来的差异4.1 同一个问题问五遍，答案能差多少输出稳定性是我在实测中最意外的发现。我原本以为，同一个问题问同一个模型，答案应该基本一致。实测下来完全不是这样。有些模型在温度参数设为0的情况下，同一个问题问五遍，答案的核心结论能出现三种不同的版本。这在生产环境里是致命的——用户今天问和明天问得到不同的答案，信任感直接崩塌。我专门做了一个稳定性测试：选20道有明确答案的题目，每道题问5遍，统计答案的一致性。结果发现，不同厂商的稳定性差异非常大。最稳定的模型，20道题里只有1道出现了答案波动；最不稳定的，有7道题出现了明显不同的答案。而且这个稳定性和模型大小没有直接关系，有些小模型反而更稳定，可能是因为它们的输出空间更受限。这个发现直接影响了我的选型策略。对于需要高一致性的场景（如客服、知识库问答），我把稳定性作为一票否决项——稳定性不达标的模型，能力再强也不用。对于创意类场景（如文案生成），稳定性反而没那么重要，多样性甚至是优点。4.2 长文本处理：标称128K，实际能用多少长文本处理是另一个重灾区。现在很多模型标称支持128K甚至更长的上下文，但实际可用长度往往要打折扣。我做过一个测试：把一份5万字的文档喂给标称128K的模型，让它回答文档末尾的一个细节问题。结果发现，有些模型能准确回答，有些则完全找不到，还有些给出了看似合理但实际错误的答案——这种最危险，因为它看起来像对的。我的测试方法是"针尖测试"：在一份长文档的不同位置（开头、中间、结尾）埋入几个特定的信息点，然后提问这些信息点，看模型能否准确检索到。测试结果显示，大部分模型在文档前1/3部分的检索准确率很高，到了后1/3就开始下降，有些模型在最后10%的部分准确率跌到50%以下。这意味着，标称128K的模型，实际可靠的处理长度可能只有64K甚至更少。实操建议：如果你的场景涉及长文本，不要只看标称的上下文窗口大小，一定要自己做针尖测试，测出模型的实际可靠处理长度。然后在生产环境里留出安全余量，比如实际可靠长度是64K，那你的输入就控制在48K以内。4.3 指令遵循：为什么模型总是不听你的格式要求指令遵循度是另一个跑分看不出来的维度。跑分高的模型，不代表它听话。我遇到过模型能力很强但完全不遵守格式要求的情况：要求输出JSON，它给你输出一段带解释的文字；要求用中文回答，它给你飙英文；要求控制在100字以内，它给你写500字。我分析下来，指令遵循度差主要有三个原因。第一是模型的指令微调不够充分，它更擅长"自由发挥"而不是"按规矩办事"。第二是提示词本身有歧义，比如"简洁地回答"这个要求就很模糊，模型不知道多简洁才算简洁。第三是模型的"自我表达欲"太强，总想补充一些它认为有用的信息，哪怕你没要求。应对策略有三条。第一，把格式要求放在提示词的最前面和最后面，首尾呼应，强化模型的记忆。第二，用具体的数字和示例代替模糊的描述，比如不说"简洁回答"，而说"用不超过50个字回答，不要有任何解释性文字"。第三，如果模型还是不听话，就在提示词里加入"如果你不遵守格式要求，回答将被视为错误"这样的负向激励，实测下来能显著提升遵循度。4.4 成本陷阱：那些账单上看不见的支出成本这块我踩的坑最多。最开始做选型时，我只看API单价，选了一家单价最低的。结果上线一个月后算总账，发现实际支出比预期高了40%。仔细一查，多出来的成本来自三个方面：一是重试成本，那家服务不稳定，经常超时，代码里的重试逻辑导致实际调用量比预期多了15%；二是长文本成本，那家对长文本的计费方式是按最大上下文窗口算的，哪怕你只用了十分之一；三是适配成本，为了适配那家的API，团队多花了将近两周的开发时间。后来我学乖了，做成本评估时一定要算"有效单价"。有效单价的计算公式是：总支出除以有效调用量。总支出包括API账单、重试浪费、适配开发的人力折算、监控运维的人力折算。有效调用量是实际产生业务价值的调用次数，不包括重试和失败调用。用这个公式算下来，很多单价低的厂商其实并不便宜。还有一个隐藏成本是"锁定成本"。如果你深度使用了某家厂商的专有功能（比如特定的微调接口、专有的插件系统），迁移到别家的成本会非常高。这个成本在选型时就要考虑进去，不能只看眼前的单价。5. 从评测结果到选型决策：怎么把数据变成行动5.1 加权评分模型：让决策有据可依评测做完之后，手里会有一堆数据。怎么把这些数据变成选型决策？我的做法是建一个加权评分模型。具体来说，把前面说的五个维度（基础能力、工程化能力、生态工具链、成本结构、合规安全）作为一级指标，每个一级指标下再设若干二级指标，然后根据你的场景给每个指标分配权重，最后加权求和得出综合分。权重的分配是主观的，但要有依据。我的方法是让所有利益相关方（产品、技术、运维、合规）一起讨论，各自给出权重建议，然后取加权平均。这样得出的权重虽然不是绝对客观，但至少代表了团队的共识，后续决策时不会有人跳出来说"你当时没考虑我的需求"。下面是一个加权评分表的模板，你可以直接拿去用：一级指标二级指标权重厂商A得分厂商B得分厂商C得分基础能力知识准确性10%897基础能力推理深度8%796基础能力指令遵循度7%688基础能力输出稳定性10%597工程化响应延迟8%789工程化并发承载7%678工程化长文本处理5%586生态文档质量4%796生态SDK成熟度4%687成本有效单价10%869合规数据政策10%788合规安全机制7%697合计100%6.68.17.4这个表里的得分是1到10分的评分，权重加起来是100%。最后算出来的综合分，厂商B最高。但注意，这个结果高度依赖权重分配。如果你的场景对成本极度敏感，把成本权重提到20%，结果可能就变了。所以这个表的价值不在于给出一个"正确答案"，而在于让决策过程透明化——每个人都能看到为什么选了这个而不是那个。5.2 场景化选型：没有万能模型，只有合适模型加权评分模型给出的是一个综合分，但实际选型时往往不是选综合分最高的，而是选最适合你场景的。我一般会做"场景化选型"：针对不同的业务场景，分别选出最合适的模型。比如，对于实时客服场景，响应延迟和输出稳定性的权重最高，基础能力的权重可以适当降低，因为客服场景的问题通常不复杂。对于内容创作场景，创意性和知识准确性的权重最高，延迟和成本可以放宽。对于数据分析场景，推理深度和长文本处理能力最关键，其他都可以妥协。这意味着，一个团队可能同时使用多家厂商的模型——客服用A家，创作B家，分析用C家。这听起来麻烦，但实际上是更理性的选择。我的建议是，不要追求"一家通吃"，而是根据场景组合使用。当然，组合使用会增加工程复杂度，所以要在收益和复杂度之间做权衡。一般来说，如果场景差异很大，组合使用的收益是值得的。5.3 持续监控：选型不是一次性决策最后要强调的是，选型不是一次性决策，而是一个持续的过程。厂商的模型在迭代，你的业务需求也在变化，今天的最优解明天可能就不是了。所以选型之后要建立持续监控机制。我一般会监控三类指标。第一类是质量指标，包括准确率、稳定性、用户满意度等，按月统计，看是否有下降趋势。第二类是性能指标，包括延迟、可用性、错误率等，实时监控，设置告警阈值。第三类是成本指标，包括实际支出、有效单价、重试率等，按周统计，看是否有异常增长。监控数据要定期回顾，我一般每季度做一次全面的选型回顾，看看是否需要调整。如果某家厂商的质量持续下降，或者成本持续上升，就要考虑迁移。迁移是有成本的，所以不能频繁迁，但也不能因为怕麻烦就一直忍着。我的经验是，当某家厂商的综合评分连续两个季度低于替代方案15%以上时，就值得启动迁移评估了。6. 我在搭建这套评估体系时踩过的坑6.1 评测集泄露：当模型"见过"你的题目第一个坑是评测集泄露。我早期做评测时，把评测集放在了一个公开的代码仓库里。结果过了几个月，发现某家模型在我评测集上的得分突然大幅提升，一开始还挺高兴，以为模型进步了。后来仔细一查，发现那家模型的新版本训练数据里可能包含了我的评测集——因为我的评测集是公开的，被爬虫抓走了。这个坑的教训是：评测集一定要保密。我现在会把评测集放在私有仓库里，访问权限严格控制。而且评测集里的题目要定期更换，不能一套题用一年。另外，评测时要注意"数据污染"的问题——如果一道题的答案在训练数据里出现过，那模型答对不代表它真的会。我的应对方法是自建时效性强的题目，用最近发生的事件来提问，这样能有效规避污染。6.2 评分标准漂移：为什么两次评测结果不可比第二个坑是评分标准漂移。我第一次做评测时，评分标准是边测边定的，测到一半觉得某个标准不合理就改了。结果测完之后发现，前半部分和后半部分的评分标准不一致，整个结果没法用。后来我定了一个规矩：评分标准必须在评测开始前完全确定，评测过程中不能改。如果确实发现标准有问题，就暂停评测，改完标准后重新开始，不能中途改。这个规矩听起来简单，但执行起来需要自律。因为评测过程中总会遇到一些"意外情况"，让你想临时调整标准。我的建议是，把这些意外情况记录下来，作为下一轮评测的改进点，而不是当场改标准。6.3 过度依赖自动评分：那些被误判的答案第三个坑是过度依赖自动评分。我早期为了省事，全部用自动评分，结果发现有些答案被误判了。比如一道题要求"用一句话总结"，模型用两句话总结了，内容完全正确，但自动评分因为字数超了判了0分。还有一道开放题，模型的回答很有创意，但和参考答案的措辞差异很大，自动评分给了低分，人工一看其实是好答案。这个坑的教训是：自动评分只能作为初筛，不能作为最终结论。我现在会做"自动评分+人工抽检"的双重校验。自动评分先跑一遍，然后人工抽检10%到20%的样本，重点看那些自动评分给出极端分数（特别高或特别低）的样本。如果发现误判率超过10%，就调整自动评分规则，直到误判率降到可接受范围。6.4 忽视工程化测试：Demo很美好，上线就崩溃第四个坑是忽视工程化测试。我早期做选型时，只测了模型的基础能力，觉得各家都差不多，就选了一家文档写得最漂亮的。结果上线后发现，那家的API在高并发下极不稳定，延迟波动巨大，还经常返回莫名其妙的错误码。后来才知道，那家厂商的推理集群是共享的，高峰期资源争抢严重。这个坑的教训是：工程化测试和基础能力测试同等重要，甚至更重要。基础能力不行，最多是效果差一点；工程化不行，那是直接不能用。我现在做选型时，工程化测试的权重至少占40%，而且一定要在接近真实生产环境的条件下做压测。压测时要模拟真实的并发量、输入长度分布、以及各种边界情况。7. 一套可以直接抄的评测执行清单说了这么多方法论，最后给一份可以直接执行的清单。这份清单是我经过多个项目迭代后沉淀下来的，你可以根据自己的情况调整。准备阶段：明确评测目标：是选型、验收还是持续监控？目标不同，评测集和评分标准的设计也不同。确定评测维度与权重：召集利益相关方讨论，形成书面共识。设计评测集：按"通用能力+场景题+压力题"三层结构设计，总量控制在200到500题。确定评分标准：客观题用规则匹配，主观题用模型评分+人工抽检，评分标准提前定好不改。准备测试环境：确保网络稳定、API配额充足、日志记录完整。执行阶段：先跑小样本（20到30题）验证流程，确认调用、评分、存储各环节正常。跑全量评测集，每个模型至少跑一遍，关键模型跑三遍取平均。同步做工程化压测：测延迟、并发、长文本、流式输出、错误处理。记录所有原始数据，包括输入、输出、耗时、Token用量、错误信息。分析阶段：计算各维度得分，填入加权评分表。做稳定性分析：同一题目的多次回答一致性如何。做长文本针尖测试：实际可靠处理长度是多少。做成本核算：算有效单价，不只看API单价。人工抽检评分结果，校准自动评分的准确性。决策阶段：根据加权评分和场景化需求，选出首选和备选方案。制定迁移和回滚预案。建立持续监控机制，设定质量、性能、成本的告警阈值。约定每季度做一次选型回顾。这份清单看起来长，但真正执行起来，一个完整的评测周期大概需要两到三周。相比选错模型后付出的代价，这两三周的投入是非常值得的。我在实际项目中的体会是，评测做得越扎实，后续的运维就越省心。那些在评测阶段偷的懒，都会在上线后以各种意想不到的方式还回来。
1. 当我们在聊"厂商AI能力对比"时，到底在比什么第一次看到"厂商AI能力对比"这个题目，很多人脑子里蹦出来的第一反应是跑分——把几家的大模型拉出来，喂同一套题，看谁答得准、答得快、答得便宜。我一开始也是这么想的，直到真正把这件事当成一个持续性的项目来做，才发现跑分只是冰山露出水面的那一角。水面之下，是模型能力、工程能力、生态能力、成本结构、合规边界这五根柱子撑起来的整套评估体系。你只比跑分，就像只凭百米冲刺成绩去判断一个运动员的综合素质，短跑冠军未必能跑马拉松，更未必能带队打比赛。这篇内容适合三类人看。第一类是做技术选型的工程师，手里攥着一个具体需求，要在几家厂商之间做决定，需要一套可落地的评估方法而不是拍脑袋。第二类是做产品规划的人，想知道当前各家AI能力的真实边界在哪里，哪些需求现在能接、哪些还得等。第三类是纯粹对这个领域好奇的从业者，想搞清楚"对比"这件事本身的方法论，避免被各种营销话术带偏。我会把整个评估框架拆开，讲清楚每一层比什么、怎么比、比出来的结果怎么解读，再补上我自己在实操中踩过的坑和总结出来的经验。需要先说明一点：这篇内容不会给出"某某厂商第一"这种结论。原因很简单，AI能力的对比高度依赖场景。一个在代码生成上表现突出的模型，放到长文档摘要任务里可能平平无奇；一个响应速度极快的轻量模型，遇到复杂推理就露怯。脱离场景谈排名，基本等于耍流氓。所以我要给你的不是一份排行榜，而是一套你自己就能用的评估方法论，以及我在搭建这套方法论过程中积累的具体操作细节。2. 评估框架的五个维度：从"能答对"到"能落地"的完整链路2.1 基础模型能力：不只是准确率这一个数字基础模型能力是整个评估的地基。很多人一上来就看准确率，但准确率这个指标本身就有很多种算法——是严格匹配还是语义匹配？是单轮还是多轮？是开放问答还是选择题？不同的算法算出来的数字能差出十几个百分点。我在实操中的做法是，把基础能力拆成四个可独立测量的子项：知识准确性、推理深度、指令遵循度、输出稳定性。知识准确性测的是模型对事实性问题的回答质量。这里有个坑：很多评测集里的题目在训练数据里可能已经出现过了，模型答对不代表它真的"会"，可能只是"背过"。我的应对办法是自建一套时效性强的测试题，比如用最近三个月内发生的行业事件来提问，这样能有效规避数据污染的问题。推理深度测的是多步逻辑链条的保持能力，典型做法是给一道需要三到五步推导的数学应用题或逻辑题，看模型在哪一步开始出错。指令遵循度测的是模型对格式要求、角色设定、约束条件的遵守情况，比如要求"用JSON格式输出且字段名必须为小写下划线风格"，看它是否严格执行。输出稳定性则是同一个问题问五遍，看答案的方差有多大——方差大的模型在生产环境里是灾难，因为你没法保证用户体验的一致性。这四个子项的权重怎么分配，完全取决于你的场景。做客服机器人的，指令遵循度和输出稳定性权重最高；做研究辅助的，推理深度和知识准确性更关键。我一般会做一个加权评分表，把每个子项的得分乘以场景权重，最后得出一个综合分。这个表长什么样，后面会给出具体模板。2.2 工程化能力：决定"能用"和"好用"的分水岭基础能力过关之后，下一个要看的维度是工程化能力。这一层最容易被忽视，但它恰恰是决定一个AI能力能不能真正落地到生产环境的关键。我见过太多团队在Demo阶段被模型的基础能力惊艳到，结果一上生产就发现各种问题：并发一高就超时、长文本一多就截断、流式输出断断续续、错误码返回得莫名其妙。工程化能力我主要看五个指标。第一是接口响应延迟，注意要区分首Token延迟和整体完成延迟，前者影响用户的"等待感"，后者影响任务的"完成效率"。第二是并发承载能力，这个不能只看官方文档写的QPS数字，要自己压测，而且要在不同输入长度下分别压测——很多服务在短输入下QPS很高，输入一长就断崖式下跌。第三是长文本处理能力，包括最大上下文窗口的实际可用长度（有些标称128K但实际到64K就开始丢信息）、长文本下的注意力保持质量、以及长文本处理的计费方式。第四是流式输出的稳定性，这个在交互式应用里特别重要，流式输出如果经常卡顿或断流，用户体验会非常糟糕。第五是错误处理机制，包括错误码的清晰度、限流策略的合理性、以及重试机制的支持情况。这里分享一个我踩过的坑。早期做选型时，我只测了单次请求的延迟，觉得各家都差不多。结果上线后发现，某家服务在并发超过20路之后，延迟直接从800毫秒飙到8秒以上，而另一家在同样并发下只涨到1.5秒。后来才知道，前者用的是共享推理集群，后者给的是独享配额。这个差异在官方文档里根本不会写，只能靠实际压测才能发现。所以我的建议是，工程化能力的评估一定要在接近真实生产环境的条件下做压测，不要只看文档参数。2.3 生态与工具链：模型之外的竞争力第三个维度是生态与工具链。这一层比的是模型之外的东西：有没有好用的SDK、有没有完善的文档、有没有活跃的开发者社区、有没有配套的微调工具、有没有现成的插件市场。这些东西不直接决定模型能力，但极大影响你的开发效率和长期维护成本。我评估生态时最看重三样东西。第一是文档质量，具体看文档的更新频率、示例代码的可运行性、以及API变更时的迁移指南是否清晰。我遇到过某家厂商的文档，示例代码里的参数名和实际API对不上，照着抄都跑不通，这种文档还不如没有。第二是SDK的成熟度，包括支持的语言种类、版本迭代频率、以及是否有类型定义（TypeScript的.d.ts文件、Python的type hints等）。第三是社区活跃度，这个可以看官方论坛的提问量和回复速度、GitHub上相关仓库的issue处理情况、以及第三方教程的数量和质量。还有一个容易被忽视的点是微调与定制能力。有些厂商提供完整的微调工具链，从数据标注到训练到部署一站式搞定；有些只提供API，微调得自己想办法。如果你的场景需要深度定制，这个差异会非常关键。我一般会做一个生态能力对照表，把各家在文档、SDK、社区、微调、插件这几个子项上的表现列出来，用星级评分，一目了然。2.4 成本结构：不只看单价，要看总拥有成本成本是选型时绕不开的话题，但很多人只看API的单价——每百万Token多少钱。这个看法太片面了。真实的成本结构要复杂得多，我把它拆成四块：直接调用成本、隐性工程成本、迁移成本和机会成本。直接调用成本就是API账单，但要注意计费方式的差异。有的按输入输出分别计价，有的统一计价，有的对缓存命中打折，有的对批量调用优惠。这些差异在用量大的时候能差出好几倍。隐性工程成本包括为了适配某家API而额外写的代码、为了处理它的限流而搭的队列系统、为了监控它的调用质量而建的日志体系。这些成本不会出现在账单上，但会实实在在消耗团队的人力。迁移成本是你从一家换到另一家时需要付出的代价，包括代码改造、数据迁移、重新测试等。机会成本则是因为选了某家而错过的其他可能性——比如选了不支持微调的，就失去了深度定制的机会。我一般会算一个"总拥有成本"（TCO），把上面四块都折算成钱，再除以预期的调用量，得出一个"有效单价"。这个有效单价才是做决策时真正该看的数字。很多时候，单价最低的那家，算上隐性工程成本后反而最贵。2.5 合规与安全：不能妥协的底线最后一个维度是合规与安全。这一层平时不显山露水，但一旦出问题就是大问题。我主要看四个方面：数据使用政策是否清晰、内容安全机制是否完善、服务等级协议是否可靠、以及是否有相关的资质认证。数据使用政策要重点看两点：你的数据会不会被用于模型训练、数据存储在哪里、保留多久。有些厂商默认会用客户数据做训练，需要手动申请才能关闭；有些则默认不用于训练。这个差异对处理敏感数据的企业来说非常关键。内容安全机制包括输入输出的过滤能力、敏感信息的识别与脱敏、以及是否支持自定义安全策略。服务等级协议要看可用性承诺、故障赔偿条款、以及历史可用性记录。资质认证则包括各类安全认证和行业合规认证，这些在特定行业（如金融、医疗）是硬性门槛。我的经验是，合规与安全这一层不要等到最后才看，要在选型初期就作为筛选条件。如果某家厂商在数据政策上不能满足你的合规要求，那它的模型能力再强也不能用，早筛掉早省事。3. 搭建可复现的评测流水线：从手工测试到自动化跑批3.1 评测集的设计：覆盖度比数量更重要要对比厂商AI能力，第一件事是设计一套评测集。很多人觉得评测集越大越好，其实不然。一套设计良好的小评测集（比如200道题），比一套随意拼凑的大评测集（比如2000道题）更有价值。关键在于覆盖度——你的评测集要能覆盖你实际场景中会遇到的各类任务。我的评测集设计方法是"三层金字塔"。底层是通用能力题，覆盖知识问答、逻辑推理、数学计算、代码生成、文本摘要、翻译、创意写作等基础任务，每类10到20题，用来测基础能力的广度。中层是场景题，完全模拟你的真实业务场景，比如如果你是做法律咨询的，就放合同审查、法条检索、案例分析这类题目，用来测场景适配度。顶层是压力题，专门挑那些容易出错的边界情况，比如超长输入、多轮复杂指令、包含陷阱的推理题，用来测能力上限和稳定性。每道题都要有明确的评分标准。我一般用三级评分：完全正确得2分，部分正确得1分，错误得0分。对于开放式题目（如创意写作），则用人工评分或模型评分（用另一个模型来打分），评分维度包括相关性、完整性、流畅度、创意性等。评分标准要提前定好，不能边测边改，否则结果不可比。这里有个实操细节：评测集里的题目要定期更新。我一般每季度换掉20%的题目，把那些已经被模型"学会"的题目替换成新的。这样才能持续测出模型的真实能力边界，而不是在测它的记忆力。3.2 自动化跑批框架：用代码代替手工手工测试只能做小样本，要做大规模对比必须自动化。我搭的跑批框架核心就三样东西：统一的调用接口、并行的执行引擎、结构化的结果存储。统一调用接口的作用是把不同厂商的API差异屏蔽掉。每家API的请求格式、认证方式、返回结构都不一样，如果每测一家就改一次测试代码，效率太低。我的做法是写一个适配层，对外暴露统一的call_model(prompt, params)接口，内部根据厂商类型路由到不同的实现。这样测试代码只需要写一遍，换厂商时只改适配层。并行执行引擎用来加速跑批。200道题如果串行跑，每道题平均3秒，就是10分钟；如果并发10路，1分钟就跑完了。但并发要注意控制速率，别把人家API打限流了。我一般会根据厂商的限流策略设置并发数，并在代码里加上指数退避的重试逻辑。结果存储用结构化的格式，我习惯用JSON Lines，每行一条记录，包含题目ID、厂商、模型版本、输入、输出、耗时、Token用量、评分等字段。这样后续做统计分析非常方便，用pandas一读就能出各种对比图表。import json import time from concurrent.futures import ThreadPoolExecutor, as_completed def run_evaluation(test_cases, model_adapter, max_workers=10): results = [] with ThreadPoolExecutor(max_workers=max_workers) as executor: future_to_case = { executor.submit(evaluate_single, case, model_adapter): case for case in test_cases } for future in as_completed(future_to_case): case = future_to_case[future] try: result = future.result() results.append(result) except Exception as e: results.append({ "case_id": case["id"], "error": str(e), "score": 0 }) return results def evaluate_single(case, adapter): start = time.time() response = adapter.call_model(case["prompt"], case.get("params", {})) elapsed = time.time() - start score = auto_score(response, case["expected"]) return { "case_id": case["id"], "output": response, "elapsed": elapsed, "score": score }这段代码的核心逻辑很直白：把测试用例分发给线程池，每个线程独立调用模型并评分，最后汇总结果。实际使用时还要加上重试、限流、日志等逻辑，但骨架就是这样。3.3 评分环节的自动化与人工校准自动评分能覆盖大部分客观题，但主观题还是需要人工校准。我的做法是"自动评分打底，人工抽检校准"。具体来说，客观题（选择题、填空题、有标准答案的计算题）用规则匹配或语义相似度自动评分；主观题先用模型评分，然后人工抽检10%到20%的样本，看模型评分和人工评分的一致性。如果一致性低于90%，就调整评分提示词或评分标准，直到一致性达标。模型评分本身也有讲究。我一般会用比被测模型更强的一个模型来做评分，并且给评分模型提供详细的评分标准和示例。评分提示词里要明确告诉它：从哪几个维度评、每个维度的分值范围、什么样的回答得高分、什么样的得低分。评分提示词的质量直接决定评分结果的可靠性，这个环节值得多花时间打磨。还有一个细节：评分时要隐藏模型的来源。也就是说，评分模型不知道这个回答是哪个厂商生成的，避免品牌偏见影响评分。我一般会把所有模型的回答混在一起，随机排序后再送去评分。4. 实测中的意外发现：那些跑分看不出来的差异4.1 同一个问题问五遍，答案能差多少输出稳定性是我在实测中最意外的发现。我原本以为，同一个问题问同一个模型，答案应该基本一致。实测下来完全不是这样。有些模型在温度参数设为0的情况下，同一个问题问五遍，答案的核心结论能出现三种不同的版本。这在生产环境里是致命的——用户今天问和明天问得到不同的答案，信任感直接崩塌。我专门做了一个稳定性测试：选20道有明确答案的题目，每道题问5遍，统计答案的一致性。结果发现，不同厂商的稳定性差异非常大。最稳定的模型，20道题里只有1道出现了答案波动；最不稳定的，有7道题出现了明显不同的答案。而且这个稳定性和模型大小没有直接关系，有些小模型反而更稳定，可能是因为它们的输出空间更受限。这个发现直接影响了我的选型策略。对于需要高一致性的场景（如客服、知识库问答），我把稳定性作为一票否决项——稳定性不达标的模型，能力再强也不用。对于创意类场景（如文案生成），稳定性反而没那么重要，多样性甚至是优点。4.2 长文本处理：标称128K，实际能用多少长文本处理是另一个重灾区。现在很多模型标称支持128K甚至更长的上下文，但实际可用长度往往要打折扣。我做过一个测试：把一份5万字的文档喂给标称128K的模型，让它回答文档末尾的一个细节问题。结果发现，有些模型能准确回答，有些则完全找不到，还有些给出了看似合理但实际错误的答案——这种最危险，因为它看起来像对的。我的测试方法是"针尖测试"：在一份长文档的不同位置（开头、中间、结尾）埋入几个特定的信息点，然后提问这些信息点，看模型能否准确检索到。测试结果显示，大部分模型在文档前1/3部分的检索准确率很高，到了后1/3就开始下降，有些模型在最后10%的部分准确率跌到50%以下。这意味着，标称128K的模型，实际可靠的处理长度可能只有64K甚至更少。实操建议：如果你的场景涉及长文本，不要只看标称的上下文窗口大小，一定要自己做针尖测试，测出模型的实际可靠处理长度。然后在生产环境里留出安全余量，比如实际可靠长度是64K，那你的输入就控制在48K以内。4.3 指令遵循：为什么模型总是不听你的格式要求指令遵循度是另一个跑分看不出来的维度。跑分高的模型，不代表它听话。我遇到过模型能力很强但完全不遵守格式要求的情况：要求输出JSON，它给你输出一段带解释的文字；要求用中文回答，它给你飙英文；要求控制在100字以内，它给你写500字。我分析下来，指令遵循度差主要有三个原因。第一是模型的指令微调不够充分，它更擅长"自由发挥"而不是"按规矩办事"。第二是提示词本身有歧义，比如"简洁地回答"这个要求就很模糊，模型不知道多简洁才算简洁。第三是模型的"自我表达欲"太强，总想补充一些它认为有用的信息，哪怕你没要求。应对策略有三条。第一，把格式要求放在提示词的最前面和最后面，首尾呼应，强化模型的记忆。第二，用具体的数字和示例代替模糊的描述，比如不说"简洁回答"，而说"用不超过50个字回答，不要有任何解释性文字"。第三，如果模型还是不听话，就在提示词里加入"如果你不遵守格式要求，回答将被视为错误"这样的负向激励，实测下来能显著提升遵循度。4.4 成本陷阱：那些账单上看不见的支出成本这块我踩的坑最多。最开始做选型时，我只看API单价，选了一家单价最低的。结果上线一个月后算总账，发现实际支出比预期高了40%。仔细一查，多出来的成本来自三个方面：一是重试成本，那家服务不稳定，经常超时，代码里的重试逻辑导致实际调用量比预期多了15%；二是长文本成本，那家对长文本的计费方式是按最大上下文窗口算的，哪怕你只用了十分之一；三是适配成本，为了适配那家的API，团队多花了将近两周的开发时间。后来我学乖了，做成本评估时一定要算"有效单价"。有效单价的计算公式是：总支出除以有效调用量。总支出包括API账单、重试浪费、适配开发的人力折算、监控运维的人力折算。有效调用量是实际产生业务价值的调用次数，不包括重试和失败调用。用这个公式算下来，很多单价低的厂商其实并不便宜。还有一个隐藏成本是"锁定成本"。如果你深度使用了某家厂商的专有功能（比如特定的微调接口、专有的插件系统），迁移到别家的成本会非常高。这个成本在选型时就要考虑进去，不能只看眼前的单价。5. 从评测结果到选型决策：怎么把数据变成行动5.1 加权评分模型：让决策有据可依评测做完之后，手里会有一堆数据。怎么把这些数据变成选型决策？我的做法是建一个加权评分模型。具体来说，把前面说的五个维度（基础能力、工程化能力、生态工具链、成本结构、合规安全）作为一级指标，每个一级指标下再设若干二级指标，然后根据你的场景给每个指标分配权重，最后加权求和得出综合分。权重的分配是主观的，但要有依据。我的方法是让所有利益相关方（产品、技术、运维、合规）一起讨论，各自给出权重建议，然后取加权平均。这样得出的权重虽然不是绝对客观，但至少代表了团队的共识，后续决策时不会有人跳出来说"你当时没考虑我的需求"。下面是一个加权评分表的模板，你可以直接拿去用：一级指标二级指标权重厂商A得分厂商B得分厂商C得分基础能力知识准确性10%897基础能力推理深度8%796基础能力指令遵循度7%688基础能力输出稳定性10%597工程化响应延迟8%789工程化并发承载7%678工程化长文本处理5%586生态文档质量4%796生态SDK成熟度4%687成本有效单价10%869合规数据政策10%788合规安全机制7%697合计100%6.68.17.4这个表里的得分是1到10分的评分，权重加起来是100%。最后算出来的综合分，厂商B最高。但注意，这个结果高度依赖权重分配。如果你的场景对成本极度敏感，把成本权重提到20%，结果可能就变了。所以这个表的价值不在于给出一个"正确答案"，而在于让决策过程透明化——每个人都能看到为什么选了这个而不是那个。5.2 场景化选型：没有万能模型，只有合适模型加权评分模型给出的是一个综合分，但实际选型时往往不是选综合分最高的，而是选最适合你场景的。我一般会做"场景化选型"：针对不同的业务场景，分别选出最合适的模型。比如，对于实时客服场景，响应延迟和输出稳定性的权重最高，基础能力的权重可以适当降低，因为客服场景的问题通常不复杂。对于内容创作场景，创意性和知识准确性的权重最高，延迟和成本可以放宽。对于数据分析场景，推理深度和长文本处理能力最关键，其他都可以妥协。这意味着，一个团队可能同时使用多家厂商的模型——客服用A家，创作B家，分析用C家。这听起来麻烦，但实际上是更理性的选择。我的建议是，不要追求"一家通吃"，而是根据场景组合使用。当然，组合使用会增加工程复杂度，所以要在收益和复杂度之间做权衡。一般来说，如果场景差异很大，组合使用的收益是值得的。5.3 持续监控：选型不是一次性决策最后要强调的是，选型不是一次性决策，而是一个持续的过程。厂商的模型在迭代，你的业务需求也在变化，今天的最优解明天可能就不是了。所以选型之后要建立持续监控机制。我一般会监控三类指标。第一类是质量指标，包括准确率、稳定性、用户满意度等，按月统计，看是否有下降趋势。第二类是性能指标，包括延迟、可用性、错误率等，实时监控，设置告警阈值。第三类是成本指标，包括实际支出、有效单价、重试率等，按周统计，看是否有异常增长。监控数据要定期回顾，我一般每季度做一次全面的选型回顾，看看是否需要调整。如果某家厂商的质量持续下降，或者成本持续上升，就要考虑迁移。迁移是有成本的，所以不能频繁迁，但也不能因为怕麻烦就一直忍着。我的经验是，当某家厂商的综合评分连续两个季度低于替代方案15%以上时，就值得启动迁移评估了。6. 我在搭建这套评估体系时踩过的坑6.1 评测集泄露：当模型"见过"你的题目第一个坑是评测集泄露。我早期做评测时，把评测集放在了一个公开的代码仓库里。结果过了几个月，发现某家模型在我评测集上的得分突然大幅提升，一开始还挺高兴，以为模型进步了。后来仔细一查，发现那家模型的新版本训练数据里可能包含了我的评测集——因为我的评测集是公开的，被爬虫抓走了。这个坑的教训是：评测集一定要保密。我现在会把评测集放在私有仓库里，访问权限严格控制。而且评测集里的题目要定期更换，不能一套题用一年。另外，评测时要注意"数据污染"的问题——如果一道题的答案在训练数据里出现过，那模型答对不代表它真的会。我的应对方法是自建时效性强的题目，用最近发生的事件来提问，这样能有效规避污染。6.2 评分标准漂移：为什么两次评测结果不可比第二个坑是评分标准漂移。我第一次做评测时，评分标准是边测边定的，测到一半觉得某个标准不合理就改了。结果测完之后发现，前半部分和后半部分的评分标准不一致，整个结果没法用。后来我定了一个规矩：评分标准必须在评测开始前完全确定，评测过程中不能改。如果确实发现标准有问题，就暂停评测，改完标准后重新开始，不能中途改。这个规矩听起来简单，但执行起来需要自律。因为评测过程中总会遇到一些"意外情况"，让你想临时调整标准。我的建议是，把这些意外情况记录下来，作为下一轮评测的改进点，而不是当场改标准。6.3 过度依赖自动评分：那些被误判的答案第三个坑是过度依赖自动评分。我早期为了省事，全部用自动评分，结果发现有些答案被误判了。比如一道题要求"用一句话总结"，模型用两句话总结了，内容完全正确，但自动评分因为字数超了判了0分。还有一道开放题，模型的回答很有创意，但和参考答案的措辞差异很大，自动评分给了低分，人工一看其实是好答案。这个坑的教训是：自动评分只能作为初筛，不能作为最终结论。我现在会做"自动评分+人工抽检"的双重校验。自动评分先跑一遍，然后人工抽检10%到20%的样本，重点看那些自动评分给出极端分数（特别高或特别低）的样本。如果发现误判率超过10%，就调整自动评分规则，直到误判率降到可接受范围。6.4 忽视工程化测试：Demo很美好，上线就崩溃第四个坑是忽视工程化测试。我早期做选型时，只测了模型的基础能力，觉得各家都差不多，就选了一家文档写得最漂亮的。结果上线后发现，那家的API在高并发下极不稳定，延迟波动巨大，还经常返回莫名其妙的错误码。后来才知道，那家厂商的推理集群是共享的，高峰期资源争抢严重。这个坑的教训是：工程化测试和基础能力测试同等重要，甚至更重要。基础能力不行，最多是效果差一点；工程化不行，那是直接不能用。我现在做选型时，工程化测试的权重至少占40%，而且一定要在接近真实生产环境的条件下做压测。压测时要模拟真实的并发量、输入长度分布、以及各种边界情况。7. 一套可以直接抄的评测执行清单说了这么多方法论，最后给一份可以直接执行的清单。这份清单是我经过多个项目迭代后沉淀下来的，你可以根据自己的情况调整。准备阶段：明确评测目标：是选型、验收还是持续监控？目标不同，评测集和评分标准的设计也不同。确定评测维度与权重：召集利益相关方讨论，形成书面共识。设计评测集：按"通用能力+场景题+压力题"三层结构设计，总量控制在200到500题。确定评分标准：客观题用规则匹配，主观题用模型评分+人工抽检，评分标准提前定好不改。准备测试环境：确保网络稳定、API配额充足、日志记录完整。执行阶段：先跑小样本（20到30题）验证流程，确认调用、评分、存储各环节正常。跑全量评测集，每个模型至少跑一遍，关键模型跑三遍取平均。同步做工程化压测：测延迟、并发、长文本、流式输出、错误处理。记录所有原始数据，包括输入、输出、耗时、Token用量、错误信息。分析阶段：计算各维度得分，填入加权评分表。做稳定性分析：同一题目的多次回答一致性如何。做长文本针尖测试：实际可靠处理长度是多少。做成本核算：算有效单价，不只看API单价。人工抽检评分结果，校准自动评分的准确性。决策阶段：根据加权评分和场景化需求，选出首选和备选方案。制定迁移和回滚预案。建立持续监控机制，设定质量、性能、成本的告警阈值。约定每季度做一次选型回顾。这份清单看起来长，但真正执行起来，一个完整的评测周期大概需要两到三周。相比选错模型后付出的代价，这两三周的投入是非常值得的。我在实际项目中的体会是，评测做得越扎实，后续的运维就越省心。那些在评测阶段偷的懒，都会在上线后以各种意想不到的方式还回来。