短难误判率仅2%,新一代网关路由SHG,在P95不升前提下完胜RouteLLM。

本文涉及的产品
模型在线服务 PAI-EAS,A10/V100等 500元 1个月
模型训练 PAI-DLC,100CU*H 3个月
交互式建模 PAI-DSW,每月250计算时 3个月
简介: 在和 RouteLLM 的两档式对比中 RouteLLM 将约百分之 69.3 的短难请求路由至轻量模型,而本文提出的网关系统将短难请求中落入轻档的比例压缩到约 2.4%,整体 P95 几乎不变。实验表明,短难请求构成了一类独立且在实践中高度相关的 LLM 路由稳健性问题,而针对性的、常数级开销的守护机制可以在不增加整体成本和尾部延迟的前提下,大幅缓解这一问题。

摘要


多档位大语言模型网关通常依赖轻量级路由策略在质量与成本之间做权衡,典型做法是根据长度和少量关键词等表层特征来估计请求难度。然而,在真实线上流量中,我们观察到一个系统性失效模式:大量文本较短但认知负荷较高的请求被误当作“简单问题”,被路由到小模型上处理,产生过度自信、缺乏证据或不合规的回答,而且难以仅凭 schema 检查将其识别出来。我们将这类输入称为短而难(short-but-hard,short-hard)请求:它们的长度位于整体分布的低分位区间之内,但高质量回答需要多步推理或领域专业知识。为专门应对这一失效模式,我们提出了短难守护机制(Short-Hard Guard, SHG),这是一种部署在网关入口处的轻量级语义规划机制。SHG 结合零训练的语义与风险规则、一个不超过 24 token 的难度探针以及一个不超过 32 token 的预检(pre-flight)检查,使短难请求的潜在复杂度显性化,并据此给出更保守的初始模型档位推荐。部署在三档路由器中时,SHG 能够显著重塑短难子群的路由结构,将首跳被送往轻档的比例从约 77% 压缩到约 2%,同时保持最强档位的占比不变,并维持 P95 延迟不升高。在和 RouteLLM 的两档式对比中 RouteLLM 将约百分之 69.3 的短难请求路由至轻量模型,而本文提出的网关系统将短难请求中落入轻档的比例压缩到约 2.4%,整体 P95 几乎不变。实验表明,短难请求构成了一类独立且在实践中高度相关的 LLM 路由稳健性问题,而针对性的、常数级开销的守护机制可以在不增加整体成本和尾部延迟的前提下,大幅缓解这一问题。


引言


大规模语言模型(LLM)已经被广泛部署为通用问答与助手系统,承载搜索、企业知识库问答、代码助手等多种生产级业务。为了在质量和成本之间取得平衡,工业界普遍采用多档位模型网关:将轻量模型(light)和更强大的模型(std/enh)接在同一入口,由路由策略按“任务难度”在不同档位之间分配请求。现有路由器大多依赖长度、标点密度等表层特征来估计复杂度,再辅以少量不确定性或模板信号,以实现“简单请求走 light、复杂请求走 std/enh”的成本优化目标。


然而,在真实线上流量中,我们观察到一个稳定且具有代表性的失效模式:大量文本短但认知负荷高的请求,被系统性地当作“简单任务”处理。例如,“黎曼猜想成立吗?”、“意识可计算吗?”、“相对论的数学推导过程是什么?”等请求在长度统计上与日常闲聊、简单问答几乎无异,却需要高阶数学、哲学或法律推理能力。在本文中,我们将这类请求形式化定义为短而难(short-but-hard,short-hard)任务:其一,长度落在整体请求分布的低分位区间内;其二,要得到高质量回答,必须依赖多步推理或领域专业知识,简单的模式匹配或常识回忆不足以支撑合格输出。短难任务广泛存在于开放数学猜想、伦理与意识哲学、法律条款冲突分析、技术规范解读等场景中,却在现有路由设计中缺乏专门的刻画与优化。

现有与路由相关的工作,主要集中在三类方向:


  1. 其一,基于长度或模板的启发式规划,将长上下文或结构化任务直接路由至更强档位。
  2. 其二,一条重要路线是利用小模型自身的不确定性(如基于对数概率或困惑度的置信度估计)进行动态路由:当预测被判为“不可靠”时,将请求升级到更大的模型,从而在保持整体质量的前提下降低平均成本。近期针对“小模型→大模型”不确定性路由的系统性基准工作,已经对多种不确定性估计和路由策略在多数据集上的 cost–quality 曲线进行了详细比较。
  3. 其三,另一类工作在模型内部通过门控与混合专家(Mixture-of-Experts, MoE)实现算力调度,由稀疏门控网络为每个 token 选择少量专家,从整体分布上提升有效容量与吞吐,这一方向在大规模预训练模型中已被广泛采用。
  4. 其四,近期的 RouteLLM 系统进一步将上述不确定性路由方法封装为统一框架,在多种路由器与多档大模型之间给出了细致的 cost–quality 基准,被广泛视为“弱模型→强模型”路由的代表性方案。然而,其优化目标同样侧重全局 cost–quality 曲线,并未显式刻画 short-hard 子群,显示出在“短文本但高认知负荷”场景下更强的前置保护能力。


上述方法在很多场景中是有效的,但其建模目标大多是从全局上优化 cost–quality 曲线:要么通过标量不确定性得分决定是否升级到更大的模型,要么在 MoE 中通过连续门控得分在专家之间做软/硬选择。就我们所知,现有路由基准与分析工作(如 RouterBench、GQR-Bench 等)虽然已经覆盖了多任务、多模型和 OOD/安全性等维度,并没有专门定义和评测一类“短文本但认知负荷高”的 short-hard 子群,也很少在入口路由阶段针对这类子群设计专门的保护机制。在实际系统中,这类 short-hard 请求通常仍然依赖“轻模型先试—失败或高不确定性后再升级”的事后补救路径,从而在长尾体验和合规风险上暴露出额外成本。

