真实世界研究（Real-World Research/Real-World Evidence, 下称 RWR/RWE）与医疗数据 AI 产品近年呈现出一种"看起来越来越像"的趋势：同样依赖电子病历、理赔数据、登记队列与多模态数据；同样强调数据治理、特征工程、模型训练与部署；同样在临床与支付方语境中讨论"效果""风险""价值"。问题在于，这种趋同究竟意味着方法论与产品形态的真实融合，还是只是在工程管线与术语层面的表面相似？
要回答这一点，必须先把两类事物的"目标函数"讲清楚：RWE 的核心是形成可被审查的因果性证据或准因果性证据，用于解释"如果采取某种干预，会发生什么变化"；医疗数据 AI 产品的核心则通常是产生可执行的预测或决策支持，用于回答"接下来更可能发生什么、该如何分配资源"。两者可以共享数据与工具，但是否融合，取决于它们是否在同一套可验证的因果框架下对齐，并承担相同等级的证据责任。
一、为什么看起来在融合：同源数据与同构工程
两者"越来越像"的第一推动力是数据资产与工程结构的同构化。
-
同源数据与同一类噪声 无论做 RWE 还是做 AI 产品，基础往往是 EHR/EMR、claims、检验检查、处方与随访数据。这些数据天然存在：缺失与不规则采样、编码漂移、选择偏倚（谁进入数据、谁被记录）、测量偏倚（记录受流程影响）、结局定义不一致等。于是，两者都必须发展相似的数据清洗、标准化、表型识别、时间对齐与质量评估体系。
-
共享工具栈：NLP、表型、表示学习、特征库 结构化数据之外，大量信息藏在病程记录、影像报告、出院小结中。NLP 抽取、弱监督标注、表型算法、特征库/知识图谱等能力，会同时服务于研究与产品。尤其在"先把数据变得可用"这一层面，研究与产品的做法往往高度一致。
-
平台化压力：从项目制到资产化 RWE 传统上偏项目制：围绕某个研究问题搭建队列、定义暴露与结局、做敏感性分析、交付研究报告。AI 产品则天然要求平台化：可复用的特征、可持续的训练与监控、可审计的数据血缘。这种平台能力反过来又会"拉着"RWE 走向数据产品化：队列生成器、结局定义库、可复现分析管线、证据版本管理等。
因此，若仅从数据基础设施与工程形态看，融合趋势确实存在，而且会进一步增强。
二、真正的分水岭：因果推断与预测建模的证据责任不同
表面趋同不等于方法论融合。关键差异在于：两者对"可接受的错误类型"与"证据可审查性"的要求不同。
-
RWE 的目标是可辩护的因果主张 RWE 需要回答"干预导致结果变化"的问题，必须面对混杂、反事实、时间依赖偏倚、处理依从性等难题。其合格输出不仅是一个数值结果，更包括：研究设计（如目标试验模拟）、变量定义、假设边界、敏感性分析、稳健性检验，以及对不可检验假设的透明披露。
-
多数 AI 产品优化的是预测或排序，不必天然给出因果解释 许多医疗 AI 产品（再入院风险、住院时长、资源调度、欺诈识别等）在业务上追求的是区分度、校准度与运营收益。即便它们会被包装成"改善结局"，其模型训练目标往往仍是相关性最大化，而不是识别"改变策略会不会改变结局"。在这里，模型可用性的门槛可能是：离线指标达标、上线 A/B 有收益、风险可控，而不是"因果主张可被外部审计"。
-
同一条管线，输出的"责任等级"不同 两者都可能用 propensity score、IPW、Doubly Robust、因果森林、Uplift 等工具，也都可能用深度学习表示。但工具相同并不意味着结论等价：如果缺少明确的干预定义、对时间零点与随访窗口的约束、对混杂结构的论证与敏感性分析，那么"用了因果工具"也可能只是因果外观。
所以，融合是否真实发生，不取决于是否"使用了因果推断术语"，而取决于产品或研究是否承担了相同等级的因果证据义务。
三、"因果推断 × 数据产品化/模型化"：可能的真实融合路径
如果说存在一条更可信的融合主线，它更接近于：把因果问题用产品化方式持续运行，并把产品的闭环反馈纳入因果框架中。这不是简单叠加，而是对组织能力与方法论同时提出更高要求。
-
从一次性研究到"证据即服务"（Evidence-as-a-Service） 将目标试验模拟、队列构建、结局定义、偏倚诊断、敏感性分析封装成可复用模块，形成版本化、可审计、可复现的证据流水线。这样，证据不是静态报告，而是可迭代更新的"证据产品"。
-
从预测到策略学习：把模型输出绑定到可执行干预 只有当模型输出对应明确可改变的行动（例如用药调整、随访策略、资源投放），并用因果框架评估"采取行动的增量效果"，预测模型才可能升级为决策模型。典型方向包括：异质性治疗效应（HTE）、uplift 建模、动态治疗策略（DTR）、离线策略评估等。
-
把部署后的反馈纳入因果识别，而不是当作"自然发生的数据" AI 产品一旦上线，会改变临床行为与数据生成机制，产生反馈回路与分布漂移。这会反噬 RWE（数据不再是"观察到的自然过程"），也会反噬模型（训练分布被自身改变）。真正融合需要用因果视角管理反馈：记录策略变更、干预触发、执行依从性，并在再训练与再评估时显式建模这些变化。
这类融合的本质，是把"因果识别的严谨性"嵌入"产品工程的持续性"中，而不是把因果推断当作点缀性的解释层。
四、为什么很多"融合"是表面相似：三种常见伪融合
在现实组织中，更常见的是"看起来融合"，但核心环节并未对齐。
-
把预测解释成因果：相关性包装成干预收益 用风险评分指导资源投放，然后宣称"降低了不良结局"，但未区分：是模型改变了结局，还是资源变化、记录变化或选择效应导致表观改善。缺少对反事实与混杂的处理，这类结论通常不可外推。
-
把因果方法当作模型组件，而非研究设计 例如使用 propensity score 进行"校正"，却没有清晰的暴露定义、时间零点、纳入排除标准、随访窗口，也没有讨论不可测混杂与敏感性分析。此时因果方法沦为"算法配方"，而非证据体系。
-
产品化只做了数据层，证据层仍是手工与不可复现 数据湖、特征库、模型平台都建好了，但研究仍靠临时脚本、口头定义与不可追踪的数据版本。表面上"研究上云、研究平台化"，实际上证据无法审计，也无法持续更新。
这些伪融合的共同点是：共享了工程外壳，却没有承担因果主张所需的透明性、可复现性与反事实推断责任。
五、判断是否"真实融合"的可操作标准
如果需要一个更务实的判别框架，可以看三条硬标准：
-
是否存在明确的干预与反事实定义 模型或分析输出是否对应"可执行动作"，并能回答"做/不做会怎样"。
-
是否具备可审计的因果证据链 是否能复现队列、变量、时间窗口与关键假设；是否做了负对照、敏感性分析、稳健性检验；是否对不可检验假设透明披露。
-
是否管理部署后的反馈回路 上线后的策略变化是否被记录并进入再评估；是否有漂移监控、再验证与证据版本迭代机制。
满足这三条，才更接近方法论与产品形态的实质融合；否则，多半是"共用数据与平台"的表面相似。
结论：会趋于融合，但不会自动融合；真正融合以因果为核心约束
真实世界研究与医疗数据 AI 产品确实会在数据基础设施、平台工程与部分分析工具上继续趋同，这是由数据同源、监管与运营效率共同推动的。但在方法论层面，二者的融合并非必然，更不会因为"使用了因果术语或因果算法"就自然发生。
更可信的判断是：融合只会在少数高价值场景中以"因果推断约束下的产品化"形式出现------即把干预定义、反事实推断、可审计证据链与部署反馈治理嵌入产品生命周期。除此之外，大量所谓融合将停留在工程管线相似、术语相似、指标相似的层面，而核心认识论差异依然存在：RWE 追求可辩护的因果证据，AI 产品追求可运行的预测与决策效率。二者能相互借力，但不能相互替代。