说明：本文中的图示采用建模工具EA进行了建模，并补充了细节信息。

在医疗领域，在过去的二十年里我们花了数亿美元构建了我们目前的医疗技术架构。然而，我们并未真正获得预期的投资回报率（ROI）。

LLM技术为我们带来了重新思考的方法和以更低的成本实现目标的潜力。

我们如何能够在不彻底更换现有技术基础设施的情况下引入大语言模型呢？

我们首先将探讨当前医疗领域的架构情况，分析其为何建设及维护成本极高，以及为何它无法满足临床医生、患者和其他医疗工作者的需求。

接下来，我们将介绍用于医疗领域的大语言模型架构，这个架构使我们能够以更低的成本实现同样的目标，并且能让临床医生、患者以及其他医疗工作者迅速获得答案。

LLM 架构利用了当前的架构，让我们随着时间慢慢完全迁移。

1 当前医疗领域的系统架构现状

虽然不同组织之间存在差异，但当前医疗领域的架构可以简化为以下逻辑图。首先是结构图，描述了各个部分的链接关系。

如下是对应的交互顺序图，说明了各个部分的交互关系：

这个过程始于各种数据库中的数据。

例如，主数据库就是存储电子病历（EMR）中所有数据的那个数据库。电子病历是临床医生用于输入患者临床数据的工具。

此外，我们还拥有包含其他数据的数据库，例如保险理赔数据、参考数据等。

注意，每个数据库都有其自身的模式。模式指的是数据在数据库中的存储方式。例如，一个包含出生日期的列，在这个数据库中可能被称为“date_of_birth”，在另一个数据库中可能被称为“birth_date”，而在另一个数据库中可能被称为“dob”。

列名上的差异问题是最基本的情况。通常，同一数据元素在不同的表中存储方式会完全不同。

同样，每个数据库中的内容也可能有所不同。在一个数据库中，出生日期可以是“1980-01-01”，而在另一个数据库中则是“1980 年 1 月 1 日”，而在另一个数据库中则是“1/1/1980”。

这是一个比较简单的例子，但是这个问题却会深入到非常复杂的层面。

1.1 标准化Schema与格式

我们有一个 ETL（提取、转换和加载）过程，读取每个数据库，将所有的模式和内容转换为我们在数据仓库中所使用的另一种格式。

这种 ETL 流程的构建和维护成本非常高。在过去二十年里，我们每年在每个医疗机构中都要投入数千万美元。

我们还没有见过哪家医疗机构能够宣称其所有的数据都存放在数据仓库里！

大多数组织只能将一小部分数据迁移到数据仓库中。

而且我们每年都持续花费更多的费用！已经二十年了！

1.2 用户界面

我们基于数据构建用户界面，以便让临床医生能够访问这些数据。该用户界面包含按钮、下拉菜单和其他控制元素，以便用户能够与数据进行交互。

这也是一个非常昂贵的过程。想一下，您为您的电子病历系统支付了多少费用呢？

我们只能设计出能够高效解答少量问题的用户界面。而对于其他情况，用户都被迫自己动手，浏览多个界面，拼凑数据以回答他们的问题。

我们想要回答的问题越多，用户界面就会变得越复杂。我们现有的电子病历系统已经到了这样一种程度：临床医生要花费很长时间点击各种界面才能回答一些简单的问题。

如果临床医生希望尽快得出结果呢？但在大多数情况下，需要等上好几个月，才能让电子病历开发商添加新的功能。

对于患者，我们创建了类似患者门户的用户界面。由于患者不像医生那样专业，所以我们开发了非常简单的患者访问平台，这个平台能回答的患者问题非常有限。

1.3 SQL 查询功能层

这些用户界面改进工作的成本之所以如此高昂，部分原因就在于“SQL查询功能 层”。

这一层会接收用户的输入，并将其转换为数据库能够理解的语言。大多数数据库仅能理解 SQL（结构化查询语言）。有些电子病历系统（如 Epic）使用的是另一种语言，但其原理是相同的。

每次我们向用户界面引入新的内容时，我们都需要编写软件来将用户的输入转换为 SQL 查询语句。