为系统性解决这一问题,本文从工程实践出发,聚焦“短难”这一狭窄但关键的稳健性挑战,做出以下三方面工作:

  1. 形式化提出 short-hard 任务并构造短难基准集 Short-Hard-39。基于真实网关日志,我们以长度分位(P40)、领域标签和符号/算子信号为过滤条件,从短文本池中筛选候选样本,再由多名具备相关背景的标注者进行“困难”标注与仲裁,构造出一个可审计、可复现的短难评测集 Short-Hard-39,用于量化短难子群在现有系统中的路由偏差、质量退化与尾部延迟放大效应。
  2. 提出短难守护机制 Short-Hard Guard(SHG),在入口侧显性化短难复杂度并给出保守首跳建议。SHG 部署于一个三档 LLM 网关的入口,通过零训练语义/风险规则、一个不超过 24 token 的难度探针以及一个不超过 32 token 的预检(pre-flight)检查,将短难请求的潜在复杂度显性化,输出单调、有界且可解释的复合复杂度分数和首跳模型档位建议。一旦命中短难信号,SHG 将强制请求至少从 std 档位起步,必要时允许一次受控升级,从结构上抑制“短而难任务被误送至 light”的错误路径,同时将新增算力开销严格限制在常数级前置项。
  3. A/B 评估验证 SHG 对短难路由与长尾延迟的影响。在 499 个有效样本(涵盖 Short-Hard-39 及相邻高复杂度请求)上的离线专项测试中,我们对比了禁用 SHG 与启用 SHG 两种配置。结果表明,SHG 能够显著重塑短难子群的路由结构:被送往 light 档的比例从约 77% 降至约 2%,std 档位吸收了绝大多数短难请求,而昂贵档位的占比保持不变;在沿用 §7 中同一组 CO-corrected P95(Overall)护栏的前提下,短难子群的 P95 延迟基本不升高,仅 P50 中位延迟因从 light 向 std 的成本再分配而小幅上升。结果表明,短难请求构成了一类独立且在实践中高度相关的 LLM 路由稳健性问题,而针对性的常数级守护机制可以在不增加整体成本和尾部延迟(在本实验设定下)的前提下,显著缓解这一结构性错配风险。同时在我们构造的短难基准上,在和 RouteLLM 的对比中将约百分之 69.3 的短难请求路由至 4B,而本文提出的网关系统将短难请求中落入轻档的比例压缩到约 2.4%,整体 P95 几乎不变。


2 问题设定与 Short-Hard 基准

2.1 系统设定:多档位 LLM 网关


本文关注的是一类多档位大模型网关系统。抽象来看,系统由三个部件构成:

  • 一个统一入口的请求接入层;
  • 一个按“任务难度”分档的模型池 A = {light, std, enh},分别对应轻量模型、中档模型与昂贵模型;
  • 一个带升级机制的路由与执行逻辑。

对每个用户请求 x(包含提示词、上下文与必要的系统参数),入口路由器会先选定一个“首跳档位” a₀ ∈ A,然后交给该档位的模型执行推理。若首跳结果不满足系统的质量或契约要求(例如:结构化输出失败、明显幻觉、拒答等),执行器可以触发有限次数的“升级”(upgrade),将请求递交更高档位的模型继续处理。

在这种设置下,我们关心的不是“选哪个具体模型”,而是对于给定请求子群,首跳档位是否匹配其真实难度。特别地,对于本文关注的短而难(short-hard)任务,如果首跳被送往 light 档位,而高质量回答实际需要至少 std 档位能力,我们就将其视为一次路由误判;后续触发的同层重试与升级,会直接反映到该子群的长尾延迟与成本上。

在整个实验与分析中,我们假定:

  • 路由器只能基于请求本身及有限的规划信号(例如长度、领域/算子标签、小模型探针分数等)做决策;
  • 对每个请求,我们都记录首跳档位、升级次数以及端到端延迟,用于后续对 short-hard 子群进行专门评估。


2.2 “短而难”的形式化定义


直观上,short-hard 查询是“字数很少,但要答好很难”的请求。为了在工程和评测上可操作,我们将其形式化为一个满足以下条件的子集:

短(short)

记真实流量中请求长度(可以是 token 数)的一维经验分布为 L。我们选取其中位于第 40 分位的长度阈值 L = P40(L),并将所有长度满足 len(x) ≤ L 的请求视为“短请求候选”。这样可以避免只看绝对长度、忽略不同业务分布差异的问题。


高认知负荷(hard)

在“短请求候选池”内部,我们进一步依赖领域信号与算子/符号信号筛选出更可能需要深度推理的样本:

  • 领域标签:请求被自动或半自动标注为 STEM(数学、物理、计算机科学等)、哲学、法律、政策等需要专业背景的领域;
  • 算子/符号信号:文本命中一小套与高难度推理强相关的符号或模式,例如 lim, ∑, ∫, ∀, ⇒、LaTeX 片段、形式逻辑记号,或者与“条款冲突”“合规界定”相关的法律表述。

满足上述任一条件的短请求,被视为 short-hard 候选。


人工黄金标签(gold hardness)

为了得到可审计的“困难”黄金标准,可以在 short-hard 候选池上进行人工标注:

  • 由两名具有相关背景(如数学/逻辑、哲学或法律)的标注者独立判断该请求是否“需要多步推理或专业知识,才能给出合规且有证据支撑的回答”,得到二值标签 hard / non-hard;
  • 若两者意见不一致,则交由第三名标注者仲裁;
  • 计算 Cohen’s κ 作为一致性指标,要求 κ ≥ 0.75,确保“困难”标签具有足够可靠性。

最终,将所有满足:

  • len(x) ≤ L,且
  • 自动筛选命中领域/算子信号,且
  • 被黄金标注为 hard

的请求集合,定义为本文的 short-hard 查询集合。在后续评测中,我们对该集合赋予一个简单的“理想路由要求”:首跳档位不应低于 std;即只要 short-hard 查询首跳被路由到 light,就被视为一次路由误判。


2.3 Short-Hard Benchmark 构造:两阶段流程

为了将上述定义落实为一个可复用的基准,我们采用一个两阶段流程来构造 Short-Hard 基准。该流程同时服务于两个目标:一是对“短而难”任务给出可审计的黄金集合;二是保证不同路由策略和系统配置之间可以在同一标尺下比较。

