企业官网建设流程全解析

被问到"该选哪个大模型"的次数，我记不清了。问的人有做客服系统的，有做知识库问答的，有想给内部流程加个助手的，还有打算把模型接进审核管线的。大多数人一上来就甩我一张排行榜截图，问我是不是选排第一的那个就行。我的回答通常不是"是"或者"否"，而是反问他一句：你拿自己的真实业务数据测过吗？没有的话，榜单再高也是别人眼里的优秀。这些年我在项目里踩过的坑，让我养成了一个习惯——选大模型，我会逐条过这 5 件事：业务效果、成本、有效上下文、延迟并发、工具链稳定性。这五关过完，才轮到排名说话。

1. 第一件事：拿业务数据实测，别让榜单替你拍板

1.1 为什么榜单分数在真实业务里经常失灵

排行榜上的分数看着客观，其实至少有三个问题绕不开。

第一是训练数据污染。测评集的题目可能在训练阶段就被模型见过了，分数自然虚高。这不一定是厂商作弊，更多是互联网上的内容早就混进了训练语料，模型哪怕没见过原题，也见过高度相似的表达。

第二是数据分布不一致。榜单测的是通用任务，比如百科问答、数学推理、代码生成，这些任务跟你业务里的真实输入根本不是一回事。你做的是短文本工单分类，或者需要从聊天记录里抽取结构化字段，那测评集里一万道题都和你无关。

第三是刷分驱动。模型厂商都知道分数会被拿来当卖点，于是会针对公开评测集做额外优化。这个现象在开源生态里更明显，有些模型论文里的指标很漂亮，拉下来一跑业务数据就现原形。

所以我的结论是：榜单可以看，但只能用来圈定候选名单，不能用来做最终决策。

1.2 自己搭评测集：从历史数据里抽 50 个样本就够起步

很多团队一听说要做模型评测，第一反应是要搞几千条数据的测试集，然后这个项目就卡死在"等数据"上了。我的经验是：先抽 50 条真实样本就够用了，重要的是样本结构和评分标准，而不是数量。

具体做法是这样。先从你历史业务数据里抽样本——比如过往的客服会话、工单记录、已经标注过的样本、线上日志里真实用户的提问。抽的时候注意覆盖几个维度：常见场景至少占一半，疑难场景占三成，边界和异常输入留两成。如果你不知道疑难场景是什么样的，就翻一下历史工单里那些被转给人工处理的记录，那里面藏着最典型的问题。

抽完之后，每条样本配一个参考答案。这个步骤不能偷懒，参考答案可以是人工写好的标准回复，也可以是从历史记录里挑选的出彩答复。没有参考答案，后面打分就全靠主观拍脑袋，评测结果没法对齐。

1.3 评分维度要拆开看，总分会掩盖问题

给模型结果打分时，最忌讳只打一个总分。总分高不代表适合，因为你不知道它是在哪个维度上拿的分。我把评分拆成几个独立维度，每个维度单独打分，再加权汇总。

这五个维度里，正确性和指令遵循度是我最看重的。前者决定了系统靠不靠谱，后者决定了你写的 prompt 能不能生效。如果格式合规性这一项连续多条不达标，那这个模型接进生产链路之前就要打一个大大的问号。

1.4 分数之外，还要拆解"失败模式"

评测结果出来之后，不要只盯着正确率这个数字，我会把错误结果批量拉出来做一次聚类，看看它"稳定地栽在哪里"。这一步给的信息比总分值钱得多。

举个例子。某次我在给一个信息抽取项目选模型，两个候选模型总分差不多，但错误模式完全不同。模型 A 的错集中在长文本输入上，超过 2000 字就开始丢字段；模型 B 的错集中在歧义表达上，遇到"张三欠李四 500 元"这种句子会分不清谁是债权人。知道了这个差异，决策就清楚了——我的业务场景里长文本占大多数，那模型 A 直接出局，哪怕它总分略高。错误模式会直接告诉你这个模型上线之后会在哪些场景给你惹麻烦，以及你需要准备多少兜底逻辑。

2. 第二件事：把成本账从"单价"算到"单次任务"

2.1 输入输出计价的不对称性

看 API 定价时，很多人只扫一眼"百万 token 多少钱"就完事了，这是最容易踩的坑。多数商用模型是输入和输出分开计价的，而且输出 token 的价格往往是输入的三到五倍。