而数据库只会返回原始数据，因此对于任何功能需求，我们都需要编写软件来将这些数据转换为表格和其他用户界面元素，以便向用户展示。

1.4 其他医护人员

电子病历系统主要是为医生设计的。而其他医护人员都只能被迫去学习如何使用并非为他们设计的工具。

你是否曾见过客服人员或家庭护理人员学习如何使用电子病历系统？

我们担心这些医护人员会在电子病历系统中出现操作失误，所以我们要么为他们制定替代流程，要么尝试为他们构建一个独立的用户界面，而用户界面构建成本又很高。

最终的结果是，大多数医护人员无法有效地参与到患者的护理工作中。

1.5 从多个来源汇总数据

还有一个问题就是：如何整合来自多个来源的数据。

例如，假设我们从电子病历数据库中获取了一个诊断结果，然后又从另一个数据库（例如 使用各种仪器进行身体检测而得到的体检数据）中获取了另一个诊断结果。

对于这位患者，我们是应该给出两个诊断结果，还是说这是同一个诊断结果从两个不同的角度得出的呢？

这也是一个非常棘手的问题，因为每个系统在存储和表述诊断信息时可能采用的方式各不相同。

2 当前架构存在的问题

根据上述所讨论的问题，最终我们得出的结果是：

   1. 数据仓库不过是又一个数据孤岛而已。这正是它们原本被期望解决的问题！

   2. 临床医生们感到不满，因为电子病历系统使用起来实在太困难了。

   3. 非临床医护人员无法有效地为患者护理做出贡献。

   4. 那些曾被承诺会有自己可用界面的患者及其护理人员，从这些确切的用户界面中获得的价值却非常少。

   5. 在过去二十年里，每个医疗机构每年仍持续花费数千万美元甚至更多，但毫无缓解的迹象。

既然我们身处人工智能时代，应该基于AI技术寻找更好的解决方法。

3 医疗领域的智能体架构(基于LLM)

大语言模型为我们提供了一种看待这个问题的新方法。

我们可以基于大模型重构当前的系统架构。这样就可以保持并继续从现有系统的投资中获得价值。

如下是采用医疗智能系统架构的逻辑结构图：

如下是医疗智能系统的交互顺序图：

下面就逐一介绍基于LLM技术构建的医疗领域系统架构的关键特性。

3.1 把数据结构和内容 转换为自然语言文本

我们还是从现有的那些数据库开始。与其花费时间将这些数据转换为数据仓库的Schema和格式，我们完全可以从每个数据库中直接将数据导出为自然语言的文本格式。如果已经有了数据仓库，也可以从该数据仓库中将数据导出为文本格式。

这可是一个简单得多的问题啊！

例如，我们无需为每个数据库中的列重新命名：比如“date_of_birth”（出生日期）、“birth_date”（出生日期）、“dob”（出生日期）。因为大语言模型能够理解英语，所以它们已经知道这些名称所指的都是相同的信息。

同样，大语言模型也能处理不同的日期格式：“1980-01-01” 与 “1 月 1 日，1980 年” 以及 “1/1/1980”。大语言模型已经知道这些是表示同一日期的不同方式。

转换为文本其实非常简单，就像这样书写文本即可：

注意，这个文本可以采用任何格式，因为大语言模型能够理解英语：

无需做任何额外的工作就能处理这两种不同的格式！想想看，这可真是件多么了不起的事情啊。

3.2 把文本知识存储到知识库

接下来，我们可以将这段文本存储到知识库中。知识库通常是一种向量数据库--一种专门用于存储文本的数据库。

先来看下，如下是当前医疗数据存储系统：

下面是基于LLM的医疗智能数据存储系统：

在数据仓库中，我们通常会使用 SQL（关系型）数据库。这种数据库有着非常严格的模式和格式要求。而且，查询必须严格按照 SQL 的格式来编写。这迫使我们必须花费大量精力将数据导入数据仓库，并创建查询以获取结果。

在知识库中，我们使用的是向量数据库。向量数据库能够存储非结构化的文本。只需用英语输入问题，向量数据库就会返回与该问题所涉及内容相关的所有文本片段。

