软件工程实践——大模型评测作业：购车决策任务中 DeepSeek-V4-Pro 与 GLM-4-Flash 的量化对比

目录

一、前言

随着大语言模型的发展，软件已从简单的规则交互演进为以自然语言为核心、具备多轮对话能力的智能应用。在工程实践中，如何设计自动化测试场景来客观、量化地评估模型性能，直接决定了"选哪个模型、怎么集成、如何迭代"这些工程决策。

本次作业中，我编写 Python 代码构建了一个「购车决策」多轮任务环境，对两个大模型进行了量化评测：

选择理由：覆盖「旗舰推理增强模型 vs 免费通用模型」两种类型，观察两类模型在约束遵守、上下文管理与成本上的差异——这正是作业建议的对比方式。

第一部分 调研，评测

1.1 大模型1：DeepSeek-V4-Pro

1.1.1 使用体验

产品介绍：DeepSeek 是深度求索公司的大模型产品，提供网页版（chat.deepseek.com）与开放平台 API（api.deepseek.com）。本次被测模型 DeepSeek-V4-Pro 是其旗舰模型：1M 上下文、最大 384K 输出、支持 JSON Output 与 Tool Calls，默认开启思考模式（推理过程中输出 reasoning_content）。计费方式为按 token 用量计费（输入 4.5 元/百万 tokens、输出 13.5 元/百万 tokens，空闲时段·缓存未命中口径，2026-11-09 官方价格页）。

注册与使用过程：通过手机号注册并登录网页版，随后进行了与自动化测试同主题的多轮购车咨询（预算 20 万、城市通勤，随后补充动力/油耗与新能源偏好要点），DeepSeek 给出了候选车型与更新后的推荐，并展示了思考过程。

优缺点分析：

用户改进意见（综合自体验与采访）：希望提供"快速模式"开关让用户在延迟与质量间取舍；希望思考过程支持折叠摘要。

用户采访（2026-11-10 晚·宿舍，约 20 分钟，已征得对象同意，姓名/人脸做匿名处理）：

• 采访对象背景：软件工程专业大三学生，平时经常用 AI 写代码，但对"AI 购车推荐"这类功能没有概念；
• 为什么选 TA / TA 的需求：TA 代表了"熟悉 AI 工具的普通开发者、而非 AI 从业者"这一群体——我想了解这类用户第一次接触 AI 决策辅助功能时的真实感受；TA 的需求是替家里人做购车参考。

采访过程：TA 在两个产品的网页版上分别独立完成了同一个购车咨询任务（"预算 20 万左右，主要家用代步，偶尔跑高速，推荐几款车并说明理由"），从打开页面到获得回答全程无需帮助，两个产品都能流畅上手（实际观察）。TA 使用的产品栏目均为网页版对话主界面：

• 问题与亮点：TA 未遇到明显使用困难（实际观察）；TA 认为**智谱的回答"更加周到，考虑到的车型或实际情况更丰富"**，两个产品回答都很流畅。
• 改进建议（TA 原话转述）：DeepSeek——回答可以更多元化一点、更贴近生活一点；智谱——回答时配上图片或更现实的具体例子会更有说服力。
• 补充观察：TA 表示平时基本不用 AI 做选车/购物类决策，但"对 AI 的推荐一般会相信，不过还是会检查它的消息来源，防止片面理解或歧义"。这个态度很有代表性：大模型推荐要赢得真实用户，光"回答自信"不够，还需要来源可查、例子可信——与我们自动化测试中发现的"推荐违反硬约束"问题相互印证。

1.1.2 自动化测试

实验设计（详细设计见代码仓库 README，此处为关键要素）：

• 固定车型数据集：20 款车型（教学模拟数据，价格为指导价口径，来源日期 2026-11-09），在每次任务开始时通过系统提示词完整提供给两个模型；
• 3 个购车场景，每场景含预算、使用需求、至少一条预算外硬约束、预期结果与评分规则：

• 多轮流程：① 购车意图+约束，要求 JSON 候选清单 → ②③ 逐条输入购车要点 → （场景A插入变更轮）→ ④ Markdown 表格对比 → ⑤ 最终唯一推荐+≥3条理由；
• 重复运行：每场景独立运行 3 次，同任务内保留上下文、不同运行重新开始；
• 评分规则：六个维度各 0-10 分，全部规则化自动判定、逐条留痕（判定标准见 1.3 节表格）。

