Ethan Mollick 这份评测结论的核心其实一句话就能说清楚长程判断类任务比短问答更能检验一个模型的真实能力而新版本模型在这个方向上进步明显。所谓长程判断类任务不是“帮我写一段文案”这种一次生成而是需要模型在较长上下文里完成信息聚合、多步推理、方案对比和最终决策的工作。比如读一份几十页的研究报告后给出投资判断或者基于多份会议纪要输出项目风险清单。这类任务失败点很多长文本中间信息漏掉、推理链断裂、前面得出的结论后面忘了用、输出看似完整但关键论据错误。Ethan Mollick 评测认为新版模型在这类任务上的表现相比此前版本有显著提升尤其在“需要持续跟踪多个约束条件并逐步收敛结论”的场景下。这篇文章不打算复述评测原文而是把评测思路拆成一套可以在自己环境里复现的验证流程怎么准备测试集、怎么接入模型、怎么批量跑任务、怎么量化“进步明显”这五个字。同时会覆盖 API 接入、批量调用、性能观察和常见问题排查。如果你在做智能体开发、长文档分析工具或复杂决策支持系统这篇文章可以直接当评测脚本参考。1. 核心能力速览能力项说明项目/模型类型大语言模型能力评测重点覆盖长程判断类任务核心能力长上下文信息聚合、多步推理、方案对比、决策收敛评测维度信息召回率、推理链完整性、约束遵循度、输出一致性部署方式API 接入 / 本地推理 / 第三方 WebUI取决于实际环境是否支持 API支持走标准 HTTP 接口可按 OpenAI 兼容格式封装是否支持批量任务支持本文会给出 Python 批量评测脚本硬件要求本地推理需按模型实际规格评估API 方式无显存要求显存占用必须按实际模型和推理框架测试文章不编造数值适合场景研究报告分析、多轮规划、决策支持、智能体任务编排需要先说清楚本文重点不是给某一个模型背书而是把“长程判断类任务评测”做成一套可复用的方法。你手里有别的模型也可以套用这套流程做横向对比。2. 适用场景与使用边界长程判断类任务和普通对话任务的区别在于它需要模型同时具备三种能力长上下文保持能力前 5000 字出现的关键约束到第 18000 字时仍然有效。多步推理能力结论 A 支撑结论 BB 又决定最终方案中间不能断。输出收敛能力信息越杂越要能在最后给出清晰、可执行的判断而不是罗列所有可能性。适合用这类模型的场景包括对多份行业报告做交叉分析并输出结论。基于项目历史纪要、代码审查记录生成风险清单。把多轮会议内容整理成决策备忘录标注未决事项。在智能体工作流中承担“规划者”角色拆解任务并依次执行。不适合的场景也要说清楚高频短对话延迟敏感这类模型在长上下文上有优势但在极短任务上不一定比轻量模型强。纯事实检索如果只是“某年某月发生了什么”用搜索引擎或 RAG 更直接。高风险自动决策比如医疗诊断、法律意见、金融自动下单模型输出只能做辅助参考不能直接作为最终依据。使用边界方面需要特别提醒如果你把企业文档、用户隐私数据或未公开的研究材料发送到模型接口先确认数据使用条款和脱敏要求。涉及人脸、声音、版权素材的内容必须确认你有合法授权。涉及内部数据的场景优先考虑本地部署或私有化部署避免敏感信息外传。3. 评测环境与前置条件不管你是调用线上 API 还是本地部署下面这套环境准备流程都适用。3.1 基础依赖建议使用 Python 3.10 以上版本安装以下依赖pip install requests pandas openpyxl openai tiktoken说明requests用于直接发送 HTTP 请求。openai库用于兼容 OpenAI 格式的 API 接入如果你的接口不是这个格式可以只用requests。pandas用于整理评测结果和导出 Excel。tiktoken用于估算 token 消耗。3.2 测试集准备长程判断类任务的评测集分为三个级别级别输入长度任务类型示例入门2000-5000 字单文档信息聚合读一篇产品说明回答定价和限制条件进阶5000-15000 字多文档交叉推理对比三份方案找出冲突条款困难15000-30000 字多约束决策基于项目日报、会议纪要、风险记录输出判断构建自己的测试集时关键不是堆数量而是控制变量。每一道题都要包含唯一正确答案或明确打分标准。至少 3 条分布在长文本不同位置的约束条件。至少 1 个需要跨章节关联才能得出的结论。测试集建议至少准备 20 道题。数量太少结论没有统计意义50 道以上就可以做比较稳定的横向对比。3.3 运行环境检查清单- Python 3.10 已安装 - 依赖包安装完成 - 测试集文件为 CSV 或 JSON 格式 - 模型 API Key 已配置如果走 API 方式 - 输出目录已创建 - 网络代理已配置如果需要关于 GPU 和显存如果用 API 方式本机不需要 GPU如果本地推理需要在部署前确认显卡型号、显存大小和模型量化格式。不同量化等级FP16 / INT8 / INT4显存占用差异很大建议先查官方文档再决定。4. 部署启动与接入方式这一章给出三种接入方式。具体路径以你自己的实际项目为准这里提供可复用的模板。4.1 方式一API 直接调用这是最快的方式适合快速验证模型能力。先用环境变量保存配置export API_BASE_URLhttps://your-api-endpoint.example.com/v1 export API_KEYsk-your-key export MODEL_NAMEyour-model-name然后写一个最小调用脚本import os import httpx api_base os.environ[API_BASE_URL] api_key os.environ[API_KEY] model os.environ[MODEL_NAME] resp httpx.post( f{api_base}/chat/completions, headers{Authorization: fBearer {api_key}}, json{ model: model, messages: [ {role: user, content: 请阅读以下材料并回答材料中有哪三项风险约束} ], temperature: 0.2, max_tokens: 800, }, timeout120, ) print(resp.status_code) print(resp.json()[choices][0][message][content])注意上面示例中的API_BASE_URL、API_KEY、MODEL_NAME都需要替换成你自己的实际配置。不同服务商的请求路径和参数不完全一致优先以你的服务商文档为准。4.2 方式二本地推理部署本地部署的通用流程是下载模型权重文件。选择推理框架常见的选择包括 vLLM、Text Generation Inference、llama.cpp 或 Ollama。启动一个兼容 OpenAI 格式的本地服务。用同一套 API 调用脚本接入。以 vLLM 为例启动命令长这样python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --served-model-name local-judge \ --port 8000 \ --gpu-memory-utilization 0.85 \ --max-model-len 32768如果显存不够跑长文本可以考虑降低--max-model-len或者换用量化版本模型。启动后访问http://127.0.0.1:8000/v1即可。4.3 方式三WebUI 接入有些场景需要人工阅读模型输出不适合纯脚本跑。可以接入支持大语言模型的 WebUI 工具比如 Open WebUI 或 LobeChat把上面的 API 地址填进去即可。这类工具的好处是有对话界面方便人工逐条核对输出质量缺点是批量任务能力弱自动化评测还是得回到脚本。5. 长程判断类任务测试与效果验证下面这套测试流程是参照 Ethan Mollick 评测长程判断类任务的方法整理的。每一步都给出了操作步骤、预期结果和判断标准。5.1 长文档信息聚合测试测试目的验证模型是否能从长文档中准确提取分散在不同位置的信息并在最后汇总时不遗漏。输入示例请阅读以下产品需求文档摘要约 8000 字然后回答 1. 该产品面向的三类目标用户分别是谁 2. 文档中提到的三个硬件限制是什么 3. 发布计划中哪个阶段的风险最大 要求回答必须引用文档原文位置。测试方法准备一份 6000-10000 字的测试文档。在文档第 10%、50%、90% 的位置分别埋入三个关键信息点。问题设计成必须跨三个位置才能完整回答。记录回答内容并逐条对照。通过标准三个信息点全部命中无遗漏。输出中引用的位置与实际位置一致。没有被文档中的干扰信息带偏。常见失败特征只回答了文档开头或结尾的信息。回答内容正确但把 A 文档的信息安到 B 文档上。输出偏长但实际有效信息占比低。5.2 多步推理稳定性测试测试目的验证模型能否在长上下文中维持推理链不在中途丢失中间结论。输入示例以下是某项目 15 个迭代版本的变更记录约 12000 字。 请回答从 v1.0 到 v1.6哪些变更被回滚了回滚是否与性能问题相关 最后给出结论在 v1.7 版本中继续推进新架构是否合理测试方法设计一段逻辑链需求变更 → 代码实现 → 性能回退 → 回滚决策 → 后续版本中的替代方案。把逻辑链打散分布在多段材料中。让模型重新串起这条链并给出判断。对同一题跑 5 次记录每次结论是否一致。通过标准5 次输出中至少有 4 次给出同一结论。关键中间步骤回滚原因、性能指标没有记错。最终判断包含对限制条件的说明而不是无理由拍板。常见失败特征中间某一步推理错误后后面全错。模型把不同版本的变更记录混在一起。输出结论明确但支撑结论的证据在实际材料中不存在。5.3 多约束决策测试测试目的验证模型在多个互相冲突的约束条件下能否做出合理取舍。输入示例你是一个技术负责人。现有约束 1. 必须在 3 周内上线。 2. 团队只有 2 名后端开发。 3. 客户要求必须包含 A、B、C 三个功能。 4. 预算只够支持其中两个功能的开发量。 请基于以下项目文档给出功能取舍方案和风险说明。测试方法把约束条件分散在材料中不要集中列在开头。其中一组约束存在天然冲突例如时间和范围冲突。判断模型是否能识别冲突并主动提出取舍而不是机械地“全部满足”。检查模型输出的风险说明是否覆盖了所有约束。通过标准模型明确识别出约束冲突。给出的取舍方案有优先级依据。对未选择方案有风险评估。输出不超 500 字的情况下仍然保留关键信息。常见失败特征模型无脑罗列所有需求声称“全部完成”。忽略了散落在材料后半段的限制条件。输出的决策建议太空泛没有落地路径。5.4 批量自动评分人工逐条评分效率太低建议写一个批量评测脚本自动输出评分表。下面给出一个可改写的评测脚本模板。import json import time import csv import httpx # 读取测试集 with open(test_set.json, r, encodingutf-8) as f: test_cases json.load(f) results [] for case in test_cases: input_text case[input] expected case[expected] start time.time() try: resp httpx.post( http://127.0.0.1:8000/v1/chat/completions, headers{Authorization: Bearer local-key}, json{ model: local-judge, messages: [{role: user, content: input_text}], temperature: 0.2, max_tokens: 1000, }, timeout300, ) output resp.json()[choices][0][message][content] elapsed time.time() - start results.append({ case_id: case[id], expected: expected, output: output, elapsed_seconds: round(elapsed, 2), status: ok, }) except Exception as e: results.append({ case_id: case[id], expected: expected, output: str(e), elapsed_seconds: 0, status: failed, }) # 导出结果 with open(eval_results.csv, w, newline, encodingutf-8) as f: writer csv.DictWriter(f, fieldnames[case_id, expected, output, elapsed_seconds, status]) writer.writeheader() writer.writerows(results) print(f完成共 {len(results)} 条成功 {sum(1 for r in results if r[status]ok)} 条)说明这个脚本直接用关键词匹配或人工抽样判断输出质量跑完拿 CSV 后再做一轮人工复核。如果你的测试集有标准答案可以再加一个 LLM-as-Judge 的步骤并用一个独立模型打分。5.5 评测维度量化对比跑完评测后建议用下面这套指标做版本对比指标计算方式说明信息召回率正确信息点 / 总信息点衡量长文档信息聚合能力推理链完整率完整推理链 / 总推理链衡量多步推理稳定性约束遵循率正确遵循约束数 / 总约束数衡量多约束决策能力结论一致率一致结论次数 / 总运行次数衡量输出稳定性平均响应时间总耗时 / 用例数衡量实际可用性Token 消耗输入 token 输出 token衡量成本只有同时对比这几个指标才能判断一个模型“进步”到底体现在哪里。Ethan Mollick 评测长程判断类工作的一个核心思路就是把“感觉变强了”变成可量化的指标差异。6. 接口 API 与批量任务6.1 单条接口调用使用 curl 直接测试接口连通性curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: local-judge, messages: [{role: user, content: 请用一句话总结这段项目日志的核心风险。}], max_tokens: 200 }如果你的远端 API 需要认证在请求头中追加Authorization字段。6.2 批量任务设计批量评测不推荐一个 for 循环无脑发请求更稳妥的做法是带队列、重试和日志。下面给出一个批量任务目录结构建议eval_project/ ├── inputs/ # 存放原始测试材料 │ ├── case_01.txt │ ├── case_02.txt │ └── ... ├── test_set.json # 测试用例索引 ├── logs/ # 运行日志 ├── results/ # 输出结果 └── eval_runner.py # 批量评测脚本批量执行时的关键参数参数建议值说明并发数1-4并发太高容易被限流或显存撑爆单请求超时120-300 秒长输入模型推理时间拉长失败重试次数2网络抖动或限流时自动重试重试间隔5 秒避免立即重试继续失败温度0.1-0.3评测场景需要确定性输出6.3 带重试的 Python 调用模板import time import httpx from tenacity import retry, stop_after_attempt, wait_fixed retry(stopstop_after_attempt(3), waitwait_fixed(5)) def call_model(client, model, prompt, timeout300): resp client.post( /v1/chat/completions, json{ model: model, messages: [{role: user, content: prompt}], temperature: 0.2, max_tokens: 1000, }, timeouttimeout, ) resp.raise_for_status() return resp.json()[choices][0][message][content] client httpx.Client(base_urlhttp://127.0.0.1:8000, timeout300) output call_model(client, local-judge, 请分析以下文档...)注意tenacity需要单独安装pip install tenacity如果你不想多一个依赖自己写 for 循环重试也可以效果一样。7. 资源占用与性能观察长程判断类任务对资源的消耗主要来自长输入本身而不是生成阶段。这里给出通用的观察方法。7.1 显存占用观察方法本地推理时用以下命令实时查看显存nvidia-smi -l 1重点观察两项显存占用长输入场景下显存占用会随输入 token 数上升。GPU 利用率如果利用率长期低于 50%瓶颈可能在 CPU 处理输入或内存带宽。更细的显存分布可以用nvidia-smi --query-gpumemory.used,memory.total,utilization.gpu --formatcsv导出。7.2 长输入的时间开销长文本场景有几个值得注意的现象Prefill 阶段耗时增长明显输入越长首 token 延迟越高。1 万 token 的输入和 1000 token 的输入首 token 延迟差异可以达到数倍到数十倍。输出速度不一定变慢只要显存没有溢出生成阶段速度主要由模型大小和推理框架决定。max_model_len 限制本地推理时超长输入会直接报错错误信息通常类似 “maximum context length”。这时要么降低max_model_len要么对输入做截断或检索。7.3 如何降低资源占用方法说明降低max_model_len限制最长输入节省显存代价是超长输入被截断使用量化版本INT8/INT4 比 FP16 省显存但精度可能略微下降输入分块先检索相关内容只把相关片段交给模型降低并发数避免多个请求同时占满显存使用流式输出降低峰值内存但不一定显著降显存这里要再次强调具体显存数字与模型大小、量化格式、推理框架、输入长度都有关系。不要套用别人的经验值必须在你自己的环境里跑一遍用nvidia-smi读取实际占用。7.4 API 方式的性能观察API 方式无法直接看显存但可以观察每次请求的响应时间。返回内容中的 token 使用量一般接口会返回usage字段。并发请求是否触发限流错误HTTP 429。建议把每次请求耗时、输入 token、输出 token 都记录到日志方便后续做成本统计。8. 常见问题与排查方法问题现象可能原因排查方式解决方案请求返回 401 UnauthorizedAPI Key 无效或未配置检查环境变量和请求头重新配置密钥确认请求头格式请求返回 404 Not Found接口路径错误或模型名不存在查看服务日志和接口文档与服务商核对接口路径和模型名请求返回 429 Too Many Requests触发限流或配额不足检查响应头中的限流信息降低并发数增加重试间隔查询账户配额本地推理报显存不足输入过长或模型过大查看nvidia-smi确认显存占用降低max_model_len换量化模型换更大显存长文本被截断超过模型上下文窗口查看报错信息和 token 统计分段输入或使用 RAG 方式截取关键片段输出质量不稳定温度参数过高检查生成参数温度降到 0.1-0.3多次运行取一致结论批量任务卡住单条请求超时或进程假死查看日志定位卡住的请求设置单次请求超时添加重试机制输出中间日志结果 CSV 乱码编码问题检查文件头和写入编码用utf-8-sig编码写入 CSV结论一致率低评测集设计不合理或题目模糊检查题目是否存在歧义优化测试集增加约束条件的明确性如果是一个完全没跑通的情况建议按这个顺序排查先确认接口连通性用 curl 发一个最小请求。再确认单条长输入能正常返回用一条测试用例单跑。最后才跑批量批量前先跑 3 条确认无问题再全量。9. 最佳实践与使用建议9.1 先小后大迭代测试第一次跑评测不要直接上 3 万字的长文本。先从 2000-5000 字的入门级测试集开始确认接口、脚本、评分流程都跑通了再逐步增加难度。这样能避免一上来就被各种环境问题淹没。9.2 保留一组固定测试集长程判断类任务评测最怕测试集随意变化。建议固定 20-50 道题长期保持不变每次模型更新后都跑一遍。这样前后结果才能对比。测试集建议按难度分级保存test_sets/ ├── basic.json # 入门级2000-5000 字 ├── medium.json # 进阶级5000-15000 字 └── hard.json # 困难级15000-30000 字9.3 批量任务要留日志批量评测脚本里一定要输出到日志文件并包含时间戳、用例 ID、请求状态。不要只在终端打印。后面排查问题时日志是唯一可靠的依据。python eval_runner.py logs/run_$(date %Y%m%d_%H%M%S).log 219.4 合规与权限管理调用模型 API 时确认以下几点测试数据是否包含个人信息、商业秘密或未公开材料。API Key 是否正确加密保存不要提交到 Git 仓库。长文本是否涉及版权材料未经授权不要用于训练或转发。本地部署的服务端口不要直接暴露到公网尽量绑定127.0.0.1或加访问控制。9.5 输出复核机制自动化评测只能筛出明显失败的情况判断类任务最终结论是否正确还需要人工复核。建议采用“机器初筛 人工抽检”的组合机器跑完全量用例并打分人工随机抽检 20%-30% 的输出重点看机器评分无法覆盖的语义错误。9.6 评测过程可复现在评测脚本里固定以下参数temperature、max_tokens、模型版本、提示词模板。只要这些参数不一致得出的“模型变强了还是变弱了”结论都可能失真。10. 总结与下一步长程判断类任务的评测本质上是在问一个更底层的问题模型能不能承担复杂工作而不只是聊天。Ethan Mollick 评测指出的“显著进步”大概率不是某个单点能力的提升而是长上下文保持、多步推理和决策收敛三个维度的综合改善。这个方向对真实业务的价值比刷榜式的短问答要大得多。如果你想快速验证一个模型的长程判断能力建议从 5.1 节的信息聚合测试开始先跑 10 条用例看信息召回率是否达到预期。如果模型连散落在长文档中的关键信息都抓不准再强的多步推理也没有意义。最容易踩的坑有三个测试集太简单模型都答对区分度为零。温度参数没固定同一道题跑 5 次结论不一致无法判断是模型问题还是参数问题。批量任务没有超时和重试跑到一半卡住前面结果全部作废。先把这套流程跑通再对齐模型版本形成自己的评测基线。后面每次模型更新跑同一套题看数据说话比看发布公告上的指标描述靠谱得多。接下来可以做的事把这套评测脚本接入到模型版本的自动化测试流程中每次新版本发布自动跑一遍长程判断测试集输出对比报表。或者继续增加困难级测试题把测试集做到 100 道以上让评测结论更稳。