所有主要的数据库供应商（如 Mongo、ElasticSearch 等）以及所有的云平台（AWS、Azure、谷歌）都提供了向量数据库服务。

3.3 提供多语言查询界面：英语、西班牙语…

由于我们正在使用的大语言模型，我们可以让用户用简单的英语或西班牙语来提出问题。

大语言模型能够理解许多常用语言，所以用户使用哪种语言并不重要。

用户不受下拉菜单、按钮和屏幕的限制。

这个语言界面能够解答我们从未遇到过的问题。而且无需对我们的软件进行任何改动！

而当我们从大语言模型那里获取数据时，这些数据将会是一个完整的答案，而不会只是用户需要自行拼凑起来才能得出的那些零散的信息。

例如，在当前的用户界面中，如果我们想了解患者过去两周的血压平均值，需要先查看一系列的血压读数，然后自己计算平均值。或者只能等待电子病历软件供应商在一年或两年后添加这一功能。

在基于大语言模型的架构中，大语言模型会返回平均血压值。用户无需进行任何计算操作。

大语言模型能够理解语言，并且具备进行数学运算的能力。

先来看下，如下是当前医疗数据查询系统：

下面是基于LLM的医疗智能数据查询系统：

3.4 提供更多交互支持：为其他医护人员

在医疗领域的大语言模型架构中，那些并非医生的医护人员能够向数据提问并获得答案，而无需借助数据分析师的帮助。

并且，大语言模型给出的答案能够以一种用户能够真正理解的方式表述出来。护士得到的答案会与护理助理、家庭健康护理人员以及客服人员得到的答案有所不同。

3.5 风险管理层

风险管理层运用相关技术来降低与数据及人工智能相关的风险。

具体可以参考《控制大型语言模型幻觉的框架》一文。

3.6 多个来源的数据聚合

在“当前架构”部分中，我们曾提及过如何对来自多个来源的数据进行聚合这一问题。

例如，假设我们从电子病历数据库中获取了一个诊断结果，然后又从另一个数据库中获取了另一个诊断结果。

由于大语言模型能够理解语言，所以它们能够辨别出对于同一诊断结果的两种表述是否是相同的。

4 LLM 架构的影响

应用于医疗领域的LLM 架构能够解决当前架构中的一些问题。

   1. 知识库消除了数据孤岛的问题。复制数据非常容易，我们可以把所有数据复制完毕，甚至可以从现有的数据仓库中复制数据。

   2. 临床医生更满意了，因为他们只需提出问题就能得到答案，而无需处理复杂的用户界面。

   3. 非临床的医疗工作者能够以他们能理解的术语获得答案。因此，他们能够为患者护理做出更多贡献。

   4. 患者及其护理人员能够获得医疗问题的答案，从而更加积极参与护理。

   5. 我们可以以远低于现有架构的成本构建和支持LLM架构。

5 声明

为了使这篇文章简短易懂，省略了通常的注意事项。

我们还会在系统中实施分诊，系统会回答某些类型的问题，并将其他类型的问题转交给合适的工作流，比如“打电话给你的医生”、“去急诊”等等。

这篇文章主要讲述的是核心理念，并非所有细节。当然，也会有某些情况是LLM 架构无法解决的。

我们可以为进化过程中设定一些步骤，这样我们就能逐步获得相应的益处。

6 总结

我们当前的医疗架构每年让每个医疗机构花费数千万美元。即使二十年过去了，我们也无法把所有数据都导入数据仓库。

临床医生对他们的电子病历系统使用体验感到非常沮丧。其他医护人员无法有效的为患者护理做出贡献。患者和护理人员很难获得关于健康记录问题的答案。

医疗LLM架构可以改变这一状况。

临床医生能够通过指尖操作轻松获得答案。其他医护人员也可以通过处理简单、常规的护理需求，减轻临床医生的部分负担。患者和护理人员也将最终获得有关自身健康状况的信息。

并且，总体成本要低得多。

本文模型图示部分采用建模工具EA进行了重新建模，欢迎试用EA（UML和SysML 建模工具）