企业官网建设流程全解析

1. 为什么我要做这份私有题库测评排行榜

过去大半年，我一直在折腾一件事：把手头几个不同来源的大模型，放到同一套私有题库里跑一遍，看看它们在真实业务场景下到底谁更能打。市面上的公开榜单不少，但真正拿自己的数据去测的人不多，原因很简单——费时、费钱、还容易测出让自己不开心的结果。可我还是坚持做了，因为公开榜单的题目往往偏通用、偏学术，跟实际落地时遇到的刁钻问题完全不是一回事。

这份排行榜覆盖的时间窗口是2026年10月这一轮测评，参与测评的模型包括几个主流闭源大模型和几个可本地部署的开源模型。私有题库是我和几个同行一起攒的，题目来源主要是三类：一是日常业务里真实踩过的坑，二是从用户反馈里提炼的边界案例，三是针对特定能力维度专门设计的压力测试题。整套题库大概四百多道题，分成了知识问答、逻辑推理、代码生成、长文本理解、指令遵循、多轮对话一致性六个大类。

做这件事的初衷很朴素：我不想再被"某某模型跑分第一"这种标题牵着走。跑分高不代表在你的场景里好用，参数多不代表推理稳。只有拿自己的题、自己的评分标准去测，才能得到对自己有意义的结论。这份汇总适合两类人看：一类是正在选型、不知道该用哪个模型的开发者；另一类是已经用上了某个模型、但总觉得效果不稳定、想看看是不是模型本身短板的从业者。下面我会把整个测评的设计思路、评分细节、实操过程、踩过的坑全部摊开讲，你可以直接照着复现一套属于自己的私有题库测评。

2. 私有题库测评的整体设计与思路拆解

2.1 为什么不直接用公开榜单

公开榜单最大的问题是"题目污染"和"目标错位"。题目污染指的是，很多公开题目在训练阶段就可能被模型见过，跑出来的分数虚高，实际用起来完全不是那个水平。目标错位指的是，公开榜单追求的是平均能力，而实际业务往往只关心某几个特定维度。比如你做的是合同审核，那你关心的就是长文本理解和指令遵循，代码能力再强跟你没关系。

我试过拿某公开榜单的前几名模型，直接放到我的业务场景里跑，结果发现排名第三的那个模型在长文本指令遵循上反而比第一名稳。原因很简单，第一名的优势集中在数学和代码，而我的题目里这两类占比很低。所以私有题库的核心价值不是"更权威"，而是"更贴合你自己的需求"。

2.2 题库的六个维度是怎么划分的

维度划分不是拍脑袋定的，而是根据实际调用场景反推出来的。我把日常调用大模型的任务做了个统计，发现大致可以归到六类里，每一类对应一种核心能力：

这个划分的好处是，测完之后你能得到一张能力雷达图，而不是一个笼统的总分。选型的时候直接看雷达图上你最关心的那个维度就行，不用被总分误导。

2.3 评分标准的设计逻辑

评分这块我改了三版才定下来。第一版用的是纯人工打分，太累，四百道题打完人都麻了。第二版改成纯自动评分，结果发现代码题和逻辑题用字符串匹配根本测不准，模型换个写法就判错了。第三版是混合方案：客观题用规则匹配加关键词覆盖，主观题用另一个更强的模型做裁判，再抽10%人工复核。

具体来说，每道题的满分是10分，评分拆成三个子项：正确性占6分，完整性占2分，格式合规占2分。正确性看答案对不对，完整性看有没有漏掉关键点，格式合规看有没有按照要求的格式输出。这个拆分很重要，因为实际业务里格式不对的答案基本等于废答案，哪怕内容是对的。

提示：裁判模型的选择很关键。我用的是当时综合能力最强的一个模型做裁判，并且固定了裁判的提示词模板，保证每道题评分标准一致。裁判模型本身也会犯错，所以10%的人工复核不能省。

2.4 测评环境的统一

