TREQS：医疗电子病历上的自然语言转SQL查询系统

当医生不再需要记住数据库密码

凌晨三点，某三甲医院ICU值班的住院医师李医生需要查询一个复杂的数据问题：「过去30天内，使用有创机械通气且ICU住院时长超过7天的患者中，平均动脉压低于65 mmHg的次数占总监测次数的比例是多少？」

在没有TREQS之前，李医生需要做三件事：理解数据库表结构、写出正确的SQL语句、反复调试直到结果正确。而现在，他只需要把这段话直接输入系统，系统就能生成对应的SQL查询语句，直接返回结果。

这就是TREQS（Text-to-SQL Generation for Question Answering on Electronic Medical Records）解决的核心问题——让医疗专业人员无需掌握SQL技能，就能直接用自然语言查询电子病历数据库。

为什么这个问题值得用一篇WWW'20论文来解决

电子病历（EMR）数据是现代医疗的核心资产。病历记录了患者的诊断、用药、检查结果、生命体征等关键信息，但这些数据通常以结构化的关系型数据库形式存储，访问门槛很高。在实际医疗场景中，医生、护士、医院管理者经常需要临时查询数据来支持临床决策或研究分析，但他们中的大多数人并不具备SQL编程能力。

传统的解决方案有两条路：要么培养懂医学又懂数据库的复合型人才，要么让IT部门开发固定报表。但前者培养周期长、成本高，后者无法满足灵活多变的查询需求。学术界早就看到了Text-to-SQL这个方向，在通用领域（WikiSQL、Spider等数据集）已有大量研究成果，但医疗领域有自己的独特性——医疗EMR数据库有复杂的表结构、多表关联查询需求、包含大量专业术语和缩写，而且查询结果直接关系到临床决策的准确性，对精确度的要求远高于通用场景。

TREQS由弗吉尼亚理工大学的王平（Tian Shi）团队提出，发表在2020年万维网会议（WWW'20）上，开创性地将Text-to-SQL技术引入医疗EMR领域，并同步开源了MIMICSQL数据集——这是当时医疗领域规模最大的Text-to-SQL标注数据集。

核心原理：如何把「人话」翻译成SQL

TREQS的技术路线建立在Seq2Seq（序列到序列）深度学习模型之上，核心架构包含以下几个关键组件：

编码器-解码器架构。编码器部分采用双向LSTM（Long Short-Term Memory）网络，将用户的自然语言问题编码为密集的语义向量表示。解码器则是一个带有注意力机制的LSTM网络，每一步生成一个SQL关键词（SELECT、WHERE、聚合函数等）或列名，最终组合成完整的SQL语句。

基于LeafNATS框架实现。TREQS构建在LeafNATS（Neural Architecture Training System）之上，这是一个由该团队开发的PyTorch深度学习训练框架。LeafNATS提供了标准化的数据加载、模型构建、训练调度和评估流程，TREQS在此基础上实现了自定义的EMR-specialized编码器和解码器模块。

复制机制（Copy Mechanism）。这是TREQS处理医疗专业术语的关键创新。EMR数据库的列名（如hadm_id、icustay_id、vent_settings）和自然语言问题中的词汇表存在显著差异，解码器需要能够「复制」输入中的专业术语直接作为SQL输出的一部分，而不是从固定词表中生成。

MIMICSQL数据集。这是该工作的另一大贡献。数据集基于MIMIC-III（Medical Information Mart for Intensive Care III）真实ICU数据集构建，包含两个版本：模板生成版（mimicsql_template，通过预定义模板自动生成大量SQL-问题对）和人工标注版（mimicsql_natural，由医疗专业人员撰写自然语言问题），共包含数万个训练样本，覆盖单表查询、多表JOIN查询、聚合查询等多种SQL类型。

技术细节：架构与实现

从代码结构来看，TREQS的核心模块组织如下：

main.py作为入口文件，负责命令行参数解析和任务调度（train/validate/test/evaluate），数据默认从mimicsql_data/mimicsql_natural目录加载。model.py定义了modelABS类，继承自modelSeq2SeqBase，实现了自定义的调度器（learning rate scheduler）和批处理逻辑，核心依赖seq2sql/model_seq2seq_base.py。

LeafNATS/目录是整个训练框架的核心，其中modules/包含各种神经网络组件：embedding层（词嵌入）、encoder（编码器）、encoder2decoder（编码器到解码器的桥接层）、attention机制（注意力层）。data/seq2sql/目录提供了针对Text-to-SQL任务的数据处理工具，包括batch处理、vocabulary构建、OOV（未登录词）处理等。

从依赖来看，TREQS基于Python 3.6+和PyTorch构建，CUDA环境是GPU训练的必备条件。模型训练的主要超参数包括：batch_size默认16，epoch默认20，使用CUDA设备加速。模型输出的是SQL语句字符串，之后由评估脚本与标准答案比对计算精确匹配率和执行准确率。

局限性：不回避的问题

尽管TREQS在医疗Text-to-SQL领域具有开创性意义，但它也存在明显的局限性需要正视。

精确度有限。作为2020年的研究工作，TREQS的模型容量和训练策略相比当前的大语言模型（LLM）有较大差距。在复杂多表JOIN查询和嵌套子查询上的表现仍有提升空间。

无生产级部署支持。代码库面向学术研究场景，没有提供Docker容器化部署方案、没有Web界面、没有API服务接口，直接在生产环境使用需要大量二次开发。

依赖MIMIC数据集。模型和数据集强绑定于MIMIC-III数据库schema，如果要迁移到其他医院的EMR系统（使用不同的数据库表结构），需要重新标注训练数据或进行迁移学习。

缺乏维护更新。代码库自2020年后没有持续维护，某些依赖包版本可能与当前Python/PyTorch生态存在兼容性问题。

行业意义：从学术论文到工程实践的桥梁

TREQS的意义不仅在于论文本身，更在于它构建的整个研究生态。MIMICSQL数据集的开源，为后续研究者提供了宝贵的医疗Text-to-SQL benchmark。LeafNATS框架的模块化设计，使得研究者和工程师可以在此基础上快速定制新的模型架构。

这个项目也反映了NLP+Healthcare交叉领域的趋势：随着LLM能力的爆发，将通用大模型的自然语言理解能力与医疗领域知识结合，正在成为医疗信息化智能化升级的重要方向。TREQS作为这一趋势的早期探索，为后续医疗NLP应用奠定了方法论基础。

对于有意在该方向深耕的开发者，建议的上手路径是：首先运行评估脚本理解模型输出格式，然后基于MIMICSQL数据集训练自定义模型，最后结合FastAPI或Flask构建推理服务。