Develop/AIclinicalresearch
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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:
HaHafeng
2026-02-21 18:15:53 +08:00
parent 428a22adf2
commit 371e1c069c
73 changed files with 9242 additions and 706 deletions
Download Patch File Download Diff File Expand all files Collapse all files

515
docs/03-业务模块/SSA-智能统计分析/00-模块当前状态与开发指南.md
View File

@@ -1,47 +1,19 @@
# SSA智能统计分析模块 - 当前状态与开发指南
> **文档版本：** v1.7
> **文档版本：** v2.0
> **创建日期：** 2026-02-18
> **最后更新：** 2026-02-20
> **最后更新：** 2026-02-21
> **维护者：** 开发团队
> **当前状态：** 🎉 **Phase 2A 前端集成完成！多步骤工作流端到端通过 + Block-based 架构共识达成**
> **当前状态：** 🎉 **QPER 智能化主线闭环完成！Q→P→E→R 端到端 40/40 通过**
> **文档目的：** 快速了解SSA模块状态，为新AI助手提供上下文
>
> **🎉 里程碑（2026-02-18）：**
> - ✅ **PRD 完成**：SSA-Pro 严谨型智能统计分析模块需求定义
> - ✅ **架构设计 V4 完成**：Brain-Hand 双层架构 + 统计护栏 + HITL 人机协同
> - ✅ **MVP 开发计划 v1.5 完成**：通过 5 轮评审，纳入完整专家配置体系
> - ✅ **5 份开发文档完成**：总览、任务清单、R服务指南、后端指南、前端指南
>
> **🎉 T 检验端到端测试通过（2026-02-19）：**
> - ✅ **🎉 完整流程验证**：数据上传 → 计划生成 → 分析执行 → 结果展示 → 代码下载
> - ✅ **R 服务 Bug 修复**：缺失值自动过滤，解决分组变量 3 组问题
> - ✅ **类型推断优化**：0/1 数字列正确识别为分类变量
> - ✅ **错误处理增强**：R 服务错误信息正确传递给前端
> - ✅ **文件名动态生成**：`{toolName}_{dataName}_{MMDD}_{HHmm}.R`
> - ✅ **前端模块激活**：智能统计分析入口可用
> - ✅ **用户会话隔离**：不同用户数据正确隔离
>
> **🎉 V11 UI 前后端联调测试通过（2026-02-20 上午）：**
> - ✅ **V11 UI 像素级还原**：Gemini 风格对话界面，全屏沉浸式体验
> - ✅ **多任务支持**：单会话内可执行多个分析任务，独立管理状态
> - ✅ **单页滚动布局**：分析计划 → 执行日志 → 分析结果，步骤进度条导航
> - ✅ **Word 报告导出**：完整统计报告，包含数据描述、方法、结果、图表、结论
>
> **🆕 🎉 Phase 2A 前端集成完成（2026-02-20 下午）：**
> - ✅ **多步骤工作流端到端**：数据上传 → 质量报告 → 多步骤规划 → SSE 实时执行 → 结果展示 → 报告/代码导出
> - ✅ **Python 数据质量服务集成**：CSV 直传 Python 解析，修复端口/环境变量问题
> - ✅ **意图识别增强**：正则提取变量名 + 变量类型判断 → 智能选择统计方法
> - ✅ **描述性统计完整支持**：专用 DescriptiveResultView 组件 + Word 导出
> - ✅ **6 个前端 Bug 修复**：SAP 误显示、布局混乱、SSE 卡死、结果丢失等
> - ✅ **Block-based 架构共识达成**：4 种 Block 类型，R 输出标准化 → Node.js 零维护 → 前端动态渲染
>
> **🆕 v1.5 新增特性（专家配置体系）：**
> - 🆕 **统计决策表**：(Goal, Y, X, Design) 四维匹配精准选工具，替代简单 RAG
> - 🆕 **R 代码库**：支持上传 100+ 成熟 R 脚本，统一 `run_analysis()` 入口
> - 🆕 **参数映射配置**：JSON Key → R 参数名可配置
> - 🆕 **护栏规则链**：支持 Block / Warn / Switch 三种 Action
> - 🆕 **结果解读模板**："填空题"式的论文级结论生成
> **🎉 重大里程碑（2026-02-21）：**
> - ✅ **QPER 四层架构主线闭环** — Phase E+ / Q / P / R 全部完成，93.5h 计划工时
> - ✅ **端到端测试 40/40 通过** — 两条完整链路（差异比较 + 相关分析）全部跑通
> - ✅ **LLM 智能意图理解** — 自然语言→四维信息提取，Confidence=0.95
> - ✅ **配置化决策表驱动** — JSON 驱动方法选择，热更新 API，方法学团队可配置
> - ✅ **LLM 论文级结论生成** — 6 要素结论 + 槽位注入反幻觉 + Zod 强校验 + 敏感性冲突准则
> - ✅ **四层降级体系** — 每层 LLM 失败时自动 fallback，系统不中断
---
@@ -53,379 +25,186 @@
|------|------|
| **模块名称** | SSA - 智能统计分析 (Smart Statistical Analysis) |
| **模块定位** | AI驱动的"白盒"统计分析系统 |
| **架构模式** | **QPER — Query → Planner → Execute → Reflection** |
| **商业价值** | ⭐⭐⭐⭐⭐ 极高 |
| **独立性** | ⭐⭐⭐⭐ 高（可独立使用，也可与其他模块协同） |
| **目标用户** | 临床研究人员、生物统计师 |
| **开发状态** | 🎉 **Phase 2A 完成，多步骤工作流端到端通过（开发 ~95%）** |
| **开发状态** | 🎉 **QPER 主线闭环完成，Phase Deploy 待启动** |
### 核心目标
> 打造一个 **"白盒"、"严谨"、"可交付"** 的智能统计分析系统。
> 让**不懂统计的医生**完成**专业级的统计分析**。
>
> **核心差异化**：
> **三大特征**：
> 1. **白盒**：用户完全理解 AI 做了什么，为什么这样做
> 2. **严谨**：统计护栏自动检测前提条件，违规时自动降级
> 3. **可交付**：生成可在本地运行的 R 代码，支持审计复现
### 功能规格
#### 核心AI能力（规划中）
1. **智能规划（Planner）**
- 🆕 **决策表匹配**：(Goal, Y, X, Design) 四维精准选工具
- RAG 工具检索：作为决策表的兜底方案
- 参数映射：将自然语言映射为统计参数（可配置）
- 统计分析计划（SAP）生成
2. **统计护栏（Guardrails）**
- 正态性检验（Shapiro-Wilk）
- 方差齐性检验（Levene）
- 样本量检验
- 大样本优化（N > 5000 抽样检验）
- 🆕 **护栏 Action**：Block（阻止） / Warn（警告） / Switch（切换方法）
3. **人机协同（HITL）**
- Plan Card：用户确认/修改分析计划
- Execution Trace：实时展示执行路径
- Result Card：结构化结果 + AI 解读
4. **代码交付**
- 生成可复现的 R 代码
- 自动注入依赖安装脚本
- APA 格式化输出（p_value_fmt）
5. **🆕 咨询模式**
- 无数据对话：用户只描述研究设计
- SAP 文档生成：结构化统计分析计划
- 多格式导出：Word/Markdown
6. **🆕 配置中台（专家知识库）**
- 🆕 **统计决策表**：Goal + Y + X + Design → Tool 映射
- 🆕 **R 代码库**：100+ 成熟脚本上传，统一 `run_analysis()` 入口
- 🆕 **参数映射**：JSON Key → R 参数名 + 校验规则
- 🆕 **护栏规则链**：Check → Threshold → Action (Block/Warn/Switch)
- 🆕 **结果解读模板**："填空题"式论文级结论
- Excel 配置导入 + 热加载 + 配置校验
#### MVP 工具清单（10个）
| 工具代码 | 工具名称 | 适用场景 |
|---------|---------|---------|
| ST_T_TEST_IND | 独立样本T检验 | 两组连续变量比较 |
| ST_T_TEST_PAIRED | 配对样本T检验 | 配对设计 |
| ST_WILCOXON | Wilcoxon秩和检验 | T检验的非参数替代 |
| ST_ANOVA_ONE | 单因素方差分析 | 多组连续变量比较 |
| ST_CHI_SQUARE | 卡方检验 | 分类变量关联 |
| ST_FISHER | Fisher精确检验 | 小样本分类变量 |
| ST_CORRELATION | Pearson/Spearman相关 | 连续变量相关性 |
| ST_REGRESSION_LINEAR | 线性回归 | 预测建模 |
| ST_REGRESSION_LOGISTIC | Logistic回归 | 二分类预测 |
| ST_DESCRIBE | 描述性统计 | 数据概览 |
> 3. **可交付**：生成论文级结论 + 可在本地运行的 R 代码，支持审计复现
---
## 🏗️ 架构设计
### Brain-Hand 双层架构 + 配置中台
## 🏗️ QPER 四层架构
```
┌─────────────────────────────────────────────────────────┐
│ 用户界面 (Frontend) │
│ 🆕 ModeSwitch | DataUploader | PlanCard | ResultCard │
│ ↓ 智能分析 ↓ 咨询模式 │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ Planner (Brain/大脑) - Node.js │
│ ┌─────────────────────────────────────────────────────┐│
│ │ DataParserService: 数据解析 → Schema 提取 ││
│ │ ToolRetrievalService: RAG 工具检索 ││
│ │ PlannerService: LLM 规划（有数据） ││
│ │ 🆕 ConsultService: 无数据咨询 ││
│ │ 🆕 SAPGeneratorService: SAP 文档生成 ││
│ │ CriticService: 结果解读（流式） ││
│ └─────────────────────────────────────────────────────┘│
│ 📌 只看 Schema，支持有数据/无数据两种模式 │
└─────────────────────────────────────────────────────────┘
↓ (仅智能分析模式)
┌─────────────────────────────────────────────────────────┐
│ Executor (Hand/四肢) - R Docker │
│ ┌─────────────────────────────────────────────────────┐│
│ │ data_loader.R: 混合数据协议（inline/OSS） ││
│ │ guardrails.R: 统计护栏（正态/方差齐性/样本量） ││
│ │ tools/*.R: 统计工具 Wrapper（glue 模板） ││
│ │ result_formatter.R: 结果格式化（p_value_fmt） ││
│ │ error_codes.R: 结构化错误码 ││
│ └─────────────────────────────────────────────────────┘│
│ 📌 操作真实数据 + 生成可复现代码 │
└─────────────────────────────────────────────────────────┘
▲
┌─────────────────────────────────────────────────────────┐
│ 🆕 配置中台 (Config Center) │
│ ┌─────────────────────────────────────────────────────┐│
│ │ ConfigLoaderService: Excel 配置加载 ││
│ │ ConfigValidatorService: 配置校验 ││
│ │ ConfigCacheService: 配置缓存 + 热加载 ││
│ └─────────────────────────────────────────────────────┘│
│ 📌 统计专家可配置，系统动态加载 │
└─────────────────────────────────────────────────────────┘
用户："比较两组血压有没有差别"
│
▼
┌─ Q · Query ─────────────────────────────────────┐
│ LLM 意图解析 + Zod 动态防幻觉 + 追问卡片 │
│ 输出：ParsedQuery { goal, y, x, design } │
└──────────────────────┬──────────────────────────┘
▼
┌─ P · Planner ────────────────────────────────────┐
│ 决策表四维匹配 + 流程模板填充 + EPV 防护 │
│ 输出：WorkflowPlan + PlannedTrace │
└──────────────────────┬──────────────────────────┘
▼
┌─ E · Execute ────────────────────────────────────┐
│ R 引擎执行 + SSE 实时进度 + Block-based 输出 │
│ 输出：StepResult[] + ReportBlock[] │
└──────────────────────┬──────────────────────────┘
▼
┌─ R · Reflection ─────────────────────────────────┐
│ LLM 论文级结论 + 槽位注入 + Zod 校验 │
│ 输出：ConclusionReport（6 要素） │
└──────────────────────────────────────────────────┘
```
### 关键技术决策
### 降级体系
| 决策点 | 方案 | 理由 |
|--------|------|------|
| **R 服务部署** | SAE Docker（固定 2 实例） | 避免冷启动延迟 |
| **数据传输** | 混合协议（<2MB inline, 2-20MB OSS） | 平衡性能与内存 |
| **代码生成** | glue 模板 | 可维护性好于 paste0 |
| **LLM 输出** | jsonrepair + Zod | 容错 JSON 解析 |
| **隐私保护** | Schema 脱敏 + 分类变量稀有值隐藏 | 防止 LLM 泄露数据 |
| **🆕 结果渲染** | Block-based 协议（4 种 Block） | R 端标准化输出 → Node.js 零维护 → 前端动态渲染 |
| 层 | 正常路径 | 降级路径 | 触发条件 |
|----|---------|---------|---------|
| Q | QueryService（LLM） | 正则匹配 fallback | LLM 超时/不可用 |
| P | DecisionTable + FlowTemplate | 硬编码 if/else | 决策表无匹配 |
| E | R 引擎 | 错误分类→友好提示 | R 运行时崩溃 |
| R | ReflectionService（LLM） | ConclusionGeneratorService（规则拼接） | LLM 失败/Zod 校验失败 |
---
## 📋 开发进度
| Phase | 任务 | 状态 | 完成日期 |
|-------|------|------|---------|
| Phase 0 | 需求分析与架构设计 | ✅ 已完成 | 2026-02-18 |
| Phase 0 | MVP 开发计划 v1.0 → v1.6 | ✅ 已完成 | 2026-02-19 |
| Phase 1 | 骨架搭建 + 配置中台 | ✅ **核心完成 95%** | 2026-02-19 |
| Phase 2A | 智能核心（多步骤工作流 + 意图识别） | ✅ **前端集成完成** | 2026-02-20 |
| Phase 2B | Block-based 动态渲染重构 | 📋 计划已制定 | - |
| Phase 2 | 智能规划 + 咨询模式 | 📋 待开始 | - |
| Phase 3 | 完善与联调 | 📋 待开始 | - |
| Phase | 任务 | 工时 | 状态 | 完成日期 |
|-------|------|------|------|---------|
| Phase 0 | 需求分析与架构设计 | - | ✅ 已完成 | 2026-02-18 |
| Phase 1 | 骨架搭建（T 检验端到端） | - | ✅ 已完成 | 2026-02-19 |
| Phase 1.5 | V11 UI 前后端联调 | - | ✅ 已完成 | 2026-02-20 |
| Phase 2A | 多步骤工作流 + 前端集成 | - | ✅ 已完成 | 2026-02-20 |
| **Phase E+** | **Block-based 标准化** | **15.5h** | ✅ **已完成** | 2026-02-20 |
| **Phase Q** | **LLM 意图理解** | **33h** | ✅ **已完成** | 2026-02-21 |
| **Phase P** | **决策表 + 流程模板** | **23h** | ✅ **已完成** | 2026-02-21 |
| **Phase R** | **LLM 论文级结论** | **22h** | ✅ **已完成** | 2026-02-21 |
| Phase Deploy | 工具补齐 + 部署上线 | 37h | 📋 待开始 | - |
| Phase Q+ | 人机协同增强 | 20h | 📋 待开始 | - |
### 🎉 已完成核心功能
### 已完成核心功能
| 组件 | 完成项 | 状态 |
|------|--------|------|
| **R 服务** | T 检验、描述性统计、卡方检验、Logistic 回归、相关分析、错误码、护栏 | ✅ 100% |
| **后端** | 路由、RClientService、DataProfileService、WorkflowPlannerService、WorkflowExecutorService、SSE | ✅ 95% |
| **前端** | V11 UI、多步骤工作流、DescriptiveResultView、R 代码/Word 导出、SSE 实时进度 | ✅ 95% |
| **Python 服务** | 数据质量分析（JSON + CSV 双端点） | ✅ 100% |
| **配置中台** | 数据库表、热加载 API | 🔄 18% |
### 开发计划文档
| 文档 | 路径 | 说明 |
|------|------|------|
| **MVP总览** | `04-开发计划/00-MVP开发计划总览.md` | 范围、架构、里程碑 |
| **任务清单** | `04-开发计划/01-任务清单与进度追踪.md` | 可追踪的 TODO 列表 |
| **R服务指南** | `04-开发计划/02-R服务开发指南.md` | R 统计工程师专用 |
| **后端指南** | `04-开发计划/03-后端开发指南.md` | Node.js 工程师专用 |
| **前端指南** | `04-开发计划/04-前端开发指南.md` | 前端工程师专用 |
| **🆕 Block-based 渲染** | `04-开发计划/08-Block-based动态结果渲染开发计划.md` | 动态结果渲染架构重构 |
### 评审记录
| 版本 | 评审报告 | 结论 | 日期 |
|------|---------|------|------|
| v1.0 | `06-开发记录/SSA-Pro 方案深度审查与风险评估报告.md` | 需修订 | 2026-02-18 |
| v1.1 | `06-开发记录/SSA-Pro 方案深度审查与风险评估报告 V2.0.md` | 需修订 | 2026-02-18 |
| v1.2 | `06-开发记录/SSA-Pro V1.2 终极审查与发令报告V3.0.md` | 🟢 通过 | 2026-02-18 |
| v1.4 | 🆕 纳入双引擎 + 咨询模式 + 配置中台 | 🟢 通过 | 2026-02-18 |
| **R 服务** | 7 个 R 工具（T 检验、描述统计、卡方、Logistic、相关分析等）+ Block-based 输出 | ✅ |
| **Q 层** | QueryService + LLM Intent + Zod 动态防幻觉 + 追问卡片 + DataProfile 增强 | ✅ |
| **P 层** | ConfigLoader + DecisionTable + FlowTemplate + PlannedTrace + 热更新 API | ✅ |
| **E 层** | WorkflowExecutor + RClient + SSE 实时进度 + 错误分类映射 | ✅ |
| **R 层** | ReflectionService + 槽位注入 + Zod 校验 + 敏感性冲突准则 + 结论缓存 + Word 增强 | ✅ |
| **前端** | V11 UI + DynamicReport + ClarificationCard + ConclusionReport（渐入动画）+ Word/R 代码导出 | ✅ |
| **Python** | DataProfileService（is_id_like 标记）+ CSV 解析 | ✅ |
| **测试** | QPER 端到端测试 40/40 通过 | ✅ |
---
## 🔧 技术依赖
## 📂 代码目录结构
### 复用的平台能力
```
backend/src/modules/ssa/
├── services/
│ ├── QueryService.ts # Q 层：LLM 意图解析
│ ├── DecisionTableService.ts # P 层：四维匹配
│ ├── FlowTemplateService.ts # P 层：流程模板
│ ├── WorkflowPlannerService.ts # P 层：核心规划入口
│ ├── WorkflowExecutorService.ts # E 层：步骤编排 + SSE
│ ├── RClientService.ts # E 层：R 引擎调用
│ ├── ReflectionService.ts # R 层：LLM 结论生成
│ ├── ConclusionGeneratorService.ts # R 层 fallback
│ ├── DataProfileService.ts # 共享：Python 数据质量
│ └── DataParserService.ts # 共享：文件解析
├── config/
│ ├── ConfigLoader.ts # 通用 JSON 加载 + Zod 校验
│ ├── tools_registry.json # R 工具注册表
│ ├── decision_tables.json # 四维匹配规则
│ └── flow_templates.json # 流程模板
├── types/
│ ├── query.types.ts # Q 层接口
│ └── reflection.types.ts # R 层接口
├── routes/
│ ├── workflow.routes.ts # 工作流 API（含结论缓存）
│ └── config.routes.ts # 热更新 API
└── ...
| 能力 | 位置 | 用途 |
|------|------|------|
| **LLM网关** | `@/common/llm/LLMFactory` | Planner + Critic |
| **RAG引擎** | `@/common/rag` | 工具检索 |
| **存储** | `@/common/storage` | OSS 数据传输 |
| **日志** | `@/common/logging` | 结构化日志 |
| **流式响应** | `@/common/streaming` | Critic 流式输出 |
backend/scripts/
├── seed-ssa-intent-prompt.ts # Q 层 Prompt 种子
├── seed-ssa-reflection-prompt.ts # R 层 Prompt 种子
├── test-ssa-qper-e2e.ts # QPER 端到端测试
└── ...
```
### LLM模型
---
| 模型 | 用途 | 说明 |
|------|------|------|
| DeepSeek-V3 | Planner + Query Rewriter | 性价比高 |
| Qwen3-rerank | 工具重排序 | 中文理解好 |
| GPT-5-Pro | Critic 结果解读 | 深度推理 |
## 🔧 开发环境
### R 依赖
### 启动服务
| 包 | 版本 | 用途 |
|-----|------|------|
| plumber | 1.2.1 | Web API 框架 |
| jsonlite | 1.8.8 | JSON 处理 |
| ggplot2 | 3.4.4 | 可视化 |
| glue | 1.7.0 | 模板代码生成 |
| car | 3.1-2 | Levene 检验 |
| httr | 1.4.7 | OSS 下载 |
```bash
# 1. 数据库（Docker）
docker start ai-clinical-postgres
# 2. Python 服务
cd extraction_service && python main.py
# 3. R 服务
cd r-statistics-service && Rscript plumber_api.R
# 4. Node.js 后端
cd backend && npm run dev
# 5. 前端
cd frontend-v2 && npm run dev
```
### 运行测试
```bash
cd backend
npx tsx scripts/test-ssa-qper-e2e.ts
```
### Prompt 种子（需数据库运行）
```bash
cd backend
npx tsx scripts/seed-ssa-intent-prompt.ts
npx tsx scripts/seed-ssa-reflection-prompt.ts
```
---
## 📚 相关文档
### 需求文档
- [PRD SSA-Pro 严谨型智能统计分析模块](./00-系统设计/PRD%20SSA-Pro%20严谨型智能统计分析模块.md)
### 设计文档
- [SSA-Pro 严谨型智能统计分析架构设计方案V4](./00-系统设计/SSA-Pro%20严谨型智能统计分析架构设计方案V4.md) ⬅️ **核心架构文档**
- [SSA-Pro (V4.1) 统计技能中心架构规范](./00-系统设计/SSA-Pro%20(V4.1)%20统计技能中心架构规范.md)
### 原型文件
- [智能统计分析V2.html](./03-UI设计/智能统计分析V2.html) - 可直接浏览器打开
### 参考文档
- [云原生开发规范](../../04-开发规范/08-云原生开发规范.md)
- [系统架构分层设计](../../00-系统总体设计/01-系统架构分层设计.md)
| 文档 | 路径 |
|------|------|
| **QPER 开发计划（主线）** | `04-开发计划/10-QPER架构开发计划-智能化主线.md` |
| **QPER 开发总结** | `06-开发记录/SSA-QPER架构开发总结-2026-02-21.md` |
| **智能化愿景设计** | `00-系统设计/SSA-Pro 理想状态与智能化愿景设计.md` |
| **PRD** | `00-系统设计/PRD SSA-Pro 严谨型智能统计分析模块.md` |
| **架构设计 V4** | `00-系统设计/SSA-Pro 严谨型智能统计分析架构设计方案V4.md` |
---
## 🎯 快速开始
## 🎯 下一步
### 目录结构
```
docs/03-业务模块/SSA-智能统计分析/
├── 00-系统设计/ # PRD + 架构设计
├── 01-需求分析/ # 用户故事、用例
├── 02-技术设计/ # 详细技术方案
├── 03-UI设计/ # 原型图
├── 04-开发计划/ # MVP 开发文档（5份）
├── 05-测试用例/ # 测试方案
└── 06-开发记录/ # 评审报告、开发日志
```
### 开发环境准备
1. **R 服务环境**
```bash
cd r-statistics-service
docker build -t ssa-r-service .
docker run -p 8080:8080 -e DEV_MODE=true ssa-r-service
```
2. **后端开发**
```bash
cd backend
npm run dev
```
3. **前端开发**
```bash
cd frontend-v2
npm run dev
```
### API 接口预览
#### 智能分析模式
```http
### 创建会话
POST http://localhost:3001/api/v1/ssa/sessions
Content-Type: multipart/form-data
# file: 数据文件
### 生成分析计划
POST http://localhost:3001/api/v1/ssa/sessions/{sessionId}/plan
Content-Type: application/json
{"query": "比较两组GLU是否有显著差异"}
### 执行分析
POST http://localhost:3001/api/v1/ssa/sessions/{sessionId}/execute
Content-Type: application/json
{"plan": {...}, "debug": false}
### 获取结果
GET http://localhost:3001/api/v1/ssa/sessions/{sessionId}/result
```
#### 🆕 咨询模式
```http
### 创建咨询会话（无数据）
POST http://localhost:3001/api/v1/ssa/consult
### 咨询对话
POST http://localhost:3001/api/v1/ssa/consult/{sessionId}/chat
Content-Type: application/json
{"message": "我有一个双臂 RCT 研究，想比较主要终点..."}
### 生成 SAP 文档
POST http://localhost:3001/api/v1/ssa/consult/{sessionId}/generate-sap
### 下载 SAP
GET http://localhost:3001/api/v1/ssa/consult/{sessionId}/download-sap?format=word
```
#### 🆕 配置中台
```http
### 导入 Excel 配置
POST http://localhost:3001/api/v1/ssa/config/import
Content-Type: multipart/form-data
# file: config.xlsx
### 热加载配置
POST http://localhost:3001/api/v1/ssa/config/reload
### 获取工具列表
GET http://localhost:3001/api/v1/ssa/config/tools
```
1. **Phase Deploy（37h）** — 补齐 ANOVA / Fisher / Wilcoxon / 线性回归 + 复合工具 ST_BASELINE_TABLE + 部署上线
2. **Phase Q+（20h）** — 变量数据字典（AI 先猜用户微调）+ 变量选择确认面板（AI 推荐医生确认）
3. **前端集成测试** — 用户手动测试 QPER 全链路的真实交互体验
---
## ⚠️ 注意事项
### 对新AI助手
1. ✅ **设计文档已完成**：开发前请先阅读架构设计V4
2. ✅ **开发计划v1.4已审批**：遵循5份开发文档进行开发
3. ⚠️ **Planner/Executor 分离**：代码目录按 planner/executor 组织
4. ⚠️ **Brain-Hand 隔离**：Node.js 只看 Schema，R 操作真实数据
5. ⚠️ **支持无数据模式**：咨询模式下 Planner 可独立工作
6. ⚠️ **配置外置**：工具定义从 Excel 加载，不硬编码
7. ⚠️ **混合数据协议**：< 2MB inline，2-20MB OSS
8. ⚠️ **代码模板同步**：修改 Wrapper 逻辑时必须同步更新 templates/
### 风险与应对
| 风险 | 概率 | 应对策略 |
|------|------|---------|
| R 工具封装进度慢 | 高 | 先做 5 个核心工具，glue 模板化开发 |
| LLM 输出 JSON 格式错误 | 中 | jsonrepair + Zod 强校验 |
| R 服务并发阻塞 | 中 | SAE 固定 2 实例 |
| Node.js xlsx 内存刺客 | 中 | SAE 内存上限 2GB+ |
| R 服务 Segfault 崩溃 | 低 | Liveness Probe + 502/504 友好提示 |
| 本地开发 OSS 不通 | 中 | DEV_MODE 读取本地 fixtures |
| 用户代码缺依赖 | 高 | 模板头部自动安装脚本 |
---
## 🚀 未来规划
### MVP 阶段（当前）
- [x] Phase 1：骨架搭建（T检验端到端跑通）✅ 2026-02-19
- [x] Phase 1.5：V11 UI 前后端联调 ✅ 2026-02-20
- [x] Phase 2A：智能核心（多步骤工作流 + 前端集成）✅ 2026-02-20
- [ ] Phase 2B：Block-based 动态渲染重构（~2.5 天）
- [ ] Phase 2：智能与交互（RAG + HITL + 10工具）
- [ ] Phase 3：打磨与调试（性能优化 + Bug修复）
### V2.0 阶段（规划中）
- [ ] 更多统计方法（Meta分析、生存分析、倾向性评分）
- [ ] 自定义工具上传
- [ ] 批量分析
- [ ] 报告导出（Word/PDF）
---
**文档版本：** v1.7
**最后更新：** 2026-02-20
**当前状态：** 🎉 Phase 2A 前端集成完成，多步骤工作流端到端通过
**下一步：** Phase 2B Block-based 动态渲染重构（4 种 Block 类型 → R/Node.js/前端全链路改造）
**文档版本：** v2.0
**最后更新：** 2026-02-21
**当前状态：** 🎉 QPER 主线闭环完成，端到端 40/40 通过
**下一步：** Phase Deploy 工具补齐 + 部署上线

