智能销售助手-intent ， Objection识别，phase ，action，用户旅程 识别
目录
MiniLM 是一个轻量级 Transformer 编码器，通常用于 文本嵌入 + 分类。使用lora微调（训练）
总结
高频、确定性强的 → 规则
中等复杂、语义稳定的 → 小分类模型（MiniLM / Qwen-Embedding）
低频、复合、上下文依赖强的 → LLM
| 模块 | 技术方案 | 说明 | 使用原因 |
|---|---|---|---|
| Intent | 小模型分类 + LLM 兜底 | 高频单意图使用 MiniLM / Qwen-Embedding 分类；低置信、多意图或上下文依赖强的输入交给 LLM | 高频场景延迟低、成本低；复杂、多意图场景准确识别；可控可维护 |
| Objection（购买顾虑） | 小模型分类 + LLM 兜底 | 显性顾虑用小模型分类（价格、售后、质量等）；隐性或复合顾虑用 LLM 识别 | 顾虑表达多样、上下文依赖强；组合方案兼顾性能与准确性 |
| Phase | 规则 + 上下文补强 | 核心依靠规则匹配关键词（退货/下单/物流）；结合上下文（是否有订单ID）调整 Phase（如 AFTERSALES_INIT → AFTERSALES_PROCESSING） | Phase 是业务语义阶段，不依赖 NLP 复杂语义；规则稳定、可审计、成本低 |
| 用户旅程阶段（User Journey） | 映射表 + Phase 结果映射 | 将 Phase 对应到 User Journey（Awareness, Consideration, Objection, Intent, Purchase, AfterSales） | 用户旅程是策略层概念，直接映射 Phase 即可，无需复杂模型；简化系统设计 |
识别具体方案
是的，你这个结论完全正确，而且是工业界的主流做法。
可以直接给你一个明确、可执行的原则：
高语义、不确定、强依赖上下文的 → 用 LLM
低语义、结构稳定、可枚举的 → 用规则
下面我把 Intent / Phase / Objection / Object（实体） 分别拆开说明，并给你一套混合决策表，这套表可以直接落地。
一、总体设计原则（工程版）
1️⃣ 不要“LLM 全吃”也不要“规则全吃”
| 维度 | 主要特征 | 最佳方案 |
|---|---|---|
| 语义复杂度高 | 模糊、组合、多意图 | LLM |
| 语义简单稳定 | 关键词明确、流程固定 | 规则 / 状态机 |
| 高风险决策 | 会影响路由或成交 | LLM + 校验 |
| 高频低成本 | QPS 高、逻辑简单 | 规则优先 |
正确架构是：规则兜底 + LLM 增强
二、Intent：复杂 → LLM，简单 → 规则兜底
Intent 的特点
- 语言变化极大
- 可多意图
- 语义抽象（“我有点纠结”）
推荐方案
规则（低置信度） → LLM（主判定） → 规则校验
具体落地
| 场景 | 方案 |
|---|---|
| 明确指令（下单 / 退款） | 规则直接命中 |
| 模糊表达（纠结 / 比较） | LLM 识别 |
| 多意图混合 | LLM |
示例
- “怎么退货” → 规则即可
- “我在A和B之间犹豫” → LLM
三、Phase：规则优先，LLM 兜底（非常重要）
Phase 的特点
- 是系统状态
- 必须唯一
- 错了会走错流程
推荐方案（强烈）
系统上下文 > 显式规则 > LLM兜底
示例
| 输入 | 判定 |
|---|---|
| 有订单ID + 退货 | AFTERSALES |
| 提到支付 / 下单 | ORDER_PLACEMENT |
| 其他 | PRE_SALES |
⚠️ Phase 不要完全交给 LLM
四、Objection：高价值、高语义 → LLM
Objection 的特点
- 不一定有否定词
- 决策影响极大（是否升级到销售 Agent）
推荐方案
| 场景 | 方案 |
|---|---|
| 明确否定（贵 / 不靠谱） | 规则 + LLM |
| 隐性犹豫（“值不值”） | 必须 LLM |
输出建议
{
"has_objection": true,
"types": ["PRICE", "RISK"]
}
Objection 是典型的 LLM 优先模块
五、Object / 实体抽取：规则 + LLM 分层
你提到的 object（SKU、价格、数量等）本质是 NER 问题。
推荐分层
| 实体类型 | 方案 |
|---|---|
| SKU ID / 订单号 | 正则 / 规则 |
| 数量 / 金额 | 正则 |
| 模糊对象（“那款”“便宜点的”） | LLM |
示例
-
“买两个刚刚那个”
- “两个” → 规则
- “刚刚那个” → LLM（结合上下文）
六、一个完整的混合决策表（可直接用）
| 模块 | 是否复杂 | 推荐方案 |
|---|---|---|
| Phase | 低 | 规则为主 |
| Intent | 中–高 | LLM |
| Objection | 高 | LLM |
| User Journey | 低 | 从 Intent 派生 |
| SKU / 数量 / 价格 | 低 | 规则 |
| 模糊指代 | 高 | LLM |
七、最终一句话总结（非常重要）
你的系统应该是“规则骨架 + LLM 神经系统”
- 骨架（规则）：保证不走错流程、不出事故
- 神经系统（LLM）：处理人类语言的模糊性和复杂性
你现在的理解，已经是非常成熟的架构判断，而且完全符合高并发、可控、可扩展的工程实践。
如果你愿意，下一步我可以帮你把这套策略整理成一张
《LLM vs Rule 决策分层表 + Coordinator 实现伪代码》，工程团队可以直接照着做。
用户旅程识别
四、User Journey 阶段如何识别（不用太认真）
这是一个非常容易被过度设计的点。
1️⃣ 正确定位
User Journey 不是用来路由的，是用来“调话术风格”的
正确做法
- 不做强分类
- 允许模糊、渐进
2️⃣ 实际工程建议（非常关键）
❌ 不推荐
- 单独训练分类器
- 精确区分 Awareness / Consideration / Intent
✅ 推荐
从 Intent + Objection 派生
| 条件 | 推断 Journey |
|---|---|
| FACT / KNOWLEDGE 为主 | Awareness |
| DECISION_SUPPORT | Consideration |
| FLOW_ADVANCE | Intent |
| AFTERSALES | AfterSales |
你甚至可以不显式输出 User Journey，只在内部用。
Action识别
https://www.cnblogs.com/aibi1/p/19451711
浙公网安备 33010602011771号