查看原文
其他

关于hippocratic.ai和glass.health的产品讨论

zhpmatrix KBQA沉思录 2024-04-15

前言:

        感觉好久没停下来写文章了,最近一篇文章是上个月初写的,时间过了一个多月,这段时间一方面大模型的生态飞速发展,另一方面笔者所在团队的工作也在快速展开中。总之,事多,人少,时间不够用(老板也是公众号粉丝,不晓得会不会被拉小黑屋谈话...

在之前的文章《Mendel.ai,面向全世界80%的非结构化临床数据》中,讨论了一款结构化方向上的产品,这篇文章讨论两款基于英语世界医疗大模型的应用产品以及笔者做的背后技术拆解,最后给出近段时间笔者在大模型应用的开发推进上,形成的一些心得。

1.hippocratic.ai


一句话概括产品特点:基于医疗大模型的患者模拟,用于医学教育。2022年创立的公司,2023年种子轮拿了5000W美金,a16z是投资方之一。

公司官网地址:https://www.hippocraticai.com/safety

产品试用地址:https://www.hippocratic.ai/clinical

产品功能上分为两块,分别是patient simulator和flashcard generator。patient simulator是指在一个医生患者对话流程中,由机器作为模拟的患者,自动生成针对真实医生的回复。该模块提供了心血管、呼吸、肠胃、肌肉骨骼、神经学、内分泌、肾脏、生殖8种模拟病人问答,并且在对话过程中病人还会表现出愤怒、急躁、焦虑等拟人化情绪,以帮助医生适应不同类型的病人。交互流程如下所示:

flashcard generator的主要功能是根据医生上传的笔记,自动生成问答对。比如上传本地的word文档,内容如下:


Patient name: Amanda Jones

DOB: 11/04/02

Presenting problem:severe headache with sudden onset, neck pain, neck stiffness, nausea and vomiting, fever for 3-4 days, no trauma, no recent illness

Differential diagnosis:

- Meningits?


在笔者自己试用的过程中,一直报错,所以暂没有尝试成功。

针对上述功能介绍,一种可能的技术实现如下:

整体上的思路比较简单,分为离线训练和在线预测两个阶段。

离线训练阶段,关键是要有高质量的真实医患对话数据。在国内,一种方式是通过self-instruct的方式来构建;外一种是在合法的条件下,可以爬取比如好大夫等问诊数据。外,如果有基于语音的门诊电子病历系统,可以直接拉取数据库中的数据。这个阶段的亮点是:怎样融合更多的医学知识

在线推理阶段,理论上可以基于一个模型,支持两个功能模块。除了可以实现患者模拟,也可以实现医生模拟。此外,flashcard的生成功能,在实现上也可以有两种方式。一种是直接生成问答对,一种是先生成问题,再将笔记和问题通过精巧的prompt构建,作为医疗大模型的输入,自动生成答案。该模块的具体实现基本等同于一个基于大模型的知识库问答产品

其实,除了上述这款产品,该团队在更早之前做了一个医疗方向上的语义搜索工具,如下:

statpearls semantic search:

https://hippocratic-medical-questions.herokuapp.com/

也许在某种程度上进一步证明:你需要的是一个有积累和沉淀的团队啊。

为了进一步了解更多信息,这里有一篇相关稿件

2.glass.health


一句话概括产品特点:根据患者的临床问题描述,基于医疗大模型自动生成鉴别诊断和诊疗计划。

该团队除了这个核心功能模块,还包括一个医疗知识笔记软件,类比专为医学从业者开发的有道云笔记(国内的类似产品也存在)。这里主要讨论前者,交互如下:

模型自动生成的结果如下所示(这里只给出鉴别诊断的生成结果):

围绕鉴别诊断生成,在学术上也做了很久了。进一步地扩展,可以将这个问题放在病历文书生成的场景,这里特指首次病程记录,一个标准的首次病程记录包括主诉,病历特点,初步诊断,诊断依据,鉴别诊断和诊疗计划。实际上,鉴别诊断的获取,未必需要采用基于医疗大模型的自动生成,还有其他方案。但是诊疗计划的获取需要依赖医疗知识和当前患者的特点,基于推理得到,理论上更适合选择模型生成的路线。这里给出一个可能的技术实现路线图:

为了进一步了解glass.health,这里推荐一篇相关资料(https://zhuanlan.zhihu.com/p/620058017)。

3.思考


        实际上,看到这些产品的时候,笔者常常会陷入到一种复杂的状态。比如:

  • 鉴别诊断和诊疗计划生成,放在病历文书生成的场景中,这个切入点似乎在全链路的价值有限?背后的思考逻辑是什么?

  • hippocratic.ai的这个产品以及背后的技术,能够撑起种子轮5000W美金以及a16z的投资吗?如果不能,凭什么?如果能,又是凭什么?

  • 这种产品做出来,第一眼望上去会给人一种“小而美”的感觉,结合自己正在做的一些产品(适时推出,敬请期待),总觉得这种感觉不是很真实?

        抛开中文医疗大模型的工作暂且不多谈(适时推出,敬请期待),在应用上的推进一次又一次地在验证着笔者早前思考的观点,如下:

模型和应用同时展开背后的思考是,一种情况下,问题一直在,早期的技术效率比起大模型而言较低,故有技术改造的需求。或者早期的技术存在天花板,比如中文纠错,现在大模型突破技术的瓶颈,使得此前不能做的事情现在可以尝试做了,比如很多文本生成类的应用。对应到上图,也就是横坐标不变,纵坐标改变。

纵坐标不变,横坐标改变。在中文医疗大模型的阈值之下,有价值的应用类型受限于技术发展,类型有限,无法无限趋近于横坐标右侧🫱。在技术阈值之上,使得此前不敢做的事情,今天也可以开始推进了。产品和技术的理想交叉点就在上图中的右上🌟的位置。产品类型足够丰富,技术深度足够高,带来的实际价值自然高。

整个横纵坐标围成的面积,也就是今天大模型线的基本盘。通过不断地做技术价值深挖和产品类型拓展,不断地拓展价值的边界。

最后,当然是要祝福大家,520,HAPPY啦!

扫码加笔者好友,茶已备好,等你来聊,

继续滑动看下一个
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存