最近在整理手头一个中医方向的毕设级项目——04589中医处方推荐系统的设计与实现。这个系统虽然是个完整工程但从拆解角度看特别适合当案例它把推荐算法、知识图谱、全栈工程全部串到了一起从数据清洗到接口联调都要走一遍拿来当课程设计、毕业设计或者求职作品集主题都很合适。系统解决的是一件很具体的事中医门诊场景下医生或学生输入患者的主诉症状后系统基于历史处方数据快速给出与之匹配的方剂、常用药味和剂量参考并附带推荐理由方便复核。我这里已经把完整源码和数据集整理打包了关注后发送关键字就能获取文末我会把文件清单和目录结构也贴出来。需要提前说明的是这个项目定位是科研学习和辅助决策工具不是诊疗系统实际应用一定要有执业医师把关。1. 项目背景中医处方推荐到底在解决什么问题1.1 传统开方流程里的三个痛点很多非中医专业的人会以为开方就是“照着教科书抄”真正接触过门诊就会发现完全不是这样。同一个患者同一种感冒在不同医生手里出来的方子可能完全不同有人从麻黄汤走有人从荆防败毒散走还有人以体质为切入点调脾胃。这种经验高度依赖个人积累年轻中医师跟诊几年可能都攒不下足够多的完整处方样本。第二个痛点是数据利用率低。三甲中医院的门诊系统里堆着海量历史处方但这些数据大部分躺在数据库里没人碰。处方里其实包含大量可挖掘信息症状与用药的对应关系、证型分布、地区用药习惯、剂量范围规律。这些信息如果用传统方式让老专家手把手带教三年五年都不一定能讲完可数据本身就客观记录着这些经验。第三个痛点是沟通成本。患者来看病时描述的症状往往是“头昏脑涨、睡眠不好、口干口苦”这类口语化描述跟中医辨证体系里的“肝阳上亢”“肝胆湿热”之间存在很大鸿沟。如果患者自己能把症状结构化提交系统可以先做一轮草拟参考医生再据此修正整个问诊效率会高很多。这三个痛点叠加起来正好对应一个推荐系统能发力的位置有历史数据、有输入信号症状、有明确产出方剂或者药味组合。所以这个项目的出发点并不是“炫技术”而是把中医门诊场景里的辅助决策需求落成一个可运行的原型。1.2 推荐系统的定位辅助决策而不是替代诊疗做一个医疗相关项目最忌讳把系统的边界说得太满。我在项目文档的第一页就写清楚本系统输出的推荐方剂仅用于学习和参考不能作为最终处方依据必须经过执业中医师审核。这个定位不仅在伦理上站得住脚在答辩和开源分享的时候也能帮自己省掉很多解释成本。从技术上看推荐系统做的是“候选集缩小”的工作而不是“给出最终答案”。比如输入“咳嗽、痰黄、咽痛”系统从方剂库里召回20个候选方再通过禁忌规则过滤掉不适合的最后按相关度排序返回前5个。医生扫一眼就能判断哪条更贴近真实辨证如果有偏差可以直接忽略。这个“人机协同”的闭环比“让系统直接出方”靠谱得多也是我在算法设计上反复提醒自己的一条主线。2. 整体架构与方案选型我为什么这样设计2.1 四层架构总览整个系统的架构我拆成了四层每一层干的事很清晰层级职责核心组件数据采集层整理处方数据、清洗结构化Python脚本、人工复核工具数据存储层存方剂、药材、证型关系和日志MySQL 8.0 Neo4j 4.x Redis算法处理层召回、过滤、排序、解释Python Flask 服务 pandas应用展示层用户交互、结果可视化Vue3 Element Plus Nginx这个分层的好处是每一层都能独立测试。比如调试推荐结果不对时我可以先查数据层有没有脏数据再查算法层召回逻辑不用把整个系统捆在一起猜问题。最后部署用 Docker Compose 把所有服务编排起来一条命令就能在服务器上起一套完整环境。2.2 推荐算法选型基于规则、协同过滤还是知识图谱选型阶段我把主流推荐方案过了一遍做了个对比表方案可解释性数据依赖实现成本中医场景适配度基于规则的辨证匹配高需要症状到证型的映射表低高符合中医“辨证论治”思维协同过滤CF中需要大量历史方剂记录中中等适合做相似方剂挖掘知识图谱KG高需要构建实体关系图高高能把“方-药-证-症”串起来深度学习模型低需要海量标注数据高中低数据量不够时容易过拟合最终我选了“规则 协同过滤 轻量知识图谱”的混合方案。直接上深度学习在门诊疗场景里并不划算因为可用的标注样本量不足以支撑复杂模型而且医生对一个必须要解释的“黑盒推荐”接受度很低。混合方案里规则负责圈定候选协同过滤负责找相似处方知识图谱负责提供结构化解释路径各司其职效果和可解释性都能照顾到。2.3 技术栈清单与版本选择后端我用的是 Flask 而不是 SpringBoot。不是 SpringBoot 不好而是这个项目更强调算法迭代速度Flask 写起来轻、调试方便一套代码直接嵌入推荐逻辑不需要额外的容器框架。等以后并发量真上来再把推荐服务单独拆成 Java 微服务也不迟。前端用 Vue3 Element Plus组件生态成熟做管理后台类的页面效率极高。数据库部分 MySQL 存结构化数据Neo4j 存“方-药-证”关系图谱Redis 做缓存这个组合基本覆盖了系统所有数据读写场景。3. 数据工程一张可用的中医处方数据集是怎么来的3.1 数据来源与脱敏处理做这个项目之前我以为最难的环节是算法真正动手才发现最难的是数据。中医处方数据来源很杂有些公开的方剂学教材、古籍数据库有些从医院脱敏门诊数据里清洗出来还有一部分网上爬来的医案需要专门校验。我最终整理出约2万条处方记录每一条都包含方名、组成、功用、主治、证型、原始症状描述和剂量信息。整理过程中我严格做了脱敏处理所有真实患者姓名、医院信息、医生工号全部剔除只保留方剂组成和辨证信息。这里要特别提醒一句医疗数据的合规问题是红线哪怕是模拟数据或者公开教材方剂在项目文档里也要写清来源不能拿来路不明的临床数据直接做开源项目。这个细节很多人在毕设阶段容易忽略到答辩被问到就麻烦。3.2 核心表结构设计建表时我没有一开始就堆很多字段而是从最核心的三张表起步方剂表、药材表、方剂-药材关联表。下面这段 SQL 是方剂表和关联表的核心部分CREATE TABLE prescription ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL COMMENT 方名, 功效 VARCHAR(500) COMMENT 功效描述, 主治 VARCHAR(500) COMMENT 主治证型, 证型 VARCHAR(100) COMMENT 核心证型标签, 来源 VARCHAR(100) COMMENT 教材/古籍/门诊脱敏, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE herb ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL COMMENT 药名, alias VARCHAR(100) COMMENT 别名集合, 性味 VARCHAR(50) COMMENT 性味归经, 禁忌标签 VARCHAR(200) COMMENT 如孕妇禁、有毒等 ); CREATE TABLE prescription_herb ( id INT PRIMARY KEY AUTO_INCREMENT, prescription_id INT, herb_id INT, dose_g DECIMAL(8,2) COMMENT 剂量统一为克, role VARCHAR(50) COMMENT 君臣佐使角色, KEY idx_prescription (prescription_id), KEY idx_herb (herb_id) );为什么设计“方剂-药材”关联表而不是直接往方剂表里塞 JSON因为后续做协同过滤和知识图谱时需要频繁按药材反查方剂、按方剂取全部药材关联表加索引查起来效率高也比 JSON 字段更容易写 SQL 做统计。而证型映射关系我单独建了一张 symptom_syndrome 表把常见症状短语映射到标准证型标签这是后面规则召回的基础。3.3 数据清洗与剂量规范化清洗这块我踩了不少坑。中药别名问题非常烦人同一个药在不同典籍里可能叫“玄参”“元参”“黑参”同一个名字在不同地区指代的药物不同比如“桂皮”时需要确认是桂枝还是肉桂。我给药材表加了一个 alias 字段把所有常见别名用分号拼进去查询时先做别名归一化。剂量规范化更是个体力活。有的方子里写“三钱”有的写“3g”还有的写“3克”甚至个别古籍方压根没有剂量。我写了一个清洗脚本先把中文数字和单位统一测量import re def normalize_dose(text): if not text: return None # 统一大写数字 mapping {一: 1, 二: 2, 三: 3, 四: 4, 五: 5, 六: 6, 七: 7, 八: 8, 九: 9, 十: 10} text text.strip() if text.endswith(钱): number text.replace(钱, ) return float(mapping.get(number, 0)) * 3 # 按1钱约3克折算 if text.endswith(两): number text.replace(两, ) return float(mapping.get(number, 0)) * 30 # 按1两约30克折算 match re.search(r(\d(\.\d)?)\s*克, text) if match: return float(match.group(1)) return None这个函数处理了最常用的“钱、两、克”三种写法。你能想象吗一套系统如果连剂量单位都不统一后面做统计分析时数据全是乱的。我的原则是清洗脚本宁可把拿不准的记录打成 NULL也不硬猜一个数值进去因为错误数据对算法的伤害比缺失数据更大。4. 核心算法实现推荐链路的分步拆解4.1 多路召回怎么把候选方子捞出来推荐链路的第一步是“多路召回”意思是从不同维度先把候选集扩大避免漏掉真正该出现的方剂。我实现了三路召回第一路是症状关键词匹配。将用户输入的“咳嗽、痰黄、咽痛”拆成关键词去 symptom_syndrome 表里查对应的证型标签比如“风热犯肺”再按证型标签召回方剂。第二路是证型标签匹配直接拿证型查方剂表的证型字段。第三路是协同过滤拿当前输入症状集合与历史方剂里的症状集合做相似度匹配用杰卡德相似系数筛出最像的历史方子。def recall_candidates(symptoms, top_k30): # 第一路症状-证型-方剂 syndrome query_syndrome_by_symptoms(symptoms) p1 query_prescription_by_syndrome(syndrome) # 第二路直接按证型标签 p2 query_prescription_by_tag(syndrome) # 第三路协同过滤找历史相似处方 p3 recall_similar_prescriptions(symptoms, top_k) # 合并候选按方剂ID去重 candidates union_by_id(p1, p2, p3) return candidates三个召回的结果做一个并集去重得到大约 20 到 40 个候选方后面接过滤和排序。这条路线的价值在于即使输入的症状描述不够规范只要有一个维度跟历史数据对得上也能把相关方剂带出来。4.2 规则过滤十八反十九畏与妊娠用药禁忌召回之后不能直接排序输出必须先做规则过滤。这里我用了一张“禁忌规则表”把传统中医里明确记载的配伍禁忌固化下来。最基础的就是十八反和十九畏比如“甘草反甘遂”“乌头反半夏”这类组合一旦候选方剂里同时出现直接剔除。INCOMPATIBLE_PAIRS [ (甘草, 甘遂), (甘草, 海藻), (甘草, 芫花), (乌头, 半夏), (乌头, 贝母), (乌头, 瓜蒌), (藜芦, 人参), (藜芦, 沙参), (藜芦, 玄参), # 这里只展示部分完整表放在规则文件里 ] def filter_by_incompatibility(candidates): result [] for p in candidates: herbs get_herbs_by_prescription(p.id) flag True for h1, h2 in INCOMPATIBLE_PAIRS: if h1 in herbs and h2 in herbs: flag False break if flag: result.append(p) return result除了配伍禁忌我还做了妊娠禁忌过滤和一些毒性药材过滤。比如含有“附子”“川乌”“马兜铃”这类药材的方子在普通场景下默认不推荐除非用户主动勾选了“允许有毒药材”的专家模式。这个设计在实际答辩时非常加好感因为评审老师一看就知道你考虑过安全边界不是只学着调包做推荐。4.3 排序与推荐理由生成过滤完之后剩下十几个候选就要排序。我给每个方剂算一个综合得分公式是score 0.5 * 症状命中率 0.3 * 证型匹配度 0.2 * 历史使用频率症状命中率是这个方剂的主治描述里能匹配到输入关键词的比例证型匹配度是方剂证型与识别出证型的重合程度历史使用频率是数据集中该方剂出现的次数归一化后的值。这样设计的好处是既看文本匹配又看真实用药频次两个维度互相补充。为了让推荐结果不显得像黑盒我把每个候选都带上一个 reason 字段。比如{ name: 桑菊饮, composition: [桑叶, 菊花, 杏仁, 连翘, 薄荷, 桔梗, 甘草, 芦根], score: 0.87, reason: 命中症状咽痛、咳嗽匹配证型风热犯肺历史使用频率较高 }这个 reason 字段是我强烈建议保留的。它一方面让医生能用临床经验判断这个推荐值不值得采纳另一方面在系统演示时也能直观展示推荐逻辑不至于让观众一头雾水。5. 前后端联调从算法模型到可用系统5.1 后端接口设计后端业务逻辑不复杂核心就一个推荐接口。我给前端暴露的是 POST/api/recommend参数是症状列表和可选的过滤选项。返回结构里包括了推荐的方剂数组和每个方剂完整的药材组成。app.post(/api/recommend) def recommend(): data request.get_json() symptoms data.get(symptoms, []) allow_toxic data.get(allow_toxic, False) top_n data.get(top_n, 5) candidates recall_candidates(symptoms) candidates filter_by_incompatibility(candidates) if not allow_toxic: candidates filter_by_toxic(candidates) results rank_candidates(candidates, symptoms)[:top_n] # 补充方剂详情和推荐理由 return jsonify({code: 0, data: results, message: ok})接口里我留了一个 allow_toxic 参数默认是 False。这个设计很实用因为普通用户场景下系统应该保守一些但如果是研究者想试一下带有附子类药材的古方也可以主动打开开关。这种“默认安全、功能可开”的设计思路放在任何工具型系统里都通用。5.2 前端界面与推荐结果展示前端我用 Vue3 写了三个主要页面推荐查询页、处方详情页、历史记录页。推荐查询页是核心交互入口左边是一个多选症状标签组件用户点击常见症状咳嗽、发热、头痛、咽干等右边实时显示推荐结果。展示推荐方剂时我用卡片形式把“方名、组成、功效、推荐理由”四块信息列清楚。组成那块对每味药会显示“桑叶 6g”这样的格式剂量数据来自清洗后的 prescription_herb 表。前端还加了一个“复制处方文本”的按钮方便实验时把推荐结果粘贴到自己的研究文档里。对了卡片底部固定显示一行小字“仅供科研参考不构成诊疗建议”这个细节很重要后面避坑部分我还会细说。5.3 部署与性能优化部署这块我用 Docker Compose 一次性起了四个容器MySQL、Neo4j、Flask 服务、Nginx 前端容器。这样不管是本地演示还是搬到服务器上一条docker-compose up -d就能跑起来比手工配环境省太多心。数据量从开始的几千条涨到两万条之后查询速度明显变慢我对三张核心表的字段加了索引又把热点数据比如药材别名表放到 Redis 里接口响应时间从 900 毫秒降到了 150 毫秒左右体验一下就顺了。优化时有个小经验不要一上来就上缓存先看慢查询日志确认瓶颈在哪里。我这次最大的瓶颈其实是 Python 端跑协同过滤时反复查库后来把候选取出来之后的药材明细一次性批量查出来避免了 N1 查询性能提升比加缓存还明显。6. 踩坑记录与常见问题排查6.1 冷启动问题新症状进来没有匹配怎么办第一个能预见的坑是冷启动。用户输入“腰膝酸软、畏寒、尿频”这个症状组合在我的数据集里可能一条都没出现过候选集直接是空的系统输出“未找到匹配方剂”。这当然不行。我的解决办法是做一个“证型兜底链”。具体来说如果精确匹配的症状组合没有命中就退回到单个症状级别去匹配证型。比如单看“畏寒”可以匹配“肾阳虚”值得庆幸的是按证型标签又能召回一批方剂。召回后我会在界面上提示用户“当前为症状级匹配建议进一步辨证”避免医生误以为这是完全精准的结果。这个“逐级放宽匹配条件”的思路在推荐系统里很常用也可以应用到别的不确定场景。6.2 推荐结果“跑偏”的排查思路项目做到中后期同事帮我试了一个输入“胃痛、反酸”结果系统第一推荐的不是常用的理气方而是一个安神方。看着就离谱。当时我以为是排序权重有问题查了一圈才发现是数据层的问题方剂的“主治”字段里有“胃痛”字样但实际方剂核心功效是安神只是某个版本的适应证里写了一句“胃不和则卧不安”。这是一个很典型的数据噪声导致算法误判的 case。排查思路很简单先把候选集打出来看看召回阶段问题出在哪里再定位是规则表缺失还是数据标注不准确。以后遇到这类问题千万别一上来就调算法参数十有八九是数据的问题。这也是我反复强调清洗的重要性原因。6.3 剂量与单位统一是个隐藏坑还有个隐藏坑是关于“单位换算”的。不同来源的方剂剂量单位五花八门古代方子写作“一撮”“半升”有些教材直接写“10克”另一些写成“三钱”。我前面写的 normalize_dose 函数只处理了钱、两、克遇到“一撮”这种模糊量词就只能标 NULL。但 NULL 值多了也不行因为展示环节没有剂量就没法按克数渲染。后来我加了一条规则遇到无法精确换算的量词不硬猜而是在界面上显示“约”字并附带原书计量描述。比如显示“半夏 约6g原书作半升”。这种做法的好处是保留原始信息同时把不确定性明确暴露给使用者反而比假装精确更可信。7. 项目亮点提炼与后续扩展方向7.1 这个项目在作品集里的亮点怎么讲如果你也打算用类似项目做作品集亮点我建议从三个角度包装。第一是工程完整性从数据清洗、算法设计到前后端部署全部自己走通这本身就是很多团队里都少见的综合素质。第二是推荐系统设计多路召回加规则过滤加排序解释这套链路是业界通用的推荐系统范式不是在实验室里死磕模型能比的。第三是领域理解能说清楚中医辨证数据的特点、禁忌规则的重要性说明你有能力把一个非结构化行业问题翻译成技术方案这在面试时非常加分。7.2 后续扩展思路这个项目再往下走我还有几个方向想试。一个是把方剂按药味组合做向量化用 embedding 表示方子然后做语义相似度检索替代现在基于关键词的召回。另一个是把知识图谱做大把“经络-脏腑-中药-方剂”的关系都链起来这样推荐理由的解释可以从“命中症状”升级成“依据归经理论推理”。再一个是加用户反馈闭环让医生标出一份推荐“有用/无用”把这部分信号回流到排序权重里让系统越用越准。不过扩展归扩展毕设阶段最重要还是把现有系统做扎实。一个能稳定运行、逻辑闭环、数据干净的项目比一个堆了十几个模型但哪里都跑不利索的项目有价值得多。我后续会把知识图谱扩展需求拆成独立的小版本迭代不急于一步到位。整个项目从立项到跑通我最深的一个感触是医疗方向的项目算法不是主角数据和安全边界才是。你花一周把推荐模型调好可能不如花一周把单位换算和禁忌规则表做得更严谨更有用。系统可以自动推荐但决策责任必须始终留在人工手里。这个原则我在编码和文档里都反复强调实际也真的是在评审和展示环节最被认可的地方。最后再提醒一句如果你也把这个项目拿去二次开发记得在自己的版本里保留“仅供科研参考不构成诊疗建议”的提示这个细节能帮你在各种场合省掉很多不必要的麻烦。源码和整理好的数据集我已经放到仓库里了关注后发“中医处方”就能拿到下载链接工程目录和启动说明都在里面。