销售助手-Action识别技术

目录

• 一句话结论（先给你定性）
• 一、先把概念彻底拆清楚（避免混）
• 二、Action 到底是什么？（这是关键）
  • Action = 系统需要立即执行的操作类型
• 三、Action 识别，用规则还是模型？——分层设计
  • 第一层：规则（Rule Engine）——必须要有
    • 典型规则 Action
  • 第二层：小模型分类（MiniLM / Qwen-Embedding + Classifier）——主力
    • 适合的 Action 类型
    • 技术实现（典型）
  • 第三层：LLM（Qwen 14B / 32B）——兜底 & 复杂场景
    • 什么时候必须用 LLM？
    • LLM 输出不应该是“直接回答”，而是结构化决策
• 四、你刚刚提的退货例子，其实正好说明问题
  • 正确拆解方式
• 五、最终推荐的 Action 识别架构（给你一张“设计图”）
• 六、把话说死一点（避免以后走弯路）
• 七、如果你愿意，下一步我可以直接帮你做

你这个问题问得非常到位，而且已经到了系统设计而不是“用不用 LLM”的层级了。
我直接给你一个工程可落地、分层清晰、不容易走歪路的答案。

---

一句话结论（先给你定性）

Action 识别不应该只用一种方式，而是「规则 + 小模型 + LLM 分层协作」

• 高频、确定性强的 Action → 规则
• 中等复杂、语义稳定的 Action → 小分类模型（MiniLM / Qwen-Embedding）
• 低频、复合、上下文依赖强的 Action → LLM

这是工业级客服 / 销售系统的标准解法。

---

一、先把概念彻底拆清楚（避免混）

你现在系统里至少有 4 个“判断维度”，很多人会混在一起：

维度	本质	例子
Intent	用户“想干什么”	咨询 / 对比 / 下单 / 投诉
Phase / Journey	处在人生哪个阶段	Pre-sales / Order / After-sales
Objection	是否有顾虑/阻力	贵、担心质量、怕退货
Action	当前一句话希望系统做什么	查优惠 / 查物流 / 发下单链接

⚠️ Action ≠ Intent
同一个 Intent，在不同 Action 下，系统行为完全不同。

---

二、Action 到底是什么？（这是关键）

Action = 系统需要立即执行的操作类型

比如：

• 返回一个事实
• 拉优惠策略
• 触发下单 CTA
• 走售后 SOP
• 转人工
• 情绪安抚

你可以把它理解成 “API / Handler 级别的决策”。

---

三、Action 识别，用规则还是模型？——分层设计

第一层：规则（Rule Engine）——必须要有

适合的 Action 类型：

• 明确关键词
• 法务 / 合规 / SLA 敏感
• 一旦误判成本很高

典型规则 Action

if 包含(订单号) && 包含(退货|退款|取消)
  → Action = AFTERSALES_RETURN

if 包含(人工客服|投诉|举报)
  → Action = ESCALATE_TO_HUMAN

if 包含(支付失败|扣款)
  → Action = PAYMENT_EXCEPTION

特点

• 快
• 可控
• 可审计
• PM / 运营能直接改

👉 这是底座，不是可选项

---

第二层：小模型分类（MiniLM / Qwen-Embedding + Classifier）——主力

这是你问 MiniLM 的核心价值点。

适合的 Action 类型

• 语义明确但表达多样
• 高频出现
• 不值得每次都调用大模型

例如：

用户话术	Action
现在买有优惠吗	CHECK_PROMOTION
能便宜点吗	CHECK_PROMOTION
有什么活动	CHECK_PROMOTION
和 XX 有什么区别	PRODUCT_COMPARISON
推荐一款适合我的	PRODUCT_RECOMMEND

技术实现（典型）

Text
 → Embedding (MiniLM / Qwen-Embedding)
 → Action Classifier（10～50 类）
 → Action = xxx

优点

• 成本极低
• 延迟极低
• 稳定性强
• 非常适合 Action 层

👉 Action 识别，80% 应该在这一层解决

---

第三层：LLM（Qwen 14B / 32B）——兜底 & 复杂场景

什么时候必须用 LLM？

• 一句话里有多个 Action
• 强上下文依赖
• 隐含意图
• Action 需要结合历史对话

例如：

“之前你说有活动，现在下单是不是更划算？但我有点担心售后。”

这里同时包含：

• 查优惠
• 轻度购买倾向
• 售后顾虑

只有 LLM 能处理这种组合判断。

LLM 输出不应该是“直接回答”，而是结构化决策

{
  "actions": [
    { "type": "CHECK_PROMOTION", "priority": 1 },
    { "type": "HANDLE_OBJECTION", "priority": 2 }
  ],
  "confidence": {
    "purchase_intent": 0.62
  }
}

---

四、你刚刚提的退货例子，其实正好说明问题

你说：

如果刚开始没有订单，用户说“我要退货”，难道不是 pre-sales 吗？

你是完全对的，而且这正好说明：

Phase ≠ Action

正确拆解方式

维度	结果
Intent	售后意图
Phase	Pre-sales（因为没有订单）
Action	CLARIFY_ORDER / GUIDE_POLICY

Action 不应该是 AFTERSALES_RETURN
而应该是：

Action = ASK_FOR_ORDER / EXPLAIN_RETURN_POLICY

👉 所以 Action 是最“贴近系统行为”的层级

---

五、最终推荐的 Action 识别架构（给你一张“设计图”）

User Query
   ↓
[Rule Engine]                ← 硬规则 / 风控 / 人工
   ↓（未命中）
[Action Classifier (MiniLM)] ← 80% 高频 Action
   ↓（低置信 or 多意图）
[LLM Decision Model]         ← 复杂组合 / 上下文
   ↓
Action List + Priority

---

六、把话说死一点（避免以后走弯路）

• ❌ 不要所有 Action 都交给 LLM

• ❌ 不要只用规则（维护成本会炸）

• ❌ 不要让 Agent 自己“猜”要干什么

• ✅ Action 是系统工程问题，不是 NLP 炫技问题

• ✅ 小模型 + 规则是主力

• ✅ LLM 是“裁判 + 编排器”

---

七、如果你愿意，下一步我可以直接帮你做

你已经到可以落代码的阶段了，我可以继续帮你：

1. 给你一个 Action taxonomy（完整 Action 枚举表）
2. 给你 MiniLM Action 分类标签设计
3. 设计 Action → Agent → Handler 映射表
4. 甚至直接给你 Prompt + JSON Schema

你可以直接说：

“下一步我们把 Action 列表定下来”