目前，大多数病理AI研究仍然基于单个时间点的切片进行诊断或预后预测。然而，同一患者在治疗和随访过程中产生的多次病理标本，可能包含着尚未被充分利用的时间信息。近期发表于Advanced Science的一项研究，通过量化膀胱癌患者前后两次H&E切片的细胞核形态变化，探索了利用纵向病理数据描述肿瘤进展的新思路。这项研究的意义或许不仅在于发现了哪些形态学指标，更在于为病理AI提供了一个值得关注的研究方向：从静态识别肿瘤特征，走向动态量化肿瘤变化。一、病理AI为什么总是在分析单个时间点？过去几年，随着病理视觉基础模型和全切片分析技术的发展，病理AI已经能够从常规H&E切片中提取越来越丰富的信息。从肿瘤诊断、组织学分级到基因突变预测、治疗反应及预后评估，绝大多数研究采用的都是相似的技术路线：获取某个时间点的病理切片，提取形态学或深度学习特征，再与临床终点建立关联。这种研究模式取得了不少成果，但存在一个容易被忽视的问题：单个时间点的病理切片只能反映肿瘤在某个时刻的组织学状态，却无法直接告诉我们肿瘤正在如何变化。例如，两个患者的肿瘤可能具有相似的组织学分级和细胞核异型性，但其中一位患者的肿瘤可能长期保持相对稳定，另一位患者则可能在近期出现了明显的形态学改变。仅从当前切片来看，两者可能难以区分，但如果能够获得此前的病理标本，就有机会通过前后的形态变化获得额外信息。实际上，临床诊疗并不总是只产生一次病理标本。对于需要重复活检、手术或长期随访的疾病，同一患者可能积累多个时间点的组织样本。特别是在接受新辅助治疗的肿瘤患者中，治疗前穿刺活检与治疗后手术标本本身就构成了天然的纵向病理数据。遗憾的是，这些来自不同时间点的病理切片，在不少计算病理研究中仍然被当作彼此独立的样本处理，其蕴含的时间变化信息并没有被充分利用。二、研究设计：把两次病理切片组成一个分析单元近日，徐州市中心医院联合东南大学、江苏师范大学等机构的研究团队在Advanced Science发表了一项关于膀胱癌纵向数字病理分析的研究。研究利用同一患者不同时间点的H&E病理切片，量化细胞核形态的动态变化，并探索这些变化与肿瘤进展之间的关系，为利用连续病理标本研究肿瘤演变提供了新的思路。膀胱癌是开展此类研究比较合适的疾病，因为部分患者，尤其是非肌层浸润性膀胱癌患者，在临床随访过程中会接受重复膀胱镜检查、经尿道肿瘤切除或活检，因而能够形成多个时间点的病理样本。研究者将同一患者较早获取的病理标本定义为T0，较晚获取的标本定义为T1，通过计算两个时间点之间的形态学特征差值，量化肿瘤随时间发生的变化。经过病例筛选和质量控制，研究建立了两个独立的纵向配对队列。其中，中心1作为发现队列，包含86名患者的86对病理切片，涉及35例进展和51例未进展患者；中心2作为独立验证队列，包含96名患者的96对切片，涉及38例进展和58例未进展患者。两个队列的T0至T1中位间隔分别为16个月和12.5个月。研究根据配对期间记录的病理学恶化情况确定进展状态，而单纯肿瘤复发、没有明确病理学进展的病例仍归入未进展组。此外，研究还使用了来自四家医院的1977张H&E全切片图像，建立传统单时间点病理AI分析的参照，并利用TCGA膀胱癌队列进行分子生物学关联分析。不过，这些数据与182对纵向病理样本属于不同的分析部分，并不能都视为纵向研究的验证数据。这项研究在数据组织上的一个关键变化，是不再将每张WSI简单视为独立样本，而是把同一患者的T0和T1组成一个配对分析单元。三、如何量化两个时间点之间的病理形态变化？虽然研究提出了纵向数字病理的概念，但核心技术并不复杂，也没有开发特别新颖的深度学习架构。其主要思路是通过现有的细胞核分割技术，从两个时间点的H&E切片中提取可解释的形态学指标，再计算前后的差异。首先，研究利用Cellpose对全切片中的细胞核进行实例分割，并提取核面积、等效直径、长短轴比例、圆形度和实心度等特征。其中，等效直径并非独立测量的核直径，而是根据核面积换算得到的等面积圆直径。随后，研究将细胞核特征汇总至局部组织区域及切片层面，从细胞核大小、形状规则性、局部细胞数量和空间组织结构等维度描述病理形态。值得注意的是，研究不仅分析整张切片的平均核形态，还利用500微米的空间网格，分析不同组织区域中细胞核大小及数量的分布情况。这使研究者能够进一步判断，所谓的形态变化究竟只是少数局部区域出现异常，还是在更大范围内发生了分布性改变。完成两个时间点的特征提取后，作者使用一个相当直接的方式计算纵向变化：用T1的特征值减去T0的特征值。这意味着，如果某个患者的平均细胞核面积在T1大于T0，那么该指标的变化量为正；反之则为负。与传统单时间点研究相比，这种分析的区别不仅在于多使用了一张切片，而在于把研究对象从某个时间点的绝对形态特征，转变为同一患者的形态变化方向及幅度。另外需要说明的是，T0与T1来自不同时间的独立病理标本，并不是对同一组织区域进行精确配准。因此，研究并没有追踪某个具体细胞核如何变化，而是比较两个时间点整体细胞核形态及其空间分布的统计差异。四、主要发现：肿瘤进展伴随着细胞核大小的纵向变化通过比较进展组与未进展组的纵向形态特征，研究者发现，细胞核大小的变化是其中比较突出的信号。在18项两个中心共有的纵向特征中，有11项表现出相同方向的进展关联，但具体效应强度存在明显的中心差异。尤其是在独立验证队列中，细胞核等效直径和核面积的变化与病理进展显著相关。平均等效核直径变化的标准化效应量为0.72，平均核面积变化的效应量为0.68，两项指标经多重检验校正后的FDR均为0.0039。进一步观察两个时间点的变化轨迹，可以发现，进展组的平均核直径和核面积总体呈现上升趋势，而未进展组则呈现下降趋势。这说明，与其仅仅考察某张切片中的细胞核是否较大，考察同一患者的细胞核是否在不同时间点之间出现了增大的趋势，也可能具有临床意义。当然，这项发现并不是在两个中心都得到了同等强度的验证。中心1中对应的核大小变化效应较弱，未达到统计学显著性。作者进一步开展了限定肿瘤区域、调整治疗因素、改变细胞核分割参数，以及采用更严格病理进展定义等敏感性分析，中心2的主要结果依然成立。例如，仅将病理分期升高视为进展，而不将单纯分级升高纳入进展时，中心2的核直径变化仍然具有统计学意义。这在一定程度上降低了研究结果仅仅来自组织学分级定义与细胞核异型性相互重叠的可能性。不过，中心之间效应强度不一致，也提示这些纵向特征仍然受到组织取样、病例构成和技术差异的影响。不只是平均核大小发生变化，空间分布也在改变。为了进一步理解核大小变化的组织学分布，研究者还分析了500微米空间网格中的细胞核面积分布。研究发现，在进展患者中，细胞核面积增大的现象并不局限于某几个局部区域，而是在更广泛的组织空间分布中表现出来。其中，反映核面积分布整体上移的指标具有较明显的组间差异，效应量达到0.80，FDR为0.007。这一结果提示，纵向病理变化不仅可以表现为某个平均特征值的改变，也可能体现为组织内某类形态学表型的整体分布发生变化。对于计算病理而言，这一点值得关注。未来进行纵向研究时，除了比较两个时间点的平均特征，还可以进一步分析肿瘤亚区域比例、细胞群组成、局部空间结构及不同组织学表型的分布变化。五、这些形态变化是否具有生物学意义？仅仅观察到形态学特征在不同时间点发生变化，还不足以说明这些变化能够反映真实的肿瘤生物学演变。因此，作者进一步引入了Ki-67免疫组化和TCGA转录组数据，为研究结果提供补充证据。在中心2具有Ki-67数据的病例中，研究发现T1的Ki-67指数与核大小变化相关指标之间存在一定的正相关，相关系数为0.267，P值为0.0468。对于同时具有T0和T1 Ki-67检测结果的28例患者，进展组的Ki-67变化量也显著高于未进展组。这一发现提示，细胞核形态变化可能与肿瘤细胞增殖活性的改变具有一定联系。不过，相关程度并不强，而且样本量较小，因此更适合作为支持性证据。另一方面，研究使用TCGA膀胱癌数据，分析从H&E中提取的核大小相关形态学指标与转录组特征之间的关联。结果显示，核大小相关指标与CD8 T细胞活性、细胞毒性、干扰素反应等多种免疫相关转录组特征呈负相关。这些结果为理解核形态与肿瘤生物学状态之间的联系提供了线索，但需要强调，TCGA分析使用的是单时间点数据，并没有验证同一患者前后两次切片的分子状态如何变化。因此，目前还不能据此确认核大小变化与免疫微环境演变之间存在明确的机制联系。六、与纵向分析形成对照：单时间点病理AI模型表现如何？前面的分析表明，同一患者在不同时间点的病理形态变化可能包含与肿瘤进展相关的信息。那么，相比之下，传统的单时间点病理AI模型又能够从切片中获得哪些信息？为此，作者还利用来自四家医院的1977张H&E全切片图像，开展了单时间点病理AI建模分析，分别比较了仅使用临床信息、仅使用UNI2病理基础模型特征，以及临床与病理特征融合的模型表现。在中心1的内部验证中，三种模型的AUC分别为0.72、0.69和0.75，融合模型表现最好。但当训练好的模型直接应用于其他三个中心时，融合模型的AUC分别为0.65、0.78和0.61，表现出明显的跨中心差异。此外，融合模型还能够对患者的无复发生存期进行风险分层，在中心1和合并外部验证队列中的风险比（HR）分别为5.18和2.22。这些结果说明，单时间点病理切片本身已经能够提供一定的临床风险信息，但模型的跨中心泛化能力仍然存在挑战。不过，需要注意的是，这部分研究与前面的纵向形态分析实际上回答了不同的问题。单时间点模型主要评估患者的复发风险，而纵向分析关注的是同一患者前后两次病理标本的形态变化及其与病理进展的关联。作者并没有在相同的临床终点上直接比较两种方法，因此尚不能证明纵向形态特征能够提供超越单时间点模型的预测价值。从这个角度来看，本文的意义并不是证明两张切片一定比一张切片预测得更准确，而是尝试从连续病理标本中提取单张切片无法直接描述的时间变化信息。 至于这些纵向变化是否能够为现有病理AI模型带来额外的临床价值，仍然需要后续研究进一步验证。七、这项研究真正值得关注的是什么？如果只从技术角度来看，这项研究所使用的Cellpose分割、形态学特征提取和统计比较，都不是特别新颖的方法。论文的创新性更多体现在研究问题和数据组织方式上。1. 从静态表型识别走向纵向变化量化传统病理AI更关注某个时间点的病理状态，例如切片中是否存在高危形态学特征，或者这些特征与患者预后之间有什么关系。纵向分析则进一步提出了另一个问题：同一患者的病理表型在一段时间内发生了哪些变化，这些变化又与疾病进展或治疗反应存在什么关系？这两类问题并不相同，也未必能够被同一种模型完全解决。特别是对于具有连续病理样本的疾病，患者自身的早期样本可以提供一个个体化的参照。即使两名患者在后一个时间点具有相似的病理形态，他们相对于各自早期状态的变化幅度，也可能完全不同。这种思路有机会使病理AI从单纯识别高风险形态，进一步发展到描述肿瘤表型的动态变化。2. 不一定需要复杂的新模型，也可以提出有价值的病理AI问题当前病理AI研究正在快速引入新的视觉基础模型、多模态融合架构和复杂的弱监督学习方法。相比之下，这项研究最核心的纵向分析，使用的是可以直接解释的细胞核形态学特征及其前后差值。这提醒我们，病理AI研究的创新并不一定需要开发全新的模型结构。合理利用现有数据、重新定义分析单元，以及提出具有临床意义的新问题，同样可能产生有价值的研究结果。当然，使用简单方法证明纵向变化可以被量化，只是第一步。这项研究尚未证明，纵向形态学特征能够提供超越单时间点病理指标的独立临床预测价值。3. 纵向病理分析还有不少值得解决的方法学问题尽管研究思路具有启发性，但真正开展高质量的纵向病理AI研究仍然面临一些挑战。首先，不同时间点的病理标本往往来自不同取样部位，组织成分、肿瘤比例及标本类型也可能存在明显差异。因此，观察到的形态变化不一定全部来自肿瘤生物学演变，还可能包含取样偏差。其次，治疗本身也会导致组织学改变。如果研究对象是治疗前后标本，那么肿瘤细胞消失、纤维化、炎症浸润及坏死比例变化，都可能成为重要的纵向信号。此时必须区分治疗诱导的变化、疾病自然进展，以及不同标本类型带来的差异。另外，这篇论文主要研究的是已经发生的病理进展与前后形态变化之间的关联，而不是在T0预测未来是否进展。只有获得T1切片后，才能计算完整的T1-T0变化量。因此，这种方法更接近于对疾病演变进行量化描述，而不能直接等同于提前预测进展风险。未来如果希望将纵向病理特征用于临床预测，还需要进一步明确预测的时间点和临床终点，例如利用T0和T1之间的变化，预测T1之后的复发或生存结局，并证明这些变化特征较单时间点模型具有额外价值。八、纵向病理AI，可能是一个值得进一步探索的研究方向从更广泛的角度来看，膀胱癌并不是唯一具有纵向病理数据的疾病。在乳腺癌、食管癌等接受新辅助治疗的患者中，治疗前穿刺活检与治疗后手术标本可以构成天然的配对数据。通过量化前后肿瘤细胞形态、组织结构、肿瘤间质比例及免疫细胞空间分布的变化，可以尝试建立更全面的病理疗效表征，并进一步研究这些变化与远期复发或生存结局之间的关系。对于炎症性肠病等需要长期组织学监测的疾病，不同随访时间点的活检标本同样可能用于量化炎症细胞浸润、腺体结构损伤及组织修复的动态变化。此外，随着病理视觉基础模型的发展，纵向病理分析也未必需要局限于人工定义的核面积、形状及密度等特征。未来可以利用基础模型分别提取不同时间点的组织表征，再通过特征差异、跨时间点交互建模等方法，学习传统病理组学指标难以描述的复杂形态变化。不过，基础模型能否真正学习到有生物学意义的时间变化，而不是放大不同时间点之间的染色、取样和扫描差异，仍然需要专门的研究设计与验证。从这个意义上说，纵向病理AI的价值，可能不在于简单地把两张WSI输入同一个模型，而在于如何建立一个能够区分真实组织学变化与技术、取样差异的量化框架。这篇Advanced Science研究还不能证明纵向病理分析一定优于传统的单时间点模型，其核心发现也需要在更大规模、取样更规范的独立队列中进一步验证。但它提供了一个值得关注的研究视角：临床长期积累的连续病理标本，除了用于每一次独立的诊断，是否还能够被重新组织起来，成为研究疾病演变的纵向数据资源？当越来越多的研究致力于从一张切片中提取更多信息时，或许也值得思考另一个问题：相比不断提高单张切片的特征提取能力，我们是否也应该开始关注同一患者不同时间点的病理切片之间，究竟发生了什么变化？

