二零二三年的春天比以往显得更加美丽婀娜，窗外的细雨纷纷洒落，樱花和着泥土的芬芳，悄悄地叩打着落地窗。笔者沏茶静坐，开始写一篇很早就很想写的文章。

开篇先给出笔者自己的一个认识：假设将构建业务系统作为容器创建，构建数据系统作为给容器加水，建立智能系统作为烧水。现阶段多数处于容器创建阶段，会需要加水的系统，但是刚需的场景比较少。会需要烧水，但是刚需的场景更少。

由此，用于烧水的医疗NLP到底面临哪些更具体的现实的问题？

（1）面向评级的销售的底层逻辑

国家意志层面是“以评促建”，面向评级意味着一定程度上的自顶向下，但是实际落地过程中，是自底向上的。这样会导致一个问题，对于院方而言，有一个东西比有一个好用的东西重要。这样的话，乙方的建设目标也不是高标准的，导致乙方的产品和服务逐渐降级。“评级”的逻辑能够带来间接价值，但无法带来直接价值。

（2）价值交换体系中，项目和服务重于产品

医疗的需求方的需求是多样且层次化的，这样导致需求的标准化程度较低，产品的标准化难度较高。如果无法有一个好用的产品体系能够支持交付能力的提升，会逐渐使得项目属性增加，服务比重增加。在组织上，这会带来产研侧和交付侧的边界问题。

在《数据智能的历史机遇与现实困境》一文中有一个观点，“如果从项目角度入手，往往目标会设定成项目的验收回款，且公司的组织配套也会往复杂项目管理，行业咨询的方向偏移，后续再往产品型公司转，难度可谓是非常之大。”

（3）决策体系复杂，价值传导链路冗长

对于院内业务，用户和客户的利益不一致。决策需要层层上传和层层下达，当涉及多个中间方的时候，导致信息在传播过程中的损耗增加。价值链路在一定程度上和信息链路保持一致。

（4）闭环构建难度高

由于并非直接解决用户的问题，同时信息传导链路长，导致用户的反馈多数时候无法快速到达产品侧，产品无法快速迭代。数据和算法的闭环也较难实现。由于院内的数据不能出院，导致如果想要有效利用院内的数据，需要配套的数据的基础设施也要同步到院内，与数据的交互行为同时发生在院内，这一切在现实环境下，实现难度很高。

（5）研究对象自身的问题

针对关键研究对象，“医疗大数据”和“医疗NLP”，笔者之前均写过文章进行分析和讨论。医疗NLP是以结构化能力为核心的应用方向，能力和内容都很重要，数据和知识都需要。但是如何实现这样的目标，在现实落地过程中，会遇到诸多的挑战。

回想两年前，笔者刚刚切入医疗NLP方向时写的文章《NLP人误闯医疗界》，兴奋中夹杂着隐约的担忧。两年后，对很多问题的理解和认识也在逐渐加深。医疗人工智能还存在较大的发展空间，但是从现阶段的时间点切入，为时尚早。

雨一直下，满眼的绿树新芽，好一派生机勃勃的模样。