468 lines
10 KiB
Markdown
468 lines
10 KiB
Markdown
# 对齐车机方案的实施流程复审
|
||
|
||
## 1. 目标
|
||
|
||
本文档用于重新审视当前项目的实现方向，并将“对齐小鹏车机类方案”的核心流程、分支决策和典型场景演示明确下来。
|
||
|
||
目标不是做一个普通聊天机器人，而是做一个面向车机/客服/前台场景的低延迟执行型 Agent：
|
||
|
||
- 简单请求本地快速闭环
|
||
- 复杂请求云端增强处理
|
||
- 多轮短句能够恢复上下文
|
||
- 多命令能够拆分为 workflow 执行
|
||
- 超出能力边界时明确拒绝或澄清
|
||
|
||
---
|
||
|
||
## 2. 对齐车机方案的核心原则
|
||
|
||
结合前面参考的小鹏公开专利，可以抽象出下面几个工程原则：
|
||
|
||
- 本地优先，云端增强，不是所有请求都直接走远端大模型
|
||
- 本地不是单模型，而是多支路并发
|
||
- 快反馈和最终反馈分离，首反馈必须短而稳
|
||
- 多轮短句优先靠上下文改写和缓存恢复，不是每轮重做完整规划
|
||
- 高风险动作必须确认
|
||
- 超能力边界时必须拒答，不能强行分类执行
|
||
|
||
---
|
||
|
||
## 3. 总体流程图
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A[用户语音输入] --> B[ASR 转文本]
|
||
B --> C[文本归一化]
|
||
C --> D[本地多支路并发]
|
||
|
||
D --> D1[keyword / rule / trie]
|
||
D --> D2[local bert classifier]
|
||
D --> D3[context rewrite / cache]
|
||
D --> D4[retrieval matcher]
|
||
|
||
D1 --> E[本地融合分级器]
|
||
D2 --> E
|
||
D3 --> E
|
||
D4 --> E
|
||
|
||
E -->|高置信| F[直接执行或直接生成 workflow]
|
||
E -->|中置信| G[等待 100~300ms 观察补充分支/云端结果]
|
||
E -->|低置信| H[云端 planner / LLM / RAG]
|
||
|
||
G --> H
|
||
H --> I[生成 intent / workflow / clarify / reject]
|
||
|
||
F --> J[插件执行]
|
||
I --> J
|
||
|
||
J --> K[首反馈 ack / progress]
|
||
J --> L[最终反馈 result / clarify / reject]
|
||
```
|
||
|
||
---
|
||
|
||
## 4. 本地与云端分工
|
||
|
||
### 4.1 本地快链路
|
||
|
||
本地负责：
|
||
|
||
- 高频固定控制类命令
|
||
- 已知业务集合内的快速意图识别
|
||
- 短句、省略句、连续调节的上下文恢复
|
||
- 简单任务的直接执行
|
||
- `<1s` 以内的首响应
|
||
|
||
本地组件：
|
||
|
||
- `keyword / rule / trie`
|
||
- `local bert classifier`
|
||
- `context rewrite / cache`
|
||
- `retrieval matcher`
|
||
- `fusion grader`
|
||
|
||
### 4.2 云端慢链路
|
||
|
||
云端负责：
|
||
|
||
- 多命令拆分
|
||
- 条件型请求理解
|
||
- 歧义消解
|
||
- 复杂问答
|
||
- planner 级 workflow 生成
|
||
|
||
---
|
||
|
||
## 5. 本地分级决策图
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A[本地多分支结果] --> B{融合分级}
|
||
B -->|high| C[直接执行]
|
||
B -->|medium| D[等待 100~300ms]
|
||
B -->|low| E[不直接执行]
|
||
|
||
D --> F{云端是否及时返回}
|
||
F -->|是| G[采用云端结果或覆盖本地]
|
||
F -->|否| H{本地是否达到最低执行阈值}
|
||
|
||
H -->|是| I[执行本地结果]
|
||
H -->|否| J[澄清或拒答]
|
||
|
||
E --> K[云端理解 / clarify / reject]
|
||
```
|
||
|
||
关键修正点：
|
||
|
||
- 不是“本地 BERT 有结果就执行”
|
||
- 不是“云端没返回就一定执行本地”
|
||
- 必须先判断本地结果是否达到最低可执行阈值
|
||
- 高风险动作即使高置信，也不能直接执行
|
||
|
||
---
|
||
|
||
## 6. 用户反馈状态图
|
||
|
||
```mermaid
|
||
stateDiagram-v2
|
||
[*] --> Received
|
||
Received --> Ack: 已接收请求
|
||
Ack --> ExecutingFast: 本地快执行
|
||
Ack --> WaitingCloud: 等待云端/复杂规划
|
||
Ack --> Clarify: 缺关键槽位
|
||
Ack --> Confirm: 高风险动作
|
||
Ack --> Reject: 超能力边界
|
||
|
||
ExecutingFast --> Result
|
||
WaitingCloud --> Result
|
||
Clarify --> Result
|
||
Confirm --> Result
|
||
Reject --> [*]
|
||
Result --> [*]
|
||
```
|
||
|
||
反馈规则：
|
||
|
||
- `ack`：收到，马上处理
|
||
- `progress`：正在为你处理
|
||
- `result`：执行完成或查询完成
|
||
- `clarify`：信息不足，补一个关键字段
|
||
- `confirm`：高风险动作确认
|
||
- `reject`：能力边界拒答
|
||
|
||
---
|
||
|
||
## 7. 反馈模板策略
|
||
|
||
### 7.1 快执行
|
||
|
||
适用：
|
||
|
||
- 打开车窗
|
||
- 调低空调
|
||
- 播放音乐
|
||
- 导航去公司
|
||
|
||
推荐反馈：
|
||
|
||
- 首反馈：`好的，正在打开车窗`
|
||
- 最终反馈：`车窗已打开`
|
||
|
||
如果设备动作极快，也可以直接播报最终反馈：
|
||
|
||
- `车窗已打开`
|
||
|
||
### 7.2 慢执行
|
||
|
||
适用：
|
||
|
||
- 查订单
|
||
- 查物流
|
||
- 多命令复杂规划
|
||
- 条件型任务
|
||
|
||
推荐反馈：
|
||
|
||
- 首反馈：`收到，我先帮你查一下`
|
||
- 最终反馈：`订单还没发货`
|
||
|
||
### 7.3 复合命令
|
||
|
||
例如：
|
||
|
||
- `打开车窗，空调调低至20度`
|
||
|
||
推荐反馈：
|
||
|
||
- 首反馈：`好的，正在为你打开车窗并调低空调`
|
||
- 最终反馈：`车窗已打开，空调已调到20度`
|
||
|
||
### 7.4 边界外请求
|
||
|
||
例如：
|
||
|
||
- `打开飞机门`
|
||
|
||
推荐反馈：
|
||
|
||
- `这个我暂时做不了，但我可以帮你导航、查订单、调空调或播放音乐`
|
||
|
||
---
|
||
|
||
## 8. 多轮上下文恢复流程
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A[当前轮输入: 再低一点] --> B[读取 session context]
|
||
B --> C{是否命中高频改写缓存}
|
||
C -->|是| D[改写为完整句]
|
||
C -->|否| E[轻量改写模型/规则补全]
|
||
D --> F[进入 router]
|
||
E --> F
|
||
F --> G[意图识别 + 槽位提取 + 执行]
|
||
```
|
||
|
||
说明：
|
||
|
||
- 这里的“上下文能力”不是 BERT 自己缓存的
|
||
- 而是 Agent 在 `session state` 中保存上轮任务和关键槽位
|
||
- 再由 `rewrite engine` 完成短句恢复
|
||
|
||
---
|
||
|
||
## 9. 典型场景流程演示
|
||
|
||
### 9.1 场景一：快执行单命令
|
||
|
||
用户输入：
|
||
|
||
- `打开车窗`
|
||
|
||
处理流程：
|
||
|
||
1. ASR 转文本：`打开车窗`
|
||
2. 文本归一化
|
||
3. 本地多支路并发
|
||
4. 若本地高置信命中 `cabin_open_window`
|
||
5. 直接执行车窗插件
|
||
6. 播报：`车窗已打开`
|
||
|
||
时序演示：
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant U as 用户
|
||
participant A as ASR
|
||
participant R as 本地路由
|
||
participant P as 插件执行
|
||
participant T as TTS
|
||
|
||
U->>A: 打开车窗
|
||
A->>R: 打开车窗
|
||
R->>P: 执行 open_window
|
||
P-->>R: success
|
||
R->>T: 车窗已打开
|
||
T-->>U: 车窗已打开
|
||
```
|
||
|
||
### 9.2 场景二：复合命令快执行
|
||
|
||
用户输入：
|
||
|
||
- `打开车窗，空调调低至20度`
|
||
|
||
处理流程：
|
||
|
||
1. 文本进入本地路由
|
||
2. 判断为多命令
|
||
3. planner 或本地 splitter 输出两个 step
|
||
4. 生成 sequence workflow
|
||
5. 顺序执行：
|
||
- 打开车窗
|
||
- 空调调到 20 度
|
||
6. 汇总反馈：`车窗已打开，空调已调到20度`
|
||
|
||
时序演示：
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant U as 用户
|
||
participant A as ASR
|
||
participant F as 融合分级器
|
||
participant W as Workflow
|
||
participant P as 插件层
|
||
participant T as TTS
|
||
|
||
U->>A: 打开车窗，空调调低至20度
|
||
A->>F: 规范化文本
|
||
F->>W: 输出 sequence workflow
|
||
W->>P: step1 open_window
|
||
P-->>W: success
|
||
W->>P: step2 set_ac(20)
|
||
P-->>W: success
|
||
W->>T: 车窗已打开，空调已调到20度
|
||
T-->>U: 车窗已打开，空调已调到20度
|
||
```
|
||
|
||
### 9.3 场景三：慢执行查询
|
||
|
||
用户输入：
|
||
|
||
- `帮我查一下订单A123456`
|
||
|
||
处理流程：
|
||
|
||
1. 本地高频分支命中订单查询
|
||
2. 首反馈先给：
|
||
- `收到，我帮你查一下`
|
||
3. 调用订单查询插件
|
||
4. 最终反馈：
|
||
- `订单A123456当前待发货`
|
||
|
||
### 9.4 场景四：条件型请求
|
||
|
||
用户输入：
|
||
|
||
- `查一下订单A123456，如果还没发货就取消`
|
||
|
||
处理流程：
|
||
|
||
1. 本地识别该请求复杂，进入云端 planner
|
||
2. planner 输出 conditional workflow：
|
||
- step1: query_order
|
||
- step2: cancel_order
|
||
- condition: order_status == pending_shipment
|
||
3. 先执行 step1
|
||
4. 若满足条件，则进入确认
|
||
5. 用户回复确认后，再执行取消
|
||
6. 最终反馈：
|
||
- `订单A123456已取消`
|
||
|
||
时序演示：
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant U as 用户
|
||
participant R as 本地融合器
|
||
participant C as 云端 Planner
|
||
participant W as Workflow
|
||
participant P as 插件层
|
||
participant T as TTS
|
||
|
||
U->>R: 查一下订单A123456，如果还没发货就取消
|
||
R->>C: 复杂条件请求
|
||
C-->>W: conditional workflow
|
||
W->>P: step1 query_order
|
||
P-->>W: order_status=pending_shipment
|
||
W->>T: 即将取消订单，仅在订单未发货时取消。请回复确认或取消
|
||
T-->>U: 确认提示
|
||
U->>W: 确认
|
||
W->>P: step2 cancel_order
|
||
P-->>W: success
|
||
W->>T: 订单A123456已取消
|
||
T-->>U: 订单A123456已取消
|
||
```
|
||
|
||
### 9.5 场景五：多轮短句恢复
|
||
|
||
对话过程：
|
||
|
||
1. 用户：`把空调调到22度`
|
||
2. 系统：`空调已调到22度`
|
||
3. 用户：`再低一点`
|
||
4. 系统读取 `last_intent=cabin_set_ac` 和 `last_temperature=22`
|
||
5. rewrite engine 改写为：`把空调调到21度`
|
||
6. 再进入意图识别和执行
|
||
7. 系统反馈：`空调已调到21度`
|
||
|
||
### 9.6 场景六：边界外请求
|
||
|
||
用户输入：
|
||
|
||
- `打开飞机门`
|
||
|
||
正确处理：
|
||
|
||
1. 本地分支都无法稳定支持
|
||
2. 若低于执行阈值，不得直接执行已有意图
|
||
3. 进入：
|
||
- reject
|
||
- 或云端澄清
|
||
4. 反馈：
|
||
- `这个我暂时做不了，但我可以帮你导航、查订单、调空调或播放音乐`
|
||
|
||
这类场景必须通过 `unknown / out_of_scope` 机制处理，不能靠封闭集分类硬选。
|
||
|
||
---
|
||
|
||
## 10. 当前项目与目标方案的对应关系
|
||
|
||
### 10.1 已经具备的能力
|
||
|
||
- 本地 `keyword / classifier / retrieval / fusion`
|
||
- 本地 BERT 分类器
|
||
- `session state`
|
||
- `context rewrite`
|
||
- `planner`
|
||
- `sequence / conditional workflow`
|
||
- 高风险确认
|
||
- demo 调试面板
|
||
|
||
### 10.2 还需要补齐的关键能力
|
||
|
||
- `unknown / out_of_scope`
|
||
- 低分拒识策略
|
||
- 明确的 `execute / reject / route_to_cloud` 决策建议
|
||
- 更多真实车机意图
|
||
- 真实插件接入
|
||
- 语音前端与 ASR/TTS 完整接入
|
||
|
||
---
|
||
|
||
## 11. 当前阶段的正式实施结论
|
||
|
||
当前方向可以继续，但必须明确：
|
||
|
||
- 本地 BERT 是本地快分支之一，不是整个系统的唯一裁决者
|
||
- 最终执行依据应来自“本地融合分级器 + planner + 风险规则”
|
||
- 用户体验的关键不只是识别正确，还包括：
|
||
- 首反馈是否快
|
||
- 多轮是否顺
|
||
- 边界是否清楚
|
||
- 风险是否可控
|
||
|
||
因此，当前正式方案应定义为：
|
||
|
||
```text
|
||
车机型 Agent = 本地并发快链路
|
||
+ 上下文改写缓存
|
||
+ 分级融合决策
|
||
+ 云端 planner
|
||
+ workflow 执行
|
||
+ 风险确认
|
||
+ reject / clarify / fallback 策略
|
||
```
|
||
|
||
---
|
||
|
||
## 12. 下一步执行优先级
|
||
|
||
建议按以下顺序继续实现：
|
||
|
||
1. 补 `unknown / out_of_scope` 和拒识阈值
|
||
2. 输出统一执行建议：
|
||
- `execute`
|
||
- `clarify`
|
||
- `reject`
|
||
- `route_to_cloud`
|
||
3. 扩真实车机场景意图：
|
||
- 车窗
|
||
- 车门
|
||
- 座椅
|
||
- 灯光
|
||
- 后视镜
|
||
- 除雾
|
||
4. 强化 rewrite/cache 高频模式
|
||
5. 接真实插件与真实语音链路
|
||
|