LLM+多模态+RAG：健康管理辅助诊疗系统毕设全解析

简介：一份面向高校人工智能、计算机相关专业毕业设计场景的完整作品包，主题是基于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_cls=True 开启方向分类，处理倾斜照片；lang="ch" 指定中文模型 ocr = PaddleOCR(use_angle_cls=True, lang="ch", show_log=False) result = ocr.ocr("blood_report.jpg", cls=True) # 把 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_cls=True会多跑一个方向分类模型，推理时间增加约 30%，但对拍照歪斜的报告识别率提升非常明显，健康场景下我不建议关掉，40ms 的额外耗时可以接受。show_log=False是防止 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), encoding="utf-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_embeddings=True) embeddings = embeddings.astype("float32") # 内积检索配合归一化向量，效果等价于余弦相似度，FAISS 推荐组合 index = faiss.IndexFlatIP(embeddings.shape[1]) index.add(embeddings)

文本切块参数直接影响检索质量。块太小会截断语义，块太大检索噪声多，我在这个项目里用的经验值是 512 字切一块、相邻重叠 64 字，这样既能保证一个完整知识点落在同一块，又不会因为硬切导致「上句没说完下块才开始」。如果你做的是药品说明书类强结构化文档，可以换成按条目切分，效果更好，但那个方案泛化性差，换文档类型又要重写。

normalize_embeddings=True配合IndexFlatIP是关键组合——所有向量归一化后再做内积，得到的值域就是余弦相似度[-1, 1]，排序阈值有直观含义，我一般设置检索得分低于 0.45 的结果直接丢弃，宁可答「知识库中暂未找到相关信息」，也不要把不相关片段喂给模型产生幻觉。查询时还有两个系数要保留给调参：top_k取 4 到 6 比较平衡，超过 8 后 Prompt 过长且噪声累积明显；查询向量也要做同样的normalize_embeddings=True，否则得分分布不可比。

3.3 LLM 推理封装：统一客户端与医疗场景提示词约束

推理层是系统的中枢，我要把它封装成一个只暴露assess()方法的类，内部同时支持本地 vLLM 服务和远程 API，这样后面换模型不用动任何业务代码。vLLM 服务启动后提供 OpenAI 兼容接口，所以客户端可以用官方openaiSDK 直接连。

from openai import OpenAI class LLMClient: def __init__(self, mode="local", base_url="http://localhost:8000/v1", api_key="EMPTY", model="Qwen2.5-7B-Instruct"): self.client = OpenAI(base_url=base_url, api_key=api_key) self.model = model def assess(self, context: dict) -> str: # 医疗场景强制低温度，保证多次回答一致性 resp = self.client.chat.completions.create( model=self.model, temperature=0.2, top_p=0.7, max_tokens=512, messages=[ {"role": "system", "content": MEDICAL_SYSTEM_PROMPT}, {"role": "user", "content": build_user_message(context)} ] ) return resp.choices[0].message.content

temperature=0.2不是随便拍的。医疗辅助场景对回答一致性要求很高，同一个报告问两次，不能一次说「偏高」一次说「偏正常」。我在调试时明显感觉到 temperature 超过 0.5 后采样随机性主导，0.1 到 0.2 之间能兼顾确定性和少量表达多样性。max_tokens=512是为了限制输出长度，健康建议场景不需要长篇大论，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 量化把权重压到 4bit，7B 模型显存占用从约 14GB 降到 6GB 上下，让 8GB 显存的消费级显卡也能跑。--dtype float16配合 awq 使用时保持半精度计算，速度和质量折中最好。--max-model-len 8192控制上下文窗口——我们的 RAG 检索结果加系统提示词和历史对话加一起通常不超过 3000 Token，8192 足够同时留下冗余。

--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 串联。下面这张表结构是论文数据库设计章节的直接素材，也方便你直接照抄建表。

后端接口我设计了三个核心端点：POST /api/upload接收多模态文件并触发解析，POST /api/assess拉取用户最新指标生成评估，GET /api/reports查询历史报告。前后端联调时最容易出问题的是parse_results里字段类型不统一——OCR 解析出来的是字符串，但数据库设计成了FLOAT，插入时经常异常。我的习惯是解析层统一做一次类型转换：数值型字段能转float就转，转不了就置空保留原文到raw_value，彻底避免接口层再做判断。

4.3 模型切换的设计模式：本地服务与 API 一键切换

毕设有一个隐藏风险：本地 7B 模型的输出质量不如大厂 API，特定问题的回答可能显得「笨」。我的习惯是做模型路由开关而不是硬编码。环境变量LLM_MODE=local走 vLLM 本地服务，LLM_MODE=api走通义千问或智谱等云端 API。答辩现场演示用本地模型，论文实验章节做效果对比时切到 API，两条数据都有。

import os mode = os.getenv("LLM_MODE", "local") if mode == "api": client = LLMClient(mode="api", base_url="https://api.xxx.com/v1", api_key=os.getenv("LLM_API_KEY"), model="qwen-plus") else: client = LLMClient(mode="local")

这个切换开关还有一层深意：系统提示词保持一致的情况下，本地模型和 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, key=cv2.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]], dtype="float32") 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 权重约 14GB，8GB 显存的显卡物理装不下；即使勉强加载，前向推理时的 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 解析的实际输出片段才通过。从那以后我整理验证结论时，必备一张「输入截图-中间结果-最终输出」的对照表，让自己的每一层设计都有实打实的数据支撑。希望这份拆解能帮你少走我走过的弯路，祝答辩顺利。

本文还有配套的精品资源，点击获取