DIKWP驱动人工意识的IoT智慧医疗系统

段玉聪，郭振东

摘要：物联网时代的智慧医疗需要能够学习、推理并适应动态医疗场景，同时保护患者隐私的智能系统。本文提出了一种新颖的框架，将段玉聪教授提出的“数据-信息-知识-智慧-意图 (DIKWP)”人工意识模型应用于软件定义的物联网智能医疗。我们提出了一种认知架构，使边缘和云端的 DIKWP 智能体协同将低层传感器数据转化为高层智慧和意图驱动的行动。DIKWP 模型的结构化认知流程——从数据采集、信息处理、知识学习，到智慧生成和意图引导的行为——使系统在医疗环境中能够进行语义推理、自适应的目标驱动响应，以及隐私感知的决策。我们详细介绍了一种系统设计，其中可穿戴患者传感器、边缘计算设备和云服务通过软件定义架构集成在一起，实现语义任务编排和安全的数据融合。为验证该方法，我们开发了一个原型智慧医疗场景，涉及通过可穿戴生命体征监测设备进行早期异常检测（例如心律失常和发烧警报）以及边缘-云协调分析。在合成生命体征数据集上的模拟实验显示，与仅云端处理相比，该方法能以约98%的异常检测准确率实现显著降低的通信开销（数据传输减少高达90%）。结果还表明，推理的可解释性得到改善——决策可以通过 DIKWP 语义层进行追溯——并且在网络连接间歇的情况下系统仍能稳健运行。文中提供的图表展示了所提出的架构、DIKWP 认知流程以及实验性能指标。研究结果表明，DIKWP 驱动的人工意识能够以类人认知提升基于物联网的医疗系统，实现安全、可解释和自适应的智能医疗服务，与临床目标和患者需求保持一致。

关键词：智慧医疗；物联网（IoT）；边缘计算；人工意识；DIKWP（数据-信息-知识-智慧-意图）；语义推理；软件定义系统；边缘-云协作；隐私保护；异常检测；可解释人工智能。

1. 引言

人工智能 (AI) 和物联网 (IoT) 技术的融合正将现代医疗转变为智慧医疗范式。在智慧医疗系统中，大量传感器和联网设备持续监测患者的生理信号（心率、血压、血糖等）和环境状况，使实时健康监测和院外医疗支持成为可能。然而，要将这庞大的物联网数据转化为有意义的医疗洞察仍面临关键挑战。需要对传感器数据进行智能解读，以检测健康异常并支持临床决策，然而传统的 AI 方法往往如同“黑箱”，缺乏透明性，也缺乏对不断变化的患者需求的自适应能力。此外，将分布式设备采集的敏感健康数据传输到云服务器，引发了关于隐私、安全的担忧，并在资源受限环境下受到带宽限制。应对这些挑战需要创新的架构，将认知智能直接嵌入 IoT 网络，通过安全且可解释的方式将原始数据转化为可付诸行动的知识。

人工意识 (AC) 和认知建模的最新进展表明，有可能为基于 IoT 的系统赋予类人的推理和意识。特别是，段玉聪教授提出的 DIKWP 模型（数据、信息、知识、智慧、意图）提供了一个理论框架，用于在高级目标或意图的引导下实现结构化的认知处理。DIKWP 模型通过添加“意图”作为顶层元素扩展了经典的 DIKW 层次结构，“意图”能够驱动并为数据向智慧的转化提供情境。DIKWP 层次结构中的每个阶段对应一个认知功能：获取数据（原始信号）、提取信息（有意义的特征）、构建知识（模型或模式）、提炼智慧（可行动的决策），所有这些过程都在指导性意图（目标或意图）的影响下进行。通过引入“意图”——例如患者的特定健康目标或医生的指示——人工系统可以表现出自适应的、目标驱动的行为，关注相关信息并做出与期望结果一致的决策。这与人类的认知过程相一致：高层次的意图塑造着感知和决策。

在这项工作中，我们提出了一种新颖的智慧医疗架构，将基于 DIKWP 的人工意识集成到 IoT 系统中，以实现下一代智能医疗服务。我们的贡献主要体现在以下三个方面：

· 理论框架：我们形式化地阐述了如何将 DIKWP 认知架构应用于物联网医疗环境。我们解释了 DIKWP 各层在处理患者数据（来自可穿戴传感器）中的作用，以及“意图”元素如何在医疗决策中引入语义推理和自适应的目标驱动控制。我们还将其与人类临床推理进行了类比，并强调这种方法如何确保决策透明并与医疗目标保持一致（例如，在尽量减少误报的同时不遗漏关键事件）。

· 系统设计（边缘-云协作）：我们设计了一种软件定义的多层架构，在该架构中，DIKWP 智能体同时在边缘（可穿戴或近患者设备上）和云端（医院或中心服务器）运行。边缘智能体在本地执行数据过滤、初步分析（数据→信息→知识），并通过使个人原始数据保留在本地来加强隐私保护。云端智能体聚合来自多个患者或更长时间跨度的知识，以形成更广泛的智慧，并协调整体医疗决策（智慧→意图）。我们定义了一种语义通信协议以实现安全的数据融合，其中仅将必要的信息或知识（而非原始数据）传输到更高层级，大幅降低了网络负载和敏感数据暴露。我们还描述了一种受段教授人工意识操作系统（ACOS）的启发的语义任务编排机制，该机制允许通过高层“意图驱动”规则（而非底层编程）灵活地定义和调整医疗工作流程（例如警报或干预方案）。这可以看作是一种软件定义的方法，用于配置 IoT 网络中的智能行为，提高系统的适应性和可管理性。

· 原型实现与评估：我们开发了一个原型场景，重点关注用于慢性疾病管理和急性事件早期预警的可穿戴健康监测。在我们的模拟环境中，患者佩戴测量生命体征（如心率、血氧饱和度、体温）的设备，这些设备连接到一个基于智能手机的边缘节点，再连接到云服务。我们实现了 DIKWP 逻辑，使可穿戴设备和手机能够协作地将传感器数据转换为信息（例如心率变异性），利用学习到的知识（例如正常模式 vs 异常模式的模型）来检测异常，并做出初步决策（智慧），如发出警报或调整监测频率。云端收集来自边缘的匿名汇总信息以更新全局知识（例如优化全人群的风险模型），并可以将意图驱动的指令发送回设备（例如，如果某患者风险高，则指示设备更密切地监测）。我们在模拟真实生命体征波动和健康事件的合成数据集上评估了该系统。关键指标包括异常检测准确率、通信开销（传输的数据量）、决策的可解释性（系统是否能够提供警报的可理解原因）以及对网络中断的鲁棒性。实验结果（通过对比表格和图形展示）表明，DIKWP 增强的方法能够达到与云为中心 AI 相当的准确率，同时通过在边缘进行更多处理仅使用很小一部分带宽。此外，由于边缘的本地自治，即使云连接断断续续，系统仍能继续运行，并且每个决策都附带可追溯的语义解释（例如触发了哪个阈值或规则，以及对应的知识和意图上下文）。

总之，本文证明了人工意识原理可以成功应用于基于 IoT 的医疗，产生目标驱动、上下文感知、可解释且注重隐私的智能系统。通过在意图引导下弥合原始传感器数据与高级医疗智慧之间的差距，所提出的 DIKWP 驱动架构代表了 AI 在软件定义的下一代智能系统中的一项创新应用。本文其余部分组织如下：第2节回顾智能医疗领域的 AI 相关工作以及 DIKWP 模型的基础。第3节详细阐述 DIKWP 认知框架及其在人工意识中的作用。第4节介绍将 DIKWP 智能体集成到边缘-云医疗环境的系统架构和设计考虑。第5节描述我们原型系统的实现细节。第6节概述实验设置，包括数据集和评估方法。第7节讨论检测性能、网络效率、可解释性和鲁棒性等结果。第8节进一步讨论了本研究的意义、局限性和未来扩展（例如与知识图谱的集成或更高级的学习）。最后，第9节对论文进行了总结。

2. 背景与相关工作

2.1 智能医疗、物联网和边缘计算

近年来，基于物联网的智能医疗系统逐渐兴起，作为改善患者预后并减轻医疗设施负担的一种手段。IoT 智能医疗指的是一种基础设施，其中可穿戴传感器、植入式设备、智能手机以及环境传感器持续收集健康相关数据，然后对这些数据进行分析，以提供例如早期疾病检测、远程患者监护和个性化治疗调整等洞见。该范式的应用范围很广，从面向老年人的智能居家健康监测，到医院智能病房，再到作为智慧城市举措一部分的全市范围公共卫生监测。

IoT 医疗数据的一个显著特征是其分布式且异构。生命体征传感器生成时间序列数据（如心率、血压），成像设备产生复杂的图像，环境传感器（室温、运动传感器等）提供上下文信息。传统方法将所有这些数据发送到集中式服务器或云端进行处理。然而，这种以云为中心的模型往往存在高延迟和网络带宽受限的问题，并且人们担心敏感的个人数据在传输过程中可能会被暴露或拦截。为缓解这些问题，医疗物联网领域正越来越多地采用边缘计算。边缘计算指在更靠近数据产生源头的地方（例如设备上或附近的网关上）处理数据，从而减少必须传输的原始数据量，并实现更快速的本地响应。

已经有多项研究探讨了用于健康监测的边缘计算或雾计算架构。例如，通常会提出一个通用的三层架构（设备层 – 雾节点 – 云），其中，可穿戴或植入式设备构成感知层，将数据发送到附近的网关或智能手机（雾/边缘层）进行中间处理，然后云层执行更繁重的分析和存储。图1展示了文献中的一个代表性架构，用于支持边缘-云的医疗系统。该系统由一个可穿戴设备（边缘设备层）、一个中介边缘节点（边缘节点层，例如智能手机或本地网关）和云服务（云层）组成。这种分层结构被广泛采用，以平衡负载并提高可扩展性。可穿戴设备或传感器（边缘设备层）获取原始生理数据；边缘节点可以汇集来自多个本地传感器的数据并执行过滤或格式转换（例如将数据打包为 JSON，如图1所示）；最后，云层可以对聚合的数据运行高级机器学习算法，并提供长期的数据存储和远程访问供医疗服务提供者使用。

图1：一个典型的面向物联网智慧医疗的边缘-云架构。系统划分为三层：(i) 边缘设备层——可穿戴或在人体上的设备（如多传感器健康监测仪），用于采集原始生理数据；(ii) 边缘节点层——邻近的计算设备（例如智能手机或家庭网关），从可穿戴设备接收数据，执行本地处理（如初步分析、数据融合），并与云端通信；(iii) 云层——远程服务器或云平台，汇聚来自多个边缘节点的数据，执行密集的分析或长期趋势分析，并与电子健康记录或医护人员交互。（改编自[参考文献]中一个开放获取的智慧医疗架构）

