后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载在模型路由系统中单一选择方法往往只能捕捉一种信号用户反馈、语义相似度、成本、质量各有侧重很难同时兼顾。semantic-router 的Hybrid Selection混合选择算法正是为解决这一问题而设计——它通过可配置权重将 Elo 反馈评分、RouterDC 语义匹配、AutoMix 质量价值与成本效率四种信号融合为统一的综合得分从而在用户体验与资源开销之间做出更稳健的决策。读完本文你将掌握 Hybrid 的数学公式、Go 核心实现、完整 YAML 配置方法、权重预设思路以及各组件在源码层面的工作原理并能在自己的路由配置中直接落地使用。Hybrid Selection 的设计动机与定位Hybrid selection 的核心思想是组合多种选择方法Elo、RouterDC、AutoMix、Cost并配以可配置的权重。这样可以在一次路由决策中同时平衡用户反馈历史Elo 评分反映真实使用体验语义匹配度RouterDC反映查询与模型能力的语义相关性质量评分AutoMix 的 POMDP 价值函数成本效率按 token 单价折算的成本信号。与 Hybrid LLM 论文的区别值得说明的是业界存在一篇同名的 Hybrid LLMDing et al.论文它训练了一个基于 BERT 的质量差quality-gap预测器用于在两个模型之间做二元路由最高可减少约 40% 的昂贵模型调用。semantic-router 的实现采用了完全不同的技术路线不是训练二元分类器而是构建一个加权集成weighted ensemble把 Elo 评分、语义相似度、POMDP 价值、成本等多路信号线性融合。从源码注释也可以印证这一点在 hybrid.go 的HybridConfig定义中注释明确标注 Based on arXiv:2404.14618同时保留了论文中质量差阈值quality_gap_threshold与 MLP 预测开关use_mlp作为可选项但主路径仍然是我们将要剖析的加权融合。算法流程整个混合选择的执行链路可以用下面的流程图概括流程要点用户查询进入路由决策四个组件各自独立计算候选模型的得分Elo 评分、RouterDC 相似度、AutoMix 价值、成本效率各分量被归一化到 [0, 1] 区间可由normalize_scores开关控制按配置权重做加权求和选择综合得分最高的模型并路由。数学基础综合得分公式Hybrid 对每个候选模型m与查询q计算综合得分score(m, q) w_elo × E(m) w_dc × S(q,m) w_mix × V(m,q) w_cost × C(m)其中E(m) 归一化后的 Elo 评分S(q, m) 归一化后的 RouterDC 相似度V(m, q) 归一化后的 AutoMix 价值C(m) 归一化后的成本效率1 - relative_costΣw_i 1所有权重之和必须为 1。分量归一化每个分量都要先被归一化到 [0, 1] 区间才能参与加权求和分量归一化方式EloE (R - 1000) / 1000超出范围时截断/clampRouterDC本身即 [0, 1]余弦相似度经 sigmoid 映射AutoMixV (V - V_min) / (V_max - V_min)CostC 1 - (cost / max_cost)在真实源码中归一化由 scoring.go 的NormalizeCandidateScores实现它会先扫描所有候选的原始得分求出 min/max再按(value - min) / (max - min)映射对越低越好LowerIsBetter的信号如成本再取1 - value反向。这与文档中表格的描述一致并且实现上对全同值集合做了保护。核心算法Go 实现原文档给出了一个简化版Select伪代码。真实的实现位于 hybrid.go其骨架如下// Select chooses the best model by combining multiple selection methods func (h *HybridSelector) Select(ctx context.Context, selCtx *SelectionContext) (*SelectionResult, error) { if err : ValidateSelectionContext(selCtx); err ! nil { return nil, err } // Collect scores from each component componentScores : make(map[string]CandidateScores) var componentResults []*SelectionResult // Get feedback-derived experience scores if h.eloSelector ! nil h.config.ExperienceWeight 0 { result, err : h.eloSelector.Select(ctx, selCtx) if err nil result ! nil { componentScores[experience] result.ScoresFor(selCtx.CandidateModels) componentResults append(componentResults, result) } } // Get RouterDC scores if h.routerDCSelector ! nil h.config.RouterDCWeight 0 { result, err : h.routerDCSelector.Select(ctx, selCtx) // ... componentScores[router_dc] result.ScoresFor(selCtx.CandidateModels) } // Get AutoMix scores if h.autoMixSelector ! nil h.config.AutoMixWeight 0 { result, err : h.autoMixSelector.Select(ctx, selCtx) // ... componentScores[automix] result.ScoresFor(selCtx.CandidateModels) } // Normalize scores if enabled if h.config.NormalizeScores { for component, scores : range componentScores { componentScores[component] NormalizeCandidateScores(scores, HigherIsBetter) } } // Combine scores with weights combinedScores : h.combineScores(componentScores, selCtx.CandidateModels) // Apply cost adjustment if h.config.CostWeight 0 { h.applyCostAdjustment(combinedScores, selCtx.CostWeight) } best : combinedScores.Best(HigherIsBetter, false) // ... return SelectionResult{ SelectedModel: bestModel.Model, Score: bestScore, Confidence: confidence, Method: MethodHybrid, Reasoning: reasoning, AllScores: combinedScores.Diagnostics(), CandidateScores: combinedScores, }, nil }与原文档中的简化版相比真实实现有三个值得注意的增强点零权重短路只有当某组件权重 0时才调用对应 selector 的Select避免无谓的计算开销例如禁用 RouterDC 时不会触发 embedding缺失组件的容错某个组件不可用如没有 embedding 函数时该分量为空BlendCandidateScores会按可用组件权重归一化处理而不是把缺失当作零分——参见 scoring.go 的实现置信度与可解释性真实实现还会根据各组件对最终选择的共识程度计算ConfidencecalculateConfidence并生成人类可读的Reasoning文本例如Hybrid combination: [Experience0.623 RouterDC0.845], weights[elo:0.30, dc:0.30, am:0.20, cost:0.20]。加权融合的池级归一化细节源码中的BlendCandidateScoresscoring.go实现了一个重要语义权重按实际可用组件重新归一化。即如果某个组件没有任何得分例如候选模型缺少描述导致 RouterDC 无法打分它的权重会被剔除其余可用组件按比例放大。这保证了即使部分信号缺失最终得分仍是一个有意义的相对排名而不是被零值拉低。四个组件的源码级原理Elo 组件基于反馈的评分学习Elo 组件的实现位于 elo.go其设计参考了 RouteLLM 论文arXiv:2406.18665的 Bradley-Terry 模型初始评分initial_rating默认 1500DefaultEloRatingK 因子k_factor默认 32控制每次反馈后评分的波动幅度支持全局评分与按决策类别category的评分两套体系CategoryWeighted默认开启反馈更新遵循标准 Elo 公式R R K × (actual - expected)其中期望胜率E_a 1 / (1 10^((R_b - R_a) / 400))还支持单模型自我反馈只有winner_model正向或只有loser_model负向时按 K 因子的 10% 做小幅奖惩评分可以通过StoragePath持久化到 JSON 文件并支持AutoSaveInterval自动保存默认 30 秒重启后可恢复。在 Hybrid 中使用 Elo 分量时其归一化为(R - 1000) / 1000并 clamp 到 [0,1]——即默认 1500 分映射为 0.5。RouterDC 组件双对比学习语义匹配RouterDCDual-Contrastive实现位于 router_dc.go参考 arXiv:2409.19886每个模型用其description描述与capabilities能力标签拼接成文本再通过 embedding 函数编码为模型向量InitializeFromConfig中的buildDescriptionText查询向量与模型向量做余弦相似度再除以temperature默认 0.07后用sigmoid映射回 (0,1)computeContrastiveSimilarity分数再做带温度的 softmax 得到最终概率applySoftmax没有描述或 embedding 不可用的模型会拿到MinSimilarity默认 0.3的底分保证不直接出局反馈会以查询哈希为键维护查询-模型亲和度矩阵affinityMatrix胜者 0.1、败者 -0.05用于后续的相似度进化。该组件对模型配置有硬性要求必须为模型提供description和capabilities否则 RouterDC 的信号质量会显著下降如果开启require_descriptions: true缺少描述的模型会导致初始化直接报错见ValidateConfig。AutoMix 组件POMDP 价值函数AutoMix 实现位于 automix.go参考 NeurIPS 2024 论文arXiv:2310.12963对每个模型维护ModelCapability成本每百万 token 单价、平均质量分、验证概率VerificationProb、成功/总查询计数等通过 AdaOps POMDP 求解器NewAdaOpsSolver支持belief_particles粒子滤波迭代计算价值函数V(s) R(s) γ × E[V(s)]成本感知模式下CostAwareRouting默认开启价值会除以1 cost × CostWeight做成本惩罚并给验证概率高于阈值的模型 10% 的加分CostQualityTradeoff默认 0.3控制质量与成本的平衡0 纯质量1 纯成本质量分可来自配置中的quality_score/ catalog 证据EvidenceScore也可来自历史反馈的学习值EMA 更新学习率 0.1。Cost 组件成本效率信号Hybrid 的成本信号不单独依赖一个 selector而是在InitializeFromConfig阶段从模型配置的pricing.input_cost_per_1k源码中映射为Pricing.PromptPer1M填充modelCosts映射然后由applyCostAdjustmenthybrid.go执行bonus : (1 - (cost-minCost)/(maxCost-minCost)) * costWeight * h.config.CostWeight scores[i].Score * 1 bonus即成本越低的模型获得越大的乘法加成且该加成同时受请求级成本权重selCtx.CostWeight与算法级CostWeight双重约束当所有候选成本相同maxCost minCost时跳过调整。配置详解完整 YAML 示例原文档给出的配置结构如下与真实配置 schema 高度一致字段名在源码 selection_config.go 中定义decision: algorithm: type: hybrid hybrid: experience_weight: 0.3 # 文档中称 elo_weight源码字段为 experience_weight router_dc_weight: 0.3 automix_weight: 0.2 cost_weight: 0.2 normalize_scores: true # Underlying method configs elo: k_factor: 32 initial_rating: 1500 router_dc: require_descriptions: true automix: cost_quality_tradeoff: 0.3 models: - name: gpt-4 description: Advanced reasoning and analysis capabilities: [reasoning, code, analysis] quality_score: 0.95 pricing: input_cost_per_1k: 0.03 output_cost_per_1k: 0.06 - name: gpt-3.5-turbo description: Fast general-purpose responses capabilities: [general, chat] quality_score: 0.75 pricing: input_cost_per_1k: 0.0015 output_cost_per_1k: 0.002字段说明与默认值字段含义默认值experience_weightElo 反馈评分权重源码字段名文档中的elo_weight为其别名0.3router_dc_weightRouterDC 语义相似度权重0.3automix_weightAutoMix POMDP 价值权重0.2cost_weight成本权重0.2quality_gap_threshold质量差阈值用于触发向更大模型升级的决策源码支持供后续升级逻辑使用0.1use_mlp是否启用 MLP 质量差预测高级选项falsenormalize_scores是否在加权前将各分量归一化到 [0,1]true四个权重的默认值可以在 hybrid.go 的DefaultHybridConfig()中直接看到。仓库自带的算法片段配置 config/fragments/algorithm/selection/hybrid.yaml 给出了另一组可直接套用的取值experience_weight: 0.4 / router_dc_weight: 0.4 / automix_weight: 0.2 / cost_weight: 0.1并已实际被 config 目录下的知识库与 recipe 引用。关于权重命名的注意点原文档 YAML 使用elo_weight而源码HybridSelectionConfig的实际 YAML 字段是experience_weight历史命名沿革二者指代同一信号。在真实部署配置中请以源码 schema 为准使用experience_weight。模型配置要求models列表是 Hybrid 的数据基础description与capabilities供 RouterDC 生成模型 embeddingquality_score供 AutoMix 初始化质量分源码中经EvidenceScore读取归一化为 0-1pricing.input_cost_per_1k供 Cost 组件计算成本效率源码读取的是每百万 token 单价PromptPer1M二者同源。权重预设文档给出了四种面向不同场景的权重预设可直接作为调参起点预设EloRouterDCAutoMixCost适用场景Balanced0.250.250.250.25通用场景Quality-focused0.40.30.20.1高价值/高风险任务Cost-focused0.10.20.20.5预算敏感场景Learning-focused0.50.20.20.1快速适应反馈需要提醒的是真实配置中权重之和必须为 1.0允许 ±0.01 容差。配置校验器vllm-sr CLI 的 test_hybrid_validator.py会拒绝全部为零的权重组合同时允许部分权重组合如只配experience_weight: 0.6 router_dc_weight: 0.4因为BlendCandidateScores会对缺失组件做池级归一化兜底。工作前提与依赖要让 Hybrid 选择达到最佳效果四个组件各自需要对应的数据输入Elo 组件需要通过/api/v1/feedback接口持续收集用户反馈评分才会随真实使用逐步收敛RouterDC 组件模型必须配置description与capabilities且路由进程需要可用的 embedding 模型通过 embedding 函数注入AutoMix 组件需要为模型配置pricing与quality_score历史反馈会进一步修正质量分与验证概率权重校验所有权重之和必须落在 1.0 ± 0.01 内否则会触发校验错误。反馈的数据契约可以参考 feedback.go 的ValidateFeedbackwinner_model与loser_model至少填一个、二者不能相同、confidence必须在 [0,1] 区间。关于反馈的传播机制Hybrid 的反馈更新并不只作用于 Elo 组件——HybridSelector.UpdateFeedbackhybrid.go会把一条反馈同时广播给 Elo、RouterDC、AutoMix 三个子组件Elo 按 Bradley-Terry 公式更新评分RouterDC 更新查询-模型亲和度矩阵AutoMix 更新模型的VerificationProb与AvgQualityEMA 学习率 0.1并触发一次 POMDP 价值函数迭代。正因如此一条反馈可以同时驱动三条学习路径这也是 Hybrid 相比单方法路由更快收敛的结构性原因。需要留意的是当 RouterDC 或 AutoMix 参与混合时反馈必须携带winner_modelrequiresWinnerFeedback否则返回ErrFeedbackWinnerRequired。运行时观测与可解释性Hybrid 在生产环境中是可观测、可解释的结构化日志每次选择会输出各组件得分与最终综合分[HybridSelector] model: experience0.3000, dc0.7000, am0.5000 → combined0.4800置信度calculateConfidence综合组件共识比例与组件平均置信度输出 0-1 的Confidence字段推理文本buildReasoning生成类似Hybrid combination: [Experience0.300 RouterDC0.700 AutoMix0.500], weights[elo:0.30, dc:0.30, am:0.20, cost:0.20]的可读原因随 SelectionResult 返回可直接透出给调用方或接入审计指标组件共识比例通过RecordComponentAgreement记录可用于监控各组件与最终决策的一致性趋势。最佳实践从均衡权重起步先使用 Balanced 预设各 0.25观察一段时间线上行为后再针对性调整监控各分量的贡献度通过日志或指标跟踪哪个组件对最终选择贡献最大判断信号质量是否健康例如 RouterDC 长期不起作用说明模型描述或 embedding 配置有问题渐进式调参每次调整幅度控制在 0.050.1避免一次大改导致路由行为剧烈抖动校验权重任何改动后确保四个权重之和为 1.0±0.01否则会被配置校验拒绝数据前置如果决定启用 RouterDC 分量务必先补齐所有候选模型的description与capabilities否则相似度信号退化为底分反而稀释其他信号反馈闭环Elo/AutoMix 的长期价值依赖持续、真实的反馈流建议结合/api/v1/feedback打通线上反馈采集。验证方式仓库提供了可直接运行验证的测试selector_test.go 的TestHybridSelector_Select构造两个候选模型不同 Elo 评分与 AutoMix 能力关闭 RouterDC 与 Cost 后验证 Hybrid 正确选出评分 质量双高的模型test_hybrid_validator.py验证配置校验器对全零权重的拒绝与对部分权重的接受router_selection_config_test.go验证 extproc 层对 hybrid 配置的解析与装配。小结Hybrid Selection 是 semantic-router 中多信号融合的代表性选择算法它以一组可配置权重将 Elo 反馈评分、RouterDC 语义相似度、AutoMix POMDP 价值与成本效率统一为一个 [0,1] 的综合得分兼顾了反馈学习、语义匹配、质量评估与成本控制四种视角其实现既保留了加权集成的简单可解释性又通过缺失组件池级归一化、反馈广播传播、置信度计算等机制保证了生产环境的健壮性与可观测性。对需要在响应质量与调用成本之间寻找平衡点的路由场景而言它是比单一算法更全面的默认选择。赞分享后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载相关推荐semantic-router 的 GMT Router 算法实战基于多轮用户反馈的个性化模型选择semantic router 的 GMT Router 算法实战基于多轮用户反馈的个性化模型选择 gmtrouter 是 semantic router 中后端API网关模型推理服务AI Agentsemantic-router 的 AutoMix 选择器基于 POMDP 的成本-质量权衡模型选择算法详解与配置实战semantic router 的 AutoMix 选择器基于 POMDP 的成本 质量权衡模型选择算法详解与配置实战 AutoMix automix 是后端API网关模型推理服务AI Agentsemantic-router 的 latency_aware 算法基于 TTFT/TPOT 百分位的延迟感知模型选择semantic router 的 latency_aware 算法基于 TTFT/TPOT 百分位的延迟感知模型选择 导读 latency_aware 是后端API网关模型推理服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载在模型路由系统中单一选择方法往往只能捕捉一种信号用户反馈、语义相似度、成本、质量各有侧重很难同时兼顾。semantic-router 的Hybrid Selection混合选择算法正是为解决这一问题而设计——它通过可配置权重将 Elo 反馈评分、RouterDC 语义匹配、AutoMix 质量价值与成本效率四种信号融合为统一的综合得分从而在用户体验与资源开销之间做出更稳健的决策。读完本文你将掌握 Hybrid 的数学公式、Go 核心实现、完整 YAML 配置方法、权重预设思路以及各组件在源码层面的工作原理并能在自己的路由配置中直接落地使用。Hybrid Selection 的设计动机与定位Hybrid selection 的核心思想是组合多种选择方法Elo、RouterDC、AutoMix、Cost并配以可配置的权重。这样可以在一次路由决策中同时平衡用户反馈历史Elo 评分反映真实使用体验语义匹配度RouterDC反映查询与模型能力的语义相关性质量评分AutoMix 的 POMDP 价值函数成本效率按 token 单价折算的成本信号。与 Hybrid LLM 论文的区别值得说明的是业界存在一篇同名的 Hybrid LLMDing et al.论文它训练了一个基于 BERT 的质量差quality-gap预测器用于在两个模型之间做二元路由最高可减少约 40% 的昂贵模型调用。semantic-router 的实现采用了完全不同的技术路线不是训练二元分类器而是构建一个加权集成weighted ensemble把 Elo 评分、语义相似度、POMDP 价值、成本等多路信号线性融合。从源码注释也可以印证这一点在 hybrid.go 的HybridConfig定义中注释明确标注 Based on arXiv:2404.14618同时保留了论文中质量差阈值quality_gap_threshold与 MLP 预测开关use_mlp作为可选项但主路径仍然是我们将要剖析的加权融合。算法流程整个混合选择的执行链路可以用下面的流程图概括流程要点用户查询进入路由决策四个组件各自独立计算候选模型的得分Elo 评分、RouterDC 相似度、AutoMix 价值、成本效率各分量被归一化到 [0, 1] 区间可由normalize_scores开关控制按配置权重做加权求和选择综合得分最高的模型并路由。数学基础综合得分公式Hybrid 对每个候选模型m与查询q计算综合得分score(m, q) w_elo × E(m) w_dc × S(q,m) w_mix × V(m,q) w_cost × C(m)其中E(m) 归一化后的 Elo 评分S(q, m) 归一化后的 RouterDC 相似度V(m, q) 归一化后的 AutoMix 价值C(m) 归一化后的成本效率1 - relative_costΣw_i 1所有权重之和必须为 1。分量归一化每个分量都要先被归一化到 [0, 1] 区间才能参与加权求和分量归一化方式EloE (R - 1000) / 1000超出范围时截断/clampRouterDC本身即 [0, 1]余弦相似度经 sigmoid 映射AutoMixV (V - V_min) / (V_max - V_min)CostC 1 - (cost / max_cost)在真实源码中归一化由 scoring.go 的NormalizeCandidateScores实现它会先扫描所有候选的原始得分求出 min/max再按(value - min) / (max - min)映射对越低越好LowerIsBetter的信号如成本再取1 - value反向。这与文档中表格的描述一致并且实现上对全同值集合做了保护。核心算法Go 实现原文档给出了一个简化版Select伪代码。真实的实现位于 hybrid.go其骨架如下// Select chooses the best model by combining multiple selection methods func (h *HybridSelector) Select(ctx context.Context, selCtx *SelectionContext) (*SelectionResult, error) { if err : ValidateSelectionContext(selCtx); err ! nil { return nil, err } // Collect scores from each component componentScores : make(map[string]CandidateScores) var componentResults []*SelectionResult // Get feedback-derived experience scores if h.eloSelector ! nil h.config.ExperienceWeight 0 { result, err : h.eloSelector.Select(ctx, selCtx) if err nil result ! nil { componentScores[experience] result.ScoresFor(selCtx.CandidateModels) componentResults append(componentResults, result) } } // Get RouterDC scores if h.routerDCSelector ! nil h.config.RouterDCWeight 0 { result, err : h.routerDCSelector.Select(ctx, selCtx) // ... componentScores[router_dc] result.ScoresFor(selCtx.CandidateModels) } // Get AutoMix scores if h.autoMixSelector ! nil h.config.AutoMixWeight 0 { result, err : h.autoMixSelector.Select(ctx, selCtx) // ... componentScores[automix] result.ScoresFor(selCtx.CandidateModels) } // Normalize scores if enabled if h.config.NormalizeScores { for component, scores : range componentScores { componentScores[component] NormalizeCandidateScores(scores, HigherIsBetter) } } // Combine scores with weights combinedScores : h.combineScores(componentScores, selCtx.CandidateModels) // Apply cost adjustment if h.config.CostWeight 0 { h.applyCostAdjustment(combinedScores, selCtx.CostWeight) } best : combinedScores.Best(HigherIsBetter, false) // ... return SelectionResult{ SelectedModel: bestModel.Model, Score: bestScore, Confidence: confidence, Method: MethodHybrid, Reasoning: reasoning, AllScores: combinedScores.Diagnostics(), CandidateScores: combinedScores, }, nil }与原文档中的简化版相比真实实现有三个值得注意的增强点零权重短路只有当某组件权重 0时才调用对应 selector 的Select避免无谓的计算开销例如禁用 RouterDC 时不会触发 embedding缺失组件的容错某个组件不可用如没有 embedding 函数时该分量为空BlendCandidateScores会按可用组件权重归一化处理而不是把缺失当作零分——参见 scoring.go 的实现置信度与可解释性真实实现还会根据各组件对最终选择的共识程度计算ConfidencecalculateConfidence并生成人类可读的Reasoning文本例如Hybrid combination: [Experience0.623 RouterDC0.845], weights[elo:0.30, dc:0.30, am:0.20, cost:0.20]。加权融合的池级归一化细节源码中的BlendCandidateScoresscoring.go实现了一个重要语义权重按实际可用组件重新归一化。即如果某个组件没有任何得分例如候选模型缺少描述导致 RouterDC 无法打分它的权重会被剔除其余可用组件按比例放大。这保证了即使部分信号缺失最终得分仍是一个有意义的相对排名而不是被零值拉低。四个组件的源码级原理Elo 组件基于反馈的评分学习Elo 组件的实现位于 elo.go其设计参考了 RouteLLM 论文arXiv:2406.18665的 Bradley-Terry 模型初始评分initial_rating默认 1500DefaultEloRatingK 因子k_factor默认 32控制每次反馈后评分的波动幅度支持全局评分与按决策类别category的评分两套体系CategoryWeighted默认开启反馈更新遵循标准 Elo 公式R R K × (actual - expected)其中期望胜率E_a 1 / (1 10^((R_b - R_a) / 400))还支持单模型自我反馈只有winner_model正向或只有loser_model负向时按 K 因子的 10% 做小幅奖惩评分可以通过StoragePath持久化到 JSON 文件并支持AutoSaveInterval自动保存默认 30 秒重启后可恢复。在 Hybrid 中使用 Elo 分量时其归一化为(R - 1000) / 1000并 clamp 到 [0,1]——即默认 1500 分映射为 0.5。RouterDC 组件双对比学习语义匹配RouterDCDual-Contrastive实现位于 router_dc.go参考 arXiv:2409.19886每个模型用其description描述与capabilities能力标签拼接成文本再通过 embedding 函数编码为模型向量InitializeFromConfig中的buildDescriptionText查询向量与模型向量做余弦相似度再除以temperature默认 0.07后用sigmoid映射回 (0,1)computeContrastiveSimilarity分数再做带温度的 softmax 得到最终概率applySoftmax没有描述或 embedding 不可用的模型会拿到MinSimilarity默认 0.3的底分保证不直接出局反馈会以查询哈希为键维护查询-模型亲和度矩阵affinityMatrix胜者 0.1、败者 -0.05用于后续的相似度进化。该组件对模型配置有硬性要求必须为模型提供description和capabilities否则 RouterDC 的信号质量会显著下降如果开启require_descriptions: true缺少描述的模型会导致初始化直接报错见ValidateConfig。AutoMix 组件POMDP 价值函数AutoMix 实现位于 automix.go参考 NeurIPS 2024 论文arXiv:2310.12963对每个模型维护ModelCapability成本每百万 token 单价、平均质量分、验证概率VerificationProb、成功/总查询计数等通过 AdaOps POMDP 求解器NewAdaOpsSolver支持belief_particles粒子滤波迭代计算价值函数V(s) R(s) γ × E[V(s)]成本感知模式下CostAwareRouting默认开启价值会除以1 cost × CostWeight做成本惩罚并给验证概率高于阈值的模型 10% 的加分CostQualityTradeoff默认 0.3控制质量与成本的平衡0 纯质量1 纯成本质量分可来自配置中的quality_score/ catalog 证据EvidenceScore也可来自历史反馈的学习值EMA 更新学习率 0.1。Cost 组件成本效率信号Hybrid 的成本信号不单独依赖一个 selector而是在InitializeFromConfig阶段从模型配置的pricing.input_cost_per_1k源码中映射为Pricing.PromptPer1M填充modelCosts映射然后由applyCostAdjustmenthybrid.go执行bonus : (1 - (cost-minCost)/(maxCost-minCost)) * costWeight * h.config.CostWeight scores[i].Score * 1 bonus即成本越低的模型获得越大的乘法加成且该加成同时受请求级成本权重selCtx.CostWeight与算法级CostWeight双重约束当所有候选成本相同maxCost minCost时跳过调整。配置详解完整 YAML 示例原文档给出的配置结构如下与真实配置 schema 高度一致字段名在源码 selection_config.go 中定义decision: algorithm: type: hybrid hybrid: experience_weight: 0.3 # 文档中称 elo_weight源码字段为 experience_weight router_dc_weight: 0.3 automix_weight: 0.2 cost_weight: 0.2 normalize_scores: true # Underlying method configs elo: k_factor: 32 initial_rating: 1500 router_dc: require_descriptions: true automix: cost_quality_tradeoff: 0.3 models: - name: gpt-4 description: Advanced reasoning and analysis capabilities: [reasoning, code, analysis] quality_score: 0.95 pricing: input_cost_per_1k: 0.03 output_cost_per_1k: 0.06 - name: gpt-3.5-turbo description: Fast general-purpose responses capabilities: [general, chat] quality_score: 0.75 pricing: input_cost_per_1k: 0.0015 output_cost_per_1k: 0.002字段说明与默认值字段含义默认值experience_weightElo 反馈评分权重源码字段名文档中的elo_weight为其别名0.3router_dc_weightRouterDC 语义相似度权重0.3automix_weightAutoMix POMDP 价值权重0.2cost_weight成本权重0.2quality_gap_threshold质量差阈值用于触发向更大模型升级的决策源码支持供后续升级逻辑使用0.1use_mlp是否启用 MLP 质量差预测高级选项falsenormalize_scores是否在加权前将各分量归一化到 [0,1]true四个权重的默认值可以在 hybrid.go 的DefaultHybridConfig()中直接看到。仓库自带的算法片段配置 config/fragments/algorithm/selection/hybrid.yaml 给出了另一组可直接套用的取值experience_weight: 0.4 / router_dc_weight: 0.4 / automix_weight: 0.2 / cost_weight: 0.1并已实际被 config 目录下的知识库与 recipe 引用。关于权重命名的注意点原文档 YAML 使用elo_weight而源码HybridSelectionConfig的实际 YAML 字段是experience_weight历史命名沿革二者指代同一信号。在真实部署配置中请以源码 schema 为准使用experience_weight。模型配置要求models列表是 Hybrid 的数据基础description与capabilities供 RouterDC 生成模型 embeddingquality_score供 AutoMix 初始化质量分源码中经EvidenceScore读取归一化为 0-1pricing.input_cost_per_1k供 Cost 组件计算成本效率源码读取的是每百万 token 单价PromptPer1M二者同源。权重预设文档给出了四种面向不同场景的权重预设可直接作为调参起点预设EloRouterDCAutoMixCost适用场景Balanced0.250.250.250.25通用场景Quality-focused0.40.30.20.1高价值/高风险任务Cost-focused0.10.20.20.5预算敏感场景Learning-focused0.50.20.20.1快速适应反馈需要提醒的是真实配置中权重之和必须为 1.0允许 ±0.01 容差。配置校验器vllm-sr CLI 的 test_hybrid_validator.py会拒绝全部为零的权重组合同时允许部分权重组合如只配experience_weight: 0.6 router_dc_weight: 0.4因为BlendCandidateScores会对缺失组件做池级归一化兜底。工作前提与依赖要让 Hybrid 选择达到最佳效果四个组件各自需要对应的数据输入Elo 组件需要通过/api/v1/feedback接口持续收集用户反馈评分才会随真实使用逐步收敛RouterDC 组件模型必须配置description与capabilities且路由进程需要可用的 embedding 模型通过 embedding 函数注入AutoMix 组件需要为模型配置pricing与quality_score历史反馈会进一步修正质量分与验证概率权重校验所有权重之和必须落在 1.0 ± 0.01 内否则会触发校验错误。反馈的数据契约可以参考 feedback.go 的ValidateFeedbackwinner_model与loser_model至少填一个、二者不能相同、confidence必须在 [0,1] 区间。关于反馈的传播机制Hybrid 的反馈更新并不只作用于 Elo 组件——HybridSelector.UpdateFeedbackhybrid.go会把一条反馈同时广播给 Elo、RouterDC、AutoMix 三个子组件Elo 按 Bradley-Terry 公式更新评分RouterDC 更新查询-模型亲和度矩阵AutoMix 更新模型的VerificationProb与AvgQualityEMA 学习率 0.1并触发一次 POMDP 价值函数迭代。正因如此一条反馈可以同时驱动三条学习路径这也是 Hybrid 相比单方法路由更快收敛的结构性原因。需要留意的是当 RouterDC 或 AutoMix 参与混合时反馈必须携带winner_modelrequiresWinnerFeedback否则返回ErrFeedbackWinnerRequired。运行时观测与可解释性Hybrid 在生产环境中是可观测、可解释的结构化日志每次选择会输出各组件得分与最终综合分[HybridSelector] model: experience0.3000, dc0.7000, am0.5000 → combined0.4800置信度calculateConfidence综合组件共识比例与组件平均置信度输出 0-1 的Confidence字段推理文本buildReasoning生成类似Hybrid combination: [Experience0.300 RouterDC0.700 AutoMix0.500], weights[elo:0.30, dc:0.30, am:0.20, cost:0.20]的可读原因随 SelectionResult 返回可直接透出给调用方或接入审计指标组件共识比例通过RecordComponentAgreement记录可用于监控各组件与最终决策的一致性趋势。最佳实践从均衡权重起步先使用 Balanced 预设各 0.25观察一段时间线上行为后再针对性调整监控各分量的贡献度通过日志或指标跟踪哪个组件对最终选择贡献最大判断信号质量是否健康例如 RouterDC 长期不起作用说明模型描述或 embedding 配置有问题渐进式调参每次调整幅度控制在 0.050.1避免一次大改导致路由行为剧烈抖动校验权重任何改动后确保四个权重之和为 1.0±0.01否则会被配置校验拒绝数据前置如果决定启用 RouterDC 分量务必先补齐所有候选模型的description与capabilities否则相似度信号退化为底分反而稀释其他信号反馈闭环Elo/AutoMix 的长期价值依赖持续、真实的反馈流建议结合/api/v1/feedback打通线上反馈采集。验证方式仓库提供了可直接运行验证的测试selector_test.go 的TestHybridSelector_Select构造两个候选模型不同 Elo 评分与 AutoMix 能力关闭 RouterDC 与 Cost 后验证 Hybrid 正确选出评分 质量双高的模型test_hybrid_validator.py验证配置校验器对全零权重的拒绝与对部分权重的接受router_selection_config_test.go验证 extproc 层对 hybrid 配置的解析与装配。小结Hybrid Selection 是 semantic-router 中多信号融合的代表性选择算法它以一组可配置权重将 Elo 反馈评分、RouterDC 语义相似度、AutoMix POMDP 价值与成本效率统一为一个 [0,1] 的综合得分兼顾了反馈学习、语义匹配、质量评估与成本控制四种视角其实现既保留了加权集成的简单可解释性又通过缺失组件池级归一化、反馈广播传播、置信度计算等机制保证了生产环境的健壮性与可观测性。对需要在响应质量与调用成本之间寻找平衡点的路由场景而言它是比单一算法更全面的默认选择。赞分享后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载相关推荐semantic-router 的 GMT Router 算法实战基于多轮用户反馈的个性化模型选择semantic router 的 GMT Router 算法实战基于多轮用户反馈的个性化模型选择 gmtrouter 是 semantic router 中后端API网关模型推理服务AI Agentsemantic-router 的 AutoMix 选择器基于 POMDP 的成本-质量权衡模型选择算法详解与配置实战semantic router 的 AutoMix 选择器基于 POMDP 的成本 质量权衡模型选择算法详解与配置实战 AutoMix automix 是后端API网关模型推理服务AI Agentsemantic-router 的 latency_aware 算法基于 TTFT/TPOT 百分位的延迟感知模型选择semantic router 的 latency_aware 算法基于 TTFT/TPOT 百分位的延迟感知模型选择 导读 latency_aware 是后端API网关模型推理服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
