企业官网建设流程全解析

国产AI大模型这一两年的变化，用“一天一个样”来形容并不过分。DeepSeek、通义千问、豆包、文心一言、智谱清言、Kimi、混元这些名字，几乎每隔一段时间就会出现在讨论里，新版本、新能力、新榜单层出不穷。但真正到了自己要用的时候，很多人会陷入一个尴尬：榜单分数高的模型，落到实际任务里不一定顺手；大家口口相传“很好用”的模型，换成自己的数据和格式，可能连输出都整理不清楚。这说明一个问题——我们需要一套自己的评价方法，而不是只盯着公开排名。

这篇文章要解决的，就是“怎么评价国产主流AI大模型”这件事。我会从评价维度、运行环境、单条任务、批量评测、幻觉测试、场景选型、常见误区和排查思路几个方向展开。适合三类人看：正在做模型选型的技术负责人、准备把大模型接入业务的开发者，以及想系统了解大模型能力的初学者。最值得关注的一点是：评价不能只靠打开对话窗口随便问几个问题，要让测试用例可复用、结论可复现，这才叫评价，否则只能叫聊天。

1. 为什么榜单排名不能直接决定选型

1.1 榜单分数和真实任务之间到底差在哪

公开榜单通常由官方或第三方机构设计，用一批固定题目来测模型的能力，比如常识问答、数学计算、代码生成、逻辑推理。这类评测有两个优势：题目标准化，结果可横向比较。但也有一个明显的短板——真实业务不会按榜单题目出牌。

举例来说，一个模型在通用知识题上得分很高，不代表它能把你的 PDF 合同准确解析成结构化字段；一个模型代码能力排在前列，也不代表它会严格遵守你项目里那套私有代码规范。真实任务更看重的是格式约束、上下文理解、指令遵循和对特定领域术语的把握，而这些恰好是固定题库很难覆盖的部分。

所以要有一个认知：榜单排名只能作为初步筛选的参考，用来圈定几个候选模型，不能直接决定最终选型。真正的评价必须围绕你自己的典型任务来设计。

1.2 先按用途给模型分类再评价

国产大模型数量多，但用途可以粗略分成几类，分类之后再评价会清晰很多：

• 通用对话类：适合日常问答、写作辅助、信息整理，主要看中文表达和常识理解。
• 代码类：适合生成、解释、重构代码，主要看代码可运行性和调试能力。
• 长文本类：适合总结论文、分析报告、处理大段资料，主要看上下文窗口和定位能力。
• 多模态类：可以输入图片、文档等，主要看图文理解和跨模态任务完成度。
• 垂直领域类：针对农业、电力、医疗、金融等专业场景优化，主要看专业术语和知识准确性。

先确定你要评价的是哪一类，再设计对应的测试内容。否则很容易出现拿一个通用模型去跑专业任务，发现效果不好，就简单判断“这个模型不行”，实际上只是预期的能力方向不对。

2. 评价前先把三种运行环境定清楚

2.1 网页版、API、本地部署怎么选

同一个模型，在不同接入方式下表现可能完全不一样，评价之前必须先确定运行环境。

网页版（比如各家官网的对话页面）体验门槛最低，注册就能用，适合快速感受模型的基础能力。但网页版通常有内置的提示词、系统设定，甚至可能自动帮你“优化”输入，所以它测出来的结果并不是模型能力的真实底线，而是“产品化之后的表现”。

API 接入更接近真实开发场景。你可以完全控制请求参数，比如温度、最大输出长度、系统提示词，也能做自动化批量测试。如果你要评价模型在业务里的表现，API 是最合适的方式。

本地部署则适合对数据隐私、调用成本、离线环境有要求的场景。本地部署能看到模型最本质的能力，但门槛也最高，需要处理显存、依赖、权重文件、推理框架等一系列问题。

2.2 本地部署的硬件门槛比想象中高

很多热词搜索里都有“本地部署AI大模型”，但实际跑下来，硬件门槛经常被低估。大模型参数量动辄几十亿甚至上百亿，浮点权重加载进内存就需要不少空间，推理时还有额外的计算开销。

以常见的开源模型为例，一个数十亿参数的中等模型，用量化方式部署，显存需求通常也在 8GB 到 16GB 左右；如果想要更高精度或者更大参数，门槛会进一步上升。低配置机器不是说完全不能跑，而是要把量化等级拉开、输入长度缩短、并发数降到最低，体验上会明显受限。