阶段一:离线黄金标准构建

这一阶段是一项一次性的离线工作,旨在产出一个高质量的、可公开审计的测试集。

候选采样与长度过滤

从真实网关日志(或具有代表性的请求池)中抽取若干天/若干批次的请求,计算长度分布 L 并确定短请求阈值 L。在此基础上,仅保留 len(x) ≤ L 的短请求样本。

领域与算子筛选

对短请求样本进行自动分析,筛选命中目标领域标签(STEM、哲学、法律、政策等)或包含高认知负荷符号(数学算子、逻辑符号、LaTeX 片段等)的请求。得到一个规模适中的 short-hard 候选池。

专家标注与一致性评估

在 short-hard 候选池上进行专家标注:两名标注者独立给出 hard / non-hard 标签,冲突样本交由第三人仲裁。计算 Cohen’s κ 并要求 κ ≥ 0.75,确保“困难”标签在统计意义上可靠。

代表性子集:Short-Hard-39

在标注完成的 hard 样本中,我们挑选出一组具有代表性的短难问题,构成 Short-Hard-39 基准子集。挑选原则包括:

  • 问法简短(受长度阈值约束);
  • 覆盖数学猜想、哲学悖论、未决法律/政策判定等典型类别;
  • 避免重复或高度相似的问题。

这一阶段的输出,是一个带有明确 hard 标签和辅助元数据(长度、领域、算子信号等)的静态测试集,其中 Short-Hard-39 用于精细分析与展示,扩展集(含其相邻高复杂度请求)用于量化评估。

阶段二:系统级评测与路由行为观测

在黄金测试集构建完成后,第二阶段用于对不同系统配置在 short-hard 子群上的行为进行对比评测。流程如下:

系统配置与路由策略

固定模型池 {light, std, enh},分别加载具体模型实例(例如 qwen3-4b / 8b / 14b),在相同的解码参数和超参数下,设置不同的路由策略:

  • 启发式基线:仅使用启发式复杂度估计与既有升级逻辑;
  • 启用 SHG 的配置:在入口规划阶段加入短难守护机制。

静态重放与自动化评测

将 Short-Hard-39 及其邻域构成的测试集(共 499 个有效样本)以统一的请求格式输入各系统配置。对于每个请求 x,系统自动记录:

  • 首跳档位 a₀;
  • 升级次数(若有)与最终档位;
  • 端到端延迟(Raw/CO,两种口径);
  • 输出是否满足基本契约(如结构化输出成功与否)。

误路由与延迟指标

结合 short-hard 黄金标签,我们定义并统计:

  • 误路由率:short-hard 请求首跳被路由到 light 的比例;
  • 升级触发率:short-hard 请求中触发升级的比例(以及平均升级次数,可在后文实验展开);
  • 长尾延迟:在 CO-corrected P95(Overall)口径下的延迟表现,以及 P50 中位延迟作为辅助指标。

这一阶段完全自动化执行,不再引入人工参与。通过“固定测试集 + 可重放日志”的方式,我们可以在相同 short-hard 样本上,对比不同路由策略的误路由率和长尾表现。


2.4 启发式规划器在 short-hard 上的错误模式与评估指标

在引入短难守护机制之前,系统使用的是一个启发式规划器基线:它通过长度、标点密度、模板命中等表层信号构造复杂度分数 score_base(x),并结合既有的风险规则与升级逻辑,决定首跳档位与是否升级。这种规划器在整体流量上可以取得不错的成本–质量折中,但在 short-hard 子群上,存在一类具有代表性的错误模式:

短文本即简单的先验偏见

由于长度被显式或隐式地视为“容易程度”的 proxy,许多形式上非常短、但语义上极为困难的问题(例如“黎曼猜想成立吗?”,“意识可计算吗?”,“该条款是否与第 7.2 条构成冲突?”)会被误判为“简单请求”,首跳路由到 light 档位。

事后升级驱动的“补救式”稳定性

在这类请求上,若 light 档模型输出武断、缺乏证据或不合规的回答,系统只能依赖事后升级机制(同层重试 + 受控升级)去补救。这种补救路径不仅增加了单位请求的总计算开销,也直接抬高了 short-hard 子群的 P50 和 P95 延迟。

为了系统性刻画这一问题,我们在后续实验中,基于第 2.3 节构造的 Short-Hard 基准,主要采用以下评估指标:

  • 路由结构:short-hard 请求在 light/std/enh 三档上的首跳分布,特别是“首跳走 light”的比例,我们将其视为该子群的误路由率;
  • 升级行为:short-hard 请求中触发升级的比例,以及升级后是否对尾部延迟产生显著影响;

长尾延迟:在 CO-corrected P95(Overall)口径下 short-hard 子群的延迟表现,并与全体流量的系统级 P95 护栏进行对比。


3 Baseline Planner:启发式规划器

在引入短难守护机制之前,我们先简要说明网关早期版本使用的启发式规划器(Baseline Planner),并将其作为 short-hard 研究中的对照基线。该规划器仅依赖长度、标点等表层特征,为每个请求打一个复杂度分数,再通过全局阈值将请求路由到 light / std / enh 三个档位。


3.1 启发式复杂度分数


对于单个请求 x,启发式规划器观测到的表层特征包括:

  • len(x):请求的近似长度,可以是字符数或更精确的 token 数;
  • marks(x):与结构复杂度相关的标点数量(如逗号、句号、括号等);
  • 1[heavy_kw(x)]:“重关键字”指示变量,当请求中命中代码、JSON、分步骤指令、检索模板等预定义模式时取值为 1,否则为 0。

基于这些特征,我们为每个请求计算一个启发式复杂度分数:

score_base(x) = len(x) / 200 + marks(x) / 6 + 0.8 · 1[heavy_kw(x)]

其中:

  • 分母 200 与 6 用于将长度项 len(x) 和标点项 marks(x) 归一化到相近量级;
  • 系数 0.8 用于将“重关键字”信号压到与前两项同一数量级,而不是一票否决。

所有常数均在独立的验证切片上通过网格扫描粗调得到,并在后续实验中保持固定,不随 short-hard 专项评测而改变。

