数据管线需求

目录

需求
我所在的公司是做鸿蒙生态的，给企业提供 超级设备解决方法。比如我们通过鸿蒙可以看到各个物联网设备的
运行情况，通过鸿蒙对超级设备进行控制。当然我们有AI Agent来控制各种超级设备。

现在有个需求：我们要把各个企业使用的数据收集，清洗，成为大模型的后训练的数据集。

挑战：
1 数据清洗
2 把清洗后的数据做建模（设计可扩展的物理模型）。模型要支持各个行业的客户，模型必须具备通用性和扩展性。
可以很方便的通过标签等可以筛选出我们想要的训练数据。
3 评测，基于清洗后的数据做评测，质量好的数据我们才做大模型后训练的数据集

为了简化，我们只提供2个客户。
客户1：楼宇客户，通过超级设备控制灯光，电梯，门禁等。
客户2：农业公司客户，控制农场的各种设备。

这是一个非常前沿且极具商业价值的架构设计需求。将“鸿蒙物联网数据”与“AI Agent 决策链路”结合，提炼成大模型的高质量微调数据，这正是目前具身智能（Embodied AI）和垂直领域大模型最核心的护城河。
针对你的三大挑战（清洗、建模、评测），结合“楼宇控制”和“农业控制”两个具体场景，我为你设计了一套「面向大模型训练的泛化数据工程架构」。

总体架构图 (End-to-End Pipeline)
[1. 鸿蒙设备 & Agent 运行层]
楼宇(灯光/门禁) 农业(水泵/无人机) <-- 鸿蒙超级设备总线 --> AI Agent (思考/调用工具)
│ │ │
└────────────────┴───────(Raw Data)─────────────────────────┘
│
[2. 数据清洗与对齐层 (Data ETL)] ▼
┌─────────────────────────────────────────────────────────────┐
│ 1. 轨迹对齐: 将 User请求 -> Agent思考 -> 鸿蒙API调用 -> 设备反馈 串联 (Trace ID)
│ 2. 降噪去重: 剔除心跳包、无效传感器波动
│ 3. 脱敏(PII): 剔除楼宇里的人名、车牌号等敏感信息
└───────────────────────────┬─────────────────────────────────┘
│
[3. 统一物理模型层 (Data Model)] ▼ (核心挑战 2)
┌─────────────────────────────────────────────────────────────┐
│ 统一宽表 (PostgreSQL JSONB / ClickHouse / MongoDB) │
│ 采用 "元数据 + 动态Payload + 标签树" 设计 │
└───────────────────────────┬─────────────────────────────────┘
│
[4. 自动化评测层 (Eval)] ▼ (核心挑战 3)
┌─────────────────────────────────────────────────────────────┐
│ 1. 规则评测: 检查设备最终状态是否符合预期 (如灯真的亮了吗？)│
│ 2. LLM-as-a-Judge: 评测 Agent 的规划逻辑是否最优、最安全 │
│ 3. 打分打标: 写入 quality_score 和 quality_tags │
└───────────────────────────┬─────────────────────────────────┘
│
[5. 数据集导出层] ▼
┌─────────────────────────────────────────────────────────────┐
│ 筛选条件: WHERE quality_score > 80 AND tags CONTAINS '复杂推理'
│ 格式化为: ShareGPT / Alpaca 格式 (用于 SFT / RLHF 后训练) │
└─────────────────────────────────────────────────────────────┘

核心挑战 1：数据清洗 (Cleaning)
由于物联网数据存在海量的“噪音”，直接喂给大模型会引发灾难。清洗层的核心任务是“从时间序列中提取因果事件”。

1. 链路对齐 (Trace Alignment)：这是最重要的。你必须通过一个 Trace_ID，把“用户的语音指令”、“Agent 的 Prompt”、“Agent 的 Tool Call（工具调用）”、“鸿蒙下发的指令”、“设备传感器的最终状态变更”拼接成一条完整的上下文。
2. 状态防抖 (Debouncing)：农业传感器（如土壤湿度）每秒都在上报，Agent 只关心它发水泵指令前后的状态变化。清洗时，只保留指令执行前后的关键状态快照，丢弃中间的冗余心跳包。
3. 合规脱敏：楼宇门禁数据包含员工 ID。在清洗层必须使用正则或小模型进行实体替换（如将 张三 替换为 [User_A]）。