环境不统一，测出来的结果没有可比性。我把所有模型的调用参数做了强制统一：温度设为0.2，最大输出长度设为2048，top_p设为0.9，关闭所有流式输出。温度设低是为了减少随机性，让结果可复现；输出长度限制是为了防止某些模型靠"话多"蒙分。

调用方式上，闭源模型走官方接口，开源模型统一部署在同一台机器上，显卡配置一致，量化方式统一用同一档。这里有个坑：不同开源模型的默认量化精度不一样，有的默认fp16，有的默认int8，如果不统一，测出来的差异可能来自量化而不是模型本身。我全部强制用同一档量化重新部署了一遍，虽然费时间，但结果才可信。

3. 核心细节解析与实操要点

3.1 题目设计的三个原则

题目设计直接决定测评的有效性。我总结了三个原则，踩过坑之后觉得每一条都不能省。

第一个原则是"一题一考点"。一道题只测一个能力点，不要既考逻辑又考格式。早期我出过一道题，要求模型先做数学推导再按JSON格式输出，结果模型推导对了但格式错了，这道题到底算它对还是错？后来我把这类题拆成两道，一道纯推导，一道纯格式，评分就清晰了。

第二个原则是"答案可验证"。每道题都要有明确的参考答案或者可判定的标准。主观题也要有评分要点，不能凭感觉打分。我见过有人出"写一篇关于XX的文章"这种题，这种题根本没法客观评分，测出来的结果全是噪声。

第三个原则是"难度分层"。题库里要有简单题、中等题、难题，比例大概是3:5:2。全是难题会导致所有模型得分都很低，区分度反而差；全是简单题又测不出差距。分层之后，简单题看基础能力，难题看上限，中等题看稳定性。

3.2 防止题目泄露的处理

私有题库最怕的就是题目泄露到训练数据里。虽然我的题库规模不大，泄露概率低，但还是做了几层防护。一是题目文本做了轻微改写，把一些标志性表述换掉；二是每道题都记录了创建时间，如果某个模型在某个时间点之后突然在这道题上表现异常好，就要警惕；三是定期轮换题目，每季度替换掉20%的老题。

这里有个实操心得：题目轮换不要一次性全换，否则前后两轮没法对比。我一般是保留80%的老题，换20%的新题，这样既能防止泄露，又能保持纵向可比性。

3.3 调用参数的统一与记录

参数统一只是第一步，记录同样重要。我建了一张调用记录表，每次测评都记录：模型名称、版本号、调用时间、温度、最大长度、top_p、是否流式、接口版本。这些信息看起来琐碎，但当你发现两次测评结果差异很大时，这些记录就是排查问题的唯一线索。

有一次我发现某个模型这轮得分比上轮低了5分，查了半天以为是模型退化了，最后翻记录才发现是接口版本更新了，默认参数变了。如果没有记录，这个坑能让我怀疑人生。

3.4 评分裁判的提示词模板

裁判模型的提示词模板我固定成了下面这个样子，你可以直接参考：

你是一个严格的评分员。请根据以下标准对模型的回答进行评分。 题目：{question} 参考答案要点：{reference_points} 模型回答：{model_answer} 评分标准： 1. 正确性（0-6分）：答案是否正确，关键结论是否准确。 2. 完整性（0-2分）：是否覆盖了所有参考答案要点。 3. 格式合规（0-2分）：是否按照题目要求的格式输出。 请只输出一个JSON，格式为： {"correctness": 分数, "completeness": 分数, "format": 分数, "reason": "简短理由"}

这个模板的关键是"只输出JSON"，避免裁判模型啰嗦一堆分析影响解析。另外reason字段限制在简短理由，太长会拖慢评分速度。

4. 实操过程与核心环节实现

4.1 测评流程的完整步骤

整个测评流程我跑了很多轮，现在固化成了下面这几步，每一步都有明确的产出物。

第一步是题库准备。把四百多道题整理成统一的JSON格式，每道题包含题目ID、维度分类、题目文本、参考答案要点、格式要求五个字段。这一步看起来简单，但格式统一能省掉后面大量的解析麻烦。

