临床AutoML流水线如何嵌入大模型：防泄漏、可复现与报告草拟

1. 临床研究里那套自动化机器学习，卡点到底在哪

临床科研圈这两年对自动化机器学习（AutoML）的态度挺分裂：一边是各种培训班把它讲成"零代码发文章"的捷径，另一边是真正跑过数据的人摇头——配置写了一下午，跑出来的模型 AUC 0.92，一换验证集掉到 0.63。这个落差不是工具不行，而是临床数据本身的结构性特征和通用 AutoML 的默认假设之间有一道沟。大语言模型（LLM）最近的介入，恰恰是把这道沟填上了一部分，但填的方式和很多人想象的不一样。

先说清楚这篇东西的定位：它讲的不是"用大模型帮你写论文"，而是把大语言模型嵌进临床研究的自动化机器学习流水线里，让它承担语义翻译、配置生成、错误诊断和报告草拟这四类工作，把原来需要数据科学家和临床医生来回拉扯好几轮的环节压缩掉。适合谁来读？一类是有临床问题但代码基础薄弱的医生和研究生，另一类是懂建模但对临床数据语义不熟的数据分析人员。如果你只是想知道"要不要上大模型"，我的判断是：在结构化表格数据上，它不会让你的模型更准，但它能让你的流程少走弯路、少踩泄漏坑、少写重复文档。

1.1 临床数据的三道硬坎：小样本、高缺失、强不平衡

通用 AutoML 框架大多在公开竞赛数据集上打磨，那些数据动辄几万到几十万行、缺失很少、类别相对均衡。临床回顾性研究的数据完全不是这个画风。

第一道坎是样本量。单中心回顾性队列常见规模是几百例到两千例，而关心的不良结局（术后并发症、院内死亡、再入院）发生率往往只有 5% 到 15%。这意味着阳性事件数可能只有几十例。按预测模型建模的经验法则，每个候选变量至少需要 10 个事件（业内常说的 EPV 原则），事件数 80 的话，能进模型的自变量最多 8 个。但临床数据库导出来往往是三百多列。这个矛盾不解决，后面所有调参都是在拟合噪声。

第二道坎是缺失，而且是非随机缺失。实验室检查不是人人都查，病情重的患者查得全、查得勤，病情轻的缺一大堆。缺失率 30% 到 60% 的变量在临床表里非常普遍。更麻烦的是，缺失本身携带信息——"有没有查某项指标"往往和疾病严重程度相关。直接删行会引入选择偏倚，直接填均值会把信号抹平。

第三道坎是数据类型混杂且语义密集。一张表里同时有连续变量（年龄、BMI、检验值）、无序分类（血型、病理类型）、有序分类（NYHA 心功能分级、ASA 分级）、自由文本（手术记录、病程描述）、时间戳（入院、手术、出院）、以及各种派生变量。通用框架的类型推断经常出错，把用 1/2/3 编码的分级变量当连续变量处理，模型结果就悄悄变形了。

还有一道容易被忽略的坎：数据泄漏。同一个患者多次入院产生多行记录，随机切分会让同一患者同时出现在训练集和验证集；"出院带药""住院天数""是否转 ICU"这类变量在预测入院时刻的结局时是事后信息。这类问题通用工具不会提醒你，因为它不懂临床时间线。

1.2 传统 AutoML 的真实使用成本，比宣传的高不少

我用过几个主流的表格 AutoML 框架，客观说它们把"搜索模型+超参"这件事做得很好，但整条流水线里搜索只占一小段。

真正耗时间的是搜索之前和之后。搜索之前要做的：把数据字典翻译成变量角色（哪些是 ID、哪些是时间列、哪些是结局、哪些绝对不能进模型）、确定分析单元（按患者还是按住院次）、设计交叉验证策略（分层？分组？时间序列切分？）、决定缺失处理策略、决定类别变量编码方式。这些没有一项是通用框架能自动做对的，因为它们依赖临床语义。

搜索之后要做的：看特征重要性是否符合临床常识（如果"是否输血"排第一，而结局是术后感染，得怀疑因果方向）、做校准评估（AUC 高但校准差的模型在临床上没法用来定阈值）、写方法学段落和结果表格、准备补充材料。这些工作量加起来，往往比搜索本身多三到五倍。

