ERROR401——大模型评测作业

目录

• 第一部分 调研，评测
  • 一、评测目标与统一实验设计
    • 1.1 为什么选择购车决策
    • 1.2 模型与实验条件
    • 1.3 固定车型数据
    • 1.4 三个场景及预期结果
    • 1.5 自动化流程与评分规则
  • 二、大模型 1：GPT
    • 2.1 功能、使用过程与体验分析
    • 2.2 用户采访记录
    • 2.3 自动化测试与 GPT 响应样例
    • 2.4 GPT 阶段结论
  • 三、大模型 2：DeepSeek
    • 3.1 功能与使用体验
    • 3.2 用户采访与改进意见
    • 3.3 自动化测试
    • 3.4 DeepSeek 阶段结论
  • 四、结果对比、边界案例与方案优选
    • 4.1 量化结果汇总
    • 4.2 两个重点边界案例
    • 4.3 改进方案与备选方案比较
• 第二部分 分析
  • 五、程序、软件工程与商业模式
    • 5.1 三个层次的理解
    • 5.2 开发时间估计
    • 5.3 同类产品对比与选型
  • 六、软件工程建议与 BUG 原因分析
  • 七、市场概况及现实生活影响
    • 7.1 市场规模与增长
    • 7.2 直接用户与潜在用户
    • 7.3 对现实生活的影响
  • 八、产品规划：能够解释“为什么不推荐”的购车助手
    • 8.1 NABCD 分析
    • 8.2 优先级与验证计划
• 九、代码、实验材料与参考资料

第一部分 调研，评测

一、评测目标与统一实验设计

1.1 为什么选择购车决策

购车推荐很容易生成一段“听起来有道理”的回答，却未必能够帮助用户作出正确选择。预算可能被误解成裸车价，车型可能混淆年份或配置，新增需求也可能在多轮对话中被遗忘。因此，本次评测重点考察：模型是否能持续遵守约束、准确使用给定数据，并在确实没有合适车型时明确说明无解。

我们将“语言表达是否流畅”和“推荐是否可核验”分开评价。即使回答详细，只要最终车型超过预算或座位不足，任务仍然失败；多款车型都符合要求时，模型选择不同车型则不直接算不稳定。

1.2 模型与实验条件

本次实际比较两条调用链的任务表现：GPT采用用户确认的官方Codex CLI，DeepSeek采用官方Chat Completions API。早期计划的GPT-4.1 API方案没有执行，不对应本文GPT成绩。

共同数据和评分规则使约束遵守情况可以对照，但两条调用链不是完全相同的模型实验环境。Codex带额外指令和进程启动，且采用外显历史重放；DeepSeek使用原生API消息。参数、测试日与并发也不同。本文不把两边耗时或token比值解释为模型速度、成本优势，不将结果外推为行业模型排名。 若要严格比较基础模型，应再统一接口、参数、上下文和调度重跑。

GPT模型文档、Codex非交互模式和DeepSeek官方接口用于核对服务使用方式。

1.3 固定车型数据

为避免实时价格、搜索结果和配置差异干扰模型能力对比，本次基础实验使用 8 条教学模拟车型数据。下列名称均为题设名称，不对应真实汽车商品；年份与配置也是实验字段。数据构造日期为 2026 年 11 月 6 日，来源为本实验自行设定。

统一价格口径： 模拟全款总支出＝模拟裸车价＋题设固定附加费用。单位为万元人民币，费用不代表真实税费，不另计优惠、补贴或贷款。续航单位为 km，属于模拟综合续航字段，不对应 CLTC、WLTC 或真实道路结果。

BEV 表示纯电，PHEV 表示插电混动，HEV 表示非插电油混。不同动力的模拟续航不能据此推导真实车辆的能耗与使用成本。对于未提供的保值率、故障率或口碑，模型应说明数据不足。

1.4 三个场景及预期结果

在调用模型之前，先固定场景与规则。每个任务包含五轮：初步推荐、需求补充、继续补充或修改、参数对比、最终决策。不同任务新建上下文，同一任务保留完整对话。

预算变更具有明确语义：S2 第三轮之后，以 23 万元替代此前的 26 万元。合理更新推荐不属于前后矛盾；继续使用被替代预算才属于约束保持失败。

1.5 自动化流程与评分规则

