企业官网建设流程全解析

前两天有个做内容产品的朋友，拿着一份大模型跑分榜单来找我，开口就问：“Qwen 和 DeepSeek 都挺高，ChatGPT 也不低，我到底该用谁？”

我没有直接回答。因为这个问题没法直接回答。

大模型选型这几年已经成了企业技术决策里的高频难题。多数人第一步就打开榜单，按分数从上往下挑。但跑了几个真实业务之后，分数最高的往往不是最合适的。我手里过过不少大模型接入项目，有知识问答、文档解析、代码辅助、甚至工业质检文本分析，最后得出一个特别朴素的经验：选模型真的不用看跑分，把下面这三件事想明白，答案自己就浮出来了。

这不是反智，也不是否认评测的价值。跑分是一个筛选工具，但它筛的是“模型能力上限”，你的业务需要的是“在特定场景下稳定输出”。这两者之间隔着部署成本、延迟、上下文长度、格式可控性、数据合规，哪一样都比几分之差更影响落地效果。

下面我以实际选型中踩过的坑和验证过的方法，把这套“三问”逻辑完整展开。

1. 跑分到底在骗你什么：榜单之外的真相

既然说不看跑分，总得先说清楚跑分哪里不靠谱。不是要全盘否定，而是要知道它的局限在哪里。

1.1 跑分测的是平均值，你的业务踩的是极端值

标准评测集一般由数万条题目组成，最后取一个平均分。你业务里真正致命的是那些边界场景：一段带错别字的文档、一份合法的合同、一句带有行业黑话的提问。这些在平均分里可能只占 0.1% 的权重，但在生产环境里可能决定可用性。

举个例子。我帮一家律所团队测过文档审查场景，榜单上某模型综合分高出竞品 3 分。但把它放在真实合同片段上跑，它自动把“不可抗力条款”里的责任限制内容理解成了“赔偿责任无限”，在场律师直接摇头。另一个低 3 分的模型反而乖乖按原文结构输出。这就是平均值骗人的典型场景。

1.2 跑分无法告诉你部署成本和响应延迟

一份榜单不会告诉你“分数高 2 分，推理速度慢三倍”意味着什么。很多高分模型参数规模大，或者是 MoE 架构，激活参数少但总参数多，本地部署时对显存和带宽的要求非常高。你真上了业务才知道，用户等不起 8 秒才蹦出一个字的首 token 延迟。

跑分也测不出“在 GPU 上跑到 64 并发时会不会崩”。这属于压测问题，跑分榜单不认这个。

1.3 跑分存在数据污染，越火的模型越严重

我不说名字，但业界已经有不少团队做过“反测试集”实验：把评测题稍微改几个字，模型性能立刻下降。说明部分模型在训练时见过原题，背答案背出来的分数，换个说法就露馅。你上生产环境后遇到的不会是原题，全是变体。

所以我的建议是：跑分只作为初筛，把候选范围缩到三到五家就够了。真正下结论，要拿你自己的业务数据做一轮盲测。这个盲测怎么做，后面第 5 章给出可执行的脚本。

2. 第一问：你的真实使用场景是对话、管道，还是嵌入式

这是选型的第一步，也是很多人没想清楚的一步。同样是“用大模型”，对话、管道、嵌入式三种场景对模型能力的要求完全不同。

2.1 对话型场景：首字延迟和语气一致性优先

对话型产品，包括智能客服、AI 助手、陪伴式聊天，核心指标不是“答得有多好”，而是“答得多快、多稳”。一个 8B 模型在普通显卡上可能跑出 30 token/s，一个 70B 模型只剩 8 token/s。对于交互产品来说，速度就是体验，体验就是留存。

语气一致性也常常被忽视。我见过不少团队换了模型之后，客服话术从“客观专业”变成“热情过度”，用户投诉明显增加。这是风格漂移问题，跑分测不出来。对话型场景建议用中等参数规模、指令跟随能力强的模型，配合温度参数调低到 0.4 以内，效果往往比盲目上大模型更稳。

2.2 管道型场景：结构化输出能力比什么都重要

数据抽取、信息结构化、报表生成、代码补全，这类场景大模型只是管道中的一个环节。后面跟着的是解析脚本、数据库、工单系统。前期模型输出的格式只要错一个字段，整个链路就崩。

测试管道型场景时，我通常会设计一个强制 JSON 输出用例，连续跑 50 条，看解析成功率。很多跑分不错的模型在“必须输出合法 JSON 且遵循指定 schema”时，失败率高得吓人。这个指标比任何通用跑分都关键。为了提升成功率，通常还要用函数调用能力强的模型，或者在提示词里锁死输出模板，甚至配合负反馈示例，也就是给几个“你不要这样输出”的坏例子。

2.3 嵌入式场景：上下文长度和检索能力是关键

