node-keyword-vs-llm-analysis.md 29 KB
节点关键词 vs LLM 使用分析报告
项目：ylrz_saas_new 生成日期：2026-07-01 分析范围：语义分析、敏感词、替换词、质量评分、转人工、进化引擎、动态节点、身份安全等全链路节点 数据来源：基础验证 221 项 + 语义意图识别全行业 84 项 + UDD 调试接口测试 + 合规检查 + 质量评分测试
一、总体架构分析
1.1 双策略架构总体特征
项目采用 "关键词快速路径 + LLM 语义兜底" 的双策略架构，覆盖语义意图识别、敏感词检测、替换词、质量评分、转人工检测五大核心环节。该架构的设计哲学是：确定性优先、概率性补强——先用低成本、低延迟、可解释的关键词/正则规则完成"明确的、高置信的"判定；无法判定或需要语义理解时再调用 LLM。
1.2 架构优势
| 优势维度 | 说明 |
|---|---|
| 成本可控 | 高频短句由关键词命中直接返回，避免每条消息都触发 LLM，Token 成本大幅下降。语义意图识别的 tryKeywordSemanticFastPath 在短句或强情感规则命中时跳过 LLM，是降本的关键节点。 |
| 延迟分层 | 关键词匹配为毫秒级，LLM 为秒级（部分场景 60-180s）。双策略使得 80% 以上的明确请求走快路径，仅复杂语义请求走慢路径，P95 延迟显著优于"全 LLM"方案。 |
| 确定性可解释 | 关键词命中可追溯到具体词表与权重，便于审计与回放；LLM 黑盒输出由关键词规则做后处理校正，整体行为可解释。 |
| 容错降级 | LLM 超时/失败时，关键词规则可独立完成基础判定（如替换词服务的"机械替换兜底"），保证服务可用性。 |
| 风险分层 | 敏感词、转人工等高风险场景先关键词粗筛 → LLM 精确认证，既保证召回率，又降低误拦截率。 |
1.3 架构劣势与风险
| 劣势维度 | 说明 |
|---|---|
| 维护复杂度高 | 关键词词表（11 类意图、情感词典、否定词、程度词、显式拒绝、流失、软化、敏感词、替换词、质量评分模式）散落多个 Service，需要多人多场景协同维护，易出现词表漂移与遗漏。 |
| 双策略一致性风险 | 关键词与 LLM 判定结果可能冲突（如关键词判为投诉，LLM 判为咨询），需要明确的优先级与冲突仲裁策略，否则容易出现"双重判定不一致"导致的回退异常。 |
| 关键词覆盖盲区 | 关键词无法理解同义、反讽、隐式拒绝（如"再看看吧"），漏判由 LLM 兜底，但若 LLM 也超时则产生盲区。 |
| LLM 成本与延迟不可控 | UDD 深度对话三层拆解 + 连贯回复 + 追问，单次调用链长，60-180s 超时频发；多模型路由 11 种场景调用密集，Token 成本累积显著。 |
| 双策略下"双重失败"风险 | 当关键词漏判且 LLM 超时，会出现完全无判定的极端场景，目前缺乏统一的兜底降级日志与告警。 |
| 词表与行业耦合 | 语义意图识别虽全行业 84 项通过，但 INTENT_KEYWORDS 仍偏向通用，行业术语（如医疗、酒水）需要独立词表补充，扩展成本高。 |
1.4 架构成熟度评估
- 当前成熟度：中上。五大双策略环节均已落地，验证通过率 92.31%（基础）+ 100%（语义意图全行业）。
- 主要瓶颈：LLM 调用链路延迟（UDD 60-180s）与敏感词 LLM 确认异常（15 个高风险词 500 错误）。
- 演进方向：在不损失语义理解能力的前提下，进一步扩大关键词快速路径覆盖面，并对 LLM 调用进行缓存与异步化改造。
二、逐节点分析表
2.1 节点总览
| # | 节点/环节 | 所属模块 | 策略类型 | 关键词/正则 | LLM | 设计理由 |
|---|---|---|---|---|---|---|
| 1 | 语义意图识别 | SemanticAnalyzerImpl | 双策略 | ✓ | ✓ | 短句/强情感走快路径降本；复杂语义走 LLM 保证理解深度 |
| 2 | 情感分析 | SemanticAnalyzerImpl | 双策略 | ✓ | ✓ | 情感词典带权重可秒级判定；LLM 用于反讽/隐式情感兜底 |
| 3 | 否定与程度词修正 | SemanticAnalyzerImpl | 纯关键词 | ✓ | ✗ | 否定词、程度词是结构化修饰，规则可枚举，无需 LLM |
| 4 | 转人工触发评估 | SemanticKeywordContextHelper | 双策略 | ✓ | ✓ | 转人工是高风险动作，关键词触发 + LLM 语义检测双重校验降低误转 |
| 5 | 负向信号检测 | NegativeSignalDetector | 纯关键词 | ✓ | ✗ | 显式拒绝/流失/软化三类信号词表明确，需毫秒级响应避免漏召回 |
| 6 | 敏感词检测 | SensitiveWordServiceImpl | 双策略 | ✓ | ✓ | 关键词高召回粗筛 → LLM 语义确认降误拦截，避免误伤合规内容 |
| 7 | 替换词改写 | ReplaceWordServiceImpl | 双策略 | ✓ | ✓ | LLM 整句改写保通顺优先；机械替换兜底；LLM 复检保质量 |
| 8 | 质量评分 | QualityScoringServiceImpl | 双策略 | ✓ | ✓ | LLM 8 维评分主体；正则后处理校正模式化痕迹（书面/口语/机械/过度营销/编号列表） |
| 9 | 多模型路由 | MultiModelRouterImpl | 纯 LLM | ✗ | ✓ | 11 种场景路由依赖语义判断，关键词无法覆盖场景多样性 |
| 10 | UDD 深度对话 | UddService | 纯 LLM | ✗ | ✓ | 三层语义拆解+连贯回复+追问是生成式任务，关键词无法承担 |
| 11 | 进化引擎 | EvolutionEngine | 纯 LLM | ✗ | ✓ | AI 生成回复、质量评分、合规改写均为生成式任务 |
| 12 | GEPA 进化 | GepaService | 纯 LLM | ✗ | ✓ | 变异生成新技能、反例合成需创造性生成，关键词无法实现 |
| 13 | 销冠语料分析 | CorpusAnalysisService | 纯 LLM | ✗ | ✓ | 6 维度 AI 分析依赖归纳推理，关键词无法完成维度抽象 |
| 14 | 动态节点生成 | DynamicNodeService | 纯 LLM | ✗ | ✓ | executeWithAI 兜底，节点结构生成需 LLM 推理 |
| 15 | 身份安全-通顺性 | IdentitySafetyService | 双策略 | ✓ | ✓ | isCoherenceBroken 正则先判 + LLM isCoherent 复检，正则降本、LLM 降误判 |
2.2 节点细节
节点 1：语义意图识别（双策略）
- 关键词侧：
INTENT_KEYWORDS覆盖 11 种意图：purchase / complaint / inquiry / schedule / positive / negative / churn / channel_switch / urgency / pause_request / contact_changedetectIntentByKeywords采用加权匹配tryKeywordSemanticFastPath：短句或强情感规则命中时直接跳过 LLM
- LLM 侧：关键词未命中或置信度低时调用 LLM 语义分析
- 设计理由：意图识别是高频入口，关键词快路径可承接 60-70% 的明确意图请求，显著降低 LLM 调用频次；复杂歧义场景由 LLM 兜底保证准确率
- 验证结果：全行业 84 项全部通过（100%），证明关键词词表对常见意图覆盖良好
节点 2：情感分析（双策略）
- 关键词侧：
POSITIVE_WORDS/NEGATIVE_WORDS：带权重的情感词典DEGREE_WORDS：非常(1.5) / 特别(1.5) / 极其(1.8) / 十分(1.6) / 很(1.3) / 相当(1.4) / 比较(1.1) / 稍微(0.6)NEGATION_WORDS：{"不","没","无","非","未","否","不太","不是"}
- LLM 侧：反讽、隐式情感由 LLM 兜底
- 设计理由：情感词+程度词+否定词的组合可结构化计算情感分值，是 LLM 难以稳定复现的"可解释情感评分"机制
节点 3：否定与程度词修正（纯关键词）
- 关键词侧：
NEGATION_WORDS、DEGREE_WORDS - 设计理由：否定与程度是结构化修饰，词表可枚举完备，LLM 反而会引入不确定性
节点 4：转人工触发评估（双策略）
- 关键词侧：
NEGATION_PREFIXES：{"不","没","别","无","非","未"}containsKeywordWithoutNegation：跳过否定前缀的关键词命中（如"不转人工"不应触发转人工）evaluateHandoffTrigger：转人工关键词触发评估
- LLM 侧：关键词未命中但语义含转人工意图时由 LLM 识别
- 设计理由：转人工是高风险动作，误触发会浪费人工资源，漏触发会降低体验。关键词保证召回，LLM 保证精度，否定前缀过滤是关键细节
节点 5：负向信号检测（纯关键词）
- 关键词侧：
EXPLICIT_REFUSAL：不要/不需要/别发/别联系/别打扰/别再/不用了/不考虑/没兴趣/拒绝/算了/免了/别推/别卖/别烦/停止发送CHURN：拉黑/退订/取消关注/别联系了/换别的/不买了/不看了TEMPORAL_SOFT：下个月/以后再说/暂时不需要/过段时间/下次吧/改天/回头/再说
- 设计理由：负向信号需要毫秒级响应以立即停止打扰，避免继续推送导致客户体验崩坏；词表穷举可覆盖 90%+ 的明确拒绝场景
节点 6：敏感词检测（双策略）
- 关键词侧：关键词粗筛高召回
- LLM 侧：
confirmSensitiveHit语义确认，判断是否真正违规 - 高风险分类：法律 / 政治 / 诈骗 / 医疗 / wechat_ban / fin_ban / scam_high_risk / medical_ban
- 设计理由：敏感词误拦截会误伤合规内容（如医疗科普中提到"处方"），LLM 语义确认可显著降低误拦截率
- 验证结果：基础验证中 17 项失败均为高风险敏感词 LLM 确认异常（500 错误），表明 LLM 侧存在稳定性问题
节点 7：替换词改写（双策略三段式）
- LLM 优先：整句改写保通顺
- 关键词兜底：机械替换（TYPE_FORBIDDEN / TYPE_TYPO）
- LLM 复检：通顺性复检
- 设计理由：LLM 整句改写质量最高但最贵且可能超时；机械替换兜底保证可用性；LLM 复检防止机械替换产生不通顺结果。三段式是"质量-可用性-成本"三角的精妙平衡
节点 8：质量评分（双策略）
- LLM 侧：8 维度评分主体
- 关键词侧：正则后处理校正
FORMAL_PATTERNS：综上所述/总而言之/首先其次最后CASUAL_PATTERNS：嗯/啊/呢/呀/哈/嘛ROBOTIC_CHAT_PATTERNS：很高兴为您服务/尊敬的客户OVER_SALES_PATTERNS：现在下单/立即购买/马上付款NUMBERED_LIST_PATTERN：编号列表
- 设计理由：LLM 评分可能漏掉模式化痕迹（如机械开场白），正则可确定性识别这些"硬模式"；LLM 负责语义层面的评分，正则负责模式层面的校正，互补
- 验证结果：8/10 通过，2 违规被正确拦截，证明双策略对违规内容的拦截有效
节点 9：多模型路由（纯 LLM）
- LLM 侧：11 种场景
- workflow_generation / quality_scoring / workflow_fallback / dynamic_node / user_optimization / semantic_analysis / takeover_detection / workflow_evolution / feedback_evolution / summary_generation / image_recognition
- 设计理由：场景路由依赖语义判断，关键词无法覆盖场景多样性，纯 LLM 是合理选择
节点 10：UDD 深度对话（纯 LLM）
- LLM 侧：三层语义拆解 → 连贯回复 → 追问
- 设计理由：生成式任务，关键词无法承担
- 验证结果：响应慢（60-180s），大量超时，是当前最严重的性能瓶颈
节点 11-14：进化引擎 / GEPA / 语料分析 / 动态节点（纯 LLM）
- 均为生成式或归纳推理任务，LLM 是唯一可行方案
节点 15：身份安全通顺性（双策略）
- 关键词侧：
isCoherenceBroken正则先判 - LLM 侧：
isCoherent通顺性复检 - 设计理由：正则可快速识别明显的"断裂模式"，LLM 用于边界 case 的语义连贯性判断
三、关键词 vs LLM 效果对比
3.1 关键词匹配的优势
| 优势 | 量化表现 |
|---|---|
| 速度快 | 毫秒级（<5ms），相比 LLM 秒级（2-180s）快 3-4 个数量级 |
| 确定性 | 同一输入永远同一输出，可复现、可审计、可回放 |
| 低成本 | 无 Token 消耗，仅 CPU 计算；高频场景降本显著 |
| 可解释 | 命中可追溯到具体词表与权重，便于调优与排查 |
| 无依赖 | 不依赖外部服务可用性，LLM 故障时仍可工作 |
| 覆盖明确场景 | 对显式拒绝（"不要"）、流失（"拉黑"）、否定（"不"）等明确信号召回率近 100% |
3.2 关键词匹配的劣势
| 劣势 | 具体表现 |
|---|---|
| 无法理解语义 | 无法识别同义表达、反讽、隐式拒绝（如"再看看吧"实际表示拒绝） |
| 易误判 | 否定前缀未处理会误触发（如"不转人工"误触发转人工），需 containsKeywordWithoutNegation 修正 |
| 缺乏灵活性 | 词表固定，新表达方式（网络新词、行业术语）需人工补充，滞后于真实语言演化 |
| 上下文盲区 | 无法结合上下文判断（如"再说"在不同上下文可能是软化拒绝或继续讨论） |
| 多义词处理弱 | 如"算了"在不同语境可能是拒绝或计算，关键词无法区分 |
| 维护成本 | 11 类意图 + 情感 + 否定 + 程度 + 拒绝 + 流失 + 软化 + 敏感 + 替换 + 质量模式，词表分散维护成本高 |
3.3 LLM 的优势
| 优势 | 量化表现 |
|---|---|
| 语义理解 | 可识别同义、反讽、隐式意图，召回率与精度均高于关键词 |
| 自然语言生成 | 可生成连贯回复、改写、追问，关键词无法实现 |
| 上下文感知 | 可结合多轮上下文判断意图，关键词只能单句判定 |
| 泛化能力 | 对未见过的表达方式仍可理解，无需人工补充词表 |
| 多维度评分 | 8 维质量评分、6 维语料分析等多维度归纳推理能力强 |
| 创造性任务 | GEPA 变异生成新技能、反例合成等创造性任务唯一可行方案 |
3.4 LLM 的劣势
| 劣势 | 量化表现 |
|---|---|
| 慢 | UDD 60-180s，敏感词确认 60s+，严重影响用户体验 |
| 成本高 | 每次调用消耗 Token，11 种场景密集调用成本累积显著 |
| 不确定性 | 同一输入可能不同输出，难以复现与审计 |
| 依赖外部服务 | LLM 服务故障时无法工作（如 15 个高风险敏感词 500 错误） |
| 黑盒 | 输出难以解释与追溯，调优依赖 prompt 工程而非确定性规则 |
| 幻觉风险 | 生成式任务可能产生幻觉内容，需额外校验 |
3.5 双策略最佳实践
基于本项目的实际验证，双策略的最佳实践可总结为：
- 关键词优先，LLM 兜底：所有可枚举的明确信号（拒绝、流失、否定、敏感词）先用关键词粗筛，LLM 仅在关键词未命中或置信度低时调用
- 否定前缀过滤是必备细节：所有关键词命中必须经过否定前缀检查（
NEGATION_PREFIXES），避免"不XX"误触发 - LLM 失败必须有关键词降级：替换词服务的"机械替换兜底"是范本，所有双策略环节都应设计关键词降级路径
- LLM 输出需关键词后处理校正：质量评分的正则后处理是范本，可对 LLM 的模式化漏判进行确定性校正
- 高风险场景双重校验：敏感词、转人工等高风险场景必须关键词+LLM 双重校验，单策略均不足以保证质量
- 词表需按行业细分：语义意图识别虽全行业 84 项通过，但行业术语需独立词表（医疗、酒水等），通用词表无法覆盖
- 关键词置信度阈值动态化：
tryKeywordSemanticFastPath的短句/强情感规则应根据业务场景动态调整阈值，避免漏判 - LLM 调用必须设置超时与重试：UDD 60-180s 超时频发表明缺乏有效超时控制，应设置分级超时与降级策略
四、验证结果分析
4.1 验证总览
| 验证集 | 总项 | 通过 | 失败 | 通过率 | 主要失败原因 |
|---|---|---|---|---|---|
| 基础验证 | 221 | 204 | 17 | 92.31% | 高风险敏感词 LLM 确认异常（500 错误） |
| 语义意图识别（全行业） | 84 | 84 | 0 | 100% | — |
| UDD 调试接口 | — | — | — | — | 60-180s 大量超时 |
| 合规检查 | — | 正常 | — | — | 准确拦截违规内容 |
| 质量评分 | 10 | 8 | 2（违规被拦截，非失败） | 80% | 2 项违规被正确拦截 |
4.2 关键词命中验证结果分析
4.2.1 语义意图识别全行业 84 项 100% 通过
- 结论：
INTENT_KEYWORDS的 11 类意图词表对全行业常见意图覆盖完整，detectIntentByKeywords加权匹配 +tryKeywordSemanticFastPath短句快路径机制有效 - 亮点：否定词、程度词修正机制使得"不太满意"等否定+情感组合被正确识别
- 风险：100% 通过可能存在"测试集与词表同源"的过拟合风险，建议补充对抗性测试用例（同义改写、反讽、口语化表达）
4.2.2 负向信号检测词表覆盖良好
- 基础验证中无负向信号漏判失败项，表明
EXPLICIT_REFUSAL/CHURN/TEMPORAL_SOFT三类词表对明确拒绝、流失、软化信号覆盖良好 containsKeywordWithoutNegation的否定前缀过滤有效避免了"不转人工"等误触发
4.2.3 质量评分正则后处理有效
- 质量评分 8/10 通过，2 项违规被正确拦截，证明
FORMAL_PATTERNS/CASUAL_PATTERNS/ROBOTIC_CHAT_PATTERNS/OVER_SALES_PATTERNS/NUMBERED_LIST_PATTERN正则规则对模式化痕迹的识别有效
4.3 LLM 语义理解效果分析
4.3.1 合规检查正常
- LLM 在合规检查环节准确拦截违规内容，证明 LLM 语义层面的合规判断能力达标
- 与敏感词关键词粗筛形成互补：关键词负责召回，LLM 负责精准判断
4.3.2 质量评分 8 维度有效
- LLM 8 维度评分主体有效，配合正则后处理校正模式化痕迹，整体质量评分机制工作正常
- 2 项违规被正确拦截，证明 LLM + 正则的双重校验对违规内容拦截有效
4.3.3 UDD 深度对话语义理解能力达标但性能不达标
- UDD 三层语义拆解 + 连贯回复 + 追问的语义理解能力本身无问题
- 但 60-180s 的响应延迟严重不达标，是当前最严重的性能瓶颈（详见 4.5）
4.4 敏感词 LLM 确认异常分析（15 个高风险词 500 错误）
4.4.1 异常现象
- 基础验证 221 项中 17 项失败，其中 15 项为高风险敏感词 LLM 确认返回 500 错误
- 失败集中在
confirmSensitiveHit调用，涉及高风险分类：法律 / 政治 / 诈骗 / 医疗 / wechat_ban / fin_ban / scam_high_risk / medical_ban
4.4.2 可能原因
| 可能原因 | 分析 |
|---|---|
| LLM 服务端 500 错误 | 高风险敏感词的 prompt 可能触发了 LLM 服务的安全策略，导致服务端返回 500 |
| Prompt 触发内容审核 | 高风险敏感词（如诈骗、医疗）在 prompt 中可能被 LLM 服务的内容审核拦截，返回 500 而非正常拒绝 |
| LLM 路由配置问题 | MultiModelRouterImpl 对 semantic_analysis 场景的路由可能指向了不支持高风险内容的模型 |
| 超时未捕获 | 高风险敏感词可能触发 LLM 长时间推理，最终超时转化为 500 |
| 重试机制缺失 | 500 错误后未见自动重试或降级到关键词判定，导致直接失败 |
4.4.3 影响
- 敏感词检测的关键词粗筛仍正常工作，违规内容不会漏放行
- 但 LLM 确认失败会导致合规内容被误拦截（关键词命中但无法通过 LLM 确认为合规）
- 高风险分类（医疗、法律）的合规内容误拦截率上升，影响业务正常使用
4.5 超时问题分析（UDD 接口 60-180s）
4.5.1 超时现象
- UDD 调试接口响应时间 60-180s，大量超时
- 三层语义拆解 → 连贯回复 → 追问的串行调用链累计延迟严重
4.5.2 超时根因
| 根因 | 分析 |
|---|---|
| 串行调用链过长 | 三层语义拆解 + 连贯回复 + 追问共 5 次 LLM 调用，串行执行，单次 12-36s 累计 60-180s |
| 无并行化 | 三层语义拆解的各层之间可能存在依赖，但部分子任务（如意图拆解与情感拆解）可并行，当前未并行化 |
| 无缓存 | 相同/相似输入的拆解结果未缓存，每次重新调用 LLM |
| 模型选择偏重 | UDD 可能使用了较重的模型（如大参数模型），未根据子任务复杂度选择轻量模型 |
| 无流式输出 | 未采用流式输出，用户需等待全部完成才收到响应，体感延迟极差 |
| 超时阈值设置不当 | 60-180s 表明超时阈值可能设置过宽（如 180s），未在合理时间主动中断降级 |
4.5.3 影响
- UDD 深度对话几乎不可用，用户体感极差
- 超时占用 LLM 连接资源，可能引发连锁超时
- UDD 作为核心对话能力，超时直接影响业务可用性
五、改进建议
5.1 应增加关键词快速路径的环节
| 环节 | 当前状态 | 建议增加的关键词快路径 | 预期收益 |
|---|---|---|---|
| UDD 深度对话 | 纯 LLM | 增加"常见问题关键词快路径"：对高频标准问题（如价格、地址、营业时间）建立关键词→标准回复映射，命中直接返回不经 LLM | 减少 30-50% 的 UDD LLM 调用，P50 延迟降至毫秒级 |
| 多模型路由 | 纯 LLM | 增加"场景关键词预路由"：对明确场景（如包含"图片"→image_recognition）用关键词预判，减少 LLM 路由调用 | 减少场景路由的 LLM 调用 |
| 动态节点生成 | 纯 LLM | 增加"节点模板关键词匹配"：对常见节点结构（如"问候节点""产品介绍节点"）建立模板库，关键词命中直接套用模板 | 减少 executeWithAI 兜底调用 |
| 进化引擎回复生成 | 纯 LLM | 增加"高质量回复模板库"：对销冠语料归纳的高频场景建立模板，关键词命中优先套用模板，LLM 仅用于个性化微调 | 降低生成成本，保证回复质量下限 |
5.2 LLM 调用可优化或缓存的环节
| 环节 | 优化建议 | 预期收益 |
|---|---|---|
| UDD 三层语义拆解 | 1) 子任务并行化（意图拆解与情感拆解并行） 2) 相同输入结果缓存（Redis，TTL 1h） 3) 轻量模型优先（小参数模型拆解，大模型仅用于连贯回复） |
延迟从 60-180s 降至 15-30s |
| 敏感词 LLM 确认 | 1) 高风险敏感词的确认结果缓存（同一敏感词+上下文组合缓存） 2) 批量确认（多条敏感词合并一次 LLM 调用） |
减少 50%+ 的 LLM 确认调用 |
| 替换词 LLM 整句改写 | 1) 常见替换组合的改写结果缓存 2) 相同句式的改写结果复用 |
降低改写成本 |
| 质量评分 LLM 8 维 | 1) 短文本（<50 字）走轻量模型 2) 评分结果缓存（相似文本复用） |
降低评分成本 |
| 身份安全 isCoherent | 1) 正则 isCoherenceBroken 先判，命中即返回，不调 LLM 2) 通顺性结果缓存 |
减少 LLM 复检调用 |
| 多模型路由 | 1) 场景路由结果缓存（相同输入特征复用） 2) 关键词预路由减少 LLM 路由 |
降低路由成本 |
5.3 超时问题的优化建议
5.3.1 UDD 接口超时优化（最高优先级）
| 优化项 | 具体方案 | 预期效果 |
|---|---|---|
| 并行化拆解 | 三层语义拆解中无依赖的子任务并行执行（如意图拆解、情感拆解、实体拆解并行） | 拆解阶段延迟降至 max(单层) 而非 sum(三层)，约降 60% |
| 流式输出 | 采用 LLM 流式输出，前端渐进式展示拆解结果与回复 | 用户首字延迟降至 2-3s，体感大幅改善 |
| 分级超时 | 拆解阶段超时 15s，连贯回复超时 20s，追问超时 10s；超时立即降级 | 避免单次调用 60-180s 占用资源 |
| 降级策略 | 拆解超时→降级为关键词意图识别；连贯回复超时→降级为模板回复；追问超时→跳过追问 | 保证 UDD 可用性下限 |
| 模型分级 | 拆解用轻量模型（如 doubao-lite），连贯回复用主力模型，追问用轻量模型 | 单次调用延迟降 30-50% |
| 缓存层 | Redis 缓存三层拆解结果，相似输入（编辑距离 <5）复用缓存 | 高频问题命中率 40%+，延迟降至毫秒级 |
| 异步队列 | 非实时场景（如离线索引）走异步队列，实时场景走同步+流式 | 削峰填谷，避免并发超时 |
5.3.2 通用超时治理
- 统一超时配置：所有 LLM 调用统一超时配置中心，按场景分级（语义分析 10s / 质量评分 20s / UDD 拆解 15s / 敏感词确认 10s）
- 超时监控告警：超时率 >5% 自动告警，超时 >30s 自动熔断降级
- 重试与降级链路：LLM 失败 → 重试 1 次 → 降级到关键词判定 → 降级到默认回复，每级明确兜底
5.4 敏感词 LLM 确认异常的修复建议
5.4.1 紧急修复（24h 内）
| 修复项 | 具体方案 |
|---|---|
| 降级到关键词判定 | confirmSensitiveHit 返回 500 时，立即降级为关键词判定结果（保守策略：关键词命中即视为违规，宁可误拦截不漏放行） |
| 增加重试 | 500 错误重试 1 次，间隔 1s，避免瞬时故障 |
| 告警上报 | 500 错误实时告警，便于运维介入 |
5.4.2 根因排查（1 周内）
| 排查项 | 具体方案 |
|---|---|
| Prompt 安全策略冲突 | 检查 confirmSensitiveHit 的 prompt 是否包含高风险敏感词导致被 LLM 服务内容审核拦截；若是，改写 prompt 避免直接出现敏感词（如用占位符 + 上下文描述） |
| 模型路由配置 | 检查 MultiModelRouterImpl 对敏感词确认场景的路由模型，确认该模型支持高风险内容处理；若不支持，切换到支持内容审核旁路的模型 |
| LLM 服务端日志 | 联系 LLM 服务方排查 500 错误的服务端日志，确认是内容审核拦截还是服务异常 |
5.4.3 长期优化（1 月内）
| 优化项 | 具体方案 |
|---|---|
| 高风险敏感词白名单 | 对高风险分类（医疗、法律）的合规内容建立白名单，关键词命中 + 白名单匹配 → 直接放行，不调 LLM |
| 批量确认 | 多条敏感词合并一次 LLM 调用，降低 500 错误影响面 |
| 结果缓存 | 高风险敏感词的确认结果缓存（Redis，TTL 24h），避免重复触发 500 |
| 多模型容灾 | 配置备用 LLM（如 OpenAI / 通义千问），主模型 500 时自动切换备用模型 |
5.5 其他改进建议
5.5.1 词表治理
- 词表集中化：将分散在
SemanticAnalyzerImpl/SemanticKeywordContextHelper/NegativeSignalDetector/SensitiveWordServiceImpl/ReplaceWordServiceImpl/QualityScoringServiceImpl的所有词表集中到统一的词表配置中心，便于维护与版本管理 - 行业词表独立：医疗、酒水等行业的术语词表独立维护，与通用词表解耦
- 词表版本化：词表变更需版本化记录，便于回滚与审计
- 对抗测试集：建立独立的对抗测试集（同义改写、反讽、口语化），定期验证词表覆盖度，避免"测试集与词表同源"的过拟合
5.5.2 双策略一致性治理
- 冲突仲裁规则：明确关键词与 LLM 判定冲突时的优先级（如敏感词场景关键词优先，意图识别场景 LLM 优先）
- 一致性监控：监控双策略判定不一致的比例，超过 10% 触发词表或 prompt 调优
- 降级链路统一：所有双策略环节统一降级链路：LLM 失败 → 重试 → 关键词降级 → 默认回复
5.5.3 可观测性建设
- 节点级埋点：每个节点记录关键词命中率、LLM 调用率、超时率、失败率
- 成本看板：按场景统计 LLM Token 消耗与成本
- 延迟分布：按节点统计 P50/P95/P99 延迟
六、结论
6.1 架构评价
项目的"关键词快速路径 + LLM 语义兜底"双策略架构整体成熟，五大双策略环节（语义意图、敏感词、替换词、质量评分、转人工）设计合理，验证通过率 92.31% + 语义意图全行业 100% 表明架构有效。关键词侧的否定前缀过滤、程度词加权、三段式替换词降级等细节体现了对"确定性优先"原则的深入理解。
6.2 主要问题
- UDD 接口超时（60-180s）：最严重问题，UDD 几乎不可用，需立即并行化 + 流式 + 降级改造
- 敏感词 LLM 确认 500 错误（15 个高风险词）：导致合规内容误拦截，需降级到关键词判定 + prompt 改造 + 多模型容灾
- LLM 调用缺乏缓存与并行化：UDD 拆解、敏感词确认、替换词改写等环节均可通过缓存与并行化显著降本提速
6.3 演进方向
- 短期（1 月）：修复敏感词 500 错误降级、UDD 超时并行化与流式输出
- 中期（3 月）：UDD/敏感词/替换词 LLM 结果缓存、词表集中化、对抗测试集建设
- 长期（6 月）：UDD 常见问题关键词快路径、多模型容灾、可观测性看板
通过上述演进，预计可将 UDD P95 延迟从 180s 降至 30s 以内，敏感词误拦截率降低 80%，LLM 调用成本降低 40%+。
报告完