企业官网建设流程全解析

前阵子发了一条朋友圈，配了张 DeepSeek V3 的跑题截图，说“某本老牌 NLP 案例书里的一道逻辑推理题，它解出来了，结果让我有点意外”。底下好几个做算法和工程的朋友都来问：你是不是准备抛弃 OpenAI 了？其实谈不上抛弃不抛弃，就是手头正好翻到一本压箱底的 NLP 案例集，里面全是那种"教科书例题 + 真实数据"的经典场景。我干脆把这批案例整理成一个临时测试集，从文本分类、命名实体识别、情感分析，到多步推理和长文本摘要，挨个喂给 DeepSeek V3 和 OpenAI 的接口，做了一轮还算严谨的横向压测。

这篇文章就记录一下完整的压测过程：怎么选案例、怎么设计提示词、怎么控制变量，以及最终那些出乎意料的结果。想换模型又怕踩坑的朋友，可以直接参考我的做法，自己重复一遍。

1. 压测从哪来：一本书和一组老考题

1.1 为什么拿书里的案例当测试集

很多人压测大模型喜欢用网上现成的 benchmark 榜单，或者随手编几个 prompt 问一问。我的经验是，这两者都有问题：榜单题太"标准"，模型可能已经见过；随手编的题又不稳定，很难量化对比。这本书里的案例属于中间态——它是一批公开多年的经典 NLP exercise，网上讨论很多，但又不是那种标准基准测试题，模型未必被针对性地"背过答案"。

我选的这批案例，共同点是"任务边界清楚、评价标准客观"。比如文本分类就明确给出标签集合，情感分析就明确要求输出 positive/negative/neutral，实体识别就要求按固定格式返回 span 类型。这类题目特别适合做横评，因为不需要你主观评判，对就是对，错就是错，跑分和统计都很干净。

适合拿来做模型压测的测试集，应该满足三个条件：第一，任务类型覆盖要广，不能只测对话聊天，要看分类、抽取、推理、生成这几类基础能力；第二，难度要有梯度，既要有送分题，也要有那种需要多步推理的题；第三，数据最好带标准答案，这样准确率能算出来，而不是靠感觉。这本书的习题结构正好满足这三点，于是我以它为蓝本，组了一个 20 道题的 mini 测试集。

1.2 测试任务与评价维度怎么定

我最终从书里挑了四类任务，每类 5 道题，一共 20 道：

• 文本分类：新闻标题分类，标签有科技、财经、体育、娱乐、时政，共 5 个类别。
• 命名实体识别：从事件描述中抽取机构名、人名、地点和日期，输出格式要求为 JSON 数组。
• 情感分析：中文电商评论的正负中三分类，其中掺了一部分网络用语，像"绝绝子"这类表述。
• 多步推理与长文本摘要：包括逻辑推理题和一份模拟会议纪要的摘要提取任务，后者同时考验长上下文处理和要点归纳。

评价维度我定了五个：准确率（直接对照标准答案）、单次平均响应耗时、输出稳定性（同一题跑三次，结果是否一致）、token 开销（调用日志里自动统计）、以及一个"人工体验分"，由我主观判断生成结果是否自然、符合任务习惯。

这里特别提醒一句：压测大模型不要只看准确率。模型的稳定性其实非常关键，同一个输入跑三次，每次答案都不一样，这种模型在生成环境里很难让人放心。我把稳定性单列为一个维度，后面实际测试中，这个指标确实帮了大忙。

2. 压测环境与公平性设计

2.1 模型版本与调用方式

为保证可比性，我全程通过 API 调用，统一走官方接口，不使用任何第三方中转或代理。OpenAI 这边用的是当前主力对话模型，DeepSeek 这边用的是 V3 的官方 API 版本。两个模型都关闭了联网搜索，避免模型"现查资料"干扰判断。

参数上，我统一设置了 temperature = 0.3、max_tokens = 2048，其余参数保持默认。这里解释一下为什么 temperature 设成 0.3 而不是 0：完全设 0 虽然输出更确定，但会让模型在某些开放式任务上"过度收敛"，反而不像真实使用场景；设到 0.3 是工程里常见的折中，既保留了一点多样性，又不至于太飘。