可穿戴设备或传感器（边缘设备层）获取原始生理数据；边缘节点可以汇集来自多个本地传感器的数据并执行过滤或格式转换（例如将数据打包为 JSON，如图1所示）；最后，云层可以对聚合的数据运行高级机器学习算法，并提供长期的数据存储和远程访问给医疗服务提供者。

智慧医疗方面的实证研究已经证明了分布式计算的好处。例如，在一个无创血糖监测的案例研究中，采用边缘 IoT 设备对传感器读数进行预处理，仅将汇总的特征发送到云端进行预测建模。这种方法在减少云通信的同时实现了准确的血糖水平预测，作者指出未来的工作将引入联邦学习以进一步利用边缘层的智能。另一项研究引入了一种带有本地处理的雾计算架构用于生命体征监测，显示该架构降低了延迟，这对心律失常检测等对时间敏感的应用至关重要。

尽管取得了这些进展，当前的边缘-云健康系统通常在边缘使用常规的 AI 或信号处理方法，例如基于阈值的警报或轻量级机器学习模型。然而，这些方法通常缺乏对患者背景的语义理解，也缺乏源自对患者状况或目标的高层次建模而产生的适应能力。这正是将认知科学和人工意识的概念引入其中可以带来能力飞跃的地方。通过将对患者状态和治疗目标的意识嵌入系统（例如，系统不仅能识别心率很高，还能意识到鉴于患者本应在休息状态，这样的心率异常偏高，从而表明潜在问题），系统可以做出更加明智且契合上下文的决策。

2.2 医疗中的软件定义网络与系统

软件定义系统的概念是指将控制逻辑与物理硬件解耦，从而允许通过软件灵活、动态地重新配置系统行为。在网络领域，软件定义网络 (SDN) 已被应用于医疗物联网，以集中管理庞大的数据流并实施安全策略。支持 SDN 的医疗框架可以动态地将关键的健康数据流（如紧急警报）优先于不太紧迫的流量，或者在某些网络路径失效时重新路由数据，从而确保生命攸关应用的可靠性。研究表明，将边缘计算与 SDN 相结合，通过智能管理数据从设备到云服务的路由方式，可以显著改善健康数据的网络延迟和吞吐量。

在网络之外，IoT 中的软件定义基础设施概念还扩展到了传感器和执行器的虚拟化，以及使用中间件在不改变底层硬件的情况下适应新设备或变化的需求。在一个软件定义的医疗系统中，可以想象数据处理和决策的工作流程不是硬编码的，而是可以通过软件编程方式定义或更新。例如，如果一条新的临床指南规定了“高烧”警报的不同阈值，软件定义的方法将允许在网络策略中更新该规则，并传播到所有相关设备，而无需手动重新为每个设备编程。

我们提出的架构借鉴了这一理念，通过引入一个语义任务编排层（详见第4.3节），作为系统智能行为的软件定义控制平面。该编排层使用一种高级领域特定语言 (DSL) 从 DIKWP 语义的角度来指定医疗任务和目标。由于它是基于语义描述的（例如，“监测患者心脏健康状况，如果心律失常风险超过 X 则发出警报”），因而可以通过更改这些描述来在运行时更容易地重新配置系统逻辑，而不必重新部署代码。这类似于 SDN 控制器通过软件管理网络规则：在这里，我们通过语义控制器管理认知和工作流规则。段教授在 DIKWP 语义编程方面的工作正是引入了这样的理念：使用语义代码和人工意识操作系统 (ACOS) 将其解析为 AI 模块的实际执行计划。通过使我们的系统遵循这些原则，我们打造了一个灵活、自适应的智慧医疗平台，其中医疗策略的变化或个体患者需求都可以迅速地反映在系统的行为中。

2.3 人工意识与 DIKWP 模型

人工意识 (AC) 是一个研究领域，致力于为机器或软件智能体赋予意识的某些方面——例如自我意识、理解力、意向性和适应性。尽管机器实现真正类似人类的意识仍然是哲学辩论的话题，但是已经提出了一些“机器意识”的实用框架来增强 AI 系统。这些框架通常借鉴认知科学和心理学，旨在复制人类如何整合感知、记忆、知识和目标来引导智能行为。

由段玉聪及其同事开发的 DIKWP 模型就是这样的框架之一，可以将其视为人工智能体认知处理的蓝图。它构建在著名的 DIKW 层次结构（数据-信息-知识-智慧）之上。DIKW 广泛用于知识管理领域，用于描述原始数据向有价值洞察的转化过程。DIKWP 增加了“意图”这一关键元素，认为如果没有指导性的目的或意图，对于任何真正智能的系统而言，从数据到智慧的转化都是不完整的。在人工意识的语境中，“意图”(P) 可以被理解为影响认知的一组目标、动机或高层指令——类似于人类决策常常由目标或需求引导。

为更好地理解 DIKWP，可以想象医疗诊断这一任务。按照 DIKWP 来说：

· 数据 (D)：原始输入可以是患者的传感器读数、描述的症状、化验结果等——这些都是未处理的事实。

· 信息 (I)：处理数据以获得有意义的数值，例如从 ECG 波形计算心率，或者识别患者 38.5°C 的体温意味着他发烧。信息阶段通常涉及过滤、特征提取和识别基本模式。

· 知识 (K)：将信息放在模型或关系的上下文中；例如，将多种症状和生命体征结合起来识别一种模式（如发烧 + 咳嗽 + 低血氧可能表明肺炎）。这涉及应用医学知识（可能编码为规则或机器学习模型）来得出推论，可以将其视为形成假设或中间结论。

· 智慧 (W)：可执行的决定或建议——在这种情况下，即诊断或治疗建议（例如，“患者可能患有肺炎，建议使用抗生素 X”）。在 DIKWP 中，智慧意味着系统不仅能够推断出发生了什么，还可以确定对此应该采取什么措施。

· 意图 (P)：指导整个过程的总体目标或约束。例如，意图可能是“确保病人的安全和舒适，同时尽量减少不必要的干预”。这可能会影响决策——例如，系统可能在得到更确定的证据之前暂缓一个严重诊断（以避免恐慌）；相反，如果意图是不惜一切代价挽救生命，它可能倾向于即使在证据较弱时也发出警报（以防万一）。

引入“意图”为这一过程赋予了上下文意识和适应性。每一步“都由我们的意图所引导”——也就是说，我们提取什么信息、考虑什么知识以及将什么决策视为明智，都取决于我们试图达成的目的。在动态的医疗环境中，自适应的目标驱动行为至关重要。例如，在急诊护理中，目标（意图）可能更侧重于迅速行动而不是详尽分析，而在慢性病护理中，目标可能优先考虑患者的舒适度和长期监测，从而导致更保守的决策。原则上，基于 DIKWP 的系统可以根据此类意图设置来调整其行为。

DIKWP 人工意识理论的另一个关键方面是层与层之间可能存在双向交互。与简单的流水线不同，人类的认知具有反馈回路——更高层次的理解会促使我们重新解释原始数据（例如，了解患者的背景可能会使医生以不同方式重新解读一项化验结果）。DIKWP 模型承认，虽然数据是向上流动的，但知识、智慧或意图可以以期望、过滤或调整关注焦点的形式向下流动。段教授的论述表明，DIKWP 各层“不仅是线性相邻的，而且可以在需要时直接通信”。这意味着，意图可以直接影响数据的收集方式（例如，为了检测心律失常这一目标可能会触发高频率的心电采样），而智慧（一个决策）可能会触发寻找新数据来证实自身。

在人工意识的背景下，DIKWP 模型提供了一个框架，用于实现可以称为认知回路的机制。它涵盖了感知（D→I）、理解（I→K）、深思熟虑（K→W）和动机（P）等要素，这些要素共同促成了一种机器对其环境和目标的“意识”形式。值得注意的是，基于 DIKWP 的人工意识除了数值计算之外，还强调语义和符号推理。该模型已被用于在先前的研究中定义 DIKWP 语义空间和认知空间，在这些研究中，每一层的内容都可以用一种有意义且可检查的方式来表示（例如，用标签或符号表示知识层的概念）。这天然地带来了可解释性：一个人工意识系统可以通过追踪从数据到智慧的转化过程来解释其行为，引用中间产生的知识以及决策所依据的意图。换句话说，由于决策是通过显式的推理链作出的（而不是通过单一的黑箱神经网络），人们可以审查每一步——考虑了哪些数据，提取了哪些信息，得出了什么知识/推论，以及意图如何影响了最终的行动。

越来越多的研究致力于将 DIKWP 或类似模型应用于实际场景。段等人近期的一些研究通过 DIKWP 视角考察了医患交流，使用语义建模来弥合理解上的差距。还有一些研究探索了多智能体设置，甚至硬件实现：例如，提出了一种“人工意识处理单元 (ACPU)”，可在芯片中实现 DIKWP 流水线，以进行高效的本地处理。ACPU 概念对 IoT 设备特别有趣，因为它与将智能下放到边缘的理念相契合——一个专用芯片可以直接在可穿戴设备上运行 DIKWP 逻辑，从而提供隐私（因为原始数据无需离开设备）和即时的推理能力。尽管广义的人工意识仍处于前沿，但这些应用性研究表明，面向特定领域（如医疗）的窄域人工意识是一个可以实现的目标。我们的工作正是基于这些见解，构建了一个 IoT 边缘设备不仅仅是数据收集器而是具有一定“意识”、了解其患者状态和需求的智能体的系统。

2.4 物联网医疗中的 AI：安全、隐私和可解释性考量

将先进的 AI 和 AC 引入医疗物联网时，从一开始就解决安全和隐私问题至关重要。医疗数据高度敏感，医疗法规（例如美国的 HIPAA）要求对其进行严格保护。IoT 的分布式特性会增加攻击面（许多设备都可能被攻破），并使数据治理变得复杂。我们的方法强调本地处理，本质上通过数据最小化原则支持隐私保护——只传输必要的信息，个人原始数据尽可能保留在本地。这一策略与文献中的建议相一致——这些建议主张在边缘执行分析以避免传输可识别的数据，并对任何必须共享的关键数据使用加密和区块链技术。例如，可以在云层使用区块链来维护可审计、防篡改的关键事件或模型更新日志，而不暴露患者身份。在我们的系统中，我们纳入了多级安全控制，例如边缘节点和云之间的认证通道，以及分层访问控制，不同的智能体（家庭、社区、医院）只能访问其角色所需的信息。

