Update vehicle control complexity rules
This commit is contained in:
@@ -23,6 +23,121 @@
|
||||
|
||||
针对车内空调、车窗、座椅、灯光、驾驶相关设置等车控能力,以下类型可以给 `complex=true`。
|
||||
|
||||
### 车控意向表达的基础分流
|
||||
|
||||
先判断 query 是否包含车内设备、车内空间、车载功能或明确车载上下文。
|
||||
|
||||
- 如果 query 包含车内设备/空间/功能线索,并表达主观感受、状态不满、舒适度诉求或潜在操作意向,业务标签优先判断为 `车载控制`,复杂度给 `complex=true`。
|
||||
- 如果 query 不包含车内设备/空间/功能线索,只是单纯表达身体感受或闲聊式状态,不要强行映射到车控;通常按 `闲聊/QA` 等非车控标签判断,复杂度不因车控规则升级。
|
||||
- “车内设备/空间/功能线索”包括但不限于:车里/车内/后排/副驾/脚底下/头顶/车窗/空调/风/座椅/阅读灯/后视镜/车耳朵/引擎盖/雨雪模式/压线提示音等。
|
||||
|
||||
示例:
|
||||
|
||||
| query | 业务标签倾向 | complex | 原因 |
|
||||
| --- | --- | --- | --- |
|
||||
| 车里空调好热 | 车载控制 | true | 包含车内设备“空调” + 主观感受,需要推断降温/调空调 |
|
||||
| 脚底下好冷,腿快冻麻了 | 车载控制 | true | 包含车内空间“脚底下” + 冷感,需要推断脚部出风/空调/座椅等 |
|
||||
| 风一直吹我脸,有点难受 | 车载控制 | true | 包含车内风向线索 + 舒适度诉求,需要推断调整风向/风量 |
|
||||
| 我好热啊 | 闲聊/QA | false | 未出现车内设备/空间/功能线索,只是身体感受 |
|
||||
| 我有点晕车 | 闲聊/QA | false | 未指定车控设备或可执行车控意向,默认不落车控 |
|
||||
|
||||
注意:如果上文已经明确处于车控慢系统确认链路,当前轮可按“多轮策略”继承;没有上文时,不要脑补车载上下文。
|
||||
|
||||
### 慢系统车控类型
|
||||
|
||||
以下车控类型进入慢系统,复杂度给 `complex=true`。其他未命中这些类型、且是明确单设备单动作的车控 query,默认走快系统,给 `complex=false`。
|
||||
|
||||
#### 意向性表达
|
||||
|
||||
用户可能无法说出功能准确名称,但表达了舒适度、主观感受、状态不满或潜在需求意向;没有明确指令“要做什么操作”,需要系统主动推断对应车控动作。
|
||||
|
||||
示例:
|
||||
|
||||
- 我感觉好冷快冻死了,帮我调一下。
|
||||
- 脚底下好冷,腿快冻麻了。
|
||||
- 风一直吹我脸,有点难受。
|
||||
|
||||
判断要点:
|
||||
|
||||
- 必须有车内设备、车内空间、车载功能或上下文线索。
|
||||
- 需要从“冷、热、闷、刺眼、难受、挤、不舒服”等感受推断空调、风向、座椅、车窗、灯光等动作。
|
||||
|
||||
#### 模糊场景表达
|
||||
|
||||
用户只有场景诉求,不知道车上有哪些模式或功能可以达到目标,需要系统把场景拆成车控动作或模式组合。
|
||||
|
||||
示例:
|
||||
|
||||
- 等下要开个会,帮我把车里状态调一下。
|
||||
- 后排宝宝睡着了,把车里调成适合睡觉的状态。
|
||||
- 今天情人节,帮我把车内营造一点节日氛围。
|
||||
|
||||
判断要点:
|
||||
|
||||
- 需要推理出空调、灯光、座椅、车窗、媒体、静音、氛围灯等可能组合。
|
||||
- 如果用户已经明确“打开氛围灯”“关闭阅读灯”这类单动作,不命中本条。
|
||||
|
||||
#### 模糊功能指代
|
||||
|
||||
用户不知道功能名或忘了名称,只能描述功能效果、触发场景或俗称,需要系统识别具体车载功能。
|
||||
|
||||
示例:
|
||||
|
||||
- 停车时自动把车耳朵收起来的功能叫什么,你帮我开一下。
|
||||
- 后视镜反光看不清,有个防反光的功能你帮我调一下。
|
||||
- 那个压线噔噔的声音把它关掉。
|
||||
|
||||
判断要点:
|
||||
|
||||
- 需要把“车耳朵收起来”“防反光”“压线噔噔”等模糊描述映射到后视镜折叠、防眩目、车道偏离提示等功能。
|
||||
- 如果功能名明确且动作明确,例如“打开后视镜防眩目”,通常是 `complex=false`。
|
||||
|
||||
#### 复杂多位置设备推理
|
||||
|
||||
用户表达了设备选择逻辑,需要根据位置、说话人、排除条件或设备集合推理具体控制对象。
|
||||
|
||||
示例:
|
||||
|
||||
- 把我头顶灯以外的灯都关了。
|
||||
- 把除了我这边以外的车窗都关了。
|
||||
|
||||
判断要点:
|
||||
|
||||
- “我这边、头顶、除了、副驾以外、其他”等需要结合车内位置和设备集合推理。
|
||||
- 明确单位置单动作如“关闭主驾车窗”不命中本条。
|
||||
|
||||
#### 口语化纠正和重复表达
|
||||
|
||||
用户表达中出现口吃、重复、临时改口或前后纠正,需要系统消解最终设备和动作。
|
||||
|
||||
示例:
|
||||
|
||||
- 你帮我打开那个那个什么引擎盖。
|
||||
- 你帮我把那个前排阅读灯哦不后排阅读灯打开。
|
||||
|
||||
判断要点:
|
||||
|
||||
- 需要从口语冗余、纠正和模糊指代中恢复最终控制目标。
|
||||
- 简单重复但不影响理解的单动作,可结合实际难度判断;明显需要纠错消解时给 `complex=true`。
|
||||
|
||||
#### 多轮确认继承
|
||||
|
||||
首轮进入慢系统并且系统主动询问用户确认时,次轮用户说确认、取消或继续类意图,默认仍进入慢系统并继承首轮车控任务。
|
||||
|
||||
示例:
|
||||
|
||||
- 首轮:“帮我打开那个适合雨雪天气防路面打滑的模式。”系统询问是否确认开启湿滑模式;次轮:“帮我开启。”次轮给 `complex=true`。
|
||||
- 首轮:“我觉得后排好挤呀帮我调一下。”系统询问是否确认调节座椅位置;次轮:“调一下吧。”次轮给 `complex=true`。
|
||||
|
||||
判断要点:
|
||||
|
||||
- 必须有明确上一轮慢系统车控确认上下文。
|
||||
- 单独看到“帮我开启”“调一下吧”且没有上一轮时,不要凭空判断为车控慢系统。
|
||||
|
||||
#### 控制兜底逻辑
|
||||
|
||||
研发口径待补充。当前只在 query 明确命中上述慢系统类型时给 `complex=true`;未命中时回到“明确单设备单动作走快系统”的原则。
|
||||
|
||||
### 场景编排
|
||||
|
||||
用户描述一个车内场景或目标状态,系统需要组合多个车控动作来完成。
|
||||
|
||||
Reference in New Issue
Block a user