在路由阶段,score_base(x) 会与两个全局阈值 thr_stdthr_enh 比较,形成一个三档决策:

  • score_base(x) < thr_std:视为“启发式上简单”,首跳建议档位为 light;
  • thr_std ≤ score_base(x) < thr_enh:建议从 std 档位起步;
  • score_base(x) ≥ thr_enh:建议直接路由至 enh 档位。

在本工作使用的配置中,这两个阈值固定为:

  • thr_std = 0.40
  • thr_enh = 0.85

上述阈值在所有方案之间保持不变,用作对比实验中的统一“尺子”。

3.2 在 Short-Hard 基准上的行为

在 Short-Hard Benchmark 上,Baseline 明显体现出“短即简单”的偏见。我们将“被判为简单”定义为 score_base(x) < thr_std,即首跳被路由到 light 档位。在 499 条短难专项样本上(包含 Short-Hard-39 及其邻域),禁用 SHG、仅使用 Baseline 时,首跳档位分布为:

  • light:约 76.95%;
  • std:约 7.62%;
  • enh:约 15.43%。

其中 Short-Hard-39 全部由人工标注为“困难”,大部分需要多步推理或专业背景。上述分布表明,Baseline 把绝大多数短难请求与普通“短而易”问题混在一起,系统性地送往 light 档位,主要依赖“首跳 light → 质量不合格 → 受控升级”的补救路径。这样既增加了单位请求的总计算开销,也抬高了短难子群的尾部延迟:在该切片上,Baseline 的 CO-corrected P95(Overall)约为 2397 ms,中位延迟 P50 约为 1052 ms。

总体而言,Baseline 在 short-hard 场景的主要问题是:特征空间对短难不敏感,将难度视为单一连续量而未显式建模 short-hard 子群,纠错主要依赖事后升级,为后续引入 SHG 提供了清晰的对照基线。

4 短难守护机制:语义感知规划器(SHG)

本节介绍用于修复 short-hard 路由误判的核心方法:语义感知规划器(Semantic-Aware Planner)。它作为入口规划阶段的替代模块,直接接收原始请求 xxx,输出一个复杂度分数和路径楼层建议,再交由后续路由器(QAR)与执行器使用。

与第 3 节的启发式规划器不同,语义感知规划器在保持原有表层启发式结构的基础上,引入了零训练语义/风险标签、轻量语义探针和 Preflight 前置体检三种信号,显式地把“短而难”任务从普通短问答中剥离出来。


4.1 设计目标

语义感知规划器的设计目标可以概括为三点。

  1. 专门修复 short-hard 误判

第 3 节表明,启发式规划器在 Short-Hard Benchmark 上会将大量短难请求首跳路由到 light 档位,随后依赖升级机制“事后补救”。语义感知规划器的首要目标,是在入口阶段就识别出这类请求,并在不依赖后验失败的前提下,给出更保守的首跳档位建议,从而减少“短文本被当成简单”的系统性错配。

  1. 常数级开销 C_overhead,与成本账本兼容

规划器引入了两次轻量模型调用(探针与 Preflight),但它们都被严格限制在常数数量级的生成长度:

  • 探针生成长度 ≤ 24 tokens
  • Preflight 生成长度 ≤ 32 tokens

这些前置开销统一计入成本账本中的规划开销项 C_overhead,并与后端推理开销 C_a(不同档位模型的单位成本)明确区分,保证整体成本可对账、可分解。

  1. 单调、有界、可解释

新的复杂度分数 score'(x) 必须满足三项性质:

  • 单调性:
    score'(x) ≥ score_base(x),只纠正低估,不制造新的低估。
  • 有界性:
    增强部分有明确理论上界,避免分数尺度失控,便于阈值在版本之间迁移。
  • 可解释性:
    用于增强的每一项信号(标签、探针分数、Preflight 结果)都在日志与 /plan 输出中对应到具体字段,可以逐请求复盘“为什么这条短问被当作难题”。

在此约束下,语义感知规划器被设计为一个纯增量模块:不改变成本模型与路由器框架,只在“如何估计复杂度、何时抬高楼层”上注入更丰富的语义信息。

4.2 语义与风险标签:零训练“安全网”


为了在不引入额外训练成本的前提下,让规划器对 short-hard 场景更敏感,我们首先设计了一套基于规则的语义与风险标签系统,作为第一道“安全网”。

标签集合与映射

预定义两个有限集合:

  • 语义标签全集
    S_sem = { style_transfer, refutation, proof, debate, abstraction }
    用于表示与深度推理、抽象思维或复杂任务结构强相关的任务类型。
  • 风险域标签全集
    S_risk = { legal, medical, finance }
    用于表示合规风险较高的领域。

对任意请求 x,零训练规则系统给出两个集合值映射:

  • S(x) ⊆ S_sem
  • R(x) ⊆ S_risk

基于此定义两个指示变量:

  • 1[semantic_heavy(x)] := 1,当且仅当 S(x) ≠ ∅,否则为 0
  • 1[risk_domain(x)] := 1,当且仅当 R(x) ≠ ∅,否则为 0

它们分别回答两个问题:“该请求是否是语义重任务?”、“该请求是否落在高风险域?”。

检测方法与防御性规则

标签检测完全采用零训练规则实现,核心包括:

  • 短语子图与模式词典
    使用多语言短语图谱与正则模板匹配“悖论”“反驳”“证明”“条款冲突”“违约责任”等强信号短语。
  • 局部上下文窗口
    匹配范围限制在关键词周围的局部窗口(如 ±64 token),避免文档远端噪声触发。
  • 防御性去噪
    若关键词出现在显式否定(如“不要讨论悖论”)或单纯引用上下文中,则不触发标签。

整个过程纯规则、无训练,延迟极低且完全可解释。

路径楼层建议 route_floor_reco

基于上述标签定义路径楼层建议。设系统三档位满足全序关系:

  • light < std < enh

规划器输出的首跳最低档位建议记为 route_floor_reco(x)。

语义与风险标签对楼层的影响定义为:

  • route_floor_reco(x) = max( light, 1[semantic_heavy(x)] · std, 1[risk_domain(x)] · std )