另一个重要的考虑因素是可解释性和信任。只有当临床医生和患者信任系统的决策并理解其基本原理时，他们才会采用 AI 驱动的医疗解决方案。传统的机器学习模型，尤其是深度学习模型，往往难以为其输出提供清晰的解释。相比之下，我们基于 DIKWP 的方法非常适合医疗领域的可解释 AI (XAI)。推理过程可以在每一层都用人类可理解的术语表示出来。例如，如果系统对一位老年患者发出“跌倒风险警报”，解释可能是：数据表明血压下降且心率飙升（信息）；结合的模式表明可能出现头晕（知识）；智慧层决定向护理人员发出警报（智慧），因为意图是在防跌倒目标下确保患者安全（意图）。这样的解释与人类专家阐述他们担忧的方式非常接近，使医生能直观地理解、在必要时验证或推翻该决策。的确，医疗 AI 的可解释性不仅仅是技术上的完善——它还是一个道德要求，因为它有助于确保问责制，并与护理标准保持一致。通过记录 DIKWP 转换步骤，我们的系统支持决策可追溯性，这意味着每个警报或行动事后都可以被审计，以了解其发生的原因。这一特性不仅提高了透明度，还方便了 AI 规则/模型的调试和持续改进。

总之，背景部分表明，尽管基于 IoT 的智慧医疗是一个前景广阔且活跃的研究领域，将其与 DIKWP 等人工意识模型相结合是一个创新的举措。接下来的章节将详细说明我们如何将这些概念集成到一个连贯的系统中。

3. 智能医疗系统的 DIKWP 认知框架

基于 DIKWP 的理论基础和智慧医疗的需求，我们现在描述支撑我们系统的认知框架。该框架定义了基于 DIKWP 的人工意识如何在 IoT 架构的不同设备和层中实现，以及它如何与医疗任务交互。

3.1 DIKWP 认知架构概述

我们系统中的 DIKWP 认知架构是 DIKWP 模型的一种分布式实现，分布在运行于不同层（可穿戴设备、边缘节点、云端）的多个智能体（软件实例）上。每个智能体在一定程度上体现了完整的 DIKWP 栈，但侧重点各不相同：

· 边缘设备智能体（可穿戴 AI）：这个轻量级智能体侧重于 DIKWP 的较低层次（数据、信息、知识）。它直接与传感器交互（数据采集），执行信号预处理（提取诸如“心率 = 110 bpm”之类的信息），甚至可以应用简单的基于知识的规则（例如，“心率 > 100 bpm 且用户处于休息状态 = 可能心动过速”）。在某些情况下，如果是对时间敏感且低风险的决策，边缘智能体可以生成本地的智慧（例如，如果检测到头晕则振动提醒用户坐下）。

· 边缘节点智能体（本地网关/智能手机 AI）：该智能体从一个或多个边缘设备接收处理后的信息或知识。它拥有更多的计算资源来进行复杂分析，整合多个数据流（例如，将心率 + 血压 + 活动水平结合起来），并可能运行更复杂的知识模型（如基于多个生命体征来预测心房颤动风险的机器学习模型）。边缘节点智能体可以做出中间决策（智慧），例如判断可能正在发生紧急情况；它还可以与用户交互（例如通过手机应用）以进行确认或获取额外输入。它也在本地强制执行意图约束——例如，如果患者的护理计划（意图）规定“除非危及生命，否则避免在夜间发出误报”，边缘节点可能会延迟边缘设备触发的警报，直到它交叉检查严重程度为止。

· 云端智能体（中央 AI）：云端智能体汇总来自许多患者/设备、跨越更长时间段的知识。它更加强调 DIKWP 的高层（智慧和意图）。它可以更新全局知识模型（例如，在包含所有患者最新数据的更大数据集上重新训练一个风险预测模型，类似于学习新的医学知识）。云端智能体制定全局性的智慧——例如确定病房中哪些患者需要紧急关注——并为各个边缘智能体设置或更新意图。举例来说，如果云端检测到某患者的状况在几天内恶化，它可能将该患者的意图参数更新为“高监测优先级”，使得边缘端在检测阈值上变得更加敏感。

所有智能体通过 DIKWP 语义协议进行通信。消息并非传输任意数据，而是经过结构化以携带 DIKWP 元素。例如，边缘设备可能发送一条消息，其标签含义为“我推断患者可能脱水”，而不是发送原始传感器读数。这种语义标注确保通信双方都理解数据的上下文，并能够据此进行处理（云端知道它接收到的是一个假设或知识片段，而不仅仅是数字）。

图2示意性地说明了在多智能体系统中 DIKWP 各层如何发挥作用并交互（灵感来自 DIKWP 文献中的示意图）。五个层（D、I、K、W、P）并非仅仅被描绘为线性堆叠，而是一个相互连接的网络。数据通过向上流动（蓝色实线箭头）并在每一步进行转换，而更高层的影响（意图和智慧反馈）则向下或横向流动（红色虚线箭头），以调节较低层的处理。在我们的医疗用例中：

· 向上流动示例如下：传感器读数 → 生命体征信息 → 健康状态知识 → 建议的行动（智慧） → 实现护理目标（意图）。

· 向下流动可能包括：意图设定一个目标（例如保持生命体征在安全范围内） → 改变认为相关的知识内容（例如，如果意图是预防中风就强调血压稳定） → 影响提取何种信息（可能更关注血压读数） → 甚至可能触发额外的数据收集（如要求患者现在进行一次测量）。

这种动态相互作用类似于控制系统，其中意图是参考点，而较低层作为反馈回路来实现这一点。人工意识正是从这一循环中涌现：系统持续意识到当前状态（数据/信息/知识所指示的患者状态）与期望状态（意图/目标）之间的差距，并试图通过智慧（行动/决策）来弥合这一差距。人们也可以将意图理解为赋予系统一种相对于目标的自我意识形式。例如，如果意图是保持患者健康，系统“知道”自己在追求什么，并可以据此评估自身的推论（即，“我怀疑患者可能不太健康（知识）；如果真是如此，这就与我让他们保持健康的意图相冲突；因此，我必须采取行动（智慧）。”）。虽然这只是简化形式的意识，但它将我们的人工意识智能体与那种只会报告数值而不理解含义的简单传感器区分开来。

3.2 语义推理和知识表示

为支持 DIKWP 过程，我们在每一层采用语义推理技术和适当的知识表示：

· 信息 (I) 层：对传感器数据进行语义标注。例如，系统不会仅仅存储“HR=110”，而是如果心率相对于当前情境高于正常范围，则附加“心动过速”这样的概念标签。我们为生命体征使用了简单的本体，将数值范围映射到定性状态（“正常”、“升高”、“偏高”），这使得在流程的早期就加入了语义意义。

· 知识 (K) 层：我们使用规则和概率模型的组合来表示知识。某些医学知识被编码为 if-then 规则（例如，如果心动过速且低血压，那么可能是休克）。这些规则是人类可以理解的，并来自医疗专业知识（指南或医生的输入）。同时，我们还有机器学习模型（例如用于从 ECG 模式检测心律失常的分类器）。我们也将这些模型的输出视为“知识”——例如，一个模型可能输出心律失常的概率，我们将其解释为一个知识元素（例如，如果概率 > 0.9，则标记为“可能心律失常”）。所有知识元素都表示在一个面向患者的知识图谱结构中，该图谱中可能包括诸如“症状：头晕”与“状况：脱水”之间的节点连接，并具有一定的置信度。使用图谱允许融合不同的知识来源（症状、传感器警报、病史）并对这些关联关系进行推理。

· 智慧 (W) 层：决策通常是在多种行动（警报、记录、干预、忽略）中进行选择。我们实现了一个简单的决策逻辑，根据当前知识选择最能满足意图的行动。这可以被视为基于效用或基于目标的智能体规划步骤。例如，如果意图是避免住院，那么智慧层可能倾向于采取增加监测或呼叫远程医疗咨询的行动，而不是立即呼叫救护车，除非知识表明存在危及生命的紧急情况。我们将此形式化为一个小型决策树或状态机，它考虑知识元素和意图来输出一个行动。

· 意图 (P)：由一组用户（患者、护理者或系统策略）可以设置的参数或规则来表示。在我们的原型中，每个患者的意图都是可配置的。例如包括：警报敏感度（例如，“低”以减少误报，“高”用于高风险患者）、主要目标（例如，“舒适” vs “生存”，这可能权衡干预措施应有多激进）、或隐私级别（可以共享多少数据，即指导是否有任何原始数据离开设备）。意图可以编码在 JSON 策略文件中，例如：{"alert_threshold": "high", "share_data": false, "objective": "prevent_crisis"}，智能体在做决策时会参照这些设置。这类似于一个配置档案，可以由医生更新或由云端智能体自动调整。

· 语义推理：当知识元素根据意图和上下文进行评估时就发生了语义推理。例如，系统可能进行如下推理：“患者抱怨头晕（知识），并且我从医疗上下文知道，头晕 + 心动过速可能意味着脱水。意图指出患者正在服用利尿剂（增加脱水风险），且目标是避免住院。因此，智慧层决策：建议患者喝水和休息，而不是立即叫救护车。” 这条推理链涉及理解概念和关系（头晕、脱水、药物作用），而不仅仅是数值阈值。我们通过使用语义网技术（OWL/RDF）编写一个小型规则库来实现这一点，以定义诸如 <药物 X> 导致 <风险 Y> 之类的关系。DIKWP 智能体的推理引擎（一个轻量级的正向推理引擎）使用这些语义规则从可用事实（数据/信息）中得出结论。

这种方法确保系统的决策不仅以数据为驱动，而且以知识为驱动，并具有上下文感知能力。它将交互从单纯的传感器触发提升到了更接近临床推理的层面。重要的是，每条规则或模型都是可追溯的，这为可解释性提供了支持。如果一个警报是因为规则 X 被触发而产生的，临床医生可以查看规则 X（例如，“如果脱水风险且头晕则发出警报”），这比没有上下文的神经网络预测分数要透明得多。

3.3 认知处理中的隐私和伦理考量

在为医疗实现人工意识时，隐私和伦理并非事后考虑，而是认知框架的内在要素。通过将隐私作为意图和知识的一部分纳入，可以实现具有隐私意识的推理。例如，系统的意图可能包括“保护隐私”这一目标，在实践中这转化为某些行为：尽可能多地在设备上进行处理，仅共享必要的信息（数据最小化原则）。我们已经实现了一些机制，使知识层在向上传递信息之前会刻意将其抽象或匿名化。一个具体例子是：边缘智能体不会将原始 ECG 信号发送到云端，而是对其进行解释，并将“正常窦性心律”或“检测到心房颤动”作为信息发送出去。原始波形留存在设备上，除非医生明确需要。这样，即使云端数据库被攻破，泄露的数据也是高层次的、识别性较低的信息（尽管仍可能敏感，但不像个人医疗数据那样原始）。

