# 节点关键词 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_change
  - `detectIntentByKeywords` 采用加权匹配
  - `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 双策略最佳实践

基于本项目的实际验证，双策略的最佳实践可总结为：

1. **关键词优先，LLM 兜底**：所有可枚举的明确信号（拒绝、流失、否定、敏感词）先用关键词粗筛，LLM 仅在关键词未命中或置信度低时调用
2. **否定前缀过滤是必备细节**：所有关键词命中必须经过否定前缀检查（`NEGATION_PREFIXES`），避免"不XX"误触发
3. **LLM 失败必须有关键词降级**：替换词服务的"机械替换兜底"是范本，所有双策略环节都应设计关键词降级路径
4. **LLM 输出需关键词后处理校正**：质量评分的正则后处理是范本，可对 LLM 的模式化漏判进行确定性校正
5. **高风险场景双重校验**：敏感词、转人工等高风险场景必须关键词+LLM 双重校验，单策略均不足以保证质量
6. **词表需按行业细分**：语义意图识别虽全行业 84 项通过，但行业术语需独立词表（医疗、酒水等），通用词表无法覆盖
7. **关键词置信度阈值动态化**：`tryKeywordSemanticFastPath` 的短句/强情感规则应根据业务场景动态调整阈值，避免漏判
8. **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) 子任务并行化（意图拆解与情感拆解并行）<br>2) 相同输入结果缓存（Redis，TTL 1h）<br>3) 轻量模型优先（小参数模型拆解，大模型仅用于连贯回复） | 延迟从 60-180s 降至 15-30s |
| **敏感词 LLM 确认** | 1) 高风险敏感词的确认结果缓存（同一敏感词+上下文组合缓存）<br>2) 批量确认（多条敏感词合并一次 LLM 调用） | 减少 50%+ 的 LLM 确认调用 |
| **替换词 LLM 整句改写** | 1) 常见替换组合的改写结果缓存<br>2) 相同句式的改写结果复用 | 降低改写成本 |
| **质量评分 LLM 8 维** | 1) 短文本（<50 字）走轻量模型<br>2) 评分结果缓存（相似文本复用） | 降低评分成本 |
| **身份安全 isCoherent** | 1) 正则 isCoherenceBroken 先判，命中即返回，不调 LLM<br>2) 通顺性结果缓存 | 减少 LLM 复检调用 |
| **多模型路由** | 1) 场景路由结果缓存（相同输入特征复用）<br>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 主要问题

1. **UDD 接口超时（60-180s）**：最严重问题，UDD 几乎不可用，需立即并行化 + 流式 + 降级改造
2. **敏感词 LLM 确认 500 错误（15 个高风险词）**：导致合规内容误拦截，需降级到关键词判定 + prompt 改造 + 多模型容灾
3. **LLM 调用缺乏缓存与并行化**：UDD 拆解、敏感词确认、替换词改写等环节均可通过缓存与并行化显著降本提速

### 6.3 演进方向

- **短期（1 月）**：修复敏感词 500 错误降级、UDD 超时并行化与流式输出
- **中期（3 月）**：UDD/敏感词/替换词 LLM 结果缓存、词表集中化、对抗测试集建设
- **长期（6 月）**：UDD 常见问题关键词快路径、多模型容灾、可观测性看板

通过上述演进，预计可将 UDD P95 延迟从 180s 降至 30s 以内，敏感词误拦截率降低 80%，LLM 调用成本降低 40%+。

---

*报告完*