semantic-router 事实核查信号路由(Fact Check Signal Routing)实战:将事实性请求智能路由到验证能力模型

发布时间:2026/10/13 2:19:24
semantic-router 事实核查信号路由(Fact Check Signal Routing)实战:将事实性请求智能路由到验证能力模型 后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载事实性查询如医疗、金融、历史类问题需要事实验证而创意、代码类查询则不需要。semantic-router 提供的fact_check信号基于机器学习自动识别该请求是否需要事实验证从而将事实性请求路由到具备幻觉检测能力的模型与插件链路。本文以 事实核查信号路由文档 为骨架结合仓库中的信号定义、分类器实现、决策引擎与端到端测试完整讲解该信号的定义方式、决策规则写法、底层 ML 分类原理与三大行业落地用例帮助你掌握一套可复制的按需验证路由方案。为什么需要按需验证不是所有查询都要事实核查在 LLM 网关场景中如果对所有请求一律施加事实验证会带来不必要的延迟与成本。fact_check信号解决的核心问题就是自动区分三类查询查询类型示例是否需要验证事实性查询法国的首都是哪里需要验证创意性查询写一个关于龙的故事不需要验证代码类查询写一个 Python 函数不需要验证从仓库的信号片段 needs-verification.yaml 可以看到fact_check信号由两个互斥的标签组成needs_fact_check查询包含应依据上下文进行验证的事实陈述与no_fact_check_needed创意、代码相关或基于观点的查询无需事实验证。该信号属于项目 Signal-Driven Decision 架构中的一种信号类型与 keyword、embedding、domain、user_feedback、preference 等信号并列可参考 信号驱动决策架构 了解整体体系。基于该信号你可以将事实性查询路由到具有幻觉检测能力的模型仅为事实性查询启用事实核查插件通过避免不必要的验证来优化成本与延迟。配置fact_check信号基础配置与决策规则基础配置在 config.yaml 中声明信号在配置文件的routing.signals段定义fact_check信号signals: fact_check: - name: needs_fact_check description: 查询包含应根据上下文进行验证的事实陈述 - name: no_fact_check_needed description: 查询是创意、代码相关或基于观点的 - 无需事实验证这与仓库中官方信号片段的格式完全一致见 needs-verification.yaml。在决策规则中使用将事实性请求路由到验证模型decisions: - name: factual_queries description: 路由带验证的事实性查询 priority: 150 rules: operator: AND conditions: - type: fact_check name: needs_fact_check modelRefs: - model: openai/gpt-oss-120b use_reasoning: true plugins: - type: system_prompt configuration: system_prompt: 你是一位事实信息专家。请提供准确、可验证的信息并在可能时提供来源。 - type: hallucination configuration: enabled: true threshold: 0.7配置要点解读rules.operator: AND决策条件全部满足才命中。fact_check信号命中needs_fact_check标签时该请求被判定为事实性请求modelRefs事实性请求应路由到具备强推理能力的模型use_reasoning: true表示启用推理模式plugins中的hallucination插件在决策命中后对该决策下模型生成的响应执行幻觉检测threshold是检测判定阈值。关于hallucination插件仓库官方片段 fact-check.yaml 给出了更完整的可配置项plugin: type: hallucination configuration: enabled: true hallucination_action: header unverified_factual_action: header include_hallucination_details: true其中hallucination_action与unverified_factual_action表示检测到幻觉或需要验证但缺少可依据上下文时采取的动作可选值包括header、body、block、none未配置时默认header在响应头中标记而不是阻断响应include_hallucination_details控制是否在标记中附带详细检测信息。这一行为在源码 req_filter_fact_check.go 的getHallucinationActionForDecision/getUnverifiedFactualActionForDecision中有明确的默认值逻辑。底层原理FactCheckClassifier 如何判定需要验证信号路由的背后是一个真实的 ML 分类器。从源码 fact_check_classifier.go 可以看到核心实现模型与输出分类器使用 halugate-sentinel ML 模型输出两个类别——0 NO_FACT_CHECK_NEEDED、1 FACT_CHECK_NEEDED映射为信号的两个标签阈值判定Classify时先取 argmax 类别与置信度只有当模型判定需要验证且置信度大于等于阈值时才最终输出needs_fact_check低于阈值则翻转判定为不需要验证fact_check_classifier.go。阈值默认值为 0.7未配置时自动取该默认值空文本处理输入为空时不调用模型直接返回needs_fact_checkfalse并标记PolicyDefault: empty_textfact_check_classifier.go避免对空请求发起无意义推理模型绑定分类器要求配置ModelID未配置时初始化直接报错fact_check_classifier.go并由项目的 model runtime 加载本地或远程模型配置结构FactCheckModelConfig包含model_id、threshold、use_cpu、max_sequence_length四个字段见 model_config_types.go。仓库内置 canonical 配置的默认工作点为阈值 0.93、use_cpu: true、模型引用fact_check_classifier见 canonical_defaults.go。对应的解析测试覆盖了完整/最小化/禁用三种配置形态验证threshold缺省为 0 且由运行时兜底、model_id必填等行为可参考 config_test.go 与分类器测试 fact_check_classifier_test.go后者直接断言了 What year did World War II end? 这类事实性问题应命中、创意性问题不应命中的行为。与幻觉检测联动只有需要验证且具备上下文时才检测值得特别注意的是fact_check信号决定是否需要对请求进行事实核查而幻觉检测是对模型响应执行的。从源码 req_filter_fact_check.go 的shouldPerformHallucinationDetection可以看出响应侧幻觉检测需要同时满足四个条件已配置可用的幻觉检测模型hallucination_detector命中决策的hallucination插件enabled: true请求被fact_check信号判定为needs_fact_check请求带有可用于支撑验证的上下文——例如 RAG 检索结果、tool 定义或历史轮次的 tool 结果HasToolsForFactCheck。这一设计非常关键没有上下文依据时即使判定为事实性请求也不会盲目执行幻觉检测此时会按unverified_factual_action处理从而避免在无依据场景下产生误报。在端到端测试 hallucination_detection.go 中正是通过事实性问题 tool 上下文的配对用例来触发检测并断言响应头x-vsr-response-warnings携带hallucination告警码。行业落地用例1. 医疗保健 - 医疗信息问题医疗查询必须事实准确以避免造成伤害。signals: fact_check: - name: needs_fact_check description: 查询包含应验证的事实陈述 domains: - name: health description: 医疗和健康查询 mmlu_categories: [health] decisions: - name: verified_medical description: 带事实验证的医疗查询 priority: 200 rules: operator: AND conditions: - type: domain name: health - type: fact_check name: needs_fact_check modelRefs: - model: openai/gpt-oss-120b use_reasoning: true plugins: - type: system_prompt configuration: system_prompt: 你是一位医疗信息专家。请提供准确的、基于证据的健康信息。 - type: hallucination configuration: enabled: true threshold: 0.8 # 医疗类设置高阈值示例查询糖尿病的症状有哪些 → ✅ 路由并验证写一个关于医生的故事 → ❌ 创意类不验证这里将fact_check信号与domain信号做 AND 组合只有同时命中health领域且判定为需要事实核查时才进入verified_medical决策。仓库中domain信号的health领域定义含mmlu_categories: [health]可参考 mmlu.yaml。2. 金融服务 - 投资信息问题财务建议必须准确以符合监管要求。signals: fact_check: - name: needs_fact_check description: 查询包含应验证的事实陈述 keywords: - name: financial_keywords operator: OR keywords: [股票, 投资, 投资组合, 股息] case_sensitive: false decisions: - name: verified_financial description: 带验证的金融查询 priority: 200 rules: operator: AND conditions: - type: keyword name: financial_keywords - type: fact_check name: needs_fact_check modelRefs: - model: openai/gpt-oss-120b use_reasoning: true plugins: - type: system_prompt configuration: system_prompt: 你是一位金融信息专家。请提供准确的金融信息并附带适当的免责声明。 - type: hallucination configuration: enabled: true threshold: 0.8示例查询苹果公司当前的市盈率是多少 → ✅ 事实性已验证解释投资策略 → ❌ 一般建议不验证关键词信号通过 OR 匹配快速捕获金融类意图case_sensitive: false表示大小写不敏感。仓库中 keyword 信号还支持bm25、ngram等匹配方法与对应阈值参数示例可参考 nlp.yaml。3. 教育 - 历史事实问题教育内容必须事实准确。signals: fact_check: - name: needs_fact_check description: 查询包含应验证的事实陈述 domains: - name: history description: 历史查询 mmlu_categories: [history] decisions: - name: verified_history description: 带验证的历史查询 priority: 150 rules: operator: AND conditions: - type: domain name: history - type: fact_check name: needs_fact_check modelRefs: - model: openai/gpt-oss-120b use_reasoning: true plugins: - type: system_prompt configuration: system_prompt: 你是一位历史专家。请提供准确的、带有恰当背景的历史信息。 - type: hallucination configuration: enabled: true threshold: 0.7示例查询第二次世界大战什么时候结束的 → ✅ 事实性已验证写一个历史小说故事 → ❌ 创意类不验证history领域同样在 mmlu.yaml 中有标准定义。可以看出三个用例的差异只在于组合的领域/关键词信号与 system prompt 内容fact_check信号的组合模式完全一致这正是该信号的通用性所在。性能特征原文档给出的参考性能特征如下维度值延迟20-50ms准确度80-90%误报率 (False Positives)5-10% (创意类被标记为事实性)漏报率 (False Negatives)5-10% (事实性被标记为创意类)说明以上数据来自版本 v0.1 教程文档的宣称值属于参考基准。实际数值取决于所用模型halugate-sentinel / fact_check_classifier、运行环境CPU/GPU、请求长度与部署形态应以你在当前环境下的实测为准。从源码看影响性能的关键因素包括分类器通过 model runtime 加载use_cpu控制是否 CPU 推理、max_sequence_length决定单次推理可处理的文本上限、阈值的高低直接影响误报与漏报的权衡——阈值越高越保守事实性请求越容易被判定为不需要验证漏报上升反之创意性请求越容易被误判为需要验证误报上升。最佳实践1. 结合领域信号同时使用fact_check和领域信号以提高准确性rules: operator: AND conditions: - type: domain name: science - type: fact_check name: needs_verification2. 设置合适的优先级事实性查询应具有更高的优先级确保在多个决策竞争时优先命中验证链路decisions: - name: verified_factual priority: 100 # 高优先级 rules: operator: AND conditions: - type: fact_check name: needs_verification3. 启用幻觉检测始终为事实性查询启用幻觉插件形成判定 → 验证 → 标记/阻断的完整闭环plugins: - type: hallucination configuration: enabled: true threshold: 0.74. 监控误报/漏报跟踪被误分类的查询持续调优阈值与组合信号logging: level: debug fact_check: true在运行时层面分类结果needs_fact_check、confidence会通过FactCheckResult结构暴露见 fact_check_classifier.go配合 debug 日志即可观测每次判定的置信度便于针对性地调整阈值。端到端验证与完整配置参考仓库提供了一套完整的幻觉检测端到端配置示例 config.hallucination.yaml其中fact_check信号与hallucination插件、domain信号同时配置并附带了真实的provider-mocker后端与决策定义可作为生产配置的最小可运行模板。对应的端到端测试用例 hallucination_detection.go 与 hallucination_detection_streaming.go 覆盖了普通与流式两种响应形态下的幻觉告警验证测试数据位于 hallucination_detection_cases.json此外 vela_halu.go 从分类信号角度验证事实核查与幻觉检测的信号链路。如果你想在自己的环境里快速复现可以直接套用该配置将provider-mocker替换为实际的 vLLM 后端。总结fact_check信号让是否需要对请求做事实核查成为路由决策的一等输入它由 ML 分类器halugate-sentinel / fact_check_classifier驱动输出needs_fact_check/no_fact_check_needed两个标签并可与domain、keyword等信号 AND/OR 组合以提升准确率配合hallucination插件实现事实性请求 → 验证模型 系统提示 响应幻觉检测的完整治理链路同时保证创意/代码类请求不被不必要的验证拖慢。合理设置阈值与优先级、监控误报漏报即可在准确性、合规性与成本之间取得平衡。如需深入理解信号组合、决策优先级与嵌套规则的整体架构可进一步阅读 信号驱动决策架构 及 配置指南。赞分享后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载相关推荐semantic-router 偏好信号路由Preference Signal Routing实战指南用 LLM 与 Embedding 实现细粒度请求路由semantic router 偏好信号路由Preference Signal Routing实战指南用 LLM 与 Embedding 实现细粒度请求路后端API网关模型推理服务AI AgentSemantic Router 的 Fact Check Signal面向证据敏感流量的学习型路由信号Semantic Router 的 Fact Check Signal面向证据敏感流量的学习型路由信号 导读 本文围绕 Semantic Router 的 f后端API网关模型推理服务AI AgentPaddleOCR Agent Skills 安装指南在 AI 应用中一句话触发文字识别与文档解析PaddleOCR Agent Skills 安装指南在 AI 应用中一句话触发文字识别与文档解析 这是面向支持 Skills 的 AI 应用如 Claud后端API网关模型推理服务AI Agent上一篇为什么选择ReGameDLL_CSCounter-Strike服务器增强的5大理由下一篇Emscripten组件化架构大型Web应用性能优化终极指南创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询