测试结果（DeepSeek-V4-Pro）：

失败/边界案例（2 个）：

1. 场景A·第3次运行——违反车长硬约束：最终推荐「海豹06 DM-i」，其理由中自己写明"车长4.83m"，却未核对 ≤4.8m 的硬约束（超 0.03m）。这是典型的"边界值疏忽"：差异只有 3cm，模型把注意力放在了预算、能耗、空间上。
2. 场景B·第3次运行——排除后复推：在第 3 轮中明确说明"汉兰达因……降为备选"，最终推荐却仍是汉兰达，且未对前后变化给出解释。多轮一致性扣 2 分。

其余 7 次运行全部满足全部硬约束；18 轮候选清单与表格参数 100% 在车型库内（防幻觉满分），表格参数与库内数据全部一致。

成本与延迟实测：单任务平均延迟 126173 秒（思考模式单轮 12-52 秒）；单任务平均费用 0.200.27 元；9 次任务总费用 2.26 元，平均每任务 2.0 万输入/1.3 万输出 tokens。

1.1.3 结论

DeepSeek-V4-Pro 在约束遵守、多轮一致性、稳定性上表现优秀（9 次任务 8 次全部合格），防幻觉能力满分级（全部推荐均在给定车型库内、参数零编造）。主要短板是延迟与成本：思考模式带来 2-4 倍的单轮延迟，是免费模型的 2-3 倍费用。适合对正确性要求高的场景（购车、理财、医疗咨询等约束密集型任务），不适合低延迟交互场景。

1.2 大模型2：GLM-4-Flash

1.2.1 使用体验

产品介绍：智谱 AI（BigModel）是国内大模型厂商，GLM-4-Flash 是其完全免费的通用模型，支持多轮对话、工具调用，通过 open.bigmodel.cn 开放平台 API 调用；网页端产品为智谱清言（chatglm.cn）。

注册与使用过程：同样通过手机号注册登录智谱清言网页版，用相同的问题进行了多轮购车咨询，并对比了两家回答风格的差异。

优缺点分析：

用户改进意见：免费档限速应在控制台有更明显的提示；回答应主动逐条核对用户给出的硬约束。

用户采访：采访内容与过程记录见 1.1.1（同一次采访覆盖两个产品）。

1.2.2 自动化测试

（实验设计、场景、评分规则与 DeepSeek 完全一致，保证公平对比。）

测试结果（GLM-4-Flash）：

失败/边界案例（3 个，选典型列出）：

1. 系统性预算违反（7/9 次）：场景C 三次最终推荐分别为小米SU7（21.59万）、领克03（15.98万）两次——全部超出 14 万预算；场景A 第2次运行推荐理想L8（32.98万），超预算 80% 以上。有趣的是，这些车型清一色是网络热门车型。
2. 变更后未调整（场景A·第3次）：需求变更为"每周 300km 长途且无充电条件"后，最终仍推荐纯电 Model 3（续航 606km < 650km 门槛），且超出预算。
3. 多约束同时违反：场景A 第2次运行的理想L8 同时违反预算（32.98>18）与车长（5.08>4.8）两条硬约束。

值得肯定的是：GLM-4-Flash 同样零幻觉（所有推荐与表格参数均在库内且数值一致）、指令格式遵循满分。

成本与延迟实测：官方免费（0 元），9 次任务总费用 0 元；但免费档存在排队：单轮实测 9-30 秒，单任务平均延迟 96~133 秒——与 DeepSeek 思考模式的端到端延迟在同一量级。单任务平均仅 0.2 万输出 tokens（DeepSeek 的 1/6），回答非常精简。

1.2.3 结论

GLM-4-Flash 的格式遵循与防幻觉能力出色、完全免费、输出精简，适合大批量、低价值的简单任务。但在约束密集型决策任务中推荐合理性不足（预算遵守率 2/9），不适合直接用于"给真实用户做购车推荐"这类高后果场景。免费档的排队延迟也需在工程集成时纳入考虑。

1.3 横向对比与可视化