嵌入式场景指把大模型作为能力模块，嵌入到 RAG 问答、数据分析工具里。这类场景下，模型需要处理的是检索出来的候选片段，不是“全凭自己记忆作答”。所以模型自身的知识量反而次要，更重要的三个能力：长上下文理解、跨段落信息聚合、避免被无关片段带偏。

我做过一个对比实验，同样在知识库问答里给六个候选片段，有的模型会盯着最开头一段话输出，后面的证据全被忽略。这种毛病在通用跑分上完全看不出来。所以嵌入式选型必须拿真实检索结果做输入测试，片段里故意掺入一条相关但错误的干扰信息，看模型会不会被误导。

这张表可以直接拿来当初判标准：

先把自己的场景归类，再带着场景指标去测模型，选型会清晰得多。

3. 第二问：API、本地还是私有化：部署现实决定模型下限

这一问本质上是回答“你能接受什么程度的依赖”。不同交付方式直接锁定了模型的可选范围。

3.1 走 API：先谈数据合规，再谈能力

很多团队上来就接各家闭源 API，能力确实强，部署成本也确实低，但有一个隐形问题：业务数据出去之后，回不来了。如果你的业务涉及用户隐私、企业财务、未公开产品信息，数据出站之前必须过合规这一关。与其后面整改，不如一开始就把数据脱敏规则定好。

另外，API 服务的可用性也是选型指标。我用过几个平台的 API，高峰期超时率从 0.5% 飙升到 5%，直接导致线上链路失败。建议在接入前至少做一周的压测，记录 p50、p95、p99 延迟和超时率。不要只看模型能力 Demo 跑得飞起，要看到它在生产压力下还能不能飞。

3.2 本地部署：显存推理公式帮你圈定模型范围

本地部署不是简单的“下载一个大模型跑起来”，硬件是硬约束。圈定模型之前，先做一个显存粗算：

权重显存大约等于参数量乘量化位数再除以 8。比如 7B 参数用 FP16，天然就需要大概 14GB 权重显存；用 INT4 量化，大约 3.5GB。加上 KV cache、中间激活和运行时开销，实际占用要比理论值多出 20% 到 50%。社区里常见的估算口径是：INT4 量化下 7B 模型至少需要 8GB 显存，14B 至少 16GB，32B 至少 24GB。

我见过不少人拿一台 16GB 的笔记本去跑 32B 模型，量化成 4bit 勉强能加载，但只要上下文一长就直接 OOM。这属于典型的“能加载”和“能使用”分不清。如果你只有单卡 24GB，比较稳的选型范围就是 INT4 量化的 14B 到 32B 家族，或者更小的 7B 跑到更高精度，反而效果不差。

工具链上，目前 Ollama 适合快速起步，一条命令就能拉起模型，配合 Open WebUI 做成带界面的人工智能工作台；vLLM 适合追求高吞吐的生产环境，它有连续的批处理加速，并发高的时候单位 token 成本能明显下降。社区里经常讨论“Ollama 装的模型到底是个什么文件”，简单说就是把模型权重封装成了 GGUF 格式，携带量化信息，方便分发和加载。生产环境如果追求吞吐，我通常直接用 vLLM 拉起来，暴露一个兼容接口给下游业务。

3.3 企业私有化：考虑的是治理链路而不是模型文件

私有化部署这个词经常被误解为“把模型下到内网服务器里”。其实真正的私有化难点在配套：离线镜像怎么更新、模型权重怎么安全分发、谁有权限发起推理请求、推理日志怎么审计、私有知识库怎么和公网模型生态隔离。

我参与过的私有化项目里，最费时间的反而不是选哪个模型，而是把数据链路打通。有一次因为内网不能访问公网模型源，光上传验证模型文件就折腾了两天。所以做私有化选型时，优先考虑支持离线部署、有成熟容器镜像方案、许可证允许内部商用的开源模型，这类模型社区生态好，出了坑也有地方查。

还有一个要提醒的安全问题：模型投毒。下载模型时尽量走官方源，校验哈希值，别因为图快从不明渠道拉压缩包。这不是危言耸听，业界已经有通过篡改模型权重植入后门的案例，被调到特定关键词时输出恶意导向内容，跑分根本测不出来。

4. 第三问：RAG、微调还是裸用：后续路线要提前定

很多团队选完模型才想起来思考“是不是该微调”，顺序完全反了。你打算怎么用这个模型，直接决定了选型时该关注哪些能力。

4.1 裸用：选通用能力最强、指令跟随最好的

如果你只是简单接个对话、做点文本改写，不打算做知识库也不做微调，那就选指令跟随能力最强的模型，不需要纠结领域知识。因为领域问题它答不准，你不该指望它答准，而是应该在应用层做好引导，比如提示词里限定范围、给足例子。

裸用场景下，上下文窗口反而更重要。同样的价格可能买到 128K 上下文的模型和 32K 上下文的模型，我倾向于选更长的那个，因为后面接 RAG 时上下文就是缓冲池子，越大越不容易截断关键信息。