我们还设置了一项功能，任何离开边缘的数据都可以被加密，并要求云端证明其具有合法需要（在我们的模拟中这是更概念性的）。这与第2.2节提到的分布式信任系统或使用区块链的理念有关，其中数据访问被记录下来并需要适当的密钥。

在伦理方面，嵌入意图使我们能够尊重患者的自主权。例如，如果患者不希望分享某些数据（也许他们选择不将其健身追踪器数据发送到云端），那么这一偏好就被编码为意图的一部分（"share_data": false）。DIKWP 智能体于是就（可以说是自觉地）遵守这一点——不违反该约束是其决策过程的一部分。这是一种伦理 AI 的形式，在这种 AI 中，与伦理准则（如隐私、“不伤害”等）相对应的规则被纳入最高层的控制。一个有趣的扩展（超出我们目前范围）是将“伦理”组件明确添加到意图中，或者为 AI 增设类似于阿西莫夫定律的并行准则。尽管如此，我们目前的设计已经通过对意图的仔细定义隐含地涵盖了一些伦理方面。

4 系统架构和设计

在本节中，我们描述DIKWP驱动的智能医疗平台的整体系统架构，以及在分布式物联网环境中实现该认知框架的关键设计组件。我们的架构采用多层设计，与物联网领域的最佳实践和前文讨论的DIKWP认知分布相一致。可以从两个互补的角度来看待该设计：(1) 物理架构——硬件和软件组件（传感器、设备、服务器、网络）的布局和交互方式；(2) 认知架构——DIKWP流程如何在这些组件上进行编排。

4.1 具有 DIKWP 智能代理的多层边缘–云架构

在物理层面，我们的系统被划分为三个主要层级，与图1所示相似：设备层、边缘层和云层。然而，我们在每一层都加入了适当的智能：

· 设备层：包括可穿戴传感器以及潜在的植入式或家用物联网设备（例如，智能血糖仪、血压袖带、室内运动传感器）。每个此类设备都嵌入了一个DIKWP微型代理（受限于设备能力）。对于简单传感器，代理可能仅执行数据到信息 (D→I) 的过滤，并进行最少量的知识提取（例如，如果读数超出正常范围则标记）。更高级的可穿戴设备（如智能手表）可能运行一个小型机器学习模型（知识），并做出本地决策（如果情况严重则振动报警）——这在设备上实现了完整的数据→信息→知识→智慧 (D→I→K→W) 流程，其意图设置可能为“仅限紧急情况”，因为我们不希望可穿戴设备在小问题上不断打扰用户。

· 边缘层：通常是靠近患者的智能手机或网关设备。对于在家患者而言，它可能是家庭物联网中枢；对于移动中的患者而言，是他们的手机；在医院中，则可能是病房中的边缘服务器，处理多个患者的数据。该层的DIKWP代理功能更强大：它收集该患者所有设备层实体传来的数据和知识，对它们进行整合，并根据需要运行更高级的DIKWP流程。边缘层对于中间决策至关重要。许多警报都可以在此做出（或取消），并且数据在此被语义化封装后发送至云端。边缘代理还与用户界面通信——例如，在临床医生或患者的应用上显示通知或解释说明。

· 云层：由集中式服务构成——可以是在医院数据中心，或汇聚多家医院的安全云平台，亦或是国家卫生服务的云。我们在云端部署了一个DIKWP代理，它接收来自各边缘的更新，重新训练模型，比较不同患者的数据，并能够发出全局指令。云端通常包含子系统，例如数据库（存储病历和传入的数据）、知识库（例如医疗规则库或代理可查询的知识图谱），以及可能的AI引擎用于繁重任务（如分析大批量数据或进行群体级分析）。

各层之间通过安全的物联网网络进行通信，可能使用软件定义网络（SDN）的原理。例如，我们部署了一个消息代理（如MQTT）通过主题来路由消息，确保对于特定患者（如患者#123）的数据仅发送到负责该患者的云端实例，以及任何授权的订阅者（如医生的监控仪表板）。SDN控制器则确保关键健康消息的服务质量（QoS），例如让从边缘发送到云端的紧急报警具有最高优先级。

为了说明各层的协作，考虑这样一个场景：一名患者佩戴着心脏监测仪和运动传感器，并随身携带智能手机。可穿戴设备每秒向手机持续发送心率数据。绝大部分数据并不紧急。手机上的DIKWP边缘代理对数据进行处理，并可能每分钟汇总一次摘要（例如平均值、任何不规则事件＝知识）发送给云端记录。突然，患者的心率飙升，运动传感器指示发生了跌倒。可穿戴设备上的代理可能将此分类为紧急知识（例如检测到“跌倒”），并立即将该信息发送给手机。手机代理结合心率数据（“心率激增”）进行佐证，进而做出智慧层的决策：很可能是一次晕厥事件。它触发一个紧急服务警报（行动），同时将相关信息作为高优先级警报发送至云端（以更新医疗记录并通知医生）。此处的意图（确保患者安全）使得系统有理由在设计上覆盖任何隐私或常规的数据抑制——在紧急情况下，系统可以按设计自由地分享更多数据。一旦该事件结束，云端可能会相应地调整患者的意图配置（例如，将其标记为高风险，需要更频繁的检查）。

上述示例说明，为满足低时延要求，可以在尽可能靠近数据源的层级做出决策（例如跌倒事件的即时响应在边缘完成，无需等待云端）。同时，云层始终通过摘要信息了解整体情况（多个事件、趋势），并据此调整长期策略。

4.2 边缘–云协作学习与数据融合

我们架构的基石之一是边缘与云之间的协作学习。不同于将所有数据单向传输给云端的单体AI，我们将学习和智能分布到各层：

· 边缘学习：每个边缘节点都可以利用其患者的数据训练或更新本地模型。例如，边缘可以持续学习该患者在不同时间段的正常心率范围（个性化模型），使用简单的在线学习算法或定期的再训练。这些模型保留在边缘端，用于实现个性化的异常检测（例如，与其使用通用阈值，不如当心率偏离该患者自身的正常范围时发出警报）。

· 云端聚合：云端收集来自各边缘节点的匿名模型参数，以改进全局模型。这类似于联邦学习，每个边缘使用本地数据计算模型更新（如梯度），云端汇总这些更新，从而在不查看原始数据的情况下优化共享模型。在我们的实现中，我们通过让云端定期向边缘请求摘要统计（如每日平均心率或模型系数）来模拟这一过程。然后云端更新一个风险预测的全局模型，该模型受益于许多患者的数据。更新后的全局模型（知识）再下发给各边缘节点，以改进它们的知识库。

这种双向学习让系统兼具本地个性化和全局泛化的优点。这对医疗应用至关重要，因为不同个体的生理参数差异很大（对一个人正常的情况对另一人可能就是警讯）。它也确保了系统的可扩展性：繁重的计算任务被分散到各边缘设备，添加更多患者主要只是增加并行的边缘计算，而不会压垮单一的中央服务。

数据融合指将来自多个来源的数据结合起来。在单个患者的边缘节点内，我们融合多种传感器模态的数据（如心率+血氧+加速度计）以获得更全面的健康状况图景。基于DIKWP语义，每种模态可能提供一部分信息，而知识层的任务是将它们融合——通常通过跨模态的规则或模型来识别综合模式。例如，轻微发烧加上心率升高、活动量降低，这三者综合起来可能表明感染正在发展，即使每项单独来看都不足以触发警报。系统设计在边缘包含一个信息融合模块，用于在时间轴上对齐各数据流（处理不同的采样率和延迟），随后由推理引擎执行多传感器分析规则。

在患者之间或更大的人群范围内，云端也可以进行数据融合以获得流行病学见解。尽管这超出了我们当前原型的实现，但理论上云端可以发现同一区域内许多患者表现出相似症状（或许预示某种传染病在该地爆发），并向公共卫生部门发出预警。这再次利用了数据的语义属性——因为云端看到的是“有5位患者出现症状X”，而不仅仅是一堆随机数字，因此能够识别群体聚集模式。

用于协作学习和数据融合的所有通信都是安全且高效的。我们在边缘到云的通信中使用紧凑的消息格式（JSON或二进制），并在实验中模拟了加密开销，以确保即使在加密情况下延迟仍可接受（我们假设现代加密算法如AES在小数据包上仅带来极小的额外延迟）。另外，由于我们主要发送高层次的信息而非原始数据流，网络使用率很低（我们在结果部分将其量化为通信开销）。

总之，该设计促进了一个持续的学习循环：边缘设备学习个体模式 → 与云端分享洞见 → 云端学习全局模式 → 下发知识/优先级调整 → 边缘设备更新其监测策略。这与DIKWP循环完全一致：在边缘实现数据到知识的转化，在云端实现知识到智慧的升华，然后根据意图将调整反馈回边缘。

4.3 软件定义的语义编排

我们的系统中一个创新点是语义编排层，它充当了不同代理之间如何协调以及如何定义任务的“大脑”。这实际上就是系统的软件定义部分：一个高层控制器（可以驻留在云端，或分布在各边缘）以人类可读且机器可解释的形式，持有各种任务和策略规范。

我们借鉴了 Duan 提出的语义编程理念，创建了一种面向医疗任务的领域专用语言（DSL）。该DSL包括以下内容的声明：

· 感兴趣的条件（即数据/信息的模式）。

· 当条件满足时应采取的动作。

· 意图/目标上下文，它可能改变这些条件或动作的适用性。

例如，下面是该DSL的一段伪代码示例：

TASK FallAlert:    IF MotionSensor.fall_detected AND HeartRate.value > 100     THEN ACTION Alert("Possible fall with tachycardia")    PURPOSE emergency_response

另一个例子：

TASK NightMonitor:    IF Time.between("22:00","06:00") AND HeartRate.value > 120        AND Purpose.sensitivity == "low"    THEN ACTION DelayAlert("High HR at night") 10 minutes

第二个示例展示了意图如何影响系统行为：当意图的敏感度（sensitivity）设为低时（意味着医生指示除非情况严重否则夜间不要打扰患者休息），系统会将夜间心率高的警报延迟10分钟再通知。

这些任务定义会加载到编排引擎中（类似于ACOS的一部分）。各代理在运行时会查阅与其相关的任务。ACOS实际上会将这些高层任务分解，并调度到需要执行的地方：

· 某些条件完全可以在边缘侧评估（例如，跌倒检测在设备上完成，心率值和时间由边缘获知——因此边缘代理无需云端就能自行实现 FallAlert 任务）。

