医械软件大语言模型验证 | 挑战与新兴策略

引言  

自2022年11月ChatGPT问世以来，大语言模型（LLMs）在医疗健康与医疗器械等众多领域展现出巨大的变革潜力。许多器械制造商正探索如何将LLMs整合至产品中，以提供临床辅助、决策支持、患者服务等功能。尽管LLMs作为人工智能的一种形式，为改善临床护理带来了前所未有的技术机遇，但同时也对其质量保证——这一医疗器械的基础要求——提出了诸多全新挑战。  

融合LLMs的医疗器械软件（MDSW）与传统MDSW存在若干本质差异：  

1. 输入输出不再受参数限制。比如传统MDSW的输入（如具有固定灰度值像素的医学图像）与输出（如”恶性/良性”的二元判断）均有明确定义，而LLMs的输入输出采用开放式自然语言形式。对于LLMs的推理，无法对参数化的输入和输出空间进行明确映射，这使得基于明确定义的输入-输出的传统软件测试方法难以适用。  

2. LLMs的算法设计及其支撑硬件中固有的随机性，导致其输出结果具有不确定性。与传统MDSW不同，相同输入不必然产生相同的输出。虽然输出变异通常围绕中心值（很可能是众数）呈局部稳定分布，但仍存在难以预测的离群值。  

3. LLMs是作为基于海量数字数据训练的通用基础模型。其训练数据质量控制不力，难以满足医疗监管要求。当LLMs以”来源未知软件”（SOUP）形式嵌入MDSW时，会带来事实错误、偏见、安全后门等与验证相关的各种风险，可能危及MDSW的安全性。由于模型知识空间的广袤性及训练过程的不透明性，此类SOUP组件的风险控制验证极具挑战。

   本文后续章节将逐一详述上述挑战，并基于现有技术水平（SOTA），为读者提供符合IEC 62304标准、能通过公告机构MDR符合性审核的验证策略建议。

挑战一：无边界输入输出  

与传统MDSW的输入输出空间可明确定义（如胸部X光片为特定维度和位深的矩阵，分类输出为封闭集中选取的标签）——基于LLMs的MDSW的运作以自然语言为基础，其输入输出在语义上均具有开放性。这一根本特性对验证工作产生深远影响。  

经典软件测试依赖于将输入空间划分为等价类、定义边界条件，并针对确定性输出建立通过/失败标准的能力。该框架预设了结构化、可枚举的输入输出关系。而在LLMs推理中，不存在此类结构。提示语言的微小扰动可能导致输出显著分歧，使得稳定的等价类构建难以实现。  

在输出端，故障不再是离散可检测事件：它可能表现为临床相关信息的遗漏、不安全的框架、过度自信的推理或虚构内容。这破坏了IEC 62304标准要求的可测试链，因开放式自然语言输出的要求无法直接映射到二元化测试结论。  

文献中提出了一些缓解策略。输入端需以严格限定的预期用途声明（明确临床场景、用户群体和允许查询类型）作为所有下游验证设计的基础。程序输入护栏可以通过在LLMs推断前筛查用户输入来补充：按主题相关性分类查询、拒绝超出范围的输入，并在提示到达模型前标记异常结构。这有效地将主动输入空间收束至限定操作域，使基于覆盖的测试更易实施。  输出端则通过架构约束（如语法限制解码、模式强制的结构化输出或基于规则的后处理护栏）在内容抵达临床用户前，将输出空间重新参数化为结构化可测试形式，有效地从设计层面重建有边界的验证目标。  

当自由文本输出不可避免时，”分解-验证”流程将生成响应拆分为离散可评估的宣称，每项均需根据预设标准（事实准确性、临床适当性和安全性）进行评估。自然语言处理（NLP）评估矩阵包括BLEU、ROUGE和BERTScore可基于经过精选的真实引用对自由文本输出进行自动化可扩展评估，尽管这些自动化指标与临床效用的相关性本身必须经过实证验证，以符合具体预期用途。互补性策略包括：通过扰动测试探查输入输出一致性而无需全空间枚举；通过语义熵分析标记出统计上更易出错的高不确定性反应。 根据IEC 62304和ISO 14971标准，最稳健的方案是组合应用上述策略，并在风险管理文件中明确声明”无法实现输入输出全覆盖”，同时通过受益-风险分析论证可接受的剩余风险。

挑战二：不确定性输出 

LLMs 中的不确定性源自两个不同且部分独立的来源，二者均直接影响IEC 62304标准下的验证。首先是算法层面：如temperature、top-p、top-k等超参数体现的随机采样策略，通过设计引入概率性的词元选择。通常将temperature值设为零（即贪心解码）被假定可消除这种波动，但越来越多的实证表明该假设在实践中并不可靠。  

“Khatchadourian and Franco（2025年，arXiv:2511.07585）通过量化五类模型架构在金融监管任务中的输出漂移，揭示了模型规模与输出一致性间的明显负相关：70-80亿参数模型在temperature值设为零时能实现100%输出一致性，而1200亿参数模型仅有12.5%的运行中输出一致（95%置信区间：3.5–36.0%），且该现象与配置无关（p < 0.0001）。Atil et al.（2024年，arXiv:2408.04667）同样记录到temperature值设为零下等效运行存在高达15%的准确率波动，且不同任务中最佳与最差性能差距达70%——这些发现共同质疑了”前沿模型更适合在受监管环境下部署”的固有认知。  

