1.9B 当决策引擎NeoHorse-1-9B 接入工单分流的最小实现【免费下载链接】NeoHorse-1-9B项目地址: https://ai.gitcode.com/hf_mirrors/TokenRhythm/NeoHorse-1-9B工单分流Ticket Routing是客服与运维系统里最典型的文本 → 结构化决策任务把一段非结构化描述映射成类别、优先级、分派人这几个封闭取值。过去十年它靠规则引擎和人工兜底运转代价是长尾表达不断侵蚀规则库、条件组合爆炸、维护成本随业务增速线性恶化。引入通用大模型后问题变成了另一面输出格式不可控、延迟与显存成本不可接受、失败时连为什么这么分都解释不了。NeoHorse-1-9B 是 TokenRhythm基元律动发布的 Agent-Native 模型 NeoHorse-1 系列中的 9B 档位同系列另有 4B 版本由 Qwen3.5-9B 经 routing harness 驱动的 Agentic 后训练而来。本文以工单分流为靶场景给出一个可运行的最小实现先用仓库自带的部署方式拉起 OpenAI 兼容服务再用 JSON Schema 约束输出最后用评测数据说明格式合规率与边界样本表现。全程只依赖仓库内文件不引入任何第三方推理栈。一、场景定义工单分流为什么适合 9B 级决策模型先看清任务本质。一条工单的分流决策可以拆成四个字段category账单/技术/账号/产品/其他、priority低/中/高/紧急、assignee一级/二级/账单组/产品组、confidence置信度。这是一个输出空间封闭、取值有限、语义可枚举的任务——恰好是决策模型而非对话模型的主场。规则引擎的困境在于中间地带同样是我充了钱没到账可能是支付回调延迟technical、也可能是账号未实名account规则写不写、写到哪一层都是成本。而通用大模型擅长理解语义却难以保证输出形状——这正是社区对这类自托管决策模型的共识其价值在于输出约束性、确定性推理与格式稳定性评估应聚焦任务完成率与格式合规而非对话榜单。NeoHorse-1-9B 的模型卡README.md直接点明了它的能力取向面向 text-based agent harness、tool use、coding 与 instruction following 后训练底层是带线性注意力混合架构的 Qwen3.5-9B。仓库里的 config.json 给出了结构证据32 层中 24 层为linear_attention、8 层为full_attentionfull_attention_interval: 4配合max_position_embeddings: 262144的原生长上下文。对工单这种输入几百 token、输出一屏 JSON 的任务这意味着决策延迟可预估9B 规模在单卡上即可自托管推理路径短上下文冗余巨大262K 上下文足够把历史工单、SLA 规则、词典全部塞进 prompt输出格式被当作一等公民训练chat_template.jinja中定义了完整的tool_call/function.../parameter...结构与think推理区模型从训练期就习惯先想、再按固定语法输出。在 Agentic 维度README 的十项基准评测显示 NeoHorse-1-9B 对 Qwen3.5-9B 的宏观均值提升为69.04 vs 65.603.44其中函数调用基准 BFCL v4 拿到 67.432.55、工具协作基准 QwenClawBench 48.734.69——这些正是把意图转成机器可执行动作能力的直接度量与工单分流的认知负荷同构。二、实现步骤JSON 约束 最小推理服务2.1 拉起服务从仓库命令到本地端点README.md 的 Deployment 章节给出了两种自托管方案这里选 vLLM参数最贴近生产形态pip install -U vllm MODEL_PATH/path/to/NeoHorse-1-9B vllm serve $MODEL_PATH \ --served-model-name neohorse-1-9b \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 262144 \ --reasoning-parser qwen3 \ --enable-auto-tool-choice \ --tool-call-parser qwen3_coder需要留意两点--reasoning-parser qwen3与--tool-call-parser qwen3_coder是模型卡明确要求的参数它们让服务端把think推理块与工具调用语法从生成流中剥离出来而--max-model-len 262144是上限而非必须——工单场景实际输入远小于此调低到 8192 即可显著降低 KV 缓存显存占用。权重侧model.safetensors.index.json 显示总权重 17.9GBBF16 四分片单张 24GB 显存卡可全量加载量化后可进一步下探。2.2 定义输出约束JSON Schema 是唯一接口分流结果的正确性一半取决于解码约束。把决策字段声明为 JSON Schema交给服务端的 guided decoding让模型只能在合法 JSON 的 token 序列里搜索ROUTING_SCHEMA { type: object, properties: { category: {type: string, enum: [billing, technical, account, product, other]}, priority: {type: string, enum: [low, medium, high, urgent]}, assignee: {type: string, enum: [tier1_support, tier2_engineer, billing_ops, product_team]}, confidence:{type: number, minimum: 0.0, maximum: 1.0}, summary: {type: string} }, required: [category, priority, assignee, confidence] }enum在这里是关键它把开放文本生成压缩成从预设枚举中选择模型不需要自由发挥类别名上游消费方分派系统、SLA 计时器也无需做字符串归一。配套的 system prompt 只描述映射规则不描述输出格式——格式完全由 Schema 接管你是工单分诊引擎。根据工单内容做分流决策。 规则 - 金额、发票、退款、扣费问题 → billing - 崩溃、报错、无法登录、接口异常 → technical - 账号权限、资料修改、实名认证 → account - 功能咨询、需求建议、使用疑问 → product - 无法判断或信息不足 → other 只输出符合给定 JSON Schema 的 JSON不要输出任何解释。2.3 最小推理服务30 行接入服务端暴露的是 OpenAI 兼容接口客户端只需一个 HTTP 调用import json, requests def route_ticket(text: str) - dict: resp requests.post( http://localhost:8000/v1/chat/completions, json{ model: neohorse-1-9b, messages: [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: f工单内容{text}}, ], temperature: 0, max_tokens: 512, guided_json: ROUTING_SCHEMA, # vLLM guided decodingSGLang 对应 json_schema 参数 }, timeout30, ) return json.loads(resp.json()[choices][0][message][content])两个参数是决策场景的底线temperature: 0保证同一条工单重复调用结果确定社区实践亦强调决策模型应使用低温采样与 JSON 强约束guided_json让解码器在每一步只放行符合 Schema 的 token从机制上消灭JSON 解析失败这一类故障。值得说明的是README.md 中评测协议写的是temperature1.0 / top_p0.95 / top_k20 / presence_penalty1.5那是为了覆盖采样空间的评测配置与生产决策的确定性诉求是两套参数——接入时不要照抄评测协议。2.4 双引擎兜底模型只做规则做不了的事最小实现不等于全量替换规则。生产上更稳的组合是规则前置、模型补位def safe_route(text: str) - dict: hit regex_rules(text) # 精确关键词规则先拦截 if hit: return hit try: decision route_ticket(text) validate(decision, ROUTING_SCHEMA) return decision except (json.JSONDecodeError, KeyError, AssertionError, requests.RequestException): return {category: other, priority: low, assignee: tier1_support, confidence: 0.0, summary: fallback: model unavailable}规则层拦截高置信的确定性样本省推理成本模型处理长尾语义校验层守住输出契约。confidence字段此时不是装饰——低于阈值如 0.6的工单自动转人工复核这比任何模型全权接管都更容易通过风控评审。多轮工单或附加上下文时chat_template.jinja对应 chat_template.jinja 与 tokenizer_config.json 中的|im_start|/|im_end|结构保证了历史消息的正确拼接无需手写 prompt 模板。三、效果评估格式合规率与边界样本表现3.1 格式合规率从祈祷解析成功到解码器保证在guided_json约束下输出在语法层必然合法这是约束解码与纯 prompt 提示的本质差别——后者只能靠模型训练印象维持格式README 中 IFEval 89.09、IFBench 66.33 反映的正是无约束条件下的指令遵循能力。真正需要评估的合规率因此上升一个层级语义合规即输出的category/assignee是否匹配工单的真实意图。这需要抽样标注统计口径建议拆成三项语法合法率约束解码下应为 100%作为回归测试门槛枚举命中率enum之外不允许新值语义准确率标注人员与模型判断一致的比例。3.2 边界样本模型的真正试金石规则引擎与模型的差距集中在边界样本上。以工单场景为例值得构造的对抗样本至少包括多意图混叠帮我改绑手机号顺便查一下上次扣款——涉及 account 与 billing 双类别、模糊优先级很急但没有 SLA 关键词、否定与反讽贵司产品真是稳定又崩了、信息不足有个问题——应落入 other 而非硬猜。NeoHorse-1-9B 在这些样本上的表现可以从评测结构中间接推断tau²-Bench 90.822.78、PinchBench 82.257.70、VitaBench 42.25相对基线 11.00——后两个恰恰是工具调用路径中多步规划 边界纠错压力最大的基准。评测增量最大的能力7.7 与 11.0恰好是分流这类读一段文字、在约束下做一步决策所需的能力说明后训练把能力密度集中在了决策路径上。3.3 落地观测清单上线后的评估不能停在一次性测试集。建议把三项指标做成持续观测兜底触发率safe_route回退次数占比超过 5% 说明 Schema 或 prompt 与真实工单分布脱节置信度校准按confidence分桶统计人工复核的改判率高置信高错误率的分桶提示过度自信决策模型通病决策日志闭环每条分流结果连同原始工单落库作为后续 LoRA 微调与规则补充的数据源——这与模型卡描述的 routing harness 思路同构执行轨迹回流成为下一轮训练的输入。至此一个可运行的工单分流最小实现已经闭合vLLM 拉起 README.md 中的服务参数 → JSON Schema 约束决策空间 →temperature0保证确定性 → 规则前置 校验兜底 → 评测与日志驱动迭代。整个链路没有依赖任何云端 API17.9GB 权重在单卡上完成自托管换来的是可控的成本、可解释的决策字段与可审计的日志——这或许才是1.9BNeoHorse-1 系列 9B 档当决策引擎最实际的注脚不追求替换所有规则只接管规则够不着的那部分长尾。【免费下载链接】NeoHorse-1-9B项目地址: https://ai.gitcode.com/hf_mirrors/TokenRhythm/NeoHorse-1-9B创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考