六维度评分汇总（0-10 分，三个场景均分；判定标准：推荐合理性=最终推荐与各轮候选满足预算+硬约束情况，指令遵循=JSON清单/对比表/最终推荐格式合规，防幻觉=推荐与参数是否在库，多轮一致性=变更调整/排除复推/需求覆盖，稳定性=3次运行合格率与指标波动，成本延迟=单任务平均延迟与费用，详见评分规则）：

【图1：雷达图 radar_dims.png】

【图2：推荐合理性分组柱状图 bar_recommend_validity.png】

【图3：延迟分组柱状图 bar_avg_task_latency_s.png】

【图4：费用分组柱状图 bar_avg_task_cost_yuan.png】

结论声明：以上对比仅适用于本次数据、场景与实验设置，不代表行业整体排名。每场景仅重复 3 次，样本量较小，结论存在局限。

1.4 改进与方案比较

针对评测发现的「模型推荐违反硬约束」问题（GLM 7/9 次、DeepSeek 1/9 次），提出改进方案：

• 选定方案：约束硬校验层（Constraint Guard）——在 LLM 之前增加结构化约束提取（把"预算18万/车长≤4.8m"解析为规则），用规则引擎在车型库上先做硬过滤，LLM 只在合格候选集内推荐，并要求输出"逐条约束核验清单"。
• 备选方案 A：提示词工程加固（在提示词中重复强调约束、要求先列约束再推荐）。成本最低，但本次实验系统提示词已明确要求"逐条核对约束"，DeepSeek 与 GLM 仍分别出现 1 次和 7 次违反，说明纯提示词方案不能根治；
• 备选方案 B：微调模型。成本高、需要标注数据，对课程场景不现实。

选择理由：方案 1 用确定性的规则兜住模型的不可靠部分，把"推荐"与"校验"解耦，是工程上标准的两阶段架构；且改动集中在推理管线外围，无需重训模型。
验证方法：复用本次 18 个任务的输入在加装 Constraint Guard 的管线上回归，对比违规率（预期降为 0）与推荐质量指标。

第二部分 分析

2.1 开发时间估计

实际开发比预估顺利的地方：两家的 API 都是 OpenAI 兼容格式，适配层可以复用；评测流程无人工环节，批跑完全自动化。比预估困难的地方：① 推理模型的 reasoning_content 会计入 max_tokens，最初设置的输出预算导致回答被截断；② CSDN 博客的图片与目录锚点需要逐项验证。

2.2 同类产品对比排名与选型建议

（仅基于本次评测，不含其他未测产品。）

程序 = 算法 + 数据结构：两家模型的架构差异（DeepSeek V4-Pro 的思考模式/更长推理链 vs GLM-4-Flash 的轻量快速架构）直接体现在"约束遵守 vs 延迟成本"的取舍上；
软件 = 程序 + 软件工程：两家都提供了完整的开放平台能力（API 网关、密钥管理、用量计费、文档、并发限速）——这是它们从"模型"成为"软件服务"的关键；
软件企业 = 软件 + 商业模式：DeepSeek 走"低价高性能"的 token 计费路线，智谱走"免费模型获客 + 高级模型/企业服务变现"路线，本次评测中 GLM 的免费策略确实有效降低了开发者试用门槛。

2.3 软件工程方面的建议

基于评测中发现的问题，对两个平台提出工程改进建议：

1. 提供"约束校验"类系统能力：GLM 若在 API 侧提供类似结构化输出校验或"自检轮"，可大幅降低约束违反率（本次 7/9 是显著的可复现缺陷）；
2. 免费档限速透明化：GLM 免费档排队导致单轮 9-30 秒延迟，建议在控制台实时展示限速状态与预估等待；
3. 思考模式的可观测性：DeepSeek 建议提供思考过程长度控制（如"简要思考"档），让用户在延迟与质量间取舍；
4. 评测工具链：建议两家提供官方评测套件（测试集管理、回归对比、成本报表），降低第三方评测的重复建设成本。

2.4 BUG存在的原因分析

引用第一部分案例，从工程视角分析（以下对模型内部原因的推断均为假设）：

工程侧结论：本次实验的提示词、数据、解析程序均可复现（全部留痕在仓库），上述缺陷在给定输入下稳定出现，不属于解析程序或数据问题——这也正是 1.4 节提出 Constraint Guard 的理由：不指望模型本身完美，用确定性组件兜底。

2.5 市场概况