配套 Python 程序完成以下流程：读取车型与场景→按固定随机种子打乱任务顺序→逐轮请求模型服务（GPT经CLI，DeepSeek经API）→解析候选列表→抽取结构化参数表→保存最终选择→执行规则评分→输出原始 JSON、CSV 与 Markdown 汇总表。

为减少自然语言表格解析的歧义，两模型统一输出 JSON。comparison 数组是一张结构化表，每个对象是一行；程序将其保存在原始记录中，便于后续转成博客表格。基础实验没有实现工具调用，因此不设置工具正确性得分。

messages = [{"role": "system", "content": shared_system_prompt}]
for user_turn in scenario_rounds:
    messages.append({"role": "user", "content": user_turn})
    reply = call_model(messages)
    messages.append({"role": "assistant", "content": reply})
    save_raw_and_parse(reply)
# 每个独立任务重新创建 messages；不把上一任务的回答带入下一任务。

上面是正文流程示意，完整可运行实现见材料包中的 benchmark.py 与 benchmark_codex.py。接口参数与上下文消息形式参考 OpenAI Chat Completions 文档 和 DeepSeek Chat Completions 文档。

综合分是可重复的规则指标，不能代替全部质量判断。例如“约束状态填写正确”只代表显式状态正确，仍须用推荐合规检查验证实际行为；理由是否充分、是否夹带未经支持的口碑结论，则由人工查看原始回答。人工复核意见单独记录，不事后改动已固定的机器评分规则。

本次不预填人民币或美元成本。若需要货币比较，应另记测试当日价目、币种、缓存命中及账单口径；不同 tokenizer 的 token 数也不等于完全相同的信息量。

二、大模型 1：GPT

2.1 功能、使用过程与体验分析

本次实际使用的是官方 Codex 命令行产品，复用本机已有登录，没有重新注册账号，也没有把网页登录体验写成 API 体验。程序通过标准输入提交固定车型和对话历史，从 JSONL 事件读取回答与用量。实际操作包括确认登录、五轮连通性试测、修正传输设置、执行正式批次及检查记录。

连接预检中，默认 WebSocket 出现多次超时，随后转到 HTTPS 才返回响应。该预检中途结束，保留为未完成批次，不计入正式 9 组任务。之后仅在测试命令内将传输设为 HTTP/SSE，未修改用户全局配置；一次五轮连通性试测通过后，再冻结正式输入运行 9 组。正式批次没有挑选、替换或删掉失败任务。

实际结果展示： 下图来自本地实验报告页面，内容由保存的真实 CLI 记录生成，不是 ChatGPT/DeepSeek 官网聊天截图。完整逐轮原文可在附件中查看。

GPT 正式实测报告页面

打开本地 GPT 实测报告

GPT实测记录.html

2.2 用户采访记录

采访对象与需求

使用过程与观察

访谈拟先安排受访者完成S1城市通勤任务，再检查S3无解场景。开始时只介绍数据为教学模拟、预算采用全款总支出，不提前给出正确车型。

在这一示例中，亮点是可以逐条追加条件，看到候选如何变化；困难是JSON适合程序处理，却需要用户理解字段含义。正式记录时，应补充具体操作、帮助次数和实际反馈，不能把这里的示例过程直接当成已发生事实。

访谈对话草稿

叶宇恒： 你觉得这个流程解决了什么问题？

陈予安： “以前我会先找几款车，再自己逐项看参数。这个流程能先根据条件缩小范围，我再核对剩下的车，思路比较清楚。”

叶宇恒： 你能直接判断推荐是否可信吗？

陈予安： “还不能。我至少要核对总价、座位和续航。这里是模拟数据，所以能对照表检查；如果换成真实车型，我还想知道是哪一年的配置、价格什么时候更新。”

叶宇恒： 最需要改进的地方是什么？

陈予安： “希望旁边一直显示我当前的条件。尤其是改预算以后，我想确认系统真的用了新预算。参数表也可以直接写‘总支出’，不用让我猜字段名。”

改进意见

可将示例建议归纳为三点：持续展示当前硬约束；把技术字段转换成清晰的中文标签；为参数显示年份、配置、价格口径和来源日期。它们与本次产品分析相呼应，但是否来自实际用户，仍应在真实采访后确认。

2.3 自动化测试与 GPT 真实回答