原因不难理解：输出 token 是模型实时逐字生成的，推理过程中每个输出 token 都要占据完整的算力时间，而输入 token 主要是并行处理，计算成本相对低。所以厂商把输出定得贵，是有物理原因在里面的。但如果你只看输入单价，成本估算能偏出好几倍。

2.2 单次任务成本公式

我算成本从来不问"单价多少"，只问"单次任务多少钱"。公式很简单：

单次任务成本 =（平均输入 token 数 × 输入单价 + 平均输出 token 数 × 输出单价）÷ 1,000,000

举一个具体的例子。假设某家商用 API 的定价是输入每百万 token 10 元，输出每百万 token 30 元。你做的是一个知识库问答应用，每次请求要携带系统提示词、检索到的若干段资料、以及前几轮对话历史，加起来大约 6000 个输入 token；模型平均返回 400 个输出 token。那单次成本就是：

6000 × 10 ÷ 1,000,000 + 400 × 30 ÷ 1,000,000 = 0.06 + 0.012 = 0.072 元

如果一天有 5 万次请求，光模型调用就是 3600 元，一个月就超过十万。很多团队方案评审时觉得"挺便宜"，上线后看到账单才反应过来，就是没算这笔单次任务账。

2.3 长上下文带来的成本放大效应

对话型应用还有一笔容易被忽略的隐性成本：每一轮新请求都要把完整的对话历史重新发给模型。一个用户聊了 20 轮，假设历史累积到 1 万个 token，那他在第 20 轮的请求本身就带着 1 万个输入 token，而不是像你想象的那样"只问一句新的"。

按上面的价格算，1 万个输入 token 就是 0.1 元，加上输出，一个长期对话会话跑下来，成本可能是首轮对话的十几倍。这个放大效应对很多高频客服类场景是致命的。所以我做成本评估时，会专门算"带历史的长会话场景占总流量多少"，这个比例直接决定要不要上上下文压缩、要不要做会话摘要。

2.4 私有化部署的临界点：什么时候该自建

成本话题绕不开开源模型和私有化部署。我的判断标准很简单：当请求量足够大，或者数据敏感度不允许外发时，才考虑自建。自建的成本要算全，不只是显卡的钱。

硬件上，一张好点的推理显卡价格不菲，要跑一个性能接近商用入门水平的开源模型，通常需要两张卡组一台机器；运行成本上，电费和机器折旧每个月都是固定的；人力成本更不可忽视，模型部署、推理框架调优、显存管理、负载均衡、版本升级，这些都需要人维护，不是下载个权重就能甩手不管的。

我见过不少团队为了省 API 费用自建，结果工程师连续三周在调显存溢出和推理速度，算下来人天成本早就超过 API 费用了。所以自建这件事，要把时间线拉到一年，算总拥有成本，而不是只看单次调用差价。

3. 第三件事：有效上下文长度，参数表上的数字要打折扣

3.1 "能塞进去"和"记得住"是两回事

模型标称支持 128K 上下文，这个数字说的是"输入序列最长能到 128K token"，意思是塞得进去。但塞得进去不等于它每个位置都记得住。我在实测中发现，很多模型在处理长上下文时，中间位置的信息质量明显下降，这种行为在学术上叫位置偏差。

类比一下，一个人一次能读一百页资料，但读到最后，他很可能已经忘了第 40 页写了什么。大模型也是这样——注意力资源的分配并不均匀，开头和结尾的内容更容易被"记住"，中间的内容容易被忽略。

3.2 大海捞针测试的局限

网上流传的"大海捞针"测试，做法是把一句关键信息藏在一大段无关文本中间，然后问模型能不能找出来。它能测出一个模型的基础检索能力，但它的局限也很明显：这测的是"找到这句话"，不是"理解整段内容"。

你实际业务里不会有那么多"捞针"场景。更多时候是让模型分析一份长文档、总结一堆聊天记录、或者按照一份几十页的规范做判断，这些任务要求在整段上下文中都保持理解，不是定位一句话就能搞定的。所以大海捞针过了，不代表长上下文能力就合格。

3.3 长对话的遗忘和位置偏差

多轮对话场景里还有另一个问题：随着轮次增加，早期轮次里的关键信息会被"挤"出注意力范围。即使所有内容都还在上下文窗口内，模型回复时可能已经默认忘记了用户开场时提的需求。

我测试时遇到过很典型的例子：开场用户说"我只想看 6 月之后的订单"，聊了十几轮之后，模型已经开始推荐 3 月的订单了，而且它没有意识到前后矛盾。这种问题在用户体感上非常糟糕，而且很难通过简单的 prompt 约束解决。