之前试过 OFA 的英文图像描述，效果不错，但有个尴尬的地方——它只会说英文。给一张风景照配文，出来的是“a view of a mountain range with a lake in the foreground”，你还得自己翻译一遍。所以看到 ModelScope 上有 mPLUG 的中文 Base 图像描述模型时，我第一反应是：终于不用在中文场景里硬套英文模型了。这个模型的定位很明确——给图片生成一句对应的中文描述。参数量约 3.5 亿，基于 mPLUG 多模态基础模型，在翻译成中文的 MS COCO Caption 数据集上做了 finetune。mPLUG 本身是阿里达摩院的工作，论文里提出了一种基于 skip-connections 的高效跨模态融合框架，发表时在 MS COCO Caption 上拿过 SOTA。这些背景信息翻译成人话就是：它不是随便拼凑的小模型，底座是有正经论文和榜单成绩背书的。实际跑起来很简单，官方给的推理代码就几行：pythonfrom modelscope.pipelines import pipelinefrom modelscope.utils.constant import Tasksmodel_id = 'damo/mplug_image-captioning_coco_base_zh'pipeline_caption = pipeline(Tasks.image_captioning, model=model_id)result = pipeline_caption('你的图片URL或本地路径')print(result)拿官方测试图跑了一下，输出的是一句完整的中文描述，句式自然，不像有些模型那样硬把英文语序塞进中文里。对于日常场景的图片，比如风景、食物、人物活动，它给出的描述基本能覆盖主体和场景，拿来当图片的 alt text、相册自动标注或者内容管理系统的初步标签是够用的。但有个点需要提前说清楚：它的训练数据是 MS COCO Caption，翻译成中文的版本。COCO 这个数据集的特点是图片以日常场景为主，描述风格偏简短、偏客观。这意味着两件事。第一，它对中文的语言习惯掌握得还不错，毕竟是在中文语料上微调过的，不会出现“人骑马”被说成“马被人骑”这种别扭表达。第二，它的描述风格会带着 COCO 的基因——短、直接、偏事实陈述，不太会给你来一段文采飞扬的散文式描述。如果你要的是“图片配文案”那种营销风格，它可能不够味；但如果你要的是“图片里有什么”的准确概括，它挺称职。另外，COCO 里没有的视觉内容，它也会犯难。你拿一张医学影像、一张工业零件图或者一张复杂的图表给它，输出的描述大概率会泛泛而谈，甚至跑偏。页面自己也写了“模型在数据集上训练，有可能产生一些偏差，请用户自行评测后决定如何使用”。这不是客套，是实话。通用场景的模型，拿到垂直领域直接用的风险，比很多人想象的要大。那它最有价值的用法是什么？我觉得是当微调底座。页面给了完整的 finetune 示例，用 coco_captions_small_slice 数据集走一遍流程，核心逻辑就是把数据集 remap 成 image 和 answer 两列，塞一个固定的 question（“what the picture describes?”），然后挂 nlp_base_trainer 跑训练。3.5 亿参数的 Base 版，单卡就能微调，门槛不高。如果你手头有某个垂直领域的中文图文对——比如电商商品图配描述、新闻配图配图注、甚至你自己拍的照片配文字——都可以拿这个预训练权重做领域适配。它已经具备了中文描述的基本能力，你只需要把它往你的场景方向推一把。有个实操细节值得注意：微调示例里用的 question 是英文的“what the picture describes?”，虽然模型是中文版，但输入 prompt 沿用了英文。实际微调时，你可以试试改成中文 prompt（比如“描述这张图片”），看看效果是否有差异。mPLUG 作为统一理解和生成的模型，对 prompt 的措辞是有一定敏感度的，这个变量值得在实验里控制一下。另外，页面提到 mPLUG 在 VQA 数据集上同等规模模型中取得过 SOTA。虽然这个页面卖的是图像描述能力，但底座本身的理解能力是在的。如果你后续想做“图片问答”方向——给一张图加一个问题，让模型回答——这个模型作为起点也是合理的。它的跨模态融合框架本来就是为理解和生成同时服务的，图像描述只是其中一个出口。总的来说，mPLUG 中文图像描述模型给我的感觉是：它不惊艳，但很实用。3.5 亿参数不算大，推理成本可控；中文输出自然，省去了翻译环节；微调接口清晰，拿自己的数据改一改就能往垂直场景推。它不会给你那种“AI 居然能这样描述图片”的震撼感，但对于需要批量给图片配中文描述、或者想找一个中文多模态底座做二次开发的场景，它是一个踏实的选择。COCO 的基因决定了它的描述风格偏保守，但保守在工程场景里往往不是缺点——准确、稳定、可预期，比偶尔灵光一现但经常跑偏要可靠得多。相关病理模型详情页：cid:link_0

