Refine label complexity knowledge
This commit is contained in:
@@ -61,8 +61,9 @@ complex 是复杂度判断,独立于业务标签。它可以先粗判,但建
|
||||
|
||||
- `判断维度/复杂度/复杂度判断.md`
|
||||
- 如果 query 涉及地图导航、POI 搜索、路线偏好、终点附近、沿途、顺路或多轮路线约束,继续读取 `判断维度/复杂度/地图导航.md`。这是 complex 维度下的专项条件表,不是新的结构维度;最终仍只输出 `complex=false/true`。
|
||||
- 如果 query 涉及车控、IoT 设备控制、生活服务、系统控制、应用控制、图片问答、媒体资源播放,并出现感受/场景/约束/跨应用/视觉推理/模糊资源推断等复杂样式,继续读取 `判断维度/复杂度/垂域专项.md`。这是 complex 维度下的专项条件表,不是新的结构维度;最终仍只输出 `complex=false/true`。
|
||||
- 如果专项条件依赖多轮上下文,必须先确认输入里是否真的提供了上一轮导航上下文;没有上下文时,不要把单轮完整 query 当作多轮次轮。
|
||||
- 多轮场景里,如果当前轮只是路线选择或路线偏好,需要先看上一轮导航任务的 complex 结果;上一轮为 `complex=true` 时当前轮继承为 `complex=true`,否则不要只凭路线选择给 true。
|
||||
- 多轮场景里,如果当前轮判断依赖上一轮任务,需要先看上一轮任务的 complex 结果;专项规则明确要求继承时才继承,不要默认所有多轮都继承。
|
||||
|
||||
## 3. 业务标签候选
|
||||
|
||||
|
||||
@@ -32,6 +32,21 @@
|
||||
- 多轮里的单独路线选择,例如“不要走高速”“走国道”“别走收费路”,当前轮不能单独作为 `complex=true` 判断依据;如果上一轮导航任务已经是 `complex=true`,则当前轮继承为 `complex=true`,否则默认 `complex=false`。
|
||||
- 如果输入里没有提供上一轮导航上下文,不要假设它是多轮次轮;应按单轮完整 query 处理。
|
||||
|
||||
## 判断次序
|
||||
|
||||
地图导航场景按下面顺序判断,越靠前优先级越高:
|
||||
|
||||
1. **确认是否有上一轮导航上下文**:如果没有上一轮,当前 query 按单轮判断。
|
||||
2. **单轮多步骤优先判断**:当前 query 同时出现主目的地和途经点、沿途点、中间点,给 `complex=true`。
|
||||
3. **单轮目标 + 路线选择优先判断**:当前 query 同时出现主目的地和路线选择、路线偏好、避让条件,给 `complex=true`。
|
||||
4. **多轮继承判断**:当前轮只是路线选择或路线偏好时,先看上一轮 complex;上一轮为 `complex=true` 则继承为 `complex=true`,否则默认 `complex=false`。
|
||||
5. **多轮短链路追加判断**:上一轮已有导航路线,当前轮只是追加沿途、顺路、中间找点,且上一轮不是 `complex=true`,给 `complex=false`。
|
||||
6. **单 POI 简单筛选判断**:目标是单 POI,只有简单距离、设施、排序、营业状态等条件,给 `complex=false`。
|
||||
7. **复杂筛选和综合推荐判断**:需要评价、避坑、冷门热门、排队、人流、外部事实验证或多候选比较,给 `complex=true`。
|
||||
8. **改口纠错判断**:单 POI 改口、取消、纠错、模糊补全,不因口语混乱升为 `complex=true`。
|
||||
|
||||
如果某条 query 同时命中多个条件,按上述顺序取优先级更高的判断。
|
||||
|
||||
## complex=false
|
||||
|
||||
以下类型默认 `complex=false`。
|
||||
|
||||
@@ -0,0 +1,219 @@
|
||||
# 垂域专项复杂度判断
|
||||
|
||||
本文件是 [复杂度判断](复杂度判断.md) 的专项条件表,父维度是 `complex` / 复杂度判断。
|
||||
|
||||
它用于沉淀不同垂域里“看起来不是简单一步执行”的复杂样式。命中本文件的复杂样式时,可以给 `complex=true`;没有命中时,不要强行升级复杂度,回到通用复杂度策略判断。
|
||||
|
||||
## 使用原则
|
||||
|
||||
- 本文件只补充 `complex=true` 的垂域专项信号,不替代业务标签判断。
|
||||
- 不要因为 query 属于某个垂域就直接给 `complex=true`,必须命中具体复杂样式。
|
||||
- 如果 query 是明确的一步控制、一步查询、一步播放、一步打开应用,通常仍按 `complex=false` 判断。
|
||||
- 如果 query 同时涉及多指令、自动任务或输出形态,仍需分别读取对应维度文件,不要把多个维度混成一个结论。
|
||||
|
||||
## 判断次序
|
||||
|
||||
1. **先判断垂域**:确认 query 属于车控、IoT 设备、生活服务、系统控制、应用控制、图片问答或媒体播放等场景。
|
||||
2. **再看复杂样式**:是否需要场景编排、意向理解、设备推理、功能组合、风险判断、推荐筛选、跨应用操作、视觉推理或资源推断。
|
||||
3. **确认是否必须推理落地**:如果用户只表达感受、场景或约束,系统需要推理出具体动作、候选对象或执行方案,通常是 `complex=true`。
|
||||
4. **排除简单直达**:如果用户已经明确给出单一设备、单一动作、单一资源、单一 App 或单一查询目标,且不需要综合判断,回到通用 `complex=false`。
|
||||
5. **未覆盖则回退**:本文件未覆盖的场景,继续使用 [复杂度判断](复杂度判断.md) 的通用策略。
|
||||
|
||||
## 复杂车控
|
||||
|
||||
针对车内空调、车窗、座椅、灯光、驾驶相关设置等车控能力,以下类型可以给 `complex=true`。
|
||||
|
||||
### 场景编排
|
||||
|
||||
用户描述一个车内场景或目标状态,系统需要组合多个车控动作来完成。
|
||||
|
||||
示例:
|
||||
|
||||
- 等下要开个会,帮我把车里状态调一下。
|
||||
- 一会儿有人上车,帮我把车内环境整理舒服点。
|
||||
|
||||
判断要点:
|
||||
|
||||
- 用户没有直接列出具体动作,而是给出场景目标。
|
||||
- 需要推理出空调、车窗、座椅、灯光、媒体、静音等可能的组合动作。
|
||||
|
||||
### 意向理解
|
||||
|
||||
用户用感受表达需求,系统必须落到具体车控意图。
|
||||
|
||||
示例:
|
||||
|
||||
- 车里有点闷,我想透透气。
|
||||
- 后排坐着不太舒服,帮我调整一下。
|
||||
|
||||
判断要点:
|
||||
|
||||
- “闷、热、冷、刺眼、不舒服”等感受本身不是具体控制动作。
|
||||
- 如果需要推断打开车窗、调空调、调座椅、调灯光等具体动作,给 `complex=true`。
|
||||
|
||||
### 设备推理
|
||||
|
||||
用户用相对位置、排除条件或隐含设备集合描述控制目标,系统需要推理出具体设备。
|
||||
|
||||
示例:
|
||||
|
||||
- 把除了我这边以外的车窗都关了。
|
||||
- 除了副驾,其他座椅加热都关掉。
|
||||
|
||||
判断要点:
|
||||
|
||||
- 需要根据说话人位置、车内座位、设备集合或排除条件推理控制对象。
|
||||
- 如果只是“关闭主驾车窗”这类明确单设备单动作,不命中本条。
|
||||
|
||||
## 复杂设备控制
|
||||
|
||||
针对空调、灯光、摄像头、扫地机、传感器等 IoT 设备,以下类型可以给 `complex=true`。
|
||||
|
||||
### 功能组合
|
||||
|
||||
用户描述家居状态或环境目标,系统需要组合多个设备能力。
|
||||
|
||||
示例:
|
||||
|
||||
- 南向房间又热又干,帮我调一下。
|
||||
- 客厅有点暗还闷,帮我弄舒服点。
|
||||
|
||||
判断要点:
|
||||
|
||||
- 需要同时考虑空调、加湿器、窗帘、灯光、新风等多个设备或功能。
|
||||
- 如果只是“打开客厅空调”这类单设备动作,回到通用判断。
|
||||
|
||||
### 状态查询
|
||||
|
||||
用户要求系统基于多个设备状态做风险、异常或整体状态判断。
|
||||
|
||||
示例:
|
||||
|
||||
- 我计划出差,家里有啥设备有安全风险吗。
|
||||
- 睡觉前帮我看看家里有没有什么不该开着的设备。
|
||||
|
||||
判断要点:
|
||||
|
||||
- 不是查询单个设备状态,而是需要遍历、归纳或判断多个设备状态。
|
||||
- 涉及安全风险、异常状态、整体巡检时,可以给 `complex=true`。
|
||||
|
||||
### 查询 + 控制混合
|
||||
|
||||
用户先要求查询环境或设备状态,再要求根据结果调整设备。
|
||||
|
||||
示例:
|
||||
|
||||
- 屋内空气怎么样,帮我调整下。
|
||||
- 看看卧室温湿度,如果不舒服就处理一下。
|
||||
|
||||
判断要点:
|
||||
|
||||
- 需要先获取状态,再决定控制动作。
|
||||
- 如果 query 明确拆成多个可独立动作,还需要另行判断多指令维度。
|
||||
|
||||
## 复杂生活服务
|
||||
|
||||
主要涉及餐饮、旅游、酒店、出行服务等生活垂域,以下类型可以给 `complex=true`。
|
||||
|
||||
### 条件筛选 / 推荐
|
||||
|
||||
用户不是简单查找一个对象,而是要求根据偏好、氛围、避坑、体验、约束做推荐。
|
||||
|
||||
示例:
|
||||
|
||||
- 想找个安静点、适合聊天的餐厅,别太吵。
|
||||
- 想找一家适合带老人吃饭的店,环境好一点,别排太久。
|
||||
|
||||
判断要点:
|
||||
|
||||
- “安静、适合聊天、别太吵、别踩雷、适合老人/孩子”等通常需要评价和体验判断。
|
||||
- 如果只是“附近餐厅”“附近最近的酒店”这类简单检索,回到通用判断。
|
||||
|
||||
### 生活垂域组合
|
||||
|
||||
用户把多个生活服务目标组合成一个整体计划。
|
||||
|
||||
示例:
|
||||
|
||||
- 想去海边待两天,住得安静点,周围吃的也别太差。
|
||||
- 周末想带孩子出去玩一天,别太累,吃饭停车都方便点。
|
||||
|
||||
判断要点:
|
||||
|
||||
- 需要综合地点、住宿、餐饮、游玩、交通、时间等多个因素。
|
||||
- 如果需要形成行程、候选比较或方案推荐,给 `complex=true`。
|
||||
|
||||
## 复杂系统控制
|
||||
|
||||
系统控制包括亮度、字体、省电、音量、通知、显示、网络、权限等系统级能力。以下类型可以给 `complex=true`。
|
||||
|
||||
### 场景 / 感受 / 约束驱动的系统操作
|
||||
|
||||
用户没有直接说具体设置项,而是描述问题或目标,系统需要推理出系统级操作。
|
||||
|
||||
示例:
|
||||
|
||||
- 手机字太小图标也小,总是点错,请整理一下。
|
||||
- 手机快没电了但一直要导航,帮我把其他耗电的都处理掉。
|
||||
|
||||
判断要点:
|
||||
|
||||
- 需要把“点错、省电、看不清、太吵、打扰”等问题映射为字体、图标、亮度、省电、后台、通知、音量等设置。
|
||||
- 如果只是“把亮度调到 50%”“打开省电模式”,通常是 `complex=false`。
|
||||
|
||||
## 复杂应用控制
|
||||
|
||||
应用控制中,以下类型可以给 `complex=true`。
|
||||
|
||||
### 跨应用操作
|
||||
|
||||
query 涉及 2 个及以上 App,需要在不同应用之间传递内容、截图、分享或继续操作。
|
||||
|
||||
示例:
|
||||
|
||||
- QQ音乐里最近单曲循环的这首歌帮我分享到微信朋友圈让朋友们也听听。
|
||||
- 支付宝里基金涨了,帮我截图发到微信让我爸也看看收益。
|
||||
|
||||
判断要点:
|
||||
|
||||
- 需要从一个 App 获取内容,再到另一个 App 执行动作。
|
||||
- 涉及内容选择、截图、分享对象、发布渠道等步骤时,给 `complex=true`。
|
||||
- 单独“打开微信”“QQ音乐搜索刘德华”不命中本条。
|
||||
|
||||
## 复杂图片问答
|
||||
|
||||
图片问答中,以下类型可以给 `complex=true`。
|
||||
|
||||
### 视觉理解 + 后续推理 / 执行
|
||||
|
||||
用户要求先理解图片、屏幕或前方环境,再做知识问答、路线规划、控制执行或风险判断。
|
||||
|
||||
示例:
|
||||
|
||||
- 前面那辆白色的车挂的哪里的牌?是哪个城市的?那个城市有什么好玩的地方,下次放假想去转转,帮我做个两天的攻略。
|
||||
- 帮我看下这个标牌上写的什么,是不是限速的?现在我开多少了,有没有超速?如果超了帮我把巡航速度调下来。
|
||||
|
||||
判断要点:
|
||||
|
||||
- 需要先从视觉信息中识别对象、文字、场景或状态。
|
||||
- 识别后还要继续问答、规划、比较或执行控制时,给 `complex=true`。
|
||||
- 单纯“这是什么”“描述一下这张图”可以按通用策略判断,不一定命中复杂。
|
||||
|
||||
## 复杂媒体资源播放
|
||||
|
||||
媒体资源包括音乐、视频、电台、有声内容等。以下类型可以给 `complex=true`。
|
||||
|
||||
### 模糊感受 / 情境 / 碎片记忆驱动的资源推断
|
||||
|
||||
用户没有给出明确资源名,而是用感受、场景、碎片歌词、模糊记忆描述内容需求,需要系统推断资源并播放。
|
||||
|
||||
示例:
|
||||
|
||||
- 我想听一首以前特别火的伤感中文歌,男声唱的,副歌我会唱但现在一下想不起名字了,你先放几首最可能的给我。
|
||||
- 先来一个适合今天这种阴天听的歌单,不要太丧,也别太闹腾,如果后面推荐越来越伤感,就帮我切到轻一点的民谣。
|
||||
|
||||
判断要点:
|
||||
|
||||
- 需要根据模糊描述召回、筛选或动态调整资源。
|
||||
- 用户要求“先放几首最可能的”“根据后续反馈调整”时,通常是多步骤推荐与播放,给 `complex=true`。
|
||||
- 明确“播放周杰伦晴天”“下一首”“暂停播放”不命中本条。
|
||||
@@ -21,12 +21,32 @@ complex 维度是独立维度,不属于业务标签本身。业务标签负责
|
||||
- 需要制定计划、比较多方案、总结长文本、生成复杂内容、连续推理通常是 `complex=true`。
|
||||
- 当复杂度边界和业务标签边界同时存在歧义时,先分别判断,再说明组合结果。
|
||||
|
||||
## 判断流程
|
||||
|
||||
进行复杂度判断时,按下面顺序推进,不要直接凭某个关键词下结论:
|
||||
|
||||
1. **确认输入形态**:当前 query 是单轮完整请求,还是依赖上一轮上下文的多轮续写;如果没有提供上一轮,不要假设存在上一轮。
|
||||
2. **确认业务场景**:先粗判 query 涉及哪个领域,例如地图导航、文档总结、数据生成、问答、控制等;业务场景只用于选择专项条件表,不直接决定 complex。
|
||||
3. **先看强 `complex=true` 信号**:是否需要规划、比较多方案、跨信息源综合、主观评价、外部事实验证、多个步骤组合。
|
||||
4. **再看强 `complex=false` 信号**:是否是原子化的一步执行、一步查询、一步控制、单一可直接满足的导航或检索。
|
||||
5. **读取专项条件表**:如果命中特定业务场景,继续读取该场景的专项条件表;专项条件优先于通用经验。
|
||||
6. **处理多轮继承**:如果专项规则依赖上一轮结果,必须明确上一轮的任务和 complex 判断;没有上一轮结果时,不做继承。
|
||||
7. **输出判断依据**:最终只输出 `complex=false` 或 `complex=true`,同时说明命中的通用条件或专项条件。
|
||||
|
||||
## 冲突处理
|
||||
|
||||
- 明确命中专项 `complex=true` 条件时,不要被“单 POI”“一步导航”“简单关键词”等泛化经验覆盖。
|
||||
- 明确命中专项 `complex=false` 条件时,不要因为业务标签看起来复杂就升为 `complex=true`。
|
||||
- 多轮场景里,当前轮是否继承上一轮复杂度,必须由专项条件表定义;不要默认所有多轮都继承。
|
||||
- 无法确认上下文时,按当前 query 自身可见信息判断,并在结果里说明缺少上下文。
|
||||
|
||||
## 判断条件组织
|
||||
|
||||
| 条件层级 | 使用场景 | 读取文件 |
|
||||
| --- | --- | --- |
|
||||
| 通用条件 | 所有 query 的基础复杂度判断 | 本文件 |
|
||||
| 地图导航专项条件 | query 涉及导航、路线规划、POI 搜索、终点附近、沿途、顺路、路线偏好、单 POI 筛选或多轮路线约束 | [地图导航复杂度判断](地图导航.md) |
|
||||
| 垂域专项条件 | query 涉及车控、IoT 设备控制、生活服务、系统控制、应用控制、图片问答、媒体资源播放,并出现感受/场景/约束/跨应用/视觉推理/模糊资源推断等复杂样式 | [垂域专项复杂度判断](垂域专项.md) |
|
||||
|
||||
使用方式:
|
||||
|
||||
|
||||
@@ -227,6 +227,10 @@
|
||||
"parent_dimension": "`complex` / 复杂度判断。",
|
||||
"path": "knowledge/判断维度/复杂度/地图导航.md"
|
||||
},
|
||||
{
|
||||
"name": "垂域专项复杂度判断",
|
||||
"path": "knowledge/判断维度/复杂度/垂域专项.md"
|
||||
},
|
||||
{
|
||||
"name": "复杂度判断",
|
||||
"path": "knowledge/判断维度/复杂度/复杂度判断.md"
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
| 维度 | 何时读取 | 文件 |
|
||||
| --- | --- | --- |
|
||||
| 标注输出形态 | 需要生成训练/评测 target,或卡片中同时存在旧 tag 与 Function 定义时 | [标注输出形态](../判断维度/标注输出形态.md),并继续读取 [输出能力](../输出能力/README.md) |
|
||||
| 复杂度判断 | 需要判断 complex 维度,或 query 可能需要规划、推理、多步骤处理时;如果 query 涉及导航、路线规划、POI 搜索、终点附近、沿途、顺路、路线偏好、单 POI 筛选或多轮路线约束,先读复杂度总规则,再继续读其专项条件表 | [复杂度判断](../判断维度/复杂度/复杂度判断.md),[地图导航复杂度判断](../判断维度/复杂度/地图导航.md) |
|
||||
| 复杂度判断 | 需要判断 complex 维度,或 query 可能需要规划、推理、多步骤处理时;如果 query 涉及导航、路线规划、POI 搜索、终点附近、沿途、顺路、路线偏好、单 POI 筛选或多轮路线约束,先读复杂度总规则,再继续读地图导航专项条件表;如果 query 涉及车控、IoT 设备控制、生活服务、系统控制、应用控制、图片问答、媒体资源播放,并出现感受/场景/约束/跨应用/视觉推理/模糊资源推断等复杂样式,继续读垂域专项条件表 | [复杂度判断](../判断维度/复杂度/复杂度判断.md),[地图导航复杂度判断](../判断维度/复杂度/地图导航.md),[垂域专项复杂度判断](../判断维度/复杂度/垂域专项.md) |
|
||||
| 多指令判断 | query 包含多个动作、并列连接、多个设备/位置/方向,或需要拆分 subquery 时 | [多指令判断](../判断维度/多指令判断.md) |
|
||||
| 自动任务判断 | query 包含“当/如果/时候/之后/到达/每/一...就”等条件触发结构,或涉及超级任务/提醒/自动化时 | [自动任务判断](../判断维度/自动任务判断.md) |
|
||||
|
||||
@@ -14,5 +14,5 @@
|
||||
1. 先读 `决策流程.md`,判断是否需要结构维度。
|
||||
2. 如果只是普通标签边界,不一定读取维度文件。
|
||||
3. 如果 query 结构复杂,按需读取 `复杂度/复杂度判断.md`、`多指令判断.md`、`自动任务判断.md`。
|
||||
4. 如果读取 `复杂度/复杂度判断.md` 后发现 query 属于某个专项场景,例如地图导航/POI/路线偏好,再读取该维度下的专项条件表;专项条件表不产生新的维度字段。
|
||||
4. 如果读取 `复杂度/复杂度判断.md` 后发现 query 属于某个专项场景,例如地图导航/POI/路线偏好,或车控/IoT/生活服务/系统控制/应用控制/图片问答/媒体播放的复杂样式,再读取该维度下的专项条件表;专项条件表不产生新的维度字段。
|
||||
5. 如果要写最终 target,必须读取 `标注输出形态.md` 和 `输出能力/输出组合规范.md`。
|
||||
|
||||
Reference in New Issue
Block a user