文心一言、GPT-3.5与GPT-4应用测评对比：统一调用层与任务分流

简介：围绕文心一言、GPT-3.5 与 GPT-4 展开的横向测评报告，面向关注大模型能力边界的产品经理、算法研究者与 AI 应用开发者，帮助判断国内外模型在真实任务中的差异，作为模型选型依据。测评覆盖常识问答、文学与图像创作、演绎与情感逻辑推理、主体信息抽取、数学解题、代码生成，以及 AI 助手、售后客服、办公协同、产品推荐、诗词理解等落地场景，逐项给出三大模型的表现对比与结论，并附投资建议与风险提示。资源为单个 PDF 文档，压缩包约 6.49MB，含完整目录与十余组回答对比图表，可直接按章节检索翻阅。已有 3636 人学习下载。适合作为模型能力评估、技术选型汇报与团队内部分享的参考材料，也可用于快速了解文心一言在分词、代码识别等环节的短板与优势场景。

1. 三个模型放在同一条流水线上比，才看得出差距在哪

某团队做过一次很典型的对比：同一套 prompt，把 model 字段从 GPT-3.5 换成 GPT-4，再把文心一言接进来，跑几十条客服问答，最后结论是“贵的不一定好”。复盘才发现，三家的 temperature 一家设 0.7 一家设 0，有一家的 system 消息被塞进了 user 里，还有一家的输出被 max_tokens 截断了一半。这套对比从第一天起就不是在比模型，是在比谁的参数更凑巧。

文心一言、GPT-3.5 及 GPT-4 的应用测评对比，难的不是把三个 API 跑通，而是把调用语义拉平，让分数差异只来自模型本身。下面按我自己的顺序写：先定评测口径，再搭统一调用层，再分维度看指标，最后是五个我踩过的坑。

2. 评测口径先确立：三个模型不是一个档位上的同类项

2.1 文心一言、GPT-3.5 与 GPT-4 的能力档位差在哪

很多人把这三个名字当成“高中低三档”来理解，这个心智模型在做选型时会直接把你带偏。GPT-3.5 走的是快和便宜的路线，短指令、单轮、格式明确的活它干得不差，但任务一旦需要多步推导、跨段落对齐，或者约束条件超过三条，稳定性掉得非常快。GPT-4 相对它的提升不在“什么都懂一点”，而在复杂约束下的稳定性和长上下文里指代不丢——你把五个字段、三段输出格式、两个禁止项写进 prompt，GPT-3.5 通常会满足前三个然后崩在第四个，GPT-4 能满足到第五个，代价是延迟和单价。

文心一言的差异不在同一条轴上。中文语料密度高，本地化表达、口语改写、中文格式类输出（商品标题、通知公告、短视频脚本）往往更自然，读起来更像人写的；但它同样会在复杂多步推理上出现“前半段对、后半段开始编”的情况，英文任务和冷门领域知识必须单独测，不能靠中文表现外推。更关键的一点是，同一个产品的不同版本之间，接口字段、返回结构、默认参数都可能变，跨版本差异有时比跨家差异还大。

所以评测报告里必须写死版本标识，并且把每次返回体里的 model、version 这类字段原样存下来。我一般会要求脚本把“请求参数 + 原始响应 + 版本字段”三样一起写入记录文件，否则两周后你回头看分数，根本说不清是哪一版跑出来的。这是最容易省掉、也最不该省的一步。

还有一个反直觉的地方：不要试图得出“谁更强”的结论。选型评审上真正会被追问的是“在我这三类任务上，用哪个模型、贵多少、掉几个点”，而不是一个总排行榜。把评测按任务分型切开，是后面所有工作的前提。

2.2 用 60 条任务搭一个能跑通的最小评测集

我不建议一上来搞几百条。60 条左右足够暴露格式崩坏、拒答、截断这三类硬伤，而且人工复核成本还在能承受的范围内。下面这张表是我常用的分配方式，条数和通过线都可以按业务改，但结构别动。

