通过提示词工程提升大模型在HLE上的表现的初步研究：TaoToken统一API通道下的配置与验证

1. 为什么要在 HLE 上折腾提示词工程HLEHumanitys Last Exam这个基准最近在圈子里讨论得挺多它的定位很直接当 MMLU 这类老基准被模型刷到 90% 以上、区分度越来越低的时候用 2500 道覆盖上百个学科、还带多模态的前沿难题来重新拉开模型之间的差距。公开题库加私有测试集的组合也让“背答案”这条路基本走不通。换句话说它测的是模型真正的理解和推理而不是记忆。但问题也来了HLE 的题目难度极高很多题在零样本zero-shot下模型连题意都抓不准。我拿 DeepSeek V3.1 的无思考模式在本地跑过一批选择题零样本大概只有 7/3718.92%到 17/6625.76%这个区间。这个数字放在 HLE 的语境里其实不算难看但离“能用”还有距离。于是很自然的一个假设就冒出来了如果不动模型权重只改提示词能不能把准确率往上抬一抬这篇就是围绕这个假设做的初步实验记录。重点不是宣布什么结论而是把一套可复现的实验环境搭出来——用 TaoToken 统一 Key/API 通道接 DeepSeek配好 settings.json 和 config.toml 骨架接上 Cline / CC Switch再写一个能跑 HLE 子集的评测脚本把每次的 token 消耗和正确数都记下来。适合谁看想自己动手验证提示工程效果、又不想在多家 API 之间来回切 Key 的开发者。2. TaoToken 统一通道一次配 Key多模型切换做提示词实验最烦的一件事是你要对比不同模型、不同提示模板结果每换一个模型就得改一遍 base_url 和 api_key。TaoToken 在这里的价值就是统一入口一个 Key、一个 API 地址背后可以路由到 DeepSeek、Claude 等不同模型。对 HLE 这种需要反复跑对照实验的场景省掉的是大量配置切换的时间。它的 API 地址是https://taotoken.net/api兼容 OpenAI 的接口格式所以任何支持自定义 base_url 的客户端基本都能直接接。官网在https://taotoken.net/文档和 Key 管理都在控制台里。这里要强调一点TaoToken 是正规的 API 聚合通道不是那种来路不明的转发。你拿到的 Key 在控制台里可以随时查看用量、轮换这对需要记录 token 消耗的实验来说很重要——后面评测脚本里我们要把每次请求的 token 数落盘方便算成本。接入前你需要准备的东西不多一个 TaoToken 账号、一个 API Key、本地 Python 环境建议 3.10以及一份 HLE 的题目子集。HLE 官方仓库在 GitHub 上centerforaisafety/hle里面有run_model_predictions.py可以参考它的调用方式。我建议先只取物理或 CS/AI 的选择题因为简答题需要人工判分不适合快速迭代。3. 可复制配置settings.json 与 config.toml 骨架先把配置落地。不同工具读的配置文件不一样Cline 走的是 VS Code 的 settings.jsonCC Switch 和部分 CLI 工具走 config.toml。下面两份骨架你可以直接抄把YOUR_TAOTOKEN_KEY换成自己的就行。3.1 settings.jsonCline / VS Code 侧{ cline.apiProvider: openai, cline.openAiApiKey: YOUR_TAOTOKEN_KEY, cline.openAiBaseUrl: https://taotoken.net/api, cline.openAiModelId: deepseek-v3.1, cline.openAiModelInfo: { maxTokens: 8192, contextWindow: 128000, supportsImages: false, supportsPromptCache: false }, cline.temperature: 0.2, cline.requestTimeout: 120000 }几个参数说明一下。temperature设成 0.2 是为了让实验可复现——提示词工程实验最怕的就是随机性把结论搅浑低温度能让同一提示多次运行的结果更稳定。supportsImages设 false因为我们这轮只做纯文本选择题图像题先排除。maxTokens给 8192 是因为 HLE 的推理链可能很长尤其是带 Thinking_process 的结构化输出给太少会被截断。3.2 config.tomlCC Switch / CLI 侧[provider] name taotoken base_url https://taotoken.net/api api_key YOUR_TAOTOKEN_KEY default_model deepseek-v3.1 [models.deepseek-v3.1] max_tokens 8192 temperature 0.2 top_p 0.95 [models.deepseek-v3.1-thinking] max_tokens 16384 temperature 0.6 [experiment] dataset hle_physics_mcq.jsonl output_dir ./runs record_tokens true这里我特意分了两个模型条目deepseek-v3.1用于无思考的基线对照deepseek-v3.1-thinking用于带推理的版本。record_tokens true是给后面评测脚本用的开关确保每次请求的 token 用量都写进结果文件。output_dir按运行批次分目录避免不同提示模板的结果混在一起。注意配置文件里的 Key 不要提交到 Git。建议用环境变量TAOTOKEN_API_KEY覆盖脚本里读环境变量优先。4. 提示词模板从角色推断到分步推理配置好了接下来是实验的核心——提示词。我参考了 HLE 官方run_model_predictions.py里的做法它原本的提示非常朴素基本只要求结构化输出。我们要做的是在这个基础上加两层角色/场景推断和分步推理。4.1 第一步让模型自己推断角色和场景思路是这样的与其我们硬编码“你是一个物理学家”不如把问题、答案、理由一起喂给模型让它反推“回答这个问题的最佳人选是谁、在什么场景下会被问到”。这样得到的角色和场景更贴合题目本身。ROLE_INFER_PROMPT issue {msg} answer {answer} cause {cause} —————— 以上是一些零散的信息。基于这些信息您认为回答这个问题的最佳人选是什么 在什么场景下可能会被问到这个问题 回答者的思考过程是怎样的并总结思考过程中出现的知识点。 请以 json 格式输出 thinking_process: str role: str scene: str knowledge: list[str] 这一步的输出会作为第二步的输入。注意这里有个关键设计角色推断和正式答题要在两次独立的对话里完成不能放在同一个上下文里。否则模型会从上下文里“学到”答案实验就失去意义了。这也是为什么脚本里要把 knowledge 提取出来再作为纯文本传进第二轮。4.2 第二步分步推理模板拿到 role、scene 和 knowledge 之后正式答题的模板长这样ANSWER_PROMPT You are {role} You are in {scene} You need to answer following question. Please follow the steps below to provide a brief answer. Step 1: Simply understand the difference between options. Step 2: Review relevant physics principles and knowledge, such as: {knowledge} Step 3: Identify the points of study by connecting relevant physics principles and knowledge to the difference between options. Step 4: Please note that the descriptions in the question itself may contain mistakes or nits, so please answer based on the facts. Step 5: Analyze the ontologys points of investigation and assume an answer. Step 6: Compare and analyze the differences between the options based on the assumed options. Your answer should in json structure as: Thinking_process: {{your thinking process, to show your followed steps to answer the question}} Explanation: {{your reason}} Answer: string, just from given options Confidence: {{your confidence score between 0% and 100% for your answer}} Here is the question: {msg} 这个模板是 ReAct 风格的Step 5 先假设答案Step 6 再回头比较选项差异。实测下来把Thinking_process放在Answer之前很关键——如果 Answer 字段在前即使模型在思考过程中出现了“Aha”时刻它也不会回头改已经写下的答案。我在本地把流式传输关掉就是为了让这个顺序严格生效。4.3 一个真实的失败案例HLE 里有一道题id: 66f2dee46721a56e35d20300问的是水星钠尾在远日点和近日点的外观差异。DeepSeek 在这题上反复出错原因是它把“钠尾”理解成被滤波器滤掉了。我后来发现如果把“水星的钠尾”改成“水星的尾巴”有时就能答对。这说明模型对某些术语的语义锚定太强提示词里适当“去术语化”反而有帮助。另一道题id: 66f28cc8b866ea3f1f4e95f5问“这怎么可能”答案却是“这些是高阻抗线圈”。把How its possible?改成What kind of coils are they?之后模型答对的概率明显上升。这类改写属于提示工程里很实用的技巧当问题问法和答案类型不匹配时主动把问法改成答案能直接回应的形式。5. 验证请求与结果记录配置和模板都齐了现在跑一次验证请求确认通道是通的再把评测脚本的结果记录方式定下来。5.1 最小验证请求先用一段最短的代码确认 TaoToken 通道能正常返回import os from openai import OpenAI client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlhttps://taotoken.net/api ) resp client.chat.completions.create( modeldeepseek-v3.1, messages[{role: user, content: 回答一个字11?}], temperature0.2, max_tokens64 ) print(resp.choices[0].message.content) print(tokens:, resp.usage.total_tokens)跑通的话你会看到输出和一个 token 数。这一步别跳过因为后面评测脚本里所有请求都走同一个 client通道不通的话整个实验都白搭。5.2 HLE 评测脚本骨架下面这个脚本把“角色推断 → 正式答题 → 记录结果”串起来。它读一个 jsonl 格式的题目文件每题跑两轮对话最后把正确数、token 消耗、每题的原始输出都写进结果文件。import json import os from openai import OpenAI client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlhttps://taotoken.net/api ) def infer_role(msg, answer, cause): prompt ROLE_INFER_PROMPT.format(msgmsg, answeranswer, causecause) resp client.chat.completions.create( modeldeepseek-v3.1, messages[{role: user, content: prompt}], temperature0.2, max_tokens2048 ) return resp.choices[0].message.content, resp.usage.total_tokens def answer_question(msg, role, scene, knowledge): prompt ANSWER_PROMPT.format( rolerole, scenescene, knowledge\n.join(knowledge), msgmsg ) resp client.chat.completions.create( modeldeepseek-v3.1, messages[{role: user, content: prompt}], temperature0.2, max_tokens8192 ) return resp.choices[0].message.content, resp.usage.total_tokens def run_eval(dataset_path, output_path): correct 0 total 0 token_sum 0 records [] with open(dataset_path, r, encodingutf-8) as f: for line in f: item json.loads(line) total 1 role_raw, t1 infer_role( item[question], item[answer], item.get(rationale, ) ) token_sum t1 try: parsed json.loads(role_raw) role parsed.get(role, an expert) scene parsed.get(scene, an exam) knowledge parsed.get(knowledge, []) except json.JSONDecodeError: role, scene, knowledge an expert, an exam, [] ans_raw, t2 answer_question( item[question], role, scene, knowledge ) token_sum t2 pred extract_answer(ans_raw) is_correct (pred item[answer]) if is_correct: correct 1 records.append({ id: item.get(id), pred: pred, gold: item[answer], correct: is_correct, raw: ans_raw, tokens: t1 t2 }) result { correct: correct, total: total, accuracy: correct / total if total else 0, tokens: token_sum, records: records } with open(output_path, w, encodingutf-8) as f: json.dump(result, f, ensure_asciiFalse, indent2) print(f正确 {correct}/{total}, 准确率 {correct/total:.2%}, tokens {token_sum})extract_answer需要你自己写从模型返回的 json 里抠出Answer字段。这里有个坑模型有时会返回B(bob)这种带括号的格式而标准答案是B直接字符串比较会判错。建议在提取时做一次清洗只保留选项字母。5.3 结果记录方式我建议每次运行都存一个独立的 json 文件文件名带上时间戳和提示模板版本比如runs/20250830_baseline.json、runs/20250830_role_infer.json。这样对比不同提示模板时直接读两个文件算差值就行。记录里除了正确数一定要保留每题的raw输出——后面分析失败原因时原始输出比正确率数字有用得多。我第一轮跑基线时是 0/37加上角色推断和分步推理后到了 7/3718.92%。第二轮因为晚上跑的时候忘了把提示从物理改成 CS/AI结果在 CS/AI 子集上拿到了 17/6625.76%。这个“意外”其实挺有意思说明这套提示模板对学科切换有一定的鲁棒性但也提醒我实验记录要写清楚每轮用的数据集和模板版本。6. 本篇常见错排查跑这套流程时我踩过的坑基本集中在下面几类列出来供你对照。Key 或 base_url 配错。最常见的报错是 401 或 404。先确认base_url是https://taotoken.net/api不要多加/v1之类的后缀也不要漏掉/api。Key 从控制台复制时注意别带空格。如果用的是环境变量确认TAOTOKEN_API_KEY在当前 shell 里确实生效了。模型名不匹配。TaoToken 通道下模型名要和控制台里列出的保持一致。写deepseek-v3.1能通写deepseek-v3可能就报 model not found。跑之前先在控制台确认一下可用模型列表。角色推断返回的不是合法 json。模型有时会在 json 外面包一层 markdown 代码块或者加一句“好的以下是结果”。脚本里用json.loads直接解析会抛异常。稳妥的做法是先做一次清洗把json 和去掉再解析。解析失败时给个默认的 role 和 scene别让整个流程中断。答案提取把格式错误算成错。前面提过B(bob)和B会被判成不同。建议提取时用正则只抓选项字母比如re.search(r[A-D], pred)。另外模型偶尔会返回Answer: B带引号也要一并清洗。token 消耗记录丢失。我第二轮就遇到过晚上跑完忘了记 token 数只能从结果 json 里恢复。所以脚本里一定要在每次请求后立刻把usage.total_tokens写进记录别等到最后统一算。上下文污染。如果你图省事把角色推断和正式答题放在同一个对话里模型会从上下文里“看到”答案准确率会虚高。务必用两次独立的create调用中间只传 role、scene、knowledge 这些不包含答案的信息。温度设太高导致结果不可复现。提示工程实验要的是可对比温度建议 0.2 以下。如果你要测 thinking 版本温度可以适当提到 0.6但同一组对照实验里温度要保持一致。7. 继续往下走把实验变成习惯这套环境搭起来之后真正有价值的是持续迭代。你可以把不同的提示模板当成变量固定数据集和模型一轮一轮跑对照。比如这轮加角色推断下轮把 Step 4 的“基于事实回答”改成更具体的指令再下轮试试把 knowledge 从列表改成段落。每次只动一个变量结果才有解释力。如果你要长期跑这类编码和评测任务可以考虑用 TaoToken 的 Coding Plan它在多轮请求下的额度管理更省心。想先验证模型本身的表现可以直接在模型对话里手动试几道 HLE 题感受一下不同提示的差异。接入文档和 API Key 管理都在控制台配置过程中遇到报错优先对照第 6 节的排查清单。最后留一个我自己的待办目前这套模板只在物理和 CS/AI 的选择题上验证过简答题还没碰。简答题的判分需要人工或另一个模型来做成本高不少但 HLE 里简答题占比不小绕不过去。下一步打算先把简答题的答案提取和判分流程跑通再回头优化提示模板。