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>
78 lines
5.3 KiB
Markdown
78 lines
5.3 KiB
Markdown
# **SSA-Pro 外部架构调研总结与研发共识备忘录**
|
||
|
||
**文档定位：** 研发团队的统一思想大纲与架构护栏
|
||
|
||
**核心参考：** 外部调研报告《医疗AI统计助手架构研究》、《智能统计分析助手开发探讨》
|
||
|
||
**宣贯目标：** 明确 SSA-Pro 智能化演进的“可为”与“不可为”，确立 **Q-P-E-R 架构** 的极简落地规范。
|
||
|
||
## **1\. 行业前沿共识：我们面临的最大挑战是什么？**
|
||
|
||
两份外部顶级调研报告一致指出，医疗 AI 统计分析面临一个根本性矛盾：
|
||
|
||
**大模型（LLM）的“概率性生成（经常出现幻觉）” 与 医学统计学要求的“100% 确定性（绝对严谨）” 之间的冲突。**
|
||
|
||
如果任由大模型自由发挥（如直接写代码计算 P 值），极易导致致命的学术错误。
|
||
|
||
### **💡 破局之道：LLM 的“哑铃型”选择性部署**
|
||
|
||
报告为我们指明了业界最佳实践：**“两头用 AI，中间用规则”**。
|
||
|
||
* **两头（Q层 & R层）**：利用 LLM 强大的自然语言处理能力，听懂医生的“大白话”，写出漂亮的“学术结论”。
|
||
* **中间（P层 & E层）**：利用传统软件工程的“决策表”和“固定代码库”死死管住执行逻辑，绝不容许 AI 产生幻觉！
|
||
|
||
## **2\. Q-P-E-R 四层架构的具体落地规范 (Actionable Guide)**
|
||
|
||
为了将高大上的理论转化为我们初创团队可以马上写的代码，请开发团队严格遵循以下落地规范：
|
||
|
||
### **🟢 Q层 (Query) \- 意图理解与澄清**
|
||
|
||
* **调研精髓**：医生缺乏统计学术语，输入充满模糊性。不要让 AI 瞎猜。
|
||
* **开发规范**：
|
||
1. **结构化槽位提取**：LLM 的任务是做“翻译官”，将自然语言翻译成 JSON 格式的统计特征（如 {"goal": "difference", "y\_type": "numeric"}），而不是直接选工具。
|
||
2. **动态意图澄清 (Human-in-the-loop)**：当 LLM 发现意图不明确时（信心度 \< 0.8），后端立即中断流程，返回前端一个带选项的卡片（如：👉\[比较差异\] 👉\[相关分析\]），让用户点击选择。
|
||
|
||
### **🟡 P层 (Planner) \- 方案规划**
|
||
|
||
* **调研精髓**：应对海量工具的 Context 爆炸，以及防止 AI 选错统计方法。
|
||
* **开发规范**：
|
||
1. **Tool RAG 动态检索**：在组装 Prompt 前，先用 pgvector 检索出最相关的 Top-5 工具定义喂给大模型，节省 Token 并提高准度。
|
||
2. **硬编码决策树兜底 (Rule-based)**：**严禁 AI 自由决定统计方法**。后端代码必须引入基于 Excel 导出的决策表。拿到 Q 层的 JSON 后，用 if-else 规则精准匹配出唯一的 Tool\_Code（如 ST\_T\_TEST\_IND）。
|
||
|
||
### **🔵 E层 (Execute) \- 代码执行**
|
||
|
||
* **调研精髓**：用户需要的是完整的分析流程，以及绝对安全的运行环境。
|
||
* **开发规范**：
|
||
1. **工作流模板 (Workflow Templates)**：不要指望 AI 去拼接多步操作。我们将底层的单个 R 脚本升级为“套餐”。例如 T 检验的 R 脚本内应包含 \[基线描述 \-\> 正态性护栏检查 \-\> 核心计算 \-\> 画图\] 完整动作，Node.js 只需发起一次调用。
|
||
2. **安全隔离**：继续使用当前的 R Docker \+ Plumber API 提供服务，通过内网 OSS 传递数据。
|
||
|
||
### **🟣 R层 (Reflection) \- 结果反思与自愈**
|
||
|
||
* **调研精髓**：AI 执行必然会报错，必须具备遇到 Error 自动修复的能力。
|
||
* **开发规范**：
|
||
1. **参数级靶向自愈 (Self-healing)**：当 R 容器报错（如“找不到年龄列”）时，Node.js 捕获 500 错误，将报错信息抛给 LLM。**警告：只允许 LLM 修改参数 JSON 重新请求，绝对禁止 LLM 现场重新生成一坨 R 代码来跑。**
|
||
2. **论文级严谨解读**：Critic Agent 根据 R 吐出的 P 值，利用预设的 Prompt 约束（严禁使用“证明了”等词），生成结构化的学术解读。
|
||
|
||
## **3\. 架构红线：我们要坚决摒弃的“大厂陷阱”**
|
||
|
||
外部报告提到了很多高级名词，但作为追求敏捷交付的团队，我们**坚决不碰**以下过度工程化的方案：
|
||
|
||
❌ **拒绝引入 LangGraph/AutoGen 等复杂编排框架**：
|
||
|
||
我们现阶段的 QPER 流程是一个清晰的“带重试的线性流水线”。用 **Node.js 原生的 while 循环和 try-catch** 就能实现完美的编排，并且更容易控制前端的 SSE 状态流。
|
||
|
||
❌ **拒绝引入微虚拟机 (Firecracker) 沙箱**：
|
||
|
||
因为我们坚持了“调用内部固定的 R 脚本”而不是“执行 LLM 现场写的随意代码”，我们天然避开了 RCE（远程代码执行）的最高风险。现有的 Docker 容器隔离已经足够安全。
|
||
|
||
❌ **拒绝多智能体辩论 (Multi-Agent Debate)**：
|
||
|
||
医疗统计有明确的数学定理，正态性 P \< 0.05 就是不满足。我们用“硬编码的 R 语言护栏”来保证正确性，不需要浪费 Token 让两个 LLM 互相辩论。
|
||
|
||
## **4\. 总结寄语**
|
||
|
||
这份调研报告是对我们目前技术路线的最高级别肯定！
|
||
|
||
它证明了我们在坚持的 **“规则匹配 \+ LLM推理 \+ 标准化执行库”** 模式，正是解决医疗 AI 痛点的终极答案。
|
||
|
||
请大家不要有任何技术栈焦虑，用最熟悉的 Node.js 和 R，用最扎实的 if-else 配合优秀的 Prompt，去打造业界最严谨、体验最好的智能统计助手！ |