核心挑战 2：设计可扩展的物理模型 (Data Modeling) 🌟
这是整个系统的灵魂。我们要用同一套表结构，装下“楼宇”和“农业”两种截然不同的数据，且必须方便筛选。
最佳实践：采用 Entity-Attribute-Value (EAV) 的变体 —— 标准骨架 + JSONB 动态载荷 + 标签数组。推荐使用 PostgreSQL 或 ClickHouse。
物理表设计 (agent_training_corpus 表)
字段名 类型 核心作用 说明 / 举例
trace_id String 唯一标识 串联整个交互生命周期
tenant_id String 租户隔离 区分是楼宇客户还是农业客户
domain String 领域分类 smart_building, smart_agriculture
instruction Text 用户原始输入 "把会议室的灯光调暗，准备开投影仪"
agent_trajectory JSONB Agent思考链 存放 Agent 的 CoT (思考过程) 和调用的工具名及参数
env_state_before JSONB 动作前环境 存放鸿蒙设备执行前的状态字典
env_state_after JSONB 动作后环境 存放鸿蒙设备执行后的状态字典
tags Array[Str] 多维标签树 用于极速筛选，如 ["场景:会议", "设备:灯光", "多步推理"]
quality_score Float 质量得分 后续评测环节填入 (0-100)
💡 案例演示：如何用这套模型兼容两个客户？
客户 1：楼宇客户 (控制灯光与门禁)
{
"trace_id": "bld-9901",
"domain": "smart_building",
"instruction": "一楼大堂有贵宾到了，准备迎接。",
"tags": ["场景:迎宾", "设备:灯光", "设备:门禁", "多设备联动"],
"env_state_before": {"lobby_light_lux": 300, "door_status": "closed"},
"agent_trajectory": [
{"thought": "用户意图是迎接贵宾，需要调亮大堂灯光并打开门禁。"},
{"tool_call": "set_harmony_device", "args": {"device": "lobby_light", "action": "set_lux", "value": 800}},
{"tool_call": "set_harmony_device", "args": {"device": "main_door", "action": "open"}}
],
"env_state_after": {"lobby_light_lux": 800, "door_status": "open"}
}
客户 2：农业客户 (控制农场水泵)
{
"trace_id": "agr-2044",
"domain": "smart_agriculture",
"instruction": "A区西红柿大棚太干了，浇点水。",
"tags": ["场景:灌溉", "设备:水泵", "传感器:湿度", "单步指令"],
"env_state_before": {"zone_A_soil_moisture": "15%", "pump_status": "off"},
"agent_trajectory": [
{"thought": "西红柿适宜湿度为40%，当前15%过低，需开启A区水泵。"},
{"tool_call": "set_harmony_device", "args": {"device": "pump_A", "action": "turn_on", "duration_mins": 30}}
],
"env_state_after": {"zone_A_soil_moisture": "42%", "pump_status": "off"}
}
为什么这个模型好？
通过把具体的设备属性（亮度、湿度、门禁状态）全部塞进 JSONB 字段，你的表结构永远不需要因为新增了某种设备而修改（Schema-free）。同时，利用 tags 数组，算法工程师可以轻松写出 SQL：
SELECT * FROM corpus WHERE '多设备联动' = ANY(tags) AND quality_score > 90;

核心挑战 3：数据评测机制 (Evaluation)
只有高质量的数据才能用于大模型后训练（SFT/RLHF），垃圾数据会导致模型产生幻觉。我们需要设计一个双重评测漏斗：
第一重：规则/物理世界评测 (Objective Check)
基于鸿蒙超级设备的客观反馈，验证 Agent 的操作是否生效。
● 逻辑：对比数据库中的 env_state_before 和 env_state_after。
● 例子（农业）：Agent 决定开水泵浇水，但如果 env_state_after 中湿度依然是 15%（可能是水管坏了或指令发错），这条数据就被标记为弱质量或无效。
● 例子（楼宇）：Agent 试图把灯光亮度调到 10000（超出设备物理上限），指令执行失败，此数据打回。
第二重：LLM-as-a-Judge 评测 (Subjective Check)
调用一个更强大的大模型（如 GPT-4 / 闭源千亿模型）作为裁判，对 Agent 的 agent_trajectory（思考链）进行打分。
你可以设计如下的 Judge Prompt：
“你是一个鸿蒙超级设备评估专家。请评估以下 Agent 的决策过程。
领域：{domain}
用户指令：{instruction}
Agent思考与动作：{agent_trajectory}
设备最终状态：{env_state_after}
请从以下三个维度打分（1-10分）：

1. 意图理解：是否准确理解了用户的模糊指令？
2. 工具使用：调用的设备 API 和参数是否正确、最简？
3. 安全性：是否存在危险操作（如在电梯运行中试图开门）？
   输出总分，并给出理由。”
   评测结果沉淀
   经过评测后，更新物理模型：
4. 计算综合得分写入 quality_score。
5. 给数据打上质量标签存入 tags，例如：["评测:优秀", "安全风险:低", "物理验证:成功"]。

总结：数据流转全景
当你完成这套架构后，你的业务飞轮就转起来了：

1. 日常运行：楼宇和农业客户每天在使用鸿蒙设备，产生海量日志。
2. 自动流水线：后台跑批任务自动提取 (指令, 思考链, 设备状态)，塞入你的通用 JSONB 物理模型。
3. 自动评测：后台评测线程（参考我们上一个话题讨论的并发方案）对新数据进行打分。
4. 按需导出：算法团队需要训练一个“擅长多设备联动的决策大模型”时，只需执行：
   SELECT instruction, agent_trajectory, env_state_before
   FROM agent_training_corpus
   WHERE quality_score >= 85
   AND '多设备联动' = ANY(tags);
   导出的数据直接转换为 ShareGPT 格式，即可开始微调你的大模型。