prompt 设计上，我做了一个统一的模板，所有题目只用这个模板换题目内容，不针对单个模型做任何单独优化。模板长这样：

你是资深 NLP 工程师。请完成以下任务，严格遵循输出格式要求。 任务类型：{task_type} 输入内容：{input_content} 输出要求：{output_requirement} 请直接输出答案，不要输出多余解释。

所有请求都通过 Python 脚本批量发送，记录原始返回内容和 token 用量，再统一做离线评分。脚本很简单，我把它放在后面实操部分，方便你自己跑。

2.2 公平性最容易翻车的几个细节

做模型对比，最大的坑其实不在模型本身，而在"不公平的测试条件"。

第一个坑是上下文污染。如果你的 prompt 里有之前对话的历史记录，两个模型会给出完全不同的表现。我这次所有请求都是独立对话，每条 prompt 里只放当前这一道题，绝对不复用会话。

第二个坑是输出格式解析。有的模型很听话，严格按 JSON 输出；有的模型会画蛇添足，在结尾加一句"希望这个答案对你有帮助"。如果你用严格解析器直接跑，后者会被判错。我这次的处理是：先用宽松解析去取代码块和 JSON 部分，解析不到才判错，这样对比的是模型真实能力，而不是解析器的鲁棒性。

第三个坑是温度参数不一致。有些模型默认 temperature 是 0.7，你手动调成 0.3 以后，它的输出风格会有很大变化。如果你只调了一个模型，没调另一个，那对比结果就没有参考价值。

第四个坑容易被忽略：相同题目的中文输入，在两个模型 API 的分词器下，token 消耗差异很大。这直接影响"成本"指标。我这边统计的是 API 返回的实际 usage 字段，不是按字符数估算，这样成本对比才准确。

3. 逐题实测：四个任务的详细结果

3.1 文本分类：DeepSeek 和 OpenAI 打平，但失败样本很有意思

文本分类我用的数据是 30 条新闻标题，5 个类别。实测下来，两个模型准确率都在 28/30 左右，基本持平。但仔细看了失败的样本，差异立刻出来了。

OpenAI 错的两题里，有一道是把"某科技公司发布新一代芯片，股价大涨"误判为财经，而不是科技。单看这句话，确实有歧义：里面出现了"股价大涨"这种明显的财经信号。DeepSeek 对这道题判对了，它给出的分类是科技，理由是核心主谓结构描述的是"公司发布芯片"，股价只是附带结果。

反过来，DeepSeek 也有自己的问题：它对"某城市举办国际马拉松赛事，数万人参加"这条标题，给出了"体育"和"时政"两个标签，违反了单标签分类的约束。这种"多输出一个标签"的错误，在工程对接时比判错类别更麻烦，因为它会让下游的规则逻辑直接崩掉。

所以这里有个很有意思的结论：两个模型的准确性相当，但错误模式完全不同。OpenAI 偏向"权重决策"（哪个关键词权重高就往哪边倒），DeepSeek 偏向"语义决策"（更在意句子的主结构和逻辑重心）。你的业务对哪种错误容忍度更高，决定了你适合用哪个模型。

表：文本分类任务结果对比

3.2 命名实体识别：DeepSeek 在简称识别上有明显优势

命名实体识别我用了一组模拟的事件新闻描述，要求抽取机构全称、机构简称、人物、地点、日期，并按 JSON 数组格式返回。评分标准是严格匹配：实体文字完全一致才算对，多一个空格都算错。

结果有点意外：DeepSeek V3 的准确率明显高于 OpenAI，主要差距出在"机构简称"这一类。比如原文里先写"某通信技术有限公司（下称某通信）"，后面再用"某通信宣布发布最新一代基站"。OpenAI 会把后面的"某通信"错误地识别成人物，或者干脆漏掉；DeepSeek 能准确关联前文的全称和简称，输出为同一实体的两个 mention。这正是实体识别里最难做的"指称消解"场景。

我在想这里面的原因：DeepSeek 在中文语料上的训练量更大，擅长捕捉"全称+括号简称"这种中文新闻里常用的写作模式。如果换成纯英文语料，优势未必存在，所以这个结论仅限于中文实体识别场景。