所以很多临床团队的真实困境不是"找不到好模型"，而是流程太长、沟通成本太高、返工太多。一个研究问题从提出到跑出可信结果，中间要经历"医生描述需求—分析人员理解偏差—配置写错—结果异常—回头再问"的循环，两三周就过去了。

1.3 大语言模型补上的那块拼图，位置很具体

大语言模型在其中的价值，不是"帮你算模型"，而是把自然语言的临床意图，翻译成机器可执行的、带约束的配置。

具体来说它擅长四件事。第一，把"我想预测这类患者术后 30 天内有没有严重并发症"这种口语化描述，转成结构化的任务定义：任务类型是二分类、分析单元是患者、结局窗口是术后 30 天、正类是 Clavien-Dindo III 级及以上。第二，看着数据字典给每个变量打角色标签，包括识别高泄漏风险变量。第三，框架报错时把堆栈信息翻译成人话，并给出具体的修改建议。第四，把运行结果整理成符合临床预测模型报告规范的方法与结果段落草稿。

它不擅长的事同样明确：数值计算不可靠、会编造不存在的变量名、对样本量和事件数的判断需要人来把关、给出的统计建议可能过度自信。所以正确的用法是把它放在"配置生成器"和"解释器"的位置，计算和判定仍然交给确定性代码和统计规则。这个边界划清楚了，整个方案就稳了。

2. 整体设计：让大模型当翻译官，让 AutoML 当执行者

我最终落地的架构是四层，从下往上分别是数据层、约束层、执行层、审计层，大语言模型横向穿在约束层和审计层之间。这个分层不是为了好看，是因为每一层出错的后果不同，必须能单独定位。数据层错了是数据问题，约束层错了是方案问题，执行层错了是配置问题，审计层错了是复现问题。混在一起排查会非常痛苦。

2.1 四层架构与各自的职责边界

数据层只管一件事：把原始导出表变成一份干净的分析表加一份数据字典。清洗规则（单位统一、日期解析、重复记录合并）由人定，代码执行，大模型不参与具体数值处理。

约束层是整个方案的核心。它接收三个输入：结构化的任务定义、数据字典、样本量与事件数的统计摘要，输出一份可行性方案。这一层里，大语言模型负责语义部分（变量角色、泄漏识别、指标优先级），确定性代码负责算术部分（事件数计算、EPV 判定、交叉验证折数下限）。两者结论冲突时，以代码为准。

执行层拿着约束层输出的配置文件去调 AutoML 框架。这一层完全确定性，随机种子固定，配置落盘，日志完整。

审计层做三件事：记录每次运行的配置快照与代码版本、独立复核关键指标、生成报告草稿。大语言模型在这里负责把技术指标翻译成临床可读的表述，但最终数字必须来自日志，不允许模型自己生成。

这个划分解决了一个很实际的问题：当结果看起来太好时，你能快速定位是数据泄漏（数据层或约束层）、是过拟合（执行层）、还是复核漏了（审计层）。

2.2 为什么不让大模型直接读数据、直接给结果

有人会问，既然模型这么强，为什么不把 CSV 丢给它，让它直接分析？三个理由，任何一个都足够。

第一是数值可靠性。语言模型做算术和统计推断的稳定性远达不到研究发表的要求，它对分位数的估计、对相关系数的判断经常是"看起来合理"而非"实际正确"。样本量 847、事件数 93 这种数字，让它心算出来的比例经常是错的。

第二是可复现性。研究必须能被别人重复。同一份数据、同一个提示词，两次调用可能给出不同建议，这在一个需要写进方法学段落、需要应对审稿人质询的场景里是不能接受的。所有关键决策必须是代码可重放的。

第三是数据合规。临床原始数据包含大量可识别信息，把整表贴进外部服务是绝对不能做的。合理做法是只把脱敏后的数据字典和统计摘要（变量名、类型、缺失率、取值范围、事件数）送进模型，原始行级数据留在本地。

所以我的原则很朴素：模型看"字典"，不看"数据"；模型出"建议"，代码做"决定"；模型写"草稿"，人做"终审"。

2.3 一条可复现的流水线长什么样

从输入到产出，我现在的流程是六步，每步都有明确的产物文件：