采样来源决定评测价值。最省事的做法是用公开榜单题，但那批题模型大概率见过，分数会虚高得离谱，你上线后会发现真实表现差一截。我一般从自己的业务日志里抽真实输入，脱敏后再用，这样评出来的分数跟线上分布是一致的。分层也要做：简单 30%、中等 40%、困难 30%，简单样本用来验证“不该出错的地方别出错”，困难样本用来区分档位。

黄金答案（参考答案）只能人工写。抽取类任务让两个人各写一份，冲突字段拉出来讨论；格式类任务不用写答案，直接写校验器；代码类任务直接写单元测试，测试就是答案。这三类里，格式类和代码类的边际成本最低，优先做。

2.3 打分规则：0/1/2 三档比百分制好用

0 分是不可用：事实错误、格式崩掉、答非所问、拒答。1 分是可用但要人工改一处以上。2 分是可直接入库。三档的好处是判定边界清楚，两个人打出来的分容易对齐；百分制的问题是“85 分和 82 分有什么区别”，讨论十分钟也说不清，最后变成凭感觉。

能用代码判的绝不人工判。JSON 能不能解析、字段名对不对、字数有没有超、代码能不能过测试，这些全部规则化。人工只判“语义是否正确”“人设有没有漂”这类没法自动化的部分，并且必须配一张判定细则卡，比如“字段值正确但单位缺失记 1 分”“事实正确但多给了一个未被要求的字段记 2 分”。细则卡不写，两个人的评分一致性会低到没法用。

一致性怎么验证：抽 20% 的样本双人评，算一致率，低于 0.8 就回去改细则，而不是继续评。这一步麻烦，但省掉它，后面所有分数都是黑匣子。

最后强调一个指标选择上的问题：三档分的均值意义不大，真正致命的是 0 分率。一个模型平均分 1.5 但 0 分率 25%，另一个平均分 1.3 但 0 分率 5%，线上该选后者。0 分意味着用户会直接看到错误答案，1 分意味着有人兜底能改，两者的业务代价差一个数量级。

3. 把三个模型塞进同一个调用层：统一封装的代码骨架

3.1 用一个 chat() 接口屏蔽三家的参数差异

差异主要在三处：请求体的字段名、鉴权头的写法、返回体里取正文的路径。我用一张声明式的配置表把这三点收进数据里，主流程只认统一参数，不写 if-else 分支。下面这段是骨架，各家 SDK 都能用，但为了让三家的调用完全对称，我这里直接用 HTTP 请求，避免 SDK 在超时、重试上的默认行为不一致。

import os, json, time, requests # 三家只在这张表里不同，主流程不出现任何分支 PROFILES = { "wenxin": {"label": "文心一言", "url_env": "WX_BASE_URL", "key_env": "WX_API_KEY", "dialect": "wx"}, "gpt35": {"label": "GPT-3.5", "url_env": "G35_BASE_URL", "key_env": "G35_API_KEY", "dialect": "oai"}, "gpt4": {"label": "GPT-4", "url_env": "G4_BASE_URL", "key_env": "G4_API_KEY", "dialect": "oai"}, } # 字段名映射：以各家官方文档为准，这里只放结构，值按文档填 FIELD_MAP = { "oai": {"max_tokens": "max_tokens", "stop": "stop"}, "wx": {"max_tokens": "max_output_tokens", "stop": "stop"}, } def build_payload(dialect, messages, temperature, max_tokens, stop=None): body = {"messages": messages, "temperature": temperature} body[FIELD_MAP[dialect]["max_tokens"]] = max_tokens if stop: body[FIELD_MAP[dialect]["stop"]] = stop return body def chat(model_key, messages, temperature=0.0, max_tokens=2048, timeout=60): p = PROFILES[model_key] url = os.environ[p["url_env"]] key = os.environ[p["key_env"]] payload = build_payload(p["dialect"], messages, temperature, max_tokens) headers = {"Content-Type": "application/json", "Authorization": f"Bearer {key}"} t0 = time.time() r = requests.post(url, headers=headers, data=json.dumps(payload), timeout=timeout) r.raise_for_status() return {"raw": r.json(), "latency_ms": int((time.time() - t0) * 1000)}