不过 DeepSeek 在实体识别上也有一个缺点：它对"日期"的识别过于激进。原文写"截至去年底"，它会输出具体的去年年份，而不是保留原文的"去年底"。从 NLP 严格评测的角度，这种"过度推断"算错的，因为原文没有给出确切年份。这也是工程对接时要注意的：如果你想保留原文字面，约束规则里得写死"禁止补充原文字面之外的信息"。

表：命名实体识别任务结果对比

OpenAI 这边唯一的明显优势是：它的 JSON 输出格式几乎从不翻车，20 道题全部一次解析成功。DeepSeek 有 4 次输出带了额外的解释文字，需要后处理才能提取 JSON。在要求"零容错"的生产环境里，这个差距是实打实的。

3.3 情感分析：网络用语这一关，DeepSeek 表现更贴近真实场景

情感分析我特意加入了网络用语和口语化表达。比如"这家店的拌面真是绝绝子"，"客服态度？？？"，"拿到手发现是坏的，家人们谁懂啊"。这些句子在标准情感词典里几乎找不到特征词，模型只能靠对语境的整体理解来判断。

两个模型的准确率都有浮动，但 DeepSeek 对网络用语的敏感度明显更高。"绝绝子"这种词它准确判为正向，"家人们谁懂啊"这种反讽句它能结合"坏的"这个事实判为负向。OpenAI 在新词、反讽、语气词这些维度上显得"过于正经"，会对"谁懂啊"这种表达产生困惑，倾向于判成中性。

这里我得补一句公道话：OpenAI 的模型在英文情感分析上非常可靠，但在中文互联网语境下，它对"最新网络热词"的更新速度明显慢于 DeepSeek。原因也好理解，DeepSeek 在国内语料上训练和迭代都更贴近中文互联网的现实。

真实业务里的情感分析，数据不会像教科书那么干净。我带过不止一次标注团队，最深的体会是：模型对"反讽"的理解能力，往往比准确率数字更能决定项目能不能落地。情感分类的准确率差 5 个点，后处理规则可能要费十倍的功夫去补。

表：情感分析任务结果对比

3.4 多步推理与长文本摘要：这是差距最大的一项

多步推理我选了书里的一道经典逻辑题："五个人参加比赛，分别获得一至五名。已知 A 不是第一，B 比 C 高两个名次，D 的名次在 E 之前，且 E 不是最后一名。问你能确定的名次有几个？" 这道题需要模型同时维护多个约束条件，做联合推理，是区分模型推理深度的一道好题。

第一次跑的时候，OpenAI 给出了完整的推理过程，最终得出了正确答案，但过程里有一个约束条件它写错了，因为结论正好对，这个错被掩盖了。DeepSeek 第二次跑的时候，不仅结论对，推理过程的每条约束也都和题目对应上了。这个细节在自动评分里根本看不出来，是我逐行读日志才发现的。

更明显的差距出现在长文本摘要上。我用书里配套的一段约 4000 字的模拟会议纪要，要求模型提炼出"决定事项、待办事项、风险点"三类要点，并限定输出 300 字以内。DeepSeek 的摘要里，所有关键数字和负责人分配都准确对应原文；OpenAI 有一处把"预算控制在 50 万以内"误写成"控制在 100 万以内"，属于事实性错误。

这种"数字失真"在长文本摘要任务里其实挺常见的。模型读长文容易丢失对精确数值的记忆，尤其是数字在文中后半段出现时。从结果看，DeepSeek 在超长上下文的信息保持能力上，这一轮的表现要好于 OpenAI。

4. 三个意外发现：比比分更有价值的细节

4.1 意外一：DeepSeek V3 的"中文语感"是隐藏优势

整体跑完之后，我回看所有日志，发现 DeepSeek 在中文任务上的表现不只是准确率略高，而是它在"语义密度"的把控上更贴近中文表达习惯。比如文本分类里"股价大涨"那题，它能把科技和财经两个信号做权重区分，而不是简单看哪个词在训练语料里更常见。这说明它在中文语境下学到的不是表层词汇对应关系，而是更深层的语义结构。

对做中文 NLP 项目的人来说，这个差异比任何榜单分数都重要。很多中文任务，尤其是涉及评论、舆情、内容理解的项目，用 OpenAI 的模型总是感觉"差一口气"，不是准确率的问题，是它生成的结果一看就不是中文母语者会有的表达方式。这个小测试让我确认了：DeepSeek 在中文语感上确实下了功夫。