第二步是批量调用。写一个脚本，遍历题库，对每个模型依次调用，把原始回答存下来。这里要注意加限流和重试机制，接口偶尔会超时，不加重试会丢数据。我一般设置每次调用间隔200毫秒，失败重试3次。

第三步是自动评分。把原始回答和参考答案一起喂给裁判模型，拿到评分JSON。这一步最耗时，四百道题乘以模型数量，跑一轮要大半天。

第四步是人工复核。随机抽10%的评分结果，人工核对裁判模型打得对不对。如果发现某个维度的评分偏差大，就要调整裁判提示词重新评。

第五步是汇总分析。把评分结果按维度聚合，算出每个模型在每个维度上的平均分，再画成雷达图。

4.2 批量调用脚本的核心逻辑

调用脚本我用的是Python，核心逻辑不复杂，但有几个细节要注意。下面是一个简化版的示例：

import json import time import requests def call_model(model_name, question, config): payload = { "model": model_name, "messages": [{"role": "user", "content": question}], "temperature": config["temperature"], "max_tokens": config["max_tokens"], "top_p": config["top_p"], "stream": False } for attempt in range(3): try: resp = requests.post(config["endpoint"], json=payload, timeout=60) return resp.json()["choices"][0]["message"]["content"] except Exception as e: if attempt == 2: return f"ERROR: {str(e)}" time.sleep(2) def run_batch(models, questions, config): results = [] for model in models: for q in questions: answer = call_model(model, q["text"], config) results.append({ "model": model, "question_id": q["id"], "dimension": q["dimension"], "answer": answer }) time.sleep(0.2) return results

这段代码的关键点是重试机制和调用间隔。重试是为了应对接口抖动，间隔是为了避免触发限流。实测下来，不加间隔的话，调用量一大就会被限流，反而更慢。

4.3 评分结果的聚合计算

评分聚合不是简单求平均，因为不同维度的题目难度不一样，直接平均会让难题多的维度显得分数低。我的做法是先对每个维度内的题目做难度加权，难题权重高，简单题权重低。权重设置是简单题1.0，中等题1.5，难题2.0。

加权平均的公式是：维度得分 = Σ(题目得分 × 难度权重) / Σ(难度权重)。这样算出来的分数更能反映模型在该维度上的真实水平，而不是被题目难度分布带偏。

4.4 2026年10月这一轮的测评结果

这一轮测评我一共跑了六个模型，其中三个闭源、三个开源。为了不涉及具体品牌，我用模型A到模型F来代称。下面是各维度加权后的得分汇总：

从这张表能看出几个有意思的现象。模型A在代码生成上领先明显，但长文本理解偏弱；模型B比较均衡，多轮一致性最好；模型C知识问答最强，但逻辑推理是短板；模型D和模型F整体偏弱，但在某些单项上还有亮点。

如果你做的是代码辅助工具，模型A是首选；如果你做的是长文档处理，模型B或模型E更合适；如果你做的是知识库问答，模型C值得考虑。这就是私有题库的价值——它不给你一个笼统的排名，而是给你一张按需选择的地图。

5. 常见问题与排查技巧实录

5.1 测评结果波动大的排查思路

结果波动是测评里最常见的问题。同一道题，同一个模型，两次跑出来的答案可能完全不一样。遇到这种情况，我一般按下面的顺序排查：

先看温度参数。温度高于0.5的话，波动是正常的，把温度降到0.2以下再测。如果温度已经很低还是波动大，就看是不是接口版本变了。有些接口会不定期更新，默认参数可能悄悄改了。再不行就看是不是题目本身有歧义，模型每次理解的角度不一样。最后才怀疑模型本身的不确定性。

我整理了一张排查速查表，遇到波动直接对着查：

5.2 裁判模型评分偏差的处理

裁判模型不是万能的，它也会偏。我遇到过裁判模型对长答案给分偏高的情况，因为长答案看起来"更完整"，但实际上可能废话多、关键点少。解决办法是在裁判提示词里明确要求"按要点覆盖评分，不按长度评分"，并且定期人工复核。