1. 需求卡片：一份 Markdown，写清研究问题、目标人群、结局定义、预测时间窗、临床用途（筛查/预警/分层）。
2. 数据字典：CSV 或 JSON，每个变量一行，含名称、中文标签、类型、取值域、缺失率、角色标记。
3. 预处理计划：JSON，规定缺失处理、编码方式、异常值处理、分组键、切分策略。
4. 搜索配置：JSON，规定候选模型族、搜索空间、评价指标、交叉验证方案、时间预算。
5. 运行产物：日志、指标表、模型文件、特征重要性、校准曲线数据。
6. 报告草稿：方法段、结果段、表格、需要人工确认的存疑点清单。

六份产物串起来，就是一条从"一句话"到"可交付结果"的链路。后面第 3 章和第 4 章会把每个环节拆开讲，包括提示词怎么写、参数怎么算、日志怎么看。

3. 核心环节拆解：从一句话需求到可交付模型

这一章是全篇最实在的部分。我会逐个环节讲清楚做什么、为什么这么做、以及大模型在这里具体承担什么。所有涉及参数的，我都会给出计算过程，你能直接照着套。

3.1 需求结构化：把临床问题翻译成建模任务

临床医生给出的需求通常长这样："我们想看看这些做了手术的病人，哪些人容易在住院期间出问题。"这句话对建模来说信息量几乎为零——"出问题"是什么结局？"住院期间"是入院到出院还是术后到出院？"哪些人"是按人还是按住院次？

我用的做法是让大模型做一次结构化追问与填充，输出固定格式的 JSON。提示词大致是这样组织的（这是骨架，实际用的时候再补领域约束）：

你是一名临床预测模型的方法学顾问。 下面是一段研究需求描述和数据字典摘要。 请输出严格的 JSON，不要输出任何解释性文字。 字段定义： - task_type: binary_classification / multiclass / regression / survival - unit_of_analysis: patient / admission / encounter - outcome_name: 结局变量在字典中的确切列名 - outcome_window: 预测时间窗，写明起点和终点 - positive_class: 正类的明确定义 - index_time: 预测起点时刻（必须是可得信息的最晚时间点） - forbidden_variables: 在该时间点之后才产生的变量列名列表 - metric_priority: 主指标与辅助指标，按优先级排序 - uncertainty: 你无法从给定信息确定的字段，用问句形式列出

关键在那个uncertainty字段。我强制模型把拿不准的东西列出来，而不是硬猜一个填上。实测下来，这个字段能捞出 80% 的潜在歧义点，比事后返工省太多。

index_time这个字段是最容易出错也是最重要的。举个例子：预测术后并发症，index_time 必须是"手术结束时刻"，那么术中出血量可以用，术后第一天的白细胞不能用。这个时间线一旦定错，整个模型的临床价值就归零了。模型不一定能自己推断出正确的时间线，但它能帮你把这个问题显式地摆到桌面上，逼着研究者和临床医生确认。

还有一个细节：正类定义必须写死阈值。比如"急性肾损伤"要明确是 KDIGO 哪一期，"再入院"要明确是 30 天内全因还是计划外。这类定义模糊会导致标注不一致，最后模型学到的是一堆噪声的平均值。

3.2 数据字典与变量角色标注：泄漏识别的主战场

数据字典是整条流水线里性价比最高的一份材料。花半天时间把字典做扎实，后面能省好几天。我的字典至少包含这几列：变量名、中文标签、数据类型（连续/无序分类/有序分类/日期/文本）、单位、取值范围或Top取值、缺失率、角色、备注。

角色字段是我自己加的，取值包括：id、time、outcome、predictor、forbidden、group_key。其中forbidden（禁用变量）是最关键的。

我把禁用变量分四类，让大模型对照字典逐条判断并给出理由：

这里有个经验：大模型对"事后信息"的识别准确率相当高，因为时间线逻辑是语言层面的推理；但对"与结局互为因果"的判断容易过度激进，会把一些其实有预测价值的变量也标成禁用。我的处理方式是让它给出"禁用理由 + 风险等级（高/中/低）"，中低风险的我自己再拍板。比如"是否使用血管活性药物"，它可能标成高风险的因果倒置，但在某些场景下这确实是早期预警信号，需要临床判断。

分组键也不能漏。同一患者多次入院的数据，必须把患者 ID 标成 group_key，否则交叉验证会泄漏。这个坑我见过太多次，AUC 虚高 0.1 以上很常见，而且很难自查出来——你会觉得模型就是很强。

