HaHafeng
428a22adf2
Phase 2A: WorkflowPlannerService, WorkflowExecutorService, Python data quality, 6 bug fixes, DescriptiveResultView, multi-step R code/Word export, MVP UI reuse. V11 UI: Gemini-style, multi-task, single-page scroll, Word export. Architecture: Block-based rendering consensus (4 block types). New R tools: chi_square, correlation, descriptive, logistic_binary, mann_whitney, t_test_paired. Docs: dev summary, block-based plan, status updates, task list v2.0. Co-authored-by: Cursor <cursoragent@cursor.com>
141 lines
11 KiB
Markdown
141 lines
11 KiB
Markdown
# **SSA-Pro 终极架构共识与智能化演进备忘录**
|
||
|
||
**文档性质：** 架构争论复盘与终极演进路线图
|
||
|
||
**审查对象：** 团队反馈文档《SSA-Pro 架构审查反馈与智能化路径讨论》
|
||
|
||
**审查时间：** 2026-02-20
|
||
|
||
**核心定调：** 🟢 完全认同团队的终极愿景；🔴 对“动态执行生成代码”的安全与稳健性提出最高级别警告；🤝 提出“受限代码生成”作为完美桥梁。
|
||
|
||
## **一、 架构师的“认错”与全面致敬 (What I Completely Agree With)**
|
||
|
||
首先，我要向团队致敬。你们指出的核心分歧点——**“高级版的 SPSS 菜单（Tool Calling）” vs “真正的 AI 数据分析师（Code Intelligence）”**，一针见血。
|
||
|
||
1. **认同“静态参数的局限性”**：
|
||
你们是对的。临床数据极其肮脏和复杂（需要衍生变量、按条件过滤、合并清洗）。如果只依赖简单的 JSON 参数映射，一旦用户说“帮我把年龄大于 60 岁的人挑出来，再把血压分为高低两组，然后做个生存分析”，基于 Tool Calling 的架构会瞬间瘫痪，因为它无法在参数里表达这种动态的数据操作。
|
||
2. **认同“100 个 R 脚本的真实定位”**：
|
||
将这 100 个脚本视为\*\*“可学习的范例库（Knowledge Base / Code Templates）”\*\*，而不是死板的 API 工具，这是一个认知上的巨大飞跃。这让系统的天花板从“自动化”提升到了“智能化”。
|
||
3. **认同“三阶段演进策略”**：
|
||
你们提出的 Phase 1 (工具调用兜底) \-\> Phase 2 (宏脚本执行) \-\> Phase 3 (代码智能) 是极其成熟的务实主义。我们不仅没有分歧，反而达成了高度的战略共识。
|
||
|
||
## **二、 架构师的“红线”警告 (Where I Strongly Push Back / Warn)**
|
||
|
||
作为对系统稳定性负责的架构师，针对你们心心念念的 **“Phase 3: Code Intelligence (执行 LLM 动态生成的代码)”**，我必须亮出工程红线。
|
||
|
||
这是整个业界（包括 OpenAI）都在面临的最难的骨头，切不可低估其危险性。
|
||
|
||
### **🚨 风险 1：动态代码执行的“核弹级”安全漏洞 (RCE Vulnerability)**
|
||
|
||
* **团队设想**：LLM 生成 R 代码 \-\> 在沙箱中执行。
|
||
* **残酷现实**：如果在常规的 Docker 容器中直接使用 R 的 eval(parse(text=llm\_code)) 或者将生成的代码写入文件运行，哪怕你做了所谓的文件权限限制，**这本质上依然是一个合法的 RCE (远程代码执行) 后门**。
|
||
* **后果**：大模型极易被“提示词注入（Prompt Injection）”攻击，生成类似于窃取环境变量、发起内网 DDoS 或占用全部 CPU 资源的恶意代码。
|
||
* **架构底线**：在没有引入 **Firecracker 级别的微虚拟机（MicroVM）** 或严格的 **eBPF 系统调用拦截**之前，**绝对禁止**在生产环境中执行 LLM 自由发挥生成的 R 代码。
|
||
|
||
### **🚨 风险 2：统计学的“幻觉谬误”与合规灾难**
|
||
|
||
* **团队设想**：LLM 可以根据数据特征动态修改/组合统计代码。
|
||
* **残酷现实**：LLM 在写 Python 的 pandas 时很强，但在写深度的医学统计 R 代码时，非常容易产生“看似合理实则谬误”的幻觉（比如错误地设置了随机效应项，或者用错了极大似然估计方法）。
|
||
* **后果**：系统生成了 P 值，用户信了，发了论文，最后发现统计算法是错的。在医疗领域，这是致命的声誉打击。
|
||
* **架构底线**：涉及 P 值计算的核心统计引擎（如 wilcox.test 的参数配置），必须保留经过人类专家验证的“硬护栏”，绝不能任由大模型自由发挥。
|
||
|
||
## **三、 破局方案：“受限代码生成”范式 (The Architect's Bridge)**
|
||
|
||
为了兼顾你们想要的“灵活性（处理复杂数据操作）”和我要的“安全性（护栏与可审计）”，我提出 **“受限代码生成 (Constrained Code Generation)”** 架构。这是连接 Phase 1 和 Phase 3 的完美桥梁。
|
||
|
||
### **核心思想：把代码切分为“安全区”和“高危区”**
|
||
|
||
我们将用户的分析诉求分为两截：**【数据加工 (Data Wrangling)】** 和 **【核心检验 (Core Stats)】**。
|
||
|
||
#### **1\. 安全区：数据加工 (允许大模型自由发挥)**
|
||
|
||
* **场景**：过滤、重命名、衍生变量（如算 BMI）。
|
||
* **机制**：允许 LLM 基于 dplyr 生成 R 代码（这部分代码就算有幻觉，最多就是报错，不会产生错误的 P 值）。
|
||
* **安全措施**：使用 R 的 AST (抽象语法树) 解析器，在执行前扫描这段生成的代码，**白名单制**仅允许 mutate, filter, select, group\_by 等数据操作函数，发现任何可疑函数直接阻断。
|
||
|
||
#### **2\. 高危区：核心检验 (大模型仅能“填空”)**
|
||
|
||
* **场景**：跑 T 检验、画 KM 曲线。
|
||
* **机制**：LLM **不被允许**生成核心检验代码。它必须从你们那 100 个脚本库中，把“专家写好的模板”检索出来，然后把第一步处理好的数据输入进去。
|
||
|
||
### **💡 “受限代码智能”工作流示例**
|
||
|
||
1. **用户输入**：“把年龄大于 60 岁的人挑出来，算一下男女的血压差异。”
|
||
2. **LLM 理解与检索**：
|
||
* 检索到专家模板：ST\_T\_TEST\_IND.R。
|
||
3. **LLM 生成混合计划 (Hybrid Plan)**：
|
||
{
|
||
"data\_wrangling\_code": "df\_filtered \<- df %\>% filter(Age \> 60)",
|
||
"core\_tool": "ST\_T\_TEST\_IND",
|
||
"core\_params": { "group\_col": "Gender", "val\_col": "BloodPressure" }
|
||
}
|
||
|
||
4. **Executor 执行**：
|
||
* 在沙箱内，先行安全校验并执行 data\_wrangling\_code。
|
||
* 将清洗后的 df\_filtered 送入经过专家配置、带有强护栏的 ST\_T\_TEST\_IND 工具中执行。
|
||
|
||
**为什么这个方案好？**
|
||
|
||
它给了大模型处理复杂现实数据的\*\*“手脚”（数据清洗代码生成）**，但牢牢锁住了大模型的**“嘴巴”（核心统计检验的绝对严谨性）\*\*。
|
||
|
||
## **四、 针对 MVP 阶段的具体行动建议 (Action Items for NOW)**
|
||
|
||
既然我们对“三阶段演进”达成了共识，那么在眼下的 MVP 阶段，请务必执行以下微调：
|
||
|
||
### **1\. 改变 Prompt 的“世界观”**
|
||
|
||
在构建 Planner 的 Prompt 时，不要对 LLM 说“你是一个从列表里挑工具的接线员”，而是对它说：
|
||
|
||
"你是一个顶尖的数据科学家。你现在有一个包含 100 个高级统计算法的**专家代码库**。请理解用户意图，从代码库中找出最合适的代码模板，并制定数据传入策略。"
|
||
|
||
*(即便它现在只能输出 JSON 参数，这种世界观设定也会极大地提高它的推理质量。)*
|
||
|
||
### **2\. 构建向量库时，保留“代码片段”**
|
||
|
||
在专家填写 Excel 配置表时，不仅仅存入“工具名”和“适用场景”，把那 100 个 R 脚本的\*\*核心源代码片段（Core Snippet）\*\*也存入向量库。
|
||
|
||
在 RAG 检索时，把这些代码片段丢给 LLM。这为未来平滑过渡到 Phase 3 埋下伏笔。
|
||
|
||
### **3\. 先不碰动态代码执行**
|
||
|
||
MVP 阶段（乃至整个 Phase 2），请严格克制住“让 LLM 动态写代码并执行”的冲动。用我们确定的“混合模式（智能分析 \+ 宏脚本）”打透核心业务流，验证 PMF（产品市场契合度）。
|
||
|
||
## **五、 最终建议**
|
||
|
||
作为系统架构师，我必须为您详细拆解为什么在现阶段（MVP及打透核心业务流阶段）必须**严格克制**这种冲动：
|
||
|
||
### **1\. 安全层面的“达摩克利斯之剑”（RCE 风险）**
|
||
|
||
让 LLM 动态写代码并执行，本质上是在您的服务器上开了一个 **RCE（远程代码执行）** 的后门。
|
||
|
||
* 即使我们有那 100 个安全的脚本作为“参考库”，LLM 在修改时，极易受到恶意用户的“提示词注入（Prompt Injection）”攻击。
|
||
* 比如用户在上传的 CSV 数据里或者需求里藏入恶意指令，诱导 LLM 生成 `system("rm -rf /")` 或者窃取服务器环境变量的代码。如果没有极其昂贵和复杂的微虚拟机（MicroVM，如 Firecracker）做硬件级隔离，普通的 Docker 容器一旦被攻破，后果不堪设想。
|
||
|
||
### **2\. 医学统计的“静默谬误”（幻觉与合规灾难）**
|
||
|
||
在医疗和临床科研领域，**“跑通了”不等于“算对了”**。
|
||
|
||
* LLM 生成的代码哪怕语法完全正确，没有报错（Bug-free），它在统计学逻辑上也可能产生“幻觉”。
|
||
* 例如，它在拼接两段代码时，可能忘记了检查数据是否符合正态分布，或者搞错了混合效应模型的随机截距项。
|
||
* 这种错误极其隐蔽（静默谬误），系统会依然输出一个漂亮的 P 值。如果医生拿着这个错误的 P 值去发论文、做临床决策，一旦被查出，将会对您的平台声誉造成毁灭性打击。
|
||
|
||
### **3\. 运维与排错的“无底洞”（不可复现性）**
|
||
|
||
* 如果系统是由预设的“宏脚本”和“固定工具”组成的，当用户报 Bug 时，您可以立刻定位：“哦，是 T 检验的脚本第 45 行出错了”，您可以轻松修复。
|
||
* 如果代码是 LLM 每次**动态生成**的，那么每次执行的代码都是“阅后即焚”的孤品。一旦报错，您根本无法复现当时的场景，调试和维护成本将呈现指数级爆炸。
|
||
|
||
---
|
||
|
||
### **为什么我坚持用“混合模式（智能分析 \+ 宏脚本）”？**
|
||
|
||
因为这是一种 **“用大模型的智商，用人类专家的底线”** 的降维打击策略：
|
||
|
||
1. **大模型只做决策（不动手）**：让 LLM 做它最擅长的事——理解医生意图，阅读列名，从这 100 个工具里**选出最合适的一个或几个**，并把参数（JSON）填好。
|
||
2. **人类专家代码执行（守底线）**：真正跑计算的，是您的 R 工程师和统计专家精心打磨过、经过千百次测试的固定脚本（包括把多个固定脚本串联起来的“宏脚本套餐”）。
|
||
3. **用户体验完美**：在用户看来，他依然是“说了一句话，AI 帮他搞定了一切（哪怕是极度复杂的全流程）”，用户体验并没有打折，但背后的工程安全性提升了一万倍。
|
||
|
||
**总结来说：** 将那 100 个代码文件作为“可供 LLM 学习和动态修改的范例库”，这是极其超前的愿景，我们可以把它放在 **Phase 3（未来的终极形态）** 去探索。
|
||
|
||
但在眼下，我们要**打透核心业务流、让产品安全上线并赢得医生信任**，就必须将这 100 个文件视为“不可篡改的执行组件”。大模型可以作为调度员指挥它们，但绝不能赋予大模型在手术台上“随意切改代码”的权力。
|
||
|