semantic-router 的 NOT 决策：用显式排除规则实现安全门控与高端路由过滤

后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载NOT是 semantic-router 决策目录中最简单也最容易被误用的排除规则当且仅当某个已知信号如越狱注入、PII 泄露不存在时路由才匹配。本文围绕 website/i18n/zh-Hans/docusaurus-plugin-content-docs/version-v0.4/tutorials/decision/not.md 的教程内容展开并结合仓库中的决策引擎源码engine.go、规则校验器validator_rule_operator.go与官方配置片段讲清楚 NOT 决策的配置写法、运行语义、真值表边界和审计注意点帮助你把它用对、用好。NOT 决策是什么让否定策略显式化semantic-router 将决策decision定义为由多个规则以布尔逻辑组合而成的路由判定见 decision_config.go 中Decision结构体。每个决策的rules是一个递归的规则表达式树其组合算子只有三种定义在 validator_rule_operator.goAND所有子条件必须同时匹配OR至少一个子条件匹配即可NOT严格一元算子对其唯一子条件的结果取反。NOT是决策目录中最简单的排除规则路由只在风险信号或不允许的信号缺失时才匹配。它的价值不在于能力复杂而在于把排除这件事从隐式推断变成路由定义中的第一等公民。官方文档给出的四个主要优势见 not.md可以概括为负面策略显式排除条件直接写在路由图中而不是散落在下游处理逻辑里适合安全门控与高端路由排除作为安全拦截之外的第二道防线排除逻辑留在路由图审查者看到路由定义即可理解其意图无需从下游行为反推审计更容易被否定的信号有名字prompt_injection等排查时可以直接定位。它解决什么问题隐式排除的审计困境有些路由只应在已知风险信号不存在时运行。如果这种排除是隐式的——比如靠下游过滤器静默丢弃、靠某个 AND 条件的恰好没命中来实现——那么审查者只能从下游行为推断路由的真实边界。结果就是路由定义看起来允许一切实际行为却悄悄排除了某些输入安全边界和责任归属都变得模糊。NOT把排除直接写进路由定义一条safe_only_route决策的规则就是prompt_injection信号必须不存在语义一目了然审计时直接看到被点名拒绝的信号。何时使用 NOT三种典型场景根据官方教程以下场景适合使用 NOT 决策必须排除已知越狱或含 PII 的流量例如排除已检测到prompt_injection的请求不让其进入某些模型路径高端路由应避开不安全输入将更昂贵、更权威的模型路径保留给干净流量而非把资源消耗在攻击性输入上升级前某冲突信号必须不存在例如升级/降级到某模型前要求某个冲突信号复杂度、领域、事件信号等不出现。同时要注意使用边界当子信号不可用unknown或未触发时NOT同样会匹配成功——这一点在下面真值表与边界语义一节详述官方明确警告不要把它当作内容安全的证明对访问敏感路由优先使用正向可信条件not.md。配置实战一条完整的 NOT 决策官方配置片段位于 config/fragments/decision/not/exclude-jailbreak.yaml与教程 YAML 完全一致routing: 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逐字段拆解字段取值说明namesafe_only_route决策名称用于日志、指标与追踪命名观测命名空间见 engine.go 的WithRoutingScopedescription一句话描述说明决策意图建议写明排除了哪个信号priority70路由策略为priority时的排序权重值越大优先级越高决策选择见 selection.gorules.operatorNOT组合算子必须为 AND/OR/NOT 之一rules.conditions一个jailbreak条件NOT 是严格一元算子只能有一个子条件且子条件必须引用存在的信号规则modelRefs目标模型列表决策匹配后请求将路由到qwen2.5:3buse_reasoning: false表示关闭模型推理模式type: jailbreak对应 config.go 中定义的信号类型常量SignalTypeJailbreak jailbreakname: prompt_injection引用的是routing.signals.jailbreak下注册的规则名。仓库自带的信号片段 config/fragments/signal/jailbreak/patterns.yaml 给出了配套定义routing: signals: jailbreak: - name: prompt_injection method: contrastive threshold: 0.8 include_history: true description: Detect common prompt-injection or jailbreak attempts. jailbreak_patterns: - ignore previous instructions - reveal the hidden prompt - jailbreak mode benign_patterns: - explain the policy - summarize the safety rules也就是说prompt_injection采用对比contrastive方法检测置信度阈值0.8并参考对话历史include_history: true。只有当该信号的置信度达到阈值从而进入SignalMatches.JailbreakRules见 engine.go 的字段注释NOT 决策才会判定信号存在并取反为不匹配。源码原理NOT 在决策引擎里如何求值归一化与校验NOT 必须恰好一个子条件配置加载阶段会调用 validator_rule_operator.go 的NormalizeRuleOperator对每条决策的规则树做递归归一化trim 空白、统一大写、省略的算子默认补为 AND并对节点形状做校验。与 NOT 相关的强制契约是NOT requires exactly one child condition, got %d——子条件数不是 1 时直接报错validator_rule_operator.go 的validateCombinationArity不支持XOR、多子 NOT、无子 NOT 等形状校验阶段即拒绝防止求值时产生永久不匹配等歧义。求值evalNOT 的真值表决策引擎在 engine.go 的evalNode中按算子分发NOT 分支落到evalNOTengine.go。其真值语义如下子条件求值状态NOT 决策结果说明false信号未命中true匹配confidence 1.0排除条件成立路由放行注意这是结构常数 1.0不是信号上报的校准分数true信号命中false不匹配风险信号存在路由不匹配unknown信号不可用/出错且配置了 on_unknown 策略unknown交由on_unknown策略no_match/match/fail_request见 decision_config.go决定两个关键实现细节值得注意strictly unaryevalNOT遇到 0 个或 2 个以上子条件时不会自行猜测语义而是记警告并当作不匹配处理NOT operator requires exactly 1 child, got %d — treating as non-match。由于校验器已提前拦截正常运行中不会走到该分支NOT 匹配的 confidence 恒为 1.0 且不可比DecisionResult.ConfidenceScored的注释明确指出keyword、language、pii 等从不上报分数的信号、谓词门以及 NOT 守卫都贡献结构常数 1.0该常数不能与基于校准或相似度的分数相比engine.go。因此选择器只会把 confidence 用于同池竞争、且全部成员都上报了同种分数的决策之间排序否则回退到 priorityselection.go 的comparableConfidencePools。测试验证NOT 的行为被明确钉死决策引擎的单元测试 engine_test.goTestDecisionEngine_EvaluateDecisionsWithNOTOperator覆盖了五类场景嵌套 OR 全部未命中时NOT 匹配exclude-coding命中嵌套 OR 任一命中时NOT 不匹配嵌套 OR 全部命中时NOT 不匹配NOT 匹配时 confidence 恒为 1.0同策略下多个 NOT 决策按 priority 排序not-medical-highpriority 20胜出。此外rule_tree_shape_test.go 将配置校验器与求值器钉在一起NOT of matched leaf → false、padded not not 被归一化后求值为true、NOR via nestingNOT 包裹 OR和NAND via nestingNOT 包裹 AND都给出了预期真值而multi-child NOT、childless NOT、XOR等非法形状一律被校验拒绝。这组测试同时证明NOT 可以嵌套在 AND/OR 树中组合出 NOR、NAND 等更复杂的排除逻辑。组合使用NOT 与 AND/OR 的嵌套决策目录 config/fragments/decision 下提供了and/、or/、not/、single/、composite/等官方片段说明这三种算子在设计上就是用来组合的。例如 NOR 的写法是rules: operator: NOT conditions: - operator: OR conditions: - type: jailbreak name: prompt_injection - type: pii name: credit_card这条规则的含义是当越狱注入与 PII 两个信号都不存在时才匹配——一个典型的仅安全流量门。语义上等价于对 OR 结果取反即 NOR。同理NOT包裹AND即 NAND只要不是同时命中若干信号就放行。嵌套时同样受一元约束NOT的conditions列表里放且只放一个子节点。审计与使用注意事项官方教程结尾给出的忠告值得反复强调谨慎使用 NOT并保持被排除的信号显式否则决策难以审计。结合源码语义落地为以下三条实践建议NOT 匹配 ≠ 内容安全子信号不可用或未触发都会让 NOT 匹配成功因此它只证明某个信号没有触发不证明输入是安全的。敏感路由应优先叠加正向可信条件如显式的 domain 白名单、authz 许可信号。给被排除的信号起清晰的名字prompt_injection、credit_card这类名字让审计者一眼看懂排除意图不要用晦涩的内部编号。被否定的信号会出现在DecisionResult.MatchedRules如jailbreak:prompt_injection见 engine.go 的formatMatchedRule与决策追踪中命名直接决定排障效率。合理设置 priorityNOT 决策的 confidence 是结构常数 1.0在confidence路由策略下与其他上报分数的决策不可比此时 priority或 tier是唯一的排序依据。安全门类 NOT 决策建议配合较高的 priority确保在多个决策同时匹配时优先被选中。小结NOT 是语义路由排除逻辑的最小单元配置上只有operator: NOT加一个子条件语义上却是显式否定的关键表达。本文从官方教程出发串起了从配置片段exclude-jailbreak.yaml、信号定义patterns.yaml、配置校验validator_rule_operator.go到引擎求值engine.go与测试验证engine_test.go的完整链路。记住两条底线NOT 是严格一元算子NOT 匹配不等于安全证明——做到这两点NOT 就是安全门控与高端路由排除中最可靠、最可审计的规则原语。赞分享后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载相关推荐semantic-router 中的 NOT 决策用三值逻辑编写显式排除的安全路由semantic router 中的 NOT 决策用三值逻辑编写显式排除的安全路由 导读 本文聚焦 semantic router 决策层中的 NOT 运算后端API网关模型推理服务AI Agentsemantic-router 决策引擎 NOT 操作符实战把排除逻辑写进路由规则semantic router 决策引擎 NOT 操作符实战把排除逻辑写进路由规则 导读 本文聚焦 semantic router 决策层中的 NOT 操后端API网关模型推理服务AI Agentsemantic-router 关键词路由Keyword Routing实战指南用显式规则实现可解释、可审计、亚毫秒级的智能路由semantic router 关键词路由Keyword Routing实战指南用显式规则实现可解释、可审计、亚毫秒级的智能路由 本指南基于 semant后端API网关模型推理服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考