前阵子想给一批图片自动配文字说明，翻了一圈方案， OFA 图像描述模型。原因很简单：它把“看图说话”这件事封装得足够轻，六行代码就能跑通，而且背后不是随便一个小模型——OFA 是阿里达摩院 ICML 2022 的工作，在 COCO Captions 官方榜单上拿过第一，Karpathy test split 的 CIDEr 到了 154.9。对于一个只想快速验证“图片自动描述”可行性的人来说，这个起点很友好。先说我实际跑的那次。拿官方 demo 里的甜甜圈图试水，输入一个 URL，输出一句 a bunch of donuts on a wooden board with popsicle sticks。句子不长，但该有的信息都有了：主体、数量、摆放方式、背景材质。对于通用场景的图片，这种描述已经能直接拿去做 alt text、相册自动标注或者内容检索的初步标签。代码也确实就是页面给的那六行：pythonfrom modelscope.pipelines import pipelinefrom modelscope.utils.constant import Tasksfrom modelscope.outputs import OutputKeysimg_captioning = pipeline(Tasks.image_captioning, model='damo/ofa_image-caption_coco_large_en')result = img_captioning('https://modelscope.oss-cn-beijing.aliyuncs.com/demo/image-captioning/donuts.jpeg')print(result[OutputKeys.CAPTION][0])批量推理也支持，传一个 list 加 batch_size 就行，做数据集级别的自动标注时省不少事。OFA 这个名字是 One-For-All 的缩写，核心思路是用一个统一的序列到序列框架，把图像描述、视觉定位、图片分类、文本生成这些跨模态任务都塞进同一个模型里。听起来野心很大，但落到使用层面，你不需要关心它内部怎么统一，只需要知道：它把图像编码器和文本解码器串成了一条“图进文出”的流水线。模型规模从 Tiny 的 33M 到 Huge 的 930M 都有，页面里这个 large 版是 470M 参数，ResNet152 加 12 层编码、12 层解码，在单卡上跑推理和轻量微调都撑得住。效果方面，COCO 榜单的数字可以参考，但更值得看的是它在不同规模上的表现梯度。Base 版 CIDEr 138.2，Large 到 142.2，Huge 冲到 145.3；经过 CIDEr Optimization 之后，Huge 的最终分数是 154.9。这个梯度说明一件事：如果你对描述质量有更高要求，换更大规模是有明确收益的，不是参数堆上去没感觉。当然，Large 和 Huge 的推理成本也差了一截，按实际场景选就行。不过，用之前最好对它的边界有个预期。这个模型训练在 COCO Caption 上，COCO 的图片以日常场景为主，描述风格偏短、偏口语。你拿它去描述一张医学影像、一张工程图纸或者一张卫星图，它大概率会给出“a black and white picture of……”这种泛泛而谈的句子，因为训练分布里没有这类视觉内容。页面自己也写了：“训练数据集自身有局限，有可能产生一些偏差，请用户自行评测后决定如何使用。”这句话不是客套，是实打实的提醒。那它的价值到底在哪？我的看法是：它提供一个足够强的通用底座，让你能用自己的图文对去微调。页面给了完整的 finetune 示例，用 coco_2014_caption 走一遍流程，核心就是把数据集 remap 成 image 和 text 两列，然后挂上 Trainers.ofa 跑训练。如果你手头有某个垂直领域的“图片-描述”配对数据——电商商品图、工业质检图、文档扫描件、甚至你个人相册的标注——都可以拿这个预训练权重做领域适配。470M 的 Large 版在消费级显卡上就能微调，这个门槛对个人开发者和小团队来说是够得着的。几个实操上容易踩的点也顺便提一下。第一，英文模型的 tokenizer 对非英文描述不友好，如果你要做中文图像描述，得换中文版本的 OFA，或者自己在中文语料上微调解码器，别指望英文权重直接迁移出像样的中文句子。第二，COCO 的 caption 偏短，微调时 max_length 和 beam search 的参数要按你的目标描述长度重新调，直接套默认值容易得到过短或重复的输出。第三，batch inference 虽然方便，但显存占用会随 batch size 线性上涨，Large 版批量跑的时候留意一下卡的内存。总的来说，OFA 图像描述模型给我最深的印象不是它在 COCO 上刷了多高的分，而是它把“图像到文本”这件事做成了一个接口清晰、可微调、规模可选的通用能力。它不是为某个垂直行业定制的，也正因如此，它的适用范围反而更宽——你可以把它当成一个起点，用自己的数据把它往任何方向推。对于想快速验证图像描述可行性、或者需要一个多模态底座来做领域适配的开发者来说，这是一个值得花半小时跑一遍的选择。相关病理模型详情页：cid:link_0

