372 lines
14 KiB
Markdown
372 lines
14 KiB
Markdown
# intelligent_cabin BERT 接入 · 冲突分析与整合方案
|
||
|
||
> 作者：AI 分析
|
||
> 日期：2026-05-26
|
||
> 状态：待你确认
|
||
|
||
---
|
||
|
||
## 背景速览
|
||
|
||
| 侧 | 项目 | 技术栈 | 角色 |
|
||
|---|---|---|---|
|
||
| **Canvas（前端/编排侧）** | ai-canvas / Next.js | TypeScript + React | 画布渲染、Artifact 管理、LLM 编排、工业工具调用（DBus/PLC）|
|
||
| **BERT 服务侧** | intelligent_cabin | Python / FastAPI | 本地 NLU：intent + slot，语音控制场景 |
|
||
|
||
这两个项目目前是独立的，尚未对接。
|
||
|
||
---
|
||
|
||
## 一、冲突点（需要明确决策的地方）
|
||
|
||
### 冲突 1：Domain 语义完全不匹配 ⚠️ 重要
|
||
|
||
**问题**：`intelligent_cabin/config/domain.yml` 里的 intent 全部来自车机场景（导航、空调、音乐、车窗、车灯……），与 `DBUS_API.md` 描述的线切割工控场景（电压、电流、速度、NC 加工、空走、回零）**毫无重叠**。
|
||
|
||
**后果**：如果直接把 BERT 服务接进来，意图识别的类别集合完全覆盖不了工控指令，识别结果几乎全是 unknown/reject。
|
||
|
||
**需确认**：
|
||
- [ ] 你们会用智能车机的这套预训练模型做迁移学习，还是重新训练工控专属的 BERT 模型？
|
||
- [ ] 还是说这个 BERT 服务只是作为基础推理框架，`domain.yml` 需要被替换成工控版 domain？
|
||
|
||
---
|
||
|
||
### 冲突 2：置信度阈值体系 vs. Canvas 路由体系
|
||
|
||
**Canvas 流程**（参考 `architecture_overview.html`）的技术视图里：
|
||
```
|
||
输入 → BERT NLU → confidence 判断 → [高置信+设备控制域] / [知识域/低置信] / [smalltalk]
|
||
```
|
||
|
||
**intelligent_cabin 的路由体系**（`router.py`）：
|
||
```
|
||
输入 → Classifier → FusionGrader →
|
||
decision = execute / clarify / route_to_cloud / reject
|
||
阈值：execute_score=0.55, execute_margin=0.18, route_to_cloud=0.75
|
||
```
|
||
|
||
两套路由各有自己的 confidence 分级，**如果串联，会出现双重过滤**：
|
||
- BERT 服务输出的 `score` 未必能直接映射到 Canvas 的 `confidence ≥ 阈值` 判断
|
||
- Canvas 目前只依赖 BERT 输出的 `domain/intent/slot/confidence`，但 BERT 服务输出的是 `intent_id + score + decision`
|
||
|
||
**需确认**：
|
||
- [ ] Canvas 侧是否需要直接消费 `decision` 字段（execute/clarify/route_to_cloud/reject），还是只取 `intent_id + score`，Canvas 自己做二次路由？
|
||
|
||
---
|
||
|
||
### 冲突 3：`textAliases`（大流程 B）vs. BERT 意图识别的竞争
|
||
|
||
**Canvas 大流程 B（调机流程中）的路由逻辑**：
|
||
```
|
||
输入 → 优先匹配 textAliases（如"完成"/"下一步"/"确认"）
|
||
→ 未命中 → BERT NLU 重新识别
|
||
```
|
||
|
||
**intelligent_cabin** 里的 `DialogActEngine`（`dialog_act.py`）也在做相似的事情：
|
||
```python
|
||
affirm: ["确认", "好的", "继续", "可以", "确定"]
|
||
cancel: ["取消", "算了", "不用了", "停止"]
|
||
```
|
||
|
||
**冲突**：
|
||
- `textAliases` 是每个 Artifact Step 私有的，属于 Canvas 状态机层面的规则匹配
|
||
- `DialogActEngine` 是系统级对话行为分类，优先级/触发顺序未对齐
|
||
- 如果两套都跑，"确认"这个词可能被 `DialogActEngine` 吃掉后不再传给 Canvas 的步骤推进逻辑
|
||
|
||
**整合建议**：
|
||
- 大流程 B 中，textAliases 匹配应在 BERT 服务之前，Canvas 侧处理，不交给 BERT 服务
|
||
- 把 `dialog_acts.yml` 的 `affirm/deny/cancel/modify` 从 BERT 服务中剥离，改为 Canvas 路由层的前置规则
|
||
- 或者让 BERT 服务的 dialog_act 结果作为辅助 metadata 透传，Canvas 侧自行决策
|
||
|
||
---
|
||
|
||
### 冲突 4：slot 语义不兼容
|
||
|
||
**BERT 服务的 slot 体系**（按车机场景设计）：
|
||
- `temperature`：空调温度（16-30°C）
|
||
- `destination`：导航目的地
|
||
- `order_id`：订单号
|
||
- `song`：歌曲名
|
||
|
||
**线切割工控的 slot 需求**（从 `DBUS_API.md` 推导）：
|
||
- `speed`：加工速度（mm/min，1-9999）
|
||
- `voltage`：放电码/电压
|
||
- `current`：跟踪值/电流
|
||
- `workpiece_id`：工件编号（0-8）
|
||
- `knife_id`：刀号（1-11）
|
||
- `param_type`：参数类型（voltage/current/servo）
|
||
- `nc_path`：NC 文件绝对路径
|
||
- `axis`：轴编号（0-5，X/Y/Z/U/V/C）
|
||
|
||
两套 slot 定义**完全不同**，需要重写 `domain.yml` 和 `rewrite_engine.py` 里的工控版本。
|
||
|
||
---
|
||
|
||
### 冲突 5：rewrite_engine 的上下文改写逻辑是车机特化的
|
||
|
||
`rewrite_engine.py` 里写死了：
|
||
```python
|
||
_AC_CONTEXT_INTENTS = {"cabin_set_ac", "cabin_ac_on", "cabin_ac_off", ...}
|
||
_AC_DEFAULT_TEMPERATURE = 24
|
||
_AC_STEP = 2
|
||
_AC_MIN_TEMPERATURE = 16
|
||
_AC_MAX_TEMPERATURE = 30
|
||
```
|
||
|
||
这些都是车机空调的业务逻辑，工控场景需要换成类似：
|
||
```python
|
||
_PARAM_CONTEXT_INTENTS = {"wirecut_set_speed", "wirecut_set_voltage", "wirecut_set_current"}
|
||
_SPEED_STEP = 5 # mm/min
|
||
_VOLTAGE_STEP = 5 # 放电码
|
||
```
|
||
|
||
**但这恰恰也是最有价值可以复用的能力**：多轮相对调节（"再快一点"→ 改写为 "速度设为 85mm/min"）在工控场景同样刚需。
|
||
|
||
---
|
||
|
||
## 二、可以直接整合的能力（不需要改动或改动很小）
|
||
|
||
### ✅ 整合点 1：FastAPI 服务直接作为 NLU 微服务接入
|
||
|
||
Canvas（Next.js 侧）可以通过 HTTP 调用 `POST /api/v1/agent/chat` 或 `POST /api/v1/agent/fill-slots`，作为 Canvas 的 "感知语义层"。
|
||
|
||
接入位置：Canvas 的"BERT NLU 意图识别"节点（技术流程视图第 2 层）
|
||
|
||
```
|
||
Canvas 输入 → HTTP POST → intelligent_cabin :8000/api/v1/agent/chat
|
||
← {intent_id, score, slots, decision}
|
||
Canvas 路由层根据 intent_id + score 继续分发
|
||
```
|
||
|
||
### ✅ 整合点 2：分级融合决策逻辑（router.py）可以直接复用
|
||
|
||
`MultiStageIntentMatcher` 里的 `execute / clarify / route_to_cloud / reject` 四态决策逻辑，与 Canvas 流程中"高置信执行 / 知识域兜底 / smalltalk" 的三路分发思路高度一致，可以直接用。
|
||
|
||
Canvas 只需要消费 BERT 服务返回的 `decision` 字段，然后：
|
||
- `execute` → Canvas 走工具调用路径（DBus）
|
||
- `clarify` → Canvas 展示澄清确认卡
|
||
- `route_to_cloud` → Canvas 走 LLM 兜底路径
|
||
- `reject` → Canvas 走 smalltalk / fallback
|
||
|
||
### ✅ 整合点 3：会话状态管理（session_store.py）
|
||
|
||
`SessionState` 里的 `context_memory` 和 `slots` 持久化机制，可以支持工控场景的多轮短句恢复（比如 "再快一点" → 记住上次速度值）。
|
||
|
||
### ✅ 整合点 4：多命令拆分（planner.py）
|
||
|
||
现有的 `sequence workflow` 和 `conditional workflow` 对工控多命令（"先回零，再开始加工"）直接可用。
|
||
|
||
### ✅ 整合点 5：高风险确认机制（dialog_rules.py）
|
||
|
||
`requires_confirmation` + `confirmation_required_risk_levels` 这套机制，完全可以映射到 Canvas 流程中"操控确认卡"的场景（Canvas 大流程 A 的场景 1），直接支持危险操作二次确认。
|
||
|
||
---
|
||
|
||
## 三、需要新建或重写的工控专属配置
|
||
|
||
### 3.1 新建 `config/domain_wirecut.yml`
|
||
|
||
需要把 DBUS_API.md 里的每个接口映射成 intent：
|
||
|
||
| intent_id | 对应 DBus 方法 | 示例语句 | 需要 slot |
|
||
|---|---|---|---|
|
||
| `wirecut_start_run` | `startRun()` | "开始加工" / "启动" | 无 |
|
||
| `wirecut_stop_run` | `stopRun()` | "停止加工" / "停机" | 无 |
|
||
| `wirecut_pause_run` | `pauseRun()` | "暂停" / "变频暂停" | 无 |
|
||
| `wirecut_home_all` | `homeAll()` | "全轴回零" / "回零" | 无 |
|
||
| `wirecut_start_kongzou` | `startKongZou()` | "开始空走" | 无 |
|
||
| `wirecut_stop_kongzou` | `stopKongZou()` | "停止空走" | 无 |
|
||
| `wirecut_set_speed` | `setSpeed(speed)` | "速度调到80" / "加快一点" | `speed:int` |
|
||
| `wirecut_set_voltage` | `setVoltage(vol)` | "电压设为90" | `voltage:int` |
|
||
| `wirecut_set_current` | `setCurrent(cur)` | "电流设为5" | `current:int` |
|
||
| `wirecut_get_status` | `getStatus()` | "查一下状态" / "当前状态" | 无 |
|
||
| `wirecut_load_nc` | `loadNC(path)` | "加载NC文件" | `nc_path:str` |
|
||
| `wirecut_set_discharge` | `SetDischargePara(...)` | "设置工件0刀1放电码80" | `workpiece_id, knife_id, param_type, value` |
|
||
|
||
### 3.2 重写 `rewrite_engine.py` 里的工控上下文改写规则
|
||
|
||
```python
|
||
# 工控版示例
|
||
_SPEED_CONTEXT_INTENTS = {"wirecut_set_speed"}
|
||
_SPEED_STEP = 5 # mm/min 每步调节
|
||
_SPEED_MIN = 1
|
||
_SPEED_MAX = 9999
|
||
|
||
_VOLTAGE_CONTEXT_INTENTS = {"wirecut_set_voltage"}
|
||
_VOLTAGE_STEP = 5
|
||
|
||
# 改写规则
|
||
"再快一点" → "速度设为 {last_speed + 5} mm/min"
|
||
"再慢一点" → "速度设为 {last_speed - 5} mm/min"
|
||
"电压再高一点" → "电压设为 {last_voltage + 5}"
|
||
```
|
||
|
||
### 3.3 更新 `dialog_acts.yml` 适配工控确认场景
|
||
|
||
当前 `dialog_acts.yml` 的 `affirm/deny/cancel` 词表可以保留，但需要补充工控场景的特化语句：
|
||
|
||
```yaml
|
||
# 工控场景补充
|
||
affirm:
|
||
+ "执行" / "开始" / "运行" / "启动"
|
||
cancel:
|
||
+ "停机" / "急停" / "中止"
|
||
inform:
|
||
+ 纯数字（速度值/电压值/电流值的slot填写）
|
||
```
|
||
|
||
---
|
||
|
||
## 四、关于 dialog_act 和 rewrite_engine 能否通过配置文件驱动
|
||
|
||
**直接回答：当前已经部分支持，但工控场景需要扩展。**
|
||
|
||
### 4.1 dialog_act 配置化现状
|
||
|
||
`dialog_act.py` 里的 `DialogActEngine` 是数据驱动的：
|
||
```python
|
||
@dataclass
|
||
class DialogActEngine:
|
||
patterns: dict[str, tuple[str, ...]] = field(default_factory=...)
|
||
```
|
||
|
||
`config_loader.py` 里已经实现了从 `dialog_acts.yml` 加载：
|
||
```python
|
||
def _load_dialog_act_engine(self) -> DialogActEngine:
|
||
...
|
||
return DialogActEngine(patterns={item.act_id: tuple(item.phrases) for item in parsed.acts})
|
||
```
|
||
|
||
**✅ 结论**：`dialog_acts.yml` 已经是配置文件，直接修改 `config/dialog_acts.yml` 就能修改 act 词表，**无需改代码**。
|
||
|
||
**但是有个缺口**：当前 `dialog_acts.yml` 只支持 `字符串包含` 匹配（`phrase in normalized`），没有支持正则或数值范围匹配。工控场景里 "85" 这样的纯数字（作为速度 slot 的 `inform`）目前是靠 Python 代码里的 `if re.search(r"\d", normalized): return "inform"` 处理的，这个逻辑是硬编码在 `dialog_act.py` 里的，暂时没有配置化。
|
||
|
||
**建议优化**（详见第五节）。
|
||
|
||
### 4.2 rewrite_engine 配置化现状
|
||
|
||
`rewrite_engine.py` 里的上下文改写逻辑**全部硬编码**，没有配置文件支持：
|
||
|
||
```python
|
||
_AC_CONTEXT_INTENTS = {"cabin_set_ac", ...} # 硬编码
|
||
_AC_DEFAULT_TEMPERATURE = 24 # 硬编码
|
||
_AC_STEP = 2 # 硬编码
|
||
```
|
||
|
||
**❌ 问题**：不同设备（线切割 / 激光切割 / 注塑机 / 其他）的参数名、步长、范围都不同，每台设备都要改代码是不合理的。
|
||
|
||
**建议优化**（详见第五节）。
|
||
|
||
---
|
||
|
||
## 五、建议优化：将 rewrite_engine 和 dialog_act 配置化
|
||
|
||
这是你关心的核心问题，以下是具体方案。
|
||
|
||
### 5.1 新增 `config/context_rewrite.yml`
|
||
|
||
```yaml
|
||
# context_rewrite.yml
|
||
param_contexts:
|
||
- intent_ids: ["wirecut_set_speed"]
|
||
slot_name: "speed"
|
||
unit: "mm/min"
|
||
step: 5
|
||
min_value: 1
|
||
max_value: 9999
|
||
default_value: 80
|
||
up_phrases: ["再快一点", "加快", "速度调高", "快一点"]
|
||
down_phrases: ["再慢一点", "减慢", "速度调低", "慢一点"]
|
||
rewrite_template: "速度设为 {value} mm/min"
|
||
|
||
- intent_ids: ["wirecut_set_voltage"]
|
||
slot_name: "voltage"
|
||
unit: ""
|
||
step: 5
|
||
min_value: 0
|
||
max_value: 200
|
||
default_value: 90
|
||
up_phrases: ["电压高一点", "电压调高"]
|
||
down_phrases: ["电压低一点", "电压调低"]
|
||
rewrite_template: "电压设为 {value}"
|
||
|
||
- intent_ids: ["wirecut_set_current"]
|
||
slot_name: "current"
|
||
unit: ""
|
||
step: 1
|
||
min_value: 0
|
||
max_value: 30
|
||
default_value: 5
|
||
up_phrases: ["电流大一点", "跟踪值高一点"]
|
||
down_phrases: ["电流小一点", "跟踪值低一点"]
|
||
rewrite_template: "电流设为 {value}"
|
||
```
|
||
|
||
然后修改 `rewrite_engine.py`，从 `context_rewrite.yml` 驱动逻辑，而不是硬编码。
|
||
|
||
### 5.2 扩展 `config/dialog_acts.yml` 支持 inform 的数值捕获
|
||
|
||
```yaml
|
||
# dialog_acts.yml 新增字段
|
||
acts:
|
||
- act_id: inform
|
||
phrases: []
|
||
# 新增：数值模式检测
|
||
numeric_patterns: ["\\d+"] # 包含数字就认为是 inform
|
||
```
|
||
|
||
并在 `dialog_act.py` 里支持 `numeric_patterns` 字段，这样 "85" / "22度" 是否算 inform 就可以通过配置控制。
|
||
|
||
### 5.3 `Settings`（config.py）里增加工控设备配置项
|
||
|
||
`app/core/config.py` 里的 `Settings` 类目前通过环境变量驱动，建议增加工控配置路径：
|
||
|
||
```python
|
||
# 新增到 Settings 类
|
||
context_rewrite_config_path: str = "config/context_rewrite.yml"
|
||
device_domain_config_path: str = "config/domain_wirecut.yml" # 可按设备切换
|
||
```
|
||
|
||
这样不同设备（线切割、激光机）只需要切换 `.env` 文件里的 `AGENT_DEVICE_DOMAIN_CONFIG_PATH` 就能换一套 domain + rewrite 配置，**不改代码**。
|
||
|
||
---
|
||
|
||
## 六、整合架构建议（整体链路）
|
||
|
||
```
|
||
语音输入
|
||
↓ ASR（前端 / 设备侧）
|
||
文本输入
|
||
↓
|
||
Canvas 路由层（Next.js / TypeScript）
|
||
├── [大流程 B 激活] textAliases 匹配 → 直接推进 Artifact 步骤（不过 BERT）
|
||
└── [其他] HTTP → intelligent_cabin :8000
|
||
↓
|
||
context rewrite（工控版配置化）
|
||
↓
|
||
BERT NLU（工控 domain）
|
||
↓
|
||
fusion decision
|
||
├── execute → Canvas 走 DBus 工具调用
|
||
├── clarify → Canvas 渲染 Artifact 确认卡
|
||
├── route_to_cloud → Canvas 走 LLM 兜底 + 知识库
|
||
└── reject → Canvas smalltalk / fallback
|
||
```
|
||
|
||
---
|
||
|
||
## 七、待你确认的清单
|
||
|
||
| # | 问题 | 选项 |
|
||
|---|---|---|
|
||
| 1 | BERT 模型是否会重训成工控版，还是继续用车机模型迁移？ | A. 重训工控 BERT B. 车机→工控迁移 C. 暂时用 mock/keyword |
|
||
| 2 | Canvas 是消费 BERT 的 `decision` 字段，还是只取 `intent_id+score` 自己路由？ | A. 消费 decision B. 自路由 |
|
||
| 3 | 大流程 B 的 textAliases 匹配，确认在 Canvas 侧做，不经过 BERT 服务？ | A. 是 B. 也经过 BERT 但 BERT 优先级低 |
|
||
| 4 | rewrite_engine 配置化的优先级？现在要做还是等工控 domain 确定后一起做？ | A. 现在就做 B. 等 domain 定了再做 |
|
||
| 5 | dialog_acts.yml 的 `inform` 数值识别是否需要配置化？ | A. 配置化 B. 保持硬编码即可 |
|
||
| 6 | 不同设备部署时，是一个 BERT 服务实例 + 不同 `.env` 配置，还是多个实例？ | A. 单实例多配置 B. 多实例 |
|
||
|
||
---
|
||
|
||
*本文档由 Antigravity 生成，请确认后继续推进实现。*
|