山东大学软件学院项目实训-基于语言大模型的智能居家养老健康守护系统-个人博客(一)

从需求到架构基线搭建驱动大模型深度推理的个性化营养干预与康复推荐引擎1. 为什么我们要重新定义“AI助手”在智慧养老这个赛道最不缺的就是“能聊天”的AI。但对于身体机能逐渐退化的老人来说一个只能陪聊、甚至会一本正经胡说八道的机器人价值微乎其微。真正能解决问题的AI必须能结合老人的真实健康数据给出可执行、且安全的干预建议。通用大模型LLM在医疗养老场景有三个天然短板- 建议太虚“多吃蔬菜、适度运动”这种正确但无用的废话太多。- 不守底线容易忽略药食冲突如服用华法林不能吃太多绿叶菜或运动禁忌。- 无法闭环建议给完就结束了至于有没有效、老人做没做系统一无所知。因此我们要构建的不是一个“聊天机器人”而是一个以数据为底座、规则为边界、大模型为大脑的智能决策中台。2. 站在已有的肩膀上我们的技术底座我们并不是在空中楼阁上画饼。目前系统已经完成了最艰苦的基础设施建设- 感知层具备 OCR 医疗单据解析能力能把纸质体检报告变数字结构化数据。- 数据层拥有健康时序数据库记录血压、血糖动态和数字病历夹。- 连接层已实现家属端绑定、预警推送和多角色 Agent 的基础架构。这些沉淀意味着我们现在要做的是把这些散落的珍珠通过一套“干预推荐逻辑”串成项链。3. 架构设计四步走逻辑第一版架构不求面面俱到核心目标是在保证安全的前提下让 AI 深入介入老人的生活干预。第一步构建“统一健康上下文”AI 的推理质量上限取决于输入的质量。我们需要把散落在各处的数据聚合为一个“数字画像”- 静态标签年龄、慢病史高血压、糖尿病等、饮食限制低盐低脂。- 动态趋势最近 7/30 天的血糖波动趋势而非单一数值。- 风险边界正在服用的药物、步态风险评估、心肺耐力等级。第二步建立“规则 RAG LLM”的混合方案我们不能把健康安全完全托付给 LLM 的概率计算。推荐流程被设计为1. 硬规则过滤比如血糖超过 16.7mmol/L系统禁止输出任何运动建议直接推送就医提醒。2. 知识检索RAG从权威的慢病指南、药食冲突库中调取专业背景资料。3. 大模型推理LLM 结合画像和专业知识生成富有“人情味”且符合个体情况的方案。4. 二次安全审校方案输出前再次经过禁忌症规则校验。第三步让每一条建议都“有据可查”为了后续优化系统必须具备“记忆”。每一条发给老人的建议后台都会记录- 触发建议时的健康快照当时指标是多少。- 使用的提示词Prompt版本和知识库来源。- 最终生成的方案。没有留痕就没有复盘没有复盘AI 永远不会进步。第四步闭环评估关键环节这是最难、但也最有价值的一步。系统要自动追踪建议后的反馈- 指标变化执行低盐建议后血压波动是否平稳了- 依从性评估哪些建议老人总是略过说明建议太难执行需要调整策略。4. 为什么选择这种“组合拳”技术方案- 规则负责“底线”医疗养老安全是 1其他是 0。规则引擎能拦截 100% 的已知禁忌。- RAG 负责“专业”确保建议不是大模型瞎编的而是有医学依据的。- LLM 负责“温度”把冰冷的医学词汇转化为老人听得懂、愿意听的日常叮嘱。5. 现阶段的挑战与风险预判作为开发者我们要清醒地看到目前的局限性1. 数据质量依赖 OCR如果老人拍的医疗单据不清晰后续的推理就是“垃圾进垃圾出”。2. 工程化挑战LLM 输出的格式如果不够标准会增加系统解析的难度。3. 闭环反馈的缺失很多生活干预如饮食目前主要靠家属手动确认存在数据断层