vpp-ai-platform/docs/08-implementation.md
stewart hu 6c999186c0 Add evaluation architecture (doc 12)
Four-layer eval design (LLM tasks / skills / safety chain / end-to-end
decision quality), datasets built on event-log replay (I7), change
gates mapping each change type to required evals — envelope widening
approvable only on shadow/online L4 data — and measurable definitions
for the proposal's core KPIs.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019u5SLNweVio6ozJX7yfxQr

🔮 View transcript: https://logs.lojong.info/s/e8u90k3t33w590r7b5y7yzqh
2026-09-01 21:03:25 -04:00

102 lines
7.1 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 08 · 实现映射:技术栈、LLM 抽象层与部署形态
> 00–07 为框架中立的架构设计;本篇是当前技术选型下的实现映射,选型变更只影响本篇。
## 1. 技术栈基线
| 层 | 选型 | 理由 |
|---|---|---|
| Agent Runtime / 智能体 / 工作流 | TypeScript + Mastra(或同类 TS 智能体框架) | 类型化工具契约与业务对象(P4 的天然载体)、工作流原语、良好 DX |
| 专业模型 Skill | Python 微服务(预测:PyTorch/statsforecast;优化:Pyomo/PuLP + 商用/开源求解器;仿真:电科院既有引擎封装) | ML/优化生态在 Python;对电科院/武大协作方友好 |
| Skill 接口 | HTTP/JSON + JSON Schema 契约(注册表校验) | 跨语言、可版本化 |
| 事件总线 | Kafka(或一期先用 PostgreSQL 事务性发件箱,二期升级) | 事件溯源主干 |
| 存储 | PostgreSQL(关系 + pgvector)+ TimescaleDB/IoTDB + 对象存储归档 | 见 05 篇 |
| 前端 | 既有业务前端渐进嵌入 AI 卡片 + 新建审批/看板界面 | 见 06 篇 §4 |
**Mastra 概念映射**(具体 API 以实现时框架版本为准):
| 架构构件 | Mastra 原语 |
|---|---|
| 五类智能体 | Agent(各配独立 instructions、工具集、记忆视图) |
| 流程模板(申报流程、复盘流程) | Workflow(步骤化、可挂起恢复——承载 Proposal 状态机的悬挂审批) |
| Skill 调用 | Tool(封装对 Python Skill 服务的类型化调用,自动写血缘) |
| 记忆三层 | Memory + 自建情景/语义存储(Mastra memory 承担工作记忆,情景/语义按 05 篇落库) |
| 意图解析 | 路由 Agent → 选择 Workflow 模板并填参 |
**需自建、框架不提供的部分**(工作量估算时别漏):
政策包引擎(规则校核)、包络模型与检查器、现势复核与执行许可服务(ExecutionPermit)、
持仓账本服务、运营工单台(Case Desk,含多级审批收件箱)、
交易平台/调度/计量适配器、执行引擎与边缘协议、审计血缘组装。
——这些恰恰是本平台的差异化资产;智能体框架只解决约 1/3 的问题。
## 2. LLM 提供商抽象层(P6)
```
Agent 代码 → 能力接口(complete / plan / extract / explain, 统一消息与工具调用格式)
→ 模型路由器(按任务类型 × 环境选择后端)
├── 开发/测试:商用 API(Claude 等)
├── 预生产:本地开源模型(Qwen/DeepSeek,验证本地化部署可行性)
└── 生产:光明电力大模型适配器
```
设计约束:
1. **面向能力最小公倍数**:不依赖单一厂商特性(如特定结构化输出模式);
工具调用格式在抽象层归一,必要时降级为「提示词 + JSON 解析 + 重试」;
2. **光明大模型适配器的未知项**(需在一期尽早与国网侧确认):
接口协议(是否 OpenAI 兼容)、上下文长度、工具调用支持形式、
电力语义特有能力的调用方式、部署位置与网络分区;
——在确认前,抽象层按「OpenAI 兼容 + 8K 上下文 + 无原生工具调用」的保守假设设计降级路径;
3. **评测集先行**:为意图解析、规则问答、申报说明生成等每个 LLM 任务建立评测集,
换后端 = 跑评测集对比,而非人工感觉;这也是向评审证明「模型可替换、平台不锁定」的硬材料。
评测体系全貌(四层对象、数据集、变更门禁、KPI 口径)见 12 篇。
## 3. 部署形态
```
┌─ 省级云(管理信息大区)──────────────────────────┐
│ 认知平面(Runtime + Agents) LLM 推理(光明/本地) │
│ Skill 服务群 数据底座 可信执行链 审批工作台 │
└──────────────┬───────────────────────────────┘
│ 单向受控接口(批准计划/包络)
┌─ 生产控制相关区 ─────────────────────────────────┐
│ 执行引擎 受控通道网关 旁路监测/熔断 │
└──────────────┬───────────────────────────────┘
│ 加密通道
┌─ 边缘 ─────────────────────────────────────────┐
│ 聚合单元边缘节点 → 本地 CPS/数据网关 → 终端设备 │
└────────────────────────────────────────────────┘
```
- 训练(预测模型迭代)用云端 GPU 集群(租赁规划);推理分两类:
LLM 推理在省级本地推理引擎,秒级控制不依赖任何推理服务(P1);
- 分区与等保:认知平面全部位于管理区;跨区仅有可信执行链单向投递与遥测回传两条通道。
## 4. 一期落地切片(建议的构建顺序)
一期(2025.12–2026.5)以 07 篇场景的**可演示闭环**为验收锚点:
1. **M1**:数据接入管道 + 时序/关系库 + 持仓账本服务(数据先行);
2. **M2**:Skill 服务群 v1(负荷/光伏/电价预测 + 报价优化 MILP)+ 评测基线;
3. **M3**:Runtime + 智能分析/交易博弈两个 Agent + 政策包引擎 + 运营工单台
(此时即可跑通 07 篇 06:00→08:30 的申报链路,申报走文件导出人工上传);
4. **M4**:资源调度 Agent + 包络模型 + 现势复核/执行许可 + 复盘流程 + AI 卡片嵌入既有页面;
5. **M5 影子运行(一期验收形态)**:全链路接实时数据,外部效果全部仿真
(申报只生成不提交、指令只投递仿真网关),逐日对比影子决策与人工实际决策——
既是最有说服力的验收演示,也是包络初值设定的数据依据;
6. 交互服务/负荷控制 Agent 与边缘控制链路放二期(依赖现场资源接入与外部联调);
二期上线路径:影子运行 → 受控实报(人工逐笔批)→ 包络自治逐步放宽。
**排序理由**:M1–M3 不依赖任何外部单位排期,最快形成端到端演示与真实历史回测能力;
回测结果(用历史行情验证报价优化收益)是二期扩大授权(包络放宽)与评审汇报的最强证据。
## 5. 风险登记(架构相关)
| 风险 | 影响 | 缓解 |
|---|---|---|
| 光明大模型接口/能力与假设不符 | 抽象层返工 | 保守假设 + 降级路径先行;一期尽早拿到接口规格 |
| 外部接口联调排期不可控 | 二期进度 | 一期全部走可独立闭环的降级通道;接口协议对接提前启动 |
| 规则校核与知识库双轨漂移 | 合规风险 | 05 篇 §4 的同步评审工作流,上线即启用 |
| 包络初值定不下来 | 自治能力无法演示 | 03 篇 TODO 清单作为业务侧一期交付物管理 |
| 预测精度不达 8% | 连锁影响报价与考核 | M2 评测基线尽早暴露差距;数据质量门禁先行 |