正式批次为 20261108T073601833115Z，9 组任务均保留五轮记录，共 45 轮。每组任务重新创建历史，每轮只提交截至当前的消息，不向模型提供程序计算的可行集或后续问题。先保存原始响应，再独立执行评分。

python benchmark_codex.py --workers 2

benchmark_codex.py 通过官方 CLI 发起真实请求；任务级 JSON 保存用量和评分，roundN_request.json保存输入历史，roundN_events.json保存 CLI 事件。CLI 没有返回原生停止原因，使用cli_turn_completed记录回合完成，native_finish_reason保留未知，没有伪称服务返回stop。

S1 城市通勤，最终回答原文：

最终选择青禾E+（C02）。其全款总支出18.5万元，不超过19万元；为5座纯电车型；模拟综合续航520km，达到450km下限；车长4450mm，不超过4500mm；配置AEB。该车型是固定教学模拟数据中唯一满足全部硬约束的车型，未放宽任何条件。

证据：GPT_S1_1，第5轮

GPT_S1_1.json

S2 预算修改，最终回答原文：

最终选择教学模拟车型C05山行P7插混七座标准版：7座、PHEV，模拟综合续航1050km且配置AEB，全款总支出23.0万元等于预算上限，满足全部硬约束。原26万元预算已被23万元替代，C06全款总支出25.5万元，超过新预算，不能继续作为候选或最终推荐。

证据：GPT_S2_2，第5轮

GPT_S2_2.json

S3 无解场景，最终回答原文：

最终无解。固定教学模拟数据中，满足至少7座、插电混动且配置AEB的车型仅有C05和C06，其全款总支出total_wan分别为23.0万元和25.5万元，均超过18.5万元预算上限。因此预算、座位、动力和AEB这组硬约束无法同时满足。

证据：GPT_S3_1，第5轮

GPT_S3_3.json
以上是正式调用记录中的原文，不再使用早期写作会话生成的示意回答作为测评证据。

2.4 GPT 实测结论

在本次固定教学数据、提示词及Codex外显历史重放条件下，GPT的结构规则检查成功9/9，综合均分100/100；S1、S2、S3各3次的分数标准差均为0。助手对45轮理由逐条复核，未发现与固定数据明确冲突的事实断言，详见GPT理由复核GPT理由复核.md。这不是独立真人盲评，也不是用户采访。

这说明本次调用链能够完成所设的需求追加、预算更新、参数复制和无解判断。数据只有8辆模拟车、每场景仅3次，条件清晰且规模小，测试容易出现满分上限效应；不能据此保证复杂真实购车任务或所有模型版本都可靠。与DeepSeek的对照还受到接口和上下文差异限制，详见1.2及4.1。

三、大模型 2：DeepSeek

3.1 功能与使用体验

本次实际使用DeepSeek官方API，没有把未登录的网页端写成已完成体验。先通过官方模型列表确认deepseek-flash可用，完成S1一个五轮试调用，再按冻结配置执行正式9组任务。试调用独立存档，不进入正式成绩。

程序逐轮发送需求，保存候选、参数表与最终选择；API返回JSON能够直接进入评分器。45轮正式请求均正常返回，解析成功，结束原因均为stop。请求原文、完整API响应、HTTP状态、时间和可用的请求标识分别保存；鉴权头不写入交付材料。

我的改进建议是将预算、总支出、比较运算和排除理由绑定到同一条证据，而不是只验证候选ID。对普通用户，界面还应显示当前硬约束及每辆车的排除原因。

双模型真实实验记录报告

图为真实API/CLI记录生成的本地实验报告，不是DeepSeek或ChatGPT官网界面；报告全文双模型实测记录.html链接到逐轮原始证据。

3.2 用户采访与改进意见

为便于比较，拟安排陈予安继续体验DeepSeek，使用相同的教学数据与S1、S3任务，约20分钟。实际采访时应记录入口、模式、日期及起止时间。由于第二次体验已经熟悉任务，上手更快可能来自练习，不能直接认为产品更易用。

使用过程与观察

访谈对话草稿

叶宇恒： 相同任务在这个入口中是否容易完成？

陈予安： “我已经知道要分几步输入，所以第二次比较熟悉。候选和表格都能看明白，但只看最后有没有推荐车型，还不足以判断整个回答是否正确。”