解释如下:

  • 默认情况下,若未命中任何标签,则建议楼层为 light。
  • 一旦命中任一语义重任务标签或风险域标签,建议楼层立刻抬升至 std。
  • 建议楼层只会被抬高,不会被降低,与第 3 节对 short-hard 的理想约束(首跳不低于 std)一致。

这一策略与系统中已有的“JSON/代码任务楼层不低于 std”的规则是同构的,便于在 QAR 中统一实现。对于 short-hard 子群而言,语义/风险标签的作用,是为后续更精细的机制预先“拉起一层安全底座”。


4.3 轻量语义探针(≤24 tokens)


规则体系的表达能力受限于预定义词典,对许多隐含推理需求的短问无能为力。为此,引入第二道信号:一次极轻量的语义探针,让最轻档模型对“自己能否胜任”给出一个数值判断。

probe_difficulty(x) 的定义与约束

语义探针通过向 light 模型发送一个固定提示,要求其仅输出一个位于区间 [0, 1] 内的实数:

  • probe_difficulty(x) ∈ [0, 1]

语义上表示:“要高质量完成该请求,大约需要多深的推理力度”。

实现上施加两条硬约束:

  • 输出形式:模型只被允许输出一个数字,不附带解释或推理文本。
  • Token 上限:从模型第一次生成开始,整体生成长度被强制截断在 ≤ 24 tokens。

这保证了探针调用在计算开销上可以视为常数级,不会随着请求长度或下游模型解码长度而放大。

开销记录与可审计性

为了与成本账本对齐并保证可复现性,每次探针调用都会记录三项信息:

  • probe_difficulty:数值分数本身
  • probe_tokens:实际生成 token 数
  • probe_prompt_hash:探针提示文本的哈希,用于锁定版本

这些字段既会作为 /plan 输出的一部分传递给下游逻辑,也会被写入事件日志,用于后续的成本核算和实验重放。探针引入的所有开销都统一计入 C_overhead。

为什么这是“模型视角的难度信号”

与长度、标点等表层特征不同,语义探针依赖的是模型对请求语义的整体理解:

  • 对于“黎曼猜想成立吗?”、“意识可计算吗?”此类短难请求,模型在内部往往已经“知道”它们对应难题或开放问题,因此会倾向于给出较高的 probe_difficulty。
  • 对于“今天天气如何?”之类真正简单的短问,模型更有信心直接给出回答,探针得分则明显偏低。

因此,probe_difficulty 提供了一条与表层启发式近乎正交的信号通道,可以显式地把“模型自己觉得难”的样本标记出来。对于 short-hard 子群,这个信号是修正 score_base 低估的关键。

4.4 Preflight 前置体检(≤32 tokens)

语义与风险标签、语义探针共同刻画的是静态难度:在看到输入文本时,系统推测这个任务可能有多难。但短难请求的最终成败,还取决于模型在生成那一刻的“动态反应”。为此,我们加入第三道防线:Preflight 前置体检。

触发条件

Preflight 并不对所有请求启用,而是只在怀疑“当前档位可能不够用”的情况下触发。采用如下条件:

  • 1[semantic_heavy(x)] = 1

  • probe_difficulty(x) ≥ τ

其中 τ ∈ (0, 1) 是固定阈值,默认 τ = 0.60。

即:

  • 只要被语义标签认定为“语义重任务”,或者
  • 被探针判定为“高难度请求”,

就会进入 Preflight 体检流程。

答案骨架与快速判别

Preflight 包含两个步骤。

  1. 生成极短“答案骨架”
    轻档模型被提示不要写完整答案,而是输出一个非常简短的骨架,例如“一句核心结论 + 2–3 个支撑点”,生成长度上限 ≤ 32 tokens。记该骨架为 y_pf。
  2. 快速判别 template / refusal / contradiction对 y_pf 运行一组轻量规则,检测是否存在典型“不胜任信号”,包括但不限于:
  • template:高度模板化、空洞、信息量极低的回答;
  • refusal:明确拒答或以“作为一个 AI 模型……”等模板话术规避问题;
  • contradiction:在很短文本内即可检测出的自相矛盾。
  1. 规则输出一个布尔标志 flag 以及原因 reason ∈ { template, refusal, contradiction, none }。

体检失败时的楼层提升

若 Preflight 判定 flag = true(存在明显不胜任信号),规划器会再次抬升建议楼层:

  • route_floor_reco(x) ← max( route_floor_reco(x), std )

保证该请求首跳不会落在 light 档位。若 flag = false,则保持原有建议不变。

整个 Preflight 的生成开销通过 preflight_tokens 记录,同样计入 C_overhead,并在日志中附带 preflight_reason 字段,便于事后分析“哪些短难样本是被 Preflight 抓出来的”。


4.5 复合复杂度分数与性质


在有了表层启发式(第 3 节)、语义/风险标签(4.2)、语义探针(4.3)之后,将这些信号组合为一个新的复合复杂度分数 score'(x),作为 QAR 的主要输入。

分数定义

记 score_base(x) 为第 3 节定义的启发式分数,则复合分数定义为:

  • score'(x) = score_base(x)
  • α · probe_difficulty(x)
  • β · 1[semantic_heavy(x)]
  • γ · 1[risk_domain(x)]

其中 α, β, γ ≥ 0 为固定权重。本文默认采用:

  • α = 0.40
  • β = 0.20
  • γ = 0.20

权重在独立验证切片上通过网格搜索粗调得到,并在所有实验中保持不变。

关键性质

该设计满足 4.1 中提出的三项性质。

  1. 单调性(只加不减)所有增强项都是非负,因此对任意 x:
  • score'(x) ≥ score_base(x)
  1. 语义增强只负责提高分数、纠正低估,不会把原本被视为“复杂”的请求误降为“简单”。
  2. 有界性(增量有上界)
    增强部分的理论上界为 α + β + γ。
    这保证分数的尺度变化是可控的,不会让路由阈值在不同版本之间失去意义。对于 short-hard 子群而言,其分数提升大致被限制在一个稳定区间内,便于在 QAR 层统一设置 thr_std、thr_enh。
  3. 可解释性(每一项可追溯)
    score'(x) 的每一个组成部分在日志中都有显式字段:score_base、probe_difficulty、semantic_heavy、risk_domain,都可以在 /plan 输出和事件日志中逐项复原。对于任意 short-hard 样本,都可以明确说明“分数为什么被抬升”“是哪个信号起决定作用”。