做医疗 NLP 的人大概都有过这种体验：拿一个通用中文 BERT 直接微调病历分类或者实体识别，跑出来的结果总差一口气。差的那口气往往不在标注数据量上，而在模型进医疗领域之前，根本没怎么见过“上消化道出血”“门静脉高压”“靶向治疗”这类术语的搭配方式。通用语料里“苹果”和“手机”的共现频率，远高于“胰腺”和“占位性病变”。医疗语言有自己的词汇分布和句法惯性，通用预训练模型对此是钝感的。基于 StructBERT 的医疗领域中文 Base 预训练模型（damo/nlp_medical_structbert_backbone_base），解决的就是这口“气”的问题。但动手之前得先把一件事说清楚：它是一个预训练底座（backbone），不是开箱即用的诊断模型。这个定位决定了它的使用方式和适用人群。StructBERT 是什么，医疗版又做了什么StructBERT 是阿里在 2019 年提出的预训练模型（arXiv:1908.04577），核心思路是在标准 MLM 之外，把语言结构显式加进预训练目标：词级的“打乱词序还原”和句级的“句子顺序预测”。简单说，它不只学“某个位置该填什么词”，还学“词和词之间的顺序关系是否合理”“两句话的先后逻辑对不对”。这个设计对中文尤其有价值，因为中文没有形态变化，词序和句序承载了更多语法与语义信息。医疗版的改动本身并不复杂：模型结构完全沿用中文 StructBERT-base（12 层 / 768 隐藏维度 / 12 头，约 102M 参数），在医学数据上继续做 MLM 预训练。没有改架构，没有加新模块，就是在医疗语料上把通用模型“泡”了一遍，让它的词向量和注意力模式向医学语言分布偏移。这种“继续预训练”的做法在领域适配里是最朴素也最稳妥的路径之一。它不承诺奇迹，但能实打实地让模型在遇到“术后观察要点”“病理分期”“免疫组化”这类表达时，激活更合理的内部表示。对于下游的序列标注、句子分类、句子相似度任务，这个底座的起点比通用 BERT 更靠近医疗语义空间。对医生读者：它不看病，它帮你把“话”变成“数据”如果你是从临床侧过来的，最需要厘清的一点是：这个模型不输出诊断结论，也不读影像。它的工作对象是文本——病历、医嘱、检查报告、问答记录。它能做的是把这些自由文本变成机器可计算的结构化表示，从而支撑几类实际场景：一是病历结构化与质控。把一段出院小结喂进去，微调后的模型可以辅助抽取“主诉、现病史、手术方式、病理结果”等字段，或者判断一份病历的完整性。二是医疗问答与检索的底座。患者问“胃出血一般住院多久”，模型能把这个问题和知识库里的段落做语义匹配，而不是靠关键词硬碰。三是术语归一与相似度判断，比如判断两条诊断描述是否指向同一概念，辅助编码或去重。但它有明确的边界：训练数据有限，页面明确写了“效果可能存在一定偏差”，且“数据评估及结果：暂无”。这意味着它没有一份官方背书的基准分数供你直接引用。对临床场景而言，这不是一个小问题——任何要进入实际工作流的模型，都需要在你们自己的数据上重新验证。把它当作一个起点更好的底座，而不是一个“已验证可用”的成品，是更负责任的态度。对开发者：微调路径和那个值得注意的示例模型页面给的示例是用 CBLUE 的 KUAKE-QQR 数据集做句子相似度微调。KUAKE-QQR 是中文医疗问答里的 query-query 相关性任务，判断两个患者提问是否语义等价。选这个例子挺合适：它直接对应医疗检索里的“同义问句识别”，也是双塔召回或 FAQ 匹配的基础能力。代码逻辑不复杂：通过 cfg_modify_fn 把 backbone 挂到 sentence_similarity 任务上，指定 query1、query2、label 三个字段，用 nlp-base-trainer 跑训练。几个实际使用时值得留意的点：第一，total_iters 的写法要按自己的数据量改。 示例里 int(len(dataset['train']) / 32) * cfg.train.max_epochs 是按 batch size 32 估算的，如果你的 batch size 或数据规模不同，这个 scheduler 的总步数会偏，影响学习率衰减曲线。第二，示例把 workers_per_gpu 设成 0 是为了演示环境稳定，真实训练时应该按机器配置调大，否则数据加载会成为瓶颈。第三，labels: ['0', '1', '2'] 是三分类设定，如果你的任务标签空间不同（比如二分类的“相关/不相关”），这里必须同步改，否则训练会直接报错或静默出错。另外，102M 的 base 规模意味着它在单卡甚至消费级显卡上就能微调，推理部署也轻量。对于医院内网或边缘环境，这个体积是友好的——不需要动辄 A100 集群，一张 24G 卡就能跑起来。它适合谁，不适合谁适合：手头有医疗文本标注数据、需要一个领域适配起点、任务落在分类/序列标注/句子相似度/检索匹配范围内的团队。尤其是那些已经在用通用 BERT 做医疗 NLP、但觉得效果“差一口气”的项目，换这个底座做对照实验，成本很低。不适合：期待直接调用就能输出诊断建议的场景；需要生成式能力（它只做理解，不做生成）；以及没有自有验证数据、打算“先上线再说”的用法。页面那句“请用户自行评测后决定如何使用”，在医疗语境下不是免责套话，是实打实的工程要求。总结医疗 StructBERT-base 的价值不在于它有多新——StructBERT 是 2019 年的架构，继续预训练也是成熟做法——而在于它把“领域适配”这件事做成了一个102M、可微调、部署轻、接口标准的现成底座。对开发者，它是一个低成本的对照基线；对医生和临床信息团队，它是把自由文本转成可用数据的起点，但必须配上一轮本地验证。医疗 NLP 没有“开箱即用”这回事，这个模型也没打算假装有。相关病例模型详情页：cid:link_0