4.2 意外二：推理的"过程稳定性"比结论更重要

多步推理任务里，OpenAI 虽然得出了正确结论，但推理过程有一个约束条件写错了。这个错非常隐蔽，不仔细读根本发现不了。DeepSeek 的推理过程则完全忠实于原文,每个约束都处理到位。

这让我反思了一件事：自动评估只看最终答案会漏掉大量信息。真实业务里，模型给出的中间过程往往是要展示给用户看的。如果过程有瑕疵，就算结论对了，用户对产品的信任感也会打折。这一轮 DeepSeek 的表现让我对它刮目相看，不是因为结论对，而是因为过程每一步都站得住。

4.3 意外三：成本账本远比想象中复杂

我把 20 道题各跑了两轮，统计了两边的 token 开销和账单。结果 DeepSeek 的账单大概是 OpenAI 的十分之一左右。但这只是表象，仔细看 token 消耗明细就会发现：DeepSeek 在中文 prompt 上的 token 计数通常略高，因为它对中文的分词方式更细，会把长词拆成多个 token。不过即便 token 数偏多，最终单价还是让它保持明显成本优势。

这里给个小提醒：评估成本不能只看"价格表上的单价"，要看"实际完成同一任务的总费用"。有的模型单价贵但 token 消耗少，有的模型单价便宜但输出废话多。最合理的做法就是我这次采用的：同一批任务，统计真实账单，然后折算单位任务成本。这样才是对项目预算负责的态度。

5. 实操避坑：解码我的压测流程与调试心得

5.1 五个最容易干扰对比的因素

做模型压测，控制变量永远是第一位的。我整理了这次踩过和预判到的五个坑，每个都是真实经验，不是理论推演。

第一个是请求并发。如果你同时发 20 个请求，不同模型的限流策略会导致部分请求排队，响应时间会被严重拉长，速度对比失真。正确做法是串行请求，确保每个请求都在相同条件下发出。

第二个是缓存干扰。有些接入层会自动缓存相同请求的返回结果，如果你重复跑"稳定性测试"，第二次以后拿到的都是缓存数据，稳定性结果会虚高。解决办法是每次请求加一个随机参数，或者用不同模型去重后的触达不同接口节点。

第三个是上下文长度差异。长文本摘要任务里，相同字符数的输入，两个模型实际感知的"信息密度"不同。如果你把 4000 字全部塞进 prompt，OpenAI 可能有截断，DeepSeek 可能还在窗口内。要先确认两边的上下文窗口配置一致。

第四个是输出风格差异。有的模型喜欢先解释再给答案，有的模型直接给答案。如果你的评分脚本只取"答案部分"还好，但如果连解释也计入 token 统计，成本对比就会偏。这里建议在 prompt 里明确"直接输出答案，不要输出多余解释"，并在后处理时把多余解释剔除再统计。

第五个是模型更新窗口。API 背后的模型可能随时升级，你周三测的和周五测的可能不是同一个版本。压测前先记录模型版本号，压测过程中不要跨版本。如果模型版本号不公开，至少保留当时的原始返回日志，方便追溯。

5.2 我的压测流程：5 步复现

如果你也想复现这套压测，可以直接按下面这个流程走，我已经把每一步的要点写清楚了。

第一步：准备测试集。选 15 到 20 道题，覆盖至少 4 类任务，每类 4 到 5 题。题目最好带标准答案，数据量不追求大，但覆盖面要均衡。

第二步：写统一调用脚本。核心逻辑是循环读取测试集 JSON，逐条构造 prompt，调用模型 API，把原始返回和 usage 写入日志文件。脚本不复杂，但一定要把 temperature 硬编码在配置里，防止手动改错。

第三步：先跑一轮"预试"。用测试集里的 3 道题分别验证两个模型能正常返回、格式能解析。这一步的目的是在正式跑之前发现 prompt 模板里的低级问题，比如输出要求写得不清楚导致模型答非所问。

第四步：正式跑三轮。所有请求串行执行，每道题跑三轮，完成"准确率 + 稳定性"双指标收集。三轮之间休息几十秒，避免触发限流。