以“忒修斯之船”悖论为例:在只看表层特征时,score_base(x) ≈ 0.217,明显偏低;语义标签命中 debate、abstraction,探针给出高分 probe_difficulty(x) = 0.9 后,score'(x) 被抬升至约 0.777,从而跨过 thr_std,被 QAR 视为至少需要 std 档位处理的任务。这正是 short-hard 修复的预期行为。


4.6 带注释伪代码:Semantic-Aware Planner 算法

综合上述三类信号,我们可以给出语义感知规划器的整体算法流程,伪代码中仅保留与 short-hard 判定直接相关的部分,其他的细节我会放在核心实现代码中,论文结尾会给出链接。

Algorithm 1  Semantic-Aware Planner

Input:  prompt x

Output: JudgeReport(含 complexity, route_floor_reco 等字段)

1:  score_base ← len/200 + marks/6 + 0.8·1[heavy_kw]     # 基线启发式复杂度分数(第 3 节),仅依赖表层特征。 2:  (S, R) ← detect_by_patterns(x)     # 通过零训练规则检测语义标签 S(x) 和风险域标签 R(x)。 3:  semantic_heavy ← 1[S ≠ ∅]     risk_domain    ← 1[R ≠ ∅] 4:  route_floor_reco ← light     if semantic_heavy = 1 or risk_domain = 1 then 5:      route_floor_reco ← max(route_floor_reco, std)     # 语义/风险标签触发路径楼层抬升,保证首跳不低于 std。 6:  if probe_enabled then 7:      (probe_difficulty, probe_tokens, probe_hash) ← run_probe(x)         # 轻量语义探针:≤24 tokens,仅输出 [0,1] 数值。     else 8:      probe_difficulty ← 0 9:  score' ← score_base             + α·probe_difficulty             + β·semantic_heavy             + γ·risk_domain     # 组合得到复合复杂度分数,用于后续 QAR 三档决策。 10: if preflight_auto and (semantic_heavy = 1 or probe_difficulty ≥ τ) then 11:     (flag, reason, pf_tokens) ← preflight_outline(x)   # ≤32 tokens 12:     if flag = true then 13:         route_floor_reco ← max(route_floor_reco, std)         # Preflight 发现模板化/拒答/矛盾,则再次抬高首跳下限。 14: 返回 JudgeReport{         complexity        = score',         complexity_legacy = score_base,         route_floor_reco,         semantic_heavy, risk_domain,         probe_difficulty, probe_tokens, probe_prompt_hash,         preflight_used   = (pf_tokens > 0),         preflight_reason = reason,         preflight_tokens = pf_tokens,         ...              # 其他与成本和护栏相关的字段     }

可以看到,语义感知规划器在结构上仍然保持与 baseline 相同的“先打分、再对比阈值”的框架,只是通过标签、探针和 Preflight 三层机制,对 short-hard 子群做了更保守的首跳建议。

4.7 与路由器(QAR)的接口:JudgeReport 对象

语义感知规划器的所有决策,最终都被封装在一个结构化对象 JudgeReport 中,并通过 /plan 接口传递给品质感知路由器(QAR)和受控执行器。本小节只列出与 short-hard 相关的核心字段:

  • complexity_legacyscore_base(x),启发式复杂度分数,用作历史对照;
  • complexityscore'(x),复合复杂度分数,是 QAR 做 light / std / enh 三档决策的主要输入;
  • semantic_heavy[]:命中的语义标签集合,对应 S(x)
  • risk_domain[]:命中的风险域标签集合,对应 R(x)
  • probe_difficulty, probe_tokens, probe_prompt_hash:语义探针的分数、开销与版本指纹;
  • route_floor_reco:路径楼层建议,取值 ∈ {light, std, enh};
  • preflight_used, preflight_reason, preflight_tokens:Preflight 是否被触发、失败原因、开销。

QAR 接收 JudgeReport 后,使用一个简单的策略完成首跳路由:

  1. complexity 与全局阈值 thr_std, thr_enh 比较,得到一个“建议档位”;
  2. 再与 route_floor_reco 取上界,保证任何由标签 / Preflight 提升的楼层约束不会被后续覆盖。

对于 Short-Hard Benchmark 中的样本而言,语义感知规划器 + QAR 的组合效果,可以概括为:

  • 在规划阶段就把 short-hard 子群“拉升”为至少 std 档;
  • 同时保持昂贵档位(enh)触发率稳定,并将探针与 Preflight 的额外开销显式计入 C_overhead

5 实验结果

本节在 Short-Hard-39 及其邻域构成的 499 条请求切片上,对比规则基线规划器(Baseline)、语义感知规划器 + 短难守护(Ours, SHG),以及当前主流的动态路由框架 RouteLLM,在短难检测、路由结构和延迟表现上的差异。为控制实验的时间,我们将生成答案长度上限统一设为 192 个 token,对所有模型和网关路由(包括 RouteLLM 对照中的 weak/strong 槽位)一视同仁;在本节关注的短文本输入场景下,该上限足以覆盖完整回答,因此不会影响不同路由策略之间的相对比较。

5.1 Short-Hard 检测能力

在本工作中,我们将 Short-Hard-39 及其邻域样本统一视为“应当至少由 std 档位起步处理”的高复杂度子群。在这一切片上,我们用首跳档位是否落在 light 来近似衡量“被误判为简单”的程度:

  • 若首跳被路由到 light,则视为一次短难误判(short-hard misclassification);
  • 若首跳落在 std 或 enh,则视为一次成功识别为“困难”的样本。

在 499 条请求上,禁用短难守护、仅使用规则基线规划器(Baseline)时:

  • 约 76.95% 的请求首跳被送往 light 档位;
  • 仅 23.05%(7.62% 在 std,15.43% 在 enh)首跳落在非 light 档位。

