Files

HaHafeng 371e1c069c 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>

2026-02-21 18:15:53 +08:00

5.6 KiB

Raw Blame History

架构委员会独立审查报告：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)

虽然架构图很完美，但在写代码时，以下三个地方极容易导致系统崩溃或用户体验翻车：

🚨 暗礁 1：Q层到 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。

🚨 暗礁 2：R层（反思层）的“无限死循环” (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变量”）。

🚨 暗礁 3：Clarifier (澄清器) 的“傻瓜式连问”体验

计划现状：信心度 <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 第一版！ 🚀

5.6 KiB Raw Blame History Unescape Escape