好的产品框架才说好的LLM模型

最近在带着团队做镜像生命的空间系统，这款基于糖尿病慢性病管理的系统我们也逐步在深入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