最近找到一个医疗模型coROM 中文医疗版，体验后想分享下感受。不是因为它参数大，而是它在“医疗 query 和医疗段落的相关性”这件事上，表现出了一种通用模型很难替代的干脆——你给它一个问句和一堆候选，它能把“术后观察要点”和“血压体温脉搏呼吸监测”这种语义上对得上、字面上未必重合的段落挑出来，而不是被“住院时间大概多久”这种泛化表述带偏。把页面说明和实际跑下来的感受整理一下，给同样在做医疗检索的朋友一个参考。它到底在做什么coROM 是个双塔（Dual Encoder）文本表示模型。Query 和 Document 各自独立过一遍编码器，取 [CLS] 位置的输出作为固定维度的向量，然后用余弦距离（页面代码里实际算的是 L2 距离，后面会聊这个细节）度量相关性。双塔的好处是工程上的：文档库可以离线批量编码建索引，线上只编码 query 做近似最近邻搜索，千万级候选下延迟可控。但它不是“BERT 套医疗数据”。底座是 ROM（Retrieval-Oriented Model） 系列，一个预训练阶段就把“检索匹配”作为优化目标的模型，而不是通用语言理解出身的 vanilla BERT。检索任务的目标函数和语言建模本来就不是一回事：前者要把相关的 query-passage 拉近、不相关的推远，后者关心的是 token 级预测或句子分类。ROM 底座让模型在进医疗微调之前，就已经对“匹配关系”更敏感。医疗适配则是在 Multi-CPR 数据集的医疗子集上完成的。这个数据集是 SIGIR 2022 的 Multi-CPR 论文配套的，覆盖通用、电商、医疗三个领域。训练分两阶段：第一阶段从官方文档集随机采样负样本，第二阶段用 Dense Retrieval 挖掘难负样本重新训练。这个二阶段设计是效果提升的关键——随机负样本太“容易”了，模型学不到细粒度的相关性边界；难负样本才是真正逼着模型去区分“相关但不完全匹配”和“确实不相关”的东西。它的效果：BM25 到 CoROM 的差距比想象中大页面给的 Multi-CPR 医疗领域召回评估数据很能说明问题：模型MRR@10Recall@1000BM2518.6948.20CoROM-tiny（256 维）22.7864.54CoROM-base（768 维）33.9173.30BM25 的 Recall@1000 只有 48.20，意味着传统词频检索在一半以上的 query 上，前 1000 个候选里根本找不到相关段落。CoROM-base 把这个数字拉到 73.30，MRR@10 也从 18.69 跳到 33.91——相关结果不仅被召回了，而且排得更靠前。tiny 版虽然指标低一截，但 256 维、64.54 的 Recall@1000，在“先粗筛再精排”的多阶段链路里作为第一层召回是完全够用的，存储和计算开销却小得多。这个对比里有个容易被忽略的点：BM25 在医疗场景的弱势不是偶然的。医疗 query 和文档之间的词汇重叠度天然偏低，患者问“上消化道出血手术大概多久”，文档写“术后应观察血压、体温、脉搏、呼吸变化”，字面上几乎没有交集，词频模型无从下手。稠密向量表示的价值就在这里。一个值得留意的细节：score 是 L2 距离，不是余弦页面代码示例里，scores 字段输出的数值是 75.6、62.2 这种量级，说明里写得很清楚：“scores 中的 score 计算两个向量之间的 L2 距离得到”。这和前面“通过余弦距离度量相关性”的表述是有出入的。实际用的时候要注意这一点：如果你按余弦相似度的直觉去设阈值（比如 0.7 以上算相关），会对不上。L2 距离的数值范围取决于向量模长，不同模型、不同版本之间不能直接横向比较。更稳妥的做法是在自己的验证集上校准一个阈值，或者干脆只用相对排序、不用绝对分数做硬截断。这种文档表述和代码实现之间的细微不一致，在工程接入时是很容易踩的坑。另外，默认 pipeline 的 max_length 是 128，页面训练超参里 max_sequence_length 也是 128。医疗段落如果偏长（比如完整的术后护理说明），超出部分会被截断，这对召回精度有实际影响。如果候选文档普遍较长，建议在 pipeline 配置里显式调大 max_length，或者先做段落切分再编码。训练和微调：4 张 V100 就能跑页面给了完整的训练示例代码，基于 dureader-retrieval-ranking 数据集，用的是 ModelScope 的 nlp_sentence_embedding_trainer。训练配置是 4 张 NVIDIA V100、3 个 epoch、batch_size 64、learning_rate 5e-6、AdamW。这个资源门槛对中小团队相当友好，意味着你可以拿自己的医疗标注数据替换掉示例数据集，在单机四卡上完成领域微调。模型 ID 有两个规格：damo/nlp_corom_sentence-embedding_chinese-base-medical（768 维）和 damo/nlp_corom_sentence-embedding_chinese-tiny-medical（256 维）。base 版精度优先，tiny 版效率优先，按你的候选规模和延迟要求选。边界要说清楚官方文档在局限性里写得很直白：模型在 Multi-CPR 医疗数据上训练，其他垂直领域的效果会下降，请自行评测后决定是否使用。这不是客套话。coROM 的领域专用性是一种明确的取舍——它在医疗检索上换来了更精准的语义对齐，代价是金融合同匹配、法律条文检索这类场景不该指望它。如果你的系统是跨领域混合检索，要么额外评估，要么考虑通用版本的 coROM。总结coROM 医疗版的价值不在于“又一个医疗文本模型”，而在于它把检索专用底座 + 难负样本二阶段训练 + 医疗领域数据这三件事叠在了一起，在召回环节给出了比 BM25 高出一大截、比通用模型更贴合医疗语义的候选质量。256 维的 tiny 版让它在存储和延迟上足够轻，4 张 V100 的微调门槛让它能被中小团队真正用起来。做医疗问答、临床知识检索、健康信息匹配的朋友，值得拿自己的数据跑一轮召回评估，重点看 Recall@1000 和 MRR@10 这两个指标——它们比任何榜单分数都更接近你实际系统的体验。相关病例模型详情页：cid:link_0

