HaHafeng
371e1c069c
Implement the full QPER intelligent analysis pipeline: - Phase E+: Block-based standardization for all 7 R tools, DynamicReport renderer, Word export enhancement - Phase Q: LLM intent parsing with dynamic Zod validation against real column names, ClarificationCard component, DataProfile is_id_like tagging - Phase P: ConfigLoader with Zod schema validation and hot-reload API, DecisionTableService (4-dimension matching), FlowTemplateService with EPV protection, PlannedTrace audit output - Phase R: ReflectionService with statistical slot injection, sensitivity analysis conflict rules, ConclusionReport with section reveal animation, conclusion caching API, graceful R error classification End-to-end test: 40/40 passed across two complete analysis scenarios. Co-authored-by: Cursor <cursoragent@cursor.com>
6.3 KiB
SSA-Pro 方案深度审查与风险评估报告
审查对象： SSA-Pro MVP 开发计划套件 (v1.1)
包含文档： MVP计划总览、任务清单、R服务指南、后端指南、前端指南
审查时间： 2026-02-18
总体评级： A- (优秀，但存在关键一致性漏洞)
1. 🚨 关键一致性漏洞 (Critical Inconsistency)
这是当前计划中最大的风险点，必须在开工前修复。
漏洞：混合数据传输协议在 R 指南中缺失
- 架构定义 (V4.1)：明确定义了“混合数据传输协议”，即 <1MB 走 Inline JSON，1-20MB 走 OSS 引用。
- 后端指南 (Doc 03)：正确实现了 data_source 逻辑，会发送 OSS Key。
- R 服务指南 (Doc 02)：❌ 严重缺失。
-
在 5.2 Wrapper 实现 示例代码中，依然假设 input$data 直接就是数据对象：
# 错误代码 (Doc 02)
df <- tryCatch(as.data.frame(input$data), ...) -
后果：如果后端发来的是 OSS Key，R 服务会直接报错或崩溃，导致 1MB 以上文件无法处理。
-
🛠️ 修正建议
在 R 服务开发指南中，必须增加一个标准化的 Data Loader 工具函数，并在所有 Wrapper 入口处调用：
# utils/data_loader.R
load_input_data <- function(input_json) {
# 兼容旧协议（纯数据）和新协议（data_source 对象）
if (!is.null(input_json$data_source)) {
source <- input_json$data_source
if (source$type == "inline") {
return(as.data.frame(source$content))
} else if (source$type == "oss") {
# ⬇️ 必须实现 OSS 下载逻辑
return(download_and_read_oss(source$key))
}
}
# Fallback
return(as.data.frame(input_json$data))
}
2. 架构层面的潜在风险 (Architecture Risks)
2.1 R 服务的“单线程阻塞”风险
- 现状：R 语言是单线程的。Plumber 默认也是同步处理。
- 场景：假设 SAE 分配了 1 个实例。用户 A 提交了一个需要跑 10 秒的 Bootstrap 任务。此时用户 B 提交了一个简单的 T 检验。
- 后果：用户 B 的请求会被阻塞 10 秒，甚至超时。HTTP 接口没有排队机制，体验极差。
- 建议：
- SAE 层面：设置较激进的扩容策略（并发数 > 2 即扩容）。
- 应用层面：考虑在 Plumber 中使用 future 包将长任务丢到后台 Promise 中运行（虽然这会增加复杂度），或者简单粗暴地在 Docker 容器中启动多个 R 进程（利用 PM2 管理 Rscript）。MVP 阶段建议至少部署 2 个 SAE 实例做负载均衡。
2.2 OSS 内网穿透的配置陷阱
- 现状：文档强调了使用“VPC 内网 Endpoint”。
- 风险：
- 开发环境（本地 Docker）通常不在 VPC 内，无法访问内网 Endpoint。
- 生产环境（SAE）在 VPC 内，必须访问内网 Endpoint。
- 建议：
- R 代码中的 OSS Endpoint 必须通过环境变量注入，绝不能硬编码。
- docker-compose.yml (开发) 注入公网 Endpoint。
- SAE 环境变量 (生产) 注入内网 Endpoint。
3. 工程细节的优化建议 (Engineering Improvements)
3.1 代码生成的“可维护性”问题
- 现状：在 R 代码中使用 glue 拼接字符串。
- 问题：将大量的 R 代码（如下载逻辑、绘图逻辑）以字符串形式写在 Wrapper 里，不仅难写，而且没有语法高亮，容易拼错。
- 建议：
- 采用 "模板文件分离" 策略。
- 在 templates/ 目录下存放完整的 .R 文件（如 t_test_template.R），在其中用 {{variable}} 占位。
- Wrapper 只负责读取文件并替换变量，不要在代码里写大段字符串。
3.2 统计结果的“精度陷阱”
- 现状：R 返回的 p_value 是浮点数。
- 问题：JSON 序列化时，极小的 P 值（如 1.23e-16）在前端 JavaScript 中可能会显示不友好，或者精度丢失。
- 建议：
- R 服务在返回 JSON 前，建议增加一个格式化后的字段，如 p_value_fmt: "< 0.001"，由 R 来决定如何科学计数显示，而不是让前端去猜。
3.3 护栏（Guardrails）的“一刀切”风险
- 现状：正态性检验失败 -> 自动降级。
- 问题：对于大样本（N > 5000），Shapiro-Wilk 检验过于敏感，哪怕极微小的偏态也会 P < 0.05。但实际上大样本下 T 检验是鲁棒的（中心极限定理）。
- 建议：
- 优化 guardrails.R 逻辑：当 N > 500 时，放宽正态性检验的阈值，或者直接跳过 Shapiro 检验，改用 Q-Q 图的峰度/偏度判断（虽然这很难自动化）。
- MVP 修正：至少加上 if (N > 5000) return PASS 的逻辑，避免大样本被错误降级。
4. 测试数据的缺失 (Missing Test Data)
文档中提到了“端到端测试”，但缺少**“标准测试数据集 (Golden Datasets)”**。
- 问题：怎么证明你的 T 检验算得是对的？
- 建议：
- 建立一个 tests/fixtures 目录。
- 准备几组 “标准答案”：
- normal_data.csv (R 算出来应该是 P=0.042)
- skewed_data.csv (应该触发护栏降级)
- missing_data.csv (应该报错或自动剔除)
- 在 CI/CD 流程中，自动跑这几组数据，比对结果是否与标准答案一致。
5. 结论与修正计划
✅ 总体评价
方案架构设计合理，技术栈选型（Node+R+Plumber）成熟。只要修复数据协议的不一致，MVP 成功率极高。
📝 需立即执行的修正 (Must-Do)
- 修正 Doc 02 (R 开发指南)：
- [ ] 增加 utils/data_loader.R 模块，实现混合协议解析。
- [ ] 修改 Dockerfile 和 Env 配置，支持 OSS_ENDPOINT 动态注入。
- [ ] 修改 Wrapper 模板，使用 load_input_data() 替代直接读取。
- 修正 Doc 03 (后端指南)：
- [ ] 确认 RClientService 发送给 R 的 Payload 结构与 R 端的解析逻辑完全匹配。
- 补充测试资源：
- [ ] 准备 3-5 个涵盖边缘情况（空值、单行、非正态）的标准 CSV 文件。
建议项目经理（PM）将上述 3 点加入 "Phase 1: 骨架搭建" 的首要任务。