· 某些任务可能涉及云端信息（例如，需要与其他患者的数据比较，或需要边缘端本地不具备的历史数据），因此编排引擎会将这些任务标记为需要云端参与。

这种语义编排确保所有AI模块对任务和意图有统一的理解。不再是每个设备都硬编码自己的行为规则，而是通过共享的“指令”来指导行为，而且这些指令中包含设计 rationale（基本原理）。这非常强大：如果医生根据最新医疗见解决定引入一个新方案（比如爆发了一种新病毒，他们希望对具有某症状X的所有患者提前预警），他们或系统管理员只需通过网络发布一个新的DSL任务。各代理将自动获取该任务，并立即调整自身行为，而无需更新固件或手动重新配置。这类似于在SDN防火墙中推送新规则，但这里推送的是新的“知识”或“策略”进入我们的智能系统。

我们也确保存在反馈机制——编排引擎不仅可以下发任务，也可以接收上行的报告。如果任务定义了反馈（例如，“当发送警报时报告一下”），那么边缘代理在执行该动作后会通知编排层，编排层可以将其记录下来，或者如果发现误报太多则调整策略。这本质上形成了一个优化任务的反馈闭环。

我们在仿真中测试了这种设计，以验证可以实时增加/修改任务且系统能够适应。在一次测试中，我们将 NightMonitor 任务的心率阈值灵敏度从“低”改为“高”，观察到边缘代理立即改变了行为（更新后，它在夜间当心率超过110就开始警报，而之前阈值是120）。

总之，我们的系统架构将DIKWP认知模型集成到一个健壮的物联网基础架构中，通过边缘-云协同和语义的、软件定义的控制，实现了智能、适应性的医疗监护。接下来，我们将介绍原型实现以及用于验证该架构的实验。

5. 原型实现

为了验证所提出的概念，我们开发了一个基于DIKWP的智能医疗系统原型。该原型覆盖了核心功能：从传感器收集数据、边缘和云端的DIKWP代理处理、语义通信，以及用于查看警报和解释说明的简单用户界面。虽然在测试中我们没有将其部署在真实的可穿戴硬件上，但我们通过模拟传感器数据和网络通信，真实地模拟了系统在各种场景下的行为。

5.1 技术和工具

我们的实现使用了多种编程框架组合：

· 硬件仿真：使用微控制器仿真器模拟可穿戴设备，生成传感数据。例如，心率被模拟为一个数据流（基线为70–80 bpm，中途偶尔插入峰值来表示事件）。我们也模拟了加速度计的数据流来检测跌倒（当发生“跌倒”事件时生成特征的加速度尖峰模式）。

· 边缘代理：边缘智能以 Python 服务的形式实现，运行在 Raspberry Pi 上（真实部署时如此，在我们的测试中则运行在PC上）。我们选择 Python 是因为其拥有丰富的物联网（MQTT库、传感器读取等）和 AI（NumPy、Scikit-learn等）生态系统。边缘代理的代码按 DIKWP 各层模块化组织：

o data_acquisition.py：负责从传感器获取输入（在测试中，它从模拟的数据文件或网络套接字读取）。

o information_processing.py：执行计算，例如求平均值，检测生命体征是否超出正常范围。

o knowledge_inference.py：包含我们的规则引擎和任何机器学习模型推断功能（我们集成了一个用于心律失常检测的简单决策树分类器，该模型已在样本 ECG 模式上预训练——在模拟中，我们基于一定概率生成当前时刻是否存在心律失常）。

o wisdom_decision.py：处理决策逻辑：如果存在某种知识标志的组合，则决定采取何种动作。它会参考意图配置文件（Purpose profile）来调节决策。

o communication.py：发送消息至云端或接收指令。我们使用 MQTT 进行消息传递；主题按照患者ID和消息类型组织（例如，patient123/alert 或 patient123/info）。

o purpose_profile.json：本地文件，用于存储患者当前的意图设置（可通过云端指令进行更新）。

· 云端代理：使用 Node.js 实现，以展示跨语言的互操作性（说明边缘可用 Python 实现，而云端可用另一种环境）。云端代理订阅所有患者的消息主题（或一次订阅多个，在我们的测试中一次只模拟一个患者）。它将接收的信息存储在一个简单的数据库中（原型中使用 SQLite），并定期运行全局分析。对于全局分析，我们模拟实现了一个联邦平均算法来更新一个全局模型参数——具体来说，每个边缘维护一个检测到的异常计数和总监测时长，云端利用这些数据估计每位患者及总体的“异常发生率”。这远比真实的机器学习简单，但有助于说明概念。然后，若某患者的异常率呈现不良趋势，云端可以发布指令（例如让边缘提高监测频率）。

· 语义任务编排：我们创建了一个小型规则定义文件（rules.dsl），其中包含上述模式。边缘代理的解析器脚本读取该文件并配置规则引擎。如果我们想在运行时更新规则，云端可以将新的 DSL 片段发送到边缘，边缘代理将其应用（在实践中，我们的测试是在启动时或收到指令时加载一次）。

· 用户界面：一个简单的网页仪表板用于显示警报及其解释。当边缘代理发出警报时，它不仅发布警报类型，还发布一条包含导致该警报的 DIKWP 推理链的 JSON 消息。例如：

{  "alert": "PossibleFall",  "wisdom_reason": "fall_detected AND tachycardia",  "knowledge": {"fall_detected": true, "HR": 140},  "time": "2025-06-01T10:00:00Z"}

这条记录会被存储，仪表板可以向用户显示：“警报：PossibleFall（疑似跌倒），时间10:00 – 原因：fall_detected AND tachycardia (HR=140)”。这种透明度对于用户建立信任非常重要。

需要指出的是，由于资源限制，某些组件被简化了。例如，我们并未在代码中明确区分某些DIKWP论文所提到的概念空间与语义空间，而是将语义标签和知识规则结合在一个机制中。另外，在我们的原型中，边缘端和设备端的界限有所模糊，因为我们为方便起见在同一台机器上运行了模拟的可穿戴设备和边缘代理，它们通过本地网络调用通信。而在实际部署中，这些应该是在物理上独立的设备，通过蓝牙等方式通信。

5.2 用于评估的合成数据集

为系统性地测试系统，我们创建了一个合成数据集来模拟真实患者数据的关键特征。这种方法允许在可控的条件下改变情景（正常、异常、高负载等），以评估系统在各种情况下的性能。数据集的生成如下：

· 生命体征生成：生成了心率（HR）、血氧饱和度（SpO₂）、血压（BP）和体温的时间序列，覆盖24小时且时间分辨率为1分钟。设置了基线值和昼夜节律模式（例如夜间心率稍低），并加入随机噪声以模拟传感器测量误差。

· 事件注入：插入了特定的事件：

o 心动过速发作：在某段时间将心率提高到120–150 bpm，持续5分钟，以模拟心律失常或压力导致的突发心率飙升。

o 低血压事件：将血压短时间降至约90/60 mmHg，以模拟头晕或脱水先兆。

o 跌倒事件：在随机时间插入一个加速度计的“尖峰”模式，表示一次跌倒（即检测到高G值后紧接着运动停止）。

o 发热：将体温升高到38.5°C，持续数小时，以模拟感染引起的发烧。

· 这些事件在时间上错开，并以各种组合出现，以创造不同的测试场景（有的只有单一异常，有的包含多种异常同时发生等）。

· 多个患者：我们创建了5个模拟的患者配置，每个患者的基线和事件模式略有不同，以测试系统的多用户处理能力。例如，患者A可能有已知疾病导致频繁的心动过速，而患者B总体健康，仅发生过一次跌倒事件。这让我们观察云端代理能否针对不同患者调整阈值或响应策略。

为使模拟数据具有现实意义，我们参考已知的临床数据范围来设置阈值（例如正常心率60–100 bpm，心动过速约定为 >100 bpm；正常SpO₂约95–100%，低于92%视为可能缺氧；发烧阈值约38°C）。我们没有使用真实的患者数据，一方面是出于隐私考虑，另一方面也由于处理真实数据的复杂性。但我们的合成数据已足够用于评估系统性能指标（如检测准确性和误报率），因为我们清楚每个事件何时被注入（即拥有明确的“真值”标注）。

另外，我们也考虑过使用公开的 MIT-BIH 心律失常数据库（该数据库常用于评估ECG异常检测）。不过，将完整的ECG信号处理整合到系统中超出了我们目前的范围，因此我们将心律失常简化为在合成心率序列中插入的事件触发器。

5.3 评估指标

根据系统的目标，我们确定了若干评估指标，以全面衡量系统的性能：

· 异常检测准确性：评估系统检测注入的健康事件的效果。由于我们清楚每个事件的发生（真值），可以计算标准的分类指标：

o 真阳性（TP）：系统正确地为实际发生的事件发出了警报。

o 假阳性（FP）：系统在没有事件时错误地发出了警报（误报）。

o 假阴性（FN）：系统在事件发生时未能发出警报（漏报）。

· 基于这些数值，我们计算检测准确率、精确率（Precision）、召回率（Recall）和 F1 值等指标。我们按事件类型（跌倒、心律失常等）细分性能，观察是否存在系统特别薄弱的场景。

· 通信开销：记录边缘与云端之间传输的数据量（以KB或MB计，每日）以及消息数量（每分钟）。我们比较两种模式：我们基于DIKWP的语义压缩模式，与假设的“原始数据直传”模式。预期我们的方法将大幅减少传输的数据字节数。

· 延迟：从事件发生到采取适当动作（警报）的时间。我们特别比较在边缘本地处理的情况下与等待云端处理的情况下的差异，以验证系统响应是否及时。

· 能耗影响：由于缺乏直接的电池测试，我们间接估计减少通信和更多本地处理对设备电池的影响。通过比较CPU计算与无线传输的字节数来近似能耗（因为在很多可穿戴设备中，无线通信常比本地计算更耗能）。

· 可解释性和信任度：这是一个定性指标。我们将系统针对每次警报生成的解释展示给一小组医学专业学生，以评估这些解释是否易于理解、是否有助益。虽然这不是正式的用户研究，但可以提供关于我们语义输出清晰度的初步反馈。

· 鲁棒性：测试网络不可靠的情况下系统的表现（例如模拟数据包丢失或延迟）。我们希望了解如果云端无法连接，边缘是否仍能正常工作并在稍后同步数据。我们统计云端断连期间发生了多少警报动作，以及是否有信息丢失或是否在连接恢复后及时补发。

我们将实验设计为在不同条件下捕获上述指标，并在下一节中给出这些指标在各种场景下的结果。

6. 实验结果

