后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载信号驱动决策Signal-Driven Decision是 Semantic Router 实现智能路由的核心架构它从每个请求中提取多个维度的信号再通过 AND/OR/NOT 布尔规则组合这些信号最终选出最合适的模型与执行路径。本指南围绕该架构完整讲解 6 种信号类型keyword / embedding / domain / fact_check / user_feedback / preference的配置方式、组合策略与底层实现原理读完即可在 config/config.yaml 中落地一套多信号协同的路由配置。核心思想从单一信号到多信号投票传统路由通常只依赖单一信号做判断例如# Traditional: Single classification model if classifier(query) math: route_to_math_model()这种模式的问题在于任何一个单一信号都可能在特定场景下误判关键词歧义、嵌入相似度噪声、分类模型偏差。信号驱动路由则改为让多个信号同时参与表决# Signal-driven: Multiple signals combined if (keyword_match AND domain_match) OR high_embedding_similarity: route_to_math_model()为什么这很重要多个信号共同投票做出的决策比任何单一信号都更准确。关键词确认了词汇层面的强匹配嵌入相似度确认了语义层面的相关性域分类则确认了知识范畴——三者相互印证既降低了误路由false positive的概率也避免了单一信号漏判false negative导致的错误兜底。从实现上看这一思想在 decision engine 中落地为SignalMatches结构它一次携带全部已命中的信号名称KeywordRules、EmbeddingRules、DomainRules、FactCheckRules、UserFeedbackRules、PreferenceRules等并附上每个信号的置信度SignalConfidences键为signalType:ruleName与原始数值SignalValues供决策引擎做布尔求值与置信度排序。6 种信号类型详解1. Keyword 信号亚毫秒级的确定性匹配原理对请求文本做快速模式匹配支持 AND/OR 运算符延迟小于 1ms适用场景确定性路由、合规与安全PII 关键词、禁用词、高吞吐流量基础配置signals: keywords: - name: math_keywords operator: OR keywords: [calculate, equation, solve, derivative]示例Calculate the derivative of x^2 → 命中 calculate 与 derivative 两个关键词。仓库中的真实配置比文档示例更丰富。查看 config/fragments/signal/keyword/nlp.yaml可以看到 keyword 信号还支持多种匹配方法与阈值routing: signals: keywords: - name: code_keywords operator: OR method: bm25 # 使用 BM25 排序检索匹配 keywords: [code, function, debug, algorithm, refactor] bm25_threshold: 0.1 case_sensitive: false - name: urgent_keywords operator: OR method: ngram # 使用 n-gram 模糊匹配 keywords: [urgent, immediate, asap, emergency] ngram_threshold: 0.4 ngram_arity: 3 # n-gram 的 n 值 case_sensitive: false对应的 正则版配置 则展示了纯关键词列表的写法。而在 config/config.yaml 的主配置中keyword 信号还支持method: fuzzy与fuzzy_threshold用于对 social security、credit card 这类敏感词做容错匹配。从源码结构看signal_config.goKeywordRule的完整字段包括operator、case_sensitive、method、fuzzy_match、fuzzy_threshold、bm25_threshold、ngram_threshold、ngram_arity这正是决定 keyword 信号快而准的底层参数。2. Embedding 信号语义相似度匹配原理通过 embedding 计算请求与候选锚点文本的余弦相似度延迟10-50ms适用场景意图识别、改写/同义表达的兜底匹配配置signals: embeddings: - name: code_debug threshold: 0.70 candidates: - My code isnt working, how do I fix it? - Help me debug this function示例Need help debugging this function → 相似度 0.78 → 命中仓库中的 support.yaml 展示了多候选与aggregation_method的用法routing: signals: embeddings: - name: technical_support threshold: 0.75 aggregation_method: max # 对多个候选取 max/mean/any 聚合 candidates: - how to configure the system - installation guide - troubleshooting steps - error message explanation - setup instructions从 signal_config.go 可以看到EmbeddingRule还支持aggregation_method枚举值为mean/max/any、image_candidates/negative_candidates多模态与对比候选、query_modalitytext/image/audio等高级字段说明 embedding 信号不仅用于文本意图还可扩展到多模态路由。决策引擎通过SignalConfidences中embedding:ruleName的真实相似度得分参与置信度排序。3. Domain 信号MMLU 域分类原理基于 MMLU 数据集训练的域分类模型覆盖 14 个学科类别延迟50-100ms适用场景学术与专业领域的路由配置signals: domains: - name: mathematics mmlu_categories: [abstract_algebra, college_mathematics]示例Prove that the square root of 2 is irrational → 分类为 Mathematics 域。仓库中 mmlu.yaml 给出了完整的 14 类域定义biology、business、chemistry、computer science、economics、engineering、history、law、math、philosophy、physics、psychology、health、other每个域都带description与mmlu_categories。在 config/config.yaml 的主配置中domain 信号还支持model_scores字段为每个域绑定评分模型domains: - name: business description: Business and management related queries. mmlu_categories: [business] model_scores: - model: qwen3-32b score: 0.96 use_reasoning: true决策引擎的matchesDomainConditionengine.go实现了域匹配的两种路径检测域直接等于类别名或检测域落在该类别的mmlu_categories列表内。4. Fact Check 信号事实核验需求检测原理基于 ML 检测请求是否需要事实核验延迟50-100ms适用场景医疗健康、金融服务、教育领域配置signals: fact_checks: - name: factual_queries threshold: 0.75示例What is the capital of France? → 需要事实核验。仓库中的 needs-verification.yaml 采用双向规则设计——既声明需要核验也声明无需核验routing: signals: fact_check: - name: needs_fact_check description: Queries with factual claims that should be verified against evidence. - name: no_fact_check_needed description: Creative or opinion-heavy prompts that do not need factual verification.对应地SignalMatches中的FactCheckRules字段注释明确说明其取值就是needs_fact_check或no_fact_check_neededengine.go决策规则可以直接按名字引用这两个结果。5. User Feedback 信号用户反馈与纠错分类原理对用户反馈与纠错行为进行分类延迟50-100ms适用场景客服场景、自适应学习配置signals: user_feedbacks: - name: negative_feedback feedback_types: [correction, dissatisfaction]示例Thats wrong, try again → 检测为负面反馈。仓库中的 escalation.yaml 定义了答错与需要澄清两类反馈routing: signals: user_feedbacks: - name: wrong_answer description: User indicates the current answer is incorrect. - name: need_clarification description: User asks for a clearer or more detailed follow-up.SignalMatches.UserFeedbackRules的注释列出了完整取值集合need_clarification、satisfied、want_different、wrong_answerengine.go。这类信号在客服场景中驱动回答错误 → 换更强大的模型重试的降级路由。6. Preference 信号LLM 路由偏好匹配原理调用外部 LLM 做路由偏好匹配延迟200-500ms适用场景复杂意图分析其他信号不足时配置signals: preferences: - name: creative_writing llm_endpoint: http://localhost:8000/v1 model: gpt-4 routes: - name: creative description: Creative writing, storytelling, poetry示例Write a story about dragons → 偏好 Creative 路由。仓库中的 power-user.yaml 展示了基于示例文本与阈值的轻量写法routing: signals: preferences: - name: terse_answers description: Users who prefer short, direct responses. examples: - keep it concise - bullet points only - answer in one paragraph threshold: 0.7从 signal_config.go 看PreferenceRule的核心字段是examples偏好锚点文本与threshold。由于它依赖外部 LLM 调用延迟最高200-500ms因此文档建议将其用于其他信号不足以判断的复杂场景而不是作为每个请求的默认信号。信号如何组合决策规则Decision Rules单个信号只回答请求长什么样组合规则才回答该往哪路由。决策decision通过布尔树把多个信号条件拼装起来其递归求值实现在evalNodeengine.go叶子节点检查具体信号是否命中AND/OR/NOT 组合节点对子节点结果做布尔运算。AND 运算符全部条件必须命中decisions: - name: advanced_math rules: operator: AND conditions: - type: keyword name: math_keywords - type: domain name: mathematics逻辑仅当 keyword 与 domain 同时命中时才路由到 advanced_math。适用场景高置信路由降低误报false positives。仓库中的真实案例是 urgent-business.yaml它要求商务域 紧急关键词同时成立才走urgent_business_route并配置了priority: 140与模型引用routing: decisions: - name: urgent_business_route description: Match only when business intent and urgent language appear together. priority: 140 rules: operator: AND conditions: - type: domain name: business - type: keyword name: urgent_keywords modelRefs: - model: qwen2.5:3b use_reasoning: falseOR 运算符任一条件命中即可decisions: - name: code_help rules: operator: OR conditions: - type: keyword name: code_keywords - type: embedding name: code_debug逻辑keyword 或 embedding 任一命中即路由到 code_help。适用场景宽覆盖降低漏报false negatives。仓库案例 business-or-law.yaml 让业务与法律两个域共享一条路由routing: decisions: - name: business_or_law_route description: Share one route across either business or law traffic. priority: 100 rules: operator: OR conditions: - type: domain name: business - type: domain name: law modelRefs: - model: qwen2.5:3b use_reasoning: false嵌套逻辑组合布尔树表达复杂规则decisions: - name: verified_math rules: operator: AND conditions: - type: domain name: mathematics - operator: OR conditions: - type: keyword name: proof_keywords - type: fact_check name: factual_queries逻辑当mathematics 域且proof 关键词 或 需要事实核验时路由。适用场景复杂路由场景。仓库中更完整的三层嵌套案例是 priority-safe-escalation.yaml它组合了 AND、OR 与 NOT并启用了推理模型routing: decisions: - name: priority_safe_escalation_route description: Combine AND, OR, and NOT for a realistic multi-signal routing case. priority: 160 rules: operator: AND conditions: - type: domain name: business - operator: OR conditions: - type: keyword name: urgent_keywords - type: complexity name: needs_reasoning:hard - operator: NOT conditions: - type: jailbreak name: prompt_injection modelRefs: - model: qwen2.5:3b use_reasoning: true注意其中的NOT分支这是决策引擎evalNOTengine.go的典型用法——排除式守卫。NOT是严格一元运算符要求恰好 1 个子节点当子条件不命中时结果为真常用于除注入攻击外均可路由这类安全策略。独立的 NOT 决策示例见 exclude-jailbreak.yamlrouting: decisions: - name: safe_only_route description: Match only when the known prompt-injection signal is absent. priority: 70 rules: operator: NOT conditions: - type: jailbreak name: prompt_injection modelRefs: - model: qwen2.5:3b use_reasoning: false端到端示例一道数学证明题的完整路由过程把上面的信号与组合规则串起来看一个真实场景。用户请求Prove that the square root of 2 is irrational信号提取signals_detected: keyword: true # prove, square root, irrational embedding: 0.89 # 与数学类查询的嵌入相似度极高 domain: mathematics # MMLU 分类结果 fact_check: true # 证明题需要核验决策过程decision: advanced_math reason: All math signals agree (keyword embedding domain fact_check) confidence: 0.95 selected_model: qwen-math为什么这样路由是合理的多信号互相印证关键词、嵌入相似度、域分类、事实核验四个信号全部一致 → 高置信度事实核验已开启保证回答经过质量校验专用模型qwen-math 最适合数学证明类任务在引擎层面这个流程对应EvaluateDecisionsWithSignalsengine.go所有命中的信号被组装进SignalMatches后引擎逐条求值决策的布尔树AND要求全命中、OR取最高置信度分支、NOT取反最后按策略如优先级策略在多个命中决策中选出胜者并返回DecisionResult包含Decision、Confidence、MatchedRules与ConfidenceScored标记。深入原理决策引擎如何求值信号组合输入模型SignalMatches一次携带所有信号命中情况与置信度见 engine.go每种信号类型对应一个[]string字段置信度以map[string]float64按signalType:ruleName键存储。递归求值evalNode递归遍历规则树叶子节点通过matchesSignalType检查信号是否命中组合节点分别走evalAND全命中才真空 AND 视为兜底 catch-all、evalOR任一命中多分支命中时按preferredMatch选择报分更高者、evalNOT严格一元取反。置信度传播evalAND在恰好一个证据叶子报分时直接继承该得分多叶子时取各命中子节点置信度的均值此时不参与报分排序见andEvidence.apply的注释逻辑evalOR取报分最高的匹配分支。未知策略当信号评估出错且配置了on_unknown策略时叶子求值可返回evaluationUnknown状态由applyUnknownPolicy决定最终行为避免因某个信号故障导致整个决策链失效。信号配置解析所有信号规则由 signal_config.go 中的Signals结构统一承载目前声明的信号族已远超 6 类还包括language、context、structure、complexity、modality、jailbreak、safety、pii、kb、conversation、event、metadata、classifier、actions等——但 v0.1 版本文档所讲的 6 类信号keyword、embedding、domain、fact_check、user_feedback、preference仍是决策组合的基础骨架。实操建议与下一步先小后大从单一 keyword 或 embedding 信号起步验证匹配效果后再叠加 domain、fact_check 等信号。善用优先级与策略多个决策同时命中时priority数值越大越优先路由策略strategy可选 priority / confidence / hybrid具体可参考 config/config.yaml 中的strategy: priority配置。注意延迟分层keyword1ms与 embedding10-50ms适合高频路径preference200-500ms这类 LLM 依赖信号只用于关键分支避免拖慢整体路由。安全信号纳入组合参考 priority-safe-escalation.yaml用NOT把 jailbreak 检测作为硬性排除条件让高质量路由与安全守卫并存。继续深入学习的仓库文档配置指南信号与决策的完整配置项说明Keyword Routing 教程keyword 信号实战Embedding Routing 教程embedding 信号实战Domain Routing 教程domain 信号实战新版 Routing Pipeline 总览信号、投影、决策、算法、插件、模型池的完整流水线视图赞分享后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载相关推荐Semantic Router 的 Signal-Driven Decision6 种信号与组合决策机制完全解析Semantic Router 的 Signal Driven Decision6 种信号与组合决策机制完全解析 本文围绕 Semantic Router 的后端API网关模型推理服务AI AgentSemantic Router 信号驱动决策Signal-Driven Decisions完全指南13 种信号与布尔树路由引擎Semantic Router 信号驱动决策Signal Driven Decisions完全指南13 种信号与布尔树路由引擎 Signal Driven后端API网关模型推理服务AI AgentvLLM Semantic Router 架构全解析信号驱动的智能路由层与插件链Signal-Driven Decision Engine Plugin ChainvLLM Semantic Router 架构全解析信号驱动的智能路由层与插件链Signal Driven Decision Engine Plugin后端API网关模型推理服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考