3.3 预处理策略生成与防泄漏校验

预处理最核心的原则只有一条：所有依赖数据的拟合步骤，必须放在交叉验证的每一折内部完成。插补的中位数、标准化的均值方差、类别编码的映射表、甚至特征筛选的入选名单，全都要在折内算。只要有一个环节在外层算了，指标就是乐观偏差。

具体到临床数据，我的默认策略是这样：

缺失处理分三档。缺失率低于 5% 的变量，连续型用中位数插补，加一个缺失指示变量；分类型把缺失单独作为一个类别。缺失率 5% 到 40% 的，连续型用中位数或模型插补，同样加指示变量，并且要在报告里写清楚。缺失率超过 40% 的，先问临床意义——如果这个指标本身就是"病情重才查"，那缺失模式有信息量，可以考虑保留并依赖指示变量；如果纯粹是记录不全，直接剔除更稳妥。

注意：不要盲目上多重插补。多重插补在小样本、高缺失、模型还要做大量超参搜索的场景下，会显著拉长运行时间，而且插补模型本身的不确定性很难传导到最终的置信区间里。除非你的研究重点就是缺失机制，否则中位数加指示变量在树模型上表现往往够用。

编码处理上，无序分类用目标无关的编码（独热或基于频次的编码），有序分类保留顺序信息用序数编码，低频类别（占比低于 1% 或样本数少于 10）合并成"其他"。

标准化只对线性模型和神经网络有意义，树模型不需要。这一点经常被搞混，导致很多人在树模型上做了一堆标准化，白费功夫。

分组与切分是防泄漏的最后一道闸。默认用按 group_key 分组的分层 K 折。分层是为了保证每折的阳性事件比例接近总体，分组是为了防止同一患者跨折。

折数怎么定？我的规则是：每折的阳性事件数不少于 20 例。事件数 93 的话，5 折每折约 18.6 例，勉强可以；事件数只有 45 的话，5 折每折 9 例，方差会大到没法看，这时候应该降到 3 折，或者干脆改用重复分层抽样加 bootstrap 评估。这个计算很简单，但很多人生搬硬套"标准 5 折或 10 折"，在小事件数场景下直接把自己坑了。

3.4 搜索空间与评价指标的配置逻辑

这一节讲参数怎么算。很多人配 AutoML 就是随手填个时间预算，结果要么没搜完要么过拟合。我给几个有依据的做法。

候选变量数上限按 EPV 算。事件数除以 10 就是候选变量数上限（保守一点可以除 15）。事件数 93，上限 9 个变量。候选变量有 200 个怎么办？两条路：一是先做降维或临床先验筛选，二是用正则化强的模型并接受它自动做选择。我倾向第一条——让临床医生从 200 个变量里挑出 15 到 25 个"必须有"的，这是最便宜也最有效的降维。

搜索预算按模型族数量乘每族最小评估次数估。假设 4 个模型族、每族至少试 25 组配置、5 折交叉验证，那就是 500 次拟合。单次拟合在千行级数据上约 2 到 5 秒，总共 20 到 40 分钟。按这个倒推时间预算，别拍脑袋填个"3 小时"然后发现只搜了 20 组。

主指标的选择取决于结局分布。阳性率高于 20% 时，ROC-AUC 和 PR-AUC 都行；阳性率低于 10% 时，我优先看 PR-AUC，因为 ROC-AUC 在不平衡数据上会给出虚高的乐观印象。同时必须报校准指标——Brier 分数和校准曲线。临床上要用模型定阈值，AUC 高但校准差的模型是不能用的。

阈值选择不要用默认的 0.5。两个思路：约登指数（最大化敏感度+特异度-1）适合没有明确临床偏好的场景；临床上更常用的是"在可接受的最低敏感度下最大化特异度"，比如筛查场景要求敏感度不低于 0.90，那就固定这个约束去找阈值。这个约束值需要临床医生给，大模型可以帮你把这句话翻译成代码逻辑，但值不能它来定。

嵌套交叉验证要不要做？如果只是内部验证加报告，外层 5 折、内层 3 折的嵌套交叉验证能给出偏差更小的性能估计，代价是计算量乘 3。小样本场景我建议做，因为乐观偏差在小样本上是系统性的，不是随机噪声。

3.5 结果解释与报告草稿：让模型写，让人签字

