feat(ssa): Complete QPER architecture - Query, Planner, Execute, Reflection layers

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>
This commit is contained in:
2026-02-21 18:15:53 +08:00
parent 428a22adf2
commit 371e1c069c
73 changed files with 9242 additions and 706 deletions

View File

@@ -0,0 +1,90 @@
# **架构委员会独立审查报告QPER 智能化主线开发计划**
**审查对象:** 《10-QPER架构开发计划-智能化主线.md》
**审查时间:** 2026-02-20
**总体评级:** 🌟 **S级 (战略与战术高度统一)**
**核心裁决:** 完全同意将此文档作为 MVP 的绝对主线。该架构已达到当前医疗 AI Agent 的工业界最佳实践水平。
## **一、 值得全团队起立鼓掌的 3 大亮点 (What You Did Exceptionally Well)**
### **1\. 极其克制的 MVP 范围管理 (The Power of 7\)**
放弃 100 个工具,死磕 7 个最核心的工具描述、T检验、秩和、卡方、相关、线回、Logistic
**架构师点评:** 这是最英明的决定。这 7 个工具覆盖了 80% 的临床医学基础论文需求。如果 QPER 架构连这 7 个都跑不顺,跑 100 个只会是灾难。
### **2\. P层规划层的“规则先行”策略 (Rule-First Strategy)**
在 Planner 中设计了 规则匹配 (决策表) \-\> LLM 兜底 的机制。
**架构师点评:** 这是对抗大模型“幻觉”的杀手锏。医学统计是有硬性定理的比如Y是二分类就必须用 Logistic 回归,容不得 AI 自由发挥)。用硬编码的决策表管住核心逻辑,用 LLM 处理模糊边缘,完美平衡了“严谨”与“智能”。
### **3\. Q层理解层引入 Tool C (DataProfiler)**
**架构师点评:** 将原本纯后端的意图识别与真实的物理数据探测Python Tool C结合。这意味着 AI 不再是“盲人摸象”,它在写计划前,就已经知道了数据的缺失率、极值和真实分布。
## **二、 必须警惕的 3 个工程暗礁 (Critical Issues to Address)**
虽然架构图很完美,但在写代码时,以下三个地方极容易导致系统崩溃或用户体验翻车:
### **🚨 暗礁 1Q层到 P层的“Token 爆炸” (The Context Window Trap)**
* **计划现状**Query 层输出 dataProfile并传给 Planner。
* **致命隐患**:如果用户的 CSV 有 100 列Tool C 跑出来的 dataProfile JSON 可能会长达 50KB。如果把这 100 列的详细信息(均值、方差、频数分布)全部塞进 Planner (DeepSeek) 的 System Prompt 里,不仅会导致响应极慢,还会让 LLM 发生“注意力涣散Lost in the middle”。
* **修正建议**
在 DataProfiler 和 Planner 之间加一个 **“按需截取 (Lazy Fetch / Pruning)”** 逻辑。
* Planner 只需要看 Schema列名、数据类型
* 只有当 IntentParser 明确识别出用户想分析 Age 和 BP\_Change 时,后端才从完整的 dataProfile 中提取这**两列**的详细统计特征,喂给 Planner。
### **🚨 暗礁 2R层反思层的“无限死循环” (The Infinite Loop of Doom)**
* **计划现状**:遇到 R 报错 \-\> AutoFixer 修改参数 \-\> 重新 Execute。
* **致命隐患**如果报错是因为“奇异矩阵Singular Matrix多重共线性导致LLM 可能会盲目地反复调整 conf.level 或换个无关紧要的参数重试,导致系统在后台疯狂请求 API最后超时。
* **修正建议**
必须在 Node.js 的 orchestrator 中建立**严格的状态机与短路机制**
1. 强制设定 MAX\_RETRIES \= 2。
2. 如果 R 返回的错误包含 system is computationally singular 或 not enough observations**直接阻断**,跳过 AutoFixer直接交由 Critic 生成一封“诊断失败报告”给用户“您的数据存在严重共线性建议删除X变量”
### **🚨 暗礁 3Clarifier (澄清器) 的“傻瓜式连问”体验**
* **计划现状**:信心度 \<0.7 时,追问澄清。
* **致命隐患**如果用户输入“帮我看看”AI 问“你的目标是用户回“看血压”AI 又问“你想用什么方法?”…… 这种填表式的追问会让医生崩溃。
* **修正建议**
Clarifier 必须是 **“带选项的封闭式提问”**,而不是开放式聊天。
* **错误示范**:“请问您想分析哪两列?”
* **正确示范**(配合前端 UI“我发现数据包含\[年龄\]和\[血压\],您是想做:👉\[差异比较\] 👉\[相关性分析\]?”(前端渲染为可点击的快捷 Tag
## **三、 架构师对开发顺序的微调建议 (Roadmap Tweaks)**
你们的 3 个 Phase 划分很合理,但我建议在内部执行时,微调一下测试策略:
### **🛠️ 建议:采用“硬编码探路法 (Hardcoded Tracer Bullet)”**
**Phase 1** 开发 Q 和 P 时,**千万不要等前端界面和真实的 R 服务!**
后端开发人员应该写一个简单的 test.js 脚本:
// 模拟前端传入
const userQuery \= "看看吃药对血压的影响";
const mockDataProfile \= { columns: { "Drug": "categorical", "BP": "numeric" } };
// 测 Q 层
const parsed \= await IntentParser.run(userQuery, mockDataProfile);
console.log(parsed); // 应该输出: { goal: "difference", Y: "BP", X: "Drug" }
// 测 P 层
const plan \= await Planner.run(parsed);
console.log(plan); // 应该命中决策表,输出: ST\_T\_TEST\_IND
**为什么这样做?** 只要后端用纯 JSON 把 Q 和 P 串通了,你们的智能化就成功了 80%。剩下的 R 执行和 UI 渲染只是体力活。
## **四、 最终结论**
这是一份可以**直接拿去向管理层汇报、向投资人路演**的技术蓝图。
QPER 不仅仅是一个架构,它是 AI Data Scientist 的标准灵魂。
请团队立刻以此文档为唯一灯塔,废弃之前所有零散的 MVP 规划,**全力冲刺 QPER 第一版!** 🚀