在启用语义感知规划器 + 短难守护(Ours, SHG)后:

  • 首跳落在 light 的比例被压缩到 2.40%;
  • 约 97.6% 的请求首跳直接进入 std 或 enh 档位,其中 std 占比上升到 82.16%。

从“检测”的角度看,这意味着:

  • 基线规划器对短难子群的“识别率”仅约为 23%,大部分被当成普通短问压到 light;
  • 引入 SHG 后,短难请求首跳被识别为“至少需要 std”的召回率提升到约 98%,误判率从约 77% 降到约 2%。

在不改动后端模型池和路由阈值的前提下,这一改动已经从结构上把“短而难”从普通短问中剥离出来。


5.2 结果及解释

我们进一步考察这一路由重塑对短难切片的延迟和成本的影响。延迟采用 Overall 口径下的 Raw / CO P95 指标,其中 CO-corrected P95 作为主判护栏;成本以各档位占比和定性 GPU-ms/req 变化进行分析。

在 499 条请求上,两种配置的汇总如下(Overall 口径):

配置 light / std / enh 首跳占比 P50 (ms, Overall) CO-P95 (ms, Overall)
禁用 SHG 77.0 / 7.6 / 15.4 ≈ 1052 ≈ 2397
启用 SHG 2.4 / 82.1 / 15.4 ≈ 1534 ≈ 2393

可以看到:

  • 尾部延迟基本不变
    CO-corrected P95 从约 2397 ms 微降至约 2393 ms,变化量在统计波动范围内,可视为“在既定 SLO 约束下保持稳定”。这表明短难守护没有恶化长尾,而是把原本在 light → 升级链路中发生的“坏轨迹”前移到 std 首跳统一吸收。
  • 中位延迟按预期上升:P50 从约 1052 ms 升至约 1534 ms,约增加 480 ms 左右。这一增量完全可以解释为:
  • 大量短问不再在 light 上尝试,而是直接从 std 启动;
  • std 解码本身比 light 更重。
    换言之,这是一次“从 light 向 std 的成本再分配”,属于设计内预期。
  • 昂贵路径成本保持稳定
    enh 档位的占比在两种配置下均为 15.4%。在我们的成本模型中,昂贵路径的触发率 r_costly 没有因为 SHG 而上升,说明短难守护带来的“质量与稳健性提升”,主要由中档模型(std)消化。

综合来看,在短难切片上,语义感知规划 + SHG 做到:

  • 在不增加昂贵档位压力、不拉高 P95 尾部的前提下;
  • 用一次常数级的规划开销 C_overhead
  • 换取了路由结构从 “light 主导” 到 “std 主导” 的整体迁移。


5.4 总体影响与代表性轨迹

我们给出一个典型个案,并从整体上讨论短难守护对路由稳健性的意义。

以“黎曼猜想成立吗?”为例:

在 Baseline 配置下,该请求首跳被路由到 light 档位,轻模型往往直接给出武断结论(例如倾向性地回答“已经被证明”或给出不带引用的模糊说法)。即便在后续质量检查中部分被拦住,也已经在首轮生成中暴露出明显的合规与可信度风险。

在 Ours (SHG) 配置下,同一请求被语义标签与探针对应为“短而难”任务,首跳楼层被抬至 std。std 模型倾向于给出“尚未被证明”“属于数论中极其重要但仍为开放的难题”等回答形式,并更经常附带背景说明,从而在事实性、审慎性上显著优于 light。

从系统角度看,短难守护的贡献可以概括为:

  • 结构性修复
    不依赖“失败后升级”这种事后纠错,而是在规划阶段就把短难子群识别出来,改变其首跳路径。
  • 可控成本转移
    成本增加集中体现在 P50 的抬升,由 std 档位承担;昂贵档位占比和 P95 尾部几乎不变。
  • 可审计性与可验证性
    所有 short-hard 判定信号(标签、探针分数、Preflight 结果)和路由决策(首跳档位、升级次数)都被事件化记录,使得我们可以在离线环境中精确重放“为什么某个短问被当成难题处理”。

整体而言,这组结果表明:短难请求在实际网关中构成了一类独立且在实践上高度相关的路由稳健性问题。在不改变模型池、不放松服务级别约束的前提下,引入一层常数开销的语义感知规划与短难守护,就能显著降低其被误判为“简单请求”的比例,并在P95尾部几乎不退化的前提下重塑路由结构。后续章节将在更大规模的整体流量上验证这种机制对全局成本和延迟的影响。


5.5 与 RouteLLM 路由的对比评测

为了将短难守护与现有动态路由方案进行对齐对比,我们在与前文相同的 Short-Hard-39 邻域切片(共 499 条请求)上,引入了现有的 RouteLLM 的两档位路由器作为对照。

具体而言,我们采用 RouteLLM 官方开源仓库中发布的 BERT 路由器 checkpoint(即在其公开训练数据上离线训练完成的 bert_gpt4_augmented),通过本地离线下载并加载该权重。整个实验统一使用同一模型池:在 4B/8B 之间进行路由:

  • 小模型:qwen3-4b(记作 weak/4B);
  • 大模型:qwen3-8b(记作 strong/8B)。

在我们的语义规划 + 短难守护(Ours, SHG)配置下,逻辑上仍保留 light/std/enh 三个档位,但在本实验中 std 和 enh 均指向同一个 8B 模型。因此,在与 RouteLLM 对比时,我们将所有 8B 调用统一视为一个 “strong-8B” 档,得到一个纯粹的「4B vs 8B」两档对比。

在该配置下,RouteLLM 式路由与 Ours (SHG) 在 short-hard 切片上的挡位分布与延迟如下。

表 1:RouteLLM 式路由 vs. Ours (SHG) 在 short-hard 切片上的两档对比(统一 4B/8B 模型池)

路由策略 weak-4B 占比 strong-8B 占比 P50 (ms) P95 / CO-P95 (ms) 平均延迟 (ms)
RouteLLM 式两档路由(4B/8B) 69.3% 30.7% ≈ 1058 ≈ 1550 ≈ 1208
语义规划 + 短难守护(Ours, SHG) 2.4% 97.6% ≈ 1532 ≈ 1543(CO-P95) ≈ 1521

