最近在带着团队做镜像生命的空间系统,这款基于糖尿病慢性病管理的系统我们也逐步在深入AI,将其产品框架和AI模型融入在一起。

在产品迭代和优化过程中,我们越来越发现尤其是在AI病历上,不仅是要求模型强大,而且还要有一个好的病历结构与产品功能操作,才能够让AI更好的解析用户情况以及分析,给出对应的推荐与病历情况。

如果没有一个好的产品框架,就不会有模型能力的展示。

我们在开发以及现在运营这个AI医疗慢性病管理系统的时候,我们总结了3点技巧。

1.用评测标准去评判产品,而不是传统的功能性测试

传荣的软件功能通过跟随PRD文档,只要功能能够正常跳转、逻辑判断就可以,保证功能可用。

但是AI产品就要用模型评测集,比如我们做慢性病的医疗产品,就要用慢性病相关的AI数据集来检验,通过AI模型落地于产品框架,看下最后的输出效果如何,能不能达到临床医生的接受度。

打开网易新闻 查看精彩图片

比如常见的就是输入的context背景内容过长导致AI和产品搭配起来后,就缺失一些字段,导致病历字段缺失。

2.模型能力参数大小与私有化部署

考虑到AI产品的并发与模型的满血能力,不少公司会选择调用现成的模型,但这个缺点就是自己成为了模型公司的训练对象,每一次对话就是一次训练,丢失了数据。

而私有化就可以方便部署的同时,还能够存储数据,以及做数据标注训练之外可以进行模型微调,总之最后才能够算自己的模型与AI产品。

但私有化就要自己搭建机房与GPU集群,这种方式就是持续投入、尤其是电费以及硬件的折旧费,都是成本。

加上现在内存越来越贵,整个机房的投入可以调用非常多的产品了,但是有私有化部署的好处是自己可以搭建若干个其他模型参数,方便来完成产品的能力打磨,也就是MVP产品研发。

后续再推广用户时候再调用云API。

3. AI 产品经理必须关注模型延迟与数据闭环

在 AI 产品设计中,模型能力并不是唯一需要关注的指标,响应延迟、并发能力和实际业务效率同样决定了 AI 能否真正落地到生产环境中。

AI 的响应速度往往受到显卡资源、模型规模、上下文长度、Token 输出速度以及并发请求量等因素影响。如果 AI 的处理时间已经超过人工完成任务的时间,那么即使模型效果很好,其实际生产价值也会大幅下降。

例如,在医疗场景中,如果医生使用 AI 辅助填写一份病历,模型解析、推理和生成结构化内容需要几十秒甚至更长,而医生手动录入可能更快,那么这样的 AI 功能就很难形成真正的效率提升。

因此,AI 产品经理还要关注2个核心问题:

1.推理速度是否足够快、系统是否能够支撑多人并发、AI 是否真正减少了用户操作时间。

在底层可以通过模型量化、推理优化、KV Cache、流式输出、更高性能 GPU 或模型路由等方式提高 Token 生成速度,从而降低整体使用延迟。

尤其是在医疗 AI 中,AI 通常不能直接替代医生做最终决策,而更适合作为辅助工具:自动解析病历、识别字段、预填写内容、提示异常信息,最终仍由医生审核和确认。因此,AI 的价值并不是单纯“生成一段文字”,而是减少医生重复录入、查找和判断的成本。

2.同时,医疗信息系统中通常存在大量结构化字段,例如诊断、主诉、既往史、检查结果、医嘱、药品以及随访信息等。

随着系统字段不断增加,前端业务系统、数据库与 AI 系统之间应该建立持续的数据同步机制,将新增字段和业务数据同步到结构化数据库、向量数据库或其他知识检索系统中。

这样一来,无论后续新增什么字段,AI 都能够对新的输入和输出进行检索、理解和辅助处理,而不需要每新增一个功能就重新开发一套 AI 能力。

更理想的方向,是未来在前端框架和业务组件层直接预留 AI 接口,让输入框、表单、病历、医嘱、影像以及其他业务模块都能够按需调用 AI。最终实现的不是“系统里增加一个 AI 聊天框”,而是让AI 成为整个业务系统底层的一种基础能力。

今天的分享就在这里。

题图来自 Unsplash ,基于 CC0 协议, 如有侵权,请联系pmtalk123删除

“分享产品经理改变世界的点滴”

产品顾问| 产品咨询|培训合作

请添加微信PMxiaowanzi

最近我的原创

每日案例拆解库,AI等产品打卡群

我创建的产品设计打卡社群,加入后365天,每天体验一款APP。提升产品设计能力,同时有1300份体验报告帮助你找到竞品

在这里你可以随时查询到你想找的各类竞品行业APP,无须自己亲自下载就可以马上得到APP的一手产品优化、交互设计、功能描述信息。

从优化&建议、商业模式、运营、功能描述、交互设计、产品定位至少6个维度,体验一款应用。

平均1天1块钱,扫码购买即可加入

连续体验48款应用,通过后原路退回

报名后添加星球助理

PMTalk123