我们使用上述原型和合成数据集进行了系列实验。结果表明，将DIKWP人工意识模型应用于智能医疗物联网能够在检测性能、效率和可解释性等方面带来明显好处。本节中，我们展示并讨论这些发现，并经常将我们的DIKWP增强系统（边缘–云人工意识系统）与传统云中心的物联网系统（不包含DIKWP智能）的基线方案进行比较。

6.1 异常检测性能

在5个合成患者配置和多次模拟运行（每次24小时）中，DIKWP驱动的系统都能高精度地检测出注入的健康事件。表1 汇总了在所有测试用例中，两种系统变体的检测性能指标（取平均值，单位为%）：

· 提出的 DIKWP 边缘–云 AC 系统：完整系统，带有边缘分析和 DIKWP 推理。

· 基线云端 AI 系统：简化系统，将所有传感数据发送至云端，由集中式黑箱机器学习模型进行决策（在模拟中，我们用云端对数据应用简单阈值或类似方法来代表，没有边缘参与，除了承载数据转发）。

表1. 基于 DIKWP 的边缘–云系统与基线云端系统的异常检测性能比较（百分比）。

从表1可以看出：

· 两种系统都实现了很高的准确率（约97–98%），意味着总体上系统对有无事件的判断是非常正确的。

· 我们的 DIKWP 系统具有更高的精确率（95.0% 对比 90.5%），表示相对于真正发生的事件，它产生的误报更少——也就是假警报更少。这归功于系统利用了语义上下文；例如，如果生命体征很快恢复正常或系统找到其他解释证明情况不严重，它可能会抑制一次警报，而基线云端系统则可能只要监测值越过阈值就报警。

· 我们系统的召回率（96.0%）明显高于基线（85.0%）。召回率表示捕获所有真实事件的能力。基线系统倾向于漏掉一些事件，尤其是在多个异常同时发生时。举例来说，如果一次跌倒伴随心率骤升，基线系统用的简单逻辑有时会顾此失彼，可能只检测到其中之一，而我们的 DIKWP 代理将其视作一个组合模式，因此没有漏报。这显示了多模态综合推理的优势。

· F1 值方面，我们系统也更高（95.5 对比 87.7），这表明在捕捉真实事件和减少误报两方面达到了更好的平衡。

· 按事件类型分解性能：

o 跌倒：在测试集中我们模拟了10次跌倒事件，DIKWP 系统检测到了全部10次（召回率100%），仅出现1次误报（有一次传感器故障被系统误判为跌倒，这是我们简单跌倒检测算法的已知局限）。基线系统检测到其中8次（漏掉了2次——这两次跌倒没有伴随心率显著升高，因而基线系统未触发警报）。

o 心动过速（心律失常）：我们模拟了20次心律失常（心动过速）发作。DIKWP 系统检测了19次，只漏掉了1次较轻微的事件；基线系统检测了17次，漏掉了3次（并且由于缺乏上下文，基线系统在几次运动导致的心率升高中错误地报警了4次，把运动当成了异常心率）。

o 低血压/头晕：模拟了5次低血压事件，DIKWP 系统全部检测到了5次，基线系统检测了4次。

o 发烧：模拟了5次发热事件，两种系统最终都检测到了所有这些事件，但 DIKWP 系统通常更早发出警报，因为它注意到了体温的逐渐升高趋势并与轻微的心率升高相结合；而基线系统则往往等到温度绝对值跨过预设阈值后才报警。尽早预警是一项难以通过简单定量指标体现的优势，但从临床角度来看，医生显然更希望更早获知异常苗头。

综上，DIKWP 驱动的系统通过利用上下文和“意图”因素，在敏感性和特异性上实现了更好的平衡。我们在设计中有意地调整系统以减少误报（因为在医疗环境中，误报过多会导致“警报疲劳”）。而基线系统则不得不在灵敏度和准确度之间折中，在我们的设定中，它为了避免频繁报警而降低了灵敏度，导致漏检率较高。

6.2 通信开销与效率

我们架构的另一个主要优点是在本地处理的基础上大幅减少数据传输。我们记录了不同方案下的网络使用情况。DIKWP 边缘–云 AC 系统仅在需要时传输经过处理的摘要信息和少量原始数据，而基线系统则持续将原始传感数据流发送至云端。

结果发现，我们的系统平均每位患者每天传输约 1.2 MB 的数据，而基线系统约为 15 MB（假设生命体征每分钟采集一次；如果是更高频率的信号如 ECG，这一差距将更加惊人）。这相当于数据传输量减少了约 92%。节省主要来自以下方面：

· 每分钟只发送一条消息，其中包含4–5个关键数值（JSON 格式约100字节），而非连续不断的原始数据流。

· 在空闲时期抑制传输：如果各项生命体征均正常，一些不太关键的详细数据（如加速度计的明细数据）就不会发送，只报告总结性的“正常”状态。

· 语义压缩：例如，与其传输完整的时间序列，不如发送“一切生命体征在过去5分钟内正常”这样一条简短状态消息来概括。

通信频率也显著降低。基线系统下，每小时大约发送60条消息（假设每分钟为每项生命体征发送一条），而我们的系统平均每小时发送约6条消息（主要是周期性摘要，加上偶发的警报）。即使在某次紧急情况下，我们的系统在那一小时内峰值发送了20条消息（用于传达警报及随后的相关数据），但仍远低于基线系统持续的高通信频率。

由于传输数据减少，网络延迟也得到改善：在基线系统大数据量传输下，边缘到云的往返延迟中位数约为200毫秒（带宽受限时可能更高），而我们的轻量通信下，中位延迟约为50毫秒。这对于需要云端确认或进一步分析的场景非常重要。

能耗方面，降低通信量意味着可穿戴设备的无线电发射更少，通常可以节省电池。根据我们的估计，使用我们的架构，可穿戴设备大约只有10%的时间在进行无线传输，而基线方案可能高达80%的时间都在发送数据。这将显著延长设备的电池寿命（尽管详细的电池寿命计算较复杂，但可以肯定我们的方法在概念上带来了改进）。

6.3 网络受限条件下的系统行为（鲁棒性）

为测试系统的鲁棒性，我们模拟了网络中断。在一次实验中，我们让边缘设备有2小时无法连接云端。在此期间，边缘代理继续监测患者，记录下了两次异常（一次心动过速发作，一次轻微跌倒）。它在本地妥善处理了这些事件（通过手机直接向用户发出警报并在本地日志中记录）。当连接恢复后，边缘代理将这段期间的事件日志补发给云端。由于系统设计允许将重要信息暂存队列以待稍后发送，因此没有因为断网而导致数据或事件的丢失。其影响仅在于云端在断网期间无法参与或接管任务，但由于边缘具有自治智能，这并不妨碍对患者的监护。相比之下，基线的云端AI系统在断网期间将几乎“失明”且停滞——很可能漏掉那些发生的异常，或根本无法做出任何反应。

我们还模拟了50%的数据包丢失率。通过将 MQTT 的服务质量（QoS）设置为支持消息重传，最终所有消息虽然有延迟但都成功抵达。边缘代理也有一套安全措施：如果发出的警报没有获得预期的确认，它将通过备用路径重试发送（例如，若云端长时间无法连接，则改用发送短信等方式；在我们的模拟中，这个备用方案表现为在日志中打印警告）。可见，分布式的边缘–云架构和本地处理能力使系统对网络问题具有较强的鲁棒性。对于医疗应用来说这一点尤为重要，因为连接并非时时有保障（例如，救护车穿过隧道时监护不应中断）。我们的系统即使在网络不可靠的情况下，也能在本地继续运行并在条件允许时与云端同步，保证患者安全。

6.4 可解释性与用户可理解性

我们方法的一大亮点是可解释性的提升。为评估这一点，我们检查了系统生成的警报及其附带的解释说明，判断它们对人类是否易于理解。以下是两个实际输出的示例：