可以看到,在完全相同的 4B/8B 模型池下:

  • 在 short-hard 切片上,RouteLLM 式路由仍然让多数短难请求(约 69.3%)停留在 4B weak 档,只有约 30.7% 的请求跳转交给 8B strong 模型。
  • 而短难守护几乎彻底反转了这一结构:只有约 2.4% 的请求仍然落在 4B,其余约 97.6% 的短难请求则直接由 8B 模型处理。

从延迟角度看,两者在尾部(P95)几乎处于同一量级:RouteLLM 的 P95 约为 1550 ms,而 Ours (SHG) 的 CO-P95 约为 1543 ms,差异在统计波动范围内。由于更多请求被分配给了 strong-8B 模型,Ours (SHG) 的 P50 为约 1532 ms。

因此,在同一个两档 4B/8B 模型池下,Ours (SHG) 相比 RouteLLM 显式地将 short-hard 子群的首跳路径迁移到由 strong-8B 主导;在几乎相同的 P95 尾部的前提下,用更高的 8Bstrong 覆盖率换取 short-hard 任务的稳健性与事实性。


此外,在离线测试的典型服务场景下,在固定模型池与P95延迟护栏约束下,我们的网关路由模式将端到端 P50 延迟和平均推理成本分别降低约 38% 和 39%,同时保持 P95 尾部延迟不退化。




6 结论与展望

本文聚焦于多档位大模型网关中长期被忽视的一类结构性风险:短而难(short-hard)请求被系统性误判为“简单任务”,从而被错误路由至轻量模型,产生武断、缺乏证据或不合规的回答。

我们基于真实网关日志构造了一个可审计的 Short-Hard-39 基准,通过长度分位、领域与符号信号筛选候选请求,并经专家标注形成“困难”黄金标签,用以刻画这一子群在现有规则规划器下的路由偏差和长尾风险。实验表明,早期的规则基线规划器在该基准上的短难误判率接近四分之三,首跳路由高度偏向 light 档位,依赖事后升级机制被动修复,给延迟尾部和合规控制带来了额外压力。


核心代码链接 https://github.com/haizei1234A/-123


论文为本人原创如需转载,注明出处。


附录:短难问题集


黎曼猜想成立吗?

连续统假设为真吗?

量子引力可统一吗?

宇宙有边界吗?

时间是离散的吗?

因果可逆转吗?

自由意志存在吗?

意识可计算吗?

黑洞信息保全吗?

暗物质究竟是什么?

暗能量本质为何?

多世界可证伪吗?

热寂能被避免吗?

生命起源何在?

RNA世界足够吗?

宇宙常数为何小?

量子测量真坍缩吗?

宏观叠加可实现吗?

全息原理普适吗?

时空是涌现的吗?

数学是被发明吗?

道德可客观吗?

意识有量化指标吗?

外星生命常见吗?

费米悖论真解何在?

强AI会涌现吗?

AGI可验证安全吗?

对齐可证明吗?

语言起源于何?

普适语法存在吗?

归纳能被证明吗?

自由能原理普适吗?

货币有最优形态吗?

市场能完全有效吗?

"气候临界点何时至?

聚变能否净增益?

人类寿命上限多少?

意识上传可行吗?

真随机可构造吗?


相关文章
|
1天前
|
云安全 人工智能 自然语言处理
|
5天前
|
搜索推荐 编译器 Linux
一个可用于企业开发及通用跨平台的Makefile文件
一款适用于企业级开发的通用跨平台Makefile,支持C/C++混合编译、多目标输出(可执行文件、静态/动态库)、Release/Debug版本管理。配置简洁,仅需修改带`MF_CONFIGURE_`前缀的变量,支持脚本化配置与子Makefile管理,具备完善日志、错误提示和跨平台兼容性,附详细文档与示例,便于学习与集成。
314 116
|
8天前
|
数据采集 人工智能 自然语言处理
Meta SAM3开源:让图像分割,听懂你的话
Meta发布并开源SAM 3,首个支持文本或视觉提示的统一图像视频分割模型,可精准分割“红色条纹伞”等开放词汇概念,覆盖400万独特概念,性能达人类水平75%–80%,推动视觉分割新突破。
592 53
Meta SAM3开源:让图像分割,听懂你的话
|
20天前
|
域名解析 人工智能
【实操攻略】手把手教学,免费领取.CN域名
即日起至2025年12月31日,购买万小智AI建站或云·企业官网,每单可免费领1个.CN域名首年!跟我了解领取攻略吧~
|
5天前
|
人工智能 Java API
Java 正式进入 Agentic AI 时代:Spring AI Alibaba 1.1 发布背后的技术演进
Spring AI Alibaba 1.1 正式发布,提供极简方式构建企业级AI智能体。基于ReactAgent核心,支持多智能体协作、上下文工程与生产级管控,助力开发者快速打造可靠、可扩展的智能应用。
|
4天前
|
弹性计算 人工智能 Cloud Native
阿里云无门槛和有门槛优惠券解析:学生券,满减券,补贴券等优惠券领取与使用介绍
为了回馈用户与助力更多用户节省上云成本,阿里云会经常推出各种优惠券相关的活动,包括无门槛优惠券和有门槛优惠券。本文将详细介绍阿里云无门槛优惠券的领取与使用方式,同时也会概述几种常见的有门槛优惠券,帮助用户更好地利用这些优惠,降低云服务的成本。
267 132
|
8天前
|
机器学习/深度学习 人工智能 自然语言处理
AgentEvolver:让智能体系统学会「自我进化」
AgentEvolver 是一个自进化智能体系统,通过自我任务生成、经验导航与反思归因三大机制,推动AI从“被动执行”迈向“主动学习”。它显著提升强化学习效率,在更少参数下实现更强性能,助力智能体持续自我迭代。开源地址:https://github.com/modelscope/AgentEvolver
412 29
|
15天前
|
安全 Java Android开发
深度解析 Android 崩溃捕获原理及从崩溃到归因的闭环实践
崩溃堆栈全是 a.b.c?Native 错误查不到行号?本文详解 Android 崩溃采集全链路原理,教你如何把“天书”变“说明书”。RUM SDK 已支持一键接入。
723 223

热门文章

最新文章