叶宇恒： 对于这段已有记录中的解释，你怎么看？

陈予安： “它说无解，这个结论没问题。但是远帆P5要20.2万元，预算只有18.5万元，就不能说它在预算内。前面如果没对照数据，我可能会把这句话直接看过去。”

叶宇恒： 这种问题会怎样影响你使用？

陈予安： “我会把它作为初步整理工具，再自己检查。希望每辆车为什么被排除都列出来，例如‘超预算1.7万元、少于7座’，这样更容易核对。”

叶宇恒： 如果没有满足条件的车，你希望系统怎么办？

陈予安： “先明确告诉我没有，再问我愿不愿意改哪一条。不要直接替我提高预算，也不要让人以为只改座位数就一定能找到合适的车。”

改进意见

基于示例对话，可以拟写以下建议：将排除原因拆成可核验的条件；显示预算与总支出的比较；需求放宽须经用户确认；对于无法证实的信息明确说明数据不足。真实采访后，应保留受访者自己的表达，删除其未提出的意见。

3.3 自动化测试与真实响应

正式批次为20261109T133942732274Z，运行命令如下；密钥从进程环境变量读取，正文展示的调用命令、交付代码和日志不包含鉴权值。

python run_deepseek.py

S1最终轮原文：

C02为纯电、5座，模拟综合续航520km满足至少450km，车长4450mm满足不超过4500mm，配备AEB，全款总支出18.5万元未超过19万元预算，全部硬约束均满足，因此最终选择C02。

证据：DeepSeek_S1_1，第5轮

DeepSeek_S1_1.json
S2最终轮原文：

最终选择C05：全款总支出23.0万元，未超过23万元上限；7座满足家庭出游；PHEV符合插电混动要求；模拟综合续航1050km达到至少1000km；并配置AEB。C06虽同样满足7座、PHEV、续航1100km和AEB，但总支出25.5万元，超过变更后的23万元预算，因此不能继续采用。

证据：DeepSeek_S2_2，第5轮

DeepSeek_S2_2.json

S3第2次、第3轮原文（含实际错误，未修饰）：

无解：严格按全款总支出total_wan判断，预算上限18.5万元，且须至少7座、插电混动、配置AEB。固定数据中7座插混车型山行P7总支出23.0万元、山行P7+总支出25.5万元，均超预算；预算内插混车型远帆P5总支出20.2万元也超预算且仅5座。无合规候选，不虚构低价配置，不放宽任何硬约束。

证据：DeepSeek_S3_2，第3轮DeepSeek_S3_2.json。其中“预算内”与20.2万元超过18.5万元的事实冲突；该轮仍正确返回空候选，因而不被当前结构规则扣分。

3.4 DeepSeek 实测结论

DeepSeek本轮9/9任务的结构规则检查通过，参数表及最终选择均符合固定条件。但助手复核发现 4/45轮理由含明确事实错误，涉及1/9任务：S3第2次的第1、2、3、5轮将远帆P5或其余插混车型误称为“预算内”。第4轮表述正确，不计入错误。详见DeepSeek理由复核DeepSeek理由复核.md。

这体现了“结构化决策正确、解释局部错误”的区别。原先固定的100分规则主要检查候选、约束状态、格式和参数表；不在看到结果后临时改权重或重算分数，另列理由错误作为补充观察。该观察来自小样本助手复核，不是行业层面的通用准确率，也不能直接归因于无法观察的内部模型机制。

四、结果对比、边界案例与方案优选

4.1 双模型量化结果汇总

两模型都完成9组、45轮正式任务；以同一固定规则计分。理由复核另外呈现，避免把评分器的覆盖范围误当成全部质量。

两模型场景得分与成功率

各自调用链的观测量： GPT平均任务耗时74.44s，DeepSeek为7.94s；平均输入/输出/总token分别为GPT 104135.4/695.1/104830.6，DeepSeek 9499.7/744.1/10243.8。

分别呈现两条调用链的任务耗时

这些耗时包含不同的封装、进程、网络和调度条件，token包含不同上下文开销，只作为各自运行记录，不据此判断基础模型速度、费用或性价比。本次不把token换算成账单金额。