4.2 做 RAG：重点关注文档理解、长文本聚合

RAG 是目前知识库问答的主流方案，核心思路是先检索后生成，让模型基于证据作答。所以模型的“知识量”不重要，“阅读能力”才重要，尤其是处理长文档、跨章节引用、表格识别这些能力。

选型时可以这样测：准备一份三四千字的行业报告，里面埋 5 个分散在不同段落的事实点，问题需要跨段落拼接才能回答。能答出来的，RAG 能力基本过关；只答出其中两三个的，接着再用。另外，RAG 链路里模型不仅要读检索片段，还要判断“这段证据够不够回答”，所以模型的拒绝回答能力也值得测。遇到证据不足时它是硬编一个答案，还是会坦诚“信息不足”，在严肃业务里差别很大。

4.3 想做微调：算力、数据、许可证三个硬门槛

微调这块水比较深。不是说你照着网上教程跑几个小时 Loss 降下去就叫微调成功，还要能持续维护、稳定上线。先看算力，LoRA 之类的高效微调方法确实能降低门槛，但数据准备才是最大的成本。微调需要高质量的成对输入输出，你要是没有几百上千条人工标注数据，效果很可能不如直接在提示词里写好规则。

另一个被忽略的点是模型许可证。不同开源模型对商用、派生分发、修改范围的规定不一样，有的要求衍生作品继续开源，有的禁止商用，有的允许修改但不允许改名再发。你要是把许可证限制的模型微调后塞进商业产品，法律风险就埋下了。所以我一般建议：先用 RAG 解决 80% 的需求，真的解决不了的，再把那 20% 的顽固问题拿去做微调。多数团队到后面会发现根本不需要微调，而是提示词和 RAG 没做透。

5. 通用一套测试框架：20 分钟就能跑出结论

开头我说的三个问题，再配合一套 20 分钟测试脚本，选型就基本落地了。这套方法不需要跑分平台，只需要你准备一段自己的真实业务数据。

5.1 准备 20 条真实输入，而不是网络上的段子题

从你的历史工单、客户提问、常见文档里抽 20 条真实输入。注意，是真实输入，不是人工编的漂亮问题。很多模型面对网络上的“脑筋急转弯”表现不错，碰到你们行业里那种措辞混乱、信息残缺的真实请求就崩了。

这 20 条题里建议包含：5 条超短输入、5 条带错别字或口语化的输入、5 条需要多步骤推理的长输入、5 条格式要求明确的输出型任务。覆盖对话、管道、嵌入式三种场景中最关键的变体。

5.2 制定粗筛维度：内容准确、格式合规、时效自知

三个维度就够，不能求全：

• 内容准确，看核心事实不跑偏；
• 格式合规，看能否按要求输出表格、JSON、特定结构；
• 时效自知，模型是否知道自己不知道，不乱编。

每个维度给个 0 到 2 分，20 条题跑完看总分。你说这不还是打分吗？对，但打分标准是你定制的，权重围绕业务来，跟榜单没关系。

5.3 算一笔成本账，比任何分数都真实

在模型能力差异不大的前提下，成本账往往是压死骆驼的最后一根稻草。不需要看官方宣传的 Token 价格，要算实际账面成本：自己部署的，按 GPU 折旧、电费、运维工时折算每条请求成本；用 API 的，按实际并发和 Token 消耗估算月费用。

这里有一个常被忽略的成本项：错误重试成本。格式错一次，链路重跑一次，Token 消耗翻倍，成本就不是账面上那个价了。所以管道类场景宁可选输出稳定但单价略高的模型，也不选便宜的“碰运气模型”。同样的道理也适用于延迟，慢模型占用用户时间，这部分成本虽然没有金额，但对留存的影响是实打实的。

6. 选型之外的几点真实心得

模型选型没有一劳永逸，它是你业务的一部分，会随业务需求一起迭代。我自己的习惯是每年至少复测一次，因为开源模型生态更新太快，去年不行的今年可能已经行了，去年要付费的今年可能有开源平替。

还有一个小技巧，不一定关注全网热搜的大模型下载链接。真正重要的是建立自己的评测题库，把它沉淀成团队资产。每来一个新模型候选，直接进同样的题库跑一遍，分数对比一目了然。这套题库比任何跑分榜单都值钱，因为它长在你的业务数据上。

最后说说心态。我看到有些人选模型纠结了半个月，其实花半天把三问问完，再花半天跑真实数据测试，结论就能出来。大多数项目里，模型能力不是瓶颈，业务流程设计才是。与其花时间找一个“完美模型”，不如把时间花在把调用方式、上下文策略、错误处理这些细节打磨好。等模型能力再涨一轮，你的应用框架还在，换个模型底座就能平滑升级，那才是真正不亏的选择。