模型跑完，产物里我最先看三样：交叉验证的指标分布（不是均值，是每一折的值）、特征重要性排序、校准曲线。这三样能过滤掉大部分问题模型。

特征重要性的解读有个技巧：先看有没有禁用变量漏进来。如果"是否输血"排在第一位而结局是术后感染，要么是泄漏（输血发生在感染之后），要么是真实的因果链（感染导致输血）——后者在预测场景下依然不该用，因为预测时点拿不到。这个判断必须人工做，但可以让大模型帮你列出"排序前十里哪些存在时间线疑问"。

报告草稿的生成，我让它按固定模板输出：研究人群与纳排标准、结局定义、候选变量与预处理、模型训练与验证策略、性能指标表、校准与临床实用性、局限性。每个段落都要求它从日志文件里取数，不许自己编。实现方式是在提示词里附上结构化的指标 JSON，并要求它只引用 JSON 中出现的数字。

这样做的效果是：草稿完成度能到七成，剩下三成主要是局限性讨论和临床意义阐述，这部分必须人来写，因为涉及对研究定位的判断。注意，任何情况下都不能让模型直接生成参考文献，它编造文献的能力远超你的想象，而且编得很像真的。

4. 实操全过程：一个完整案例走通

为了让上面的东西能落地，我把一个模拟项目的完整流程走一遍。数据是虚构的，结构参考常见的单中心回顾性队列：约 1100 例手术患者，结局是术后 30 天内严重并发症，阳性 96 例，候选变量 180 个。

4.1 环境与目录约定

目录结构我固定成下面这样，几年下来觉得最省心：

project/ ├── 00_raw/ # 原始导出，只读，永不修改 ├── 01_dict/ # 数据字典、变量角色表 ├── 02_plan/ # 需求卡片、预处理计划、搜索配置（JSON） ├── 03_run/ # 每次运行一个时间戳子目录 │ └── 20250101_1430/ │ ├── config_snapshot.json │ ├── metrics.json │ ├── log.txt │ └── model.pkl ├── 04_report/ # 报告草稿与图表 └── 05_audit/ # 复核记录、人工确认清单

原始数据只读这一条是铁律。我见过太多次"在原始表上直接改了编码，后来忘了改了什么"的事故，回头根本没法复现。

运行环境用固定版本的虚拟环境，把所有依赖版本导出成锁文件。这一步看着繁琐，但半年后你要重跑一遍补充分析时，会感谢当时的自己。

4.2 提示词模板与输出约束

需求结构化的提示词，前面 3.1 已经给了骨架，这里补充两个实操细节。

第一，输出必须是可解析的 JSON。我会在提示词里给一个完整的空模板，要求"只填充值，不要增删字段"。同时在调用侧做 schema 校验，解析失败就重试一次，再失败就人工介入。不要指望模型的输出永远规整，一定要有兜底。

第二，所有涉及数字的字段，要求它引用来源。比如缺失率字段，要求写成{"value": 0.37, "source": "dict_row_42"}。这样一旦发现数字不对，能立刻定位是字典给错了还是模型读错了。

变量角色标注的提示词，我通常一次性把字典的前 60 行和完整列名列表都给它，让它先输出一份角色表，然后我用代码做交叉校验：被标成 outcome 的必须只有一列；被标成 group_key 的必须是 ID 类；被标成 forbidden 的必须给出理由字符串。校验不过的直接打回。

实测下来，一个 180 变量的字典，模型初版标注的准确率大概在八成左右，主要的错误集中在有序分类被标成连续、以及少数因果倒置判断过度。人工过一遍大概二十分钟，比从零开始标快得多。

4.3 执行脚本与运行记录

执行层我写成一个薄封装，核心逻辑是：读配置、建 Pipeline、跑搜索、落盘。伪代码大致如下，重点看 Pipeline 的组织方式：