规则分同为100只能说明本测试未通过这些自动指标区分二者；理由复核则发现了真实差异。每场景n=3，标准差为0也不等于没有不确定性。更有效的后续评测应扩大数据、加入复杂冲突，并在实验前为理由定义可计算的事实检查。

证据：GPT评分表scores.csv、DeepSeek评分表]scores.csv、GPT理由复核GPT理由复核.md、DeepSeek理由复核DeepSeek理由复核.md。

4.2 失败与边界案例分析

案例B1：DeepSeek解释错误，但结构化结果正确。

S3第2次的预算为18.5万元。第2轮原文称：

预算内的插混车型远帆P5仅5座。

固定数据中C03远帆P5总支出为20.2万元，20.2＞18.5，不能归入预算内。第3轮又写出“预算内插混车型远帆P5总支出20.2万元也超预算”，句内分类与比较结果相互矛盾。相同错误出现在该任务第1、2、3、5轮；第4轮正确。见任务完整记录DeepSeek_S3_2.json和第3轮API原始响应DeepSeek_S3_2_round3_response.json。

实际影响是解释可能误导用户理解排除原因；若用户进一步只放宽座位数，仍无法买到18.5万元内的插混车。模型始终正确给出无解、空候选和null最终选择，当前评分器也没有检查reason中的每个预算分类，所以原规则分保持100。我们将其单列为理由质量失败，不把它隐去或事后改成结构评分失败。

案例B2：预算修改与等号边界，双方均处理正确。

S2第三轮预算明确从26万元改为23万元。两模型三次均在修改后排除C06（25.5万元），保留C05（总支出恰为23.0万元）。这说明本轮能采用用户的新需求，且没有把“≤23”误作“＜23”。见GPT_S2_2，第3—5轮GPT_S2_2.json
及DeepSeek_S2_2，第3—5轮DeepSeek_S2_2.json。推荐随明确变更而更新，不属于前后矛盾。

预检中另有工程问题： GPT连接预检曾出现WebSocket超时后回退HTTPS，首份预检响应把数值预算写成嵌套对象。未完成预检与正式批次分开；正式运行前采用HTTP/SSE并明确字段类型，详见原始预检记录。不能把连接失败直接解释为模型能力不足。

4.3 改进方案与备选方案比较

针对B1，我选择“结构化事实校验＋证据绑定的解释生成”。原有程序只验证候选与参数表，还应让每条预算判断都对应车型ID、比较字段、阈值及运算结果，例如C03.total_wan=20.2 > budget_wan=18.5，再基于这些结果生成理由。

选择B，是因为本次错误针对确定的数字比较，已有数据足以由程序判断；模型审核可作为辅助，但不替代确定性检查。

验证计划： 保留本轮原文，事先建立含“预算内/外”对照、等于阈值、只超0.1万元、无解、预算变更及多项放宽的断言集。对A/B使用相同模型和调用链、相同任务量，比较理由事实错误率、违规断言拦截率、误拦截率及新增耗时；另检查结构正确率是否下降。该方案尚未实现，不预填改进百分比。

第二部分 分析

五、程序、软件工程与商业模式

5.1 三个层次的理解

对模型平台，我们能够观察的是接口行为、文档和实际结果；对自身测试程序，则应承担更完整的实现与质量责任。发生解析错误时，不能不经检查就归因于模型。

5.2 开发时间估计

这里估计的是 两名具备 Python 和 API 基础的开发者，在现有模型服务上构建课程级评测原型，不包含从零训练基础模型，也不冒充被测平台的真实研发工期。以下为计划估算，非实际工时。

两人并行也不能简单把总人日除以二，因为场景、接口和结果分析存在先后依赖。课程原型可按约一周安排，成熟商用系统还需车型数据授权、报价更新、运维和更多质量验证，不能沿用这一工期。

5.3 同类产品对比与选型

第一部分显示：在这套清晰的小型固定数据任务中，两条调用链都能正确筛选、更新预算并识别无解，结构规则没有区分出胜负。对于需要结构化候选列表的教学原型，二者在本轮都满足要求，但仍应保留确定性校验。

当用户更依赖解释时，本轮GPT的45轮理由未发现明确数据冲突，DeepSeek有4轮出现预算分类错误，因此在本次设置下，GPT解释更一致；这只是受限观察，不能排除调用封装、提示上下文和参数的影响，不能推导为所有GPT或DeepSeek版本的整体排名。