400
docs/03-业务模块/SSA-智能统计分析/04-开发计划/09-智能化差距分析与演进路线图.md Normal file
View File

@@ -0,0 +1,400 @@
# SSA-Pro 智能化差距分析与演进路线图
> **文档版本：** v1.0
> **创建日期：** 2026-02-20
> **基准文档：** `00-系统设计/SSA-Pro 理想状态与智能化愿景设计.md`
> **当前状态：** Phase 2A 前端集成完成，多步骤工作流端到端通过
> **文档目的：** 明确当前系统与理想智能化之间的差距，规划演进路径
---
## 1. 执行摘要
### 核心结论
**当前系统已搭好"四肢"（R 执行 + SSE 实时进度 + 前端展示 + Word/R 导出），但缺少"大脑"（LLM 意图理解 + 决策表规划 + 论文级结论生成）。**
| 维度 | 当前状态 | 理想状态 | 差距 |
|------|---------|---------|------|
| 用户输入 | 用户需了解变量名和分析意图 | 用自然语言描述临床问题即可 | 🔴 大 |
| 方法选择 | 硬编码 if/else 规则 | 决策表四维匹配 + LLM 兜底 | 🔴 大 |
| 流程规划 | 从零拼装步骤列表 | 预定义流程模板 + 数据驱动调整 | 🔴 大 |
| 执行引擎 | 顺序执行，各步独立 | 结果串联 + 护栏降级 + 可中断 | 🟡 中 |
| 结果输出 | 数值表格 + 基础图表 | 论文级综合结论 + 方法学说明 | 🔴 大 |
### 智能化等级评估
```
L1 单方法执行 ████████████████████ 100% ✅ 已完成（2026-02-19）
L2 智能选方法 ███████░░░░░░░░░░░░░ 35% 🟡 有规则匹配，缺决策表和 LLM
L3 数据自适应 ████░░░░░░░░░░░░░░░░ 20% 🔴 护栏在 R 内部，未与规划联动
L4 流程编排 ████████░░░░░░░░░░░░ 40% 🟡 多步骤能跑，缺模板和串联
L5 论文级输出 ███░░░░░░░░░░░░░░░░░ 15% 🔴 缺 LLM 结论生成
```
---
## 2. 五大核心组件差距详析
### 2.1 意图理解器 (Intent Parser) — 完成度 20%
**理想状态：**
- LLM 从用户自然语言中提取四维信息：Goal / Y_Type / X_Type / Design
- 不确定时主动追问澄清（展示选择卡片）
- 支持模糊输入："有没有效"、"帮我分析一下"
**当前实现：**
- `WorkflowPlannerService.parseUserIntent()` — 正则匹配关键词
- "相关" → correlation，"影响" → regression，"比较" → comparison
- 变量名通过正则从用户文本中提取，与 DataProfile 变量列表交叉匹配
- 变量类型通过 DataProfile 判断（categorical / numeric）
**差距明细：**
| 能力 | 理想 | 当前 | 状态 |
|------|------|------|------|
| Goal 分类 | Difference / Association / Prediction / Description | 关键词硬编码 | 🔴 |
| Y/X 类型提取 | LLM 自动识别结局变量和自变量 | 正则提取变量名 | 🟡 |
| Design 识别 | 独立 / 配对 / 重复测量 | 不支持 | 🔴 |
| 模糊理解 | "有没有效" → 差异比较 | 需要用户说"比较" | 🔴 |
| 追问澄清 | 展示选择卡片让用户确认 | 不追问，直接猜测 | 🔴 |
| 多目标识别 | 识别多个分析目标并分拆 | 不支持 | 🔴 |
**关键缺失文件/服务：**
- `IntentParserService`（LLM 驱动的意图解析，替代当前的 `parseUserIntent` 方法）
- 前端追问卡片组件（当 AI 不确定时展示选项）
---
### 2.2 数据诊断器 (Data Diagnostician) — 完成度 30%
**理想状态：**
- 独立的"数据体检报告"模块
- 检测项：正态性、方差齐性、缺失比例、异常值、样本量、分组平衡性
- 诊断结果直接传递给路径规划器，影响方法选择
**当前实现：**
- Python `DataProfileService`：变量类型推断、缺失率、基本统计量、唯一值
- R `guardrails.R`：在方法执行时检查正态性（Shapiro-Wilk）和方差齐性（Levene）
- 前端 `DataProfileCard` + `DataProfileModal`：展示数据概况
**差距明细：**
| 检测项 | 理想 | 当前 | 状态 |
|--------|------|------|------|
| 变量类型推断 | 自动识别 | Python DataProfile ✅ | ✅ |
| 缺失值统计 | 占比 + 建议处理策略 | 有占比，无处理建议 | 🟡 |
| 正态性检验 | 独立模块，结果传递给 Planner | R 内部执行，不回传 | 🔴 |
| 方差齐性 | 独立模块，结果传递给 Planner | R 内部执行，不回传 | 🔴 |
| 异常值检测 | IQR 方法 + 可视化标注 | 不检测 | 🔴 |
| 样本量评估 | 功效分析建议 | 不评估 | 🔴 |
| 分组平衡性 | 各组比例 + 提示不平衡 | 不检测 | 🔴 |
| 诊断→规划联动 | 自动影响方法选择 | 完全割裂 | 🔴 |
**关键问题：**
- 数据诊断（Python DataProfile）和统计前提检查（R guardrails）是两个独立系统
- R 护栏在执行时发现正态性不满足时自动降级（如 T→Wilcoxon），但不通知 Planner
- Planner 做规划时不知道数据特征，全凭变量类型硬编码选方法
---
### 2.3 路径规划器 (Pathway Planner) — 完成度 15%
**理想状态：**
- 决策表匹配：(Goal, Y_Type, X_Type, Design) → 精准选工具
- 流程模板：预定义标准分析流程（如"两组差异比较 = 清洗 → 描述 → 正态检验 → [T/U] → 效应量 → 可视化"）
- 数据驱动调整：根据诊断结果动态修改流程
- 生成完整的 SAP（统计分析计划）供用户确认
**当前实现：**
- `WorkflowPlannerService.generateSteps()` — 硬编码 if/else 链
- 如果 `analysisType === 'comparison'` 且 Y 是连续 → 加 T 检验步骤
- 总是先加描述性统计步骤
- 输出 `WorkflowPlan { title, steps[] }` 结构
**差距明细：**
| 能力 | 理想 | 当前 | 状态 |
|------|------|------|------|
| 决策表匹配 | 四维精准匹配 | 硬编码 if/else | 🔴 |
| 流程模板 | 5-8 个预定义模板 | 无模板概念 | 🔴 |
| 数据驱动调整 | 诊断结果影响规划 | 不参考诊断结果 | 🔴 |
| SAP 生成 | 结构化计划文档 | 简单步骤列表 | 🔴 |
| 敏感性分析 | 自动添加补充分析 | 不支持 | 🔴 |
| 效应量步骤 | 自动包含 | 不支持 | 🔴 |
| 可视化步骤 | 自动规划图表 | 不支持（R 内部生成） | 🟡 |
**关键缺失文件/服务：**
- `DecisionTableService` — 决策表加载和四维匹配
- `FlowTemplateService` — 流程模板管理
- 决策表 Excel 配置文件
- 流程模板配置文件
---
### 2.4 流程执行器 (Workflow Executor) — 完成度 40%
**理想状态：**
- 按 SAP 定义的顺序执行多个方法
- 上一步输出作为下一步输入（结果串联）
- 护栏检查失败时自动降级方法
- 每步实时反馈中间结果
- 用户可暂停/跳过/取消
**当前实现：**
- `WorkflowExecutorService.executeWorkflow()` — 顺序遍历 steps 数组
- 每步独立调用 R 服务（通过 `RClientService`）
- SSE 实时推送 `step_start` / `step_complete` / `workflow_complete`
- 前端实时展示执行日志和结果（terminal-box + 结果卡片）
**差距明细：**
| 能力 | 理想 | 当前 | 状态 |
|------|------|------|------|
| 顺序执行 | ✅ | ✅ | ✅ |
| SSE 实时反馈 | ✅ | ✅ | ✅ |
| 步骤级结果展示 | ✅ | ✅ | ✅ |
| 结果串联 | 上步输出 → 下步输入 | 各步独立执行 | 🔴 |
| 护栏降级 | 失败时自动切换方法 | 不支持 | 🔴 |
| 暂停/跳过/取消 | 用户可控 | 一旦开始无法中断 | 🔴 |
| 错误恢复 | 某步失败提供重试选项 | 失败则标记 failed | 🟡 |
| 步骤间数据共享 | 共享清洗后数据集 | 每步重新加载原始数据 | 🔴 |
**这是完成度最高的组件**，架构基础已就位，需要补充的是上层能力。
---
### 2.5 结论生成器 (Conclusion Generator) — 完成度 15%
**理想状态：**
- 论文级综合结论，包含 6 个要素：
1. 样本描述（纳入/排除）
2. 主要结果（核心统计量 + P 值）
3. 效应解读（效应量含义）
4. 敏感性分析（结果稳健性）
5. 方法学说明（为什么选这个方法）
6. 局限性声明（数据处理说明）
- LLM 生成自然语言结论
**当前实现：**
- `ConclusionGeneratorService` 存在但功能有限
- 前端展示：统计量数值、P 值、效应量（数字形式）
- Word 导出：executive_summary + 各步骤统计量表格
**差距明细：**
| 结论要素 | 理想 | 当前 | 状态 |
|----------|------|------|------|
| 样本描述 | "共纳入 186 例，剔除 14 例..." | 无 | 🔴 |
| 主要结果 | LLM 自然语言描述 | 数字展示（P=0.015） | 🔴 |
| 效应解读 | "中等程度效应" | 数字展示（r=0.52） | 🔴 |
| 敏感性分析 | "T 检验得到一致结论" | 不支持 | 🔴 |
| 方法学说明 | "因不满足正态性..." | 无 | 🔴 |
| 局限性声明 | 自动生成 | 无 | 🔴 |
| 多步骤整合 | 综合所有步骤生成报告 | 各步骤独立展示 | 🟡 |
| 可发表质量 | 直接用于论文 | 需大量人工整理 | 🔴 |
**关键缺失：**
- LLM 结论生成 Prompt（调用 GPT/DeepSeek 生成论文级文字）
- 结果解读模板（"填空题"式结论模板）
- 多步骤结果整合逻辑
---
## 3. 已完成的基础设施（不需要重做）
在规划演进路径之前，确认以下基础已就位，无需重复建设：
| 基础设施 | 状态 | 说明 |
|----------|------|------|
| R 统计引擎 | ✅ | Docker 部署，7 个工具，plumber API |
| Node.js 后端框架 | ✅ | 路由、Service 架构、SSE |
| 前端 V11 UI | ✅ | 三栏布局、对话式交互、结果展示 |
| SSE 实时通信 | ✅ | 前后端消息格式已对齐 |
| 数据上传 + OSS | ✅ | 文件上传、预签名 URL |
| Python 数据质量 | ✅ | 变量类型推断、基础统计 |
| R 代码导出 | ✅ | 多步骤聚合导出 |
| Word 报告导出 | ✅ | docx 库，多步骤报告 |
| R 护栏系统 | ✅ | 正态性、方差齐性检查（R 内部） |
| Block-based 协议 | 📋 | 规范已制定，待实施（2.5 天） |
---
## 4. 演进路线图
### 4.1 推荐路径（按投入产出比排序）
```
当前状态（Phase 2A 完成，L1-L2 之间）
│
│ ① LLM 意图理解 + 决策表匹配 (~5天)
│ - IntentParserService: LLM 提取 Goal/Y/X/Design
│ - DecisionTableService: 四维 → 工具精准匹配
│ - 前端追问卡片组件
▼
L2 完成: 智能选方法
│ 「用户不再需要知道 T 检验、卡方检验是什么」
│
│ ② 流程模板 + 结果串联 (~3天)
│ - FlowTemplateService: 5-8 个预定义流程
│ - 步骤间数据共享机制
│ - 敏感性分析自动添加
▼
L4 完成: 流程编排
│ 「从单方法跃迁到完整统计分析流程」
│
│ ③ LLM 结论生成 (~3天)
│ - ConclusionService: LLM 综合解读
│ - 结论模板体系
│ - 方法学说明自动生成
▼
L5 完成: 论文级输出
│ 「结果可直接复制到论文中」
│
│ ④ 数据诊断→规划联动 + 追问机制 (~5天)
│ - DataDiagnosticService: 异常值/样本量/平衡性
│ - 诊断结果传递给 Planner
│ - 护栏结果回传机制
▼
L3 完成: 数据自适应
│ 「系统自动根据数据特征调整方法」
│
│ ⑤ 高级交互 (~3天)
│ - 执行暂停/跳过/取消
│ - 步骤失败自动降级
│ - 用户修改 SAP 后重新执行
▼
理想状态: 完全智能化统计分析系统
```
### 4.2 各阶段详细任务
#### 阶段 ①：LLM 意图理解 + 决策表匹配（~5 天）
| 任务 | 层级 | 预估 | 说明 |
|------|------|------|------|
| 设计 Intent Prompt | 后端 | 4h | 提取 Goal/Y/X/Design + 置信度 |
| 实现 IntentParserService | 后端 | 6h | LLM 调用 + 结构化输出 + Zod 校验 |
| 设计决策表 Excel 模板 | 配置 | 3h | 四维匹配规则 + 10 个工具映射 |
| 实现 DecisionTableService | 后端 | 6h | Excel 加载 + 四维匹配逻辑 |
| 重构 WorkflowPlannerService | 后端 | 4h | 集成 Intent + DecisionTable |
| 前端追问卡片组件 | 前端 | 4h | 当置信度低时展示选项 |
| 联调测试 | 全栈 | 4h | 多场景测试 |
#### 阶段 ②：流程模板 + 结果串联（~3 天）
| 任务 | 层级 | 预估 | 说明 |
|------|------|------|------|
| 定义 5 个流程模板 | 配置 | 3h | 差异/关联/描述/回归/基线表 |
| 实现 FlowTemplateService | 后端 | 4h | 模板加载 + 参数填充 |
| 步骤间数据共享 | 后端+R | 6h | 清洗后数据缓存 + 传递 |
| 自动添加敏感性分析 | 后端 | 3h | 主要分析 + 替代方法 |
| 自动添加效应量步骤 | 后端 | 2h | Cohen's d / r |
| 联调测试 | 全栈 | 4h | 完整流程测试 |
#### 阶段 ③：LLM 结论生成（~3 天）
| 任务 | 层级 | 预估 | 说明 |
|------|------|------|------|
| 设计结论生成 Prompt | 后端 | 4h | 6 要素结论模板 |
| 实现 ConclusionService | 后端 | 6h | LLM 调用 + 流式输出 |
| 设计解读模板配置 | 配置 | 3h | 每种工具的"填空题"模板 |
| 前端论文结论展示 | 前端 | 4h | Markdown 渲染 + 复制 |
| Word 报告增强 | 前端 | 3h | 纳入论文级结论 |
| 联调测试 | 全栈 | 3h | |
#### 阶段 ④：数据诊断→规划联动（~5 天）
| 任务 | 层级 | 预估 | 说明 |
|------|------|------|------|
| 实现异常值检测 | Python/R | 4h | IQR 方法 + 可视化标注 |
| 实现样本量评估 | Python/R | 3h | 功效分析建议 |
| 实现分组平衡性检测 | Python | 2h | 各组比例 + 提示 |
| 诊断结果传递给 Planner | 后端 | 4h | DataDiagnosis → PlannerInput |
| R 护栏结果回传机制 | 后端+R | 6h | 护栏结果影响后续步骤 |
| 前端诊断报告增强 | 前端 | 4h | 问题列表 + 建议 + 评分 |
| 前端追问机制 | 前端 | 4h | 不确定时展示选择卡片 |
| 联调测试 | 全栈 | 4h | |
#### 阶段 ⑤：高级交互（~3 天）
| 任务 | 层级 | 预估 | 说明 |
|------|------|------|------|
| 执行暂停/跳过/取消 | 后端+前端 | 6h | SSE 控制消息 |
| 步骤失败自动降级 | 后端 | 4h | T 检验失败 → Wilcoxon |
| SAP 修改后重新执行 | 前端+后端 | 6h | 用户编辑步骤 → 重新规划 |
| 联调测试 | 全栈 | 4h | |
---
## 5. 工时与里程碑
| 阶段 | 核心目标 | 工时 | 智能等级 |
|------|---------|------|---------|
| Block-based 重构 | 结果渲染标准化 | 2.5天 | 基础设施 |
| ① LLM 意图 + 决策表 | 用户不需要知道方法名 | 5天 | → L2 |
| ② 流程模板 + 串联 | 从单方法到完整流程 | 3天 | → L4 |
| ③ LLM 结论生成 | 论文级输出 | 3天 | → L5 |
| ④ 数据诊断联动 | 全自动方法调整 | 5天 | → L3 |
| ⑤ 高级交互 | 可中断 + 降级 | 3天 | 完善 |
| **合计** | **理想状态** | **~21.5天** | **L5** |
### 里程碑时间线（预估）
```
2026-02-21 ─── Block-based 重构开始
2026-02-24 ─── Block-based 完成 ✓ 基础设施就绪
2026-02-25 ─── 阶段① 开始：LLM 意图 + 决策表
2026-03-01 ─── 阶段① 完成 ✓ L2 智能选方法
2026-03-02 ─── 阶段② 开始：流程模板 + 串联
2026-03-05 ─── 阶段② 完成 ✓ L4 流程编排
2026-03-06 ─── 阶段③ 开始：LLM 结论生成
2026-03-10 ─── 阶段③ 完成 ✓ L5 论文级输出
2026-03-11 ─── 阶段④ 开始：数据诊断联动
2026-03-17 ─── 阶段④ 完成 ✓ L3 数据自适应
2026-03-18 ─── 阶段⑤ 开始：高级交互
2026-03-21 ─── 阶段⑤ 完成 ✓ 理想状态
```
---
## 6. 成功标准
### 用户体验验证
| 测试场景 | 当前表现 | 目标表现 |
|----------|---------|---------|
| 用户说"有没有效" | ❌ 无法理解 | ✅ AI 识别为差异比较 |
| 用户不知道该用什么方法 | ❌ 必须指定 | ✅ AI 自动选择 |
| 数据不满足正态性 | 🟡 R 内部降级，用户不知 | ✅ 规划时就选非参数方法 |
| 分析结果 | 🟡 P 值 + 数字 | ✅ "两组差异显著(P<0.001)，中等效应" |
| 导出报告 | 🟡 需大量整理 | ✅ 可直接用于论文 |
### 智能化评分卡
| 能力 | 权重 | 当前评分 | 目标评分 |
|------|------|---------|---------|
| 意图理解 | 25% | 2/10 | 8/10 |
| 方法选择 | 20% | 3/10 | 9/10 |
| 流程规划 | 20% | 2/10 | 8/10 |
| 执行引擎 | 15% | 6/10 | 9/10 |
| 结论生成 | 20% | 1/10 | 8/10 |
| **加权总分** | **100%** | **2.7/10** | **8.4/10** |
---
## 7. 风险与依赖
| 风险 | 概率 | 影响 | 应对策略 |
|------|------|------|---------|
| LLM 意图提取准确率不足 | 中 | 高 | 低置信度时追问用户，而非猜测 |
| 决策表覆盖率不足 | 中 | 中 | RAG 工具检索作为兜底方案 |
| LLM 结论生成"幻觉" | 中 | 高 | 基于模板+真实数据填充，而非自由生成 |
| 步骤间数据串联复杂度 | 中 | 中 | 先实现缓存共享，不做复杂依赖图 |
| 流程模板无法覆盖长尾场景 | 低 | 中 | 预留"自定义流程"入口 |
---
**文档维护者：** SSA 架构团队
**最后更新：** 2026-02-20
**下一步行动：** 确认优先级后，从 Block-based 重构 → 阶段 ① 开始执行