还有一个坑是裁判模型对格式的判定太严。比如题目要求输出JSON，模型输出的是JSON但字段顺序不一样，裁判可能判格式不合规。这种要在提示词里说明"字段顺序不影响格式合规性"。

5.3 开源模型部署的常见坑

开源模型部署这块坑最多。第一个坑是量化精度不统一，前面提过了，必须强制统一。第二个坑是显存不够导致的部分层卸载到CPU，速度慢不说，结果还可能受影响。部署前一定要确认显存够用，不够就换小一点的模型或者降低量化精度。

第三个坑是不同推理框架的输出格式不一样。有的框架默认带系统提示词，有的不带；有的默认加了特殊token，有的没加。这些差异会直接影响测评结果。我的做法是统一用一个推理框架，所有模型都在同一个框架下部署，把框架层面的差异降到最低。

5.4 题库维护的长期建议

私有题库不是建一次就完事了，它需要长期维护。我的建议是每季度做一次小更新，每年做一次大更新。小更新替换20%的题目，大更新重新审视维度划分和评分标准。

另外，题库要版本化管理。每次更新都打一个版本号，测评结果要标注用的是哪个版本的题库。否则过几个月你回头看结果，根本不知道当时测的是什么题，数据就没法对比了。

注意：题库更新后，老模型的分数不能直接和新模型的分数比，因为题目变了。要么用同一版本题库重测所有模型，要么只做同版本内的横向对比。

6. 我在这轮测评里踩过的几个真实坑

第一个坑是低估了评分环节的工作量。我一开始以为自动评分跑一遍就完事了，结果发现裁判模型的输出格式不稳定，有时候输出JSON，有时候输出一段文字里夹着JSON，解析脚本改了好几版才稳定。后来我在提示词里加了"只输出JSON，不要任何其他文字"，情况才好起来。

第二个坑是忽略了模型的知识截止时间。有些题目的答案有时效性，比如某个产品的功能在某个时间点之后变了，模型如果知识截止时间早，就会答错。这不是模型能力问题，是时效性问题。后来我在题库里给每道题标注了时效性要求，时效性强的题目单独统计，不混进总分。

第三个坑是调用成本失控。四百道题乘以六个模型，再加上裁判模型的调用，一轮下来调用量不小。我一开始没做预算控制，跑了两轮才发现成本超预期。后来我做了两件事：一是把简单题的比例提高，减少难题的调用量；二是裁判模型只在必要时调用，能用规则匹配的就不调裁判。

第四个坑是人工复核的抽样偏差。我一开始是随机抽10%，后来发现随机抽样可能抽不到问题集中的维度。改成按维度分层抽样，每个维度都抽10%，这样更容易发现维度级别的评分问题。

7. 这套测评方法还能怎么扩展

这套方法目前只覆盖了文本能力，但实际业务里多模态需求越来越多。下一步我打算加入图片理解和表格理解两个维度，题目形式也要相应调整。图片理解可以测模型对图表、截图的解读能力，表格理解可以测模型对结构化数据的处理能力。

另一个扩展方向是加入成本维度。现在排行榜只看能力，不看成本，但实际选型时成本是绕不开的。我打算在下一轮测评里记录每个模型的单次调用成本和响应延迟，做成"能力-成本"二维图，这样选型时能更全面地权衡。

还有一个方向是加入稳定性测评。同一个模型在不同时间、不同负载下的表现是否一致，这个在实际生产环境里很重要。我打算做一组重复调用测试，看模型输出的方差有多大，方差小的模型在生产环境里更可靠。

这套私有题库测评的方法，核心不在于题库有多大、模型有多少，而在于它逼着你去想清楚自己到底需要什么能力。公开榜单告诉你谁最强，私有题库告诉你谁最适合你。这两件事完全不是一回事。我自己做完这几轮测评之后，选型的时候心里踏实多了，因为我知道每个模型的短板在哪里，也知道在什么场景下该用谁。如果你也在纠结选哪个模型，不妨花点时间搭一套自己的私有题库，哪怕只有几十道题，测出来的结论也比看十篇公开榜单有用。