对真实产品，我更看重“正确数据＋外部校验＋可追溯理由”的组合，而不是仅凭本轮满分选择模型。需要成本或低延迟选型时，应将模型置于相同接口与时间条件下重新测量，再结合实际计费；本文不以现有耗时差作性价比结论。

六、软件工程建议与 BUG 原因分析

B1已有实际API原文，错误不来自博客转述：数据中的20.2万元正确，响应理由却写“预算内”。结构化候选仍正确，因此输出中的事实分类与解释是一条独立质量链路。该观察支持加强理由检查，但无法从黑箱记录确定模型内部根因。

下表区分已观察到的事实与排查假设；其他类型是工程诊断方向，不冒充本轮都实际发生过。

对团队协作，我建议按“接口适配、数据场景、评测复核”划分责任，修改任一输入都记录版本；在正式实验前冻结评分规则。测试过程中不要为了提高某模型分数，单独补发提示或偷偷删掉失败任务。若需要重新运行，应建立新的批次并说明原因。

七、市场概况及现实生活影响

7.1 市场规模与增长

不同报告对大模型服务、API 与智能体市场的定义不同，应分别列明口径。以下使用报告机构发布的估计和预测，不将其写成当前已实现收入，也不将两个市场直接相加。

资料查阅日期为 2026 年 11 月 6 日。上述 LLM 报告包含多种部署和应用，不能直接当作“大模型 API 市场”的精确规模；Agent 市场也不限于购车助手。本稿没有取得可核验且口径统一的 API 独立市场规模，因而采用更宽口径作为背景并保留这一限制。

7.2 直接用户与潜在用户

CNNIC 的 5.15 亿是中国生成式 AI 用户背景数据，不能视为本产品直接用户，更不能视为付费用户。本产品当前尚未开展外部用户招募，暂无真实活跃或付费用户统计。

若后续估算潜在市场，可用“目标地区年度购车需求人数×愿意使用线上助手的比例×可触达比例”建立模型，再通过公开数据和访谈校准。比起直接套用行业总用户数，这种估算更接近产品实际能够服务的人群。

7.3 对现实生活的影响

我认为大模型正在降低获取和整理信息的门槛。过去用户需要反复阅读参数表、询问销售并自行比较，现在可以先用自然语言描述需求，由助手生成一份待核验的候选清单。这种价值也适用于学习、编程和日常计划。

但信息组织能力增强，也会让错误更有说服力。购车案例中，一处预算口径或配置错误就可能改变判断；用户若只看语言是否自信，会放大这种影响。产品应帮助用户检查信息，而非要求用户盲目信任结论。

对软件工程学习而言，重点也从“能不能调通一次模型”转向“如何明确需求、定义质量、处理失败并持续回归”。人的工作仍包括核验数据、理解真实需求、确认重要变更以及承担最终判断。

八、产品规划：能够解释“为什么不推荐”的购车助手

8.1 NABCD 分析

我计划在现有模型之上构建“约束可确认、数据可追溯、无解可解释”的购车助手。核心价值是减少用户在预算、配置和推荐理由之间反复核对的负担。

创新点是将“推荐理由”与“排除理由”同时作为产品输出，尤其把“当前没有合适车型”作为正常结果。用户可以主动调整某一约束，再看到候选集如何变化，而不必重新阅读整段聊天记录。

8.2 优先级与验证计划

首轮验收以受控场景的约束正确性为主。后续进入真实购车场景前，应接入可靠车型数据、扩大用户调研，并按真实使用情况补充地域报价和配置差异；教学模拟数据不支持现实车型推荐结论。

九、代码、实验材料与参考资料

【代码仓库链接】

两模型各9次正式任务，合计18次、90轮；烟雾测试及未完成连接预检单独存档，不混入正式样本。API鉴权信息不写入博客、配置示例或实验附件。

参考资料：

1. 本次课程作业要求。
2. OpenAI：GPT-6.1 Sol。
3. Codex非交互模式。
4. DeepSeek官方接入说明。
5. DeepSeek Chat Completions。
6. CNNIC：我国生成式人工智能用户规模实现翻一番。
7. Grand View Research：LLM市场。
8. Grand View Research：AI Agents市场。
9. 《构建之法》相关章节及NABCD分析方法。