逻辑说明：PROFILES只放“怎么连”，FIELD_MAP只放“字段叫什么”，两者都是纯数据，新增一个模型只要加一行配置。chat()里不判断是哪一家，只按dialect去查表，这样后面加并发、加重试只在chat()外面包一层，不会改到三个分支。

参数说明：temperature统一在 0～1 之间取值，不要去“换算”另一家的 0～2 区间——你只需要在自己定义的口径内取三家都能接受的交集，评测期固定 0，线上再按业务调。max_tokens必须显式传，绝不依赖默认值，因为默认值往往是“能给出多少给多少”，一跑长文就被截断。timeout建议 60 秒起步，长文抽取场景给到 120 秒。

取正文的地方也要收口。返回体里正文的路径三家不同，写一个extract_text(model_key, resp)，按model_key查表取。这个函数是唯一知道返回结构的地方，别让它散落在评测脚本里。

提示：真实项目里不要在代码里硬编码 base_url，也不要把 key 写进配置文件，用环境变量或配置中心注入，评测脚本和线上服务共用同一套读取逻辑。

3.2 三个必调参数和两张对照表

评测期的参数和线上参数目标是相反的：评测要的是“可复现”，线上要的是“可接受”。混在一起调，就会出现“线上调完觉得不错，评测分数又对不上”的情况。

第二张表是版本与响应记录，别嫌麻烦，只所有结果都落进去：

finish_reason这个字段是很多人忽略的关键线索。同一批题里，如果某一家length的比例明显偏高，那不是模型差，是你的max_tokens给少了。如果不记录它，你会得到“这家模型答不完整”这种错误结论。

3.3 批量跑评测脚本：并发、重试、结果写入

单线程跑 60 条、三家、每题平均 5 秒，一轮下来十五分钟，改一次 prompt 就要等一刻钟，人是会烦的。并发到 4～8 是合理的起点，再往上要先确认账号级配额。

import hashlib, json, random, time from concurrent.futures import ThreadPoolExecutor, as_completed RETRYABLE = (429, 500, 502, 503, 504) def run_one(model_key, case, out_fp, done_ids): if case["id"] in done_ids: # 断点续跑：已完成的直接跳过 return last_err = None for attempt in range(4): try: resp = chat(model_key, case["messages"], temperature=0.0, max_tokens=case.get("max_tokens", 2048)) rec = { "id": case["id"], "model": model_key, "prompt_hash": hashlib.sha256( json.dumps(case["messages"], ensure_ascii=False).encode()).hexdigest()[:12], "latency_ms": resp["latency_ms"], "raw": resp["raw"], } out_fp.write(json.dumps(rec, ensure_ascii=False) + "\n") out_fp.flush() return except requests.HTTPError as e: code = e.response.status_code if code not in RETRYABLE: # 参数错、鉴权错，重试没意义 raise last_err = e except requests.Timeout as e: last_err = e time.sleep((2 ** attempt) + random.random()) # 指数退避 + 抖动 raise RuntimeError(f"{case['id']} 重试耗尽: {last_err}") def run_suite(model_key, cases, out_path): done = set() try: # 断点续跑：先读已有结果 with open(out_path) as f: done = {json.loads(l)["id"] for l in f if l.strip()} except FileNotFoundError: pass with open(out_path, "a") as out_fp, ThreadPoolExecutor(max_workers=6) as pool: futs = [pool.submit(run_one, model_key, c, out_fp, done) for c in cases] for f in as_completed(futs): f.result() # 有异常就在这里抛出，不要吞

逻辑说明：三条主线是并发、重试、断点续跑。RETRYABLE只放限流和服务端错误，参数错和鉴权错必须立刻抛出来，否则你会重试四次然后得到同一个 400，白等十几秒。退避用2**attempt加随机抖动，避免多个线程同一时刻撞上去。断点续跑的意义在于：跑 600 条时中途挂一次，不用从头再来。

