最近团队要做一个内部知识库问答功能第一轮选型时大家几乎默认去看各种国产大模型排名。我花了两天把榜单前几位都试了一遍结果很有趣排名靠前的模型在通用聊天上确实流畅但放到我们自己的文档问答场景里有的答非所问有的格式混乱还有一个开源模型反而在任务型回复上更稳。这件事让我重新想明白了一个道理——评价国产主流AI大模型真正的问题不是“谁更强”而是“在你自己的任务、部署和成本条件下谁更值得长期用”。与其反复刷新排名不如建立一套属于自己的评测工作流。这篇文章就把我目前在用的评价方法写出来包括四个评价维度、一次可复现的评测流程、五个容易踩的坑以及结果不如预期时的排查路径。它不会直接告诉你“选A还是选B”但能让你在下一次选型时不再只凭感觉。1. 先承认一个事实榜单之外的差距往往藏在细节里1.1 榜单测试题和你业务里的真实输入不是同一回事很多榜单评测用的是公开测试集里面的题目再难也是被清洗过的。而真实业务输入是另一种形态用户可能打错字可能一句话里夹杂多个意图可能上传的文档有大量重复章节也可能问一个需要从三段材料里交叉印证的问题。一旦遇到这种输入模型之间的真实差距就会被放大。A模型可能擅长总结但不会按指定格式输出B模型格式稳定但在需要多步推理时容易漏步骤C模型回答质量不错但每次请求要多出几十毫秒并发一高就开始超时。这些问题在榜单分数上是看不出来的。所以我在评测任何国产大模型时第一件事不是去看它的综合分而是先把自己业务里最常出现的 30 到 50 条真实输入整理出来作为第一版评测集。这一步看起来笨但它决定了后面的选型有没有参考价值。1.2 模型能力不是一条直线而是一张能力分布图同一个模型在不同任务上的表现往往差异很大。有的在中文创作和文案改写上很突出有的在代码生成和逻辑推理上更稳定有的在工具调用和 Agent 场景里设计得更好还有的因为开源协议和社区生态更适合私有化部署和二次开发。所以评价时不要问“这个模型好不好”要问“这个模型在我要做的任务上表现稳不稳定”。把任务拆开比把模型排名放一起更有用。目前常见的国产大模型候选池可以列出一个大致范围百度文心系列、阿里通义千问系列、字节豆包系列、智谱 GLM 系列、DeepSeek 系列、腾讯混元、讯飞星火、MiniMax、零一万物等。这里不讨论谁排在前面而是把它们当成一个待验证的集合。每个模型的能力边界、上下文长度、接口兼容性、开源与闭源策略都不同这些信息会直接影响选型判断。1.3 榜单更新周期和你的项目周期不一定同步榜单通常是在某个时间点、用固定版本跑出来的。但模型在迭代API 背后的模型版本也可能在悄悄升级而你的项目可能要运行半年甚至更久。这意味着你今天看到的评测结果只能代表“某个版本的模型在某个任务集上的表现”。放到项目里之后可能两个月后接口返回质量就变了也可能是变得更好了但你需要知道这个变化。所以我在做模型评测时会强制记录三样东西模型版本、评测日期、评测集版本。没有这三样记录的评测结果后面很难复盘。这不是形式主义而是为了让“评价”这个行为本身可追溯。2. 我建议用四个维度搭一套评价坐标系而不是只比分数2.1 任务维度从“聊天好不好”换成“我的任务能不能完成”评价任何模型之前先把任务类型写清楚。常见的大模型任务大概可以分成几类开放对话与内容生成摘要、改写、翻译分类、抽取、信息整理代码生成与代码解释工具调用与 Agent 规划知识库问答与检索增强生成结构化数据提取与格式化输出每种任务的要求不一样。有的任务更看重语义理解有的更看重格式稳定性有的更看重多步推理有的更看重对长文本的利用能力。不要拿一个“客服问答”的需求去用“通用写作”的评测维度打分。我一般会把任务分成主场景和次场景主场景只选 1 到 2 个次场景控制在 3 个以内。评测样本也按这个比例分配避免把大量样本花在次要任务上。2.2 部署维度API、私有化、本地部署前置条件完全不同国产大模型的使用方式目前大致可以分成三类。第一类是 API 在线调用。优点是接入快、不需要自己准备显卡适合快速验证和短期项目。缺点是要考虑数据出域、调用限流、网络延迟以及按 Token 计费带来的成本波动。第二类是私有化部署或本地部署。数据留在自己环境里可控性强适合内部知识库、敏感数据、高合规要求的场景。但需要准备 GPU 资源要考虑显存、并发、模型版本管理、服务监控和日志部署门槛明显高于 API。第三类是混合方式。把核心敏感任务放在本地模型上把长尾或高难度任务转发到云端 API。这种模式目前在不少团队里是常态但需要额外处理路由逻辑、成本统计和失败降级。部署工具方面如果只是单机快速尝试Ollama 这类工具比较方便如果需要提供稳定的推理服务vLLM 这类方案会更适合。两者不是二选一而是不同阶段的工具。一开始可以先用 Ollama 跑通流程确认模型效果等要上生产了再考虑用 vLLM 做并发和性能优化。2.3 成本维度按 Token 计价之外还要算开发、运维和迭代成本成本是评价国产大模型时最容易算错的部分。只看 API 单价是不够的。还要算单次请求的实际消耗通常包括输入 Token、输出 Token、失败重试带来的额外请求成本以及可能需要做的后处理逻辑。比如一个模型回答内容不错但经常把格式写错那你的程序就需要花额外代码去修复格式这就是隐形成本。如果选择本地部署成本结构会更复杂GPU 硬件的一次性投入、机器功耗、机房或云主机费用、运维同学的时间成本、模型升级时的重新验证成本。很多人以为本地部署更省钱但实际把运维时间和硬件折旧算进去小规模场景不一定比 API 便宜。我一般会用“单条有效请求的综合成本”来做横向比较。计算方法也很简单总成本除以真正可用的成功响应数。这样可以把重试、后处理、人工修正这些因素都折算进去。2.4 生态维度工具链、框架、微调能力决定了长期维护是否顺畅一个模型单点能力再强如果接入生态不好后期维护也会很痛苦。我会关注几个问题模型是否提供 OpenAI 兼容接口这决定了现有的很多工具能不能直接接上是否有官方或社区维护的 SDK是否容易集成进 Spring AI、LangChain 这类框架是否支持微调微调的成本和文档是否清楚是否有配套的评测工具、知识库方案和 Agent 能力而不是只给一个聊天接口。这些看起来很工程化的问题恰恰是决定一个模型能不能从“Demo”走进“生产”的关键。评价维度需要确认的问题验证方法常见注意点任务维度模型在主场景上是否稳定满足要求用 30 条真实输入逐条跑不要用通用题库替代业务样本部署维度数据能否出域、硬件是否够、服务能否稳定API 测试 本地推理验证显存够启动不等于能扛住并发成本维度单条有效请求的综合成本是多少统计 Token、耗时、重试率别忽略失败重试和人工修正生态维度接口兼容性、框架集成、微调是否方便查看文档 跑通一个最小集成接口标准比功能数量更重要3. 一次可复现的评测实战从接口调用到本地部署再到小批量压测3.1 先做评测集而不是先找模型评测集不需要很大但要覆盖真实输入的各种情况。我一般会包括正常输入业务里最常见的提问或待处理文本异常输入空内容、超短输入、错别字、口语化表达边界输入超长文本、多轮对话、多个问题叠加、明显超出模型能力的问题格式要求需要输出 JSON、Markdown、表格、固定模板等给每条样本写下“期望结果”哪个字段必须出现、哪些内容不能出现、输出格式是什么。这个标准越具体后面对比模型时越容易判断。3.2 先串行跑 API确认效果不急着并发API 评测阶段我先用 Python 写一个最简单的脚本读取评测集逐条请求记录每次请求的输出、耗时和 Token 消耗。暂不考虑并发因为第一步是为了看效果不是为了压性能。import json import time import requests # 示例结构实际使用时替换为对应模型的接口地址和密钥 API_URL https://your-model-endpoint/v1/chat/completions API_KEY your-api-key def evaluate_one(sample): headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } payload { model: model-name, messages: [ {role: user, content: sample[input]} ], temperature: 0.2, max_tokens: 1024 } start time.time() try: resp requests.post(API_URL, jsonpayload, headersheaders, timeout60) latency time.time() - start data resp.json() return { input_id: sample[id], output: data[choices][0][message][content], latency: latency, status: resp.status_code, error: None } except Exception as e: return { input_id: sample[id], output: None, latency: time.time() - start, status: -1, error: str(e) } with open(eval_set.json, r, encodingutf-8) as f: eval_set json.load(f) results [evaluate_one(sample) for sample in eval_set] with open(api_results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2)这段代码不复杂但已经能拿到三个关键数据可用性、耗时、输出内容。后面再写脚本去统计格式符合率和正确率。3.3 本地部署先确认参数再谈效果如果候选池里有开源模型并且你有私有化需求就需要在本地跑一轮。以 Ollama 为例常见流程是先在官网下载对应平台版本然后拉取模型。拉取哪个模型、要不要做量化取决于你的显卡显存和任务要求。# 示例命令具体模型名和版本以实际可用的为准 ollama pull qwen2.5:7b ollama run qwen2.5:7b如果评测目标是高并发推理服务可以用 vLLM 启动一个 OpenAI 兼容的服务# 示例结构实际参数需要按部署环境调整 python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --port 8000 \ --gpu-memory-utilization 0.85 \ --max-model-len 8192这里要特别提醒本地部署启动成功只是第一步更关键的是显存余量、推理延迟和并发能力。同一个模型7B 和 70B 对硬件的要求完全不同同样 7B 模型全精度和 4-bit 量化也会有速度和效果差异。3.4 小批量压测从 10 条并发开始观察 P95 延迟和错误率效果测试通过之后再做一轮小批量压测。压测不是为了把服务打崩而是要看在业务预期并发下模型的 P95 延迟、错误率是否可接受。可以从 10 条并发开始确认服务稳定后再逐步提到 20、50 条。观察几个指标平均延迟和 P95 延迟超时请求占比返回格式错误率显存是否持续增长是否出现 OOM失败后重试是否会放大压力压测结果如果很差先不要急着归因于模型能力先确认是不是部署参数、并发策略或后端资源的问题。3.5 判定标准不是单一准确率而是一组指标模型评测不能只有一个准确率。我通常用这套指标来比较指标说明通过标准可用率请求成功且没有抛出异常大于 99%格式符合率输出能按预期解析如 JSON 或表格大于 95%内容正确率人工抽样判断结果是否正确按场景设定通常 80% 以上再考虑试用长尾稳定性连续多次请求没有偶发超时或乱码连续跑 100 条无明显异常单条综合成本包括 Token、重试、后处理、人工修正和预算目标对比注意内容正确率需要人工抽样确认不要只看模型打分。模型给自己打分往往比真人宽松得多。4. 评价国产大模型最容易踩的五个坑4.1 用完美提示词测试忽略了真实输入里的噪声很多评测把提示词写得很精炼、很完整但真实用户不会这么说话。真实输入可能包含错别字、无意义的口头语、截断的语句、多种语言混排。如果评测集里都是“完美输入”你会高估模型在实际场景里的可用性。建议在评测集里加入至少 10% 到 20% 的脏数据模拟真实情况。4.2 拿一个超长上下文需求去压所有模型上下文窗口是这两年国产大模型竞争的焦点之一但“支持 128K”和“在 128K 下依然稳定”是两回事。模型能接收长文本不代表它能有效利用长文本的每个部分。很多模型在输入超过一定长度后对中间部分内容的注意力会明显下降这不是个别现象。测试长文本能力时不要只测“能不能不报错”要看关键信息在长文本的不同位置时模型是否都能准确抽取。我一般会准备三份测试关键信息在开头、关键信息在中间、关键信息在结尾。4.3 本地部署只看启动成功没看并发和延迟本地部署的最初成功很容易让人产生错觉模型启动了回答也没问题就以为可以上线。实际上显存足够启动模型和显存足够支撑并发是两回事。推理时 KV Cache 会随着并发请求数和序列长度动态增长如果设置不当并发一起来就可能 OOM 或延迟飙升。所以本地部署评测一定要有“并发长文本连续请求”的组合测试而不是只跑几条数据看效果。4.4 忽略模型版本和接口版本的变更模型厂商会迭代模型API 参数也可能调整开源模型的版本也很多。今天评测时用的是model-0715可能过一个月默认版本就换了。如果评测记录里没有版本信息后面遇到输出变化时很难判断是业务问题还是模型变化。我通常在脚本里把模型版本、接口地址、评测集版本一起写进结果文件。这样下次复评才能知道差异到底来自哪里。4.5 只看单次成功不看重试和失败对线上业务来说最麻烦往往不是单次回答不够好而是偶发失败、超时、返回了一个无法解析的结构。评测时一定要统计失败分布哪些输入会导致超时哪些输入会让模型输出不完整哪些输入会触发安全过滤导致空回复。这些数据比单次质量更能影响用户体感。建议评测结果里单独增加一个“失败样本”目录把每次失败对应的输入、输出和错误信息都留档。换模型或者调参数时这些样本就是最好的回归测试。5. 当结果不如预期时先别急着换模型5.1 先走一遍完整排查链路评测结果不理想先不要立刻下结论“这个模型不行”。我会按下面这个顺序排查看输入原始文本是否被截断、编码是否正确、评测集本身是否有问题。看提示词系统提示是否清楚、有没有给出示例、格式约束是否明确。看参数temperature 是否过高、max_tokens 是否太短、是否误开了流式输出导致解析不完整。看后端API 是否限流、本地服务显存是否不足、是否有并发抢占。看模型边界这个任务本身是不是当前模型擅长的事比如让一个小参数模型做复杂的数学推理效果差是大概率事件。大部分“效果不稳”的问题都出在前四层而不是模型本身。5.2 哪些问题不需要换模型以下问题通常可以通过工程手段解决输出格式不稳定在提示词里给一个完整示例或者增加一个后处理解析步骤。事实性错误接入知识库用检索增强生成替换纯生成。偶尔超时调整并发策略增加重试和降级逻辑。多轮对话记忆丢失改成显式拼接历史消息而不是完全依赖模型自身记忆。如果这些手段还没用再考虑换模型。5.3 哪些问题必须换模型如果遇到下面这些情况就需要认真考虑更换候选模型在多个提示词和参数组合下推理结果依然系统性出错。工具调用或 Agent 规划能力不足无法完成多步任务。多轮对话超过几轮后上下文信息明显丢失。本地部署时模型能力达不到业务要求API 版本又因为数据合规不能用。5.4 模型切换成本比你想象的高先固化评测资产换模型不只是改一个接口地址提示词要重新适配后处理逻辑可能要改微调数据要迁移评测集要重新跑一遍。所以在确定要切换之前先把评测集、脚本、结果记录都固化下来。这样至少能回答一个问题“新模型在你的评测集上真的比旧模型好吗”6. 从一次选型走向一套长期评测资产6.1 把评测集和脚本放进版本管理评测集本身就是最有价值的项目资产。每次业务发生变化都可以往里面增加新样本每次模型发布新版本都可以跑一遍做回归。我更建议把评测集、评测脚本和结果记录放在同一个仓库里统一管理版本。这样后续任何人接手都能知道当前模型在什么条件下被验证过。6.2 给每个候选模型建立一张“模型卡”我会给每个模型维护一份简短记录包含以下内容模型名称与版本评测日期和评测集版本主场景表现、次场景表现部署方式与硬件条件单条综合成本估算已知问题和触发条件适合的情况和不适合的情况有了模型卡选型时就不用重新跑一遍所有测试直接拿历史记录做横向对比。6.3 定期复评模型、业务和成本都会变化模型版本会更新业务数据会变化API 价格也会调整。建议每隔一到两个季度把现有模型在核心评测集上重新跑一遍。这样做的价值不是追求“最新的就是最好的”而是确保你正在使用的模型在你当前的业务条件下仍然合适。6.4 说到底评价国产大模型的关键不是模型而是你的评测工作流国产主流 AI 大模型的选择空间已经足够大闭源 API 和开源权重都在快速迭代。今天这个模型可能在某项任务上领先明天另一个模型可能因为生态优势后来居上。更重要的是你的业务不会等模型完全成熟后再启动。你需要的不是“全网最好的模型”而是在你的任务、你的数据、你的成本和你的运维条件下能够稳定交付结果的那个模型。要找到它最可靠的方式不是依赖某个榜单而是把评测这件事变成一套可复用的工作流。先跑通最小评测集再验证部署条件再压测并发和成本最后固化成模型卡。这套流程跑完哪怕换一个模型、换一个项目你也不会慌。