import json, time, hashlib from pathlib import Path # 下面两个模块按你的实际技术栈替换 from my_pipeline import build_preprocessor, build_search_space from my_automl import TabularSearch cfg = json.loads(Path("02_plan/search_config.json").read_text()) run_dir = Path("03_run") / time.strftime("%Y%m%d_%H%M") run_dir.mkdir(parents=True) # 配置快照：把配置和它的哈希一起存下来 cfg_text = json.dumps(cfg, sort_keys=True, ensure_ascii=False) (run_dir / "config_snapshot.json").write_text(cfg_text, encoding="utf-8") cfg_hash = hashlib.sha256(cfg_text.encode()).hexdigest()[:12] pre = build_preprocessor( numeric_impute=cfg["preprocess"]["numeric_impute"], # median add_missing_indicator=cfg["preprocess"]["add_indicator"], categorical_min_freq=cfg["preprocess"]["min_freq"], # 0.01 ordinal_cols=cfg["preprocess"]["ordinal_cols"], ) search = TabularSearch( models=cfg["search"]["model_families"], metric=cfg["search"]["primary_metric"], # 如 pr_auc cv_folds=cfg["search"]["cv_folds"], # 由事件数推算 group_key=cfg["split"]["group_key"], # 患者ID stratify_col=cfg["split"]["stratify_col"], # 结局列 time_budget_sec=cfg["search"]["time_budget_sec"], random_state=20250101, ) result = search.fit(cfg["data"]["path"], target=cfg["data"]["target"], preprocessor=pre) result.dump(run_dir)

几个必须写进脚本的细节。随机种子固定到每一个环节，包括搜索、折划分、模型初始化。分组键必须真的传进去，很多框架支持但这个参数经常被忘。每次运行落一个配置快照加哈希，这样报告里能写清"结果对应哪一次运行"。

运行日志我要求至少记录：开始结束时间、每折的样本数与事件数、每折指标、最终选中配置、特征数量、警告信息。日志不是给机器看的，是给你三个月后回看时看的。

4.4 结果复核：三个必看的数字

跑完之后，我不看排行榜第一的模型，先看三个数字。

第一个，交叉验证每折指标的极差。5 折 AUC 是 0.78、0.81、0.79、0.62、0.80，均值 0.76 看着还行，但那一折 0.62 说明模型在某类人群上崩了。这时候要去看那一折的阳性事件数是不是特别少，或者某个关键变量的分布是不是有偏移。极差超过 0.15 我基本不会接受这个结果。

第二个，校准斜率。理想值是 1，明显小于 1 说明模型过度自信（预测的高风险没有实际那么高），大于 1 说明欠自信。这个数字比 AUC 更能反映模型能不能用于临床决策。小样本场景下校准斜率普遍偏小，如果没有做任何修正，就要在局限性里写清楚。

第三个，从训练集表现到验证集表现的下降幅度。训练 AUC 0.95、交叉验证 0.76，这个 0.19 的差距就是过拟合的量。差距大要么是变量太多，要么是模型太复杂，要么是有隐性泄漏。我的经验是差距控制在 0.10 以内比较健康。

这三个数字看完，再回头决定要不要调整搜索空间。多数情况下我会做一次"减变量"的对照实验：把候选变量从 180 砍到临床先验的 20 个左右，再跑一遍。如果性能没掉，说明原来那 180 个变量里大部分是噪声，用精简版本更可信，也更好解释。这个对照实验花不了多少时间，但能显著提升结果的说服力。

5. 常见问题与排查技巧实录

这一章是我踩过的坑的集合。分成提示词层面、数据层面、流程层面三块，最后给一张速查表。

5.1 提示词层面的三个典型故障

输出格式漂移。同一个提示词连跑十次，可能有两次输出的 JSON 少个字段或者多一层嵌套。解决办法不是反复改提示词措辞，而是加代码侧的 schema 校验和自动重试，同时把 temperature 调到很低。另外，字段越少越稳，别在一个提示词里让它同时做五件事。

变量名幻觉。让模型基于数据字典给建议时，它可能引用一个字典里根本不存在的变量名，或者把两个相似的变量名混起来。防御方式很直接：它输出的每个变量名都用代码去字典里查一遍，查不到的打回。这个校验必须做，不能靠肉眼。

建议过度自信。它会用很确定的语气告诉你"应该用某某方法处理缺失"，即使这个建议在你的数据规模下并不合适。我的应对是在提示词里明确要求"对每条建议标注适用前提和风险"，并且约定"当事件数少于 100 时，任何涉及复杂模型的建议必须同时给出简化替代方案"。用规则约束它的表达习惯，比事后逐条甄别省力。

5.2 数据层面最容易翻车的四个点

类型推断错误。用 1/2/3/4 编码的心功能分级被当连续变量，模型会假设 1 到 2 的距离等于 3 到 4。这类错误在自动流程里非常隐蔽，因为不报错。防御方式是数据字典里显式写类型，预处理按字典走，不依赖自动推断。

