什么是 Signal-Driven Decision?
Signal-Driven Decision 是 Semantic Router 的核心路由架构。它不再依赖单一分类器,而是并行提取请求的多个维度信号(Signal),并通过布尔树组合它们以做出精确的路由决策。
核心理念
传统路由使用单一信号:
# 传统:单一分类模型
if classifier(query) == "math":
route_to_math_model()
Signal-Driven routing 使用多种 signal:
# 信号驱动:多种信号组合
if (keyword_match AND domain_match) OR high_embedding_similarity:
route_to_math_model()
**核心优势**:通过多维度的信号交叉验证,有效避免了单一模型经常发生的判定盲区,提升了路由的鲁棒性。
## 13 种 Signal 类型
### 1. Keyword Signal
- **内容**:使用 AND/OR 运算符的快速模式匹配
- **延迟**:小于 1ms
- **用例**:确定性路由、合规性、安全性
```yaml
signals:
keywords:
- name: "math_keywords"
operator: "OR"
keywords: ["calculate", "equation", "solve", "derivative"]
示例:"Calculate the derivative of x^2" → 匹配 "calculate" 和 "derivative"
2. Embedding Signal
- 内容:使用 embedding 的语义相似度
- 延迟:10-50ms
- 用例:意图检测、释义处理
signals:
embeddings:
- name: "code_debug"
threshold: 0.70
candidates:
- "My code isn't working, how do I fix it?"
- "Help me debug this function"
示例:"Need help debugging this function" → 0.78 相似度 → 匹配!
3. Domain Signal
- 内容:MMLU 领域分类(14 个类别)
- 延迟:50-100ms
- 用例:学术和专业领域路由
signals:
domains:
- name: "mathematics"
mmlu_categories: ["abstract_algebra", "college_mathematics"]
示例:"Prove that the square root of 2 is irrational" → Mathematics (数学) 领域
4. Fact Check Signal
- 内容:基于机器学习的需要事实验证的查询检测
- 延迟:50-100ms
- 用例:医疗保健、金融服务、教育
signals:
fact_checks:
- name: "factual_queries"
threshold: 0.75
示例:"What is the capital of France?" → 需要事实核查
5. User Feedback Signal
- 内容:用户反馈和更正的分类
- 延迟:50-100ms
- 用例:客户支持、自适应学习
signals:
user_feedbacks:
- name: "negative_feedback"
feedback_types: ["correction", "dissatisfaction"]
示例:"That's wrong, try again" → 检测到负面反馈
6. Preference Signal
- 内容:基于 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" → 偏好创意路由
7. Language Signal
- 内容:多语言检测(100 多种本地化语言)
- 延迟:小于 1ms
- 用例:路由查询特定语言的模型或采用特定语言的策略
signals:
language:
- name: "en"
description: "English language queries"
- name: "es"
description: "Spanish language queries"
- name: "zh"
description: "Chinese language queries"
- name: "ru"
description: "Russian language queries"
- 示例 1:"Hola, ¿cómo estás?" → Spanish (es) → Spanish model
- 示例 2:"你好,世界" → Chinese (zh) → Chinese model
8. Context Signal
- 内容:基于 token 计数的短/长请求处理路由
- 延迟:1ms(处理过程中计算)
- 用例:将长上下文请求路由到具有更大上下文窗口的模型
- 指标:使用
llm_context_token_count直方图跟踪输入 token 计数
signals:
context_rules:
- name: "low_token_count"
min_tokens: "0"
max_tokens: "1K"
description: "短请求"
- name: "high_token_count"
min_tokens: "1K"
max_tokens: "128K"
description: "需要大上下文窗口的长请求"
示例:一个包含 5,000 个 token 的请求 → 匹配 "high_token_count" → 路由到 claude-3-opus
9. Complexity Signal
- 内容:基于 embedding 的查询复杂度分类(困难/简单/中等)
- 延迟:50-100ms(embedding 计算)
- 用例:将复杂查询路由到强大模型,简单查询路由到高效模型
- 逻辑:两步分类:
- 通过将查询与规则描述进行比较,找到最匹配的规则
- 使用困难/简单候选 embedding 在该规则内分类难度
signals:
complexity:
- name: "code_complexity"
threshold: 0.1
description: "检测代码复杂度级别"
hard:
candidates:
- "design distributed system"
- "implement consensus algorithm"
- "optimize for scale"
easy:
candidates:
- "print hello world"
- "loop through array"
- "read file"
示例:"How do I implement a distributed consensus algorithm?" → 匹配 "code_complexity" 规则 → 与困难候选高度相似 → 返回 "code_complexity:hard"
工作原理:
- 将查询 embedding 与每个规则的描述进行比较
- 选择最匹配的规则(描述相似度最高)
- 在该规则内,将查询与困难和简单候选进行比较
- 难度信号 = max_hard_similarity - max_easy_similarity
- 如果信号 > 阈值:"hard",如果信号 < -阈值:"easy",否则:"medium"
10. Modality Signal
- 内容:将提示词分类为纯文本(AR)、图像生成(DIFFUSION)或两者兼有(BOTH)
- 延迟:50-100ms(内联模型推理)
- 用例:将多模态或创意提示词路由到专用生成模型
signals:
modality:
- name: "image_generation"
description: "需要图像合成的请求"
- name: "text_only"
description: "无需图像输出的纯文本响应"
示例:"画一幅海洋上的日落" → DIFFUSION 模态 → 路由到图像生成模型
工作原理:Modality 检测器(在 inline_models 的 modality_detector 中配置)使用小型分类器判断查询需要文本、图像还是两种输出模式。结果作为信号发出,并在决策中通过规则 name 引用。
11. Authz Signal(RBAC)
- 内容:Kubernetes 风格的 RoleBinding 模式——将用户/用户组映射到命名角色,这些角色充当信号
- 延迟:<1ms(从请求头读取,无需模型推理)
- 用例:基于等级的访问控制——将高级用户路由到更好的模型,限制访客访问
signals:
role_bindings:
- name: "premium-users"
role: "premium_tier"
subjects:
- kind: Group
name: "premium"
- kind: User
name: "alice"
description: "可访问 GPT-4 级别模型的高级用户"
- name: "guest-users"
role: "guest_tier"
subjects:
- kind: Group
name: "guests"
description: "仅限使用小模型的访客用户"
示例:请求携带请求头 x-authz-user-groups: premium → 匹配 premium-users 绑定 → 发出信号 authz:premium_tier → 决策路由到 gpt-4o
工作原理:
- 用户身份(
x-authz-user-id)和用户组成员关系(x-authz-user-groups)由 Authorino / ext_authz 注入 - 每个
RoleBinding检查用户 ID 是否匹配任意Usersubject,或用户的任意用户组是否匹配Groupsubject(subject 内部为 OR 逻辑) - 匹配时,
role值作为类型为authz的信号发出 - 决策通过
type: "authz", name: "<role>"引用
Subject 名称必须与 Authorino 注入的值匹配。用户名来自 K8s Secret 的
metadata.name;用户组名来自authz-groups注解。
12. Jailbreak Signal
- 内容:通过两种互补的方法(BERT 分类器和对比嵌入)进行对抗性提示词和 Jailbreak 尝试检测
- 延迟:50–100ms(BERT 分类器);50–100ms(对比法,初始化后)
- 用例:阻断单轮提示词注入 以及 多轮升级的渐进式攻击