semantic-router Context 信号实战指南:基于 Token 窗口的启发式长上下文路由

📅 发布时间:2026/10/12 2:01:59
semantic-router Context 信号实战指南:基于 Token 窗口的启发式长上下文路由
后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载导读context是 semantic-router 中的一类启发式信号heuristic signal它不依赖分类器推理而是直接根据请求的预估 token 量判断请求是否需要更大的有效上下文窗口从而把长文档流量路由到支持 32K、128K 甚至更大上下文的模型同时让短请求留在更便宜、更快的模型上。读完本文你将掌握routing.signals.context的完整配置语法、闭区间带band语义与边界细节、与模型上下文窗口过滤的协作机制以及如何通过vllm-srCLI 和 Dashboard 校验配置。什么是 Context 信号context信号用于检测需要更大有效上下文窗口的请求。规则定义在routing.signals.context之下属于启发式信号家族——它根据 token 窗口需求而非分类器推断进行路由。src/semantic-router/pkg/config/config.go中将其类型常量为SignalTypeContext context在路由目录routing_surface_catalog.go中作为可被决策规则引用的信号类型注册。解决的问题两个提示可以询问同一个主题但需要的上下文窗口截然不同一个是几行字的问答另一个是几万字的长文档分析。如果路由只看 domain领域长文档可能被送到上下文窗口不够、导致截断或失败的模型上。context通过把上下文窗口需求提升为一等路由输入first-class routing input解决这个问题。核心优势显式化长上下文路由长上下文路由需求不再隐式地埋在模型默认值里而是成为配置中可见、可维护的规则。成本控制防止短提示为超尺寸上下文模型支付不必要的成本长上下文模型通常更贵、更慢。阈值复用同一个上下文阈值可以被多个决策规则复用。信号协同可以很好地与 domain、complexity 等其他信号配合工作形成多维度的路由决策。何时使用满足以下任一场景即可考虑使用context信号部分路由需要 32K、128K 或更大的上下文支持长文档流量应使用不同的模型家族例如专门的 long-context 模型希望短请求停留在更便宜或更快的模型上路由决策依赖上下文规模本身而非仅依赖主题。配置语法在路由器配置文件YAML中信号规则定义如下routing: signals: context: - name: long_context min_tokens: 32K max_tokens: 256K description: Requests that need a larger effective context window.仓库中提供了可直接参考的完整片段长上下文信号配置示例。字段说明字段类型是否必填说明namestring必填信号名称供决策规则以type: context引用不能为空、不能重复min_tokensstringTokenCount二选一闭区间下界含缺省视为 0max_tokensstringTokenCount二选一闭区间上界含缺省表示带为上界开放descriptionstring可选人类可读说明最长 500 字符name与description的约束、min_tokens/max_tokens的格式正则^[0-9](\.[0-9])?[KMkm]?$可在 CRD 类型定义 types_route.go 中看到这也是 Kubernetes 校验与 YAML 解析共用的一份契约。带Band的区间语义每条规则定义的是一个闭区间 token 带当min_tokens token_count max_tokens时匹配。源码实现ContextBounds.Matches可见于 signal_config.go。关键语义规则两个边界都可选但至少设置一个。缺省min_tokens视为 0。省略max_tokens即为开区间带open-ended任何不低于min_tokens的请求都匹配没有上限。通常用它在最后一个带上承接溢出流量使高于最大有界带的请求仍携带上下文信号。对应结构体中的Unbounded字段诊断输出形如[8000, ∞)。min_tokens与max_tokens相等时为精确匹配带只命中该一个 token 数。边界契约测试 context_classifier_test.go 明确验证了 1000 同时落在[0,1K]与[1K,1K]两个带、而 1001 落在两者之外的行为。所有匹配的规则都会被报告按配置顺序返回。带之间允许重叠重叠时两个名称都会出现在x-vsr-matched-context响应头中。该头连同x-vsr-context-token-count的定义见 headers.go。带之间的缺口与重叠会在配置加载时记录 warning。缺口内的请求不匹配任何 context 规则。带分析逻辑ContextBandIssues位于 signal_config.go会返回ContextBandOverlap含Contains判断外层带是否完整包含内层带与ContextBandGap两类问题validator_context_test.go中的TestContextBandIssues验证了 1001~3999 为缺口、wide 完全包含 narrow 等场景。验证会拒绝两个边界均未设置、无法解析、负值、过大值以及min_tokens大于max_tokens的规则。错误信息统一带routing.signals.context[...]前缀见 validator_context_test.go。多带配置示例routing: signals: context: - name: short_context min_tokens: 0 max_tokens: 8K - name: medium_context min_tokens: 8001 max_tokens: 64K - name: long_context min_tokens: 64001 description: Open-ended band; matches everything above 64K tokens.该示例中的long_context即开区间带任何超过 64K token 的请求都会命中它。TestParseYAMLLoadsOpenEndedContextBandvalidator_context_test.go覆盖了此类配置从 YAML 解析到校验的完整链路。数值解析细节K/M 后缀min_tokens/max_tokens接受K与M后缀1.5K、0.5M。解析实现TokenCount.Value位于 signal_config.goK乘 1000M乘 1,000,000支持小数如0.5M 500000并拒绝 NaN、Inf 与负数超过int上限时报 token count is too large。YAML 1.1 类型转换陷阱带限值在解析前会先经过路由器 YAML 解码器的类型化遵循 YAML 1.1 规则0123按八进制解析为 830x10按十六进制解析为 161_000解析为 10001:30不是数字。引用quote一个值可以保持其字面含义例如0123就是 123。vllm-srCLI 应用相同的类型化逻辑因此其校验结果与路由器从转发文件加载的结果一致。环境变量引用带限值可以引用环境变量如${CTX_MIN}。路由器在配置加载时展开它因此 CLI 接受该带但会给出 warning 而不是直接校验它。源码级实现Token 计数与请求上下文估计字符启发式计数器默认计数使用字符启发式而非完整 tokenizeCharactersPerToken 4散文约 4 字节/token。CharacterBasedTokenCounter.CountTokens计算len(text)字节数除以 4 并向上取整是 O(1) 操作对 UTF-8 多语言文本字节数高于字符数会得到保守偏高的估计。实现见 context_classifier.go。请求上下文估计公式路由准入前会基于请求 envelope 做内容无关的上下文估计公式见 request_context_estimate.goceil(TextBytes / 4) StructuredBytes 8192 * ImageCount FramingTokens OutputTokenReserve各组成含义同一文件顶部常量散文文本按 4 字节/tokenschema、工具参数等结构化 JSON 按 1 字节/token估算标点密集的 payload 比散文 token 化更密每张图片预留8K token的保守预算chat 模板的 role/控制 token 预留每条消息 4、工具调用 8、工具定义 8输出 token 预留取自请求的max_tokens/max_completion_tokens。该估计同时解析 OpenAI Chat Completions 与 Anthropic Messages 两种 envelopeEstimateOpenAIRequestContext/EstimateAnthropicRequestContext通过gjson直接消费原始 JSON保留超过 2^53 的整数字面量精度。对消息角色、名称、tool_calls、function_call、response_format 等逐项计入未知的结构化内容按原始词法表示计入而非静默丢弃。分类器与 Token FloorContextClassifier.Classify会计算 token 数并依次比对所有已编译规则ClassifyWithTokenFloor还会把校准后的文本估计与请求 envelope 的保守下限TokenFloor取较大值用于覆盖工具 schema、结果与图片 payload 等不会复制进信号文本的部分。规则在构造时预编译为compiledContextRuleokfalse的规则保留名称用于诊断但永不匹配热路径不做字符串解析。见 context_classifier.go。决策引擎中的引用context 信号以type: contextname: rule_name的形式被决策规则引用例如validator_context_test.go中的 YAML 片段decisions: - name: overflow_route rules: operator: AND conditions: - type: context name: overflow_context modelRefs: - model: model-b use_reasoning: false决策引擎的匹配行为由 engine_context_test.go 验证matches 与 no match 两种用例。与模型上下文窗口的交互依赖与限制context 带只是路由信号不会改变模型的上下文窗口上限——路由器在过滤候选模型时仍会单独强制执行窗口限制token 估计依赖请求表示不保证后端一定接受最终 prompt冷启动时散文按约 4 字节/token 估算随后路由器仅对文本至少 4 KiB 的请求从 provider 上报的 prompt usage 学习真实比例更短的请求中 chat-template 开销占主导报告数量不可靠请保持模型卡上的上下文窗口准确并为生成输出预留空间选路前路由器会移除那些配置的、正的上下文窗口小于预估请求的决策候选缺失上下文元数据的候选仍保持资格向后兼容若所有候选的窗口都已知不足路由器会拒绝请求而不是把它转发给不合格的后端。验证与工具链一致性Router、vllm-srCLI 与 Dashboard 应用相同的校验规则一个通过vllm-sr config validate的带在路由器中也能正常加载。这意味着你可以在部署前用 CLI 先行校验 context 带配置再同步给路由器和 Dashboard三端行为保持一致。配置校验相关的测试接受/拒绝用例全集见 validator_context_test.go。完整实战示例综合以上内容一份覆盖短、中、长、溢出四档的典型配置routing: signals: context: - name: short_context min_tokens: 0 max_tokens: 8K description: Short queries stay on the fast/cheap model. - name: medium_context min_tokens: 8001 max_tokens: 64K description: Medium documents go to the 64K model family. - name: long_context min_tokens: 64001 max_tokens: 256K description: Long documents need a 256K context model. - name: overflow_context min_tokens: 256001 description: Everything above the largest bounded band.配合决策规则引用type: context信号名即可在 Router、vllm-srCLI 与 Dashboard 三端获得一致的长上下文路由行为。注意在最后一个开区间带之前仔细设计边界利用配置加载时的 overlap/gap warning 及早发现带之间的缺口。赞分享后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载相关推荐G-Helper 上手 5 分钟华硕笔记本的轻量级 Armoury Crate 替代G Helper 上手 5 分钟华硕笔记本的轻量级 Armoury Crate 替代 G Helper 是一款华硕笔记本的轻量控制工具性能模式、风扇曲线、显桌面应用系统编程pstack 上下文窗口守护指南有限上下文的 token 预算与子代理路由策略pstack 上下文窗口守护指南有限上下文的 token 预算与子代理路由策略 导读 principle guard the context window 是人工智能AI 技能AI 插件开发工具semantic-router 结合 Istio Gateway 部署指南基于 ExtProc 与 Gateway API 的语义路由实战semantic router 结合 Istio Gateway 部署指南基于 ExtProc 与 Gateway API 的语义路由实战 本文以 seman后端API网关模型推理服务AI Agent上一篇SPT-AKI存档编辑器终极塔科夫离线版角色定制工具下一篇ComfyUI-Impact-Pack V8AI图像增强的终极解决方案让模糊图像瞬间变专业创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考