一、技术架构与设计理念端云协同推理是华为云医疗AI使能平台的另一核心架构特性，其核心设计理念是“推理在本地，训练在云端”——推理任务在本地GPU或消费级PC上执行，云端负责模型管理和调度。这一架构针对病理AI领域普遍存在的本地医院缺少算力资源这一核心难题，将训练完成的模型下沉至本地或边缘端进行推理，既保障诊断实时性，又通过安全机制确保病理数据合规。平台预置乳腺癌、结直肠癌等推理模型，支持端云大小模型协同推理，云侧和端侧两种推理模式。基层医院无需购置昂贵的GPU服务器，仅凭普通消费级PC即可完成AI推理，带宽需求降低85%，推理速度压缩至秒级。二、部署模式与工作流平台的端云协同客户端安装后，推理任务在本地GPU上执行，云端负责模型管理和调度。在病理图像推理环节，平台支持两种推理模式：云上推理适用于算力需求较高的复杂诊断任务；端侧推理适用于对实时性和数据本地化要求较高的场景。用户可在平台中选择预置模型，上传.svs格式的病理图像文件（单次最多可选择20张），创建推理任务后即时获取AI辅助诊断结果和可视化分析报告。在实际部署方面，方案采用“云上安全存算，以租代建、开箱即用”模式，PIS系统集成周期约一周，无需升级院内网络带宽，本地消费级PC即可承载相关AI推理能力。相比传统院内集中自建模式，首年投入可下降90%，五年总成本可降低40%以上。三、轻量化部署与边缘推理在轻量化部署方面，华为云推出的RuiPath 2.0 Edge版本仅200万参数，可部署在医院普通PC设备上，结合云端协同实现分钟级推理，进一步降低基层硬件门槛。端云协同的推理架构使医院无需购置本地算力集群即可获得顶级AI能力，推理速度压缩至秒级，为基层医疗机构的智慧病理建设提供了高性价比的技术路径。

一、技术原理与架构设计云上增训是华为云医疗AI使能平台的核心架构特性之一，旨在解决病理AI领域中模型跨院泛化能力不足的根本性难题。由于各医院在制片、染色、扫描等环节存在操作差异，通用病理模型难以在不同医疗机构间实现精准适配，传统方案往往需要从零开始训练模型，数据需求量大、周期长、门槛高。云上增训的技术路径是：医院将本院特色病例数据在云端进行增量训练，让基础大模型快速适配本院疾病谱与诊断习惯。平台支持“少样本训练”能力，医疗机构可以在RuiPath 2.0基础上使用本院数据做二次强化学习，仅需传统训练不到10%的数据，即可生成适配本院业务的定制化病理模型。这一机制显著降低了模型训练的数据门槛与时间成本。二、关键能力与安全设计在训练工具层面，平台将复杂的AI开发流程提炼为“看、训、推”三大核心环节，并细化为8个标准化步骤：数据整理、数据上云、数据集导入、创建数据集、数据集标注与发布、模型训练与部署、模型推理、报告查看。平台为病理医生提供了增训Agent智能助手，在病理系统中深度整合，支持医生无需掌握编程技能即可完成模型训练操作。在数据安全层面，平台采用端云协同混合计算架构，在医院端提取少量疑似肿瘤区域特征上传至云端，节省85%的带宽并实现加密传输；云端基于全密态“可用不可见”机制完成诊断推理与模型增训。通过端到端加密、切片脱敏、云端安全防护、数据保险箱、模型保险箱等能力，保障病理数据在云上专区存储、传输和使用过程中的安全合规，实现数据不出“域”。三、实践成效以邯郸市中心医院为例，该院病理科通过每轮几十张切片的小样本训练，完成了乳腺癌、结直肠癌等模型的本地化优化。乳腺癌模型针对本地病例的有无肿瘤判别准确率从早期约95%提升至接近100%，组织学类型达到90%以上；结直肠活检小标本模型的有无肿瘤准确率达到99%，这验证了云上增训机制在真实临床场景中的有效性。

一、平台背景与战略定位2026年6月，华为云正式上线“行业AI梦工厂”四大专区，涵盖智慧医疗、具身智能、智能制造、科学计算四大行业。其中，智慧医疗专区是全国首个面向医疗行业的医疗AI社区，医疗AI使能平台于同期升级并开启公测。该平台深度融合了上海交通大学医学院附属瑞金医院的临床实践经验与华为在ICT、云、AI领域的核心技术积累，构建了“场景—模型—平台—社区”端到端的医疗AI支撑体系，并提供全流程的云上工具链。平台的核心目标定位于解决医疗AI落地中的结构性难题。当前国内医疗行业面临三大痛点：优质医疗资源分布不均、病理医生严重短缺、基层诊断能力薄弱。据统计，中国有3.8万家医院，但仅有5000家医院开设了病理科，病理医生不足2万人，市场需求缺口超过14万人，且病理科与病理医生高度集中于少数三甲医院。医疗AI使能平台的设计初衷，正是通过平台化、社区化的方式，将顶级医院的诊断能力转化为基层可用的标准化工具。二、技术基础与生态格局平台的模型底座依托瑞金医院与华为联合研发的瑞智病理大模型RuiPath。该模型覆盖了90%的中国常见癌种和90%的下游诊断任务，通过数据飞轮机制在临床使用中持续迭代优化。RuiPath 2.0版本进一步将诊断任务扩展至205项，覆盖19个常见癌种，在59项下游诊断任务中有42项取得SOTA效果。在生态建设方面，平台采用开放社区模式，面向三甲医院、地市级医院、县域医院及开发者群体开放。目前已有90余家医院接入使用RuiPath病理大模型并入驻华为云智慧医疗专区，覆盖重庆大学附属三峡医院、普洱市人民医院、瑞安市人民医院、石家庄市人民医院等各级医疗机构，标志着国内病理AI进入规模化应用阶段。

一、功能定位与设计理念模型训练是华为云医疗AI使能平台最具差异化价值的功能模块，其核心设计目标是将AI模型训练的门槛从“算法工程师级”降低至“病理医生级”。平台将复杂的AI开发流程提炼为“管、看、推、训”全流程能力升级，覆盖从数字切片存储管理、智能辅助阅片、AI推理诊断到模型持续训练优化的完整闭环。平台的核心设计理念是“千医千面”——每位病理医生都可以基于自身诊断经验和对形态学的认知特点，训练专属的病理AI模型。无论是三甲医院的亚专科专家，还是基层医院的病理医生，都可以将个人诊断经验转化为可复用、可迭代的AI能力。二、标准化训练流程平台将AI模型训练流程标准化为8个可操作的步骤，使病理科医生无需编程基础即可高效完成模型训练：数据整理：对现有病理切片与诊断数据进行规范化梳理；数据上云：安全高效地将数据迁移至云端平台；数据集导入：将病理图像批量导入平台系统；创建数据集：按病种、部位等维度建立结构化数据集；数据集标注与发布：进行ROI标注与质控，发布为标准数据集；模型训练与部署：基于基础大模型进行增量训练，一键完成部署；模型推理：将训练好的模型应用于实际切片的智能分析；报告查看：查看AI辅助诊断结果与可视化分析报告。在操作体验方面，完成标注后只需点击“启动训练”，系统自动完成后续流程，无需人工干预。对于300余张切片的训练任务，首轮训练约耗时仅需几小时，耗时与切片数量和图像分辨率相关。三、模型迭代与持续优化平台支持模型的持续迭代优化。以邯郸市中心医院为例，该院建立了“数据—训练—验证—反馈”的多轮迭代策略：样本审视阶段检查标注质量、识别可能的噪声或逻辑漏洞；指标评估阶段关注验证集和测试集的准确率变化；数据补强阶段针对数据量少的类型补充高质量样本；持续训练阶段重复上述流程，逐步提升模型性能。依托华为云的数据飞轮机制，医院仅需约10%训练数据即可构建专属模型，在持续使用中通过数据飞轮实现“越用越准”。基层医院可打造本地化病理模型，实现从“单点能力”向“区域均质化能力”转变。这一机制使模型能够随着临床数据的积累而持续进化，而非停留在静态的初始训练状态。