第五步：离线评分。我建议先用宽松解析提取答案，再对照标准答案打分。评分之后单独看"失败样本"，人工分析错误类型，这一步往往比准确率数字更有价值。

我用这段代码做批量调用，你可以直接替换模型名和密钥使用：

import json import time import openai def run_eval(task_list, model_name, api_base, api_key): client = openai.OpenAI(api_key=api_key, base_url=api_base) results = [] for task in task_list: prompt = build_prompt(task) try: resp = client.chat.completions.create( model=model_name, messages=[{"role": "user", "content": prompt}], temperature=0.3, max_tokens=2048 ) content = resp.choices[0].message.content usage = resp.usage results.append({ "task_id": task["id"], "output": content, "prompt_tokens": usage.prompt_tokens, "completion_tokens": usage.completion_tokens, "latency": time.time() }) except Exception as e: results.append({"task_id": task["id"], "error": str(e)}) time.sleep(2) return results def build_prompt(task): return f"你是资深 NLP 工程师。请完成以下任务，严格遵循输出格式要求。\n任务类型：{task['type']}\n输入内容：{task['input']}\n输出要求：{task['output_format']}\n请直接输出答案，不要输出多余解释。"

这段代码里我特意加了两秒的 sleep，别小看这个停顿，它能有效规避限流。如果你要跑大批量，建议改成指数退避，判断 429 错误后自动等待。

5.3 结果解读的四个层次

拿到日志之后，解读结果要分四个层次，只看最表层的准确率等于白跑。

第一层是"结论层"，就是准确率、耗时、成本这些硬指标，用于快速定位哪边占优。第二层是"错误样本层"，把失败的题挨个看，搞清楚是模型理解错、格式错还是知识错。第三层是"稳定性层"，对比同一道题的三轮输出，看是完全一致、措辞不同但意思一致、还是意思都不一样。第四层是"过程层"，逐字看推理题和摘要题的回答，检查逻辑链条和事实性细节。这四个层次叠加起来，才能形成对模型的完整判断。

我这次的测试里，如果只看第一层，结论是"DeepSeek 小幅领先"；但结合第二层和第三层，结论会变成"DeepSeek 在中文语义理解上更可靠，但格式规范性需要后处理兜底"。这个差异对工程决策的影响完全不同。

6. 到底要不要换？给出我的个人判断

6.1 适合换到 DeepSeek V3 的场景

按这次压测的结果，如果你的项目属于这几类，换成 DeepSeek V3 是划算的。

第一类是中文内容理解项目，比如舆情分析、评论情感识别、中文新闻分类。这类项目对中文语感的依赖度高，DeepSeek 的语义理解能力直接转化成准确率优势。第二类是成本敏感型项目，比如需要通过 API 批量处理大量文本的场景。DeepSeek 单位任务成本低，同样的预算能处理的数据量成倍增加。第三类是长文本摘要和知识密集任务。这次压测中 DeepSeek 在长文档的信息保持上表现更好，如果你需要处理会议纪要、合同、研报这类长文，值得重点测试。

另外，如果你介意数据出境，或者业务上对 API 的国内访问延迟有要求，使用 DeepSeek 在合规和响应速度上也有实际好处。这个因素在技术对比之外，往往比模型本身的分数更具决定性。

6.2 暂时不建议换的场景

如果你是做纯英文任务，或者你的输出格式要求极度严格、没有任何后处理纠错空间，OpenAI 的格式稳定性和英文语感仍然有优势。还有一类场景，如果你的系统已经深度集成了 OpenAI 的生态工具链，比如函数调用、插件、矩阵式的 prompt 管理，迁移成本不能只看模型本身。

我的建议很直接：不要因为一次压测就做全量切换，也不要因为习惯就拒绝新选项。拿你自己的真实任务，按我上面的方法跑一轮，用数据说话，远比听任何人的结论都可靠。

这次测完，最让我意外的不是谁赢谁输，而是大模型竞争的焦点正在从"通用能力"转向"场景适配"。两家的模型在通用任务上越来越接近，但在具体语言、具体任务类型上的分化越来越明显。对做工程的人来说，这不是坏事，意味着你终于可以根据项目需求选最合适的工具了。