简介一份面向高校人工智能、计算机相关专业毕业设计场景的完整作品包主题是基于LLM与多模态人工智能的健康管理与辅助诊疗系统包含毕业设计论文与汇报PPT适用于需要从架构设计、模型接入到文档产出全流程参考的本科生和研究生。项目技术栈覆盖Vue.js与Element Plus搭建前端交互界面Flask与SQLAlchemy实现后端服务与数据处理MySQL承担业务存储RabbitMQ负责异步消息PyTorch与Transformers结合Qwen2.5-3B-Instruct落地大模型推理能力能清晰展示健康管理问答、辅助诊疗提示等典型应用链路。压缩包共247个文件、约93.2MB以vue组件、py后端脚本、pdf论文与PPT、jpg与svg图件、sql脚本等类型为主覆盖系统前后端实现、模型接入、论文与展示材料等完整交付内容。目前已有90人学习下载适合毕业设计参考、系统二次开发或多模态医疗AI入门。1. 健康管理与辅助诊疗系统LLM 与多模态到底在毕设里做什么把一份血常规报告、一张舌象照片和一段口述症状同时丢给一个系统让它给出健康评估和辅助诊疗建议——这种能力在传统 Web 毕设里根本做不出来但换成大模型 LLM 驱动就顺理成章。这个毕业设计项目做的就是这件事输入侧是多模态文本、图像、OCR 报告中间层是微调或提示词约束下的大模型推理输出侧是结构化的健康建议与风险提示最后再配论文和汇报 PPT。这套资源适合两类人一是计算机、软件工程等相关专业的毕设选题者二是想快速搭一个医疗方向大模型 Demo、但不想从零写代码的从业者。它解决的核心问题不是替代医生诊断而是把「多模态数据—知识检索—LLM 推理」这条路完整走通让系统能读报告、能看懂舌象特征、能基于医学知识库给出有限范围内的辅助建议并在论文和答辩里把技术逻辑讲圆。2. 架构与数据流从多模态输入到辅助诊疗建议的五层链路2.1 为什么必须多模态而不是只做一个文本对话机器人很多第一次做医疗方向 LLM 项目的同学会先做一个「聊天版问诊系统」用户打字描述症状LLM 回复建议。这类系统技术门槛很低但论文写到第三章就撑不住了——它没有任何多模态处理能力也解释不了「为什么别的毕设不这么做」。真实健康管理场景里数据本身就是多形态的。医院检查报告是 PDF 或图片中医诊断依赖舌象、面色照片日常健康管理还有血压计、体重秤上传的时序数值。如果系统只接受文本输入等于把最关键的信息源丢掉了。所以要做一个能落地的健康管理与辅助诊疗系统第一决策是数据通路设计文本主诉走自然语言解析OCR 报告走图像转文本再进结构化抽取图像舌象、面色走视觉特征提取三类特征融合后一起交给 LLM 推理。多模态的价值不是「炫技」而是让 LLM 的推理有依据。比如用户上传一张舌象照片单靠视觉模型只能输出「舌色淡红苔薄白」这个描述本身没有诊疗含义但当它和用户的血糖值、主诉文本拼在一起模型就能结合知识库判断「脾虚湿盛的可能性较高」——这就是多模态融合的实际意义。毕设答辩时评审最常问的「你的系统比纯聊天机器人强在哪」也能用这条链路正面回答。2.2 五层架构设计每一层的数据形态与职责边界我会把系统按数据流拆成五个层次每一层只做一件事层与层之间用明确的数据结构对接。这样不仅代码好写论文架构图也清晰。接入层处理用户提交的原始数据文本、图片报告拍照、舌象、PDF。这一层只做格式校验和规范化比如图片压缩到大模型期望的尺寸、文本去空白、PDF 转图片。解析层是第一个关键节点文本走正则与命名实体抽取图片走 OCR 和视觉编码器输出的统一格式是一组带置信度的结构化字段。融合层把各模态抽取结果拼装成一个统一的上下文对象和后续还有路由到 RAG 知识库的检索结果一起组成一个「事实包」。推理层是大模型 LLM 的核心工作区根据系统提示词模板、事实包和用户问题生成回答对外暴露统一 API。应用层面向最终用户和展示包括健康档案页面、历史记录查询、报告生成、风险预警消息。层与层之间的接口设计值得多说一句解析层和融合层输出的统一数据格式我建议用一个 dataclass 或 Pydantic 模型定义字段包括modal_type、content、confidence、source。这样后续换模型、换 OCR 工具都只影响本层不会把整个系统拖翻车。毕设论文的系统设计章节画一张分层数据流图加上这个数据结构定义比写十段描述性文字都有说服力。2.3 LLM 选型与知识库方案API 调用还是本地开源模型选型是这类系统里最影响成败的决策。毕设场景下有两个可选路线直接调用大模型 API或者本地部署开源模型。API 路线的优势是效果稳定、代码简单但缺点很现实——论文里的「系统架构图」会变成一个外部黑匣子评审追问「模型内部机制」时你只能讲大模型通用原理而且毕设答辩现场如果网络波动演示会翻车我在后面的避坑章节会专门讲这件事。本地开源模型路线需要一台像样的 GPU但它的优势是系统闭环完整从模型加载、量化到推理封装都是你自己实现的论文里能写「基于 Qwen2.5-7B-Instruct 的蒸馏部署」这类实打实的工作量。我一般推荐 7B 这个档位——13B 级别的模型对显存和推理延迟都不友好7B 经过 AWQ 量化后单张 8GB 显存可以跑速度也能接受。如果实在没有 GPU退一步用 API 方案做第一版 Demo把接口封装成统一的LLMClient论文里标注清楚。知识库方面健康管理场景必须配 RAG因为医学知识更新频繁且对准确性要求高纯靠模型参数记忆容易出现幻觉。第一步是收集并清洗医学指南、健康科普文档第二步是把文档切块向量化存入向量数据库第三步是在推理时把用户问题向量化、检索 top-k 相关片段、拼进 Prompt。进阶方案是用 GraphRAG——把知识抽成实体关系图再检索对「药品相互作用」这类关联型问询效果更好但毕设工作量会明显增大我一般建议先把 RAG 跑通GraphRAG 作为论文的「系统优化与展望」。热词检索结果里反复出现的「LLM wiki 知识库」本质就是这类方案要注意它解决的是「知识怎么组织」的问题不是「模型怎么选」的问题。3. 核心模块落地OCR 解析、RAG 检索与 LLM 推理代码详解3.1 检查报告解析PaddleOCR 抽取指标与结构化输出健康管理系统的第一步是让系统能「读报告」。常见的输入是一张手机拍摄的血常规或生化检验报告照片里面是印刷体中文数字混排文本。我选用 PaddleOCR 的原因是它中文识别效果好、安装简单并且自带方向分类器对手机随手拍这种旋转、倾斜的输入鲁棒性最好。import re from paddleocr import PaddleOCR # use_angle_clsTrue 开启方向分类处理倾斜照片langch 指定中文模型 ocr PaddleOCR(use_angle_clsTrue, langch, show_logFalse) result ocr.ocr(blood_report.jpg, clsTrue) # 把 OCR 结果拼成整段文本用于后续正则抽取 lines [] for page in result: for item in page: lines.append(item[1][0]) # item [坐标框, (识别文本, 置信度)] full_text \n.join(lines) # 抽检关键指标匹配项目名 分隔符 数值 单位 patterns [ r(空腹血糖|血糖)[:\s]*([0-9]\.?[0-9]*)\s*(mmol/L), r(糖化血红蛋白)[:\s]*([0-9]\.?[0-9]*)\s*(%), r(总胆固醇|甘油三酯)[:\s]*([0-9]\.?[0-9]*)\s*(mmol/L), ] parsed [] for pattern in patterns: for m in re.finditer(pattern, full_text): parsed.append({item: m.group(1), value: m.group(2), unit: m.group(3)})这段代码有两个核心参数需要说明。use_angle_clsTrue会多跑一个方向分类模型推理时间增加约 30%但对拍照歪斜的报告识别率提升非常明显健康场景下我不建议关掉40ms 的额外耗时可以接受。show_logFalse是防止 PaddleOCR 在每次初始化时刷屏服务端日志会被淹没。正则抽取是这版实现的简化做法。真正生产场景里报告单往往是表格结构同一项目可能出现在不同行列这时要按坐标框位置做行分组再匹配。毕设论文里可以写「第一版基于正则抽取后续工作引入版面分析模型」把这一步做成一个可迭代的模块不要觉得正则方案丢人。抽取结果统一存入parsed列表后下一步就是把它转成融合层的标准数据结构与文本主诉、图像视觉特征拼接。3.2 医学 RAG 知识库向量化、索引构建与检索参数有了结构化指标还不够用户问「我这个血糖值到底算不算高」时系统需要医学知识支撑。RAG 知识库的方案是把医学指南和科普文档切成片段用嵌入模型转成向量构建索引查询时做相似检索把命中的片段拼进 Prompt 让 LLM 基于它们回答。from sentence_transformers import SentenceTransformer import faiss import os # 中文医学文本建议用 text2vec 系列通用 embedding 模型对医学名词编码效果偏差 encoder SentenceTransformer(shibing624/text2vec-base-chinese) doc_dir med_kb/ chunks [] # 预先切好的文本块每块 512 字左右相邻块重叠 64 字 metadata [] for file in os.listdir(doc_dir): if not file.endswith(.txt): continue text open(os.path.join(doc_dir, file), encodingutf-8).read() start, step, overlap 0, 512, 64 while start len(text): chunk text[start : start step] chunks.append(chunk) metadata.append({source: file, offset: start}) start step - overlap embeddings encoder.encode(chunks, normalize_embeddingsTrue) embeddings embeddings.astype(float32) # 内积检索配合归一化向量效果等价于余弦相似度FAISS 推荐组合 index faiss.IndexFlatIP(embeddings.shape[1]) index.add(embeddings)文本切块参数直接影响检索质量。块太小会截断语义块太大检索噪声多我在这个项目里用的经验值是 512 字切一块、相邻重叠 64 字这样既能保证一个完整知识点落在同一块又不会因为硬切导致「上句没说完下块才开始」。如果你做的是药品说明书类强结构化文档可以换成按条目切分效果更好但那个方案泛化性差换文档类型又要重写。normalize_embeddingsTrue配合IndexFlatIP是关键组合——所有向量归一化后再做内积得到的值域就是余弦相似度[-1, 1]排序阈值有直观含义我一般设置检索得分低于 0.45 的结果直接丢弃宁可答「知识库中暂未找到相关信息」也不要把不相关片段喂给模型产生幻觉。查询时还有两个系数要保留给调参top_k取 4 到 6 比较平衡超过 8 后 Prompt 过长且噪声累积明显查询向量也要做同样的normalize_embeddingsTrue否则得分分布不可比。3.3 LLM 推理封装统一客户端与医疗场景提示词约束推理层是系统的中枢我要把它封装成一个只暴露assess()方法的类内部同时支持本地 vLLM 服务和远程 API这样后面换模型不用动任何业务代码。vLLM 服务启动后提供 OpenAI 兼容接口所以客户端可以用官方openaiSDK 直接连。from openai import OpenAI class LLMClient: def __init__(self, modelocal, base_urlhttp://localhost:8000/v1, api_keyEMPTY, modelQwen2.5-7B-Instruct): self.client OpenAI(base_urlbase_url, api_keyapi_key) self.model model def assess(self, context: dict) - str: # 医疗场景强制低温度保证多次回答一致性 resp self.client.chat.completions.create( modelself.model, temperature0.2, top_p0.7, max_tokens512, messages[ {role: system, content: MEDICAL_SYSTEM_PROMPT}, {role: user, content: build_user_message(context)} ] ) return resp.choices[0].message.contenttemperature0.2不是随便拍的。医疗辅助场景对回答一致性要求很高同一个报告问两次不能一次说「偏高」一次说「偏正常」。我在调试时明显感觉到 temperature 超过 0.5 后采样随机性主导0.1 到 0.2 之间能兼顾确定性和少量表达多样性。max_tokens512是为了限制输出长度健康建议场景不需要长篇大论512 个 Token 足够生成一段结构化的评估和建议如果你的报告还要同时输出症状分析和饮食方案可以放宽到 768但不要超过 1024否则响应延迟和成本都会上升。MEDICAL_SYSTEM_PROMPT 是另一个决定成败的部分我给出一版经过验证的写法系统角色定义为「健康管理助手不是执业医师」明确「只基于用户提供的数据和知识库检索结果作答」强制输出格式为「风险等级 异常指标解读 生活方式建议 就医提示」四段最后加一条「如果知识库中没有对应信息必须明确说暂未检索到相关依据严禁编造」。这条提示词直接决定系统会不会在答辩现场给出一个离谱的诊断建议。4. 本地部署与接口对接量化方式、vLLM 服务参数与数据表设计4.1 本地推理服务vLLM 部署 Qwen2.5-7B 的参数配置本地部署这条线我推荐 vLLM 而不是原始的 HuggingFace pipeline原因有三vLLM 的 PagedAttention 显存利用率和吞吐量都比原生推理高出数倍它对 OpenAI 接口做了兼容上一章的LLMClient可以直接对接连续批处理让 7B 模型在单卡上的推理延迟稳定在 1 秒左右答辩演示不至于让观众等十秒。启动命令python -m vllm.entrypoints.openai.api_server \ --model Qwen2.5-7B-Instruct \ --quantization awq \ --dtype float16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --port 8000这套参数是几轮调教后比较稳的组合。--quantization awq用 AWQ 量化把权重压到 4bit7B 模型显存占用从约 14GB 降到 6GB 上下让 8GB 显存的消费级显卡也能跑。--dtype float16配合 awq 使用时保持半精度计算速度和质量折中最好。--max-model-len 8192控制上下文窗口——我们的 RAG 检索结果加系统提示词和历史对话加一起通常不超过 3000 Token8192 足够同时留下冗余。--gpu-memory-utilization 0.85是显存分配上限剩下的 15% 留给 KV Cache 和临时计算。如果设置为 0.95 以上长时间运行后容易在并发请求时爆显存调低到 0.7 会牺牲并发吞吐。毕设演示是单用户顺序访问0.85 最安全。还有一个小技巧启动后先执行curl http://localhost:8000/v1/models确认服务正常再启动后端别把故障排查拖到答辩现场。4.2 前端接口与健康档案数据表设计后端我建议走 Spring Boot 或者 FastAPI对 FastAPI 的话代码量更小、和 Python 生态无缝衔接。系统需要存储四类数据用户基本信息、多模态原始记录、结构化解析结果、评估报告。建四张表就够了关联关系用用户 ID 串联。下面这张表结构是论文数据库设计章节的直接素材也方便你直接照抄建表。表名核心字段说明usersid, name, age, gender, allergy_history, created_at用户基础档案过敏史字段用于药品建议过滤health_recordsid, user_id, modal_type, raw_file_path, parse_status, created_at每次上传的原文记录modal_type 区分文本/图片/PDFparse_resultsid, record_id, item_name, item_value, item_unit, confidenceOCR 或实体抽取的结构化指标一记录对多指标assessment_reportsid, user_id, risk_level, summary, advice, related_docs, model_version, created_at评估报告related_docs 存 RAG 命中的知识库文档 ID后端接口我设计了三个核心端点POST /api/upload接收多模态文件并触发解析POST /api/assess拉取用户最新指标生成评估GET /api/reports查询历史报告。前后端联调时最容易出问题的是parse_results里字段类型不统一——OCR 解析出来的是字符串但数据库设计成了FLOAT插入时经常异常。我的习惯是解析层统一做一次类型转换数值型字段能转float就转转不了就置空保留原文到raw_value彻底避免接口层再做判断。4.3 模型切换的设计模式本地服务与 API 一键切换毕设有一个隐藏风险本地 7B 模型的输出质量不如大厂 API特定问题的回答可能显得「笨」。我的习惯是做模型路由开关而不是硬编码。环境变量LLM_MODElocal走 vLLM 本地服务LLM_MODEapi走通义千问或智谱等云端 API。答辩现场演示用本地模型论文实验章节做效果对比时切到 API两条数据都有。import os mode os.getenv(LLM_MODE, local) if mode api: client LLMClient(modeapi, base_urlhttps://api.xxx.com/v1, api_keyos.getenv(LLM_API_KEY), modelqwen-plus) else: client LLMClient(modelocal)这个切换开关还有一层深意系统提示词保持一致的情况下本地模型和 API 对同一问题的回答差异本身就值得写进论文——本地模型可能需要更强的提示词约束才能达到 API 的遵从度这个「对齐」过程就是你在毕设答辩里能讲深入的点。切换开关让这个对比实验可以一键复现也侧面证明系统设计里模型无关性做得好。我当时就是靠这个设计在答辩时回应了「如果不是用开源模型你的贡献在哪」的追问。5. 避坑与常见问题医疗 LLM 项目里的六个翻车点5.1 模型一本正经地编造诊断结论现象用户上传一份正常范围内的血脂报告LLM 却根据某次 API 测试时的噪声回答给出「动脉粥样硬化高风险」的结论而且表述非常肯定不细看不知道是编的。原因大模型存在幻觉本质是概率采样得出的下一个 Token 并不保证事实正确如果检索知识库片段得分低于阈值仍然强制拼进 Prompt就会放大错误另外系统提示词里没有硬约束输出边界模型在开放生成模式下会「自由发挥」。解决我从两个方向同时堵。一是提示词强制加约束「仅根据报告数值和知识库条目作答禁止推测用户未提供的疾病诊断超出知识范围时回答暂未检索到相关依据」。二是代码侧做内容过滤RAG 检索得分低于 0.45 的片段不参与生成输出文本里命中「确诊」「患有XX病」等高危词时强制降级为「存在相关风险请前往医院进一步检查」。这两层都过了才能呈现给用户。5.2 手机拍的报告 OCR 结果乱码严重现象手机斜着拍的一张检验报告识别出来的文本多处缺字血糖项目的数字从「5.6」变成了「5.e」正则匹配全部落空解析层输出空列表。原因手机拍摄存在透视畸变和反光扫描类文档假设的「平面正拍」前提不成立手机上报告可能还带了复杂背景白色以外的区域会干扰检测框。解决图像预处理先做一次矫正。我在解析层加了两步先用 OpenCV 检测报告单最大外接矩形做透视变换把拍摄角度拉正再对其内区域做自适应二值化增强对比度。透视矫正代码是这个环节的通用做法import cv2 import numpy as np img cv2.imread(report_photo.jpg) gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) # 边缘检测 找最大四边形返回四个角点 box edges cv2.Canny(gray, 50, 150) contours, _ cv2.findContours(edges, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE) cnt max(contours, keycv2.contourArea) rect cv2.minAreaRect(cnt) box cv2.boxPoints(rect).astype(float32) # 透视变换拉正 width, height 800, 1000 dst np.array([[0, 0], [width - 1, 0], [width - 1, height - 1], [0, height - 1]], dtypefloat32) M cv2.getPerspectiveTransform(box, dst) warped cv2.warpPerspective(img, M, (width, height))拉正之后再用 PaddleOCR 识别文本清晰度显著提升。这个坑是血泪经验第一次在线演示时我就因为没做矫正现场拍照测试直接翻车从那以后我所有拍照输入都强制走透视变换流程。5.3 7B 模型在 8GB 显存上 OOM 崩溃现象启动 vLLM 时 GPU 显存直接打满加载模型中途报CUDA out of memory服务进程退出。原因没有量化。7B 模型 FP16 权重约 14GB8GB 显存的显卡物理装不下即使勉强加载前向推理时的 KV Cache 还会再占约 2GB所以必然崩溃。解决换 AWQ 量化权重大小压缩到约 6GB再把--gpu-memory-utilization设置为 0.85运行时占用约 7GB干净落地。如果显卡只有 6GB还有一条退路把--max-model-len降到 4096 减少 KV Cache或用 GPTQ 4bit 量化。更极端的做法是在 CPU 上跑量化后的 4bit 模型但推理一条回答可能要等 20 秒答辩体验会非常差我一般不建议。5.4 知识库里明明有正确答案检索却找不到现象用户问「糖尿病人能不能吃柚子」知识库里明确有「柚子含糖量较低但服用降糖药期间需谨慎」系统却回答「未检索到相关信息」。原因embedding 模型把「糖尿病」和「柚子」在向量空间里的距离拉得较远。通用中文 embedding 模型是在网页文本上训练的对医学概念和食物属性的语义关联表达很弱此外如果查询是整句话没有做关键词拆分长句语义会被无关词稀释。解决检索策略从「单查询向量」升级为「多向量候选集」。把用户问题用命名实体识别拆成「糖尿病、柚子」两个词分别向量化检索各取 top 4 合并去重后再进行重排序同时扩充一个医学同义词表把「血糖高/糖尿病」「吃/食用」等常见等价表达在检索前做统一替换。这个优化投入产出比很高十来行代码检索命中率明显提升。5.5 演示现场模型答偏提前准备的三条兜底路径现象答辩演示时现场网络环境切换导致本地 vLLM 服务端口被防火墙拦截测试题答出一半就连接失败。原因本地服务绑定 8000 端口演示环境无线网络有隔离策略另外演示机器的 GPU 在长时间待机后可能触发驱动重启服务进程死掉没人发现。解决演示前 15 分钟强制走一遍健康检查curl http://localhost:8000/v1/models确认服务存活、nvidia-smi看 GPU 状态。同时准备一条不依赖网络的演示路径——用提前打包好的离线报告图片和预先跑好的评估结果做界面流转展示即使 LLM 服务挂掉也能展示完整的系统流程。这才是答辩演示永远有后手的关键。6. 论文写作与答辩 PPT把系统讲成能过审的完整故事论文结构直接映射系统实现评审想看的是「需求—设计—实现—验证」闭环。我的建议是五章对应绪论讲健康管理背景和 LLM 应用于医疗的现状关键技术章节写 LLM 原理、多模态融合方法、RAG 和向量检索记得交代为什么选 7B 模型加量化部署而不是直接用 API系统设计章节就是第二章的五层架构加数据库表结构系统实现章节贴 OCR 解析、RAG、推理封装的代码并分析每个参数实验章节做三个验证——RAG 命中率对比有/无检索增强、不同 temperature 下的回答一致性评测、量化前后推理延迟对比。这三组实验数据就是你有别于「纯调 API 的 Demo」的硬证据。答辩 PPT 控制在 12 页页内信息要少而关键。我推荐的页面对应关系是第 1-2 页放背景与核心问题第 3-4 页放系统架构图和数据流第 5-6 页放多模态解析与 RAG 检索模块第 7-8 页放 LLM 推理和量化部署第 9-10 页放演示录屏和评测数据第 11-12 页放创新点总结与展望。每页只留一张架构图或一组对比表文字控制在 3 行以内。评审注意力有限的几分钟内图比代码重要。演示环节有个实际经验现场别用实时问答做主线本地 7B 模型在陌生话题上可能答不漂亮。我的做法是主线用三组预录好的典型病例演示完整流程——报告上传、OCR 解析、RAG 检索、报告生成、风险提示备用一条现场问答路径展示灵活性。主讲人讲到自己做过的量化部署和 RAG 检索调参过程时会比照着 PPT 念稿自然得多。那一年我自己的教训是论文初稿把「多模态融合」写得过于抽象被导师批「没落到代码」后来把流程图替换成 OCR 解析的实际输出片段才通过。从那以后我整理验证结论时必备一张「输入截图-中间结果-最终输出」的对照表让自己的每一层设计都有实打实的数据支撑。希望这份拆解能帮你少走我走过的弯路祝答辩顺利。本文还有配套的精品资源点击获取
