82 lines
2.4 KiB
Markdown
82 lines
2.4 KiB
Markdown
# 工作流
|
||
|
||
## 分支 A:线上候选直接作为数据样本
|
||
|
||
适用表达:
|
||
|
||
- “把筛选出的数据变成样本”
|
||
- “拿线上数据做评测集”
|
||
- “保留这批线上 case”
|
||
- “导出候选样本”
|
||
|
||
流程:
|
||
|
||
1. 分析需求,确认目标标签和复杂度。
|
||
2. 设计 ELK 挖掘策略。
|
||
3. 用 `elk_search_cases.py` 拉候选。
|
||
4. 用 `elk_join_request_logs.py` 补全 main/pre_processing 字段。
|
||
5. 展示小批候选给用户 review。
|
||
6. 用户确认后,优先用 `build_online_records.py` 直接生成 canonical records 和流通表格。
|
||
7. 只有需要人工查看 draft 或混合生成数据时,才用 `build_dataset_draft.py` 转 dataset draft,再接 product-data。
|
||
|
||
这个分支不生成新 query。
|
||
|
||
### rid 快速转样本流程
|
||
|
||
适用表达:
|
||
|
||
- “把这个 rid 的数据拉下来,作为测试数据”
|
||
- “这几个 request_id 转成我们的元数据”
|
||
- “线上命中的这批样本直接导出”
|
||
|
||
流程:
|
||
|
||
1. 整理 `request_ids`、`dataset_label`、`target`、`complex`、时间范围。
|
||
2. 如果用户说“一周内/最近 7 天”,传 `lookback_days: 7`;如果给起止日期,传 `date_from/date_to`;如果只给某一天,传 `date`。
|
||
3. 调用 `build_online_records.py`。
|
||
4. 检查返回的 `summaries`:
|
||
- `query`
|
||
- `target`
|
||
- `target_source`
|
||
- `prev_session_count`
|
||
- `main_domain`
|
||
- `planning_result`
|
||
5. 告诉用户输出路径:
|
||
- `output/records.jsonl`
|
||
- `output/records.csv`
|
||
- 用户要求训练/评测时,再导出 `training.jsonl` / `eval_planning.csv`
|
||
|
||
`prev_session` 以前处理 `promptModel` 的 `[对话历史]` 为准。不要用主表 `session_id`
|
||
重建模型输入历史;它更适合排查同设备/同链路日志,不适合作为训练/评测 prompt 历史。
|
||
|
||
## 分支 B:基于线上问题补充生成数据
|
||
|
||
适用表达:
|
||
|
||
- “基于这些 badcase 再生成一批”
|
||
- “扩写类似 case”
|
||
- “构造训练数据”
|
||
|
||
流程:
|
||
|
||
1. 先完成分支 A 的线上问题定位和 review。
|
||
2. 总结线上错误模式、边界和负例。
|
||
3. 切到 `product-data` 的 generation goal / generation plan。
|
||
4. 用户确认计划后再生成新数据。
|
||
|
||
## review 展示建议
|
||
|
||
每条候选优先展示:
|
||
|
||
```text
|
||
request_id:
|
||
query:
|
||
planning_result:
|
||
main.domain / main.func:
|
||
candidate_domains:
|
||
session_id / device_id:
|
||
tts:
|
||
```
|
||
|
||
不要默认展示完整 prompt。prompt 很长时只展示命中片段。
|