我建议普通用户在评测阶段优先走 API 或者网页版，先把能力和业务匹配度摸清楚。只有当你确认某个模型适合你的场景，并且对数据隐私、成本控制有明确需求时，再考虑本地部署。不要在还没搞清任务需求时就先搭部署环境，那样容易把精力耗在环境问题上，反而忽略了对模型能力的判断。

2.3 新手跑通最小评价流程

如果你刚开始接触大模型评价，不要一上来就设计几十个测试用例。先把最小流程跑通：

1. 选定 2 到 3 个候选模型。
2. 从自己的典型工作里找出 5 个真实任务。
3. 用相同的提示词分别发给这些模型。
4. 把输出保存下来，先不做评分，只看整体观感。

这一步的目的不是打分，而是建立“模型真实输出”的直觉。很多人在这一步就会发现，有些模型看起来参数很强，但回答方式、格式偏好、语气控制根本不适合自己的项目。这种初筛，比看任何榜单都更贴近实际。

3. 从单条任务到批量评测的完整流程

3.1 单条任务要覆盖六个基础能力

逐个跑通单条任务时，我建议至少覆盖六个能力维度，而不是只测“它能不能答对”：

• 指令遵循：你要求“用表格输出”“不超过三句话”“不要解释”，它有没有做到。
• 事实准确性：涉及具体名称、数字、日期、政策时，是否正确或明确表示不知道。
• 逻辑推理：多步推理题能不能给出一致、清晰的思路。
• 长文本处理：给一篇长文，能否按要求定位信息或总结核心。
• 格式处理：要求 JSON、Markdown 表格、代码块时，能否稳定输出合法格式。
• 边界感知：面对不确定、超出知识范围的问题，会不会承认不确定，而不是硬编。

前两个维度最容易出问题，也最容易在后续批量任务里放大。

3.2 批量评测怎么设计输入和输出

单条任务跑通之后，如果只是几个问题，手动复制粘贴也能完成。但要评价一个模型的能力，样本量不足会带来很大的偶然性。这时候就需要批量评测。

批量评测至少要规划四件事：

1. 输入列表：把所有测试问题整理成一个文件，每行一条，带编号。
2. 提示词模板：固定统一模板，只替换任务内容，保证对比公平。
3. 输出保存：每个模型的回答单独保存到一个目录，文件名包含模型名和问题编号。
4. 失败记录：超时、报错、空输出、格式非法，都要单独记录，不能悄悄忽略。

注意：批量评测时不要一上来就开大并发。先用一条请求确认接口、参数、日志都正常，再逐步提高并发，否则很容易把超时和限流误判成模型能力问题。

我自己习惯的做法是先用 10 到 20 个问题做小批量验证，确认流程没问上，再扩展到几百个问题。这样即使中间出问题，排查范围也小。

3.3 评分标准：客观题和主观题分开

批量评测拿到输出后，评分标准要提前定好。客观题和主观题不能混在一起打分。

客观题（如数学答案、代码是否可运行、事实判断）评分标准要明确：答案完全正确得多少分，过程正确但结果错误得多少分，完全不相关得多少分。这类题目最好由人工核对或者用固定脚本判断，不要依赖模型自己打分。

主观题（如写作质量、总结完整度、逻辑流畅度）需要用评分维度拆开，比如内容完整性、结构清晰度、语言准确性、有无多余信息。可以按 1 到 5 分逐项打分，但要注意不同评价人员之间的一致性。如果条件允许，同一份输出让两个人分别打分，再取平均值，比一个人凭感觉给分更可靠。

4. 幻觉测试：让模型学会“自知之明”

4.1 设计一套能触发幻觉的测试用例

“AI幻觉”是最近讨论度很高的词，说到底就是模型一本正经地给出错误信息，而且语气往往比真实答案还自信。评价大模型，幻觉测试是必须做的一项。

要触发幻觉，可以设计三类问题：

1. 虚构概念：问一个不存在的技术术语、书籍或人物，看模型会不会编造解释。
2. 时间敏感信息：问“最新的政策”“今年的统计数字”，看模型是否把过时信息当成事实。
3. 精确细节：问某个用户手册里的具体参数、某个合同条款的原文，看模型是否在信息不完整时强行补全。

一个健康的模型，在这类问题面前应该明确表示“我不确定”“我无法确认”“我的知识截止时间之前没有这个信息”。如果模型每次都能给出非常完整的答案，反而要警惕，因为完整不等于正确。

4.2 提示工程对幻觉的抑制作用

幻觉不能完全消除，但可以通过提示工程明显抑制。评价时，你可以同时测试两种提示词，看模型的差异：