• 大模型 API 市场：据 IDC 报告，2025 年中国大模型应用市场规模预计达 232.5 亿元（同比增长约 87%），模型 API 与平台服务是其中增长最快的部分（引用来源见参考文献，数据以报告原文为准）；
• 智能体/Agent 应用市场：Gartner 预测到 2028 年 33% 的企业软件将包含 Agentic AI 能力（2025 年预测，2024 年不足 1%），购车助手、导购 Agent 等垂直场景是典型落地点；
• 直接用户：中国开发者群体数百万级（仅 CSDN 注册用户即超千万），企业客户与 C 端用户则是潜在的更大市场——本次评测中 GLM 用免费模型获客正是瞄准开发者入口；
• 竞争格局：国内已形成"免费轻量模型（获客）+ 旗舰付费模型（变现）+ 云平台（锁定）"的三层打法，与 2.2 节的分析一致。

2.6 产品规划（NABCD）

如果我是被测产品的新任项目经理，我会做这个功能——「购车决策守护模式（Constraint Guard 购车助手）」：

• N（需求）：本次评测直接证明——真实用户在购车咨询中给出预算与硬约束后，主流模型仍会给出超预算/违规推荐（GLM 7/9、DeepSeek 1/9）。这是"推荐不可信"的硬痛点；
• A（做法）：在对话管线中增加结构化约束提取 + 车型库硬过滤 + 强制"逐条约束核验清单"输出，模型只在合格集内推荐；
• B（好处）：违规推荐率预期降为 0（确定性组件保证）；用户信任度提升；每次推荐可追溯核验记录，规避"AI 瞎推荐"的信任危机；
• C（竞争）：现有通用对话助手（包括两家自身）均无硬校验层；汽车之家等垂直产品的筛选器又不支持自然语言多轮交互。两者之间的空白正是本功能的位置；
• D（演示）：本作业的 18 个任务与评分脚本就是现成的回归基准（baseline），改造后可立即量化演示改进幅度。

2.7 大模型对现实生活的影响

通过本次作业我切身的感受：大模型显著降低了信息获取与决策辅助的成本（一次购车咨询从"翻论坛几小时"变成"几分钟多轮对话"），但它同时是一个**"说得自信但不一定对"的顾问**——旗舰模型也会在边界值上犯错，免费模型会系统性地忽视预算。这意味着：① 普通用户需要学会"给约束、看核验"的用法；② 软件工程师的责任是把校验与兜底做成系统能力，而不是把可靠性寄托于模型自觉；③ 大模型正在重塑"软件开发"本身——本次作业的评测代码、评分规则、可视化全部由人机协作完成，未来"会写评测、会做兜底"将是一线工程师的核心能力。

三、实验材料与代码

• 代码仓库：https://codehub.devcloud.cn-north-4.huaweicloud.com/fbe64c8bfe7e44c798795d4df6c06ecf/102400216 （本项目位于 sw-hw3-llm-eval 目录，含完整代码：数据集、场景定义、评测主流程、评分脚本、可视化脚本）
• 实验材料：车型数据 data/cars.json、场景与评分规则 data/scenarios.py、原始记录 results/raw/（18 个任务全部轮次，脱敏）、评分明细 results/score_details.json、汇总 results/scores.csv、图表 results/figures/
• 密钥安全：API Key 全部经环境变量/本地 .env 读取，未出现在代码、仓库或本博客中

Tips

1. 推理模型的输出预算：DeepSeek 思考模式的 reasoning_content 计入 max_tokens，最初我把 max_tokens 设小导致回答被截断——接推理模型要把输出预算放宽（本次用 8192）；
2. 免费模型的排队：GLM-4-Flash 免费档实测单轮排队 9-30 秒，"免费"不等于"快"，批量任务要预留时间预算或错峰；
3. 省钱：本次 DeepSeek 全程仅花费 2.26 元（18 任务 × 平均 0.2 元）；固定系统提示词可命中输入缓存进一步省钱（本次按未命中口径保守估算）；
4. 评测工程习惯：规则化打分 + 逐条留痕（本次 18 任务每个判定都有明细 JSON），比主观印象可靠得多，也方便博客引用与复核；
5. 发博客前：检查目录锚点能正确跳转、图片外链可访问、API Key 确认没混进任何截图或代码粘贴块。