一、功能架构与预置模型AI推理诊断是华为云医疗AI使能平台的核心功能模块之一，为病理医生提供开箱即用的AI辅助诊断能力。平台预置乳腺癌、结直肠癌等推理模型，支持端云大小模型协同推理，用户可根据临床场景需求选择云侧或端侧推理模式。在模型能力方面，平台依托的RuiPath病理大模型覆盖了中国常见癌种和大部分下游诊断任务，通过数据飞轮机制实现越用越准的持续优化。RuiPath 2.0版本将诊断项目扩展至两百余项，覆盖乳腺癌、结直肠癌、肺癌等19个常见癌种，能够覆盖病理医生90%以上的日常工作。在下游诊断任务中，有数十项取得SOTA效果，综合性能优于海外同类病理基础模型。二、推理流程与操作路径AI推理诊断的操作流程设计遵循极简原则。用户在平台中选择预置模型（如病理体验模型-乳腺癌），系统自动带出相关病理知识库，涵盖各类癌症标准病理诊断逻辑。用户上传待推理的病理图像文件后，点击“立即创建”即可进入AI推理界面。平台支持单次最多选择20张病理图像，推理完成后可查看病理切片和详细的推理结果，包括各诊断任务的输出和可视化分析报告。在诊断任务配置方面，平台支持灵活的自定义诊断任务。用户可根据本院实际需求定义分类体系，例如肿瘤区域检测、组织学分级、亚型分类等多层级诊断任务。这种灵活性使平台能够适配不同医疗机构的差异化诊断需求，而非局限于固定诊断模板。三、临床验证与实践成效在临床验证方面，邯郸市中心医院基于平台的乳腺癌模型训练结果显示，经过多轮迭代优化，诊断任务准确率已稳定提升至90%以上。乳腺癌模型针对本地病例的有无肿瘤判别准确率从约95%提升至更高，组织学类型达到90%以上。RuiPath 2.0在罕见病种方面也有突破性进展。面对罕见病种样本不足的困境，研究团队借助多模态生成模型合成训练数据，使淋巴瘤有无诊断准确率达到96.48%。这些数据表明，平台的AI推理诊断能力已具备进入临床生产流程的技术成熟度。

一、功能原理与技术特性智能辅助阅片是华为云医疗AI使能平台面向病理医生的核心应用功能，旨在通过AI技术提升病理诊断的效率和准确性。平台以“将医生对形态学的认知固化到AI算法中”为核心理念，致力于让每位病理医生都能拥有贴合自身诊断风格的AI助手。智能辅助阅片的核心能力包括：AI快速完成全切片数字化扫描和分析，通过热力图自动标注可疑病灶区域，高效捕获微小病变，为早期病变鉴别提供可靠依据。平台突破了传统AI“千人一面”的局限，支持病理医生基于自身对形态学的认知特点与专科经验，通过平台训练打造专属病理AI模型，构建个人独有的“数字分身”，实现“千医千面”的个性化赋能。二、工作流重构与效率提升在临床工作流层面，智能辅助阅片正在推动病理科工作模式的根本性转变。以邯郸市中心医院为例，该院构建了“AI初筛+医师复核”的全新工作流：扫描仪将切片自动转为数字图像，云端算力逐张完成智能分析，标注有无肿瘤、组织亚型、恶性分级；医生只需在工作站上复核确认。这一模式彻底改变了传统显微镜人工阅片的工作方式，医师重复性阅片减少，审片效率得到了极大的提升。在诊断效率方面，AI辅助下的单切片诊断时间从分钟级压缩到秒级。瑞安市人民医院病理科医生反馈：“AI自动识别癌区并生成报告，阅片时间大幅缩短。病理医生从重复劳动中解放出来，有了更多时间学习”。AI初筛将阳性病例的阅片时间压缩至2分钟以内，患者拿到报告的周期也随之缩短。三、可解释性与质量控制在可解释性方面，平台持续提升病理诊断的透明度。RuiPath 2.0首次在组织学亚型、浸润深度、核分裂象等维度实现精确的可解释性标识，让AI分析过程透明可追溯。推理完成后，热力图功能可直观显示癌变区域的范围和严重程度，这对教学和质控具有重要价值。智能辅助阅片不仅提升了诊断效率，更通过可视化分析工具增强了病理医生对AI结果的信任度和采纳意愿。

一、功能定位与架构设计数据管理是华为云医疗AI使能平台的基础功能模块，为病理科数字化转型提供从数字切片存储到数据集构建的全流程数据管理能力。平台端到端打通院内病理信息系统到华为云医疗AI使能平台，实现病理数据全生命周期管理的完整闭环。平台支持数字切片的本地存储与云端协同管理。以瑞安市人民医院的实践为例，医院通过华为云智慧医疗专区打通RuiPath病理智能体、医疗AI使能平台与院内病理工作流，实现了从数字切片扫描、本地存储、医生工作站、PIS系统到病理医生复核的闭环应用。在存储层面，平台依托华为OceanStor Pacific分布式存储技术打造医疗数据湖，实现一秒千片的数据吞吐能力，历史标本可保留30年，统一压缩算法最多可节省45%存储空间。二、数据准备与质量管理在数据集构建环节，平台提供完整的工具链支持。用户可创建病理训练数据集，按病种和诊断任务维度进行结构化组织。平台预置了乳腺癌、结直肠癌等常见癌种的推理任务模板，覆盖有无肿瘤、组织学类型、脉管侵犯等多个诊断维度。在数据标注方面，平台提供专业标注工具，支持对每张病理切片的有无肿瘤、组织学类型与分级等诊断任务信息进行逐一标注确认，确保从源头把控数据质量。在数据上传和管理方面，平台支持.svs格式的病理图像文件，通过OBS批量上传工具将全切片数字图像上传至云端，在客户端关联本地路径后平台自动识别已上传的数据。平台还提供了病理知识库功能，收录各类癌症标准病理诊断逻辑，包括癌变判定、分型、分级等诊断项之间的关联关系，AI推理时调用这些规则校验各任务输出，确保结果符合临床诊断逻辑、判读标准统一一致。

扫描仪、AI软件、信息系统各自为战，病理科数字化转型常困于“最后一公里”。全流程数字化建设可打通系统壁垒，让AI能力真正下沉到日常诊断场景。面对智慧病理科建设投入大、周期长、集成难的落地难题，本次直播特邀上海衡道医学数字产品总经理左彦飞，以上海瑞金医院为标杆，分享衡道全数字化智慧病理科建设的实战经验。同时，深度拆解医疗AI使能平台对接PIS系统的关键路径，PIS对接后，切片扫描完成即自动推送AI诊断，实现扫片到报告的全流程自动化闭环，真正解放病理医生双手。 10月21日（周三）17:00正式开播，扫码即可预约。观看直播送专属好礼，和行业专家一起打通智慧病理“最后一公里”，我们不见不散。医疗AI使能平台“体验有礼”活动流程1、平台试用申请（申请格式填写：体验官活动+姓名+工作单位+职位）2、登录体验，操作指引请见【医疗AI使能平台操作指引】3、本帖评论，上传模型推理&训练体验图片+华为云账号领取好礼！一、活动时间2026年10月21日——2026年11月23日 二、活动规则及奖项说明1、医疗AI使能平台试用申请在线上传本地切片完成病理模型推理，完成后在本页回帖，分享完成在线诊断的截图+华为云账号名即可获得华为云镭射包、数据收纳包（任选一） 2、下载医疗AI使能平台客户端并登录完成上传图像切片病理模型推理，体验后在本页回帖，分享完成病理诊断的截图+华为云账号名即可获得华为云定制数据收纳包、镭射包、防晒服、胶囊伞、保温杯（任选一）       3、VOC声音反馈有礼：体验医疗AI使能平台功能后，在本帖下分享反馈您对平台功能的建议或者意见反馈合理有效建议可获得华为mini超级快充充电器(Max 25W)、柔绒保暖披肩围巾、防晒服（任选一），最多10名  4、优秀案例分享有礼：在智慧医疗社区发帖分享您使用医疗AI使能平台的实践任务，参考案例“基于华为云医疗AI使能平台训练专属模型...”可获得华为云定制三脚架自拍杆、柔绒保暖披肩围巾、罗技键盘套装、云宝盲盒（任选一），最多10名（奖品有限，先到先得） 如有疑问，请咨询医疗AI小助手联系邮箱：hcmedcommunity@huawei.com  活动注意事项：1、严禁使用多个账号重复盖楼；严禁恶意刷屏、发布与主题无关的内容，影响活动秩序；严禁使用 P 图、盗用等作弊手段。上述行为一经发现取消获奖资格；2、开奖公示：活动结束后，将于5个工作日（11月23日至11月30日）后在本活动贴发布获奖名单公示，公示期为5天（11月30日至12月5日）；3、奖品发放：公示期结束后，工作人员将通过论坛站内信联系获奖用户核对信息、发放奖品，虚拟奖品直接发放至用户账号，实物奖品通过快递邮寄。获奖名单公示期后预计5个工作日内寄出；4、活动期间，如遇不可抗力因素（如服务器故障、网络问题等），活动主办方有权调整活动时间或内容；5、活动奖励不可兑换现金，奖品颜色、款式等以实物为准；6、活动最终解释权归论坛运营方所有。