1297
docs/03-业务模块/SSA-智能统计分析/04-开发计划/10-QPER架构开发计划-智能化主线.md Normal file
View File

File diff suppressed because it is too large Load Diff

69
docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/QPER V3.0 架构审查与工程护航报告.md Normal file
View File

@@ -0,0 +1,69 @@
# **架构委员会独立审查报告：SSA-Pro QPER 智能化主线 (V3.0)**
**审查对象：** 《10-QPER架构开发计划-智能化主线.md》(v3.0)
**审查时间：** 2026-02-21
**总体评级：** 🌟 **S+ 级 (极度卓越，可作为创业公司 AI Agent 标杆)**
**核心裁决：** 绿灯放行（Green Light）。该计划完美融合了学术界前沿理论与极简工程实践，准予立即进入编码攻坚阶段。
## **一、 为什么这份计划能拿 S+？(三大高光决策)**
1. **“断舍离”的顶级理解 (延后配置中台)**：
在只有 10 个工具的 MVP 阶段，强行开发一套 Excel 导入和专家配置后台是极其浪费资源的。直接在 Node.js 中用 10 个静态 JSON 对象来充当“决策表”，**把工时从 2 周压缩到了 2 天**，极大地加速了核心引擎的验证。
2. **Q 层的结构化降维 (防幻觉槽位)**：
让 IntentParser 只输出 goal, y, x, design 这四个核心维度，而不是直接输出统计方法。这彻底阻断了 LLM “瞎编统计方法”的可能，把智能体最容易出错的环节卡死了。
3. **清晰的 5 大验收场景 (TDD 导向)**：
文档最后给出的 5 个核心验收场景（差异、相关、预测、描述、追问）极其精准。这相当于给测试团队（QA）和 Prompt 工程师画好了靶子，开发不再是盲人摸象。
## **二、 必须预先防范的 3 个工程隐患 (Hidden Engineering Risks)**
计划的宏观架构已经无懈可击，但在具体写 Node.js 代码时，请务必规避以下三个暗礁：
### **🚨 隐患 1：DataProfiler 的“重复运算”与资源浪费**
* **设计现状**：在 Q 层，IntentParser \-\> DataProfiler \-\> Clarifier。
* **物理现实**：DataProfiler 需要调用 Python 的 Tool C 去解析 20MB 的 CSV。如果用户在同一个会话里，先问了“比较血压”（触发一次 Profiler），又接着问“那年龄呢？”（又触发一次 Profiler），会导致极大的延迟和服务器 CPU 浪费。
* **架构强制要求 (Caching)**：
必须在 Node.js 的 Session 级别实现 **DataProfile 缓存**。
用户上传文件后，DataProfiler **只执行一次**，并将结果（轻量级 Schema JSON）存入 Redis 或内存 Session 中。后续的 Q 层循环直接读取缓存，实现毫秒级响应。
### **🚨 隐患 2：QPER 的“异步状态机”面条代码风险 (Spaghetti Code)**
* **设计现状**：系统存在 Clarifier (等用户回复) 和 Reflection (捕获异常重试) 两种中断/循环逻辑。
* **物理现实**：如果纯用 if-else 和嵌套 while 循环来写这种带“人机交互中断（HITL）”的工作流，Node.js 代码会迅速劣化为难以维护的面条代码。
* **架构强制要求 (State Machine)**：
后端开发必须采用**显式状态机 (Explicit State Machine)** 来管理会话状态。定义一个标准的 ExecutionStatus 枚举：
PENDING\_INTENT \-\> CLARIFYING \-\> PLANNING \-\> EXECUTING \-\> REFLECTING \-\> COMPLETED。
当状态为 CLARIFYING 时，立刻中断执行并向前端发送卡片，等待下一次 HTTP 请求恢复状态。
### **🚨 隐患 3：UI 感知盲区 (The UX Blackhole during Reflection)**
* **设计现状**：R 层（Reflection）在后台捕获错误、修改参数、重新执行。
* **物理现实**：这个过程可能长达 15-20 秒。如果在双屏 V8 UI 上，用户只看到一个 Spinner 在转，他们会以为系统死机了。
* **架构强制要求 (SSE Trace Streaming)**：
Node.js 的编排器必须将 Q-P-E-R 的每一次状态跃迁，通过 **SSE (Server-Sent Events)** 推送给前端。
*前端必须能渲染出这样的日志*：
\[Executor\] 正在计算 T 检验...
\[Executor\] ❌ 失败：变量存在完全共线性。
\[Reflection\] 🧠 AI 正在反思并修正分析计划...
\[Executor\] 🔄 重新执行：已剔除共线变量...
这种“展示 AI 工作和纠错过程 (Show your work)”的体验，是智能体产品的核心爽点。
## **三、 对 Prompt 工程师的战术指导**
由于你们取消了配置中台，所有的智能压力都来到了 Prompt 工程师肩上。请遵循以下最佳实践：
1. **Prompt 文件化隔离**：
千万不要把长达百行的 Prompt 用反引号 (\`\`) 直接硬编码在 .ts 业务代码里！请在项目中建立一个 src/prompts/ 文件夹，将 Prompt 写在 .md 文件中（如 intent\_parser.md），利用 fs.readFileSync 运行时加载。这方便以后无缝迁移到数据库配置中心。
2. **Few-Shot 示例至高无上**：
在 IntentParser 的 Prompt 中，不要花大量篇幅解释什么是“差异”，直接给它 10 个经典的医生问句和对应的 JSON 答案。**在医疗统计领域，10 个高质量的 Few-Shot，胜过 1000 字的逻辑说教。**
## **四、 结语**
你们的 V3.0 计划展现了极高的业务理解力和工程克制力。你们没有被“大厂花哨的架构”带偏，而是用最务实的手段构建了最核心的智能壁垒。
**请带着这份审查报告召开项目启动会（Kick-off Meeting）。**
让前端准备对接 SSE 状态流，让后端搭好状态机框架，让 R 工程师专注跑通工具。**SSA-Pro 的第一场硬仗，可以开始了！**

90
docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/QPER架构审查与工程避坑指南.md Normal file
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)**
虽然架构图很完美，但在写代码时，以下三个地方极容易导致系统崩溃或用户体验翻车：
### **🚨 暗礁 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 第一版！** 🚀

0
docs/03-业务模块/SSA-智能统计分析/06-开发记录/SSA-Pro MVP 智能化增强指南.md → docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/SSA-Pro MVP 智能化增强指南.md
View File

0
docs/03-业务模块/SSA-智能统计分析/06-开发记录/SSA-Pro Prompt体系与专家配置边界梳理.md → docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/SSA-Pro Prompt体系与专家配置边界梳理.md
View File

0
docs/03-业务模块/SSA-智能统计分析/06-开发记录/SSA-Pro R 服务代码深度审查报告.md → docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/SSA-Pro R 服务代码深度审查报告.md
View File

0
docs/03-业务模块/SSA-智能统计分析/06-开发记录/SSA-Pro V1.2 终极审查与发令报告V3.0.md → docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/SSA-Pro V1.2 终极审查与发令报告V3.0.md
View File

0
docs/03-业务模块/SSA-智能统计分析/06-开发记录/SSA-Pro 前端 UI 改进计划审查报告.md → docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/SSA-Pro 前端 UI 改进计划审查报告.md
View File

0
docs/03-业务模块/SSA-智能统计分析/06-开发记录/SSA-Pro 前端UI改进计划-审查回应.md → docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/SSA-Pro 前端UI改进计划-审查回应.md
View File

0
docs/03-业务模块/SSA-智能统计分析/06-开发记录/SSA-Pro 动态结果渲染与通信协议规范.md → docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/SSA-Pro 动态结果渲染与通信协议规范.md
View File

0
docs/03-业务模块/SSA-智能统计分析/06-开发记录/SSA-Pro 方案深度审查与风险评估报告 V2.0.md → docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/SSA-Pro 方案深度审查与风险评估报告 V2.0.md
View File

0
docs/03-业务模块/SSA-智能统计分析/06-开发记录/SSA-Pro 方案深度审查与风险评估报告.md → docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/SSA-Pro 方案深度审查与风险评估报告.md
View File

0
docs/03-业务模块/SSA-智能统计分析/06-开发记录/SSA-Pro 智能化演进路径评估报告.md → docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/SSA-Pro 智能化演进路径评估报告.md
View File

0
docs/03-业务模块/SSA-智能统计分析/06-开发记录/SSA-Pro 智能化演进阶梯.md → docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/SSA-Pro 智能化演进阶梯.md
View File

0
docs/03-业务模块/SSA-智能统计分析/06-开发记录/SSA-Pro 架构审查反馈与智能化路径讨论.md → docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/SSA-Pro 架构审查反馈与智能化路径讨论.md
View File

109
docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/SSA-Pro 架构诊断与复合工具扩展方案.md Normal file
View File

@@ -0,0 +1,109 @@
# **SSA-Pro 架构诊断与复合工具扩展方案**
**文档性质：** 架构诊断总结与 Phase Deploy 扩充计划
**诊断对象：** 经典队列研究分析流程（Table 1, Table 2, Table 3）的实现缺口
**核心结论：** 🌟 **诊断完全正确！** 架构与 AI 均无问题，核心缺口在于缺少“多变量聚合”的**复合 R 工具 (Macro-Tool)**。采用 gtsummary 填补此缺口，是四两拨千斤的神来之笔。
## **1\. 团队诊断结果复盘与高度认可**
团队提出的诊断击中了医疗 AI 统计分析的最核心痛点：**“原子工具”与“临床真实工作流”的错位。**
* **我们当前的误区**：把 10 个工具全部做成了“验证单一假设”的原子工具（如：只查一个变量的 T 检验）。
* **临床的真实诉求**：“一键出 Table 1”。一张表里包含了 20 个变量的描述、分布检验、T 检验、Wilcoxon、卡方检验，甚至 Fisher 检验。
* **破局解法**：新建复合工具 ST\_BASELINE\_TABLE，把复杂的循环、判断、拼表工作，全部**下沉到 R 引擎内部去完成**，释放 LLM 的规划压力。
## **2\. 核心利器：ST\_BASELINE\_TABLE 的设计与实现**
团队提出的用 R 语言的 gtsummary 包来实现表 1 和表 2，是极其专业的选择。gtsummary 是目前全球医学统计界公认的“顶流制表神器”。
### **2.1 R 端开发要求 (仅需 6-8 小时)**
R 开发工程师只需做一层很薄的 Wrapper，gtsummary::tbl\_summary() 会自动完成绝大部分工作：
\# ST\_BASELINE\_TABLE 伪代码示例
library(gtsummary)
run\_tool \<- function(input) {
df \<- load\_data(input$data\_source)
\# 核心一行代码：按分组变量 (by) 统计所有传入的分析变量
\# gtsummary 会自动判断是连续还是分类，自动选 T检验 或 卡方
table\_obj \<- df %\>%
select(all\_of(c(input$params$group\_var, input$params$analyze\_vars))) %\>%
tbl\_summary(by \= input$params$group\_var, missing \= "ifany") %\>%
add\_p() \# 自动执行统计检验并添加 P 值
\# 将 gtsummary 对象转换为标准前端 report\_blocks
\# ...
}
**能力覆盖**：
* ✅ 自动处理连续与分类变量。
* ✅ 自动处理正态与非正态的检验降级。
* ✅ 自动计算期望频数并切换 Fisher。
* ✅ 完美对应 **表1（基线比较，group\_var=暴露因素）** 和 **表2（单因素筛选，group\_var=结局指标）**。
## **3\. 规划层 (Planner) 的流程模板升级**
基于这个强大的复合工具，我们立刻可以在 flow\_templates.json 中配置一个秒杀市面所有竞品的\*\*“队列研究全家桶”\*\*。
"cohort\_study\_standard": {
"name": "经典队列研究全套分析 (Table 1-3)",
"steps": \[
{
"order": 1,
"role": "baseline\_table",
"tool": "ST\_BASELINE\_TABLE",
"name": "表1: 组间基线特征比较",
"params\_mapping": {
"group\_var": "{{exposure\_var}}", // 暴露/分组变量
"analyze\_vars": "{{all\_covariates}}"
}
},
{
"order": 2,
"role": "univariate\_screen",
"tool": "ST\_BASELINE\_TABLE",
"name": "表2: 结局指标单因素分析",
"params\_mapping": {
"group\_var": "{{outcome\_var}}", // 结局变量
"analyze\_vars": "{{all\_covariates}}"
}
},
{
"order": 3,
"role": "multivariate\_reg",
"tool": "ST\_LOGISTIC\_BINARY",
"name": "表3: 结局多因素 Logistic 回归",
"params\_mapping": {
"outcome\_var": "{{outcome\_var}}",
"predictors": "{{exposure\_var}} \+ {{significant\_covariates}}" // 纳入表2中P\<0.05的变量
}
}
\]
}
## **4\. 对系统价值的深远影响**
1. **Planner (大模型) 压力骤降**：LLM 不再需要像写循环一样生成 20 个分析步骤。它只需要提取出【结局变量】、【分组变量】和【协变量列表】即可。这使得规划的准确率无限逼近 100%。
2. **完美契合《统计分析报告.docx》**：
* **Table 1** \-\> 对应 Step 1
* **Table 2** \-\> 对应 Step 2
* **Table 3** \-\> 对应 Step 3
这标志着我们的 AI 从“答题机器”变成了真正掌握科研 SOP 的“高级数据分析师”。
3. **用户体验魔法化**：用户只需一句话输入（“这批队列数据，结局是生存状态，主要看吸烟的影响，帮我出一套完整报告”），系统就会直接扔出 3 张可以直接放进 SCI 论文的超长三线表。
## **5\. 决议与后续行动**
团队的这个诊断极其精辟，**强烈同意纳入 Phase Deploy 阶段执行**。
**Action Items:**
1. **R 工程师**：将研究 gtsummary 包作为 P0 级任务，本周内用 6-8 小时将其封装为 ST\_BASELINE\_TABLE，并测试其提取 report\_blocks 表格结构的能力。
2. **后端工程师**：在决策表中加入 cohort\_study\_standard 流程模板。
3. **前端工程师**：准备好能够支持横向滚动、拥有复杂表头（Span Header）的高级三线表组件，以迎接 Table 1 这种包含大量数据的巨型表格。
**做得漂亮！这是让系统具备商业变现能力的决定性一步。**

0
docs/03-业务模块/SSA-智能统计分析/06-开发记录/SSA-Pro-V11-UI-Development-Summary-2026-02-20.md → docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/SSA-Pro-V11-UI-Development-Summary-2026-02-20.md
View File

0
docs/03-业务模块/SSA-智能统计分析/06-开发记录/UI遮挡Bug终极修复指南.md → docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/UI遮挡Bug终极修复指南.md
View File

194
docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/医疗AI统计助手架构研究.md Normal file
View File

@@ -0,0 +1,194 @@
# **智能化医疗统计分析助手 (SSA-Pro) 底层架构与大模型智能体演进深度研究报告**
在当今医疗信息学与人工智能交叉的前沿领域，大型语言模型（LLM）正经历从单纯的文本生成工具向具备自主规划、工具调用与推理能力的智能体（Agent）范式转移。针对医疗统计分析场景，系统不仅需要处理医生输入的极度非结构化、充满模糊性与领域特定黑话的自然语言诉求，更需要跨越概率性生成模型与确定性数理统计之间的巨大鸿沟。医疗数据的分析容不得丝毫“幻觉”，任何一个伪造的 P 值或误用的统计检验方法，都可能导致临床试验结论的南辕北辙，进而危及患者生命安全与医疗决策的科学性。
基于 Q-P-E-R（Query 理解层、Planner 规划层、Execute 执行层、Reflection 审视层）的四层架构，为解决这一痛点提供了坚实的系统论基础。该架构通过深度解耦自然语言理解、统计学逻辑推理、底层代码编译执行以及医学结论转译，试图在灵活性与严谨性之间找到最佳平衡点。然而，在系统向高阶智能化演进的过程中，每一层都面临着严峻的技术抉择。本报告将以首席 AI 架构师的视角，深入剖析这四个核心模块中的前沿理论、工业界最佳实践，并提出高度可落地的架构演进方案。
## **议题 1：Query 层（用户意图识别与澄清）的最佳实践**
Query 层是整个智能化统计分析系统的“感知中枢”。临床医生在输入需求时，往往缺乏对统计学术语的精确掌握，其表述（如“这 200 个患者的数据，新药到底有没有效？”）在统计学语境下是高度欠定的。系统必须将这种自然语言精准映射为包含分析目的（Goal）、因变量（Y\_var）、自变量（X\_var）以及实验设计（Design）的四维结构化意图。
### **意图识别的技术路线深度对比与 ROI 分析**
在垂直领域的结构化意图提取任务中，工业界目前主要徘徊在纯提示词工程（Prompt Engineering）、检索增强生成（RAG）、监督微调（SFT）以及自然语言转领域特定语言（NL2DSL）四条技术路线之间。
纯提示词工程（Zero-shot 或 Few-shot）依赖于调用诸如 GPT-4o 或 Claude 3.5 Sonnet 等前沿大模型，通过在其系统提示中注入大量的规则说明与少量示例来实现意图抽取。这种方法的优势在于启动成本极低，能够快速进行原型验证，并且前沿模型具备强大的泛化与常识推理能力 1。然而，在复杂的医疗统计场景下，其边界效应显而易见。随着临床元数据（如包含成百上千个变量的数据字典）的输入，提示词长度急剧膨胀，大模型极易陷入“中间迷失”（Lost in the middle）的困境，导致指令遗忘或抽取目标偏移 3。此外，长期依赖商业前沿模型的 API 会带来高昂的推理成本、不可控的延迟，以及更为致命的患者隐私数据泄露风险 4。
引入意图识别知识库（RAG）能够部分缓解上述问题。在医疗场景中，单纯的向量检索（基于嵌入的 RAG）往往因为缺乏实体关联而表现不佳。前沿实践表明，构建基于临床实体增强检索（CLEAR）或知识图谱的结构化 RAG 系统，可以显著降低大模型的幻觉率并减少 Token 消耗 5。例如，系统可以在预处理阶段建立一个“医疗同义词与统计变量映射”的知识图谱，当医生提到“新药有效性”时，RAG 模块首先将“有效性”关联到具体的临床终点（如血压下降值或生存率），再将这些增强后的上下文喂给 LLM。这种做法将外部领域知识与 LLM 的推理能力结合，提高了识别的准确性 6。
然而，从投资回报率（ROI）与生产环境稳定性的角度来看，监督微调（SFT）小型专有模型（如 14B 参数量级的开源模型）展现出了压倒性的优势。最近的实证研究表明，在特定领域的结构化信息提取（如将临床文本转化为 JSON 格式的元数据）任务中，经过 DPO（直接偏好优化）或 SFT 训练的百亿参数模型，其表现不仅能够匹敌甚至在特定结构化约束下超越通用大模型 7。SFT 使得模型内化了统计意图提取的特定分布，彻底消除了复杂提示词的需求。在医疗场景下，本地部署 SFT 模型不仅实现了数据的绝对物理隔离（满足 HIPAA 或 GDPR 合规要求），还使得单次推理成本呈指数级下降。
进一步地，结合语义解析（Semantic Parsing）的 NL2DSL 方案代表了意图识别的最终演进形态。在这种架构下，开发团队预先定义一套严格的统计分析计划（SAP）上下文无关文法（CFG），并通过“受限解码”（Constrained Decoding）技术强制 LLM 在生成 Token 时必须符合该 DSL 的语法规则 9。这意味着模型输出的将不再是概率性的自由文本，而是 100% 语法正确的抽象语法树（AST）或强类型的 JSON Schema。在 SSA-Pro 中，采用 SFT 本地模型辅以 NL2DSL 受限解码，是兼顾极高解析准确率、数据安全性与系统 ROI 的最佳工业实践。
| 技术路线 | 实施复杂度 | 推理成本与延迟 | 结构化输出稳定性 | 医疗数据合规性 |
| :---- | :---- | :---- | :---- | :---- |
| **纯提示词工程 (API)** | 低 | 高 | 中等（易受指令漂移影响） | 低（数据出境风险） |
| **知识检索增强 (RAG)** | 中等 | 中等 | 较高（依赖知识库质量） | 视模型部署方式而定 |
| **监督微调小型专有模型 (SFT)** | 高 | 低 | 高（深度契合特定任务） | 高（支持本地私有化部署） |
| **受限解码的 NL2DSL** | 极高 | 低 | 绝对稳定（100% 语法正确） | 高（本地运行且逻辑可审计） |
### **主动追问（Clarification）的“人类在环”机制设计**
当医生输入的描述过于简略，导致大模型提取的四维意图置信度低于预设阈值时，系统必须触发主动追问机制。传统的对话机器人在遇到不确定性时，往往会生成发散性的开放问题（如：“请问您具体想怎么定义有效性？”）。这种做法将思考的负担重新推回给用户，极易引发医生的认知疲劳与抵触情绪，并且用户后续的开放式回答可能引入新的歧义 11。
优雅的“人类在环”（Human-in-the-loop）澄清机制应当遵循“发散思考，收敛提问”的设计模式（Divergent Outline Clarification）11。具体而言，当 Query 层的意图评估器识别出信息缺失（例如，缺失具体的比较基准或分组变量）时，系统会隐式启动一个“澄清子智能体（Clarifier Sub-Agent）”。该智能体首先调取数据体检报告中的变量字典，进行蒙特卡洛树搜索（MCTS）式的路径模拟，预测出 2 到 3 种在当前数据结构下合法且具备统计学意义的分析假设 11。
随后，智能体将这些底层计算路径转化为通俗易懂的临床业务选项，生成一个收敛性的多选题返回给医生。例如，系统不再问“你想用什么指标”，而是输出：“我们检测到您的数据中包含多个可能的终点指标，为了评估‘新药是否有效’，请问您倾向于选择：A. 比较用药前后连续的血压下降绝对值（适用于 T 检验）；B. 比较用药后达到正常血压标准的患者比例（适用于卡方检验）。” 这种将大模型的内部歧义转化为外部确定性选择题的机制，不仅严格约束了上下文状态空间，避免了多轮对话带来的逻辑发散，同时也起到了隐性教育用户的作用，极大提升了医疗 AI 系统的专业感与可信度 14。
## **议题 2：Planner 层（分析路径规划）的构建方案**
Planner 层是智能统计助手的核心大脑。它的任务是将 Query 层提取出的意图结构与数据体检报告（缺失率、偏度、峰度、样本量等）进行对齐，并据此生成一份严格的、包含具体步骤的统计分析计划（SAP）。在这个环节，数理统计的严密性与大模型的“幻觉”本性发生了最直接的冲突。
### **静态规则与动态规划的架构博弈**
在 LLM 智能体架构中，关于任务规划主要存在两种极端范式：基于硬编码与决策树的“静态规则引擎”，以及完全由 LLM 主导、边思考边执行的“动态规划”（如 ReAct 范式）16。
ReAct（Reasoning and Acting）模式通过在“思考、行动、观察”之间不断循环来推进任务。虽然它在开放域问题（如网络搜索或代码调试）中展现出强大的适应性，但在医疗统计中却是灾难性的 17。首先，ReAct 容易陷入局部最优解，导致分析流程缺乏全局一致性；其次，多轮循环会消耗海量 Token（即所谓的“ReAct 税”），显著降低系统响应速度并增加成本；最关键的是，频繁的自主决策极易引发“动作幻觉”，即模型在没有数理依据的情况下随意捏造统计转换或过滤条件 17。
相比之下，坚持使用硬编码的 JSON 决策表虽然安全，但过于僵化，无法应对临床数据中层出不穷的边缘情况（Edge Cases）。因此，工业界的最佳实践是采用“先规划，后执行”（Plan-and-Execute / Plan-and-Solve）的混合架构 17。在这一架构中，规划和执行被物理隔离。Planner 智能体首先作为一个全局调度者，在一个单独的推理周期内，综合所有约束条件生成一个完整的、包含多步骤的有向无环图（DAG）计划。这个计划一旦生成，便不再轻易更改。只有在底层执行层（Execute）明确返回不可恢复的运行时错误时，系统才会通过回调机制（Callback）触发局部的动态重规划（Dynamic Replanning）20。这种分离机制不仅将 API 调用成本降低了数倍，更重要的是它锁死了统计分析流程的确定性边界，使得每一步操作在执行前都是可审计和可预测的 18。
### **将“统计学先验知识”深度注入系统**
要让 Planner 在 Plan-and-Execute 架构中生成完美的工作流，单纯依赖大模型预训练权重中蕴含的统计知识是极不靠谱的。模型可能因为语料分布的偏差，错误地为非正态小样本数据推荐参数检验。将专家先验知识（如“分类变量用卡方，连续变量正态用 T 检验”）高效注入系统的最佳形态，是构建一个独立的“统计学知识图谱（Statistical Knowledge Graph, SKG）”并结合规则引擎 6。
提示词约束（Prompt Constraint）虽然实现简单，但随着规则的增多会导致上下文臃肿，且 LLM 难以在复杂的逻辑长链中保持绝对的遵循率 3。而硬编码的规则引擎虽然绝对准确，但难以处理自然语言意图中的软性模糊条件。因此，采用知识图谱作为中间件是最优解。在这个 SKG 中，节点代表数据类型（连续、分类、有序）、统计假设（正态性、方差齐性）、分析方法（T 检验、Wilcoxon 检验、ANOVA）以及后续的可视化手段；边则代表了严密的逻辑条件与因果关系 25。
在实际运行中，系统通过图检索增强生成（GraphRAG）技术，将当前用户的数据特征与图谱中的节点进行匹配。系统提取出从“数据起点”到“统计方法终点”的一条或多条有效子图路径（Sub-graph）。然后，将这条结构化的路径知识作为“硬性指令”注入到 Planner 智能体的系统提示词中 23。这种图谱注入机制（Graph Injection）彻底剥夺了 LLM 在核心统计规则上的“自由裁量权”，大模型退化为一个高级的“编译器”，其唯一任务是将图谱输出的绝对正确规则翻译为具体的、适配当前数据集维度的操作代码，从而从根本上消除了统计方法选择上的幻觉 24。
### **规避上下文爆炸的精细化状态管理**
在将 Data Profile（数据体检报告）、Metadata（变量字典）、User Goal（用户意图）喂给 LLM 以做出规划时，必须实施激进的上下文隔离与压缩策略，以防止“中间迷失”现象 28。
系统应建立“冷热状态分离（Hot and Cold Context Separation）”机制 29。对于 Planner 而言，它不需要看到全量数据的每一行内容，甚至不需要看到每一个变量的详细描述。热上下文（Hot Context）仅包含：高度浓缩的用户最终目标、只包含涉事变量（X 与 Y）的数据类型与关键统计特征（如“X：二分类；Y：连续，缺失率 2%，Shapiro-Wilk P\<0.05 拒绝正态”），以及从 SKG 中提取的方法学路径。
冷上下文（Cold Context）——包括全量数据框架、不相关变量的分布、以及冗长的建表语句——全部卸载到外部键值存储（KV Store）或向量数据库中。Planner 只生成高级指令（如 invoke\_non\_parametric\_test(var\_x, var\_y)），而具体的执行工具（Tools）在被调用时，才会去冷上下文中拉取具体的数据片段进行运算 6。同时，引入“观察结果掩码（Observation Masking）”技术，当底层工具返回长篇大论的数据摘要时，系统内部的记忆管理模块会将其压缩为简短的状态占位符，从而保持大模型规划窗口的绝对清洁与高效 28。
## **议题 3：Execute 与 Reflection 层的智能化深度**
如果在 Planner 层解决了“做什么”的问题，那么 Execute 层解决的就是“如何跑通”，而 Reflection 层则是解决“如何解释”。这两个位于后端的层级，是直接决定最终临床输出物质量的关键防线。
### **Execute（执行层）的代码沙箱自愈能力**
在真实的医疗数据分析中，底层 R 语言引擎的执行往往充满变数。数据中未预见的多重共线性导致设计矩阵不可逆（奇异矩阵错误），或者极大似然估计算法不收敛，这些都是难以通过静态规则彻底预测的运行时错误（Runtime Errors）30。为了实现高健壮性的自愈能力（Self-Correction），架构必须引入具备元认知（Metacognitive）能力的诊断闭环 13。
工业界的最佳实践是将 R 脚本执行置于强隔离的容器化沙箱中（如基于 Docker 或 WebAssembly 的环境），并全面捕获标准输出（stdout）、标准错误（stderr）以及运行时的堆栈轨迹（Traceback）33。一旦捕获到异常状态（如 Error in solve.default(X) : system is computationally singular），Execute 层会立即冻结执行，并将错误上下文连同原始 R 代码抛给一个专门的“检查者智能体（Inspector/Critic Agent）” 32。
这种自愈并非盲目地让大模型“再试一次”。先进的 Agent-R 范式引入了蒙特卡洛树搜索（MCTS）的思想，系统会在内存中展开一条错误恢复轨迹 13。检查者智能体会分析错误根因，例如针对“矩阵奇异”问题，它会自主决定在代码中临时插入一段计算方差膨胀因子（VIF）的诊断代码，找出引起共线性的冗余变量（如同时包含了“身高”、“体重”和“BMI”），修改原始特征选择逻辑，剔除高 VIF 变量，或改用岭回归（Ridge Regression）等正则化方法，重新生成 R 脚本并提交沙箱运行 30。这种基于“诊断-修复-验证”状态机的迭代机制，能够在无人类干预的情况下，自动跨越绝大多数数据科学的工程性陷阱，大幅提升了任务完成的成功率 36。
### **Reflection（审视层）的反幻觉输出机制**
Reflection 层承担着将冰冷的 JSON 统计结果转化为具有人情味、符合医学论文规范的文字结论的任务。由于大语言模型本质上是基于概率的下一个 Token 预测器，其对数值的敏感度和事实一致性往往存在固有缺陷。如果模型在撰写结论时捏造了 P 值，或者将置信区间（CI）随意篡改以迎合“具有统计学显著差异”的文本倾向，后果是不堪设想的 38。
为了达成绝对的反幻觉保证，必须在 Reflection 层实施多重防线：
1. **基于受限解码的严格映射**：执行层返回的结构化 JSON（包含 P 值、OR 值、CI 等）不得直接作为自由文本混入提示词中让模型续写。相反，应采用模板引擎和函数调用（Function Calling）强制模型进行数值映射。模型被剥夺了生成数值 Token 的权限，所有的统计量只允许通过指向 JSON 键值的引用槽位（如 {{result.p\_value}}）进行渲染 10。
2. **分对数（Logit）熵值监控与一致性检验**：模型在产生幻觉时，其输出 Token 的概率分布往往会从陡峭变为平缓（呈现出高不确定性的均匀分布特征）。系统可以通过截获生成关键医学声明（如“显著提高”、“呈正相关”）时的前 K 个 Token 概率，运行柯尔莫哥洛夫-斯米尔诺夫检验（K-S Test）。一旦检测到熵值异常升高，即触发警报，拒绝当前生成，并要求模型在更高的温度（Temperature=0）下重新推理 42。
3. **引入验证链（Chain-of-Verification, CoVe）**：在初稿生成完毕后，再引入一个完全独立的小型纠错模型（Verifier）。该模型只被分配一个任务：逐字比对生成的医学文本中的每一个数值和趋势描述，是否与底层的 JSON 数据在数学逻辑上绝对一致。一旦发现哪怕小数点后两位的微小偏离，即判定校验失败，打回重写 44。
### **生成具有说服力的可解释性“方法学说明”**
在医学统计中，医生对系统的信任往往不取决于最终结果有多么完美，而取决于系统能否自圆其说。Reflection 层不仅要输出“新药有效”，更要生成符合 APA 标准的“方法学说明”（Methodology Section），解释 Planner 为什么这么选。
实现这一点的关键在于建立一条端到端的“溯源轨迹（Traceability）”。在 Planner 层调用知识图谱（SKG）做出决策时，系统需要将触发规则的审计日志保存为结构化元数据（例如：Trigger\_Rule\_402: Type=Continuous, Shapiro-Wilk=0.03 (\<0.05), N=200 \-\> Path=Non\_Parametric\_Mann\_Whitney）。
在 Reflection 层生成方法学说明时，LLM 会将这条审计日志作为骨架，扩写为流畅的学术文本：“为了评估新药对收缩压的影响，本研究首先对数据进行了 Shapiro-Wilk 正态性检验。由于数据显著偏离正态分布（p \= 0.03），且样本分布满足两独立样本条件，故系统未采用独立样本 T 检验，而是选用了非参数的 Mann-Whitney U 检验来比较两组间的数值中位数差异。该方法的选择有效避免了偏态数据导致的统计效力下降……” 这种将内部状态机的决策树透明化、并用自然语言解释其统计学合理性的过程，是建立专家级信任的最有效手段 24。
## **议题 4：行业标杆与高级 Agent 架构模式参考**
为了确保 SSA-Pro 在未来的长远生命力，架构底座的选择与演进路线必须与最先进的工业界标准对齐。
### **底层架构模式选择：LangGraph 是 Q-P-E-R 的最佳载体**
在目前的智能体开发框架生态中，以 AutoGen 为代表的“多智能体对话协作（Multi-Agent Conversation）”范式和以 LangGraph 为代表的“状态机与工作流编排（State Graph）”范式代表了两种截然不同的架构哲学 47。
对于高度严谨、要求确定性执行的医疗统计分析流程而言，LangGraph 是毫无争议的最优选择。AutoGen 将任务推进的主导权交给了 LLM 之间的黑盒对话，依赖提示词来指引哪一个 Agent 下一步发言。这种模式容易导致控制流混乱、代理之间无休止的死循环，以及状态在多轮对话中的隐性丢失 47。这在不允许任何非预期发散的医疗分析中是致命的。
相反，LangGraph 强迫开发者用图论（Graph）的思维将系统抽象为“节点（Node）”和“边（Edge）”。在 SSA-Pro 中，Q-P-E-R 就是四个核心的大型节点（或子图）。数据作为全局的状态对象（State），顺着边在节点间有向流动。更重要的是，LangGraph 原生支持带有条件路由的环状图（Cyclic Graph），使得 Execute 层的“出错-诊断-重试”闭环得以用极其明确的工程代码（而非纯 Prompt）进行控制 47。同时，它内置的持久化检查点（Checkpointer）完美支撑了 Query 层的“人类在环”澄清机制，使得系统可以在任意节点挂起，等待医生输入选择题答案后，毫无状态损耗地恢复执行 48。
| 架构维度 | AutoGen (对话式编排) | LangGraph (状态图编排) | 在 SSA-Pro 中的适用性对比 |
| :---- | :---- | :---- | :---- |
| **控制流范式** | 基于 LLM 隐式路由的群聊 | 基于代码显式定义条件边 | LangGraph 提供了医疗系统必需的绝对掌控权。 |
| **状态共享** | 依赖对话历史窗口的积累 | 结构化 TypedDict 强制传递 | LangGraph 避免了对话堆积造成的上下文挤兑。 |
| **错误恢复** | Agent 互相指责和修正，易发散 | 显式的错误捕捉与环路重试 | LangGraph 的重试逻辑可控，避免陷入 token 消耗黑洞。 |
| **断点交互(HITL)** | 依赖提示词介入，控制较弱 | 原生支持节点级别挂起与恢复 | 完美契合医生的中途选择性介入澄清机制。 |
### **业界顶尖 AI 统计产品的核心亮点借鉴**
在通用数据分析领域，Julius AI 与 Energent.ai 代表了目前业界最高的智能化水平。SSA-Pro 可以从这些标杆中汲取宝贵的工程经验。
Julius AI 的巨大成功并非仅仅因为其背靠强大的基座模型，而在于其极其工程化的计算隔离与状态记忆能力。Julius 在处理复杂文件时，完全放弃了让 LLM 内部进行数值计算的尝试，而是构建了强大的 Python/R 隔离沙箱环境，保障了大基数数据的安全处理 51。此外，Julius 设计了一个特殊的“学习子智能体（Learning Sub Agent）”，在用户多次进行数据分析的过程中，它会默默在后台构建关于该用户数据库的 Schema 关系和偏好记忆，使得后续查询越来越精准 53。
Energent.ai 则展示了面向企业级的“无代码代理推理层（Agentic Reasoning Layers）”的威力。它不提供一个容易让人产生迷茫的开放式对话框，而是高度聚焦于将杂乱的表格转换为成品的分析图表与演示文稿（PPT）。它通过极端的专门化分工（清洗智能体、分析智能体、图表智能体各司其职），实现了高达 94.4% 的金融分析准确率 54。这印证了我们在 Planner 和 Execute 层中必须解耦与极度细化智能体分工的架构思路。
### **通向 L5 全自主数据科学家的技术演进路线图**
参考自动驾驶的 SAE 标准，工业界正在构建数据智能体的 L0 到 L5 自主性演进分类 55。目前的 SSA-Pro QPER V1.0 架构，通过提供强大的执行辅助并依赖医生（人类在环）进行目标澄清与最终把关，正处于 **L3 级（条件自主：Orchestration 阶段）**。要最终实现能够彻底替代人类高级生物统计学家的 **L5 级（完全自主：Generative 阶段）**，系统需要遵循以下三阶段的技术演进路线：
**第一阶段：攻克 L4 级高阶自主（主动型智能体架构）** 在这一阶段，系统必须打破“一问一答”的被动响应模式。SSA-Pro 需要接入医院的电子病历（EMR）或临床试验数据流，进化出“主动感知与异常诊断”能力。当后台新的患者数据持续汇入时，驻留智能体（Resident Agents）将自主监控数据漂移，自动识别出临床指标（如某类并发症发生率的突增），并主动触发 Q-P-E-R 流程。系统无需医生输入指令，便能自主规划分析路径、撰写诊断代码、生成可视化报告，并将最终的异常预警直接推送到医生的桌面端 56。此阶段的核心技术突破在于构建长期的情节记忆（Episodic Memory）与基于强化学习（RL）的环境交互能力 57。
**第二阶段：跨域大模型群体智能（Agent-to-Agent 协作）** 进入 L4 后期的系统将不再是单一的 Q-P-E-R 链条，而是裂变为多个具备深度专业角色的微型组织。例如，建立“数据工程智能体”（负责纵向缺失值插补理论）、“资深生物统计智能体”（负责贝叶斯后验概率推断）、“流行病学智能体”（负责控制混杂偏倚与因果推断）以及“审稿人智能体”（专门负责挑错与证伪）。系统内采用类似多智能体辩论（Multi-Agent Debate）的共识机制，面对一个复杂的临床研究目的，各方智能体通过自主的 Agent-to-Agent (A2A) 通信协商出最佳分析方案 58。
**第三阶段：达到 L5 级完全自主（驱动科学范式转移）** 在最终的 L5 形态，系统将具备独立完成端到端医学科研的能力。它能够自主抓取最新的 PubMed 论文网络（GraphRAG），发现目前肿瘤治疗中的统计学研究空白；随后，系统可以自主提出创新性的科研假设，从万级别规模的异构临床数据库中自主提取、关联病历与基因组数据，设计前瞻性的虚拟临床试验（In Silico Trials）。此时，智能体不仅能修正 R 语言的语法错误，更能识别出人类当前统计学方法本身的局限性，自主组合并编写出全新的机器学习算法或统计算子来解决问题，最终自动生成符合《Nature》、《Lancet》标准的高质量学术论文全文 55。在这个阶段，AI 不再是医生的“分析助手”，而是成为了推动生物医学边界拓展的“全天候数据科学家同行”。
#### **引用的著作**
1. Prompt engineering for accurate statistical reasoning with large language models in medical research \- Frontiers, 访问时间为 二月 21, 2026， [https://www.frontiersin.org/journals/artificial-intelligence/articles/10.3389/frai.2025.1658316/full](https://www.frontiersin.org/journals/artificial-intelligence/articles/10.3389/frai.2025.1658316/full)
2. Harnessing Large‐Language Models for Efficient Data Extraction in Systematic Reviews: The Role of Prompt Engineering \- PMC, 访问时间为 二月 21, 2026， [https://pmc.ncbi.nlm.nih.gov/articles/PMC12559671/](https://pmc.ncbi.nlm.nih.gov/articles/PMC12559671/)
3. Effective context engineering for AI agents \- Anthropic, 访问时间为 二月 21, 2026， [https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
4. Clinical Information Extraction with Large Language Models: A Case Study on Organ Procurement \- PMC, 访问时间为 二月 21, 2026， [https://pmc.ncbi.nlm.nih.gov/articles/PMC12099322/](https://pmc.ncbi.nlm.nih.gov/articles/PMC12099322/)
5. Clinical entity augmented retrieval for clinical information extraction \- PMC \- NIH, 访问时间为 二月 21, 2026， [https://pmc.ncbi.nlm.nih.gov/articles/PMC11743751/](https://pmc.ncbi.nlm.nih.gov/articles/PMC11743751/)
6. Injecting Knowledge Graphs in different RAG stages | by Chia Jeng Yang \- Medium, 访问时间为 二月 21, 2026， [https://medium.com/enterprise-rag/injecting-knowledge-graphs-in-different-rag-stages-a3cd1221f57b](https://medium.com/enterprise-rag/injecting-knowledge-graphs-in-different-rag-stages-a3cd1221f57b)
7. Fine-Tuning Methods for Large Language Models in Clinical Medicine by Supervised Fine-Tuning and Direct Preference Optimization: Comparative Evaluation \- PMC, 访问时间为 二月 21, 2026， [https://pmc.ncbi.nlm.nih.gov/articles/PMC12457693/](https://pmc.ncbi.nlm.nih.gov/articles/PMC12457693/)
8. Leveraging open-source large language models for clinical information extraction in resource-constrained settings \- Oxford Academic, 访问时间为 二月 21, 2026， [https://academic.oup.com/jamiaopen/article/8/5/ooaf109/8270821](https://academic.oup.com/jamiaopen/article/8/5/ooaf109/8270821)
9. LLM-Hardened DSLs for Probabilistic Code Generation in High-Assurance Systems, 访问时间为 二月 21, 2026， [https://deanm.ai/blog/2025/5/24/toward-data-driven-multi-model-enterprise-ai-7e545-sw6c2](https://deanm.ai/blog/2025/5/24/toward-data-driven-multi-model-enterprise-ai-7e545-sw6c2)
10. Large Language Models for Domain-Specific Language Generation Part 2: How to Constrain Your Dragon | by Andreas Mülder | itemis | Medium, 访问时间为 二月 21, 2026， [https://medium.com/itemis/large-language-models-for-domain-specific-language-generation-part-2-how-to-constrain-your-dragon-e0e2439b6a53](https://medium.com/itemis/large-language-models-for-domain-specific-language-generation-part-2-how-to-constrain-your-dragon-e0e2439b6a53)
11. Divergent Outline Clarification in LLMs | by Charlie Koster \- Medium, 访问时间为 二月 21, 2026， [https://ckoster22.medium.com/divergent-outline-clarification-in-llms-6221dd6902fa](https://ckoster22.medium.com/divergent-outline-clarification-in-llms-6221dd6902fa)
12. LLM-based Agents Suffer from Hallucinations: A Survey of Taxonomy, Methods, and Directions \- arXiv.org, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2509.18970v1](https://arxiv.org/html/2509.18970v1)
13. Training AI Agents to Self-Correct: A Deep Dive into Agent-R's Theoretical Foundations, 访问时间为 二月 21, 2026， [https://medium.com/@avd.sjsu/training-ai-agents-to-self-correct-a-deep-dive-into-agent-rs-theoretical-foundations-1c6d00fecdf6](https://medium.com/@avd.sjsu/training-ai-agents-to-self-correct-a-deep-dive-into-agent-rs-theoretical-foundations-1c6d00fecdf6)
14. Bird-Interact: Re-imagining Text-to-SQL Evaluation for Large Language Models via Lens of Dynamic Interactions \- arXiv, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2510.05318v2](https://arxiv.org/html/2510.05318v2)
15. AmbiBench: Benchmarking Mobile GUI Agents Beyond One-Shot Instructions in the Wild, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2602.11750v1](https://arxiv.org/html/2602.11750v1)
16. Dynamic Planning vs Static Workflows: What Truly Defines an AI Agent | by Tao An \- Medium, 访问时间为 二月 21, 2026， [https://tao-hpu.medium.com/dynamic-planning-vs-static-workflows-what-truly-defines-an-ai-agent-b13ca5a2d110](https://tao-hpu.medium.com/dynamic-planning-vs-static-workflows-what-truly-defines-an-ai-agent-b13ca5a2d110)
17. ReAct vs Plan-and-Execute: A Practical Comparison of LLM Agent Patterns, 访问时间为 二月 21, 2026， [https://dev.to/jamesli/react-vs-plan-and-execute-a-practical-comparison-of-llm-agent-patterns-4gh9](https://dev.to/jamesli/react-vs-plan-and-execute-a-practical-comparison-of-llm-agent-patterns-4gh9)
18. Planning Pattern for AI Agents: Strategic Reasoning Before Action | Gian Paolo Santopaolo, 访问时间为 二月 21, 2026， [https://genmind.ch/posts/Planning-Pattern-for-AI-Agents-Strategic-Reasoning-Before-Action/](https://genmind.ch/posts/Planning-Pattern-for-AI-Agents-Strategic-Reasoning-Before-Action/)
19. ReAct\&Plan: Hybrid Reactive & Planning Strategy \- Emergent Mind, 访问时间为 二月 21, 2026， [https://www.emergentmind.com/topics/react-plan-strategy](https://www.emergentmind.com/topics/react-plan-strategy)
20. Plan-and-Act: Improving Planning of Agents for Long-Horizon Tasks \- arXiv, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2503.09572v2](https://arxiv.org/html/2503.09572v2)
21. ALAS: Transactional and Dynamic Multi-Agent LLM Planning \- arXiv, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2511.03094v1](https://arxiv.org/html/2511.03094v1)
22. How to Build a Plan-and-Execute AI Agent \- Ema, 访问时间为 二月 21, 2026， [https://www.ema.co/additional-blogs/addition-blogs/build-plan-execute-agents](https://www.ema.co/additional-blogs/addition-blogs/build-plan-execute-agents)
23. How to Improve Multi-Hop Reasoning With Knowledge Graphs and LLMs \- Neo4j, 访问时间为 二月 21, 2026， [https://neo4j.com/blog/genai/knowledge-graph-llm-multi-hop-reasoning/](https://neo4j.com/blog/genai/knowledge-graph-llm-multi-hop-reasoning/)
24. Synergistic Joint Model of Knowledge Graph and LLM for Enhancing XAI-Based Clinical Decision Support Systems \- MDPI, 访问时间为 二月 21, 2026， [https://www.mdpi.com/2227-7390/13/6/949](https://www.mdpi.com/2227-7390/13/6/949)
25. LLMs \+ Knowledge Graphs: A Practical Guide to Real-World Intelligence \- Medium, 访问时间为 二月 21, 2026， [https://medium.com/@visrow/llms-knowledge-graphs-a-practical-guide-to-real-world-intelligence-0081b9d79cb1](https://medium.com/@visrow/llms-knowledge-graphs-a-practical-guide-to-real-world-intelligence-0081b9d79cb1)
26. Injecting Knowledge Graphs into Large Language Models \- arXiv, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2505.07554v1](https://arxiv.org/html/2505.07554v1)
27. Injecting Knowledge Graphs into Large Language Models \- ResearchGate, 访问时间为 二月 21, 2026， [https://www.researchgate.net/publication/391676783\_Injecting\_Knowledge\_Graphs\_into\_Large\_Language\_Models](https://www.researchgate.net/publication/391676783_Injecting_Knowledge_Graphs_into_Large_Language_Models)
28. Cutting Through the Noise: Smarter Context Management for LLM-Powered Agents, 访问时间为 二月 21, 2026， [https://blog.jetbrains.com/research/2025/12/efficient-context-management/](https://blog.jetbrains.com/research/2025/12/efficient-context-management/)
29. Context Engineering in Google ADK: The Ultimate Guide to Building Scalable AI Agents, 访问时间为 二月 21, 2026， [https://medium.com/@juanc.olamendy/context-engineering-in-google-adk-the-ultimate-guide-to-building-scalable-ai-agents-f8d7683f9c60](https://medium.com/@juanc.olamendy/context-engineering-in-google-adk-the-ultimate-guide-to-building-scalable-ai-agents-f8d7683f9c60)
30. Help for package spaMM \- CRAN, 访问时间为 二月 21, 2026， [https://cran.r-project.org/web/packages/spaMM/refman/spaMM.html](https://cran.r-project.org/web/packages/spaMM/refman/spaMM.html)
31. LLM as Runtime Error Handler: A Promising Pathway to Adaptive Self-Healing of Software Systems \- arXiv, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2408.01055v1](https://arxiv.org/html/2408.01055v1)
32. Self-correcting Code Generation Using Multi-Step Agent \- deepsense.ai, 访问时间为 二月 21, 2026， [https://deepsense.ai/resource/self-correcting-code-generation-using-multi-step-agent/](https://deepsense.ai/resource/self-correcting-code-generation-using-multi-step-agent/)
33. AgentBay: A Hybrid Interaction Sandbox for Seamless Human-AI Intervention in Agentic Systems \- arXiv, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2512.04367v1](https://arxiv.org/html/2512.04367v1)
34. LAMBDA: A Large Model Based Data Agent arXiv ... \- Defeng Sun, 访问时间为 二月 21, 2026， [https://defengwebsite.github.io/files/2407.17535v2.pdf](https://defengwebsite.github.io/files/2407.17535v2.pdf)
35. Applied Numerical Methods \- (NAFTI \- Ir) | PDF | Polynomial \- Scribd, 访问时间为 二月 21, 2026， [https://www.scribd.com/document/586172726/Applied-Numerical-Methods-NAFTI-ir](https://www.scribd.com/document/586172726/Applied-Numerical-Methods-NAFTI-ir)
36. OR-LLM-Agent: Automating Modeling and Solving of Operations Research Optimization Problem with Reasoning Large Language Model \- arXiv.org, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2503.10009v1](https://arxiv.org/html/2503.10009v1)
37. Why can't LLMs self-correct bad code? : r/ChatGPTCoding \- Reddit, 访问时间为 二月 21, 2026， [https://www.reddit.com/r/ChatGPTCoding/comments/1cygnez/why\_cant\_llms\_selfcorrect\_bad\_code/](https://www.reddit.com/r/ChatGPTCoding/comments/1cygnez/why_cant_llms_selfcorrect_bad_code/)
38. A Comprehensive Survey of Hallucination in Large Language Models: Causes, Detection, and Mitigation \- arXiv, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2510.06265v1](https://arxiv.org/html/2510.06265v1)
39. Why language models hallucinate \- OpenAI, 访问时间为 二月 21, 2026， [https://openai.com/index/why-language-models-hallucinate/](https://openai.com/index/why-language-models-hallucinate/)
40. Consistency Is the Key: Detecting Hallucinations in LLM Generated Text By Checking Inconsistencies About Key Facts, 访问时间为 二月 21, 2026， [https://aclanthology.org/2025.findings-ijcnlp.129.pdf](https://aclanthology.org/2025.findings-ijcnlp.129.pdf)
41. White Paper: The State of Hallucinations in AI-Driven Insights \- Fuel Cycle, 访问时间为 二月 21, 2026， [https://fuelcycle.com/resources/white-paper-the-state-of-hallucinations-in-ai-driven-insights/](https://fuelcycle.com/resources/white-paper-the-state-of-hallucinations-in-ai-driven-insights/)
42. Consistency Is the Key: Detecting Hallucinations in LLM Generated Text By Checking Inconsistencies About Key Facts \- arXiv, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2511.12236v1](https://arxiv.org/html/2511.12236v1)
43. Hallucination Detection and Mitigation in Large Language Models \- arXiv, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2601.09929v1](https://arxiv.org/html/2601.09929v1)
44. From Illusion to Insight: A Taxonomic Survey of Hallucination Mitigation Techniques in LLMs, 访问时间为 二月 21, 2026， [https://www.mdpi.com/2673-2688/6/10/260](https://www.mdpi.com/2673-2688/6/10/260)
45. THaMES: An End-to-End Tool for Hallucination Mitigation and Evaluation in Large Language Models \- arXiv.org, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2409.11353v1](https://arxiv.org/html/2409.11353v1)
46. AI Agents Need an Inference-Bearing Knowledge Graph. Here's Why. \- Squirro, 访问时间为 二月 21, 2026， [https://squirro.com/squirro-blog/ai-agents-inference-knowledge-graphs](https://squirro.com/squirro-blog/ai-agents-inference-knowledge-graphs)
47. AutoGen vs LangGraph: Comparing Multi-Agent AI Frameworks \- TrueFoundry, 访问时间为 二月 21, 2026， [https://www.truefoundry.com/blog/autogen-vs-langgraph](https://www.truefoundry.com/blog/autogen-vs-langgraph)
48. Tested 5 agent frameworks in production \- here's when to use each one : r/AI\_Agents, 访问时间为 二月 21, 2026， [https://www.reddit.com/r/AI\_Agents/comments/1oukxzx/tested\_5\_agent\_frameworks\_in\_production\_heres/](https://www.reddit.com/r/AI_Agents/comments/1oukxzx/tested_5_agent_frameworks_in_production_heres/)
49. Autogen vs. LangGraph : r/LangChain \- Reddit, 访问时间为 二月 21, 2026， [https://www.reddit.com/r/LangChain/comments/1b7q44y/autogen\_vs\_langgraph/](https://www.reddit.com/r/LangChain/comments/1b7q44y/autogen_vs_langgraph/)
50. langchain-ai/langgraph: Build resilient language agents as graphs. \- GitHub, 访问时间为 二月 21, 2026， [https://github.com/langchain-ai/langgraph](https://github.com/langchain-ai/langgraph)
51. DataLab vs. Julius AI Comparison \- SourceForge, 访问时间为 二月 21, 2026， [https://sourceforge.net/software/compare/DataLab-vs-Julius.ai/](https://sourceforge.net/software/compare/DataLab-vs-Julius.ai/)
52. AI for Data Analysis | Julius vs. Claude: How do they compare?, 访问时间为 二月 21, 2026， [https://julius.ai/compare/julius-vs-claude](https://julius.ai/compare/julius-vs-claude)
53. 16 Best Data Analysis Tools: Features & How to Choose \[2026\] \- Julius AI, 访问时间为 二月 21, 2026， [https://julius.ai/articles/data-analysis-tools](https://julius.ai/articles/data-analysis-tools)
54. Best AI data agent architecture comparison 2026 | Energent.ai, 访问时间为 二月 21, 2026， [https://energent.ai/use-cases/en/compare/best-ai-data-agent-architecture-comparison](https://energent.ai/use-cases/en/compare/best-ai-data-agent-architecture-comparison)
55. Data Agents: Levels, State of the Art, and Open Problems \- arXiv, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2602.04261v1](https://arxiv.org/html/2602.04261v1)
56. The Six Maturity Levels of AI Agents | by Girish Kurup \- Medium, 访问时间为 二月 21, 2026， [https://girishkurup21.medium.com/the-six-maturity-levels-of-ai-agents-9720264a6c82](https://girishkurup21.medium.com/the-six-maturity-levels-of-ai-agents-9720264a6c82)
57. LLM-in-Sandbox-RL: Tool-Driven Reinforcement Learning \- Emergent Mind, 访问时间为 二月 21, 2026， [https://www.emergentmind.com/topics/llm-in-sandbox-reinforcement-learning-llm-in-sandbox-rl](https://www.emergentmind.com/topics/llm-in-sandbox-reinforcement-learning-llm-in-sandbox-rl)
58. Agent4S Framework: Autonomous Science Workflows \- Emergent Mind, 访问时间为 二月 21, 2026， [https://www.emergentmind.com/topics/agent4s-framework](https://www.emergentmind.com/topics/agent4s-framework)
59. Multi-Agent Collaboration Mechanisms: A Survey of LLMs \- arXiv, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2501.06322v1](https://arxiv.org/html/2501.06322v1)
60. HKUSTDial/awesome-data-agents \- GitHub, 访问时间为 二月 21, 2026， [https://github.com/HKUSTDial/awesome-data-agents](https://github.com/HKUSTDial/awesome-data-agents)

78
docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/外部架构调研总结与研发共识备忘录.md Normal file
View File

@@ -0,0 +1,78 @@
# **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，去打造业界最严谨、体验最好的智能统计助手！

189
docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/智能统计分析助手开发探讨.md Normal file
View File

@@ -0,0 +1,189 @@
# **智能化统计分析助手架构设计与实践：基于 Q-P-E-R 范式的深度研究报告**
## **引言与架构概述**
在自动化数据科学与临床统计学领域，系统架构的演进已经从传统的静态、基于规则的执行脚本，正式跨入具备自主推理、规划与自我纠错能力的智能体（Agent）时代。对于旨在极大提高系统智能化能力的统计分析助手（SSA-Pro）而言，如何在赋予大型语言模型（LLM）对话灵活性的同时，严格保障统计学分析的严谨性、可重复性与合规性，是架构设计的核心挑战。为了解决生成式人工智能固有的“幻觉”问题与专业统计分析对确定性的绝对需求之间的矛盾，业内最前沿的解决方案是构建基于 Query（查询）、Planner（规划）、Execute（执行）与 Reflection（反思）的四层 Q-P-E-R 架构框架 1。
这一架构的核心原则在于“分层递进”与“LLM 的选择性使用” 1。在 Q-P-E-R 范式中，系统的认知边界被严格划分：语言模型仅被部署在首端的 Query 层用于自然语言理解与意图解析，以及尾端的 Reflection 层用于结果解释与逻辑反思 1。中间的 Planner 层则依赖于确定性的决策表（Decision Tables）与工作流模板，而 Execute 层则完全交由成熟的统计引擎（如 R 语言代码库）进行精确计算 1。本研究报告将针对意图识别、智能规划器的构建、庞大 R 代码库的动态调用与修改、以及自我审查机制等核心问题，进行极其详尽的理论剖析与最佳实践推演，旨在为系统性提升统计分析助手的智能化水平提供详实的架构蓝图。
## **第一章：Query 层（认知与理解）—— 多模态意图识别与数据诊断诊断**
Query 层是整个智能统计分析系统的认知入口，其核心目标是将用户模糊的、非结构化的自然语言输入，精准转化为包含分析目标（Goal）、结果变量（Y）、预测变量（X）以及实验设计（Design）四个维度的结构化查询对象（ParsedQuery） 1。在构建这一层时，如何实现高精度的用户意图识别是首要解决的关键问题。
### **意图识别的技术路径：提示词工程与知识库的博弈**
在当前的智能体开发实践中，用户意图识别主要存在三种技术路径，它们在响应延迟、可扩展性以及对复杂语境的理解能力上各有优劣 2。
第一种路径是纯基于提示词（Prompt）与函数调用（Function Calling）的意图提取。这种方式依赖于将预定义的统计目标分类（如“差异性分析”、“相关性分析”、“预测模型”、“描述性统计”）直接写入系统提示词中，要求 LLM 在阅读用户输入后，直接输出对应的 JSON 结构 1。这种方法的优势在于启动成本低且对自然语言的微小差异具有极高的包容度 2。然而，当系统规模扩大，特别是面对医学或复杂商业分析中成百上千种细分统计意图时，将所有规则塞入上下文窗口不仅会导致极高的 Token 消耗和延迟，还会成倍增加模型幻觉的风险 3。
第二种路径是建立大规模意图识别知识库，通过语义路由（Semantic Routing）和向量检索（Vector Embeddings）来实现。语义路由器会将用户的查询转化为高维向量，并与向量数据库中预先存储的成千上万条标准意图话术进行余弦相似度比对 2。一旦相似度超过特定阈值，系统将直接触发对应的底层工作流，而无需调用沉重的生成式 LLM 4。这种方法在处理极其庞大的意图分类时具有毫秒级的响应速度和绝对的确定性，但其劣势在于缺乏推理能力，难以处理包含多个子意图的复合问题 4。
第三种路径，也是目前复杂数据分析智能体（如医疗临床试验助手）普遍采用的最佳实践，是混合智能体路由（Hybrid Agentic Routing） 5。在这种模式下，系统首先使用一个轻量级的分类器（如基于提示词的小型快速模型）进行顶层意图拦截。一旦识别出用户的查询属于复杂的统计范畴，系统会触发检索增强生成（RAG）机制，连接到专有的统计学知识库或临床终点数字图书馆（Library of Digital Endpoints） 5。通过将用户输入与知识库中的本体标签进行匹配，LLM 能够基于检索到的专业上下文，精确填补结构化查询中的缺失字段 6。
对于 SSA-Pro 这类专业级统计分析系统，强烈建议采用这种混合路径。此外，必须在 Query 层引入置信度阈值机制。当 LLM 提取上述四个维度信息（目标、Y、X、设计）的置信度低于 0.7 时，系统绝不能强行向下游传递错误参数，而应通过 Clarifier（澄清模块）主动发起多轮对话，利用动态生成的澄清卡片（ClarificationCard）向用户追问缺失的关键变量 1。
### **数据诊断：意图识别的物理锚点**
一个常被忽视的行业洞察是：纯粹的语义意图识别在统计学领域是不充分的。用户的意图不仅存在于文字中，还深刻绑定在其提供的数据几何形态中。例如，用户可能要求“比较两组患者的血压差异”，从语义上看，这指向了独立样本 T 检验。但如果血压数据存在严重的极端异常值且不符合正态分布，正确的意图解析必须被重定向为非参数的曼-惠特尼 U 检验。
因此，Query 层的智能化水平提升，必须依赖于 DataProfiler（数据诊断服务）的深度介入 1。在生成最终的意图对象之前，系统必须调用后台脚本对用户上传的数据进行一次全方位的自动化体检。这包括利用四分位距（IQR）进行异常值检测、评估各组样本量的平衡性、计算数据缺失率、以及准确识别每个变量的物理类型（连续性、分类、二元） 1。提取出的这些数据画像元数据（Metadata）随后会被注入到 LLM 的提示词模板中。通过这种被称为混合提示（Hybrid Prompting）的技术，结合明确的指令、推理脚手架（思维链）和严格的格式限制，系统能够基于真实的数据分布来校准用户的初始意图，从而在源头上杜绝无效的统计请求 8。
| 意图识别路径 | 核心机制 | 适用场景与优势 | 潜在劣势与挑战 |
| :---- | :---- | :---- | :---- |
| **基于提示词的函数调用** | LLM 解析文本语义，强制输出符合预定义 JSON 模式的目标与变量映射。 | 适用于早期开发或意图种类较少的系统。灵活性极高，能理解极其模糊的自然语言 2。 | 延迟高，Token 成本昂贵；当工具集扩大时，极其容易出现参数幻觉和分类错误 3。 |
| **基于知识库的语义路由** | 将查询向量化，与庞大语料库中的标准模板进行相似度计算匹配。 | 适用于拥有标准化 SOP 且意图数量庞大的成熟系统。响应速度极快，成本极低，具备确定性 2。 | 无法处理超出知识库范围的新型提问；对复合型意图（一句话包含多个诉求）的解析能力较差 4。 |
| **混合智能体与元数据注入** | 结合轻量级分类器、垂直领域 RAG 检索以及底层数据的自动化诊断画像。 | 业内最佳实践（如临床数据智能体）。能够结合数据真实分布与语义信息，实现极高精度的意图矫正 5。 | 架构复杂度最高；需要构建完善的异常处理与多轮澄清对话（Clarifier）机制 1。 |
## **第二章：Planner 层（规划与决策）—— 神经符号规划与 SAP 自动生成**
当 Query 层输出了包含数据画像与用户目标的 ParsedQuery 后，系统进入控制统计学严谨性的核心地带——Planner 层。这一层的主要职责是决定具体的分析方法论和执行顺序，并最终生成一份详尽的统计分析计划（Statistical Analysis Plan, SAP） 1。为了提升智能化水平并保证绝对的科学正确性，Planner 层必须摒弃纯粹依赖 LLM 生成逻辑的做法，转而采用行业内最前沿的神经符号整合（Neuro-Symbolic Integration）架构。
### **神经符号架构与决策表（Decision Table）的构建**
传统的数据分析智能体往往采用思维链（Chain-of-Thought）提示，让 LLM 自己推理应该使用何种统计方法。然而，自然语言推理虽然灵活，但在严密的统计学法则面前却经常充满歧义和不精确性，极其容易忽略潜在的假设前提 10。神经符号架构则结合了两种范式的优势：利用 LLM 强大的语义解析与上下文管理能力（神经系统），结合硬编码的、基于专家经验的统计学逻辑规则库（符号系统） 12。
在具体实现中，这种符号逻辑体现为 DecisionTable（决策表）模块 1。要建立一个智能化的 Planner，绝不能让 LLM 自由发挥，而是必须将明确的约束信息输入到决策逻辑中。这些输入信息包括：用户定义的分析目标（如关联性、差异性）、Y 变量的属性（如连续性变量、二分类变量、多分类变量）、X 变量的属性及其数量、以及实验设计方式（如配对样本还是独立样本） 1。
通过建立一个高维度的映射矩阵，系统能够实现精确的方法匹配。例如，当系统识别到目标为“比较差异”，因变量为“连续性变量”，自变量为“包含两个类别的分类变量”，且实验设计为“独立样本”时，决策表会确定性地将“独立样本 T 检验”设为“首选工具”（Primary Tool）。同时，基于统计学的基本规则，决策表必须配备条件分支：如果数据诊断显示不满足正态分布或方差齐性，则指定“曼-惠特尼 U 检验”或“韦尔奇 T 检验”为“备选工具”（Fallback Tool） 1。通过这种将显式规则与大模型结合的手段，系统既能理解复杂的业务诉求，又能确保统计学路径的绝对合规。
### **工作流模板（Flow Templates）与分层图建模**
真实的专业统计分析绝非单一算法的调用，而是一整套标准操作流程（SOP）。为了让 Planner 生成的 SAP 达到专业级水准，必须在架构中引入 FlowTemplateService 1。不同分析目标对应不同的标准化流程模板。以“两组连续性变量比较”这一模板为例，Planner 不仅要规划主分析（T 检验），还要强制在 SAP 中自动插入前置步骤，如描述性统计生成（均值、标准差）、假设检验（正态性的 Shapiro-Wilk 检验、方差齐性的 Levene 检验），以及后续的敏感性分析 1。这些流程被打包成可重用的工作流，极大地降低了 LLM 的规划难度，并确保了不同用户执行相同任务时结果的一致性 14。
在行业最佳应用中，诸如 MetaGPT 开发的 Data Interpreter 智能体，已经将这种线性流程升级为基于分层有向无环图（Hierarchical DAG）的动态图建模 15。面对复杂的数据科学问题，LLM 驱动的规划器会将庞大的分析目标拆解为多个子任务节点，并通过图结构表达它们的执行依赖关系 16。DAG 架构不仅允许系统识别可并行执行的任务（如同时进行异常值检测与相关性分析），还赋予了系统极强的动态适应能力。如果在分析中途由于数据形态的突然改变导致某个节点失效，基于图结构的 Planner 可以在局部重新规划路径，而无需从头重启整个分析链条 17。
## **第三章：Execute 层（编排与执行）—— 破解百级 R 代码库的动态修改与融合**
Execute 层承担着将高维度的 SAP 翻译为底层机器可执行指令，并与 R 引擎进行交互以获取统计结果的重任 1。贵团队目前面临的核心痛点是：已拥有超过 100 个成熟的 R 语言脚本，希望通过 LLM 修改和调度这些代码以响应多样化的用户需求。在处理庞大代码库时，传统的代码生成方案会遭遇严重的瓶颈，而破解这一难题需要综合运用元数据 RAG 检索、抽象语法树（AST）解析以及结构化的工具调用范式。
### **元数据检索增强（Metadata RAG）解决上下文溢出**
将 100 多个动辄数百行的 R 语言脚本全部塞入 LLM 的上下文窗口是完全不可行的。这不仅会导致高昂的算力成本，更会引发模型注意力机制的崩溃（即“迷失在中间”现象），导致生成的代码张冠李戴 19。业内最佳实践是利用检索增强生成（RAG）技术，但并非对源代码本身进行检索，而是对“代码元数据”进行检索 21。
该方案要求在离线阶段，利用 LLM 对现有的 R 代码库进行系统性扫描，为每一个脚本、每一个函数生成高度浓缩的文档摘要 21。这些摘要必须详细记录该函数的功能意图、所需的入参数据类型、期望的返回结果以及典型的应用示例 22。随后，这些摘要被转化为向量嵌入（Embeddings）并与原始 R 文件的抽象语法树（AST）节点建立严格的映射关系 21。当 Planner 层下达具体的分析指令时，执行层的控制智能体首先在元数据向量库中进行检索，精准定位到解决当前任务所需的 1 到 3 个核心 R 脚本，仅仅提取这些高度相关的代码片段作为上下文提供给 LLM 21。这种精准喂药的策略从根本上保障了 LLM 在修改复杂系统时的稳定性。
### **基于抽象语法树（AST）的代码动态融合与组装**
当 LLM 接收到用户的个性化需求（如过滤特定人群、修改特定的回归参数）并需要对现有的 R 脚本进行修改时，最忌讳的做法是让 LLM 重写整个文件。由于传统对话界面生成的代码片段经常在合并时破坏源文件的结构，业内开始转向基于抽象语法树（AST）的代码融合技术 23。
AST 能够将 R 语言源码解析为由节点和分支组成的树状逻辑结构。当 LLM 基于用户需求生成了修改后的代码片段后，系统会同时对原始的 R 文件和 LLM 生成的片段进行 AST 解析 23。在树的层面上，系统可以像做外科手术一样，精准定位到需要替换的函数定义或需要更新的数据过滤逻辑，将 LLM 生成的新节点无缝嫁接到原始代码树上，并最终重新生成完整的 R 脚本 23。这种方法彻底规避了正则表达式匹配的脆弱性，确保插入的代码不仅语法合法，而且维持了原有企业级代码的稳定结构 23。
### **胶水代码（Glue Code）的动态生成与区块化输出**
在实际运行中，Execute 层表现为一个智能的工具调用（Tool-Calling）框架 25。这 100 多个 R 脚本被封装为一个个具有严格输入输出 Schema 限制的独立工具。LLM 在这一层的主要角色不再是“从零编写算法”，而是扮演“编排者”的角色，编写轻量级的“胶水代码”（Glue Code），利用 R 语言中的 pal、ellmer 等集成包，将各种参数和数据框（Dataframes）与现有的工具库连接起来 27。
为了彻底解放 LLM 对 UI 渲染的负担，极大地提高智能化并降低出错率，Execute 层必须贯彻“区块化（Block-based）协议” 1。在修改和封装所有的 100+ R 工具时，应统一其输出标准，强制引擎返回 report\_blocks（如标准化的表格数据、键值对指标、序列化的图像对象），而不是让 LLM 去生成复杂的 HTML 或 Markdown 渲染代码 1。前端 UI 层接收到这些区块后进行动态渲染，这种计算与展示的深度解耦，是构建高性能统计智能体的黄金准则。
## **第四章：Reflection 层（反思与审查）—— 闭环系统中的自我纠错与长效记忆**
传统的自动化脚本在遭遇报错时会立刻中断并抛出异常，等待人类工程师介入。而在 Q-P-E-R 架构中，Reflection 层的引入标志着系统从反应性的“系统 1”跃升为深思熟虑的“系统 2” 30。该层通过在系统内部建立闭环的评估与纠错机制，使得智能体能够像资深统计师一样，对刚刚产生的计算结果进行批判性质疑和自适应修复 14。
### **运行时错误捕获与基于 Reflexion 的代码修复**
在 Execute 层动态组装和运行 R 代码的过程中，语法报错、数据维度不匹配或库依赖冲突是不可避免的。当 R 引擎抛出错误堆栈日志时，Reflection 层会捕获这些信息，并触发基于 Reflexion 框架的自我反思循环 30。
该机制结合了思维链（CoT）推理与口头强化（Verbal Reinforcement）技术 30。充当“LLM 批评家”（LLM Critic）的智能体不会盲目地要求重新运行代码，而是会深度分析错误日志，并用自然语言生成一份反思摘要（例如：“尝试对包含缺失值的向量进行相关性计算导致了 NA 错误，需要在调用 cor() 函数前加入 use \= 'complete.obs' 参数”），随后将包含明确改进建议的指令回传给 Execute 层进行二次尝试 1。这种无需外部新数据训练即可实现代码层面自我修复的能力，是保障系统稳健运行的核心 30。
### **自动化统计学审查与安全护栏（Guardrails）**
相较于显性的代码报错，更隐蔽且危险的是由于违反统计学假设而得出的“数学上正确但科学上谬误”的结果。因此，Reflection 层必须配备一套自动化的统计学审查护栏 8。
当统计计算顺利完成并返回结果时，Reflection 层需要依据 Planner 层在决策表中设定的预定规则，对结果进行深度校验。例如，如果主分析执行了方差分析（ANOVA），系统必须优先检查并发执行的 Levene 检验的 p 值 8。如果发现 ![][image1]（即方差不齐的假设被拒绝），Reflection 层必须主动阻断当前分析结果的输出，判定此次分析在统计学上是不成立的，并自动向 Planner 层发出回调指令，强制切换至预设的备选工具（Fallback Tool，如 Welch's ANOVA）重新执行 8。此外，可以通过引入基于微调或特定提示模板的“LLM 裁判”（LLM-as-a-judge），审查最终报告是否完整包含检验统计量、自由度、置信区间等必须元素，从而确保输出达到学术发表级别的质量 1。
### **长效记忆与经验积累的存储机制**
为了让智能助手随着使用时间的推移变得越来越聪明，避免在同一数据集上重复犯错，系统必须建立完善的记忆与经验存储机制 14。这种记忆分为两类：
1. **短期上下文记忆：** 在单一会话周期内保持多轮对话的完整状态，允许用户在中途改变分析方向或对图表配色提出修改意见，而无需重新阐述数据背景 14。
2. **长期语义记忆库：** 作为一个专门的向量数据库（Vector Database），长期记忆库用于存储智能体在运行中总结出的宝贵经验 36。例如，当系统经过多次反思循环终于解决了一个复杂的 R 代码包冲突问题，或者识别出某个特定业务数据中潜藏的隐藏过滤逻辑时，它会将这一经验浓缩并打上语义标签存入向量数据库 14。在未来的分析任务中，如果面对相似的表结构或查询意图，系统会优先提取这些经验记录，直接跳过错误的推理路径，实现跨会话的系统性进化 37。
| 反思与审查维度 | 触发条件与输入 | 处理机制与技术手段 | 输出与下一步动作 |
| :---- | :---- | :---- | :---- |
| **执行期代码错误** | R 引擎抛出报错堆栈与日志 33。 | 利用 Reflexion 框架与 CoT 进行错误根因分析，生成口头强化摘要 30。 | 将附带修改建议的自然语言指令回传给 Execute 层重写胶水代码 33。 |
| **统计学假设冲突** | 前置检验（如正态性、方差齐性）返回不合规的统计量 8。 | 与决策表（Decision Table）中的理论约束进行比对，触发规则护栏 8。 | 阻断错误结果生成，回调 Planner 强制激活并执行备选方案 8。 |
| **逻辑优化与经验沉淀** | 复杂任务执行成功或经过多轮干预后得出正确结果 14。 | 对执行路径进行摘要提炼，并转化为高维向量存储 36。 | 将关键经验存入长期向量记忆库，在未来类似场景中进行语义预加载 37。 |
## **第五章：针对数据分析 Agent 的最佳应用与行业实践**
在当前人工智能与数据科学交叉的最前沿领域，许多顶级机构已经构建了基于上述逻辑的强大智能体。通过分析这些最佳应用案例，可以为我们系统性提升智能化水平提供直接的借鉴。
### **OpenAI 的内部高级数据智能体**
OpenAI 开发的内部数据智能体（Advanced Data Analysis 工作流的前身）展示了端到端分析闭环的巨大潜力 14。该系统的显著特征是彻底将迭代和试错的负担从人类用户转移到了机器身上 14。在其实践中，智能体会自主管理从自然语言理解、SQL 数据库查询到最终图表绘制的全过程。更重要的是，它具备极强的自我检查能力：当一个查询由于错误的联合（Join）逻辑返回空数据时，它不会直接向用户报错，而是深入数据库的元数据层，重新分析表结构，调整查询逻辑进行重试 14。为了解决重复性劳动的效率问题，OpenAI 引入了“可复用工作流”（Reusable Workflows）机制，将高频的商业报表生成和验证逻辑打包成模块，确保了系统在面对日常统计分析时的高度一致性 14。
### **MetaGPT Data Interpreter 的图结构动态规划**
在开源生态中，MetaGPT 团队推出的 Data Interpreter 堪称复杂数据科学规划的典范 15。在面对机器学习任务或多变量相关性分析时，传统的线性思维链往往会陷入死胡同。Data Interpreter 创新性地引入了基于分层有向无环图（DAG）的动态规划机制 16。在分析开始前，它将庞大的目标拆解为细粒度的任务节点图。最关键的是，在执行过程中，系统持续监控节点产生的数据流，如果因为上游工具的处理导致中间数据形态发生变化，Data Interpreter 能够在不破坏全局目标的前提下，动态调整下游的任务图结构 17。通过配合自动化的工具集成与基于经验的置信度验证，该系统在机器学习任务上的准确率从基线的 88% 大幅提升至 95%，在开放式数学推理问题上提升了 112% 16。
### **临床试验智能体的合规与团队协作机制**
在合规要求极为严格的医药研发与临床试验领域，智能体的最佳应用集中在对绝对准确性和可追溯性的追求上。例如，在处理诸如统计分析计划生成和 TLFs（图表和列表）批量生成的工作流中，智能体受到严格的数字终点库（DiMe）本体和联邦监管指南的约束 6。
以 TeamMedAgents 等框架为例，它们采用了基于角色的多智能体协作模式，将人类医疗团队的审查逻辑映射到 AI 系统中 41。在这些系统中，负责编写 SAS 或 R 代码的“分析智能体”之上，必定叠加着一个独立的“医学监查智能体” 41。监查智能体专门负责在后台审查统计结果是否符合预先设定的决策树逻辑，并验证所有的数据流向是否满足 ALCOA+（可归因性、易读性、同时性、原始性和准确性）的数据完整性标准 42。这种强护栏设计不仅实现了 40% 的交付提速，更满足了 FDA 对防篡改决策日志的监管要求 42。
### **Julius AI 的持久化学习与无缝交互**
作为商业化非常成功的数据分析应用，Julius AI 的核心竞争力在于其底层对于“持久化学习”（Persistent Learning）的巧妙运用以及对交互界面的极简重构 44。用户只需连接数据库或上传 CSV，系统会在后台自动构建数据库的 Schema 映射关系，并且随着用户的持续使用，系统能记住特定的字段含义（例如记忆“revenue”列应该与销售表关联） 44。其智能化的另一大亮点是能将复杂的分析逻辑直接转化为基于 Notebook 的可视化步骤，辅以自然语言的洞察解释，在底层使用 Python/R 代码沙盒保障运算精准度的同时，在表层给用户提供了高度拟人化的交流体验 45。
## **第六章：核心总结与智能化提升之系统性建议**
综上所述，开发一款具有极致智能化能力的统计分析助手，绝不仅仅是对一个生成式语言模型进行简单的封装。它需要融合自然语言处理、符号逻辑学、抽象语法树解析以及深度强化学习机制，构建一个缜密且容错的生态工程。针对贵团队的需求，要系统性提升 SSA-Pro 的智能化水平，建议在开发路径上采取以下四个核心维度的落地策略：
首先，在**理解维度**，坚决放弃粗放的全文 Prompt 分类，全面拥抱以元数据为驱动的混合路由架构。通过前置的数据诊断服务（DataProfiler）获取变量的真实物理特征，将其作为强约束条件注入意图识别流程，辅以语义检索库进行细分统计目标的精准锚定，并在低置信度时引入柔性的澄清卡片与用户互动。
其次，在**规划维度**，必须将统计学的灵魂——严密的数理逻辑与假设检验规则，固化为神经符号系统的决策表（Decision Table）。利用大模型强大的推理能力去理解业务场景，但将其最终落地的统计方法选择权，交由硬编码的逻辑树与标准化工作流模板（Flow Templates）来裁定，从而在根源上消除模型在方法论选择上的幻觉。
再次，在**执行维度**，面对百级以上的高价值 R 语言遗产代码库，应利用基于抽象语法树（AST）和代码元数据的检索增强（RAG）技术进行盘活。让 LLM 从“代码编写者”转型为“流程编排者”，通过生成轻量级的胶水代码，精准调度封装好的 R 函数工具。同时，全面实施计算与渲染解耦的“区块化”输出协议，保障前端展示的灵活性与底层执行的稳定性。
最后，在**反思维度**，要赋予系统“自我意识”。通过构建拦截运行错误的 Reflexion 循环框架，以及核对统计假设的自动审查护栏，实现结果交付前的高频内审。并辅以支持语义检索的长效记忆向量数据库，使智能体能够在使用中不断累积纠错经验，实现从单次自动化工具向可持续进化的智能分析专家的终极跨越。
#### **引用的著作**
1. 10-QPER架构开发计划-智能化主线.md
2. Intent Recognition and Auto‑Routing in Multi-Agent Systems \- GitHub Gist, 访问时间为 二月 21, 2026， [https://gist.github.com/mkbctrl/a35764e99fe0c8e8c00b2358f55cd7fa](https://gist.github.com/mkbctrl/a35764e99fe0c8e8c00b2358f55cd7fa)
3. Manual intent detection vs Agent-based approach: what's better for dynamic AI workflows? : r/LangChain \- Reddit, 访问时间为 二月 21, 2026， [https://www.reddit.com/r/LangChain/comments/1l7p3qy/manual\_intent\_detection\_vs\_agentbased\_approach/](https://www.reddit.com/r/LangChain/comments/1l7p3qy/manual_intent_detection_vs_agentbased_approach/)
4. Mastering RAG Chatbots: Semantic Router — User Intents | by Tal Waitzenberg | Medium, 访问时间为 二月 21, 2026， [https://medium.com/@talon8080/mastering-rag-chabots-semantic-router-user-intents-ef3dea01afbc](https://medium.com/@talon8080/mastering-rag-chabots-semantic-router-user-intents-ef3dea01afbc)
5. AI Workflows vs. AI Agents \- Prompt Engineering Guide, 访问时间为 二月 21, 2026， [https://www.promptingguide.ai/agents/ai-workflows-vs-ai-agents](https://www.promptingguide.ai/agents/ai-workflows-vs-ai-agents)
6. AI Agent-Powered FDA-Compliant Clinical Trial Design Using the Library of Digital Endpoints | by Alex G. Lee | Medium, 访问时间为 二月 21, 2026， [https://medium.com/@alexglee/ai-agent-powered-fda-compliant-clinical-trial-design-using-the-library-of-digital-endpoints-c2c1d0be3248](https://medium.com/@alexglee/ai-agent-powered-fda-compliant-clinical-trial-design-using-the-library-of-digital-endpoints-c2c1d0be3248)
7. AI Agent Clinical Trial Optimization 2025 \- Rapid Innovation, 访问时间为 二月 21, 2026， [https://www.rapidinnovation.io/post/ai-agent-clinical-trial-optimization-assistant](https://www.rapidinnovation.io/post/ai-agent-clinical-trial-optimization-assistant)
8. Prompt engineering for accurate statistical reasoning with ... \- Frontiers, 访问时间为 二月 21, 2026， [https://www.frontiersin.org/journals/artificial-intelligence/articles/10.3389/frai.2025.1658316/full](https://www.frontiersin.org/journals/artificial-intelligence/articles/10.3389/frai.2025.1658316/full)
9. Prompt engineering for accurate statistical reasoning with large language models in medical research \- PubMed, 访问时间为 二月 21, 2026， [https://pubmed.ncbi.nlm.nih.gov/41159127/](https://pubmed.ncbi.nlm.nih.gov/41159127/)
10. HybridMind: Meta Selection of Natural Language and Symbolic Language for Enhanced LLM Reasoning \- arXiv, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2409.19381v5](https://arxiv.org/html/2409.19381v5)
11. Bridging Symbolic Logic and Neural Intelligence: Hybrid Architectures for Scalable, Explainable AI \- Preprints.org, 访问时间为 二月 21, 2026， [https://www.preprints.org/manuscript/202504.0887](https://www.preprints.org/manuscript/202504.0887)
12. Advancing Symbolic Integration in Large Language Models: Beyond Conventional Neurosymbolic AI \- arXiv, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2510.21425v1](https://arxiv.org/html/2510.21425v1)
13. Symbolic-to-LLM Integration in Hybrid AI \- Emergent Mind, 访问时间为 二月 21, 2026， [https://www.emergentmind.com/topics/symbolic-to-llm](https://www.emergentmind.com/topics/symbolic-to-llm)
14. Inside OpenAI's in-house data agent | OpenAI, 访问时间为 二月 21, 2026， [https://openai.com/index/inside-our-in-house-data-agent/](https://openai.com/index/inside-our-in-house-data-agent/)
15. Data Interpreter: An LLM Agent For Data Science \- ACL Anthology, 访问时间为 二月 21, 2026， [https://aclanthology.org/2025.findings-acl.1016.pdf](https://aclanthology.org/2025.findings-acl.1016.pdf)
16. arxiv.org, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2402.18679v1](https://arxiv.org/html/2402.18679v1)
17. Data Interpreter LLMagent Data Science | PDF | Formal Verification \- Scribd, 访问时间为 二月 21, 2026， [https://www.scribd.com/document/905799019/Data-Interpreter-LLMagent-Data-Science](https://www.scribd.com/document/905799019/Data-Interpreter-LLMagent-Data-Science)
18. Auto-DS (I): The Data Interpreter | by Haitham Bou Ammar | Medium, 访问时间为 二月 21, 2026， [https://medium.com/@haitham.bouammar71/auto-ds-i-the-data-interpreter-1cbecf2820ff](https://medium.com/@haitham.bouammar71/auto-ds-i-the-data-interpreter-1cbecf2820ff)
19. How to use existing production code to build new features : r/aipromptprogramming \- Reddit, 访问时间为 二月 21, 2026， [https://www.reddit.com/r/aipromptprogramming/comments/1hykq77/how\_to\_use\_existing\_production\_code\_to\_build\_new/](https://www.reddit.com/r/aipromptprogramming/comments/1hykq77/how_to_use_existing_production_code_to_build_new/)
20. From Snippets to Systems: Advanced Techniques for Repository-Aware Coding Assistants | by Colin Baird | Medium, 访问时间为 二月 21, 2026， [https://medium.com/@colinbaird\_51123/from-snippets-to-systems-advanced-techniques-for-repository-aware-coding-assistants-cf1a2086ab41](https://medium.com/@colinbaird_51123/from-snippets-to-systems-advanced-techniques-for-repository-aware-coding-assistants-cf1a2086ab41)
21. LLM Agents for Automated Dependency Upgrades \- arXiv, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2510.03480v1](https://arxiv.org/html/2510.03480v1)
22. ReadMe.LLM: A Framework to Help LLMs Understand Your Library \- arXiv, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2504.09798v1](https://arxiv.org/html/2504.09798v1)
23. LLM generated code snippet merging into existing using ASTs : r/theprimeagen \- Reddit, 访问时间为 二月 21, 2026， [https://www.reddit.com/r/theprimeagen/comments/1idtjp2/llm\_generated\_code\_snippet\_merging\_into\_existing/](https://www.reddit.com/r/theprimeagen/comments/1idtjp2/llm_generated_code_snippet_merging_into_existing/)
24. Many Hands Make Light Work: An LLM-based Multi-Agent System for Detecting Malicious PyPI Packages \- arXiv, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2601.12148v2](https://arxiv.org/html/2601.12148v2)
25. Creating and using a Code Agent \- Dataiku Developer Guide, 访问时间为 二月 21, 2026， [https://developer.dataiku.com/latest/tutorials/genai/agents-and-tools/code-agent/index.html](https://developer.dataiku.com/latest/tutorials/genai/agents-and-tools/code-agent/index.html)
26. Tool Based Agent Pattern \- Elumenotion, 访问时间为 二月 21, 2026， [https://www.elumenotion.com/journal/toolbasedagents/](https://www.elumenotion.com/journal/toolbasedagents/)
27. Three experiments in LLM code assist with RStudio and Positron, 访问时间为 二月 21, 2026， [https://tidyverse.org/blog/2025/01/experiments-llm/](https://tidyverse.org/blog/2025/01/experiments-llm/)
28. LLM-Powered, Expert-Refined Causal Loop Diagramming via Pipeline Algebra \- MDPI, 访问时间为 二月 21, 2026， [https://www.mdpi.com/2079-8954/13/9/784](https://www.mdpi.com/2079-8954/13/9/784)
29. Replace Python with Go for LLMs? : r/golang \- Reddit, 访问时间为 二月 21, 2026， [https://www.reddit.com/r/golang/comments/1lfr9hi/replace\_python\_with\_go\_for\_llms/](https://www.reddit.com/r/golang/comments/1lfr9hi/replace_python_with_go_for_llms/)
30. Building a Self-Correcting AI: A Deep Dive into the Reflexion Agent with LangChain and LangGraph | by Vi Q. Ha | Medium, 访问时间为 二月 21, 2026， [https://medium.com/@vi.ha.engr/building-a-self-correcting-ai-a-deep-dive-into-the-reflexion-agent-with-langchain-and-langgraph-ae2b1ddb8c3b](https://medium.com/@vi.ha.engr/building-a-self-correcting-ai-a-deep-dive-into-the-reflexion-agent-with-langchain-and-langgraph-ae2b1ddb8c3b)
31. A Survey of Self-Evolving Agents: On Path to Artificial Super Intelligence \- arXiv, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2507.21046v1](https://arxiv.org/html/2507.21046v1)
32. Self-Evaluation in AI Agents Through Chain of Thought and Reflection \- Galileo AI, 访问时间为 二月 21, 2026， [https://galileo.ai/blog/self-evaluation-ai-agents-performance-reasoning-reflection](https://galileo.ai/blog/self-evaluation-ai-agents-performance-reasoning-reflection)
33. Agent Feedback Loops: From OODA to Self-Reflection | by Tao An | Medium, 访问时间为 二月 21, 2026， [https://tao-hpu.medium.com/agent-feedback-loops-from-ooda-to-self-reflection-92eb9dd204f6](https://tao-hpu.medium.com/agent-feedback-loops-from-ooda-to-self-reflection-92eb9dd204f6)
34. Self-Reflection in LLM Agents: Effects on Problem-Solving Performance \- arXiv, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2405.06682v3](https://arxiv.org/html/2405.06682v3)
35. \#12: How Do Agents Learn from Their Own Mistakes? The Role of Reflection in AI, 访问时间为 二月 21, 2026， [https://huggingface.co/blog/Kseniase/reflection](https://huggingface.co/blog/Kseniase/reflection)
36. Best practices for managing long-term memory in chatbots (Bedrock Agents) | AWS re:Post, 访问时间为 二月 21, 2026， [https://repost.aws/questions/QUvmFZ\_RPoTEm8jQk0SddKNw/best-practices-for-managing-long-term-memory-in-chatbots-bedrock-agents](https://repost.aws/questions/QUvmFZ_RPoTEm8jQk0SddKNw/best-practices-for-managing-long-term-memory-in-chatbots-bedrock-agents)
37. Comparing File Systems and Databases for Effective AI Agent Memory Management | by Richmond Alake | Oracle Developers | Feb, 2026 | Medium, 访问时间为 二月 21, 2026， [https://medium.com/oracledevs/comparing-file-systems-and-databases-for-effective-ai-agent-memory-management-5322ac45f3b6](https://medium.com/oracledevs/comparing-file-systems-and-databases-for-effective-ai-agent-memory-management-5322ac45f3b6)
38. Building smarter AI agents: AgentCore long-term memory deep dive \- AWS, 访问时间为 二月 21, 2026， [https://aws.amazon.com/blogs/machine-learning/building-smarter-ai-agents-agentcore-long-term-memory-deep-dive/](https://aws.amazon.com/blogs/machine-learning/building-smarter-ai-agents-agentcore-long-term-memory-deep-dive/)
39. DATA INTERPRETER: AN LLM AGENT FOR DATA SCIENCE \- OpenReview, 访问时间为 二月 21, 2026， [https://openreview.net/pdf/6908a9386102602f5d4722c6ffbb3d740ead352a.pdf](https://openreview.net/pdf/6908a9386102602f5d4722c6ffbb3d740ead352a.pdf)
40. arXiv:2409.12046v2 \[cs.CL\] 19 Sep 2024, 访问时间为 二月 21, 2026， [https://arxiv.org/pdf/2409.12046](https://arxiv.org/pdf/2409.12046)
41. TeamMedAgents: Enhancing Medical Decision-Making of LLMs Through Structured Teamwork \- arXiv, 访问时间为 二月 21, 2026， [https://arxiv.org/html/2508.08115v1](https://arxiv.org/html/2508.08115v1)
42. Agentic AI in Clinical Trials: Enabling Scalable Solutions | EPAM, 访问时间为 二月 21, 2026， [https://www.epam.com/insights/blogs/agentic-ai-in-clinical-trials-enabling-scalable-solutions](https://www.epam.com/insights/blogs/agentic-ai-in-clinical-trials-enabling-scalable-solutions)
43. Generative AI in the pharmaceutical industry: Moving from hype to reality \- McKinsey, 访问时间为 二月 21, 2026， [https://www.mckinsey.com/industries/life-sciences/our-insights/generative-ai-in-the-pharmaceutical-industry-moving-from-hype-to-reality](https://www.mckinsey.com/industries/life-sciences/our-insights/generative-ai-in-the-pharmaceutical-industry-moving-from-hype-to-reality)
44. AI for Data Analysis | AI in Analytics: What It Is, How It Works, and a Top Example \- Julius AI, 访问时间为 二月 21, 2026， [https://julius.ai/articles/ai-in-analytics](https://julius.ai/articles/ai-in-analytics)
45. AI for Data Analysis | Workflows: AI-Driven Insights, 访问时间为 二月 21, 2026， [https://julius.ai/feature\_page/workflows](https://julius.ai/feature_page/workflows)
46. Top 10 AI Tools for Excel Data Analysis in 2026 | by Powerdrill AI \- Medium, 访问时间为 二月 21, 2026， [https://medium.com/@powerdrillai/top-10-ai-tools-for-excel-data-analysis-in-2026-8edd8eba3a70](https://medium.com/@powerdrillai/top-10-ai-tools-for-excel-data-analysis-in-2026-8edd8eba3a70)
[image1]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEYAAAAYCAYAAABHqosDAAACj0lEQVR4Xu2Xz6tNURTHl1DkV2TwlPKUUiaUX3kmBpTyIwNRyNTEyIC/wMTATCRvYCCRTGQi5WXIWCYMCAMlGTAgP/bH2uveddY9957z7u3d3mB/anXP/u51ztnne/dZex+RQqFQKBQKzTxM8TfHdOgbxOIUn6V77olq93/epbiRYn2K5Sl2pfiYYp1Pmo98TXHTtTlGawJTMIMHNTjvumsDxphxFmcrGWPmWBRqOCA6UM+CrO0JeuRRii9B2y567iKnYcwZUcP3OX2s8FBPUvxIsTL01fFKeo0BtJkoBupyVmT9qNMwhleokb0p3oq+czCV4n2KU52M2cO0fiM6CI7bYlM7goa5/VgmmvM06BiAfsdprYxZleJ+ip2iF8CQLbnvufTeqAkG+C3FixQLQ18bGMP3KEp/wwwKJ/23g27GvHQaxjwTnV0Xc39Pjbkras5+0YRJ13cka7wOTTCw36KrySjMlTGYYXA86dobRXN2O00O5d/H0nvjy1kbNO02i+ZcjR1DMg5j6iCnduX7I9XpBh9k8GDAjLkWO4aEa/2KojQbYwY86KPPOG21OzZqr78ki6eDjoY5beAf+ymjv0r9/gw0FohBRAPAVqULuX0pt291MpRaY6y+eCcPZm2D09owavE9LzUDFNXOufbSFFdcG15L7z5mq+i5a3Mbg2jv6GR090mcX8HqC2aAJTLIYcEUbjTb5druzUbPOJk1D9dFYwYYm7KGaQYrq39gNnqxhtnKxCJUweoLFyCBsD3NqPCgbPCYRW02eLBGdAyMieCYmejZlnVvAhzO+j3RYspeKjIhmvMp/xLcs0K/+jIXtPkkmDfU1ZeC6E4XY45Lt0AVRD/R2eFiTHyPC4Uq/wAHw7g+JlDcWQAAAABJRU5ErkJggg==>

102
docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/架构与产品委员会综合评估报告.md Normal file
View File

@@ -0,0 +1,102 @@
# **架构与产品委员会综合评估报告：SSA-Pro 人机协同 (HITL) 交互增强与 Phase Q+ 演进规划**
**文档版本：** v2.0 (完整整合版)
**创建日期：** 2026-02-20
**核心裁决：** 🌟 **极度赞同 (Highly Recommended)**。引入“变量字典”与“变量筛选”两大专家协同功能，不仅填补了 AI 临床背景知识的短板，且通过划分为独立的 Phase Q+ 子阶段，完美平衡了“追求极致体验”与“保障核心交付”的矛盾。
## **第一部分：业务需求评估 (为什么要引入人机协同？)**
在纯自动化的 QPER 流程中，AI 缺乏临床先验知识。将选择权和定义权适度交还给医生，是对医学专业性的最大尊重。
### **💡 增强点一：用户主导的变量选择 (Variable Selection)**
* **业务痛点**：医院导出的原始数据往往包含上百列。如果任由 AI 自由发挥，极易把无关变量（如 Patient\_ID、病床号）纳入模型，导致多重共线性或过拟合。
* **协同价值**：医生最清楚哪些是核心指标，哪些是干扰项。
* **UX 设计建议 (穿梭框/卡片交互)**：
在 Q 层处理时，弹出“变量筛选控制台”。
**🤖 AI:** "我已解析您的数据（共 56 个变量）。为了提高准确度，请确认您本次研究关注的核心变量："
* **\[AI 智能预选\]** (AI 根据 Prompt 自动勾选最相关的 5 个变量)
* **\[展开全部列表微调\]** (用户可手动增删)
### **💡 增强点二：建立变量说明与数据字典 (Data Dictionary)**
* **业务痛点**：临床数据列名极不规范（如 grp 为 1 和 2，AI 根本不知道哪个是治疗组）。
* **协同价值 (AI-Assisted Codebook)**：
坚决避免让用户手动填写 100 列的表单。采用 **“AI 先猜，用户微调”** 模式：
1. Python DataProfiler 读取数据后，后台静默调用 LLM 猜测变量含义。
2. 弹出 **“变量数据字典确认表”** 给用户审阅：
* age \-\> AI猜: 患者年龄 \-\> 用户确认 ✅
* grp \-\> AI猜: 分组 (1, 2\) \-\> 用户补充 ✍️: 1=新药, 2=安慰剂
3. 这个经过用户确认的字典，将成为后续 Planner 和 Critic 的**黄金上下文 (Golden Context)**。
## **第二部分：架构演进决议 (为什么剥离为 Phase Q+ ?)**
虽然上述想法极佳，但在项目实施初期，如果将重度前端交互（表格编辑、状态回传）与核心后端 AI 逻辑耦合，会导致严重的**单点阻塞**。
因此，委员会决议：**将这两个人机交互检查点作为独立增强任务，归入 Phase Q+ 阶段。**
### **剥离的战略意义：**
1. **解耦后端AI与前端UI的依赖**：让后端可以先行打磨 LLM 从自然语言中提取 \[Goal, X, Y, Design\] 的核心纯逻辑（Phase Q）。
2. **确立 AI 的“智商基线 (Baseline)”**：只有先让 AI 在没有任何人类帮助的情况下硬跑，才能摸清意图识别的真实准确率；之后加上 Phase Q+ 的人工辅助，才能量化“人机协同的提升价值”。
## **第三部分：Phase Q+ 在状态机中的精确占位**
在未来的 Phase Q+ 中，这两个人机检查点将像“拦截器（Interceptor）”一样，无缝插入现有的 ExecutionStatus 状态机中。
stateDiagram-v2
\[\*\] \--\> UPLOADING: 上传文件
UPLOADING \--\> PROFILING: Python Tool C 探查
%% Phase Q+ 新增节点 1
PROFILING \--\> DICT\_EDITING: 🆕 (Phase Q+) 拦截
note right of DICT\_EDITING
展示数据字典表格
用户编辑含义/纠正类型
点击确认后放行
end note
DICT\_EDITING \--\> PENDING\_INTENT: 放行
PENDING\_INTENT \--\> PARSING\_INTENT: 用户输入自然语言
%% Phase Q+ 新增节点 2
PARSING\_INTENT \--\> VARIABLE\_CONFIRMING: 🆕 (Phase Q+) 拦截
note right of VARIABLE\_CONFIRMING
AI 已预选 X/Y 变量
展示变量穿梭框面板
用户微调纳入排除
end note
VARIABLE\_CONFIRMING \--\> PLANNING: 放行
PLANNING \--\> EXECUTING: E 层接管
* **架构向后兼容性**：在 Phase Q+ 开发完成前，系统状态将直接从 PROFILING \-\> PENDING\_INTENT，以及 PARSING\_INTENT \-\> PLANNING 自动流转，底层架构基建完全一致。
## **第四部分：研发实施路线图 (Revised Roadmap)**
基于这个决议，QPER 计划被拆解得更加平滑、颗粒度更细：
| 阶段 | 核心任务 | 性质 | 验证目标 |
| :---- | :---- | :---- | :---- |
| **Phase Q (主线)** | IntentParser (意图解析), DataProfiler (自动探查) | 后端 \+ AI 主导 | 证明 LLM 能盲猜出 Goal, X, Y 槽位。 |
| **Phase P (主线)** | Planner (决策表匹配) | 后端 \+ 规则主导 | 证明系统能基于槽位选对 100% 正确的统计工具。 |
| **Phase E (主线)** | Executor (R 服务执行) | 后端 \+ R 主导 | 证明 R 引擎能跑通、护栏能拦截。 |
| **Phase R (主线)** | Reflection (自动报错重试) | 后端 \+ AI 主导 | 证明系统具备遇到错误自动修改参数的能力。 |
| \--- | \--- | \--- | \--- |
| **Phase Q+ (增强)** | **变量字典面板、变量纳入确认卡片** | 前端体验主导 | **让 AI 从“可用”变为“好用”，注入临床背景知识。** |
| **Phase E+ (增强)** | Block-based 动态多区块渲染 | 前端体验主导 | 支持多图多表的完美富文本展示。 |
## **第五部分：给开发团队的当前实操建议**
为了在当前（无 Phase Q+ 的情况下）顺利推进核心 Phase Q 的开发，请后端团队采用以下\*\*“默认放行策略”\*\*：
1. **DataProfiler 接口契约保持不变**：
DataProfiler 依然需要输出一个标准的 DataProfile JSON。在目前的 Phase Q 阶段，这个 JSON 直接由后端传给 IntentParser；在未来的 Phase Q+ 阶段，这个 JSON 只是中间先发给前端修改，修改完再发给 IntentParser。
2. **IntentParser 的容错增强**：
因为当前没有人类帮 AI 筛选无关变量，Prompt 中必须加强指令：*“请自动忽略如 ID、姓名、病床号等明显的非分析变量。”*
### **结语**
不要试图让 AI 彻底取代临床医生的判断。最好的系统是用 AI 去做繁琐的计算，而把关键的\*\*“定义权”**和**“特征选择权”**通过优雅的 UI 还给医生。 请团队立刻将精力砸向**纯逻辑的 Q-P-E-R 主线闭环\*\*。当核心链路通畅的那一天，就是我们从容增加 Phase Q+ 人机协同面板的完美时机！

0
docs/03-业务模块/SSA-智能统计分析/06-开发记录/架构审查报告：Phase 2A 核心开发计划 .md → docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/架构审查报告：Phase 2A 核心开发计划 .md
View File

0
docs/03-业务模块/SSA-智能统计分析/06-开发记录/架构审查报告：SSA-Pro 愿景与落地策略.md → docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/架构审查报告：SSA-Pro 愿景与落地策略.md
View File

0
docs/03-业务模块/SSA-智能统计分析/06-开发记录/终极架构共识与智能化演进备忘录 (1).md → docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/终极架构共识与智能化演进备忘录 (1).md
View File

108
docs/03-业务模块/SSA-智能统计分析/06-开发记录/SSA-QPER架构开发总结-2026-02-21.md Normal file
View File

@@ -0,0 +1,108 @@
# SSA QPER 架构开发总结
> **日期：** 2026-02-21
> **范围：** Phase E+ / Q / P / R 四阶段全部完成
> **耗时：** ~93.5h（计划内），跨 2026-02-20 ~ 2026-02-21
> **结果：** QPER 智能化主线闭环，40/40 端到端测试通过
---
## 1. 完成概览
| Phase | 名称 | 核心产出 | 状态 |
|-------|------|---------|------|
| **E+** | Block-based 标准化 | 7 个 R 工具输出 `report_blocks`，前端 `DynamicReport` 动态渲染，Word 导出 | ✅ 100% |
| **Q** | Query 层（LLM 意图理解） | `QueryService` + LLM Intent 解析 + Zod 动态防幻觉 + 追问卡片 + DataProfile 增强 | ✅ 100% |
| **P** | Planner 层（决策表+模板） | `ConfigLoader` + `DecisionTableService` + `FlowTemplateService` + `PlannedTrace` + 热更新 API | ✅ 100% |
| **R** | Reflection 层（LLM 结论） | `ReflectionService` + 槽位注入 + Zod 校验 + 敏感性冲突准则 + 结论缓存 API + 前端渐入动画 | ✅ 100% |
---
## 2. 各阶段关键文件
### Phase E+ — Block-based 标准化
| 文件 | 说明 |
|------|------|
| `r-statistics-service/tools/*.R` | 7 个 R 工具全部输出 `report_blocks` |
| `frontend-v2/.../DynamicReport.tsx` | 4 种 Block 渲染（markdown/table/image/key_value） |
| `frontend-v2/.../exportBlocksToWord.ts` | Block → Word 导出 |
### Phase Q — LLM 意图理解
| 文件 | 说明 |
|------|------|
| `backend/.../services/QueryService.ts` | LLM Intent 解析 + json-repair + Zod 动态校验 + 正则 fallback |
| `backend/.../types/query.types.ts` | `ParsedQuery` / `ClarificationCard` 接口 + `createDynamicIntentSchema` |
| `backend/scripts/seed-ssa-intent-prompt.ts` | `SSA_QUERY_INTENT` Prompt 种子脚本 |
| `extraction_service/operations/data_profile.py` | `is_id_like` 非分析变量自动标记 |
| `frontend-v2/.../ClarificationCard.tsx` | 封闭式追问卡片组件 |
### Phase P — 决策表 + 流程模板
| 文件 | 说明 |
|------|------|
| `backend/.../config/ConfigLoader.ts` | 通用 JSON 加载 + Zod 校验 + 内存缓存 + 热更新 |
| `backend/.../config/decision_tables.json` | 四维匹配规则（Goal×Y×X×Design） |
| `backend/.../config/flow_templates.json` | 4+1 个标准流程模板 |
| `backend/.../config/tools_registry.json` | R 工具注册表 |
| `backend/.../services/DecisionTableService.ts` | 规则匹配引擎 |
| `backend/.../services/FlowTemplateService.ts` | 模板选择 + EPV 防护 |
| `backend/.../services/WorkflowPlannerService.ts` | 核心规划入口 + `PlannedTrace` 输出 |
| `backend/.../routes/config.routes.ts` | `POST /reload` 热更新 API |
### Phase R — LLM 论文级结论
| 文件 | 说明 |
|------|------|
| `backend/.../types/reflection.types.ts` | `ConclusionReport` / `LLMConclusionSchema` / `classifyRError` |
| `backend/.../services/ReflectionService.ts` | LLM 结论生成 + 槽位注入 + Zod 校验 + fallback |
| `backend/scripts/seed-ssa-reflection-prompt.ts` | `SSA_REFLECTION` Prompt（含敏感性冲突准则） |
| `backend/.../routes/workflow.routes.ts` | `GET /sessions/:id/conclusion` 缓存 API |
| `frontend-v2/.../ConclusionReport.tsx` | 逐 section 渐入动画 + 一键复制 + source 标识 |
| `frontend-v2/.../exportBlocksToWord.ts` | Word 导出增强（纳入 LLM 结论） |
---
## 3. 端到端测试结果
**测试脚本：** `backend/scripts/test-ssa-qper-e2e.ts`
**运行方式：** `npx tsx scripts/test-ssa-qper-e2e.ts`
| 测试项 | 结果 |
|--------|------|
| 登录认证 | ✅ JWT Token 获取 |
| 创建会话 + 上传 CSV | ✅ 21 列 / 311 行 |
| 数据画像（Python） | ✅ 行列数正确 |
| **Q 层** — LLM Intent | ✅ Goal=comparison, Confidence=0.95, 变量名准确 |
| **P 层** — Plan | ✅ 3 步流程, PlannedTrace 完整 |
| **E 层** — R 引擎执行 | ✅ 3/3 步骤成功, 10 个 ReportBlocks |
| **R 层** — LLM 结论 | ✅ source=llm, 6 要素完整（摘要/发现/统计/方法/局限/建议） |
| 结论 API 缓存 | ✅ 14ms 缓存命中 |
| 第二条链路（相关分析） | ✅ 2/2 步骤成功, LLM 结论正确 |
| 错误分类验证 | ✅ 异常变量 confidence=0.4, 不崩溃 |
| **总计** | **40/40 通过, 0 失败** |
---
## 4. 架构亮点
1. **四层降级体系** — 每层都有 fallback：Q→正则, P→硬编码, R→规则引擎, 前端→旧组件
2. **LLM 三层防御** — `jsonrepair` → `JSON.parse` → `Zod Schema`，Q 层和 R 层共用范式
3. **统计量槽位注入** — LLM 被剥夺生成数值的权限，所有 P 值/效应量来自 R 引擎实际输出
4. **配置化驱动** — 决策表/流程模板/工具注册表均为 JSON，方法学团队可配置，`POST /reload` 热更新
5. **PlannedTrace 审计** — P 层只生成策略（"如果…则…"），E 层 R 引擎执行事实，R 层合并两者生成方法学说明
---
## 5. 下一步
| 阶段 | 内容 | 预计工时 |
|------|------|---------|
| **Phase Deploy** | 补齐 4 个原子 R 工具（ANOVA/Fisher/Wilcoxon/线性回归）+ 复合工具 ST_BASELINE_TABLE + 部署 | 37h |
| **Phase Q+** | 变量数据字典 + 变量选择确认面板（人机协同增强） | 20h |
---
**文档维护者：** SSA 架构团队
**关联文档：** `04-开发计划/10-QPER架构开发计划-智能化主线.md`