一种是不做任何约束，直接提问；另一种是加上约束，比如“如果不确定，请直接告诉我不知道”“请只基于提供的资料回答，不要补充额外信息”“如果资料中没有相关内容，请明确说明”。

通常情况下，第二种提示会降低模型编造的概率，也会让模型更频繁地承认不知道。如果你的业务场景本身允许模型说“不知道”，那这个行为是加分项；反之，如果业务需要模型给一个尽量完整的答案，你就要在幻觉风险和功能完整度之间做权衡。

这也是为什么评价不能只看“答对率”，还要看“错误方式”。两个模型答题正确率一样，一个在不确定时说不知道，另一个在不确定时编造细节，落到真实业务里风险完全不同。

4.3 哪些“错误”不该算作幻觉

幻觉测试也要避免误伤。有些输出看起来像错误信息，但实际上不是幻觉：

• 理解偏差：问题本身有歧义，模型理解的角度和你预期不一致，答非所问。
• 格式错误：模型理解了问题，但输出格式不合要求，这属于指令遵循问题，不是幻觉。
• 知识截止限制：模型训练数据时间早于你的提问时间，它给出的是旧信息，这是时效性问题。
• 资料缺失：你只提供了部分资料，模型基于有限信息推断，这在业务上属于逻辑问题，不是编造。

判断幻觉时，要区分“模型在编造”和“信息不全导致的不准确”。这两类问题的处理方式完全不同：前者需要换模型或者加强提示约束，后者需要补齐输入资料。

5. 长文本、代码、数学、多轮对话分别怎么测

5.1 长文本：理解、定位、记忆

很多国产大模型宣传长文本能力，评价这个能力时要避免一个误区：只看“能输入多长”没有意义，关键是输入长文本之后，模型还能不能准确工作。

建议用一篇 5000 到 20000 字的材料做三类测试：

1. 全局总结：让模型总结整篇材料的核心观点，看是否遗漏重要信息。
2. 精确提取：让模型找到材料中某个具体数字、人名或结论，考察定位能力。
3. 跨段推理：让模型结合材料前段和后段的信息回答问题，考察长程记忆。

现实里很多长文本模型在“开头和结尾”回答得不错，但中间部分信息容易丢失。测试时最好把目标信息放在材料的不同位置，分别测试，才能看出真实水平。

5.2 代码：可运行性比代码风格重要

代码类模型的评价，第一标准是可运行性，不是“看起来像不像参考答案”。

我给代码任务定的评分顺序是：

1. 生成的代码能否直接运行。
2. 运行结果是否符合题目的输入输出要求。
3. 是否考虑了边界情况。
4. 代码结构和注释是否可读。

前两条不过关，后面再漂亮也没用。测试代码任务时，建议选择有明确输入输出的小题目，然后把模型生成的代码放到真实环境里执行验证。不要只看生成结果自己说“看起来对”。

5.3 数学逻辑：答案之外还要看推理路径

数学题是评价逻辑能力的好方法，但评分时要同时看答案和推理路径。

有些模型答案正确，但推理过程明显偷换概念或者跳步；有些模型答案错了，但思路方向是对的，只是中间计算失误。对真实业务来说，这两种情况价值完全不同。前者说明模型可能靠“背诵”而不是“理解”得到答案，后者说明模型具备推理框架，只是稳定性需要提升。

建议选择带有固定答案的题目，评分时把“最终答案正确”和“推理路径合理”分开记录，这样才能看出模型是理解能力还是记忆能力更占优势。

5.4 多轮对话：一致性和上下文覆盖

多轮对话测试主要看两点：上下文保持能力和一致性。

可以设计一个逐步叠加信息的对话场景，比如先给模型一个背景设定，然后在后续轮次里逐步追问细节，看模型是否记得你前面提供的信息。还可以故意在第一轮让模型给出一个结论，第二轮追问它“你刚才说的是什么”，看它能否复述。

一致性差的表现很典型：模型在前面说“方案 A 更合适”，后面换一种问法，它又改成“方案 B 更合适”，而且没有意识到自己前后矛盾。这在需要长期对话的客服、咨询、辅助决策场景里是致命问题。

6. 不同场景下的选型建议

6.1 学习研究：先看文档和社区

如果你是学大模型相关知识，或者正在拆解大模型能力，我建议先别急着追求“最强模型”，而是选文档齐全、社区案例多、生态丰富的模型。原因是学习过程里你会遇到大量环境问题、参数问题、提示词问题，这些问题靠社区经验能解决大半，比模型本身强一丁点更有价值。

