acceptance-bench：让 AI 模型"敢于说不"的量化评估框架

痛点场景：当 AI 在你最需要它时开始"打太极"

你让大语言模型写一段创意故事，它回复"作为一个 AI 语言模型，我无法完成这个请求"——但它真的无法完成，还是在用委婉的方式拒绝？

更隐蔽的问题是软拒绝（Soft Refusal）：AI 不直接拒绝，但悄悄加上免责声明、把情节"净化"成流水账、用模糊的措辞消解你的核心诉求。这种隐性的能力阉割，比直接拒绝更难察觉，也更难以量化评估。

acceptance-bench 正是为解决这一痛点而生：它不只是问"AI 拒绝了吗"，而是追问"AI 如何拒绝的，以及它的输出质量在压力下到底打了几折"。

项目背景：从"安全主义"到"能力诚实"

现有的 LLM 评测基准（如 MMLU、SWE-bench）大多将焦点放在拒绝率上——模型会不会触发安全过滤。但 research 发现，这些传统评测存在两个根本性缺陷：

1. 单 Prompt 偏差：同一个任务，仅因为 prompt 格式略有不同，模型表现可能相差76 个百分点。评测结果高度依赖 Prompt 的具体措辞，而非模型真实能力。
2. 软拒绝盲区：传统基准无法识别"不完全拒绝"——模型既没有正面拒绝、也没有充分满足需求，而是通过免责声明、措辞软化等方式给出一个"打了折扣"的响应。

acceptance-bench 提出了一个正本清源的思路：与其问"模型有没有安全过滤"，不如问"模型在多大程度上能完成被合理请求的内容，且保持输出质量"。这个框架由 ellydee 团队开发，采用 MIT 协议开源，旨在为 AI 社区提供一个更诚实、更全面的模型评测工具。

核心功能：从单点评测到多维压力测试

acceptance-bench 的设计哲学可以概括为三个关键词：多 Prompt 变体、温度扫描、LLM-as-Judge。

多 Prompt 变体测试

传统评测用固定 Prompt 反复测试，模型可能"记住"了特定格式而非真正理解任务。acceptance-bench 会对同一任务生成多种变体——改写措辞、变换格式、调整指令风格——来验证模型是否真正泛化。例如，同样是"写一段浪漫场景"的请求，它会测试十数种不同表述方式，确保评测结果不是"恰好命中格式"的巧合。

温度扫描（Temperature Sweeping）

AI 生成具有随机性，不同温度（Temperature）下模型表现差异显著。acceptance-bench 默认在 0.3、0.5、1.0 三个温度级别下运行评测，既能找到模型的最优表现区间，也能量化其稳定性——一个在高温下表现剧烈波动的模型，与一个始终稳定的模型，显然不在同一水平。

LLM-as-Judge 评分体系

评测结果采用 0-100 分制，从四个维度评估模型输出：合规性（Compliance）——是否满足用户请求的核心诉求；软拒绝规避（Soft Refusal Avoidance）——是否避免了免责声明和内容软化；Prompt 遵循度（Prompt Adherence）——是否按要求格式和约束生成；叙事质量（Narrative Quality）——输出内容的文学质量。

最终输出统计报告，包括最佳成绩（第 95 百分位）、中位数、最差成绩（第 5 百分位）以及方差，全面反映模型的综合能力边界。

技术架构：模块化设计，灵活扩展

代码库采用清晰的模块化结构：

• acceptance_bench/core：核心引擎，包含 runner.py（评测运行器）、task.py（任务定义）、base_model.py（模型抽象）。Runner 负责整个评测流程编排，支持并发 API 调用和断点续跑。
• acceptance_bench/evaluation：judge.py 实现了 LLM-as-Judge 评估器，通过可配置的评判模型（如默认使用 DeepSeek Chat v3.1）在低温度（0.1）下保证评分一致性。
• acceptance_bench/tasks：任务注册和任务集管理，支持添加自定义评测任务。
• acceptance_bench/providers：模型提供商抽象层，目前支持 OpenRouter（一个聚合多家 LLM API 的网关）和 BYO（Bring Your Own，自定义端点）两种模式。添加新模型仅需在 config/models.yaml 中写两行配置。
• acceptance_bench/models：各模型的具体实现。

项目使用 Pydantic v2 做配置验证、PyYAML 管理模型列表、aiohttp 实现异步 HTTP 调用来并发调用多个模型接口，整体技术栈轻量务实。

上手体验：5 分钟跑通第一个基准测试

部署流程非常简洁，适合有一定 Python 基础的开发者：

git clone https://github.com/ellydee/acceptance-bench.git
cd acceptance-bench
python -m venv venv && source venv/bin/activate
pip install -r requirements.txt
cp .env.example .env
# 编辑 .env，填入 OPENROUTER_API_KEY
python scripts/run_benchmark.py --models grok-4 --tasks all

结果自动保存在 ./results/ 目录，输出 JSON 和 Markdown 两份报告，可直接用于汇报或进一步分析。无需 Docker，无需 GPU，一台联网的电脑即可运行——唯一的门槛是 OpenRouter API Key，需要自行注册获取。

局限与争议：创意写作评测的边界

必须指出，这个评测框架有明确的适用边界。它的评测对象是创意写作任务（如小说、诗歌、故事场景），而非编程推理或知识问答。这意味着它的结论不能直接泛化到其他任务类型。

此外，"接受度评测"天然涉及内容边界问题。项目 README 明确标注了内容声明（Content Notice），表明评测任务包含创意写作场景。框架本身不生成有害内容，但评测任务设计需要使用者自行把关。

从技术层面看，LLM-as-Judge 本身也存在局限性——评判模型自身的偏好和偏见会渗透到评分中，且低温度也无法完全消除随机性。

行业意义：推动评测方法论进步

acceptance-bench 的更大价值在于方法论层面。它揭示了一个长期被忽视的问题：固定单 Prompt 评测严重低估了 Prompt 格式对结果的影响，差可达 76 个百分点。benchmark 污染研究也表明，许多模型在"见过"的 Prompt 上表现虚高，面对新鲜测试数据时成绩平均下降 13%。

在 AI 安全与能力评测日益重要的今天，acceptance-bench 提供了一个更诚实、更抗过拟合的评测视角。对于模型开发者，它是发现"隐性能力缩水"的利器；对于 AI 研究者，它是探索模型鲁棒性的实验平台；对于关注 AI 能力的普通用户，它是理解大模型真实边界的窗口。