DuckDB实战:从数据库到 DataAgent：MIMIC 工作流完整链路

前面四篇，我们拆开了每一步：MIMIC 数据怎么拿、31 个模板怎么设计、模板路由怎么做到 96.8%、OMOP 本体怎么补上概念查询。

这篇把它们串起来——从原始数据到能回答临床问题的工作流，一条完整链路。

● ● ●

完整链路长什么样

临床问题
  → 本体层：问题翻译成概念（Sepsis → 135 个后代码）
  → 路由层：LLM 从 31 模板选 1（或选本体展开路线）
  → 执行层：确定性 SQL 执行
  → 校验层：golden 快照对比
  → 答案 + 审计日志

DataAgent 五层架构：本体 → 路由 → 执行 → 校验 → 审计

这五层就是我们团队在 NPP（一个桌面级数据分析平台）里实现的 DataAgent 架构。数据不出院、结果可追溯、每步可审计。

● ● ●

每一层解决什么问题

本体层（第四篇）：LLM 的短板是编码知识。它不知道 A40.0 也是脓毒症。本体层把「问题 → 概念 → 编码展开」变成确定性过程，LLM 只做概念翻译，不做编码猜测。

路由层（第二、三篇）：直接写 SQL 的准确率 80.6%，选模板的准确率 96.8%。路由层把「写 SQL」降维成「选模板」，LLM 不碰 SQL 语法，只做 31 选 1 的选择题。

执行层：模板 SQL 是工程验证过的，路由选对则执行必对。这层是确定性的，没有模型参与，只有 SQL 引擎。

校验层：golden 快照（行数+列数）兜底。路由选错、参数填错，校验层能拦住。

审计：每次查询留下完整日志（什么问题、选了哪个模板、填了什么参数、结果多少行）。医疗场景审计是刚需，不是可选项。

● ● ●

为什么跑在本地

这套链路最容易被忽视的优势是部署形态：全本地。

• 数据：MIMIC catalog 单文件（约 300 MB），本地磁盘
• 模型：Qwen3.8 27B，本地 GPU 服务器（4×4090），4bit 量化
• 引擎：DuckDB 嵌入式，无服务无端口

对比云端方案：数据不出院（隐私合规）、不按 token 计费（成本固定）、断网可用（不依赖外部 API）。MotherDuck 的博客说本地跑 450 道题电费不到 0.5 美元，我们实测方向一致。说实话，本地推理的成本优势在医疗场景是决定性的。

● ● ●

实测数据回顾

端到端 90.3% 看着比路由 96.8% 低，但注意：路由选对的 28 题执行层 100% 通过。剩下的差距全在路由环节，而路由的失败是「两个模板语义重叠」这种可修的目录问题，不是模型能力天花板。

● ● ●

这套东西能复用到别的数据吗

能。模板路由的思路不依赖 MIMIC：

1. 01
   换数据库：catalog 换成别的库，模板重写，golden 重生成
2. 02
   换领域：临床问题换成金融/电商问题，概念层换成对应本体
3. 03
   换模型：路由模型可以升级，模板资产不变

我们团队在 DuckDB 生态里做过类似的通用模板（ETL、跨库 join、JSON 处理），同样的「选模板不做自由发挥」思路在非医疗数据上也成立。

● ● ●

局限和诚实声明

说清楚这套方案的边界：

• 31 个模板覆盖的是高频问题
  ，不是全部问题。开放式长尾问题仍需要自由 SQL 兜底
• 模板维护有成本
  ：schema 变更、新需求都要改模板、重跑 golden
• 本体收益不均匀
  ：编码集中的疾病（AKI、T2DM）增益为 0，本体层的价值在长尾分散编码
• 96.8% 是评测集数字
  ，不是生产承诺。评测 31 题覆盖常见临床问题，生产环境需要持续补充 golden

● ● ●

参考来源

1. 01
   本系列第三篇《复现 MotherDuck：Qwen3.8 27B 在 MIMIC 上做到 96.8%》（评测闭环详情）
2. 02
   本系列第二篇《31 个模板，把 MIMIC 变成可查询资产》（模板设计）
3. 03
   本系列第四篇《OMOP 本体：字面查询漏掉 57% 的脓毒症患者》（本体展开）
4. 04
   NPP 平台——DataAgent 架构落地载体（本文所属团队产品，详情可私信交流）
5. 05
   MotherDuck 博客《Agentic SQL for Free with Qwen3.8 27B and DuckDB》：https://motherduck.com/blog/Agentic-SQL-for-Free-with-Qwen3.8-27B-and-DuckDB/