后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载导读本文围绕 semantic-router 的user_feedback信号系统讲解如何识别用户跟进消息中的纠错、满意、澄清与换方案意图并将其映射为决策规则decisions实现对不满意用户的自适应模型升级路由。读完本文你将掌握user_feedbacks信号的定义方法、user_feedback条件在决策规则中的组合写法、四类反馈的配置模板以及如何结合源码级原理反馈检测器、准入门、阈值机制在真实业务客服升级、教育自适应学习中落地该能力。1. 信号背景为什么需要用户反馈路由user_feedback是 semantic-router 基于信号驱动的决策架构Signal-Driven Decision中的一类重要信号。与关键词、嵌入、领域等单轮请求内信号不同用户反馈信号聚焦于多轮会话中的跟进消息follow-up messages——用户在收到助手回复之后往往会通过自然语言表达对回答质量的评价纠错CorrectionsThats wrong、No, thats not what I meant满意度表达SatisfactionThank you、Thats helpful、Perfect澄清请求ClarificationsCan you explain more?、I dont understand重试请求RetriesTry again、Give me another answer。user_feedback信号自动识别这些模式从而让路由层获得四个关键能力能力说明自适应路由Adaptive Routing检测到用户不满意时将请求路由到更强的模型纠错处理Correction Handling自动处理 thats wrong、try again 类消息换模型重新作答满意度分析Satisfaction Analysis区分正向与负向反馈为监控和运营提供数据体验改进Improved UX用户表达不满时给出更高质量的回答避免对话流失这种设计对应的典型应用路径是纠错类消息路由到更强大、更擅长推理的模型满意度信号用于服务质量的监控与统计跟进问题得到与其意图匹配的妥善处理基于反馈持续改进回答质量。关于信号驱动的完整架构信号类型、组合规则、决策引擎可参阅 Signal-Driven Decision Architecture。2. 源码视角user_feedback 信号是如何被识别出来的在深入配置之前先了解该信号在 semantic-router 中的实现位置这有助于理解后面配置项的真实语义。2.1 反馈检测器与四类标准标签用户反馈分类由独立的 ML 检测器完成核心实现在 feedback_detector.go。源码中定义了五个标准标签常量FeedbackLabelSatisfied satisfied FeedbackLabelNeedClarification need_clarification FeedbackLabelWrongAnswer wrong_answer FeedbackLabelWantDifferent want_different FeedbackLabelNoFeedback no_feedback其中no_feedback是 Vela 模型引入的显式负类用于打破每条跟进消息都必须是反馈的封闭集假设closed-set assumption——即普通跟进如补充信息不应被强行归类为反馈。源码注释明确写道不确定性不等于满意的证据uncertainty is not evidence of satisfaction。检测器还内置了标签归一化逻辑normalizeFeedbackLabelfeedback_detector.go可把模型原始输出如SAT、NEED_CLARIFICATION、WRONG_ANSWER、WANT_DIFFERENT统一映射为标准小写形式保证与config.yaml中定义的信号名一致。2.2 只有有前序助手回复才触发检测反馈检测并非每次请求都执行。在 feedback_signal_gate.go 中定义了准入逻辑func shouldEvaluateUserFeedbackSignal(hasPriorAssistantReply bool) bool { return hasPriorAssistantReply }也就是说只有当会话中存在前一条助手回复hasPriorAssistantReply 为 true时才会对该轮用户文本做反馈分类首轮提问不会触发反馈检测。这一行为由测试用例 feedback_signal_gate_test.go 验证在不适用非跟进输入下模型准入门调用次数必须为 0且不产生任何MatchedUserFeedbackRules匹配而在适用输入下则恰好调用 1 次。2.3 检测结果如何变成决策条件检测器输出FeedbackResult字段见 feedback_detector.goFeedbackType、Confidence、Abstained、Class等随后由evaluateUserFeedbackSignalclassifier_signal_rule_evaluators.go将FeedbackType与配置的user_feedbacks规则名比对命中的规则名被追加到results.MatchedUserFeedbackRules最终作为SignalMatches.UserFeedbackRules传入决策引擎见 classifier_signal_decision.go。因此配置中的信号名必须与检测器输出的标签完全一致如wrong_answer、need_clarification、satisfied、want_different否则即使检测到反馈也不会命中规则。2.4 反馈检测器的底层配置反馈检测器本身由feedback_detector配置块驱动其结构定义在 model_config_types.gofeedback_detector: enabled: true # 是否启用反馈检测 model_id: ... # 用于反馈分类的模型引用必填由 ML 模型提供分类能力 threshold: 0.5 # 置信度阈值低于阈值视为不确定/弃权 use_cpu: false # 是否使用 CPU 推理 max_sequence_length: ... # 单次推理的最大序列长度 feedback_mapping_path: ... # 可选标签映射文件路径id2label/label2idx值得注意的细节均有源码依据threshold默认为 0.5feedback_detector.go若模型输出中存在no_feedback负类低置信度预测会保留真实标签但标记Abstained弃权而不会被当作满意度若为旧式四分类模型无no_feedback类低置信度预测按applyThreshold逻辑回退为satisfied其置信度取满意类的概率feedback_detector.go空输入会被拒绝测试TestFeedbackRejectsEmptyInputWithoutInventingSatisfaction明确保证空输入不会凭空造出满意度。3. 基础配置定义 user_feedback 信号在config.yaml的routing.signals下通过user_feedbacks列表声明反馈信号。每个信号由name与description组成配置结构体UserFeedbackRule见 signal_config.gosignals: user_feedbacks: - name: wrong_answer description: User indicates previous answer was incorrect - name: satisfied description: User is satisfied with the answer - name: need_clarification description: User needs more clarification on the answer - name: want_different description: User wants some other different answer在仓库自带的主配置 config/config.yaml 中user_feedbacks与reasks重复提问不满信号、fact_check、domains等信号并列出现说明该信号是可与其他信号协同的多信号体系中的一员。3.1 在决策规则中使用 user_feedback信号本身只负责识别意图真正决定如何路由的是决策规则decisions。以下示例演示了答错后重路由到更强模型并改写系统提示词的完整写法decisions: - name: wrong_answer_route description: Handle user feedback indicating wrong answer - rethink and provide correct response priority: 150 rules: operator: AND conditions: - type: user_feedback name: wrong_answer modelRefs: - model: openai/gpt-oss-120b use_reasoning: true plugins: - type: system_prompt configuration: system_prompt: The user has indicated that the previous answer was incorrect. Please carefully reconsider the question, identify what might have been wrong in the previous response, and provide a corrected and accurate answer. Think step-by-step and verify your reasoning before responding. - name: retry_with_different_approach description: Route requests for different approach priority: 100 rules: operator: AND conditions: - type: user_feedback name: want_different modelRefs: - model: openai/gpt-oss-120b use_reasoning: true plugins: - type: system_prompt configuration: system_prompt: The user wants a different approach or perspective. Provide an alternative solution or explanation that differs from the previous response.要点拆解conditions中的type: user_feedback与name组合即该信号已匹配modelRefs指定命中的模型与是否开启推理use_reasoning: true适合纠错、换方案等需要重新推理的场景plugins中的system_prompt类型插件在路由命中时改写系统提示词引导模型以重新思考、纠正错误的姿态作答priority用于多个决策同时满足时的裁决数值越大优先级越高。4. 四类反馈类型的完整配置与示例4.1 Wrong Answer答错纠错典型模式Thats wrong、No、Incorrect、Try againsignals: user_feedbacks: - name: wrong_answer description: User indicates previous answer was incorrect decisions: - name: wrong_answer_route description: Handle user feedback indicating wrong answer priority: 150 rules: operator: AND conditions: - type: user_feedback name: wrong_answer modelRefs: - model: openai/gpt-oss-120b use_reasoning: true plugins: - type: system_prompt configuration: system_prompt: The user has indicated that the previous answer was incorrect. Please carefully reconsider the question and provide a corrected answer.示例查询Thats wrong, the answer is 42 → ✅ 检测到纠错No, thats not what I meant → ✅ 检测到纠错Try again with a different approach → ✅ 检测到纠错4.2 Satisfied满意典型模式Thank you、Perfect、Thats helpful、Greatsignals: user_feedbacks: - name: satisfied description: User is satisfied with the answer decisions: - name: track_satisfaction description: Track satisfied users priority: 50 rules: operator: AND conditions: - type: user_feedback name: satisfied modelRefs: - model: openai/gpt-oss-120b use_reasoning: false plugins: - type: system_prompt configuration: system_prompt: The user is satisfied. Continue providing helpful assistance.示例查询Thank you, thats exactly what I needed → ✅ 检测到满意Perfect, that helps a lot → ✅ 检测到满意Great explanation → ✅ 检测到满意4.3 Need Clarification需要澄清典型模式Can you explain more?、I dont understand、What do you mean?signals: user_feedbacks: - name: need_clarification description: User needs more clarification on the answer decisions: - name: provide_clarification description: Provide more detailed explanation priority: 100 rules: operator: AND conditions: - type: user_feedback name: need_clarification modelRefs: - model: openai/gpt-oss-120b use_reasoning: true plugins: - type: system_prompt configuration: system_prompt: The user needs more clarification. Provide a more detailed, step-by-step explanation with examples.示例查询Can you explain that in simpler terms? → ✅ 需要澄清I dont understand the last part → ✅ 需要澄清What do you mean by that? → ✅ 需要澄清4.4 Want Different Approach想要不同方案典型模式Give me another answer、Try a different way、Show me alternativessignals: user_feedbacks: - name: want_different description: User wants some other different answer decisions: - name: retry_with_different_approach description: Provide alternative solution priority: 100 rules: operator: AND conditions: - type: user_feedback name: want_different modelRefs: - model: openai/gpt-oss-120b use_reasoning: true plugins: - type: system_prompt configuration: system_prompt: The user wants a different approach or perspective. Provide an alternative solution or explanation that differs from the previous response.示例查询Give me another way to solve this → ✅ 需要替代方案Show me a different approach → ✅ 需要替代方案Can you try a different method? → ✅ 需要替代方案5. 进阶实践从单信号到多信号组合的生产级反馈路由原教程的基础配置演示了单信号直连决策。而在仓库的官方反馈配方 config/recipes/feedback/config.yaml及其等价的 DSL 版本 config/recipes/feedback/recipe.dsl中可以看到该能力在生产环境中的完整进阶形态——用户反馈不再孤立使用而是与关键词、reask重复提问、事实核查、领域、上下文长度等信号加权组合形成分级恢复通道recovery lanes。5.1 配套的关键词与 reask 信号配方中除了user_feedbackswrong_answer、need_clarification还声明了专门捕获隐式不满的frustration_feedback_markers关键词信号含中英文wrong、thats wrong、doesnt work、try again、不对、错了、这不行、再试一次等以及reasks信号reasks: - name: likely_dissatisfied description: Current user turn closely repeats the immediately previous user turn. threshold: 0.8 lookback_turns: 1 - name: persistently_dissatisfied description: Current user turn repeats the last two user turns in a row. threshold: 0.8 lookback_turns: 2reask信号在仓库中与user_feedback并列见 config/config.yaml它通过用户重复提问间接推断不满是显式反馈之外的强补充——因为很多用户并不会直接说出你答错了。5.2 投影Projection把反馈压力量化为分数配方通过projections把多维信号加权求和为feedback_recovery_pressure反馈恢复压力与verification_pressure证据核验压力两个分数projections: scores: - name: feedback_recovery_pressure method: weighted_sum inputs: - type: user_feedback name: wrong_answer weight: 0.36 - type: reask name: likely_dissatisfied weight: 0.24 value_source: confidence - type: reask name: persistently_dissatisfied weight: 0.46 value_source: confidence - type: keyword name: frustration_feedback_markers weight: 0.18 value_source: confidence # ... code_error_markers / needs_fact_check / domain / context 等随后通过threshold_bands映射把压力分数划分为三档恢复强度对应 recipe.dsl 的投影映射feedback_retry0.24 ≤ score 0.55一般重试feedback_escalate0.55 ≤ score 0.85升级恢复feedback_verified_escalatescore ≥ 0.85高置信/高价值升级。这些投影信号随后被决策规则引用条件type: projection, name: feedback_escalate等。从源码看投影输入正是从MatchedUserFeedbackRules等信号结果取值的见 classifier_projection_inputs.go。5.3 分级模型通道不同不满强度对应不同模型配方将模型按成本与能力分档通过modelCards声明能力标签模型档位定位qwen/qwen3.5-rocmcheap常规跟进与轻量澄清的默认通道google/gemini-3.1-prorepair重复不满、调试与答案修复的中成本通道openai/gpt5.4verified需证据核验或高价值不满恢复的专属通道对应决策链优先级从高到低feedback_verified_recoverypriority 240显式/持续不满 证据敏感场景 → 顶级模型 高推理强度feedback_persistent_code_recoverypriority 230持续重复提问 代码错误 → 顶级模型feedback_code_recoverypriority 220代码错误 不满信号 → 中档模型修复feedback_persistent_recoverypriority 210持续重复提问非证据/代码场景→ 顶级模型feedback_general_recoverypriority 200一般不满 → 中档模型feedback_need_clarificationpriority 180显式澄清请求 → 便宜模型 响应缓存similarity_threshold: 0.86,ttl_seconds: 1800feedback_defaultpriority 10无任何恢复信号 → 便宜模型兜底。每个恢复决策还通过header_mutation插件在出站请求头中打上X-Feedback-Lane如verified-recovery、code-recovery与X-Route-Source: feedback-recipe便于链路观测与后续审计。该配方完整展示了显式反馈 隐式关键词 重复提问 证据敏感度如何共同决定模型档位——这正是本教程所讲能力在生产环境中的标准进阶用法。6. 典型业务用例6.1 客服升级Customer Support - Escalation问题不满意的客户需要更高质量的回答否则极易流失。signals: user_feedbacks: - name: wrong_answer description: Customer indicates previous answer was incorrect decisions: - name: escalate_to_premium description: Escalate to premium model priority: 150 rules: operator: AND conditions: - type: user_feedback name: wrong_answer modelRefs: - model: openai/gpt-oss-120b use_reasoning: true plugins: - type: system_prompt configuration: system_prompt: The customer was not satisfied with the previous answer. Provide a better, more accurate response.仓库中还存在一个精简的片段示例 config/fragments/signal/user-feedback/escalation.yaml它以routing.signals.user_feedbacks片段形式提供了wrong_answer与need_clarification两个信号的即用定义可作为拼装完整配置的片段参考。6.2 教育自适应学习Education - Adaptive Learning问题学生困惑时需要不同的讲解方式僵化的单一回答会阻塞学习进度。signals: user_feedbacks: - name: need_clarification description: Student needs more clarification on the answer decisions: - name: detailed_explanation description: Provide detailed explanation priority: 100 rules: operator: AND conditions: - type: user_feedback name: need_clarification modelRefs: - model: openai/gpt-oss-120b use_reasoning: true plugins: - type: system_prompt configuration: system_prompt: The student needs more clarification. Provide a detailed, step-by-step explanation with examples.7. 最佳实践7.1 与上下文Context信号组合结合会话历史可以显著提升反馈检测效果。反馈检测本身依赖存在前序助手回复见第 2.2 节因此显式维护对话状态是推荐的组合方式# Track conversation state context: previous_response: true conversation_history: 3 # Last 3 messages7.2 为纠错设置较高的优先级纠错类决策应拥有高优先级确保其优先于普通回复决策被选中decisions: - name: handle_correction priority: 100 # High priority for corrections从决策引擎的调用链classifier_signal_decision.go可以看到决策按配置顺序经decision.NewDecisionEngine评估priority是多规则命中时的裁决依据生产配方中恢复通道普遍采用 150~260 的高优先级区间。7.3 监控满意度指标持续跟踪反馈模式把满意度信号纳入日志与指标体系logging: level: info user_feedback: true satisfaction_metrics: true在源码层面每次反馈检测都会记录执行耗时与置信度到results.Metrics.UserFeedbackExecutionTimeMs、Confidence、ConfidenceAvailable、PolicyDefault见 classifier_signal_rule_evaluators.go并可进一步通过 apiserver 的 route_classification_metrics.go 暴露为可观测指标。7.4 为不同反馈类型选择合适模型纠错Corrections路由到能力更强、成本更高的模型开启use_reasoning: true澄清Clarifications路由到擅长解释的模型若只是轻量澄清可如生产配方所示保留在便宜通道并叠加响应缓存满意Satisfaction维持当前模型无需升级。8. 完整决策链路小结一个携带用户反馈的请求在 semantic-router 中大致经历如下链路请求进入后系统判断是否为跟进消息是否存在前序助手回复决定是否评估user_feedback信号feedback_signal_gate.go若为跟进消息反馈检测器对当前用户文本做 ML 分类得到FeedbackType与置信度低于阈值的预测被标记为弃权或回退feedback_detector.go分类结果与配置中的user_feedbacks规则名比对命中的规则写入MatchedUserFeedbackRulesclassifier_signal_rule_evaluators.go决策引擎结合user_feedback条件及其他信号/投影按priority选出最终决策classifier_signal_decision.go命中决策后执行modelRefs模型切换、plugins如system_prompt改写、header_mutation打标、response_cache缓存等动作。该机制的正确性由多个测试用例保障包括 feedback_signal_gate_test.go、feedback_abstention_test.go弃权语义、builtin_recipe_policy_test.go负反馈后应走推理通道、反馈不能替代缺失的助手历史、引述式反馈不算恢复等它们共同界定了反馈信号的边界行为。9. 参考本文档原始位置website/versioned_docs/version-v0.1/tutorials/intelligent-route/user-feedback-routing.md完整信号驱动决策架构signal-driven-decisions.md生产级反馈配方YAML / DSLconfig/recipes/feedback/config.yaml、config/recipes/feedback/recipe.dsl信号片段示例config/fragments/signal/user-feedback/escalation.yaml反馈检测器实现feedback_detector.go决策引擎接线classifier_signal_decision.go信号配置结构signal_config.go赞分享后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载相关推荐Semantic Router 用户反馈信号路由基于满意度与更正的自适应模型路由实战指南Semantic Router 用户反馈信号路由基于满意度与更正的自适应模型路由实战指南 本指南完整讲解 Semantic Router 项目中 user_f后端API网关模型推理服务AI AgentSemantic Router 用户反馈信号user-feedback让路由决策听见用户的纠正与不满Semantic Router 用户反馈信号user feedback让路由决策听见用户的纠正与不满 user feedback 是 semantic后端API网关模型推理服务AI AgentSemantic Router 偏好信号路由Preference Signal Routing实战指南基于外部 LLM 的复杂意图匹配与决策路由Semantic Router 偏好信号路由Preference Signal Routing实战指南基于外部 LLM 的复杂意图匹配与决策路由 本指南深后端API网关模型推理服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/14 17:11:44 · 阅读 1.2k semantic-router 用户反馈信号路由实战：基于 user_feedback 信号的满意度感知与自适应路由配置指南
后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载导读本文围绕 semantic-router 的user_feedback信号系统讲解如何识别用户跟进消息中的纠错、满意、澄清与换方案意图并将其映射为决策规则decisions实现对不满意用户的自适应模型升级路由。读完本文你将掌握user_feedbacks信号的定义方法、user_feedback条件在决策规则中的组合写法、四类反馈的配置模板以及如何结合源码级原理反馈检测器、准入门、阈值机制在真实业务客服升级、教育自适应学习中落地该能力。1. 信号背景为什么需要用户反馈路由user_feedback是 semantic-router 基于信号驱动的决策架构Signal-Driven Decision中的一类重要信号。与关键词、嵌入、领域等单轮请求内信号不同用户反馈信号聚焦于多轮会话中的跟进消息follow-up messages——用户在收到助手回复之后往往会通过自然语言表达对回答质量的评价纠错CorrectionsThats wrong、No, thats not what I meant满意度表达SatisfactionThank you、Thats helpful、Perfect澄清请求ClarificationsCan you explain more?、I dont understand重试请求RetriesTry again、Give me another answer。user_feedback信号自动识别这些模式从而让路由层获得四个关键能力能力说明自适应路由Adaptive Routing检测到用户不满意时将请求路由到更强的模型纠错处理Correction Handling自动处理 thats wrong、try again 类消息换模型重新作答满意度分析Satisfaction Analysis区分正向与负向反馈为监控和运营提供数据体验改进Improved UX用户表达不满时给出更高质量的回答避免对话流失这种设计对应的典型应用路径是纠错类消息路由到更强大、更擅长推理的模型满意度信号用于服务质量的监控与统计跟进问题得到与其意图匹配的妥善处理基于反馈持续改进回答质量。关于信号驱动的完整架构信号类型、组合规则、决策引擎可参阅 Signal-Driven Decision Architecture。2. 源码视角user_feedback 信号是如何被识别出来的在深入配置之前先了解该信号在 semantic-router 中的实现位置这有助于理解后面配置项的真实语义。2.1 反馈检测器与四类标准标签用户反馈分类由独立的 ML 检测器完成核心实现在 feedback_detector.go。源码中定义了五个标准标签常量FeedbackLabelSatisfied satisfied FeedbackLabelNeedClarification need_clarification FeedbackLabelWrongAnswer wrong_answer FeedbackLabelWantDifferent want_different FeedbackLabelNoFeedback no_feedback其中no_feedback是 Vela 模型引入的显式负类用于打破每条跟进消息都必须是反馈的封闭集假设closed-set assumption——即普通跟进如补充信息不应被强行归类为反馈。源码注释明确写道不确定性不等于满意的证据uncertainty is not evidence of satisfaction。检测器还内置了标签归一化逻辑normalizeFeedbackLabelfeedback_detector.go可把模型原始输出如SAT、NEED_CLARIFICATION、WRONG_ANSWER、WANT_DIFFERENT统一映射为标准小写形式保证与config.yaml中定义的信号名一致。2.2 只有有前序助手回复才触发检测反馈检测并非每次请求都执行。在 feedback_signal_gate.go 中定义了准入逻辑func shouldEvaluateUserFeedbackSignal(hasPriorAssistantReply bool) bool { return hasPriorAssistantReply }也就是说只有当会话中存在前一条助手回复hasPriorAssistantReply 为 true时才会对该轮用户文本做反馈分类首轮提问不会触发反馈检测。这一行为由测试用例 feedback_signal_gate_test.go 验证在不适用非跟进输入下模型准入门调用次数必须为 0且不产生任何MatchedUserFeedbackRules匹配而在适用输入下则恰好调用 1 次。2.3 检测结果如何变成决策条件检测器输出FeedbackResult字段见 feedback_detector.goFeedbackType、Confidence、Abstained、Class等随后由evaluateUserFeedbackSignalclassifier_signal_rule_evaluators.go将FeedbackType与配置的user_feedbacks规则名比对命中的规则名被追加到results.MatchedUserFeedbackRules最终作为SignalMatches.UserFeedbackRules传入决策引擎见 classifier_signal_decision.go。因此配置中的信号名必须与检测器输出的标签完全一致如wrong_answer、need_clarification、satisfied、want_different否则即使检测到反馈也不会命中规则。2.4 反馈检测器的底层配置反馈检测器本身由feedback_detector配置块驱动其结构定义在 model_config_types.gofeedback_detector: enabled: true # 是否启用反馈检测 model_id: ... # 用于反馈分类的模型引用必填由 ML 模型提供分类能力 threshold: 0.5 # 置信度阈值低于阈值视为不确定/弃权 use_cpu: false # 是否使用 CPU 推理 max_sequence_length: ... # 单次推理的最大序列长度 feedback_mapping_path: ... # 可选标签映射文件路径id2label/label2idx值得注意的细节均有源码依据threshold默认为 0.5feedback_detector.go若模型输出中存在no_feedback负类低置信度预测会保留真实标签但标记Abstained弃权而不会被当作满意度若为旧式四分类模型无no_feedback类低置信度预测按applyThreshold逻辑回退为satisfied其置信度取满意类的概率feedback_detector.go空输入会被拒绝测试TestFeedbackRejectsEmptyInputWithoutInventingSatisfaction明确保证空输入不会凭空造出满意度。3. 基础配置定义 user_feedback 信号在config.yaml的routing.signals下通过user_feedbacks列表声明反馈信号。每个信号由name与description组成配置结构体UserFeedbackRule见 signal_config.gosignals: user_feedbacks: - name: wrong_answer description: User indicates previous answer was incorrect - name: satisfied description: User is satisfied with the answer - name: need_clarification description: User needs more clarification on the answer - name: want_different description: User wants some other different answer在仓库自带的主配置 config/config.yaml 中user_feedbacks与reasks重复提问不满信号、fact_check、domains等信号并列出现说明该信号是可与其他信号协同的多信号体系中的一员。3.1 在决策规则中使用 user_feedback信号本身只负责识别意图真正决定如何路由的是决策规则decisions。以下示例演示了答错后重路由到更强模型并改写系统提示词的完整写法decisions: - name: wrong_answer_route description: Handle user feedback indicating wrong answer - rethink and provide correct response priority: 150 rules: operator: AND conditions: - type: user_feedback name: wrong_answer modelRefs: - model: openai/gpt-oss-120b use_reasoning: true plugins: - type: system_prompt configuration: system_prompt: The user has indicated that the previous answer was incorrect. Please carefully reconsider the question, identify what might have been wrong in the previous response, and provide a corrected and accurate answer. Think step-by-step and verify your reasoning before responding. - name: retry_with_different_approach description: Route requests for different approach priority: 100 rules: operator: AND conditions: - type: user_feedback name: want_different modelRefs: - model: openai/gpt-oss-120b use_reasoning: true plugins: - type: system_prompt configuration: system_prompt: The user wants a different approach or perspective. Provide an alternative solution or explanation that differs from the previous response.要点拆解conditions中的type: user_feedback与name组合即该信号已匹配modelRefs指定命中的模型与是否开启推理use_reasoning: true适合纠错、换方案等需要重新推理的场景plugins中的system_prompt类型插件在路由命中时改写系统提示词引导模型以重新思考、纠正错误的姿态作答priority用于多个决策同时满足时的裁决数值越大优先级越高。4. 四类反馈类型的完整配置与示例4.1 Wrong Answer答错纠错典型模式Thats wrong、No、Incorrect、Try againsignals: user_feedbacks: - name: wrong_answer description: User indicates previous answer was incorrect decisions: - name: wrong_answer_route description: Handle user feedback indicating wrong answer priority: 150 rules: operator: AND conditions: - type: user_feedback name: wrong_answer modelRefs: - model: openai/gpt-oss-120b use_reasoning: true plugins: - type: system_prompt configuration: system_prompt: The user has indicated that the previous answer was incorrect. Please carefully reconsider the question and provide a corrected answer.示例查询Thats wrong, the answer is 42 → ✅ 检测到纠错No, thats not what I meant → ✅ 检测到纠错Try again with a different approach → ✅ 检测到纠错4.2 Satisfied满意典型模式Thank you、Perfect、Thats helpful、Greatsignals: user_feedbacks: - name: satisfied description: User is satisfied with the answer decisions: - name: track_satisfaction description: Track satisfied users priority: 50 rules: operator: AND conditions: - type: user_feedback name: satisfied modelRefs: - model: openai/gpt-oss-120b use_reasoning: false plugins: - type: system_prompt configuration: system_prompt: The user is satisfied. Continue providing helpful assistance.示例查询Thank you, thats exactly what I needed → ✅ 检测到满意Perfect, that helps a lot → ✅ 检测到满意Great explanation → ✅ 检测到满意4.3 Need Clarification需要澄清典型模式Can you explain more?、I dont understand、What do you mean?signals: user_feedbacks: - name: need_clarification description: User needs more clarification on the answer decisions: - name: provide_clarification description: Provide more detailed explanation priority: 100 rules: operator: AND conditions: - type: user_feedback name: need_clarification modelRefs: - model: openai/gpt-oss-120b use_reasoning: true plugins: - type: system_prompt configuration: system_prompt: The user needs more clarification. Provide a more detailed, step-by-step explanation with examples.示例查询Can you explain that in simpler terms? → ✅ 需要澄清I dont understand the last part → ✅ 需要澄清What do you mean by that? → ✅ 需要澄清4.4 Want Different Approach想要不同方案典型模式Give me another answer、Try a different way、Show me alternativessignals: user_feedbacks: - name: want_different description: User wants some other different answer decisions: - name: retry_with_different_approach description: Provide alternative solution priority: 100 rules: operator: AND conditions: - type: user_feedback name: want_different modelRefs: - model: openai/gpt-oss-120b use_reasoning: true plugins: - type: system_prompt configuration: system_prompt: The user wants a different approach or perspective. Provide an alternative solution or explanation that differs from the previous response.示例查询Give me another way to solve this → ✅ 需要替代方案Show me a different approach → ✅ 需要替代方案Can you try a different method? → ✅ 需要替代方案5. 进阶实践从单信号到多信号组合的生产级反馈路由原教程的基础配置演示了单信号直连决策。而在仓库的官方反馈配方 config/recipes/feedback/config.yaml及其等价的 DSL 版本 config/recipes/feedback/recipe.dsl中可以看到该能力在生产环境中的完整进阶形态——用户反馈不再孤立使用而是与关键词、reask重复提问、事实核查、领域、上下文长度等信号加权组合形成分级恢复通道recovery lanes。5.1 配套的关键词与 reask 信号配方中除了user_feedbackswrong_answer、need_clarification还声明了专门捕获隐式不满的frustration_feedback_markers关键词信号含中英文wrong、thats wrong、doesnt work、try again、不对、错了、这不行、再试一次等以及reasks信号reasks: - name: likely_dissatisfied description: Current user turn closely repeats the immediately previous user turn. threshold: 0.8 lookback_turns: 1 - name: persistently_dissatisfied description: Current user turn repeats the last two user turns in a row. threshold: 0.8 lookback_turns: 2reask信号在仓库中与user_feedback并列见 config/config.yaml它通过用户重复提问间接推断不满是显式反馈之外的强补充——因为很多用户并不会直接说出你答错了。5.2 投影Projection把反馈压力量化为分数配方通过projections把多维信号加权求和为feedback_recovery_pressure反馈恢复压力与verification_pressure证据核验压力两个分数projections: scores: - name: feedback_recovery_pressure method: weighted_sum inputs: - type: user_feedback name: wrong_answer weight: 0.36 - type: reask name: likely_dissatisfied weight: 0.24 value_source: confidence - type: reask name: persistently_dissatisfied weight: 0.46 value_source: confidence - type: keyword name: frustration_feedback_markers weight: 0.18 value_source: confidence # ... code_error_markers / needs_fact_check / domain / context 等随后通过threshold_bands映射把压力分数划分为三档恢复强度对应 recipe.dsl 的投影映射feedback_retry0.24 ≤ score 0.55一般重试feedback_escalate0.55 ≤ score 0.85升级恢复feedback_verified_escalatescore ≥ 0.85高置信/高价值升级。这些投影信号随后被决策规则引用条件type: projection, name: feedback_escalate等。从源码看投影输入正是从MatchedUserFeedbackRules等信号结果取值的见 classifier_projection_inputs.go。5.3 分级模型通道不同不满强度对应不同模型配方将模型按成本与能力分档通过modelCards声明能力标签模型档位定位qwen/qwen3.5-rocmcheap常规跟进与轻量澄清的默认通道google/gemini-3.1-prorepair重复不满、调试与答案修复的中成本通道openai/gpt5.4verified需证据核验或高价值不满恢复的专属通道对应决策链优先级从高到低feedback_verified_recoverypriority 240显式/持续不满 证据敏感场景 → 顶级模型 高推理强度feedback_persistent_code_recoverypriority 230持续重复提问 代码错误 → 顶级模型feedback_code_recoverypriority 220代码错误 不满信号 → 中档模型修复feedback_persistent_recoverypriority 210持续重复提问非证据/代码场景→ 顶级模型feedback_general_recoverypriority 200一般不满 → 中档模型feedback_need_clarificationpriority 180显式澄清请求 → 便宜模型 响应缓存similarity_threshold: 0.86,ttl_seconds: 1800feedback_defaultpriority 10无任何恢复信号 → 便宜模型兜底。每个恢复决策还通过header_mutation插件在出站请求头中打上X-Feedback-Lane如verified-recovery、code-recovery与X-Route-Source: feedback-recipe便于链路观测与后续审计。该配方完整展示了显式反馈 隐式关键词 重复提问 证据敏感度如何共同决定模型档位——这正是本教程所讲能力在生产环境中的标准进阶用法。6. 典型业务用例6.1 客服升级Customer Support - Escalation问题不满意的客户需要更高质量的回答否则极易流失。signals: user_feedbacks: - name: wrong_answer description: Customer indicates previous answer was incorrect decisions: - name: escalate_to_premium description: Escalate to premium model priority: 150 rules: operator: AND conditions: - type: user_feedback name: wrong_answer modelRefs: - model: openai/gpt-oss-120b use_reasoning: true plugins: - type: system_prompt configuration: system_prompt: The customer was not satisfied with the previous answer. Provide a better, more accurate response.仓库中还存在一个精简的片段示例 config/fragments/signal/user-feedback/escalation.yaml它以routing.signals.user_feedbacks片段形式提供了wrong_answer与need_clarification两个信号的即用定义可作为拼装完整配置的片段参考。6.2 教育自适应学习Education - Adaptive Learning问题学生困惑时需要不同的讲解方式僵化的单一回答会阻塞学习进度。signals: user_feedbacks: - name: need_clarification description: Student needs more clarification on the answer decisions: - name: detailed_explanation description: Provide detailed explanation priority: 100 rules: operator: AND conditions: - type: user_feedback name: need_clarification modelRefs: - model: openai/gpt-oss-120b use_reasoning: true plugins: - type: system_prompt configuration: system_prompt: The student needs more clarification. Provide a detailed, step-by-step explanation with examples.7. 最佳实践7.1 与上下文Context信号组合结合会话历史可以显著提升反馈检测效果。反馈检测本身依赖存在前序助手回复见第 2.2 节因此显式维护对话状态是推荐的组合方式# Track conversation state context: previous_response: true conversation_history: 3 # Last 3 messages7.2 为纠错设置较高的优先级纠错类决策应拥有高优先级确保其优先于普通回复决策被选中decisions: - name: handle_correction priority: 100 # High priority for corrections从决策引擎的调用链classifier_signal_decision.go可以看到决策按配置顺序经decision.NewDecisionEngine评估priority是多规则命中时的裁决依据生产配方中恢复通道普遍采用 150~260 的高优先级区间。7.3 监控满意度指标持续跟踪反馈模式把满意度信号纳入日志与指标体系logging: level: info user_feedback: true satisfaction_metrics: true在源码层面每次反馈检测都会记录执行耗时与置信度到results.Metrics.UserFeedbackExecutionTimeMs、Confidence、ConfidenceAvailable、PolicyDefault见 classifier_signal_rule_evaluators.go并可进一步通过 apiserver 的 route_classification_metrics.go 暴露为可观测指标。7.4 为不同反馈类型选择合适模型纠错Corrections路由到能力更强、成本更高的模型开启use_reasoning: true澄清Clarifications路由到擅长解释的模型若只是轻量澄清可如生产配方所示保留在便宜通道并叠加响应缓存满意Satisfaction维持当前模型无需升级。8. 完整决策链路小结一个携带用户反馈的请求在 semantic-router 中大致经历如下链路请求进入后系统判断是否为跟进消息是否存在前序助手回复决定是否评估user_feedback信号feedback_signal_gate.go若为跟进消息反馈检测器对当前用户文本做 ML 分类得到FeedbackType与置信度低于阈值的预测被标记为弃权或回退feedback_detector.go分类结果与配置中的user_feedbacks规则名比对命中的规则写入MatchedUserFeedbackRulesclassifier_signal_rule_evaluators.go决策引擎结合user_feedback条件及其他信号/投影按priority选出最终决策classifier_signal_decision.go命中决策后执行modelRefs模型切换、plugins如system_prompt改写、header_mutation打标、response_cache缓存等动作。该机制的正确性由多个测试用例保障包括 feedback_signal_gate_test.go、feedback_abstention_test.go弃权语义、builtin_recipe_policy_test.go负反馈后应走推理通道、反馈不能替代缺失的助手历史、引述式反馈不算恢复等它们共同界定了反馈信号的边界行为。9. 参考本文档原始位置website/versioned_docs/version-v0.1/tutorials/intelligent-route/user-feedback-routing.md完整信号驱动决策架构signal-driven-decisions.md生产级反馈配方YAML / DSLconfig/recipes/feedback/config.yaml、config/recipes/feedback/recipe.dsl信号片段示例config/fragments/signal/user-feedback/escalation.yaml反馈检测器实现feedback_detector.go决策引擎接线classifier_signal_decision.go信号配置结构signal_config.go赞分享后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载相关推荐Semantic Router 用户反馈信号路由基于满意度与更正的自适应模型路由实战指南Semantic Router 用户反馈信号路由基于满意度与更正的自适应模型路由实战指南 本指南完整讲解 Semantic Router 项目中 user_f后端API网关模型推理服务AI AgentSemantic Router 用户反馈信号user-feedback让路由决策听见用户的纠正与不满Semantic Router 用户反馈信号user feedback让路由决策听见用户的纠正与不满 user feedback 是 semantic后端API网关模型推理服务AI AgentSemantic Router 偏好信号路由Preference Signal Routing实战指南基于外部 LLM 的复杂意图匹配与决策路由Semantic Router 偏好信号路由Preference Signal Routing实战指南基于外部 LLM 的复杂意图匹配与决策路由 本指南深后端API网关模型推理服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考