参数说明：max_workers从 4 开始，观察错误率，稳定再加；单账号的并发上限和每分钟 token 上限是两个不同的限制，长文任务往往先撞 token 限。flush()每次写完都调，进程被杀时少丢数据。结果文件用 jsonl，一行一条，方便后面用 pandas 直接读。

这里有个血泪经验：三个模型的结果务必分文件写，别写进同一个文件靠字段区分。某次我把结果合成一个文件，中途某个模型报错重跑了一遍，最后统计时同一批 id 出现两次，分数直接算歪，排查了半小时才想起来是重复行。

4. 分维度实测：中文指令遵循、长文抽取、代码生成各看什么指标

4.1 中文指令遵循：格式约束是最先崩的地方

这一维度不需要模型有多聪明，只需要它听话。测试方法是给一段百字左右的输入，要求按固定结构输出，比如“输出 JSON，只包含 title、summary、tags 三个字段，summary 不超过 40 字，不要输出任何解释”。看着简单，实际跑下来分化非常明显。

import json, re FENCE = re.compile(r"^```(?:json)?\s*|\s*```$", re.M) def strip_fence(text): """剥掉模型爱加的 markdown 围栏和‘好的，以下是’前缀""" text = FENCE.sub("", text.strip()) text = re.sub(r"^(好的|当然|以下是)[^\n]*\n", "", text) return text.strip() def check_format(text, required=("title", "summary", "tags"), max_summary=40): t = strip_fence(text) try: obj = json.loads(t) except json.JSONDecodeError: return {"ok": False, "reason": "json_invalid"} missing = [k for k in required if k not in obj] if missing: return {"ok": False, "reason": f"missing:{missing}"} if len(str(obj["summary"])) > max_summary: return {"ok": False, "reason": "summary_too_long"} return {"ok": True, "reason": "pass"}

逻辑说明：strip_fence只做两件确定的事——剥围栏、剥固定前缀，不要写过于激进的正则去“猜”JSON 边界，那样会把正文里的花括号也吃掉，造成假阳性。check_format返回结构化原因，是为了后面能按失败类型分组统计，而不是只看到一个总合法率。

参数说明：max_summary=40要跟着业务要求走，卡得越死区分度越高，但也越容易把“41 字但内容完美”判成失败，所以我一般会同时记一个“超长但其他都对”的中间档，人工抽样看一眼再决定算不算过。

实测里最有价值的一条观察是：GPT-3.5 在这类任务上的失败绝大多数是“多说了话”——JSON 前后加一句“好的，以下是整理结果”，或者把字段名从 summary 改成 摘要。文心一言的失败更多是“自由发挥”，字段名对了但多塞了两个自己加的字段。GPT-4 的失败率低，但延迟明显高一截。这三种失败模式对应的修复手段完全不同：前者靠剥壳和提示词，中者靠更严格的字段白名单校验，后者只能接受或者换更小的模型。

提示词层面有个立刻见效的招：在 system 里写“只输出 JSON，第一个字符必须是左花括号”，比写“不要输出解释”有效得多。这是约束的具体化，不是玄学。

4.2 长文抽取：字段级 F1 比整段相似度靠谱

长文抽取别用 BLEU、ROUGE 那套，字段抽取的输出是结构化的，用整段文本相似度衡量毫无意义。正确做法是逐个字段算命中。

def field_scores(pred: dict, gold: dict): """逐字段算 P/R/F1，字段值做去空格和全半角归一""" norm = lambda v: str(v).strip().replace("：", ":").replace("，", ",") tp = sum(1 for k, v in gold.items() if k in pred and norm(pred[k]) == norm(v)) p = tp / max(len(pred), 1) r = tp / max(len(gold), 1) f1 = 0 if p + r == 0 else 2 * p * r / (p + r) return {"precision": round(p, 3), "recall": round(r, 3), "f1": round(f1, 3)}

逻辑说明：精确率惩罚“多抽”，召回率惩罚“漏抽”，两个一起看才知道模型是保守还是激进。归一化那一步必不可少，中文输出里全半角混用、冒号前后加空格的情况非常普遍，不归一化会凭空多出一堆错误。