3.4 自己设计上下文压测，量出"有效长度"

我给团队的建议是，别信宣传上的最大值，自己压一遍。方法不复杂：准备一份你业务里真实会出现的长文档，比如操作手册、聊天记录、历史报告，从中挑出十个散落在不同位置的关键细节；然后分别用 8K、16K、32K、64K 的填充长度把文档撑大，每个长度跑二十遍，统计关键细节的回答准确率。

填到某个长度后准确率明显掉到及格线以下，那个位置就是"有效上下文"的边界。我最近一次给某个长文档分析场景做压测，标称 128K 的模型在 32K 之后就开始漏细节，最后我们按 32K 来规划系统设计，给上层加了检索模块，而不是把所有内容都硬塞给模型。

4. 第四件事：延迟、吞吐和并发，上线前必须亲自压一遍

4.1 平均延迟会骗人，要盯 p95 和 p99

模型本身的能力再强，如果上线以后转圈圈，用户一样会弃用。延迟指标里，平均值是最会骗人的。p95 或者 p99 才是你真正需要关心的数字，因为最慢的那批请求，才是用户真实感受到的体验。

同一个模型，可能平均延迟 1.2 秒，看起来不错，但 p95 是 4 秒，p99 直接到了 8 秒。这意味着 5% 的请求要等四秒以上，1% 的请求要等八秒。对一个在线交互场景来说，这个尾延迟完全是不可接受的。

4.2 首 token 延迟和流式输出比"总耗时"更影响体感

评估延迟时，我会拆成两个阶段来看：从请求发出到模型返回第一个 token 的时间（首 token 延迟），以及后续生成速度。为什么这么拆？因为现在主流应用都做流式输出，用户看到第一个字在动，就会觉得系统在工作。

有的模型总耗时差不多，但首 token 特别慢，用户盯着屏幕干等一两秒才看到字符出现，体验极差。有的模型首 token 快，后面生成速度慢，用户能看到文字一行行冒出来，虽然总耗时更长，但体感反而更好。所以压测的时候，这两个指标要分开记录。

4.3 并发压测的做法和三根曲线

单请求测出来的数据不能代表生产环境。同一个模型，在只有一个请求时可能很快，但 50 个请求同时进来，就会出现排队、超时、甚至直接报错。我做并发压测的方法比较朴素：根据业务预估高峰期 QPS，准备一到两倍的压测量级，用脚本同时发起请求，记录三组数据：

• 延迟分布：并发上升后，p50、p95、p99 分别恶化到多少
• 吞吐上限：每秒能稳定处理多少请求，超过这个数之后延迟曲线开始陡峭上升
• 错误率：高并发下请求失败的占比，很多无状态 API 在过载时会选择直接拒绝

这个压测一定要在真实网络环境里做，不要在本地连测试环境模拟，因为公网网关、限流策略、服务端排队，统统都是变量。你测出来的结果，直接决定了上线之后要不要加限流、要不要做超时重试、要不要买更大的并发配额。

4.4 三种部署形态下的延迟差异

同一个模型换一种部署形态，延迟表现可能完全不同。公有 API 的好处是零运维，但它在高峰期可能出现共享资源争抢；托管式私有部署在延迟稳定性上好一些，代价是费用更高；完全自建则可以把延迟压到最低，但要自己处理扩容和故障。

我的建议是：先明确你的延迟目标是"秒级可用"还是"毫秒级可用"。客服助手、知识库问答这类场景，三秒内出结果基本没问题；但如果是高频调用、嵌在用户操作链路里的功能，比如输入联想、实时审核，那 p95 必须控制在 1 秒以内，这时就应该优先考虑私有部署形态。

5. 第五件事：工具调用和结构化输出的稳定性，决定能不能长成系统

5.1 函数调用质量是智能体架构的地基

如果你的目标不只是"聊天"，而是让模型去调用工具、操作业务系统，那函数调用能力就是绕不开的一关。模型在什么情况下决定调用哪个函数、参数提取得准不准、会不会在不需要调工具时强行调用，这些细节直接决定你的智能体流程能不能跑通。

我拿真实场景测函数调用时，会准备一组业务函数，比如查库存、查订单、发通知，然后构造一批需要调用工具才能回答的任务。重点看三类错误：该调用的没调用，导致答非所问；参数从文本里提错，比如把收货人当成下单人；不需要调用时强行调用，凭空造出一个工具结果。这三个错误只要有一个比例偏高，这个模型做智能体应用就很难受。

