05 · 部署与演进
1. 部署方案
目标形态:单机内网部署的 Spring Boot 应用,连 MaxCompute + 调 DeepSeek。
1.1 构建
# 本机构建(JDK 11 + Maven,阿里云镜像)
mvn clean package -DskipTests
# 产出:target/metric-ontology-query-0.1.0.jar
1.2 运行
export DEEPSEEK_API_KEY=sk-xxx
export MAXCOMPUTE_ENDPOINT=xxx
export MAXCOMPUTE_ACCESS_ID=xxx
export MAXCOMPUTE_ACCESS_KEY=xxx
export MAXCOMPUTE_PROJECT=xxx
java -jar target/metric-ontology-query-0.1.0.jar
1.3 验证
curl -X POST http://localhost:8080/api/query \
-H "Content-Type: application/json" \
-d '{"question": "上个月华东区成交额环比多少?"}'
# 响应
{
"metric": "GMV",
"result": [{"region_group": "华东区", "value": 120000000}],
"analysis": "华东区 GMV 环比下降 12.3%,主因..."
}
2. 依赖清单
| 依赖 |
用途 |
版本 |
| spring-boot-starter-web |
REST API |
2.7.18 |
| apache-jena-libs |
本体推理 |
4.10.0 |
| odps-sdk-core |
MaxCompute 查询 |
0.59.0-public |
| JDK |
运行环境 |
11(Temurin) |
3. 后续演进路线
3.1 近期(MVP 之后)
| 演进项 |
内容 |
| 指标规模扩展 |
从 3 个指标扩展到几十个,验证「配置驱动」的可维护性 |
| 维度扩展 |
增加时间维度层级(日→周→月→季→年)的推理 |
| 缓存 |
本体推理结果缓存(等价映射、维度展开) |
| 模糊表达兜底 |
LLM 识别不出指标/维度时,回退追问 |
3.2 中期
| 演进项 |
内容 |
| 本体规模增长 |
概念 > 1000 时,Jena 换 TDB 持久化 + 增量推理 |
| 复杂指标 DSL |
支持多表 join、窗口函数的结构化 DSL |
| 多模型切换 |
若需换模型/复杂编排,评估 Spring AI |
3.3 远期
| 演进项 |
内容 |
| 自动本体生成 |
从表结构 + 指标口径文档自动生成指标本体 |
| 指标血缘可视化 |
指标 → 账单表 → 原始表 的血缘图谱 |
| 主动分析 |
从"被动查询"到"主动发现异常指标" |
4. 风险与边界
| 风险 |
应对 |
| Jena 规则推理 ≠ 完整 DL |
指标本体的推理需求(等价/层级/派生)恰好是规则推理能覆盖的,不引入 DL 推理机 |
| 本体维护成本 |
配置驱动,新增指标只加配置;骨架低频变更 |
| LLM 结构化输出不稳定 |
用 response_format=json_object + JSON Schema 约束 + 解析失败重试 |
| MaxCompute 查询延迟 |
简单聚合查询,账单表有分区(dt),查询走分区裁剪 |
5. MVP 验收标准
- [ ] 能识别「成交额」与「GMV」是同一指标(等价推理)
- [ ] 能展开「华东区」为 7 个省份(层级推理)
- [ ] 能拆解「客单价」为 GMV ÷ 订单数(派生推理)
- [ ] 生成的 SQL 强制包含口径过滤(status/refunded)
- [ ] 自然语言 → 结果 → 归因分析的完整链路跑通