Update project and configurations
This commit is contained in:
Zou-Seay
467
intelligent_cabin/archive/docs/solution_review.md
Normal file
467
intelligent_cabin/archive/docs/solution_review.md
Normal file
@@ -0,0 +1,467 @@
|
||||
# 对齐车机方案的实施流程复审
|
||||
|
||||
## 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. 接真实插件与真实语音链路
|
||||
|
||||
Reference in New Issue
Block a user