5.2 JSON 输出稳定性和 schema 遵循能力

另一个容易被忽略的是结构化输出的稳定性。做系统集成时，我们经常需要模型输出一段 JSON，然后交给下游程序处理。如果模型输出的字段名时准时不准、偶尔夹带解释性文字、甚至把 JSON 写坏，你的解析层就要花大量精力去兜底。

我的测试方法是给模型一张明确的字段清单，让它按给定 schema 输出，连续跑 100 条，统计三个指标：合法 JSON 的比例、字段名和类型完全匹配的比例、完全无多余内容的比例。这三个比例如果低于 95%，接进生产环境前就要三思。现在有些平台会提供约束解码能力，能在语法层面保证输出是合法 JSON，但它只能保证格式，不能保证语义正确，该做的校验一步都不能省。

5.3 生态成熟度：微调、部署和周边工具的配套

单点能力再强，配套跟不上也很难落地。我会重点看模型周边生态的成熟度：能不能在主流推理加速框架里跑起来、有没有现成的量化方案来压缩显存、社区里有没有人踩过坑并留下解决方案、出问题的时候能不能快速找到资料。

开源模型的好处是你可以自己调整，比如做低秩微调来适配特定域，或者用量化把大模型塞进更小的显存。商用闭源模型的好处是省心，但如果你想做深度定制，它就像一个黑盒，你只能通过 prompt 去调。这两种模式没有绝对的好坏，取决于你的团队有没有对应的人才和时间。

5.4 版本迭代风险：今天能用的能力，明天还在吗

大模型领域变化快，选型时还得考虑版本迭代的稳定性。商用模型可能会调整定价、下线旧版本、或者悄悄改变某个接口的行为，这些变化对你的生产系统可能是破坏性的。开源模型也可能因为社区转向、维护者停更，导致你依赖的版本得不到安全修复。

我选商用模型时，会专门确认是否支持版本固定，以及变更通知的周期；选开源模型时，会关注项目的活跃度和发布节奏。做技术的都知道，技术选型一旦定下来，迁移成本是很高的，这方面的风险控制，越早考虑越主动。

6. 附赠一条红线：安全合规和数据边界要提前查清楚

6.1 数据流向：输入、输出和日志去了哪里

前面五件事都过关后，还有一条红线是安全合规。很多人等到数据要出省、要过审的时候才想起来查，那时已经晚了。选型阶段就应该搞清楚：你发送给模型的文本会存储在哪里、存储多长时间、厂商会不会拿你的数据做模型训练、是否支持申请关闭数据留存。

这些信息通常在服务条款和数据协议里写着，要逐条核对。如果条款写得不清晰，宁可请对方给个书面确认，也不要稀里糊涂上线。我见过有团队因为没查清楚日志留存策略，闭眼让数据在外部流转了几周，后来合规审计时才发现问题，整个项目被叫停返工。

6.2 数据脱敏和权限控制

就算厂商承诺数据不留存，我仍然建议在上层加一道脱敏。凡是发给模型的文本，先过一遍敏感信息识别，把身份证号、手机号、地址、银行卡号这类直接替换成脱敏占位符；返回结果里也要做一次反向审查，防止模型把不该出现的原始敏感信息带回来。

这不是不信任厂商，而是把安全边界控制在自己手里。模型服务只是一个组件，它永远不该成为你数据安全的信任根。权限控制同样重要，谁有权限调用哪个模型、能不能传外部数据、调用配额是多少，这些都应该纳入你现有的权限管理体系，而不是单独放开一个口子。

6.3 部署选项和合规清单

最后给一张简单的核查清单，可以直接拿去做选型时的一轮问答：

这张表逐项过完，能帮你把合规风险从"上线后爆发"提前到"选型时规避"。数据边界这件事，永远是越早确认成本越低。

最后说一个我在真实项目里的体会。去年有个团队让我帮他们选一个做对话摘要的模型，对方一开始笃定榜单第一准没错，我坚持按这五件事过了一遍：业务实测发现它在口语化聊天记录上漏要点，成本核算发现他们的高并发场景会把预算烧穿，长上下文压测在 16K 附近就开始丢细节。后来换了一个按照真实场景评测通过的方案，上线后稳定性好得多。从那次以后我更加确定，选大模型这件事没有标准答案，只有适不适合你的业务、你的成本结构、你的数据边界。把这五件事逐条过完，你听到的就不是别人的推荐，而是自己拿真实数据得出来的结论。