医疗AI喊了这么多年，真正落到临床的有多少？这个问题，病理科医生可能最有发言权。中国有3.8万家医院，但开设病理科的只有5000家。病理医生不足2万人，缺口超过14万。更麻烦的是，这2万人高度集中在少数三甲医院——基层患者想做个像样的病理诊断，往往要把切片寄到大城市，等上一两周才能拿到报告。优质医疗资源分布不均这个老问题，在病理领域表现得尤为尖锐。华为云行业梦工厂智慧医疗专区里的医疗AI使能平台，试图用一种不太一样的方式来解决这个问题。它的思路不是再做一个“更强的AI模型”然后卖给医院，而是把病理诊断能力、华为的云和AI技术、以及一个开放的社区生态揉在一起，做成一个基层医院能用、病理医生能上手、开发者能参与的平台。这个定位有几个值得注意的地方。第一，它把“顶级医院的诊断能力”变成了“可配置的模块”。 瑞金医院与华为联合研发的瑞智病理大模型RuiPath，覆盖了90%的中国常见癌种和90%的下游诊断任务。但平台没有止步于“预置一个大模型”，而是让每家医院可以在RuiPath基础上做本地化增训，适配自己的疾病谱和诊断习惯。这意味着基层医院拿到的不是一个“死”的模型，而是一个可以“活”起来的底座。第二，它把“算力门槛”降到了消费级PC的水平。 传统病理AI部署方案要求医院购置GPU服务器，动辄几十万上百万的投入，很多基层医院根本扛不住。医疗AI使能平台采用端云协同架构，推理在本地PC上跑，训练在云端完成。这个设计直接砍掉了基层医院最大的硬件障碍。第三，它把“AI开发”这件事从算法工程师手里交到了病理医生手里。 平台把模型训练流程拆成8个标准步骤，医生不需要写代码，只需要整理数据、标注、点“启动训练”。这个转变的意义不在于技术有多难，而在于真正懂病理的人终于可以自己去训练AI了。目前，这个平台已经有近百家医院接入，覆盖三甲、地市级和县域医院。不同层级的医院都在用自己的方式使用这个平台。这个信号比任何技术指标都更有说服力：医疗AI的普惠化，可能真的在从口号变成现实。

华为云医疗AI使能平台的技术架构中，有两个设计决策值得深入拆解：云上增训和端云协同推理。前者解决模型跨院泛化问题，后者解决基层算力缺失问题。两者共同构成了平台“训练在云、推理在端”的技术底座。一、云上增训：用少样本学习破解跨院泛化病理AI领域有一个长期存在的工程难题：模型跨院泛化能力差。原因在于各医院在制片、染色、扫描等环节存在系统性差异，同一张切片在不同医院的扫描仪下可能呈现出不同的色彩分布和纹理特征。一个在A院训练到98%准确率的模型，到了B院可能直接掉到70%。传统解决方案是从头训练，但这对基层医院来说几乎不可行——需要大量标注数据、需要GPU集群、需要算法团队。云上增训的设计逻辑是：不让医院从零开始，而是在一个已经“见过大世面”的基础模型上做增量适配。技术实现路径分为三层：第一层，基础模型底座。 RuiPath 2.0覆盖19个常见癌种、205项诊断任务，在59项下游任务中42项取得SOTA。这个底座的价值在于它已经学习到了大量通用的病理形态学特征，不需要从零开始“认识”什么是肿瘤、什么是正常组织。第二层，增量训练机制。 医院上传本院特色病例数据，在RuiPath基础上做二次强化学习。平台支持少样本训练，据称仅需传统训练不到10%的数据量即可生成适配本院业务的定制化模型。以邯郸市中心医院为例，该院通过每轮几十张切片的小样本训练，乳腺癌模型的有无肿瘤判别准确率从约95%提升至接近100%，组织学类型达到90%以上。结直肠活检小标本模型的有无肿瘤准确率达到99%。第三层，安全与合规。 数据不出“域”是医疗AI的硬约束。平台采用端云协同混合计算架构，在医院端提取疑似肿瘤区域特征后加密上传，节省85%带宽。云端基于全密态“可用不可见”机制完成诊断推理与模型增训，通过端到端加密、切片脱敏、数据保险箱、模型保险箱等能力保障安全合规。二、端云协同推理：把算力门槛降到消费级PC如果说云上增训解决的是“模型好不好”的问题，端云协同推理解决的是“跑不跑得动”的问题。基层医院部署病理AI最大的障碍是算力。传统院内集中自建模式需要GPU服务器，首年投入动辄数十万。端云协同推理的架构设计是：推理任务在本地GPU或消费级PC上执行，云端只负责模型管理和调度。这个架构的关键技术指标包括：带宽需求降低85%：医院端只上传疑似肿瘤区域的特征向量，不需要传输完整全切片图像；推理速度压缩至秒级：本地PC即可承载推理任务，诊断时间从分钟级压缩到秒级；部署周期约一周：PIS系统集成周期短，无需升级院内网络带宽；成本结构优化：相比传统院内集中自建模式，首年投入可下降90%，五年总成本可降低40%以上。在部署形态上，平台支持云侧和端侧两种推理模式。云侧推理适用于算力需求较高的复杂诊断任务，端侧推理适用于对实时性和数据本地化要求较高的场景。RuiPath 2.0 Edge版本仅200万参数，可部署在医院普通PC设备上，结合云端协同实现分钟级推理，进一步降低基层硬件门槛。三、架构协同效应云上增训和端云协同推理不是两个孤立的技术特性，而是一个闭环系统：云端训练出的模型下沉到端侧推理，端侧推理产生的新数据回流到云端做增训，增训后的模型再下沉到端侧。 这个数据飞轮机制使模型能够随着临床数据的积累而持续进化。从工程角度看，这个架构的巧妙之处在于它把“重”的部分放在云端，把“轻”的部分放在端侧。云端承担模型训练和迭代的算力消耗，端侧只负责推理。医院不需要养一个算法团队，也不需要买GPU集群，只需要一台普通PC和网络连接，就能获得顶级病理AI能力。这对于推动病理AI从三甲医院向县域医院下沉，具有实质性的工程意义。