6.2 内容创作：中文表达和格式稳定

内容创作场景，重点考察模型的中文表达质量、语气控制能力和格式稳定性。可以准备几种文体测试：新闻报道、产品文案、技术教程、日常周报。不要只看一篇写得怎么样，要看同一个模型能不能稳定地按你的语气要求输出，而不是这次文绉绉、下次大白话。

6.3 应用开发：接口稳定性优先

做应用开发时，模型能力只占一部分，接口稳定性同样关键。要重点看响应延迟、错误率、限流策略、超时表现、输出是否容易解析。一个模型能力再强，如果接口经常不稳定、返回结构老变、批量请求超时率高，那在真实业务里的开发成本会非常高。

评测接口稳定性时，至少跑 50 到 100 次连续请求，记录成功率、平均响应时间、最大响应时间、异常类型，不要只测一两次就下结论。

6.4 垂直行业：农业、电力这类场景要独立思考

最近“农业大模型”“电力系统大模型”这类概念很热。评价这类垂直模型时，我的建议是：优先测它是否真的理解行业术语和业务流程，而不是只看它有没有挂一个“农业”或“电力”的名称。

比如农业场景，可以问“土壤墒情持续偏低时，灌溉决策应该优先考虑哪些因素”；电力场景，可以问“独立储能电站参与现货交易时，电价信号和充放电策略怎么联动”。把这些真实业务问题拿去测，比看宣传描述可靠得多。

还要注意一个边界：垂直领域模型通常是在通用模型基础上微调而来，它的专业能力强，但通用能力可能会被削弱。所以评价要分两块：专业题目要测，通用题目也要测，避免专业能力提升、基础能力明显下降这种情况影响整体使用。

7. 评价中的常见误区和排查思路

7.1 答错不一定是模型不行

评测过程中最容易犯的错误，是把所有问题都归结到模型能力上。实际上，很多“答错”是因为：

• 提示词本身有歧义，模型接收到的指令不明确。
• 输入资料编码或者格式有问题，模型读到的内容已经残缺。
• 请求参数设置不当，比如温度过高导致输出随机性变大。
• 模型知识截止时间早于问题涉及的时间。

遇到错误输出时，先调整提示词和参数，用两条不同表述再测一次，如果还是错误，才考虑归因到模型能力。

7.2 卡住、超时、输出为空先查哪里

批量评测时遇到卡住、超时、输出为空，不要急着怀疑模型或接口，按下面的顺序排查：

1. 检查输入格式：编码是否为 UTF-8，JSON 是否合法，文本里有没有异常字符。
2. 检查请求参数：超时时间是否设得太短，最大输出长度是否太小，并发数是否超过限制。
3. 检查资源占用：内存、磁盘、CPU 是否被打满，尤其是本地部署场景。
4. 检查日志：接口返回的错误码、错误描述，往往比现象更准确。
5. 检查网络：连接是否被中断，代理设置是否影响请求，域名解析是否正常。

绝大多数“卡住”问题都不是模型能力问题，而是环境或参数问题。

7.3 评测结果怎么记录才能复现

评测做完了，如果记录不规范，结果就无法复现，相当于白测。我建议每个评测任务至少记录这些信息：

• 模型名称和版本（如果有版本号，一定记录）。
• 接入方式（网页、API、本地部署）和完整参数。
• 提示词原文。
• 输入材料样本。
• 模型原始输出。
• 评分结果和评分人。
• 异常现象和当时的排查记录。

把这些信息整理成固定格式的表格或目录，后续不管是换模型、换参数，还是写选型报告，都能直接复用。评价国产主流AI大模型这件事，说到底不是一次性的好奇心测试，而是一个需要持续迭代的工作流。模型更新速度这么快，今天的能力不代表三个月后的水平，只有把方法和记录沉淀下来，才能在下一次新版本发布时，快速判断值不值得升级。

我个人更建议把评价拆成三层来做：先用 5 个真实任务做初筛，再用 20 到 50 个问题做能力维度测试，最后用批量评测验证稳定性和边界。每一层都跑通，再谈选型结论。这样下来，你得到的不只是一个“哪个模型好”的答案，而是一套能反复使用、能根据任务变化调整的评价能力。踩过几次之后你会发现，很多看似是模型能力的问题，其实是提示词、环境、参数或者输入材料没有处理干净。把这些前置问题先解决掉，大模型本身的能力边界才能看得更清楚。