Add local analysis and workspace docs
This commit is contained in:
武阳
@@ -0,0 +1,553 @@
|
||||
文档结构
|
||||
1. 数据迭代Agent架构
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- 1-2周MVP方案
|
||||
- badcase反馈渠道接入、自动收集分析
|
||||
|
||||
- 1-2周MVP方案
|
||||
1. 定义一个最小的任务流程，整理流程中AI需要具备的能力
|
||||
- 工具
|
||||
- 记忆
|
||||
- 环境
|
||||
- 技术选型
|
||||
|
||||
Badcase 反馈渠道接入与自动收集分析:数据挖掘Agent设计方案
|
||||
|
||||
Router Data Agent Workbench 方案文档
|
||||
1. 背景
|
||||
当前快慢系统路由的数据开发流程，主要围绕以下任务展开：
|
||||
- 分析需求 / badcase
|
||||
- 明确快慢系统边界
|
||||
- 构建评测集
|
||||
- 构建训练集
|
||||
- 挖掘线上样本
|
||||
- 人工标注与复核
|
||||
- 模型训练与回放评估
|
||||
- 根据结果继续补齐数据
|
||||
现有流程本质上仍然是 人驱动的数据开发
|
||||
人理解需求
|
||||
→ 人拆解边界
|
||||
→ 人写 prompt / 规则
|
||||
→ 人捞数据
|
||||
→ 人筛样本
|
||||
→ 人整理评测集
|
||||
→ 人分析模型问题
|
||||
→ 人沉淀经验
|
||||
这个流程可以用 AI 做局部提效，但如果只是把每一步变成一个 LLM 节点，本质上仍然是旧框架。
|
||||
本项目希望重构的不是某几个节点，而是整个数据开发范式。
|
||||
|
||||
---
|
||||
1.1 业务尝试：快慢系统评测集构建
|
||||
当前路由标签空间包括：
|
||||
FAST_DIRECT
|
||||
SLOW_FILTER_RANK
|
||||
SLOW_DISAMBIGUATE
|
||||
SLOW_GOAL_STATE
|
||||
SLOW_WORKFLOW
|
||||
SLOW_CONTEXT_DEPENDENT
|
||||
SLOW_UNCLEAR
|
||||
SLOW_ADVANCED_CAPABILITY
|
||||
这些标签不是普通分类标签，而是路由系统的 能力边界定义。
|
||||
评测集构建的核心目标也不是简单判断 fast / slow，而是判断：
|
||||
这个请求为什么复杂？
|
||||
complexity reason 是什么？
|
||||
例如：
|
||||
导航到附近停车场
|
||||
→ FAST_DIRECT
|
||||
|
||||
导航到附近最大的停车场
|
||||
→ SLOW_FILTER_RANK
|
||||
真正困难的不是打标签本身，而是持续维护这些边界：
|
||||
- 哪些请求快系统可以稳定承接？
|
||||
- 哪些请求必须交给慢系统？
|
||||
- 哪些 case 是边界混淆？
|
||||
- 哪些标签定义不清？
|
||||
- 哪些线上 badcase 暴露了新的边界问题？
|
||||
- 哪些模型错误值得转成训练集 / 评测集？
|
||||
2. 数据迭代Agent架构
|
||||
建设一个面向快慢路由系统的数据开发 Agent 环境：Router Data Agent Workbench
|
||||
它的目标是：
|
||||
让 Agent 能够围绕一个需求 / badcase，自主理解问题、探索数据、发现边界冲突、提出人工裁决问题、生成评测集候选、沉淀长期经验，从而显著提升路由评测 / 训练数据构建效率。
|
||||
目标不是做一个固定流程平台，而是做一个 Agent-native 的数据开发工作台。
|
||||
|
||||
---
|
||||
2.1 Agent定位
|
||||
- 不做传统 workflow+LLM节点提效
|
||||
[图片]
|
||||
2.1.1 不做传统 workflow
|
||||
不采用这种模式：
|
||||
需求理解节点
|
||||
→ 边界分析节点
|
||||
→ 样本挖掘节点
|
||||
→ 预打标节点
|
||||
→ 人工审核节点
|
||||
→ 评测集生成节点
|
||||
这种方式的问题是：
|
||||
- 还是人预先设计流程
|
||||
- LLM 只是填充节点
|
||||
- Agent 没有真正自主决策
|
||||
- 新问题仍然需要人调整流程 / prompt
|
||||
- 长期价值有限
|
||||
这不是 AI 原生，而是旧流程自动化。
|
||||
|
||||
---
|
||||
2.1.2 做 Agent-native workbench
|
||||
目标模式是：
|
||||
给 Agent 一个目标、工作区、资料、工具、经验、权限和评价标准；
|
||||
Agent 自己决定下一步做什么；
|
||||
系统负责提供环境、边界、记录、校验和人工裁决入口。
|
||||
核心区别：
|
||||
传统 Workflow
|
||||
Agent-native Workbench
|
||||
人提前画流程
|
||||
Agent 根据任务自主推进
|
||||
LLM 填节点
|
||||
Agent 自己选择资料、工具和行动
|
||||
prompt 是核心
|
||||
workspace / skills / memory / tools 是核心
|
||||
人负责执行大量步骤
|
||||
人只负责关键业务裁决
|
||||
每次任务从头开始
|
||||
经验持续沉淀，下一次复用
|
||||
输出一个结果
|
||||
输出结果 + 过程 + 经验 + 可复用资产
|
||||
|
||||
---
|
||||
2.2 系统定位
|
||||
Router Data Agent Workbench 应该承担以下职责：
|
||||
输入：
|
||||
- 需求文档
|
||||
- badcase
|
||||
- 线上 session
|
||||
- 当前标签定义
|
||||
- 历史评测集
|
||||
- 模型预测结果
|
||||
- 人工裁决记录
|
||||
|
||||
输出：
|
||||
- 边界分析
|
||||
- open questions
|
||||
- 人工裁决问题
|
||||
- 候选样本池
|
||||
- 标注任务
|
||||
- 专项评测集候选
|
||||
- 训练集候选
|
||||
- 回放评估报告
|
||||
- 标签定义修订建议
|
||||
- 可复用经验
|
||||
它不是一个“评测集生成器”，而是一个 路由数据开发 Agent 工作环境。
|
||||
|
||||
---
|
||||
2.3 核心架构
|
||||
Router Data Agent Workbench 由 6 个核心要素组成：
|
||||
- Workspace：任务工作区
|
||||
- Skills：领域经验包
|
||||
- Tools：可执行工具
|
||||
- Memory：Agent 外部认知状态
|
||||
- Policy：权限与人工裁决边界
|
||||
[图片]
|
||||
|
||||
---
|
||||
2.4 Workspace：任务工作区
|
||||
每个需求 / badcase 启动后，系统创建一个独立 workspace。
|
||||
示例结构：
|
||||
[图片]
|
||||
Workspace 的作用：
|
||||
- 承载任务上下文
|
||||
- 记录 Agent 中间理解
|
||||
- 保存探索过程
|
||||
- 支持人机协作
|
||||
- 沉淀可复用经验
|
||||
- 保证过程可追溯
|
||||
Agent 不是在一个固定流程里跑，而是在 workspace 中像研究员一样工作。
|
||||
|
||||
---
|
||||
2.5 MD First：以 Markdown 作为 Agent 工作语言
|
||||
[图片]
|
||||
Agent 工作过程优先使用 Markdown
|
||||
适合用 Markdown 的内容：
|
||||
需求理解
|
||||
边界分析
|
||||
open questions
|
||||
人工裁决记录
|
||||
挖掘策略
|
||||
失败尝试
|
||||
经验总结
|
||||
效果报告
|
||||
标签定义说明
|
||||
原因：
|
||||
- MD 更适合人读
|
||||
- MD 更适合 Agent 自然读写
|
||||
- MD 更适合沉淀讨论和判断过程
|
||||
- MD 更接近真实工作台，而不是状态机
|
||||
但不是完全不要结构化。
|
||||
原则是：
|
||||
MD 是 Agent 的工作语言；
|
||||
JSONL / CSV / DB 是数据资产的交换格式。
|
||||
也就是：
|
||||
内容
|
||||
推荐格式
|
||||
需求理解
|
||||
MD
|
||||
边界分析
|
||||
MD
|
||||
人工裁决
|
||||
MD
|
||||
经验沉淀
|
||||
MD
|
||||
候选样本池
|
||||
CSV / JSONL
|
||||
评测集
|
||||
JSONL
|
||||
训练集
|
||||
JSONL
|
||||
回放结果
|
||||
表格 + MD 报告
|
||||
工具调用参数
|
||||
schema / JSON
|
||||
最终原则：
|
||||
Agent 工作过程 MD first；
|
||||
系统边界 schema when needed。
|
||||
|
||||
---
|
||||
2.6 Skills：领域经验包，而不是流程节点
|
||||
[图片]
|
||||
Skills 不应该被设计成固定节点。
|
||||
错误理解：
|
||||
Skill 1：需求理解
|
||||
Skill 2：边界分析
|
||||
Skill 3：数据挖掘
|
||||
Skill 4：预打标
|
||||
Skill 5：评测生成
|
||||
这还是 workflow。
|
||||
正确理解：
|
||||
Skill 是 Agent 可发现、可按需加载、可组合的领域经验包。
|
||||
示例：
|
||||
/skills/
|
||||
router-label-boundary/
|
||||
SKILL.md
|
||||
examples.md
|
||||
known-confusions.md
|
||||
decision-principles.md
|
||||
|
||||
online-session-mining/
|
||||
SKILL.md
|
||||
query-patterns.md
|
||||
sampling-strategies.md
|
||||
badcase-mining.md
|
||||
|
||||
eval-set-construction/
|
||||
SKILL.md
|
||||
golden-set-rules.md
|
||||
boundary-set-rules.md
|
||||
anti-patterns.md
|
||||
|
||||
active-learning-router/
|
||||
SKILL.md
|
||||
disagreement-mining.md
|
||||
hard-negative-mining.md
|
||||
recall-gap-analysis.md
|
||||
Agent 在运行中根据问题自主选择是否读取某个 skill。
|
||||
例如：
|
||||
发现 FAST_DIRECT 和 SLOW_FILTER_RANK 边界不清
|
||||
→ 读取 router-label-boundary skill
|
||||
|
||||
需要从线上 session 挖相关样本
|
||||
→ 读取 online-session-mining skill
|
||||
|
||||
发现模型离线准确率高但线上效果差
|
||||
→ 读取 active-learning-router skill
|
||||
Skill 的价值不是定义流程，而是沉淀经验。
|
||||
|
||||
---
|
||||
2.7 Resources：可检索资料
|
||||
Resources 是 Agent 可读取的业务上下文。
|
||||
包括：
|
||||
当前标签定义
|
||||
历史标签定义版本
|
||||
历史 badcase
|
||||
历史人工裁决
|
||||
已有评测集
|
||||
已有训练集
|
||||
线上 session 索引
|
||||
topquery 集合
|
||||
模型预测结果
|
||||
模型误判样本
|
||||
历史回放报告
|
||||
Agent 不应该一次性把所有资料塞进上下文。
|
||||
更合理的方式是：
|
||||
Agent 先读任务目标
|
||||
→ 判断需要什么资料
|
||||
→ 按需检索相关资源
|
||||
→ 只把当前需要的内容纳入上下文
|
||||
这样可以避免上下文污染，也能让 Agent 更像真实研究员一样探索。
|
||||
|
||||
---
|
||||
2.8 Tools：可执行能力
|
||||
Tools 是 Agent 可以调用的实际能力。
|
||||
示例：
|
||||
search_online_sessions()
|
||||
sample_top_queries()
|
||||
find_similar_cases()
|
||||
mine_by_pattern()
|
||||
mine_by_embedding()
|
||||
mine_by_model_disagreement()
|
||||
cluster_and_dedup()
|
||||
run_router_eval()
|
||||
run_online_replay()
|
||||
create_annotation_queue()
|
||||
read_human_review_result()
|
||||
train_router_model()
|
||||
compare_model_versions()
|
||||
Agent 不应该直接写复杂 SQL 或手工操作数据表。
|
||||
系统应该提供稳定、可控、可审计的工具接口。
|
||||
Agent 自己决定：
|
||||
什么时候查线上 session
|
||||
什么时候找历史裁决
|
||||
什么时候跑模型分歧
|
||||
什么时候构造混淆样本
|
||||
什么时候创建标注任务
|
||||
什么时候请求人工裁决
|
||||
|
||||
---
|
||||
2.9 Memory：Agent 外部认知状态
|
||||
Memory 不是简单存几个结构化字段。
|
||||
错误理解：
|
||||
{
|
||||
"status": "running",
|
||||
"target_label": "SLOW_FILTER_RANK"
|
||||
}
|
||||
正确理解：
|
||||
Memory 是 Agent 为了完成长期任务而主动维护的外部认知状态。
|
||||
建议形式：
|
||||
memory/current_understanding.md
|
||||
memory/open_questions.md
|
||||
memory/human_decisions.md
|
||||
memory/failed_attempts.md
|
||||
memory/reusable_lessons.md
|
||||
其中：
|
||||
current_understanding.md
|
||||
记录 Agent 当前对任务的理解。
|
||||
open_questions.md
|
||||
记录尚未解决的边界问题。
|
||||
human_decisions.md
|
||||
记录人工裁决及其理由。
|
||||
failed_attempts.md
|
||||
记录无效挖掘策略，避免重复踩坑。
|
||||
reusable_lessons.md
|
||||
记录可复用经验，供后续任务调用。
|
||||
长期看，系统要沉淀：
|
||||
哪些标签容易混淆
|
||||
哪些边界已有裁决
|
||||
哪些挖掘策略有效
|
||||
哪些关键词误伤高
|
||||
哪些样本适合评测集
|
||||
哪些样本只适合训练集
|
||||
哪些模型错误模式反复出现
|
||||
判断系统是否真正 Agent-native 的关键标准之一：
|
||||
下一次遇到类似问题，Agent 是否明显更聪明。
|
||||
|
||||
---
|
||||
2.10 Policy：权限与人工裁决边界
|
||||
[图片]
|
||||
Agent 可以自主推进任务，但不能无限自由。
|
||||
需要明确哪些事情 Agent 可以自动做，哪些必须人类确认。
|
||||
暂时无法在小米办公Pro文档外展示此内容
|
||||
核心原则：
|
||||
Agent 负责探索和建议；
|
||||
人负责业务边界裁决。
|
||||
|
||||
---
|
||||
3. 人的角色
|
||||
人不再是流程执行者。
|
||||
人不应该做：
|
||||
手写 prompt
|
||||
手动拼关键词
|
||||
手动捞数据
|
||||
手动合并 Excel
|
||||
大量刷 easy case
|
||||
手动维护所有边界记忆
|
||||
人应该做：
|
||||
裁决业务边界
|
||||
确认标签定义变更
|
||||
审核 golden set 入库
|
||||
处理高分歧样本
|
||||
处理高流量低置信样本
|
||||
确认模型回放结论
|
||||
一句话：
|
||||
人是边界裁判，不是数据流水线工人。
|
||||
|
||||
---
|
||||
4. Agent 应该如何向人提问
|
||||
Agent 不应该问：
|
||||
下一步怎么办？
|
||||
而应该提出可裁决问题。
|
||||
示例：
|
||||
边界裁决问题：
|
||||
|
||||
“导航到最近的停车场”应该标为 FAST_DIRECT 还是 SLOW_FILTER_RANK？
|
||||
|
||||
候选判断：
|
||||
|
||||
A. FAST_DIRECT
|
||||
理由：最近可以视为导航系统默认距离排序，快系统可以直接执行。
|
||||
|
||||
B. SLOW_FILTER_RANK
|
||||
理由：最近也是排序条件，请求涉及候选集合选择。
|
||||
|
||||
Agent 建议：A
|
||||
|
||||
原因：
|
||||
当前快系统导航 POI 默认支持距离优先，因此“最近的停车场”不应等同于“最大的停车场 / 评分最高的停车场”这类优化筛选请求。
|
||||
|
||||
请确认：
|
||||
1. 接受 A
|
||||
2. 改为 B
|
||||
3. 补充新的边界规则
|
||||
人工裁决后，Agent 写入：
|
||||
memory/human_decisions.md
|
||||
长期标签边界知识库
|
||||
相关 skill 的 known-confusions.md
|
||||
以后类似问题直接复用。
|
||||
|
||||
---
|
||||
5. 典型运行方式
|
||||
[图片]
|
||||
|
||||
用户输入：
|
||||
一批 badcase + 需求说明 + 当前标签定义
|
||||
Agent 启动任务 workspace。
|
||||
然后 Agent 自主推进：
|
||||
1. 读取需求和 badcase
|
||||
2. 写 goal.md
|
||||
3. 写 current_understanding.md
|
||||
4. 检索相关标签定义
|
||||
5. 检索历史类似裁决
|
||||
6. 判断当前问题涉及哪些边界
|
||||
7. 自主选择数据挖掘策略
|
||||
8. 查询线上 session / topquery / 模型误判样本
|
||||
9. 聚类、去重、找代表样本
|
||||
10. 发现标签冲突或定义不清
|
||||
11. 生成 open_questions.md
|
||||
12. 向人提出高价值裁决问题
|
||||
13. 根据裁决继续挖掘和修正
|
||||
14. 生成候选评测集
|
||||
15. 生成回放报告
|
||||
16. 沉淀 reusable_lessons.md
|
||||
注意：这不是预设流程，而是一个典型任务可能自然形成的行动轨迹。
|
||||
|
||||
---
|
||||
6. 关键产物
|
||||
第一版系统建议产出以下文件：
|
||||
goal.md
|
||||
current_understanding.md
|
||||
boundary_analysis.md
|
||||
open_questions.md
|
||||
human_decisions.md
|
||||
failed_attempts.md
|
||||
reusable_lessons.md
|
||||
candidate_pool.csv
|
||||
annotation_queue.csv
|
||||
eval_set_candidate.jsonl
|
||||
label_definition_patch.md
|
||||
replay_report.md
|
||||
trace.md
|
||||
skills_used.md
|
||||
这些产物分为三类：
|
||||
6.1 Agent / 人类协作产物
|
||||
goal.md
|
||||
current_understanding.md
|
||||
boundary_analysis.md
|
||||
open_questions.md
|
||||
human_decisions.md
|
||||
reusable_lessons.md
|
||||
6.2 数据资产产物
|
||||
candidate_pool.csv
|
||||
annotation_queue.csv
|
||||
eval_set_candidate.jsonl
|
||||
6.3 审计与复盘产物
|
||||
trace.md
|
||||
skills_used.md
|
||||
failed_attempts.md
|
||||
replay_report.md
|
||||
|
||||
---
|
||||
7. MVP 建议
|
||||
第一版不要做大而全平台。
|
||||
先验证一个最小闭环：
|
||||
输入 badcase，Agent 能否自主探索并产出高质量边界问题和候选评测集。
|
||||
MVP 输入
|
||||
1. 一批 badcase
|
||||
2. 当前标签定义
|
||||
3. 可查询的线上 session / topquery
|
||||
4. 现有评测集
|
||||
5. 模型预测结果，可选
|
||||
MVP 输出
|
||||
1. boundary_analysis.md
|
||||
2. open_questions.md
|
||||
3. human_decisions.md
|
||||
4. candidate_pool.csv
|
||||
5. eval_set_candidate.jsonl
|
||||
6. replay_report.md
|
||||
7. reusable_lessons.md
|
||||
MVP 验收标准
|
||||
1. Agent 能自己识别涉及的标签边界
|
||||
2. Agent 能自己查找相关历史定义 / 样本
|
||||
3. Agent 能自己提出挖掘策略
|
||||
4. Agent 能找出一批有效候选样本
|
||||
5. Agent 能提出高质量人工裁决问题
|
||||
6. 人工裁决后，Agent 能继续修正结果
|
||||
7. 最终候选评测集可被人工抽检使用
|
||||
8. 本次经验能被后续任务复用
|
||||
|
||||
---
|
||||
8. 成功标准
|
||||
项目成功不看是否跑通一个固定流程，而看以下能力：
|
||||
1. Agent 是否能自主理解新需求 / badcase？
|
||||
2. Agent 是否能主动寻找相关历史定义和裁决？
|
||||
3. Agent 是否能判断当前问题属于哪些标签边界？
|
||||
4. Agent 是否能自主决定挖哪些数据？
|
||||
5. Agent 是否能发现标签定义冲突？
|
||||
6. Agent 是否能提出高质量人工裁决问题？
|
||||
7. Agent 是否能生成可用候选评测集？
|
||||
8. Agent 是否能根据人工裁决修正自己的判断？
|
||||
9. Agent 是否能沉淀经验？
|
||||
10. 下一次遇到类似问题，Agent 是否明显更聪明？
|
||||
最重要的是第 10 点。
|
||||
如果每次任务都像第一次一样重新开始，那就不是经验驱动。
|
||||
|
||||
---
|
||||
9. 最终结论
|
||||
[图片]
|
||||
本项目不应该定义为：
|
||||
用 Agent 编排快慢系统评测集构建流程
|
||||
而应该定义为：
|
||||
给路由数据开发建设一个 Agent-native 工作环境。
|
||||
最终形态是：
|
||||
Router Data Agent Workbench
|
||||
它的核心不是流程，而是：
|
||||
Workspace
|
||||
Skills
|
||||
Resources
|
||||
Tools
|
||||
Memory
|
||||
Policy
|
||||
它要实现的能力是：
|
||||
需求 / badcase
|
||||
→ Agent 自主探索
|
||||
→ 发现边界问题
|
||||
→ 挖掘候选数据
|
||||
→ 提出人工裁决
|
||||
→ 生成评测 / 训练资产
|
||||
→ 回放验证
|
||||
→ 沉淀经验
|
||||
→ 下次复用
|
||||
一句话总结：
|
||||
不是让 AI 跑数据流程，而是让 Agent 拥有一个可以自主完成数据开发工作的环境。
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user