简介毕业设计资源围绕大语言模型与多模态人工智能技术构建健康管理与辅助诊疗系统面向计算机、医学信息工程等专业学生提供从需求分析、系统设计到论文撰写与答辩展示的完整参考。压缩包共247个文件约93.2MB核心包含论文电子版与汇报PPT另有Vue.js前端页面、Flask后端服务、MySQL数据库脚本及RabbitMQ消息队列配置大模型侧基于PyTorch与Transformers框架集成Qwen2.5-3B-Instruct推理能力覆盖数据存储、消息通信与智能问答等关键环节。包内46张jpg界面截图可用于对照系统运行效果多份PDF与设计文档辅助理解架构思路py源码与vue组件按模块组织目录清晰便于按需检索。阅读论文可还原设计决策脉络参照PPT可快速组织答辩内容适合作开题、中期检查及答辩前参考目前已有92人学习下载。1. LLM多模态人工智能的健康管理与辅助诊疗系统毕业设计为什么选“多模态”而不只靠大模型你拿着血常规报告去问通用大模型它只能帮你读字面意思你拍一张舌象照片问它它倒是能说两句可一旦把几十项检验指标和主诉文本放在一起它就不知道先看哪个了。真正的健康管理与辅助诊疗系统本质是一个“信息整合”命题不是“接一个LLM”命题。这套毕业设计题目给出的答案是把文本问诊、语音描述、医学图像、检验指标四路输入汇到同一条推理链路再交给LLM做综合判断最后输出带风险等级的结构化建议。我拆完这套资源和配套论文、汇报PPT之后的直观感受是多模态融合是它的技术难点也是论文工作量和答辩演示里最拿得出手的地方。适合想做医疗AI方向、又不想把毕业设计做成“API调用员”的学生。整套资源覆盖了从系统设计、数据库建模、多模态预处理到RAG检索增强、Prompt编排再到论文成稿和汇报PPT的完整链路。你照着走完能看清医疗场景下“数据入口→特征融合→模型推理→结果输出”的完整形态也能知道哪些环节是真正的工作量哪些环节是纯凑字数。2. 系统架构与技术选型从需求到调用链的落地映射2.1 需求拆解辅助诊疗系统到底在解决什么辅助诊疗不是替代医生下结论而是把医生接诊时看到的文字描述、语音补充、影像资料和检验数值汇总成一份“可讨论的结构化参考意见”。毕业设计层面需求拆成下面几条链路才说得清楚用户描述症状系统支持文字输入和语音输入两种方式用户上传体检报告或拍摄舌象、面相、皮肤照片系统提取可计算的特征系统关联用户历史健康档案按时间维度生成健康趋势LLM依据多模态输入和检索到的医学知识生成辅助诊断建议、生活干预建议和复查提醒所有结果结构化落库支持医生或用户事后回看审计。这套系统的主流程可以表述为“多模态输入采集 → 数据预处理 → 特征融合 → 知识检索 → LLM推理 → 结构化输出”。你在论文的“系统设计”章节里画这条调用链比写一百行功能描述都直观。这里要提醒你一个习惯问题别在一开始就陷入“模型选多大”的纠结。毕业设计的核心评价点是“完整度”和“可解释性”。导师想看到的是你理解每个环节为什么存在而不是你调了一个多牛的模型。2.2 技术选型为什么是RAG多模态而不是单一模型先看一张我常用的对比表这张表可以直接改写进论文的“技术选型分析”小节对比维度纯LLM问答方案RAG多模态融合方案输入形态仅文本文本、语音、图像、表格指标医学知识时效性依赖模型训练数据容易过时知识库独立更新可控性强幻觉风险高医学场景不可接受中低检索结果可追溯输出可解释性低无法定位依据高可展示知识来源毕业设计工作量偏少答辩容易空洞适中每一章都有实体内容部署成本低可控向量库可本地部署这里的选择逻辑很明确医学是高风险领域LLM的幻觉问题不是靠“微调”能解决的。微调在本科毕设里成本极高——需要标注数据、GPU资源和大量实验时间而且微调之后依然无法解决时效性问题。RAG则把“模型能力”和“知识来源”解耦你可以在不重训模型的情况下把最新版药品说明书、检验指标参考区间塞进知识库。技术栈方面我的习惯是后端用 Python FastAPI前端用 Vue3 或微信小程序二选一。数据库用 MySQL 存用户档案和诊断记录向量库用 Milvus 或 Chroma 存知识库切片。大模型接口统一走一个 middleware 网关便于切换不同服务商避免答辩当天某一家 API 不可用导致整个演示凉掉。2.3 数据库设计健康档案、检查记录与知识库的三层结构数据库是这套系统里最容易被忽视但论文里最好写的一部分。我建议至少设计三组核心表用户健康档案主表、每次咨询的检查记录表、辅助诊疗结论表。-- 用户健康档案表存储基础信息和历史病史 CREATE TABLE user_profile ( id INT PRIMARY KEY AUTO_INCREMENT, user_name VARCHAR(64) NOT NULL, age INT, gender TINYINT COMMENT 0-男 1-女 2-未知, height_cm DECIMAL(5,1), weight_kg DECIMAL(5,1), allergy_history TEXT COMMENT 过敏史支持逗号分隔多个条目, chronic_disease TEXT COMMENT 慢性病史高血压/糖尿病/其他, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 咨询检查记录表一次咨询对应一条主记录和N条多模态附件 CREATE TABLE consult_record ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, consult_time DATETIME, symptom_text TEXT COMMENT 主诉文本一段话描述症状, voice_transcript TEXT COMMENT 语音转写后的文本, image_paths JSON COMMENT 上传图像的文件路径列表, lab_indicator JSON COMMENT 检验指标的JSON结构化字段, status TINYINT DEFAULT 0 COMMENT 0-处理中 1-已完成 2-失败, FOREIGN KEY (user_id) REFERENCES user_profile(id) ); -- 辅助诊疗结论表LLM输出落库支持审计回溯 CREATE TABLE diagnosis_result ( id INT PRIMARY KEY AUTO_INCREMENT, consult_id INT NOT NULL, risk_level TINYINT COMMENT 1-低风险 2-中风险 3-高风险, summary TEXT COMMENT LLM生成的综合判断摘要, suggestions JSON COMMENT 结构化建议列表用药提醒/生活方式/复查建议, references JSON COMMENT 知识库来源引用用于可追溯, model_name VARCHAR(64) COMMENT 本次调用的模型标识, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (consult_id) REFERENCES consult_record(id) );image_paths用文件路径列表而不用二进制存库是工程经验和论文双重考虑的结论图片在数据库里只保留路径实际文件走独立存储目录或 OSS既方便清洗调试也能避免数据库膨胀。lab_indicator用 JSON 是因为不同体检机构的项目名称千差万别结构化字段在毕业论文里反而难以覆盖所有场景。diagnosis_result里单独留一个model_name字段答辩时如果你想对比不同模型的效果这条字段能帮你省很多事。3. 多模态数据接入与预处理文本、语音、图像、检验指标的四路融合3.1 文本与语音问诊信息的清洗与转写文本是最基础的一路输入但它的坑不在“接进去”而在“怎么洗”。用户输入的主诉文本通常口语化严重夹杂着错别字、网络用语和大量无用信息。我一般会做三层清洗第一层正则去掉表情符号和重复标点第二层做同义替换比如把“有点难受”归一化成“不适”第三层做症状关键词提取抽取出部位、持续时间、疼痛性质等字段。语音输入在毕设里常被做成“看起来有实际不解释”的黑匣子这其实是论文里可以浓墨重彩写的一块。语音转写我一般接 Whisper 或云厂商 ASR但关键点在于转写后的文本不能直接进模型要做置信度处理。import re import json def normalize_symptom_text(raw_text: str) - dict: 清洗主诉文本提取结构化症状要素 返回JSON方便后续拼接Prompt # 去掉表情符号匹配常见emoji范围直接替换为空 emoji_pattern re.compile( [\U0001F600-\U0001F64F\U0001F300-\U0001F5FF\U0001F680-\U0001F6FF], flagsre.UNICODE ) text emoji_pattern.sub(, raw_text) # 去除多余空白和重复标点 text re.sub(r\s, , text).strip() text re.sub(r[。!?]{2,}, 。, text) # 用简单规则抽取症状片段按标点切分过滤过短片段 segments [seg for seg in re.split(r[,。;], text) if len(seg) 2] # 同义归一化映射表按需求自行扩充 synonym_map { 有点难受: 轻微不适, 特别疼: 剧烈疼痛, 老犯困: 嗜睡, 没力气: 乏力 } segments [synonym_map.get(seg, seg) for seg in segments] return { cleaned_text: .join(segments), segment_count: len(segments), segments: segments } # 调用示例模拟用户输入 sample_input 最近老犯困没力气偶尔还有点难受食欲也一般般... result normalize_symptom_text(sample_input) print(json.dumps(result, ensure_asciiFalse, indent2))这段代码里有三个参数值得你在答辩时展开讲emoji_pattern的unicode范围匹配处理的是用户从手机粘贴文本时夹带的符号re.sub(r[。!?]{2,}, 。, text)把多个终止符压缩成一个避免LLM把重复标点当作信息密度segment_count过滤单字碎片防止像“疼”这样的单字被单独作为一段输入。语音转写文本走的也是同一套清洗逻辑之后可以和手动输入统一处理。语音分支还有一个容易翻车的细节转写结果的置信度。Whisper 这类工具对普通话的识别率在安静环境下还行但用户一旦站在嘈杂环境里转写文本里经常出现同音错字。我会在转写后加一个简单的“医学术语纠错表”把“心慌”误写成“星荒”这类错误用映射表纠正回来。这个纠错表只有几十条但足以让答辩时的语音演示效果稳一大截。3.2 医学图像从舌象照片到可计算的特征描述图像输入放在这套系统里最合适的入口是舌象和面色判断这也是中医诊断里成熟度比较高的方向。我不建议直接让LLM“看”图片——目前的LLM视觉接口对医学图像的编码细节理解有限而且你要在论文里写清楚特征提取算法直接丢给大模型反而没什么可写。我采用的是双路方案第一路用OpenCV做传统特征提取计算舌色、舌苔厚薄的HSV分布特征第二路把关键特征文本化后拼进Prompt。这样做的好处是让LLM基于“描述”而非“原始像素”推理可控性强得多。import cv2 import numpy as np def extract_tongue_features(image_path: str) - dict: 提取舌象HSV颜色特征 返回舌色倾向和舌苔厚薄的量化描述 img cv2.imread(image_path) if img is None: return {error: image not found} # 统一缩放到固定尺寸减少不同设备拍照的尺度差异 img cv2.resize(img, (224, 224), interpolationcv2.INTER_AREA) # 转HSV色彩空间医学图像常用HSV而非RGB做色相分析 hsv cv2.cvtColor(img, cv2.COLOR_BGR2HSV) # 划分舌体区域简化版本用中心60%区域近似实际可用分割模型 h, w, _ hsv.shape roi hsv[int(h*0.2):int(h*0.8), int(w*0.2):int(w*0.8)] h_channel roi[:, :, 0].flatten() s_channel roi[:, :, 1].flatten() v_channel roi[:, :, 2].flatten() # 统计H通道均值OpenCV中H范围0-179红色约0-10和170-179 avg_hue np.mean(h_channel) avg_sat np.mean(s_channel) avg_val np.mean(v_channel) # 按阈值规则给出文本描述避免直接把数值丢给LLM if avg_hue 10 or avg_hue 165: tongue_color 偏红 elif avg_hue 25: tongue_color 偏黄 else: tongue_color 偏淡 if avg_sat 100: coating 舌苔较厚 elif avg_sat 60: coating 舌苔中等 else: coating 舌苔较薄 return { tongue_color: tongue_color, coating: coating, avg_hue: round(float(avg_hue), 2), avg_sat: round(float(avg_sat), 2) }cv2.resize用INTER_AREA而不是默认的INTER_LINEAR是因为插值算法直接关系到后续色彩统计的稳定性。ROI区域取中心60%是为了减少嘴唇、牙齿和背景对色相统计的干扰。H通道的阈值判断标准不追求医学精确但足以在论文里展示一套“规则可解释”的特征提取流程。你如果后续想改进可以把ROI提取换成轻量级分割模型这块写进“未来展望”里会让论文的延展性更好。3.3 检验指标规则校验与异常标记检验指标是四路输入中“数值密集度”最高的一路也是最容易出乱子的。用户上传一张体检报告照片OCR识别出来的数字经常缺单位或错位直接塞给LLM会产生离谱幻觉。我在这路输入上坚持“宁缺毋滥”的原则先做规则校验不合格的字段宁可丢弃也不能硬传给模型。def validate_lab_indicators(indicators: dict) - dict: 校验检验指标单位归一化 范围合法性判断 异常标记 输入格式: {项目: {value: 数值, unit: 单位}} REFERENCE_RANGES { 白细胞计数: (4.0, 10.0), # 单位: 10^9/L 血红蛋白: (120.0, 160.0), # 单位: g/L 空腹血糖: (3.9, 6.1), # 单位: mmol/L 甘油三酯: (0.4, 1.7) # 单位: mmol/L } UNITS { 白细胞计数: 10^9/L, 血红蛋白: g/L, 空腹血糖: mmol/L, 甘油三酯: mmol/L } validated {} for item, data in indicators.items(): if item not in REFERENCE_RANGES: continue value float(data[value]) unit data.get(unit, ) # 物理合理性检查数值不可能为负数或超出人类极限 if value 0 or value 2000: print(f[WARN] 非法数值: {item}{value}) continue low, high REFERENCE_RANGES[item] # 异常标记低于下限/高于上限/正常 if value low: status low elif value high: status high else: status normal validated[item] { value: value, unit: UNITS[item], status: status, reference: f{low}-{high} } return validated这个函数的核心价值体现在三处REFERENCE_RANGES定义的是“参考范围”论文里必须标注来源是临床指南或教材不能自己编物理合理性检查里的value 2000是兜底过滤防OCR识别错位status字段设计成low/high/normal三态而非直接写“异常”是把判断权留给LLM系统只做数据标记。异常标记之后的融合策略也很关键不是所有维度都要喂给LLM。我的原则是“有异常才强调正常值只做概要”。当检验指标超过10项时如果全部拼接进PromptLLM的注意力会被正常值稀释。我会把异常项单独挑出加上一句“以下指标超出参考范围”再附带全部指标的JSON概要。4. 核心诊疗引擎Prompt编排、医学知识库与LLM的协作4.1 从多模态输入到结构化Prompt特征怎么喂给模型这是整套系统技术含量最高的模块。LLM本身不理解“多模态”它只理解文本。所以你的工程能力体现在把四种输入形态统一转成文本特征并用一种让LLM容易遵循的结构排列出来。我习惯把Prompt分成四段系统角色定义、当前用户状态、知识库检索结果可选、输出格式约束。下面是一个可替换的构造函数def build_medical_prompt( user_profile: dict, cleaned_symptom: str, tongue_features: dict, lab_indicators: dict, retrieved_knowledge: list ) - str: 构造最终发送给LLM的Prompt retrieved_knowledge: RAG检索结果切片列表 # 第一段角色定位——明确边界禁止越权诊断 system_role ( 你是一名健康管理助手你的任务是基于用户提供的主诉、 体征数据和检验指标给出健康风险提示与就医建议。 你不是执业医师不能给出确诊结论。若信息不足 必须主动询问或建议就医。 ) # 第二段用户基础档案摘要 user_summary ( f用户年龄{user_profile[age]}岁 f性别{男 if user_profile[gender] 0 else 女} f身高{user_profile[height_cm]}cm f体重{user_profile[weight_kg]}kg。 ) if user_profile.get(chronic_disease): user_summary f既往病史{user_profile[chronic_disease]}。 # 第三段症状、舌象、检验指标 status_block ( f主诉症状{cleaned_symptom}\n f舌象特征{tongue_features.get(tongue_color, 未知)} f{tongue_features.get(coating, 未知)}\n f检验指标关注异常项\n ) # 只把异常指标详细列出正常项一笔带过 for item, detail in lab_indicators.items(): if detail[status] ! normal: status_block ( f- {item}: {detail[value]} {detail[unit]} f(参考范围 {detail[reference]}) [异常{detail[status]}]\n ) # 第四段RAG检索到的参考知识 knowledge_block if retrieved_knowledge: knowledge_block 以下是检索到的医学参考资料请优先依据它们\n for i, doc in enumerate(retrieved_knowledge[:3], 1): knowledge_block f[{i}] {doc}\n # 第五段输出格式硬约束 output_constraint ( 请按以下JSON格式输出不要输出额外解释\n {\risk_level\: \low|medium|high\, \summary\: \综合判断摘要\, \suggestions\: [\建议1\, \建议2\], \need_doctor\: true} ) prompt \n.join([ system_role, 用户档案 user_summary, 当前状态 status_block, knowledge_block, output_constraint ]) return prompt这段代码的设计意图是让LLM明确三件事第一它不能被当做人——system_role里的“不能给出确诊结论”既是产品合规要求也是论文里“安全性设计”章节的素材第二它的注意力被引导到异常项而非全部数据——[异常high]这种显式标记比单纯数值更能触发模型的敏感度第三它的输出被强制约束成JSON——这样后续才能自动化解析、落库到diagnosis_result表。这里有一个经验性的细节suggestions字段我故意用中文键而非英文字段因为绝大多数中文医疗语料训练出的模型对中文JSON键名的一致性更好如果你用riskLevel这种驼峰格式偶尔会出现模型输出和你的解析代码不匹配的问题。4.2 知识库检索与召回让LLM依据指南而不是凭空编RAG模块在毕设里的实现并不需要多高的复杂度但需要把链路跑通。我在这个系统里用的检索链路是医学文档 → 文本切片 → Embedding向量化 → 向量检索 → TopK结果拼进Prompt。切片策略是RAG工程里最玄学的部分但也是论文里最好写参数分析的部分。我的默认配置是切片大小500字符重叠50字符。太大切片内容容易被无关信息稀释太小语义不完整。重叠50字符是为了避免恰好把一个完整概念切断在切片边界。from typing import List def chunk_text(doc: str, chunk_size: int 500, overlap: int 50) - List[str]: 文本切片函数按段落优先、长度兜底的策略 paragraphs doc.split(\n) chunks [] current for para in paragraphs: # 段落过长时强制按固定窗口切分 if len(para) chunk_size: for i in range(0, len(para), chunk_size - overlap): chunks.append(para[i:i chunk_size]) continue # 当前累积加段落仍小于切片上限继续累积 if len(current) len(para) 1 chunk_size: current para \n else: # 先把当前切片截断到上限然后保留重叠部分重新累积 chunks.append(current[:chunk_size]) tail current[-overlap:] if overlap 0 else current tail para \n if current.strip(): chunks.append(current[:chunk_size]) return chunks这个切片函数的关键在于“段落优先”策略先按换行符切段只有段落长度超过阈值时才硬切。这样做比纯按字符长度切片的效果明显要好因为医学文档的段落本身就承载了完整语义。知识库的内容从哪里来毕设场景里最方便的是把《内科学》常见病章节的电子版、药品说明书公开数据、以及体检报告常见指标解读整理成Markdown文档按疾病类型分目录存放。这里有一个合规细节论文里要写清楚知识来源不要直接引用受版权保护的整本教材。我一般建议用公开指南摘要和科普级别内容答辩时更安全。4.3 输出后校验与LLM-as-judge让演示结果可复现把模型输出直接落库不是好习惯。我一般会在模型返回后加三道校验第一道是JSON语法解析校验很多模型偶尔会输出多余的前导文字或末尾句号解析失败就要求模型重试一次第二道是枚举字段校验比如risk_level必须严格是low/medium/high之一出现其他值就抛出不兼容错误第三道是规则校验比如用户所有指标正常且主诉为“无不适”时risk_level不应为high。这三道校验可以在论文里写成“输出鲁棒性设计”是一块能体现工程素养的内容。每次从模型返回的结果都先过这三个关卡过了才写入diagnosis_result表不过就触发自动重试。LLM-as-judge 是最近在AI应用层非常流行的质量验证方法放在这里用性价比极高拿一个额外的模型可以是同一个模型的另一个实例也可以是一个轻量模型去给主模型的输出打分判断是否有逻辑矛盾或遗漏关键项。这在答辩演示时是个很漂亮的加分项——你可以在PPT里放两列主模型的输出、评判模型的打分。import json def validate_and_judge(model_output: str) - dict: 输出后处理先解析JSON再规则校验 # 清理模型输出中的多余字符兼容常见非严格JSON cleaned model_output.strip() if cleaned.startswith(json): cleaned cleaned[7:-3].strip() if cleaned.endswith(): cleaned cleaned[:-3].strip() try: result json.loads(cleaned) except json.JSONDecodeError as e: return {valid: False, error: fJSON解析失败: {e}} # 枚举校验 if result.get(risk_level) not in [low, medium, high]: return {valid: False, error: f非法风险等级: {result.get(risk_level)}} if suggestions not in result or not isinstance(result[suggestions], list): return {valid: False, error: 缺少suggestions列表} if not isinstance(result.get(need_doctor), bool): return {valid: False, error: need_doctor必须为布尔值} return {valid: True, result: result}这一步能过滤掉约5%~10%的不稳定输出。答辩前用固定测试集跑一遍所有输出都无异常时演示才不会有“现场翻车”的风险。5. 毕业设计避坑与排查从数据到答辩的五个高频翻车点5.1 多模态接口超时前端频繁报错现象图像上传后前端等很久没有响应最后直接超时语音转写偶尔也卡住用户以为系统崩了。原因这三个操作都是计算密集型的——图片特征提取、ASR转写、LLM推理——如果后端是同步阻塞逻辑一个请求占住线程其他请求全部排队。解决把耗时操作全部改为异步任务。后端用FastAPI的BackgroundTasks或独立的消息队列Celery或简单的Redis队列前端提交后先拿到一个任务ID然后轮询或WebSocket推送结果。我的做法是更粗暴但更稳的方案图片和语音预处理直接同步执行控制在500ms以内LLM推理设计为30秒超时配合前端loading文案“AI医生正在分析请稍候”用户在这个场景下普遍有耐心等10秒以上。5.2 同样的输入两次给的结论不一样现象答辩前一天演示还很正常第二天跑同一个测试用例输出的建议内容变了甚至风险等级都不同。原因大模型推理本身带有随机性temperature参数没有设置为0或者远程API在频繁请求时自动调整了采样参数。解决所有医疗场景的推理请求temperature固定设为0或接近0的值关闭随机采样同时把随机种子seed固定。如果你调用的是云端API要看服务商文档确认是否支持seed参数。还有一招后悔药把每次的模型输出连同输入一起存库答辩时如果评委要求看一致性直接展示历史记录比口头解释更有说服力。5.3 RAG检索总召回不到相关内容医疗回答出现幻觉现象知识库里明明有高血压管理章节用户问“血压高怎么办”检索结果却返回了“糖尿病饮食建议”最后LLM给出的答案出现明显编造。原因最常见的根源是切片时把大标题和正文切断了Embedding向量丢失了语义锚点。比如“高血压”这个标题落在切片A末尾“患者饮食建议”落在切片B开头切片B的向量就无法和查询建立关联。解决把文档切片策略从“按长度硬切”改成“按语义块切”。保留Markdown各级标题作为切片的元数据在切片内容前面拼上标题路径。这个做法在向量检索里叫做metadata augmentation用大白话说就是让每个切片知道自己属于哪一章检索时顺手过滤掉不属于该疾病章节的无关结果。5.4 答辩演示时网络波动整个系统瘫掉现象到了演示节点访问大模型API的请求超时或返回限流错误前端白屏演示中断。原因毕业设计答辩现场用的往往是大楼公用WiFi对境外或高并发API的限制很严格而且现场多人同时用网带宽极不稳定。解决准备两层降级方案。第一层是本地模型兜底——在答辩用的笔记本上部署一个小模型比如几GB的量化模型网络API失败时自动切换到本地推理速度稍慢但能跑通全流程。第二层是“预录演示视频”法把完整操作流程提前录制成高清视频放在本地现场如果网络确实不行直接播放视频并同步讲解。这两层方案我都试过实际体验上本地模型兜底更自然评委不会觉得你在逃避演示。5.5 论文查重偏高AI生成的痕迹明显现象论文提交查重后重复率超过30%标注的AI痕迹检测为高风险。原因毕设系统相关的章节用了太多套话模板比如“随着人工智能技术的飞速发展”这类开头在知网库里同质化严重加上从LLM生成内容里直接摘录的段落未改写。解决论文叙事从“技术栈罗列”改成“问题驱动”。每一章开头先写“这里遇到了什么问题现有方案为什么不够”再写“我采用了什么方案参数怎么定的”。比如第2章不要写“该系统采用FastAPI框架”改写成“最初使用Flask搭建后端但异步任务增多后出现阻塞现象调研后改用FastAPI的异步支持”。叙述方式的变化会显著降低查重率同时让论文看起来有真实决策过程。6. 从系统到答辩固定测试用例与汇报PPT的关键技巧6.1 固定测试集一致性验证与效果演示两用系统开发完成后我强烈建议你建一个固定测试集至少包含10~20个病例场景。每个场景写清楚四路输入的标准值主诉文本、语音转写文本、舌象描述特征、检验指标JSON、预期输出等级。这个测试集有三个用途。第一功能性回归测试——每次改完代码后跑一遍确保没有把之前能跑通的场景改坏。第二一致性验证——固定temperature0后连续跑三次相同输入检查输出是否一致。第三答辩演示素材——挑其中3个最典型的病例做演示路径一个低风险、一个中风险、一个高风险覆盖全部输出形态。我设计测试集时有一条血泪经验不要只设计“典型症状”用例也一定要混入“信息不足”的用例。比如只给一句“我最近睡不好”没有补充数据系统应返回“需要更多症状细节建议补充睡眠时长、是否伴有其他不适”而不是硬着头皮给建议。这种信息不足场景的处理方式往往是答辩时评委最欣赏的部分因为大多数人的毕设都做成了“有输入必输出”的机器人。6.2 PPT叙事线让评委在5分钟里看清你的工作量汇报PPT是毕业设计的最终呈现载体大多数人会犯同一个毛病按系统模块一页一页平铺上来讲数据库建了几张表中间贴代码截图最后放运行截图。这种PPT的信息密度很低评委看不出你的思考。我用的叙事线是“痛点→矛盾→方案→实证”四段式。开头第一页直接抛出一个场景用户拿着一份体检报告和一张舌象照片面对通用大模型得到的回答是孤立的、割裂的无法形成综合判断。第二页指出当前方案的局限——纯LLM有幻觉且不消化多模态输入微调又成本过高。第三页亮出你的系统架构图重点标注“多模态预处理RAG结构化输出”这条主线。之后每一页都在回答“这个模块解决了上一页的哪个矛盾”。PPT里有一个细节技巧值得压轴使用放一张“接口调用参数表”列出不同temperature值和不同TopK检索数量下同一测试用例的生成结果对比。这张表直观展现了你不只是把模型接进去还做了参数级别的测试与调优。论文里同样的数据放在实验章节简直是一鱼两吃。这次做这个项目到最后我已经记不清为 RAG 召回率低调了多少次切片参数半夜盯着日志看“知识库检索为空”的报错看了多少遍。但有一段代码习惯我始终没丢所有配置项——切片大小、重叠长度、temperature、seed、参考范围阈值——全部集中在一个config.yaml里每次实验换参都强制记录一条实验日志。答辩时评委问我“你这些参数是拍脑袋定的吗”我直接翻出实验日志表横竖都是一张表说服力远超口头解释。希望你做完这个项目之后也把“留实验记录”的习惯带走它比这一个毕设项目本身更值钱。希望帮到你。本文还有配套的精品资源点击获取