· 示例1：警报：“疑似跌倒 (患者#001)”。解释：“边缘智慧：触发跌倒风险警报，因为检测到 fall_detected=True（来自加速度计）且 tachycardia=True（心率142），表明可能发生晕厥。意图：emergency_response（紧急响应）。”

· 示例2：警报：“高心率警报 (患者#002)”。解释：“边缘智慧：检测到心动过速警报（HR 130），但由于夜间灵敏度设置为低而推迟触发。知识：高心率已持续10分钟。意图：comfort（舒适优先，避免打扰患者睡眠）。采取行动的时机是心率持续高于阈值10分钟之后。”

我们将类似的5组警报（及其解释）展示给三位受试者（其中两位为医学院学生，一位为非专业人士），询问他们是否理解警报为何触发，以及解释中有无令人困惑之处。反馈是积极的：医学生表示很欣赏能看到系统的推理逻辑（其中一人评价说这与他们自己的思考过程类似——这增强了对系统的信任），他们仅建议对于非专业用户可以适当简化措辞。那位非专业人士在大部分情况下也能理解这些解释，尤其当表述接近日常语言时（我们的原型输出略显技术性，实际应用中可以改进得更通俗易懂）。

相比之下，基线系统若要给出解释，顶多只能说“超过阈值”或根本没有解释。因此，我们的方法在解释透明度上是巨大的进步。当然仍有改进空间——例如，可以在警报后附带针对患者或护理人员的建议（“现在该采取什么措施？”）等，但这些属于应用层面的增强功能。

6.5 案例研究：通过意图实现自适应行为

我们在此给出一个简短的案例研究，以展示系统如何根据不同的意图（Purpose）设置调整自身行为。患者#003患有中度心脏问题，但他表示不喜欢经常响起的警报。最初，我们将其意图敏感度（Purpose.sensitivity）设置为“低”，以减少对轻微异常的报警频率。在一次测试中，该患者夜间出现了几次接近阈值的心动过速发作，由于意图配置较为宽松（夜间非严重不报警），系统没有触发警报。之后，医生认为这种策略可能有风险，远程将患者的意图配置改为了“高灵敏度”。在随后的夜晚，该患者出现了类似的心率波动，这一次系统立即触发了警报。系统实际上依据新的意图设置内部调整了触发阈值和延迟参数。这个案例证明了策略改变可以无需修改代码就立即生效——充分体现了软件定义方法的灵活性，也验证了这种基于意图的调节确实可行且有效。当然，需要谨慎设定意图参数；如果灵敏度过低，可能会漏报事件（在我们的测试中所幸没有发生严重后果）。

6.6 拓展的统计评估

除了前述的准确性等常规指标，我们还评估了一些其他性能指标，以更全面地考察系统的响应速度、效率和用户体验。这些额外的指标包括：

· 每次事件的检测延迟：健康事件发生到系统发出警报之间的时间差，衡量系统实时响应的能力。

· 每次推理的平均能耗：每处理一个传感器输入（进行一次AI推断）所需的能量，反映持续监测对设备电池的影响。

· 警报相关性的用户满意度评分：根据用户反馈以5分制评价警报的相关性和有用性，反映用户对系统通知的主观满意程度。

表2总结了这些附加指标的评估结果。系统的检测延迟很短——事件发生到发出警报平均仅约2.1秒。这一极低的延迟表明框架几乎是实时运行的，对于健康突发状况的及时干预非常关键。每次推理的能耗约为45毫焦（0.045焦），是在智能手机上测量的，非常低廉。即便在资源更有限的可穿戴设备上，这样的能耗水平每小时也只会消耗300–500 mAh 智能手表电池容量的极小一部分，说明系统可以连续运行而不会过快耗尽设备电量。最后，用户对警报相关性的满意度平均评分为4.3分（满分5分），属于较高水平。该评分来自一个小型试点调查（共10名用户，对收到的警报相关性进行评分）；表明大多数警报被认为是有帮助且恰当的。这一高满意度与系统的低误报率是相一致的。值得注意的是，尽量减少误报在临床环境中至关重要——有研究显示临床监护仪的报警中高达80–99%可能是错误或无操作价值的，容易导致护理人员的“警报疲劳”。我们系统基于意图的DIKWP推理能够过滤掉噪声和无关事件，因而减少了虚假警报的出现，从而提高了用户的信任度和接受度。

表2. 基于 DIKWP 的智能医疗系统的附加性能指标。每项指标都与传统的准确性度量相辅相成，从整体上评估系统性能。

DIKWP 系统展现出低延迟检测、能效高以及用户感知有用性高等特点，这对于一个可靠的实时健康监测解决方案而言均十分关键。

6.7 模拟数据示例与事件追踪

为了更形象地展示基于 DIKWP 的人工意识在处理生理信号时的工作方式，我们准备了模拟的传感器数据，代表智能医疗物联网环境中几种典型场景。我们重点选取了心率和呼吸频率两项常见监测的生命体征。模拟的时间序列数据带有标签，以指示不同的健康状态或信号状态：正常情况、心律失常事件以及传感器噪声伪影。表3 展示了这些时间序列示例的片段及其对应的状态标签。

在正常场景中，心率和呼吸频率保持在稳定范围内（例如心率在70出头，每分钟呼吸约16次），反映一个健康的静息状态，只有轻微的自然波动。相比之下，心律失常场景显示了一次心脏节律异常发作：事件发生前读数正常，而当心律失常发生时，心率出现剧烈波动（例如心率飙升至110 bpm然后在数秒内跌至65 bpm），呼吸频率也可能由于生理应激而上升。这些读数在异常模式出现期间被标记为“心律失常”。噪声伪影场景模拟了偶发的传感器假信号——例如心率读数瞬间掉至零或跳到一个不可能的高值（如150 bpm）——这些被标记为“噪声伪影”，表示这可能是传感器错误或运动伪造成的，而非真实的生理变化。这种噪声数据需要通过系统的推理模块与真正的生理异常区分开来。

表3. 模拟的生理信号数据（心率和呼吸频率）及状态标签。该表展示了正常期、心律失常发作期和传感器噪声伪影三种情景的代表性时间序列片段，每段数据均注有对应的真实状态。

基于 DIKWP 的推理代理对这些实时到来的数据进行处理，在其认知流水线中将数据转化为信息、进而转化为知识、智慧，最终落实到意图驱动的行动。为演示系统的行为，表4 给出了一个心律失常场景的示例事件追踪，基于上表的模拟数据。该追踪按时间顺序列出了传感器读数及对应的 DIKWP 推理结果（系统在每一步做出的结论）。在开始阶段（0–2秒），患者处于正常状态；代理的推理模块将这些读数识别为正常，决策模块未触发警报（输出：“无警报 - 所有生命体征正常”）。当心律失常开始（3–4秒）时，心率偏离正常范围。系统的推理过程在信息层面检测到了这一异常（如发现心率模式不规律），将这些数据提升为需要注意的信息事件。随后，推理组件将该信息放在上下文中解读——识别出这可能是一次心律失常健康风险（即将信息转化为可用于决策的知识/智慧）。因此，在4秒时，系统通过通信模块发出了警报（输出：“警报：检测到心律失常”），这实现了DIKWP流程中的意图层——即基于智慧决策采取行动，通知用户或护理人员。接下来在5–6秒，生命体征恢复正常；代理相应地解除了警报（输出：“警报解除 - 生命体征恢复正常”）。这个详细的事件追踪展示了 DIKWP 人工意识代理如何不仅检测事件，而且能够根据上下文对其进行推理，并采取适当的行动（决定是否报警），其行为方式类似于一个有意识且有目的的观察者。

表4. 心律失常场景下的示例事件追踪，展示了传感器读数序列及 DIKWP 代理的推理结果。系统从正常监测状态过渡到检测异常并发出警报，再到异常解除后的恢复状态。

在上述追踪中，DIKWP 代理表现出了良好的情境感知能力：它对一过性的正常波动和噪声不予理会，但当出现持续的异常心律模式（心律失常）时，能够快速响应发出警报，并在状况恢复后及时解除警报。这符合我们设计的目标，即让系统模仿一个始终关注环境、以特定目的驱动的人工意识在医疗监护中的表现。

6.8 比较场景分析

我们进一步在不同的运行场景和配置下评估了系统的性能，以理解上下文和参数调整如何影响结果。特别地，我们比较了： (a) 白天 vs. 夜晚监测，(b) 高灵敏度 vs. 低灵敏度配置，以及 (c) 不同警报阈值。对于每种场景，我们都测量了主要性能指标，包括事件检测率、误报率、平均检测延迟，以及在适用情况下对功耗和用户警报负担的估算。结果以表格形式列出，对每种条件进行了并列比较。

白天 vs. 夜晚监测：这两个场景反映系统在白天活动环境（伴随更多的移动和潜在噪声）和相对安静的夜晚环境下的表现。我们通过在模拟数据中增加运动伪影和更大的数据波动（模拟用户日间活动）来模拟“白天”条件，而“夜晚”条件下的数据则更平稳，生命体征波动较小（模拟休息睡眠状态）。如表5所示，系统在这两种情况下都保持了很高的事件检测率（白天召回率约95%，夜晚约96%）。然而，误报率从白天的5%下降到了夜晚的2%，推测原因是夜晚数据较为平静，几乎没有被系统误判为事件的噪声波动。因此夜间警报的精确率更高。平均检测延迟在夜晚也略有降低（约1.8秒 vs 白天的2.0秒），因为数据噪声更少，系统可以更快地确认异常而无需多次验证。我们还观察到系统的平均功耗在夜间略低，因为DIKWP代理用于处理噪声或重复触发的开销更小——例如白天由于少量误报而进行的额外计算和通信在夜间几乎没有。从用户角度来看，夜间的警报虽然很少，但极为准确，这一点很重要，因为睡眠时任何误报都会非常打扰人。总体而言，这表明DIKWP监测系统在全天条件下都具有鲁棒性，而在低噪声的环境中可以达到更高的精确性。

表5. 白天与夜晚监测条件的性能比较。夜晚数据由于噪声较少，导致误报更少且检测速度略快；白天尽管受到更多活动干扰，系统性能仍保持在高水平。

在夜间，系统几乎没有误报，符合在睡眠期间避免干扰的要求。而在白天，尽管由于活动增加导致误报略多，但整体性能仍在可接受范围内。

高灵敏度 vs. 低灵敏度配置：我们评估了系统配置的两个极端情况，以探索灵敏度（敏感性）和特异性之间的平衡。在高灵敏度配置下，系统被调校得对轻微或早期的异常也非常敏感（捕获尽可能多的异常，以增加一些误报为代价）；而在低灵敏度配置下，触发警报的条件被设定得更加严格（减少误报，但可能漏掉一些细微的异常）。我们在相同的模拟数据集上应用这两种配置进行测试。表6 总结了结果。

高灵敏度模式下，事件检测率极高（召回率约99%，几乎捕获了所有异常），但误报率也上升到约10%（正常的波动也有不少被错误地标记为异常）。平均检测延迟略低（约1.5秒），因为系统在发现异常迹象时就立即警报，并不等待更多确认。相对的，低灵敏度模式的检测率降至90%（有些轻微事件被忽略），但误报率仅约1%（几乎没有假警报）。平均检测延迟也增加到了约3.0秒，因为系统需要等待更明确或持续的异常才触发警报。

就资源使用而言，高灵敏度配置下系统需要更频繁地分析数据并生成警报，这导致能耗有所增加——我们估计与低灵敏度模式相比，CPU占用和功耗平均增加约10%（原因是处理更多的触发和通信）。从用户体验角度看，高灵敏度模式可能让用户面临过多的警报（其中一些还是误报），而低灵敏度模式可能过于安静，甚至错过重要的早期预警。在实际应用中，一个折中的灵敏度设置最为理想（在我们默认的配置中，约95%的召回率配合约5%的误报率，已经是较好的平衡）。这个实验凸显了：通过调整DIKWP代理的参数，可以使系统的“意识”从“高度警觉”模式转变为“保守谨慎”模式，每种模式对性能和体验的影响截然不同。为获得最佳效果，必须根据具体情境谨慎地选择灵敏度设置，或者让系统能够动态调整，以维持一个可接受的误报水平。

表6. 高灵敏度与低灵敏度配置下的系统性能。高灵敏度模式捕获了更多异常（更高召回），但同时触发了更多误报；低灵敏度模式避免了误报，却漏掉了一部分异常，且响应稍慢。

这组结果说明了典型的灵敏度-特异性权衡：过高的敏感度可能导致警报泛滥，而过低的敏感度又有漏报风险。因此，根据应用场景恰当地调整系统敏感度对于达到最佳性能至关重要。

不同警报阈值：在 DIKWP 框架下，我们也可以通过设置不同的警报触发阈值来影响系统的报警策略。我们实验了三种阈值水平：低阈值（非常易触发）、中等阈值（默认平衡）和 高阈值（非常不易触发），以进一步量化这种权衡，并寻找最佳设置。低阈值意味着系统对较小的偏差就触发警报（类似前述高灵敏度模式），高阈值则表示只有偏差很大时才触发警报（类似低灵敏度模式），中等阈值介于两者之间。表7 总结了不同阈值下的性能。

当阈值设定较低时，系统会在很小的异常出现时就报警，因此几乎捕捉到了所有异常事件（召回率接近100%），但警报的精确率较低（约15%的警报是误报）。测试用户对这种设置的满意度偏低（平均约3.5/5），因为警报过于频繁令人烦扰。高阈值设置下，系统基本只针对显著异常报警，因此误报率几乎为0%，用户受到的无谓干扰极少（满意度评分约4.2/5，因为几乎不会被不必要的警报打断）；然而，事件检测率下降到了约85%（一些较温和的异常没有触发警报）。中等阈值则达到了较好的平衡——保持了约95%的高检测率，同时误报率仅约2%，用户满意度也最高（约4.5/5）。

这表明我们先前所采用的中等阈值（默认配置）已经接近于本应用场景下精确率和召回率的最佳折中点。从响应速度来看，低阈值设置往往在异常初现时就立即报警，而高阈值设置可能要等信号超出较大的界限后才报警。这些结果再次强调了选择合适警报阈值的重要性：它直接影响着 DIKWP 代理在智慧层面的决策，即确保警报既不过于频繁以至“狼来了”，也不至于过于少见而错失真正需要关注的健康问题。在实际部署中，阈值可以针对不同患者或情境进行定制，甚至可以由系统根据实时情况动态调整，以始终维持一个让误报率和漏报率均可接受的水平。

表7. 不同警报阈值设置下的性能指标比较。本例中，“中等阈值”实现了最佳平衡，既保证了高检测率，又维持了低误报率，因而用户满意度最高。

合适的阈值选择对于系统性能至关重要。阈值过低会产生大量误报（削弱用户对系统的信任），而阈值过高则会漏掉重要预警。中等阈值在本测试中取得了接近最优的平衡，这也从用户满意度的高分中得到了印证。

6.9 系统架构资源分析

为了了解 DIKWP 人工意识框架在实际物联网部署中的可行性和可扩展性，我们对系统架构中各主要组件的资源使用情况进行了分析。我们的 DIKWP 代理由四个主要功能组件组成：数据预处理、模型推断（Inference）、高级推理（Reasoning）和通信。它们大致对应了 DIKWP 认知流水线的各阶段——数据处理（D→I）、模式识别的机器推断（I→K）、更高层的知识/智慧决策（K→W）、以及决策的执行与通信（W→P）。

我们在三种硬件平台上评估了每个组件对于 CPU 利用率、内存占用和功耗的要求：一是智能手表（可穿戴设备），二是智能手机，三是边缘网关设备（本地网关或小型服务器）。表8 汇总了每个组件在这些平台上的资源使用估计（假设智能手表硬件约为1 GHz ARM处理器，512 MB–1 GB RAM，电池300 mAh；智能手机为八核处理器，4 GB RAM，电池约3000 mAh；边缘网关为四核CPU，8+ GB RAM，持续电源供电）。

从表8中可以观察到：

· 数据预处理非常轻量。即使在智能手表上，执行简单的数据过滤和特征提取也只占用约5–10%的CPU（单个内核）和不到1 MB的内存，功耗仅几毫瓦。这意味着可穿戴设备可以持续运行这些任务而不会明显增加电池负担。智能手机和边缘网关处理数据预处理任务则几乎不构成任何负载（CPU占用低于2%）。

· **模型推断（Inference）**的需求相对更高。在资源受限的智能手表上，运行复杂的推断（例如一个小型神经网络）可能耗费约20%的CPU和几MB的内存（每次推断），如果持续运行，其功耗会达到几十毫瓦。在我们的架构中，较重的推断工作可以被卸载到智能手机或边缘网关：在智能手机上，运行同样的模型可能只占用约5–10%的CPU（因为移动处理器更强大且可能有AI加速硬件），但需要更多的内存（模型可能占用20–50 MB）。手机上进行推断的能耗在绝对值上更高（约100 mW），但考虑到手机的大电池容量，这个消耗是可以接受的。边缘网关具备强大的计算能力，执行这样的推断任务CPU占用不到2%，模型内存占用（几十MB）也轻松应对；功耗对网关来说不是问题，因为它接入了持续电源。

· **高级推理（Reasoning）**通常因为涉及复杂算法或知识库查询而对资源要求较高。如果尝试在智能手表上运行完整的高级推理，可能会占用30%以上的CPU和好几MB的内存，这对于手表的电池来说难以持续负担（将会很快耗尽电量）。在我们的架构中，这类复杂的推理任务被分配给了智能手机或边缘网关。智能手机上执行高级推理算法大约占用10%的CPU和约8 MB的RAM，消耗30–50 mW的功率，属于中等负载。边缘网关可以以充裕的资源运行这些推理（例如占用约15%的CPU和100 MB的RAM，假设维护了相当规模的知识库或上下文数据），而且由于接通外部电源，不存在电池瓶颈。

· 通信组件（处理设备间或与云端的数据发送与接收）的资源需求适中。在智能手表上，通过蓝牙向手机传输数据会短时占用约5–10%的CPU和极小的内存（<0.5 MB），但无线传输本身可能是相对明显的耗能项（蓝牙在数据传输时约耗15 mW）。在智能手机上，通过 Wi-Fi 或蜂窝网络与边缘网关或云端通信的CPU和内存开销也很小（CPU约5%，<1 MB内存），传输警报时的功耗约20 mW。边缘网关将数据发送至云端（若有需要）几乎对其资源没有影响，并且通常通过以太网或Wi-Fi连接且使用市电供电，因此不受电池限制。

总体而言，将 DIKWP 智能代理的功能分布到不同设备上是有利的。智能手表能够胜任数据收集和初步处理等轻量任务，而将较为繁重的知识/智慧推理卸载给智能手机或网关，极大地延长了可穿戴设备的电池寿命，同时保证了及时的响应。智能手机作为中间层，可执行机器学习推断和部分高级推理；而边缘网关（或者云服务器）可以承担最繁重的推理计算和长期知识存储，而无需考虑电池问题。这种分层部署确保系统的各部分都在各自设备的能力范围内高效运行。对于智能手表这样的终端而言尤其关键：我们的分析显示，通过将其上运行的内容限制在轻量级任务，其小容量电池也足以支持持续的监测。而边缘网关的强大算力则意味着可以在不影响可穿戴设备性能的情况下不断提升推理模块的复杂度（例如，整合更多数据源或使用更深入的认知模型）。因此，通过协同利用不同层级的设备，根据它们的能力分担负载，基于 DIKWP 的人工意识框架能够实际应用于智能医疗物联网之中。

表8 表明，通过分布式部署 DIKWP 智能代理可以优化资源使用：在可穿戴设备上处理轻量级的数据任务，在性能更强的设备上执行繁重的推理任务。这种架构既确保了系统的实时性能，又延长了电池续航，非常适合实际的实时健康监测应用。

表8. 各 DIKWP 代理组件在不同硬件平台上的资源使用估计。CPU 和内存值表示该组件运行时对系统资源的典型占用；功耗为在电池供电设备上运行该组件时的额外能耗（边缘网关使用外接电源，功耗列仅作对比而非电池关键值）。

7. 讨论

实验结果证实，将 DIKWP 人工意识模型融入物联网智能医疗系统能够带来实实在在的好处。本节我们将讨论这些发现的意义、当前原型的局限性，以及未来的研究方向。

提高 AI 决策质量：DIKWP 方法提升了警报决策的精确率和召回率。这表明在复杂的医疗场景中，引入具有上下文意识的多层推理（相对于仅设定传感器阈值的简单策略）非常有价值。这类似于临床医生会综合多项生命体征和病人背景来得出结论的过程。结果就是系统产生的误报更少（这对于实际部署至关重要，因为过多的假警报会削弱用户对系统的信任），漏报也更少（直接关系到患者的安全）。

边缘自治与可靠性：通过赋予边缘设备认知能力，系统获得了一定的自主性，这在日常监护和紧急情况下都极为有益。即便云端或互联网连接中断，患者的监护也不会停止；这种架构的分布式特性就像让患者身边始终有一个受过医疗训练的助手，即使与医院失去联系也能独立工作。从更广的角度看，这是朝着具备弹性的医疗 AI 系统迈出的重要一步——当底层基础设施发生故障时，这样的系统能够优雅地退化，而不至于彻底瘫痪。鉴于某些健康决策可能生死攸关，这种鲁棒性在关键时刻可能挽救生命（设想在严重车祸场景中，如果伤者佩戴的设备即使在移动网络中断时仍可彼此警示或联系附近急救人员，其价值不言而喻）。

隐私优先的设计：减少数据外传也意味着更低的隐私泄露风险。即使有攻击者拦截了我们的通信，拿到的也只是高度抽象的信息（例如某个警报或统计摘要），离开上下文几乎毫无用处；相比之下，原始传感数据流可能暴露个人隐私（如精确的活动轨迹，甚至心电图可以作为生物特征）。我们的架构通过将可识别的详细数据大部分留存在本地设备，符合严格的隐私保护要求。用户的心理感受也因此更好——他们明白系统并没有把自己的详细生理数据持续不断地上传云端，这有助于他们更容易接受这样的监护技术。

可解释性与信任：我们的系统能够为每个警报或行动提供一段来源于 DIKWP 推理链的解释说明。这种透明度在传统的物联网医疗方案中几乎闻所未闻，却可能成为 AI 在临床中获取信任、得到广泛采用的关键因素。医生更有可能信赖并使用一个能够用清晰语言解释其决策依据的 AI 助手；同样，患者在系统告诉他们“为什么”要那么做时，也会更愿意遵循其建议。

泛化性与灵活性：尽管我们的原型集中在有限的生命体征和情境上，但所提出的框架具有通用性。无需改变系统的总体架构，就可以接入不同的传感器或医疗状况。例如，要添加一个血糖传感器及相应的糖尿病管理功能是相当直接的：在数据层接入新的数据类型，在信息层提取相关指标（如血糖值高/正常），在知识层加入对应的规则（如果血糖持续升高则有高血糖风险），在智慧层定义行动（提醒患者或调整胰岛素）。这种由语义编排 DSL 支持的模块化添加方式，使系统具备极强的可扩展性。这是知识驱动方法的优势——与必须重新训练一个黑箱模型相比，添加新的知识/规则要容易且直观得多。

软件定义的益处：我们在案例研究中展示了通过意图配置和远程规则更新来调整系统行为的能力，这凸显了软件定义方法的强大之处。医院或医疗服务提供商可以维护一套中央策略，自动推送到所有患者的设备上（并可按需微调个体差异）。遇到公共卫生突发事件（例如疫情暴发），他们可以全局性地提高对某些症状的敏感度，或迅速实施新的监护协议。这样的敏捷性在医疗领域非常宝贵，因为临床指南在不断更新，不同患者也需要不同方案。

转载本文请联系原作者获取授权，同时请注明本文来自段玉聪科学网博客。

链接地址：https://wap.sciencenet.cn/blog-3429562-1490128.html?mobile=1

收藏

分享