参数说明：字段多的时候建议加权，关键字段（金额、日期、编号）权重给高，描述类字段权重给低。加权后的总分更贴近业务感受，但不加权的那份也要留着，用来定位问题。

长文还有个绕不开的工程问题：整篇塞还是先切再合并。我的一般做法是 8k token 以内整篇塞，超过就先按段落切块，每块抽一遍，最后做字段级投票——同一个字段多数块给出相同值就采信，冲突的块单独记下来人工看。投票策略比“取第一个非空”稳，尤其在合同、财报这类前后重复表述多的文档上。

4.3 代码生成：pass@1 的简版测法与三个陷阱

代码维度最省事，因为答案就是可执行的测试。给函数签名加一段说明，让模型补全实现，然后把实现扔进子进程跑单元测试。

import re, subprocess, tempfile, os def extract_code(text): """优先取 ```python 围栏内的内容，没有围栏就整段当代码""" m = re.search(r"```(?:python)?\s*(.*?)```", text, re.S) return (m.group(1) if m else text).strip() def run_tests(code, test_code, timeout=5): src = code + "\n\n" + test_code with tempfile.TemporaryDirectory() as d: p = os.path.join(d, "case.py") open(p, "w", encoding="utf-8").write(src) try: r = subprocess.run(["python", p], capture_output=True, timeout=timeout, text=True) return {"pass": r.returncode == 0, "stderr": r.stderr[-500:]} except subprocess.TimeoutExpired: return {"pass": False, "stderr": "timeout"}

逻辑说明：extract_code先剥围栏，因为模型十次有八次会加；run_tests用临时目录加子进程，把“模型写的代码”和“你的评测脚本”彻底隔离，防止模型输出里的sys.exit()或者死循环把你整个评测跑挂。超时 5 秒足够，函数级题目跑不完就是死循环。

参数说明：timeout别给太小，某些题涉及排序或字符串处理，慢机器上 1 秒会误判。stderr只留最后 500 字符，够定位又不至于把结果文件撑爆。

三个陷阱记一下：模型输出经常自带一段if __name__ == "__main__"的示例，会把你的测试输出搅乱，预处理时删掉；有的模型会import第三方库，测试环境里没有就报 ImportError，这属于模型没遵守“只用标准库”的约束，算失败不算环境问题，但要在报告里单独列出来；还有模型会改写函数签名，测试直接报参数不匹配，这类要在提示词里把签名原样贴一遍并且标注“签名不得改动”。

4.4 成本与延迟：把 token 与延迟数据放在同一张表里

最终决策靠的往往不是分数，是这张表。单价按各家官方价目填，别抄别人的，会变。

要注意的是输出 token 占比。抽取类任务输入长、输出短，成本主要由输入决定；改写类任务输入输出差不多长；代码生成输出可能比输入还长，成本结构完全不同。所以单次成本要按任务分型算，混在一起算平均值会得出错误结论。

延迟看 P95 而不是均值。均值 1.2 秒、P95 8 秒的服务，用户体验是“偶尔卡死”，均值再好看也没用。评测阶段就把 P50 和 P95 一起记下来，上线时才有依据做超时和降级策略。

5. 评测翻车排查：五个“模型不行”其实是脚手架不行

评测跑完发现某家分数低得离谱，先别下结论。我遇到的情况里，至少一半的问题出在自己的脚手架上。下面五条按出现频率排。

5.1 现象：GPT-4 得分反而低于 GPT-3.5

原因几乎总是截断。GPT-4 的回答更啰嗦、更完整，同样给 512 的max_tokens，GPT-3.5 刚好说完，GPT-4 说到一半被切掉，后面的格式校验、字段抽取全部失败。解决方法是把max_tokens按任务输出上限给足，同时统计finish_reason里length的占比，超过 5% 就说明额度不够，回去改参数重跑。顺手记一条：所有“大模型不如小模型”的反常结论，先查截断，再查温度，最后才怀疑模型。

5.2 现象：文心一言大量返回拒答或空内容

