1. 创造力评测为什么突然成了多模态模型的“灵魂拷问”如果你最近在跑多模态模型的评测会发现一个尴尬的现实分类、VQA、captioning 这些任务早就被刷到接近饱和模型能准确说出图里有什么、能推理出下一步动作但你让它判断“这张设计稿的创意到底好在哪”它给出的答案往往空洞得像模板作文。北邮团队推出的 CreBench 正是冲着这个痛点来的——它是全球首个把“创造力”拆成创意想法、创意过程、创意作品三阶段并用 12 个细粒度指标做行为锚定打分的多模态基准。换句话说它不再只问模型“你看到了什么”而是问“你觉得这个创意为什么新、新在哪、能不能落地”。CreBench 的核心价值在于把原本高度主观的“创意好不好”变成了可复现的评分链路。它定义了 Creative IdeaOriginality、Appropriateness、Creative ProcessImmersion、Divergence、Structuring、Evaluation、Elaboration、Creative ProductEffectiveness、Aesthetic、Novelty、Manufacturability、System Complexity共 12 个指标每个指标都有 5 分制 rubric并由受过 CATConsensual Assessment Technique训练的专家标注。配套的 CreMIT 数据集包含 2.2K 创意实例、79.2K 人类反馈扩展出 470 万条多模态指令训练出的 CreExpert 基于 LLaVA-1.5 微调在人类一致性上把 GPT-4V 甩开了 36 个百分点以上。这套体系适合谁如果你在做多模态 Agent 的创意评估模块、在设计教育类产品里做作业点评、或者在研究 MLLM 的认知对齐CreBench 提供了一条可以直接复现的评测链路。但问题来了CreBench 本身是评测框架和数据集真正跑起来需要调用多模态模型接口而 LLaVA、GPT-4V、Gemini 2.5 Vision 这些模型的接入方式各不相同Key 管理、Base URL 配置、请求格式差异会消耗大量时间。我在实际复现时用 TaoToken 的统一 Key 通道把多模态调用收敛到一套配置上下面把完整流程拆开讲。2. TaoToken 统一 Key 在多模态创造力评测里的前置准备CreBench 的评测流程本质上是“给模型一张创意作品图 一段创意过程描述让模型按 12 指标输出评分和理由”。这意味着你需要一个能稳定调用多模态模型的通道。直接对接各家官方 API 的问题是LLaVA 系模型通常要自己部署或找托管端点GPT-4V 和 Gemini 2.5 Vision 的请求体格式、图片编码方式、返回结构都不一样评测脚本里要写一堆 if-else 分支。TaoToken 的作用是把这些差异收敛到 OpenAI 兼容的接口规范上你只需要维护一个 Base URL 和一个 Key模型 ID 作为参数切换。前置准备分三块。第一块是账号和 Key访问官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册后进入控制台 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 创建 API Key。建议为 CreBench 评测单独建一个 Key方便按项目统计消耗。第二块是确认你要评测的模型 IDCreBench 论文里对比了 GPT-4V、Gemini 2.5 Vision 和 CreExpert你可以先用 GPT-4V 类模型跑通链路再替换成其他多模态模型做横向对比。第三块是环境准备Python 3.9安装 openai 和 requests 两个库即可不需要为每个模型单独装 SDK。这里有个容易踩的坑CreBench 的评分 rubric 要求模型输出结构化的 12 指标分数而多模态模型对“请按 JSON 输出”的遵循程度参差不齐。我的做法是在 system prompt 里把 12 个指标名和 5 分制锚定描述写死并要求返回 JSON然后在代码里做一次 schema 校验。TaoToken 的接口层不做内容改写所以 prompt 工程完全由你控制这对评测的可复现性很重要——同一套 prompt 换模型差异才归因于模型本身。另外提醒一点CreBench 项目主页和论文里提供的 CreExpert checkpoint 是开源的如果你想本地部署 CreExpert 做对照需要额外的 GPU 资源如果只是想快速验证评测链路用 TaoToken 调 GPT-4V 类模型先跑通打分流程再决定要不要上本地模型这样时间成本最低。API 地址统一用 https://taotoken.net/api注意这个地址不带 UTM 参数直接作为 Base URL 写入配置。3. 可复制的 Base URL 与 Key 配置片段含 JSON/TOML/settings这一节直接给可复制的配置。不管你用哪种方式管理配置核心三件套是 Base URL、API Key、Model ID。先给一个通用的 JSON 配置文件放在项目根目录的config/taotoken.json{ base_url: https://taotoken.net/api, api_key: sk-your-taotoken-key-here, default_model: gpt-4o, timeout: 120, max_retries: 3 }如果你用 Python 的 openai 库读取配置后初始化客户端import json from openai import OpenAI with open(config/taotoken.json, r, encodingutf-8) as f: cfg json.load(f) client OpenAI( base_urlcfg[base_url], api_keycfg[api_key], timeoutcfg[timeout], max_retriescfg[max_retries], )如果你习惯用 TOML 管理比如在pyproject.toml或独立的taotoken.toml里[taotoken] base_url https://taotoken.net/api api_key sk-your-taotoken-key-here default_model gpt-4o timeout 120 max_retries 3读取方式import tomllib from openai import OpenAI with open(taotoken.toml, rb) as f: cfg tomllib.load(f)[taotoken] client OpenAI( base_urlcfg[base_url], api_keycfg[api_key], timeoutcfg[timeout], max_retriescfg[max_retries], )如果你在 VS Code 里用 Cline 或类似插件做评测脚本调试settings 里通常需要填 Base URL 和 Key。以 Cline 的 MCP 配置为例在cline_mcp_settings.json里{ mcpServers: { taotoken-eval: { command: python, args: [-m, crebench_eval.server], env: { OPENAI_BASE_URL: https://taotoken.net/api, OPENAI_API_KEY: sk-your-taotoken-key-here, DEFAULT_MODEL: gpt-4o } } } }注意这里的三件套必须齐全Base URL 是https://taotoken.net/apiKey 是你控制台创建的Model ID 在请求时通过model参数传入。如果你用 Codex 类的 CLI 工具auth.json里通常这样写{ openai: { base_url: https://taotoken.net/api, api_key: sk-your-taotoken-key-here } }配置写完后先别急着跑 CreBench 全量评测用一条最小请求验证通道是否通。下面这段代码发一张测试图加一句 prompt确认返回结构正常resp client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: You are a creativity evaluator.}, {role: user, content: [ {type: text, text: Describe this image in one sentence.}, {type: image_url, image_url: {url: https://example.com/test.jpg}} ]} ], max_tokens200, ) print(resp.choices[0].message.content)如果这一步返回正常说明 Base URL、Key、Model ID 三件套配置无误可以进入 CreBench 的评分 prompt 构造。如果报错先看第 5 节的排查对照表。4. 验证请求与多模态创造力打分成功结果配置通了之后下一步是把 CreBench 的 12 指标 rubric 塞进 prompt让模型对一张创意作品图输出结构化评分。我构造的评分请求分三部分system prompt 定义评分规则user message 包含图片和创意过程描述最后要求 JSON 输出。先看 system prompt 的写法SYSTEM_PROMPT 你是创造力评估专家需要按照 CreBench 的 12 个指标对创意作品打分。 评分采用 5 分制每个指标必须给出 1-5 的整数分和一句理由。 Creative Idea: - Originality: 1完全常见, 5高度原创 - Appropriateness: 1与任务无关, 5高度契合任务目标 Creative Process: - Immersion: 1明显敷衍, 5深度投入 - Divergence: 1思路单一, 5多方向发散 - Structuring: 1结构混乱, 5结构清晰 - Evaluation: 1无自我评估, 5有明确取舍依据 - Elaboration: 1细节缺失, 5细节丰富 Creative Product: - Effectiveness: 1无法实现目标, 5高效达成 - Aesthetic: 1美感差, 5美感强 - Novelty: 1无新意, 5显著新颖 - Manufacturability: 1无法制造, 5易于制造 - System Complexity: 1过于简单, 5复杂度恰当 必须返回 JSON格式如下 {scores: {Originality: {score: 4, reason: ...}, ...}, overall: 3.8} 然后构造请求把图片和创意过程描述一起发过去import base64 def encode_image(path): with open(path, rb) as f: return base64.b64encode(f.read()).decode(utf-8) img_b64 encode_image(samples/creative_work_01.jpg) resp client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: [ {type: text, text: 创意过程描述作者先发散出 5 个方向最终选择将废旧塑料瓶改造成模块化花盆过程中迭代了 3 版结构。请按 12 指标打分。}, {type: image_url, image_url: {url: fdata:image/jpeg;base64,{img_b64}}} ]} ], max_tokens1500, temperature0.2, ) import json result json.loads(resp.choices[0].message.content) print(json.dumps(result, ensure_asciiFalse, indent2))成功返回的结果应该类似这样{ scores: { Originality: {score: 4, reason: 将废旧塑料瓶转化为模块化花盆在材料再利用方向上有明显新意}, Appropriateness: {score: 5, reason: 完全契合可持续设计任务目标}, Immersion: {score: 4, reason: 过程描述显示作者迭代了 3 版结构投入度较高}, Divergence: {score: 4, reason: 先发散 5 个方向再收敛发散性良好}, Structuring: {score: 4, reason: 从发散到收敛到迭代结构清晰}, Evaluation: {score: 3, reason: 有取舍但依据描述不够具体}, Elaboration: {score: 4, reason: 模块化设计细节较丰富}, Effectiveness: {score: 4, reason: 花盆功能可实现}, Aesthetic: {score: 3, reason: 造型简洁但美感中规中矩}, Novelty: {score: 4, reason: 材料再利用角度有新意}, Manufacturability: {score: 4, reason: 塑料瓶加工难度低}, SystemComplexity: {score: 3, reason: 模块化增加了一定复杂度但可控} }, overall: 3.8 }拿到这个结果后你可以做两件事验证链路是否可靠。第一把同一张图同一段描述重复请求 3 次看 12 指标分数的方差如果方差过大说明 temperature 需要调低或 prompt 需要加 few-shot 示例。第二换一个模型 ID比如换成 Gemini 2.5 Vision 或本地部署的 CreExpert用同一套 prompt 跑对比 overall 分数和人类标注的差距。CreBench 论文里 CreExpert 的 Overall PCC 是 65.50%GPT-4V 是 29.27%你可以用这个作为参照判断你的评测链路是否复现出了类似的趋势。如果你想快速验证模型对话能力而不写代码可以直接用模型对话页面 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 手动上传图片测试评分 prompt 的效果确认 prompt 稳定后再落到脚本里批量跑。5. 本篇常见错误排查401、local proxy failed、reading choices、OAuth复现 CreBench 评测链路时报错集中在几个地方。下面按真实报错对照排查。401 Unauthorized最常见的原因是 Key 没填对或 Base URL 写错。检查config/taotoken.json里的api_key是否以sk-开头base_url是否是https://taotoken.net/api注意不要多加/v1也不要带 UTM 参数。如果你用的是环境变量确认OPENAI_API_KEY和OPENAI_BASE_URL都设置了且没有被子进程覆盖。还有一种情况是 Key 被删除或过期去控制台 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 重新创建一个。local proxy failed / connection refused这个报错通常出现在你本地起了代理但代理没运行或者环境变量里残留了HTTP_PROXY/HTTPS_PROXY指向一个不存在的端口。排查方法是先在终端curl -I https://taotoken.net/api看能否通如果不通就检查网络配置。另外如果你在 Docker 里跑评测脚本容器内的 localhost 和宿主机的 localhost 不是一回事需要把 Base URL 换成宿主机的可达地址或者直接在容器内配置网络。reading choices 报错 / KeyError: choices这个错误说明返回的 JSON 里没有choices字段通常是请求被拒绝或返回了错误结构。先打印resp的原始内容看是什么。常见原因是 model ID 写错了比如把gpt-4o写成了gpt4o或者用了 TaoToken 不支持的模型名。另一个原因是图片 base64 太大超过了请求限制把图片压缩到 1MB 以内再试。还有一种情况是max_tokens设得太小模型还没输出完就被截断导致 JSON 解析失败——把max_tokens调到 1500 以上。OAuth 相关报错如果你用 Codex 类 CLI 工具auth.json里同时存在 OAuth token 和 API Key 时可能冲突。解决方法是清空 OAuth 字段只保留base_url和api_key。如果你用 Claude Code 做评测脚本的润色或辅助编码接入时同样需要三件套Base URL 填https://taotoken.net/apiKey 用控制台创建的Model ID 按需选择。Claude Code 的配置入口在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 有说明按文档把三件套填全即可不要只填 Key 不填 Base URL。评分结果不稳定 / JSON 解析失败这不是接口报错但很常见。多模态模型对 JSON 格式的遵循程度不一建议在 prompt 里加一句“只返回 JSON不要加 markdown 代码块标记”然后在代码里做容错解析先尝试json.loads失败则用正则提取{...}再解析。如果还是不稳定把temperature降到 0.1 或 0并加一个 few-shot 示例。CreExpert 本地部署相关如果你在本地跑 CreExpert 做对照显存不够会报 CUDA OOM。LLaVA-1.5 7B 版本在 FP16 下大约需要 14GB 显存如果卡不够可以用 4-bit 量化加载。另外 CreExpert 的 checkpoint 需要和对应的 tokenizer 版本匹配版本不一致会报 tokenizer 相关错误按项目主页的 requirements 安装依赖。6. 把 CreBench 评测链路固化下来从单次验证到批量跑分跑通单张图的评分后下一步是把它变成可复用的批量评测脚本。我的做法是把 CreBench 的 12 指标 rubric 抽成一个独立的 prompt 模板文件把模型 ID、图片路径、创意过程描述作为变量传入输出统一存成 JSONL每行一条记录包含image_id、model_id、scores、overall、timestamp。这样你可以随时换模型 ID 做横向对比也可以把 CreExpert 的本地输出和 API 模型的输出放在同一张表里算 PCC。批量跑的时候注意两点。第一控制并发。多模态请求的响应时间比纯文本长并发太高容易触发限流建议用concurrent.futures把并发控制在 5 以内并在每次请求之间加 0.5 秒间隔。第二做好断点续跑。评测 2.2K 实例可能需要几小时脚本要支持从 JSONL 里读取已完成的image_id并跳过避免重复消耗。如果你要长期做这类评测可以考虑用 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 来管理额度把评测脚本的调用和日常编码辅助分开统计。最后说一个实测下来的经验CreBench 的 12 指标里Creative Process 维度的评分最不稳定因为“过程”信息依赖你提供的描述文本模型对描述的理解差异会直接反映在 Immersion 和 Divergence 分数上。建议在批量跑之前先固定一套创意过程描述的模板比如统一按“发散方向数 → 收敛依据 → 迭代次数 → 最终选择理由”的结构写这样不同模型之间的对比才公平。如果你只是想做模型选型先跑 Creative Product 的 5 个指标就够了Idea 和 Process 维度留到需要细粒度分析时再上。
1. 创造力评测为什么突然成了多模态模型的“灵魂拷问”如果你最近在跑多模态模型的评测会发现一个尴尬的现实分类、VQA、captioning 这些任务早就被刷到接近饱和模型能准确说出图里有什么、能推理出下一步动作但你让它判断“这张设计稿的创意到底好在哪”它给出的答案往往空洞得像模板作文。北邮团队推出的 CreBench 正是冲着这个痛点来的——它是全球首个把“创造力”拆成创意想法、创意过程、创意作品三阶段并用 12 个细粒度指标做行为锚定打分的多模态基准。换句话说它不再只问模型“你看到了什么”而是问“你觉得这个创意为什么新、新在哪、能不能落地”。CreBench 的核心价值在于把原本高度主观的“创意好不好”变成了可复现的评分链路。它定义了 Creative IdeaOriginality、Appropriateness、Creative ProcessImmersion、Divergence、Structuring、Evaluation、Elaboration、Creative ProductEffectiveness、Aesthetic、Novelty、Manufacturability、System Complexity共 12 个指标每个指标都有 5 分制 rubric并由受过 CATConsensual Assessment Technique训练的专家标注。配套的 CreMIT 数据集包含 2.2K 创意实例、79.2K 人类反馈扩展出 470 万条多模态指令训练出的 CreExpert 基于 LLaVA-1.5 微调在人类一致性上把 GPT-4V 甩开了 36 个百分点以上。这套体系适合谁如果你在做多模态 Agent 的创意评估模块、在设计教育类产品里做作业点评、或者在研究 MLLM 的认知对齐CreBench 提供了一条可以直接复现的评测链路。但问题来了CreBench 本身是评测框架和数据集真正跑起来需要调用多模态模型接口而 LLaVA、GPT-4V、Gemini 2.5 Vision 这些模型的接入方式各不相同Key 管理、Base URL 配置、请求格式差异会消耗大量时间。我在实际复现时用 TaoToken 的统一 Key 通道把多模态调用收敛到一套配置上下面把完整流程拆开讲。2. TaoToken 统一 Key 在多模态创造力评测里的前置准备CreBench 的评测流程本质上是“给模型一张创意作品图 一段创意过程描述让模型按 12 指标输出评分和理由”。这意味着你需要一个能稳定调用多模态模型的通道。直接对接各家官方 API 的问题是LLaVA 系模型通常要自己部署或找托管端点GPT-4V 和 Gemini 2.5 Vision 的请求体格式、图片编码方式、返回结构都不一样评测脚本里要写一堆 if-else 分支。TaoToken 的作用是把这些差异收敛到 OpenAI 兼容的接口规范上你只需要维护一个 Base URL 和一个 Key模型 ID 作为参数切换。前置准备分三块。第一块是账号和 Key访问官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册后进入控制台 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 创建 API Key。建议为 CreBench 评测单独建一个 Key方便按项目统计消耗。第二块是确认你要评测的模型 IDCreBench 论文里对比了 GPT-4V、Gemini 2.5 Vision 和 CreExpert你可以先用 GPT-4V 类模型跑通链路再替换成其他多模态模型做横向对比。第三块是环境准备Python 3.9安装 openai 和 requests 两个库即可不需要为每个模型单独装 SDK。这里有个容易踩的坑CreBench 的评分 rubric 要求模型输出结构化的 12 指标分数而多模态模型对“请按 JSON 输出”的遵循程度参差不齐。我的做法是在 system prompt 里把 12 个指标名和 5 分制锚定描述写死并要求返回 JSON然后在代码里做一次 schema 校验。TaoToken 的接口层不做内容改写所以 prompt 工程完全由你控制这对评测的可复现性很重要——同一套 prompt 换模型差异才归因于模型本身。另外提醒一点CreBench 项目主页和论文里提供的 CreExpert checkpoint 是开源的如果你想本地部署 CreExpert 做对照需要额外的 GPU 资源如果只是想快速验证评测链路用 TaoToken 调 GPT-4V 类模型先跑通打分流程再决定要不要上本地模型这样时间成本最低。API 地址统一用 https://taotoken.net/api注意这个地址不带 UTM 参数直接作为 Base URL 写入配置。3. 可复制的 Base URL 与 Key 配置片段含 JSON/TOML/settings这一节直接给可复制的配置。不管你用哪种方式管理配置核心三件套是 Base URL、API Key、Model ID。先给一个通用的 JSON 配置文件放在项目根目录的config/taotoken.json{ base_url: https://taotoken.net/api, api_key: sk-your-taotoken-key-here, default_model: gpt-4o, timeout: 120, max_retries: 3 }如果你用 Python 的 openai 库读取配置后初始化客户端import json from openai import OpenAI with open(config/taotoken.json, r, encodingutf-8) as f: cfg json.load(f) client OpenAI( base_urlcfg[base_url], api_keycfg[api_key], timeoutcfg[timeout], max_retriescfg[max_retries], )如果你习惯用 TOML 管理比如在pyproject.toml或独立的taotoken.toml里[taotoken] base_url https://taotoken.net/api api_key sk-your-taotoken-key-here default_model gpt-4o timeout 120 max_retries 3读取方式import tomllib from openai import OpenAI with open(taotoken.toml, rb) as f: cfg tomllib.load(f)[taotoken] client OpenAI( base_urlcfg[base_url], api_keycfg[api_key], timeoutcfg[timeout], max_retriescfg[max_retries], )如果你在 VS Code 里用 Cline 或类似插件做评测脚本调试settings 里通常需要填 Base URL 和 Key。以 Cline 的 MCP 配置为例在cline_mcp_settings.json里{ mcpServers: { taotoken-eval: { command: python, args: [-m, crebench_eval.server], env: { OPENAI_BASE_URL: https://taotoken.net/api, OPENAI_API_KEY: sk-your-taotoken-key-here, DEFAULT_MODEL: gpt-4o } } } }注意这里的三件套必须齐全Base URL 是https://taotoken.net/apiKey 是你控制台创建的Model ID 在请求时通过model参数传入。如果你用 Codex 类的 CLI 工具auth.json里通常这样写{ openai: { base_url: https://taotoken.net/api, api_key: sk-your-taotoken-key-here } }配置写完后先别急着跑 CreBench 全量评测用一条最小请求验证通道是否通。下面这段代码发一张测试图加一句 prompt确认返回结构正常resp client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: You are a creativity evaluator.}, {role: user, content: [ {type: text, text: Describe this image in one sentence.}, {type: image_url, image_url: {url: https://example.com/test.jpg}} ]} ], max_tokens200, ) print(resp.choices[0].message.content)如果这一步返回正常说明 Base URL、Key、Model ID 三件套配置无误可以进入 CreBench 的评分 prompt 构造。如果报错先看第 5 节的排查对照表。4. 验证请求与多模态创造力打分成功结果配置通了之后下一步是把 CreBench 的 12 指标 rubric 塞进 prompt让模型对一张创意作品图输出结构化评分。我构造的评分请求分三部分system prompt 定义评分规则user message 包含图片和创意过程描述最后要求 JSON 输出。先看 system prompt 的写法SYSTEM_PROMPT 你是创造力评估专家需要按照 CreBench 的 12 个指标对创意作品打分。 评分采用 5 分制每个指标必须给出 1-5 的整数分和一句理由。 Creative Idea: - Originality: 1完全常见, 5高度原创 - Appropriateness: 1与任务无关, 5高度契合任务目标 Creative Process: - Immersion: 1明显敷衍, 5深度投入 - Divergence: 1思路单一, 5多方向发散 - Structuring: 1结构混乱, 5结构清晰 - Evaluation: 1无自我评估, 5有明确取舍依据 - Elaboration: 1细节缺失, 5细节丰富 Creative Product: - Effectiveness: 1无法实现目标, 5高效达成 - Aesthetic: 1美感差, 5美感强 - Novelty: 1无新意, 5显著新颖 - Manufacturability: 1无法制造, 5易于制造 - System Complexity: 1过于简单, 5复杂度恰当 必须返回 JSON格式如下 {scores: {Originality: {score: 4, reason: ...}, ...}, overall: 3.8} 然后构造请求把图片和创意过程描述一起发过去import base64 def encode_image(path): with open(path, rb) as f: return base64.b64encode(f.read()).decode(utf-8) img_b64 encode_image(samples/creative_work_01.jpg) resp client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: [ {type: text, text: 创意过程描述作者先发散出 5 个方向最终选择将废旧塑料瓶改造成模块化花盆过程中迭代了 3 版结构。请按 12 指标打分。}, {type: image_url, image_url: {url: fdata:image/jpeg;base64,{img_b64}}} ]} ], max_tokens1500, temperature0.2, ) import json result json.loads(resp.choices[0].message.content) print(json.dumps(result, ensure_asciiFalse, indent2))成功返回的结果应该类似这样{ scores: { Originality: {score: 4, reason: 将废旧塑料瓶转化为模块化花盆在材料再利用方向上有明显新意}, Appropriateness: {score: 5, reason: 完全契合可持续设计任务目标}, Immersion: {score: 4, reason: 过程描述显示作者迭代了 3 版结构投入度较高}, Divergence: {score: 4, reason: 先发散 5 个方向再收敛发散性良好}, Structuring: {score: 4, reason: 从发散到收敛到迭代结构清晰}, Evaluation: {score: 3, reason: 有取舍但依据描述不够具体}, Elaboration: {score: 4, reason: 模块化设计细节较丰富}, Effectiveness: {score: 4, reason: 花盆功能可实现}, Aesthetic: {score: 3, reason: 造型简洁但美感中规中矩}, Novelty: {score: 4, reason: 材料再利用角度有新意}, Manufacturability: {score: 4, reason: 塑料瓶加工难度低}, SystemComplexity: {score: 3, reason: 模块化增加了一定复杂度但可控} }, overall: 3.8 }拿到这个结果后你可以做两件事验证链路是否可靠。第一把同一张图同一段描述重复请求 3 次看 12 指标分数的方差如果方差过大说明 temperature 需要调低或 prompt 需要加 few-shot 示例。第二换一个模型 ID比如换成 Gemini 2.5 Vision 或本地部署的 CreExpert用同一套 prompt 跑对比 overall 分数和人类标注的差距。CreBench 论文里 CreExpert 的 Overall PCC 是 65.50%GPT-4V 是 29.27%你可以用这个作为参照判断你的评测链路是否复现出了类似的趋势。如果你想快速验证模型对话能力而不写代码可以直接用模型对话页面 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 手动上传图片测试评分 prompt 的效果确认 prompt 稳定后再落到脚本里批量跑。5. 本篇常见错误排查401、local proxy failed、reading choices、OAuth复现 CreBench 评测链路时报错集中在几个地方。下面按真实报错对照排查。401 Unauthorized最常见的原因是 Key 没填对或 Base URL 写错。检查config/taotoken.json里的api_key是否以sk-开头base_url是否是https://taotoken.net/api注意不要多加/v1也不要带 UTM 参数。如果你用的是环境变量确认OPENAI_API_KEY和OPENAI_BASE_URL都设置了且没有被子进程覆盖。还有一种情况是 Key 被删除或过期去控制台 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 重新创建一个。local proxy failed / connection refused这个报错通常出现在你本地起了代理但代理没运行或者环境变量里残留了HTTP_PROXY/HTTPS_PROXY指向一个不存在的端口。排查方法是先在终端curl -I https://taotoken.net/api看能否通如果不通就检查网络配置。另外如果你在 Docker 里跑评测脚本容器内的 localhost 和宿主机的 localhost 不是一回事需要把 Base URL 换成宿主机的可达地址或者直接在容器内配置网络。reading choices 报错 / KeyError: choices这个错误说明返回的 JSON 里没有choices字段通常是请求被拒绝或返回了错误结构。先打印resp的原始内容看是什么。常见原因是 model ID 写错了比如把gpt-4o写成了gpt4o或者用了 TaoToken 不支持的模型名。另一个原因是图片 base64 太大超过了请求限制把图片压缩到 1MB 以内再试。还有一种情况是max_tokens设得太小模型还没输出完就被截断导致 JSON 解析失败——把max_tokens调到 1500 以上。OAuth 相关报错如果你用 Codex 类 CLI 工具auth.json里同时存在 OAuth token 和 API Key 时可能冲突。解决方法是清空 OAuth 字段只保留base_url和api_key。如果你用 Claude Code 做评测脚本的润色或辅助编码接入时同样需要三件套Base URL 填https://taotoken.net/apiKey 用控制台创建的Model ID 按需选择。Claude Code 的配置入口在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 有说明按文档把三件套填全即可不要只填 Key 不填 Base URL。评分结果不稳定 / JSON 解析失败这不是接口报错但很常见。多模态模型对 JSON 格式的遵循程度不一建议在 prompt 里加一句“只返回 JSON不要加 markdown 代码块标记”然后在代码里做容错解析先尝试json.loads失败则用正则提取{...}再解析。如果还是不稳定把temperature降到 0.1 或 0并加一个 few-shot 示例。CreExpert 本地部署相关如果你在本地跑 CreExpert 做对照显存不够会报 CUDA OOM。LLaVA-1.5 7B 版本在 FP16 下大约需要 14GB 显存如果卡不够可以用 4-bit 量化加载。另外 CreExpert 的 checkpoint 需要和对应的 tokenizer 版本匹配版本不一致会报 tokenizer 相关错误按项目主页的 requirements 安装依赖。6. 把 CreBench 评测链路固化下来从单次验证到批量跑分跑通单张图的评分后下一步是把它变成可复用的批量评测脚本。我的做法是把 CreBench 的 12 指标 rubric 抽成一个独立的 prompt 模板文件把模型 ID、图片路径、创意过程描述作为变量传入输出统一存成 JSONL每行一条记录包含image_id、model_id、scores、overall、timestamp。这样你可以随时换模型 ID 做横向对比也可以把 CreExpert 的本地输出和 API 模型的输出放在同一张表里算 PCC。批量跑的时候注意两点。第一控制并发。多模态请求的响应时间比纯文本长并发太高容易触发限流建议用concurrent.futures把并发控制在 5 以内并在每次请求之间加 0.5 秒间隔。第二做好断点续跑。评测 2.2K 实例可能需要几小时脚本要支持从 JSONL 里读取已完成的image_id并跳过避免重复消耗。如果你要长期做这类评测可以考虑用 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 来管理额度把评测脚本的调用和日常编码辅助分开统计。最后说一个实测下来的经验CreBench 的 12 指标里Creative Process 维度的评分最不稳定因为“过程”信息依赖你提供的描述文本模型对描述的理解差异会直接反映在 Immersion 和 Divergence 分数上。建议在批量跑之前先固定一套创意过程描述的模板比如统一按“发散方向数 → 收敛依据 → 迭代次数 → 最终选择理由”的结构写这样不同模型之间的对比才公平。如果你只是想做模型选型先跑 Creative Product 的 5 个指标就够了Idea 和 Process 维度留到需要细粒度分析时再上。