第二重非确定性源自计算层面。浮点运算在并行 GPU 执行中的非关联性意味着，由批次构成和硬件调度决定的运算顺序会影响中间激活值，最终改变输出词元概率。这种效应在侧重推理的模型中尤为显著，早期舍入误差会通过延伸的思维链传递。最新研究指出批次规模变化是该现象的主要驱动因素，并提出批次不变内核作为硬件层级的缓解措施（Yuan et al., 2025, arXiv:2506.09501）。

在符合IEC 62304标准的验证过程中，不能通过固定temperature或随机种子来假定消除非确定性因素；必须针对具体模型、部署基础设施和硬件配置进行实证表征。验证方案应包含重复性一致性测试，并针对具有代表性的输入，采用具备统计学依据的样本量开展测试。应用层控制能有效减少漂移现象，其本身也应作为有效缓解手段接受验证。模式约束输出将LLMs的响应限制在预定义结构中。例如采用包含枚举字段名和值类型的JSON对象。由于受限输出空间减少了随机变异可能传播的词元数量，这种架构措施既能显著提升运行间一致性，又能为传统验证重新界定输出空间边界。  在检索增强生成（RAG）架构中，LLMs的响应基于从受控知识库检索的信息，此时传递给模型的检索段落顺序会影响输出结果生成：相同查询可能检索到相同文档，但在多次运行中以不同顺序呈现，从而引入新的变异源。确定性检索排序可以通过在组成提示词前对检索结果施加固定且与内容无关的排序键来实现，消除了这种漂移源，降低了 RAG 流程对不确定性的影响。

挑战三：将LLMs视为SOUP

IEC 62304为管理未知来源软件（SOUP）提供了结构化框架：制造商必须识别所有SOUP组件（第8.1.2节），记录对其功能和性能的要求（第5.3.3节），评估已发布的异常列表（第7.1.3节），并为涉及安全问题的异常建立风险控制（第7.2节），同时将SOUP的变更视为需要记录风险分析的变更事件（第7.4节）。该框架基于一个根本假设：制造商能够明确描述SOUP组件的功能、已知故障模式及其功能边界。而基础模型对这些假设提出了挑战，尤其引发了包括事实不准确、偏见和安全后门等新型风险类别，现有SOUP验证工具包对此准备不足。  

LLMs通过预测统计上可能的词元序列生成输出，而非从经过审核的知识库中检索已验证的事实。这种架构使得幻觉成为固有故障模式，而非可检测的异常。与带有公开异常列表的传统 SOUP 组件不同，基础模型的事实性错误分布在一个有效近乎无限的知识空间中，而模型提供商无法穷举。由于测试空间过大，且故障不会通过明确定义的错误来示警，验证临床无害事实性错误无法简化为传统黑盒测试。系统性评估需要有经过基准真值验证的临床测试集，通过多次采样描述错误输出的分布特征，并进行事实一致性评分。  

此外，基于大规模数字语料训练的基础模型会编码这些语料的统计规律，包括健康相关内容中展现的人口统计、文化和社会经济偏见。基于LLMs的医疗器械软件可能表现出患者亚组间的性能差异，若无针对性分层评估难以察觉。与侠义机器学习分类器中可检查特征空间和决策边界的传统算法偏差不同，大语言模型的偏倚分布在数十亿参数中，无法归因于任何可识别的架构组件。验证需要使用人口分层测试数据集进行前瞻性偏倚评估，理想情况下应与临床专家共同设计，并预设组间性能差异的接受阈值。

在信息安全领域，训练数据投毒构成了一种独特的供应链威胁。攻击者若能将有害内容注入基础模型的训练数据集中，便可植入后门行为。例如模型在常规输入下输出正常结果，但当提示语中出现特定触发模式时，其输出会转向预设的有害方向。由于制造商无法预知触发机制，且中毒行为在常规测试中处于潜伏状态，标准功能验证流程无法检测到。训练数据来源的不透明性进一步加剧了验证难度。因此需要采取多层次风险缓解策略，包括与模型供应商签订训练数据透明度协议、对抗性测试、在生产环节监控输出异常等来解决这个问题。与前两个挑战类似，风险控制措施无法完全消除LLMs SOUP组件引入的安全隐患，风险管理文件中必须明确说明这一事实，并根据ISO 14971标准将剩余风险与器械临床受益进行评估并记录。

值得注意的是，将基础LLMs归类为IEC 62304标准下SOUP具有实践合理性且日益获得认可。但这尚未在SoTA标准或MDCG指南中正式确立。IEC 62304的SOUP框架被设计用于对具有明确定义接口的离散型现成软件组件，在将其应用于具有涌现行为且训练流程不透明的数十亿参数生成模型时，需要审慎调整并充分论证。

小结 

本文探讨了LLMs在医疗器械软件（MDSW）中引发的三大基础性验证挑战：自然语言输入与输出空间的无界限性、输出不确定性的内在与计算根源，以及将基础模型作为IEC 62304标准下SOUP引入的新型安全风险。每一项挑战都动摇了数十年来支撑软件验证实践的基本假设，且目前均未形成完全标准化的监管解决方案。当前SOTA提供了一系列新兴策略组合，包括输入护栏、输出约束、重复运行一致性测试、分层偏倚评估和对抗性测试。这些策略经整合与妥善记录后，可构建出既具备技术合理性，又符合现行监管框架要求的验证方法。  

若您需要制定基于LLMs的医疗器械软件验证策略或符合性审核方面的支持，请立即联系我们！Qserve 拥有丰富的实践经验，支持医疗器械制造商应对 AI/ML 驱动 MDSW 的监管复杂性。从验证策略设计、测试方案制定到风险管理文件准备和临床评价支持，我们可提供针对客户需求量身定制的专业技术咨询服务。期待与您合作！