原因是内容安全策略的触发阈值和另两家不在一个位置。你的评测集里如果有医疗、金融、法律这类敏感领域的正常业务问句，很容易被拦下来，finish_reason会给出类似内容过滤的标识。解决办法不是去绕过，而是把“拒答”当成一个独立类别统计，和“答错”分开看；同时检查评测集里是不是混进了表述上确实有风险的样本，该剔除的剔除。报告里如实写“该类目下拒答率 X%”，这本身就是选型要的信息。

5.3 现象：并发一开高，某一家错误率突然飙到 30%

原因是账号级限流，而且三家的限制维度不一样，有的按请求数，有的按 token 数，长文任务往往先撞 token 限。解决办法是给每个模型配独立的并发池和令牌桶，不要三个模型共用一个线程池；退避策略用指数加抖动；把 429 单独计数并打点，超过阈值自动降并发。这一条不做，跑长文评测基本没法看。

5.4 现象：JSON 解析失败率 30%，人工看每条都“差不多是对的”

原因是模型在 JSON 前后加了说明文字或 markdown 围栏。解决办法是加剥壳函数，并且做一次“修复重试”：把原始输出连同“只输出合法 JSON”的要求再发一次，成本很低但能把合法率拉高不少。如果某家提供了强制结构化输出的能力，评测时就用上，但要在报告里注明“已启用结构化输出”，否则和没启用的模型比不公平。

5.5 现象：同一批题跑两次，分数差了十个点

三个原因按概率排：temperature 没锁死；厂商侧模型静默更新；评测集顺序影响了你自己的缓存逻辑。解决办法是评测期 temperature 固定 0，把响应体里的版本字段全部存下来，并对评测集算一个整体 hash 写进报告头。跑两次分数不一致时，先比 hash，再比版本字段，最后比温度，能省掉大量无谓的争论。

注意：这套排查顺序建议固化成 checklist，贴在评测脚本的 README 里。人一旦看到低分，第一反应永远是“这家不行”，而不是“我哪里配错了”。

6. 从评测到上线：按任务分流比死磕一个模型更划算

评测做完，最常见的错误决策是“选一个总分最高的，全量切过去”。实际跑起来你会发现，高分模型在简单任务上纯属浪费，低分模型在困难任务上照样崩，两头不讨好。我一般做成两级路由：先用便宜的模型跑，用可判定的信号决定要不要升级。

信号怎么选，取决于任务。格式类任务用“校验器是否通过”当信号，不通过就升级重跑一次；抽取类任务用“字段缺失数”当信号，缺两个以上就升级；开放问答没有硬信号，就用“回答长度异常短”“出现不确定表述”这类弱特征，配合抽样人工看。升级比例控制在 15% 以内，成本才划得来。

def route(case, cheap="gpt35", strong="gpt4"): r1 = chat(cheap, case["messages"], temperature=0.0) text = extract_text(cheap, r1["raw"]) ok = check_format(text)["ok"] if case["type"] == "format" else True if ok: return {"model": cheap, "text": text, "escalated": False} r2 = chat(strong, case["messages"], temperature=0.0) # 只在必要时花这份钱 return {"model": strong, "text": extract_text(strong, r2["raw"]), "escalated": True}

这段代码的重点不是逻辑复杂，而是escalated这个字段必须打点。上线后每天看升级率，它突然从 10% 涨到 40%，要么是流量分布变了，要么是便宜那家悄悄更新了版本——两种都需要你立刻知道。另外别忘了缓存，同样的输入在评测和线上会重复出现，缓存命中率做上去，比换模型省钱快得多。

最后说个我自己的教训。早期做这类对比，我特别执着于“跑出一个结论”，花两周把表格填得漂漂亮亮，结果评审会上被问了一句“这个结论三个月后还成立吗”，答不上来。后来我改了做法：评测脚本和评测集当成长期资产维护，每季度重跑一次，版本字段一比，变化自然就出来了。模型在变，你的评测口径也得跟着校准，一次性的对比报告没有第二次生命。这套东西搭起来大概两三天，但省下的是后面每一次选型争论的时间。

希望帮到你。

本文还有配套的精品资源，点击获取