单位不统一。同一个指标在不同年份的检验系统里单位不同，肌酐有 mg/dL 和 μmol/L 两种，混在一起会让这个变量彻底失效。清洗阶段必须做单位归一并记录换算系数。

日期与时序错乱。入院时间和手术时间格式不一致、时区混用、时间差算出来是负数。建议所有时间列统一解析成标准时间类型，并且加一条断言：术后时间必须晚于手术时间，不满足的直接报错而不是静默跳过。

重复记录与同一患者多行。除了前面说的分组切分，还要检查同一次住院是否有重复行（不同系统导出的合并导致的）。去重规则要写进预处理计划，不能靠人工临时处理。

5.3 问题排查速查表

6. 合规、复现与几点实践心得

6.1 数据安全这条线不能碰

不管效率提升多少，有一条线不能越：原始行级数据不出本地。送到外部服务的只能是脱敏后的数据字典和聚合统计量。变量名本身也可能带信息（比如包含具体日期或编号），送出去之前要脱敏。

如果研究所在的环境不允许调用外部服务，那就本地部署小参数模型。小模型在"把自然语言转成结构化 JSON""解释报错信息"这类任务上表现已经够用，不需要最强的模型。真正需要强模型的场景（复杂方法学讨论）可以用脱敏后的抽象问题去问，不带任何具体数据。

另外，模型的建议不构成统计学或临床决策的最终依据。所有对外输出的结果，必须经过具备相应资质的人员复核签字。这一点在团队协作里要写进流程，不能靠自觉。

6.2 可复现性做到什么程度算够

我的标准是：换一个人，拿着你的目录，能在一天内重现主要结果表。达到这个标准需要四样东西：配置快照（含哈希）、依赖版本锁文件、固定随机种子、原始数据与清洗脚本。

再加一条我自己加的：决策日志。每次关键决策（为什么剔除某个变量、为什么选这个指标、为什么改折数）都记一行，写上日期和理由。三个月后你会忘记当时的判断依据，而审稿人恰恰最爱问这个。这份日志让大模型帮你整理成初稿是合适的——它只是把你的记录组织成通顺的句子，不涉及任何新信息的生成。

6.3 几点实打实的体会

第一，先跑基线，再谈自动化。我的习惯是先用三五个临床先验变量跑一个逻辑回归，拿到基线指标。后面所有复杂模型都要跟这个基线比。很多项目做完发现，二十个变量的梯度提升模型比五个变量的逻辑回归只高 0.02 的 AUC，那从临床可用性角度，后者反而更值得推荐。基线是防止自己被复杂流程带偏的锚。

第二，大模型最大的价值在"减少返工"，不在"提高精度"。它不会让你的模型变准，但它能让"医生提需求—分析人员理解—配置落地"这个循环从三轮压到一轮。省下来的时间应该花在两件事上：把变量定义抠准，把验证策略做扎实。这两件事的收益远大于调参。

第三，不要相信任何没有经过外部或时间验证的性能数字。内部交叉验证再漂亮，也只是内部。如果条件允许，留一个时间段的数据做时间外验证，或者找一个规模小一点的独立队列。性能下降是正常的，下降多少、在哪些亚组下降，才是真正有价值的信息。我见过太多内部 AUC 0.85、外部 0.65 的例子，问题往往出在变量定义不一致或人群构成差异，而不是模型本身。

第四，把模型的用途想清楚，比把模型调准更重要。筛查用的模型要高敏感度、宁可误报；预警用的模型要校准好、阈值可解释；分层用的模型要能稳定区分几个风险档，而不是追求连续概率的精细度。用途不同，指标优先级、阈值选择、甚至模型族选择都不一样。这件事在动手写第一行代码之前就该定下来，并且写进需求卡片。

最后分享一个具体的小技巧：把每次运行的关键指标记到一个累积的 CSV 里，字段包括运行时间、配置哈希、变量数、模型族、主指标均值、极差、校准斜率。跑过二三十次之后，你回头看的不是某一次的结果，而是这三十次之间的关系——哪类配置稳定、哪些变量一旦加入就掉点、时间预算加到多少之后收益就没了。这张表比任何单次报告都更能告诉你下一步该往哪走。