别拿对话榜单衡量决策模型：评测方法之争比模型本身更值得吵

别拿对话榜单衡量决策模型评测方法之争比模型本身更值得吵【免费下载链接】NeoHorse-1-4B项目地址: https://ai.gitcode.com/hf_mirrors/TokenRhythm/NeoHorse-1-4B当一款模型发布时人们习惯性地打开对话榜单MMLU 多少分、GSM8K 多少分、HumanEval 多少分然后迅速得出结论强或不强。但这种惯性正在失效——至少对于以执行任务、操作工具、达成目标为目的的决策型模型这套以答对一道题为单元的评测逻辑衡量不了模型在真实业务流程中能否把事办成。基元律动TokenRhythm联合无问芯穹、清华、北大、阿里等机构发布的 Agent-Native 模型 NeoHorse-14B/9B 两个版本恰好提供了一个观察窗口它的技术报告不再把重心放在能答多好而是放在能完成多少任务——这份 4B 版权重发布在 README.md 中给出了完整的数据与评测协议。围绕它的社区讨论也几乎都指向同一个主题决策模型该用任务完成率衡量而不是对话榜单。这篇文章不打算重复4B 打败 9B之类的口号而是拆解评测方法之争本身对话榜为什么失灵、任务完成率怎么测、榜单与业务价值为何错位以及各方到底在争什么。对话榜为什么失灵测的是说话不是办事对话榜单的典型形态是给模型一个静态问题等一个静态答案然后与参考答案比对。这套机制默认了模型的工作场景是问答——输入完整、目标明确、无需与环境交互。而决策模型的工作场景完全不同它需要调用工具、接收工具返回、根据反馈修正下一步直到任务闭环。这在 NeoHorse-1-4B 的对话模板 chat_template.jinja 中体现得淋漓尽致。模板里内置了一套完整的工具调用协议tool_call functionexample_function_name parameterexample_parameter_1 value_1 /parameter /function /tool_call同时定义了tool_response包裹的反馈格式并要求函数调用必须以规定的 XML 格式嵌套在tool_call标签内。再看模型配置 config.jsoneos_token_id指向|im_end|词表中注册了tool_call、tool_response、think等一整族决策专用 token见 tokenizer_config.json。一个对话模型需要这种东西吗不需要。这些设计的存在说明NeoHorse-1-4B 的训练目标根本不是生成一段漂亮的回答而是生成一个可被系统解析、可驱动下一次动作的结构化决策。这就是对话榜失灵的根源对话榜单不奖励正确调用工具后成功拿到结果只奖励答案文本与参考答案的相似度。一个在 10 轮工具调用中 8 次成功、最后交付正确结果的任务执行者在对话榜上的得分可能远低于一个只会说漂亮话的聊天机器人而一个在 2 轮内就放弃任务、输出一段文不对题总结的模型对话榜上反而可能拿到不错的流畅度分数。评测单元错了结论自然没有意义。任务完成率导向的评测设计从答案到闭环NeoHorse-1-4B 的做法是把评测单元从问答换成任务闭环。README.md 中的十基准评测表清晰地体现了这一分层能力分组基准NeoHorse-1-4B对比基准Qwen3.5-4BAgenticQwenClawBench44.6838.476.21AgenticWorkBuddy Bench34.4124.629.79AgenticPinchBench77.3371.196.14AgenticVitaBench32.0021.5010.50AgenticBFCL v461.7961.020.77Agentictau2-Bench88.4684.294.17CodingHumanEval96.9587.209.75CodingLiveCodeBench v659.4353.715.72Instruction FollowingIFBench65.3360.335.00Instruction FollowingIFEval88.3587.061.29Overall十基准均值64.8758.945.93注意表中 Agentic 组占六席QwenClawBench、WorkBuddy Bench、PinchBench、VitaBench、BFCL v4、tau2-Bench——它们测的不是模型知道什么而是模型在模拟环境中能否完成一系列需要工具调用的真实任务。这类基准的评分机制与对话榜有本质差异多轮执行而非单轮问答任务由若干步组成中途的每次工具调用都可能改变后续状态结果可验证而非文本比对以目标是否达成如任务是否解决、函数是否按规格实现作为得分依据奖励错误恢复一次调用失败后能否根据反馈调整策略是重要的能力分项。更值得注意的是 README 中披露的评测协议——它不是默认参数跑一遍SGLang v0.5.17 ·temperature1.0·top_p0.95·top_k20·min_p0.0·presence_penalty1.5·repetition_penalty1.0· thinking mode enabled withenable_thinkingtrueandforce_nonempty_contenttrue。QwenClawBench、WorkBuddy Bench、tau2-Bench 各跑三轮PinchBench 与 VitaBench 各跑一轮。这段协议至少透露三个评测设计要点其一决策任务带有随机性多轮取平均才可比较单轮分数没有统计意义其二enable_thinkingtrue意味着评测明确允许模型先思考再行动思考质量本身也被纳入评估轨道其三采样参数刻意宽松temperature1.0因为决策评测要测的是分布行为而非一次抽样的运气。社区实操中进一步补充了任务完成率导向的指标体系格式合规率输出能否被 JSON/工具解析器稳定解析、边界样本准确率接近业务边界的决策是否稳健、置信度校准模型自信程度是否与实际正确率匹配——这些指标在传统对话榜上根本不存在却在工单分派、工业质检、风险判断等结构化决策场景中直接决定系统的可用性。这也解释了为什么社区大量实战文章反复强调temperature0、JSON 强约束、规则模型协同等工程要点评测逻辑变了使用方式必须跟着变。榜单与业务价值的错位分数不等于能落地对话榜单还有一个更隐蔽的问题它天然向大倾斜——参数越多、资源越充足通常分数越高。而业务决策场景的约束是反过来的模型必须跑在有限的显存上、必须在延迟预算内返回、必须能被私有化部署、必须输出可被下游系统消费的结构化结果。NeoHorse-1-4B 的架构选择正是围绕这些约束展开的。config.json 显示32 层 Transformer 中只有 8 层使用全注意力full_attention其余 24 层为linear_attention含conv1d、dt_bias、A_log等线性注意力/状态空间参数配合max_position_embeddings: 262144的 26 万上下文窗口。这种少数全注意力层 多数线性注意力层的混合结构本质上是在长上下文代价与记忆能力之间做的工程取舍——权重索引 model.safetensors.index.json 中两层分片的 8.4GB 体量也印证了它在消费级硬件上可推理的定位。这些取舍在对话榜上不值钱在业务上却是硬通货部署成本4B 量级意味着单卡即可运行社区实测覆盖 GGUF 量化、vLLM、Ollama、llama.cpp 等全链路甚至可跑在边缘设备许可自由度Apache-2.0 协议见 README.md 的 License 章节允许商用闭源改造这是企业内网私有化部署的前提可审计性决策模型的价值不在回答正确而在决策过程可解释、可回溯、可被规则校验——这是对话榜完全无法量化的维度。再看训练路线。澎湃新闻对技术报告的报道指出NeoHorse-1 的训练语料以包括 OpenSquilla基元律动的开源 Routing Harness在内的执行轨迹为核心每条轨迹保留了能力需求预测、路由选择、模型响应、工具调用和环境反馈经目标完成度、证据一致性、错误恢复等质量评估后用于后训练。README 也将其总结为routing-guided curriculum SFT routing-guided on-policy distillation。换句话说这个模型的成绩单不是靠题库刷出来的而是靠真实执行轨迹中做没做成的信号塑造的——训练信号与评测信号同源这正是它敢在任务完成率维度上说话的底气。这带来一个直接的启示当评测维度从知识转向执行模型的能力边界就不再由参数量决定而由执行环境、工具接口、反馈回路决定。一个 30B 的通用模型在 4GB 显存上跑不起来业务价值就是零一个 4B 的决策模型能在同样的硬件上稳定完成任务业务价值就是一。对话榜不会告诉你这些。各方立场与建议评测该往哪里走围绕决策模型怎么评的分歧本质上反映了三类参与者的不同利益诉求模型开发方主张任务完成率优先。NeoHorse-1 的技术路线本身就是这种立场的体现用 Routing Harness 记录工具交互与结果把能力级反馈回灌给下一轮训练混合比形成评测—选择—更新的闭环。在他们看来评测不仅是打分更是下一轮训练数据的筛选器——对话榜无法承担这个角色因为答得漂亮不是可复用的训练信号而任务成功/失败是。评测方与研究者的顾虑是标准化。任务完成率依赖具体环境工具集、模拟器、判定器换个环境分数就可能失真可复现性和横向可比性都弱于静态基准。README 特意披露完整采样协议、跑数轮数、判定器版本如 VitaBench 使用 DeepSeek-V4-Flash 模拟器与裁判正是为了缓解这种担忧——但这也说明任务完成率评测的实验条件必须像论文一样严格报告否则就是新的营销工具。落地开发者关心的是成本与可预测性。社区大量实操文章的共同结论是决策模型选型时与其看榜单总分不如看三类硬指标——格式合规率解析失败率必须低到可接受、边界准确率业务红线附近不能翻车、以及延迟/显存在目标硬件上能不能跑。这是以业务价值为准绳的务实评测观。综合各方的合理主张可以提炼出三条可操作的建议双轨评测知识型任务沿用对话榜单决策型任务必须用任务完成率基准如 tau2-Bench、BFCL 类加业务侧指标格式合规率、置信度校准双轨报告避免单一数字误导选型公开实验条件任务完成率评测必须报告协议——采样参数、跑数轮数、模拟器与判定器版本、上下文长度否则分数不可复现也不可比回归业务闭环最终极的评测是把模型放进真实流水线用任务完成率 单次成本的组合来度量让模型、提示词、规则校验、工具链作为一个整体被评估。对话榜单之争的本质是模型像不像一个博学的聊天者与模型能不能把活干完之争。NeoHorse-1-4B 用一份以 Agentic 基准为主体的成绩单、一套完整披露的评测协议和一个以执行轨迹为核心的后训练管线把这个问题摆到了桌面上评测方法决定模型被训练成什么样也决定技术社区把钱和时间花在哪里。这个争论的走向比任何单一模型的分数都更值得关注。【免费下载链接】NeoHorse-1-4B项目地址: https://ai.gitcode.com/hf_mirrors/TokenRhythm/NeoHorse-1-4B创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考