簡介畢業(yè)設(shè)計資源圍繞大語言模型與多模態(tài)人工智能技術(shù)構(gòu)建健康管理與輔助診療系統(tǒng)面向計算機、醫(yī)學(xué)信息工程等專業(yè)學(xué)生提供從需求分析、系統(tǒng)設(shè)計到論文撰寫與答辯展示的完整參考。壓縮包共247個文件約93.2MB核心包含論文電子版與匯報PPT另有Vue.js前端頁面、Flask后端服務(wù)、MySQL數(shù)據(jù)庫腳本及RabbitMQ消息隊列配置大模型側(cè)基于PyTorch與Transformers框架集成Qwen2.5-3B-Instruct推理能力覆蓋數(shù)據(jù)存儲、消息通信與智能問答等關(guān)鍵環(huán)節(jié)。包內(nèi)46張jpg界面截圖可用于對照系統(tǒng)運行效果多份PDF與設(shè)計文檔輔助理解架構(gòu)思路py源碼與vue組件按模塊組織目錄清晰便于按需檢索。閱讀論文可還原設(shè)計決策脈絡(luò)參照PPT可快速組織答辯內(nèi)容適合作開題、中期檢查及答辯前參考目前已有92人學(xué)習(xí)下載。1. LLM多模態(tài)人工智能的健康管理與輔助診療系統(tǒng)畢業(yè)設(shè)計為什么選“多模態(tài)”而不只靠大模型你拿著血常規(guī)報告去問通用大模型它只能幫你讀字面意思你拍一張舌象照片問它它倒是能說兩句可一旦把幾十項檢驗指標(biāo)和主訴文本放在一起它就不知道先看哪個了。真正的健康管理與輔助診療系統(tǒng)本質(zhì)是一個“信息整合”命題不是“接一個LLM”命題。這套畢業(yè)設(shè)計題目給出的答案是把文本問診、語音描述、醫(yī)學(xué)圖像、檢驗指標(biāo)四路輸入?yún)R到同一條推理鏈路再交給LLM做綜合判斷最后輸出帶風(fēng)險等級的結(jié)構(gòu)化建議。我拆完這套資源和配套論文、匯報PPT之后的直觀感受是多模態(tài)融合是它的技術(shù)難點也是論文工作量和答辯演示里最拿得出手的地方。適合想做醫(yī)療AI方向、又不想把畢業(yè)設(shè)計做成“API調(diào)用員”的學(xué)生。整套資源覆蓋了從系統(tǒng)設(shè)計、數(shù)據(jù)庫建模、多模態(tài)預(yù)處理到RAG檢索增強、Prompt編排再到論文成稿和匯報PPT的完整鏈路。你照著走完能看清醫(yī)療場景下“數(shù)據(jù)入口→特征融合→模型推理→結(jié)果輸出”的完整形態(tài)也能知道哪些環(huán)節(jié)是真正的工作量哪些環(huán)節(jié)是純湊字?jǐn)?shù)。2. 系統(tǒng)架構(gòu)與技術(shù)選型從需求到調(diào)用鏈的落地映射2.1 需求拆解輔助診療系統(tǒng)到底在解決什么輔助診療不是替代醫(yī)生下結(jié)論而是把醫(yī)生接診時看到的文字描述、語音補充、影像資料和檢驗數(shù)值匯總成一份“可討論的結(jié)構(gòu)化參考意見”。畢業(yè)設(shè)計層面需求拆成下面幾條鏈路才說得清楚用戶描述癥狀系統(tǒng)支持文字輸入和語音輸入兩種方式用戶上傳體檢報告或拍攝舌象、面相、皮膚照片系統(tǒng)提取可計算的特征系統(tǒng)關(guān)聯(lián)用戶歷史健康檔案按時間維度生成健康趨勢LLM依據(jù)多模態(tài)輸入和檢索到的醫(yī)學(xué)知識生成輔助診斷建議、生活干預(yù)建議和復(fù)查提醒所有結(jié)果結(jié)構(gòu)化落庫支持醫(yī)生或用戶事后回看審計。這套系統(tǒng)的主流程可以表述為“多模態(tài)輸入采集 → 數(shù)據(jù)預(yù)處理 → 特征融合 → 知識檢索 → LLM推理 → 結(jié)構(gòu)化輸出”。你在論文的“系統(tǒng)設(shè)計”章節(jié)里畫這條調(diào)用鏈比寫一百行功能描述都直觀。這里要提醒你一個習(xí)慣問題別在一開始就陷入“模型選多大”的糾結(jié)。畢業(yè)設(shè)計的核心評價點是“完整度”和“可解釋性”。導(dǎo)師想看到的是你理解每個環(huán)節(jié)為什么存在而不是你調(diào)了一個多牛的模型。2.2 技術(shù)選型為什么是RAG多模態(tài)而不是單一模型先看一張我常用的對比表這張表可以直接改寫進(jìn)論文的“技術(shù)選型分析”小節(jié)對比維度純LLM問答方案RAG多模態(tài)融合方案輸入形態(tài)僅文本文本、語音、圖像、表格指標(biāo)醫(yī)學(xué)知識時效性依賴模型訓(xùn)練數(shù)據(jù)容易過時知識庫獨立更新可控性強幻覺風(fēng)險高醫(yī)學(xué)場景不可接受中低檢索結(jié)果可追溯輸出可解釋性低無法定位依據(jù)高可展示知識來源畢業(yè)設(shè)計工作量偏少答辯容易空洞適中每一章都有實體內(nèi)容部署成本低可控向量庫可本地部署這里的選擇邏輯很明確醫(yī)學(xué)是高風(fēng)險領(lǐng)域LLM的幻覺問題不是靠“微調(diào)”能解決的。微調(diào)在本科畢設(shè)里成本極高——需要標(biāo)注數(shù)據(jù)、GPU資源和大量實驗時間而且微調(diào)之后依然無法解決時效性問題。RAG則把“模型能力”和“知識來源”解耦你可以在不重訓(xùn)模型的情況下把最新版藥品說明書、檢驗指標(biāo)參考區(qū)間塞進(jìn)知識庫。技術(shù)棧方面我的習(xí)慣是后端用 Python FastAPI前端用 Vue3 或微信小程序二選一。數(shù)據(jù)庫用 MySQL 存用戶檔案和診斷記錄向量庫用 Milvus 或 Chroma 存知識庫切片。大模型接口統(tǒng)一走一個 middleware 網(wǎng)關(guān)便于切換不同服務(wù)商避免答辯當(dāng)天某一家 API 不可用導(dǎo)致整個演示涼掉。2.3 數(shù)據(jù)庫設(shè)計健康檔案、檢查記錄與知識庫的三層結(jié)構(gòu)數(shù)據(jù)庫是這套系統(tǒng)里最容易被忽視但論文里最好寫的一部分。我建議至少設(shè)計三組核心表用戶健康檔案主表、每次咨詢的檢查記錄表、輔助診療結(jié)論表。-- 用戶健康檔案表存儲基礎(chǔ)信息和歷史病史 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 ); -- 咨詢檢查記錄表一次咨詢對應(yīng)一條主記錄和N條多模態(tài)附件 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 語音轉(zhuǎn)寫后的文本, image_paths JSON COMMENT 上傳圖像的文件路徑列表, lab_indicator JSON COMMENT 檢驗指標(biāo)的JSON結(jié)構(gòu)化字段, status TINYINT DEFAULT 0 COMMENT 0-處理中 1-已完成 2-失敗, FOREIGN KEY (user_id) REFERENCES user_profile(id) ); -- 輔助診療結(jié)論表LLM輸出落庫支持審計回溯 CREATE TABLE diagnosis_result ( id INT PRIMARY KEY AUTO_INCREMENT, consult_id INT NOT NULL, risk_level TINYINT COMMENT 1-低風(fēng)險 2-中風(fēng)險 3-高風(fēng)險, summary TEXT COMMENT LLM生成的綜合判斷摘要, suggestions JSON COMMENT 結(jié)構(gòu)化建議列表用藥提醒/生活方式/復(fù)查建議, references JSON COMMENT 知識庫來源引用用于可追溯, model_name VARCHAR(64) COMMENT 本次調(diào)用的模型標(biāo)識, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (consult_id) REFERENCES consult_record(id) );image_paths用文件路徑列表而不用二進(jìn)制存庫是工程經(jīng)驗和論文雙重考慮的結(jié)論圖片在數(shù)據(jù)庫里只保留路徑實際文件走獨立存儲目錄或 OSS既方便清洗調(diào)試也能避免數(shù)據(jù)庫膨脹。lab_indicator用 JSON 是因為不同體檢機構(gòu)的項目名稱千差萬別結(jié)構(gòu)化字段在畢業(yè)論文里反而難以覆蓋所有場景。diagnosis_result里單獨留一個model_name字段答辯時如果你想對比不同模型的效果這條字段能幫你省很多事。3. 多模態(tài)數(shù)據(jù)接入與預(yù)處理文本、語音、圖像、檢驗指標(biāo)的四路融合3.1 文本與語音問診信息的清洗與轉(zhuǎn)寫文本是最基礎(chǔ)的一路輸入但它的坑不在“接進(jìn)去”而在“怎么洗”。用戶輸入的主訴文本通常口語化嚴(yán)重夾雜著錯別字、網(wǎng)絡(luò)用語和大量無用信息。我一般會做三層清洗第一層正則去掉表情符號和重復(fù)標(biāo)點第二層做同義替換比如把“有點難受”歸一化成“不適”第三層做癥狀關(guān)鍵詞提取抽取出部位、持續(xù)時間、疼痛性質(zhì)等字段。語音輸入在畢設(shè)里常被做成“看起來有實際不解釋”的黑匣子這其實是論文里可以濃墨重彩寫的一塊。語音轉(zhuǎn)寫我一般接 Whisper 或云廠商 ASR但關(guān)鍵點在于轉(zhuǎn)寫后的文本不能直接進(jìn)模型要做置信度處理。import re import json def normalize_symptom_text(raw_text: str) - dict: 清洗主訴文本提取結(jié)構(gòu)化癥狀要素 返回JSON方便后續(xù)拼接Prompt # 去掉表情符號匹配常見emoji范圍直接替換為空 emoji_pattern re.compile( [\U0001F600-\U0001F64F\U0001F300-\U0001F5FF\U0001F680-\U0001F6FF], flagsre.UNICODE ) text emoji_pattern.sub(, raw_text) # 去除多余空白和重復(fù)標(biāo)點 text re.sub(r\s, , text).strip() text re.sub(r[。!?]{2,}, 。, text) # 用簡單規(guī)則抽取癥狀片段按標(biāo)點切分過濾過短片段 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 } # 調(diào)用示例模擬用戶輸入 sample_input 最近老犯困沒力氣偶爾還有點難受食欲也一般般... result normalize_symptom_text(sample_input) print(json.dumps(result, ensure_asciiFalse, indent2))這段代碼里有三個參數(shù)值得你在答辯時展開講emoji_pattern的unicode范圍匹配處理的是用戶從手機粘貼文本時夾帶的符號re.sub(r[。!?]{2,}, 。, text)把多個終止符壓縮成一個避免LLM把重復(fù)標(biāo)點當(dāng)作信息密度segment_count過濾單字碎片防止像“疼”這樣的單字被單獨作為一段輸入。語音轉(zhuǎn)寫文本走的也是同一套清洗邏輯之后可以和手動輸入統(tǒng)一處理。語音分支還有一個容易翻車的細(xì)節(jié)轉(zhuǎn)寫結(jié)果的置信度。Whisper 這類工具對普通話的識別率在安靜環(huán)境下還行但用戶一旦站在嘈雜環(huán)境里轉(zhuǎn)寫文本里經(jīng)常出現(xiàn)同音錯字。我會在轉(zhuǎn)寫后加一個簡單的“醫(yī)學(xué)術(shù)語糾錯表”把“心慌”誤寫成“星荒”這類錯誤用映射表糾正回來。這個糾錯表只有幾十條但足以讓答辯時的語音演示效果穩(wěn)一大截。3.2 醫(yī)學(xué)圖像從舌象照片到可計算的特征描述圖像輸入放在這套系統(tǒng)里最合適的入口是舌象和面色判斷這也是中醫(yī)診斷里成熟度比較高的方向。我不建議直接讓LLM“看”圖片——目前的LLM視覺接口對醫(yī)學(xué)圖像的編碼細(xì)節(jié)理解有限而且你要在論文里寫清楚特征提取算法直接丟給大模型反而沒什么可寫。我采用的是雙路方案第一路用OpenCV做傳統(tǒng)特征提取計算舌色、舌苔厚薄的HSV分布特征第二路把關(guān)鍵特征文本化后拼進(jìn)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} # 統(tǒng)一縮放到固定尺寸減少不同設(shè)備拍照的尺度差異 img cv2.resize(img, (224, 224), interpolationcv2.INTER_AREA) # 轉(zhuǎn)HSV色彩空間醫(yī)學(xué)圖像常用HSV而非RGB做色相分析 hsv cv2.cvtColor(img, cv2.COLOR_BGR2HSV) # 劃分舌體區(qū)域簡化版本用中心60%區(qū)域近似實際可用分割模型 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() # 統(tǒng)計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) # 按閾值規(guī)則給出文本描述避免直接把數(shù)值丟給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而不是默認(rèn)的INTER_LINEAR是因為插值算法直接關(guān)系到后續(xù)色彩統(tǒng)計的穩(wěn)定性。ROI區(qū)域取中心60%是為了減少嘴唇、牙齒和背景對色相統(tǒng)計的干擾。H通道的閾值判斷標(biāo)準(zhǔn)不追求醫(yī)學(xué)精確但足以在論文里展示一套“規(guī)則可解釋”的特征提取流程。你如果后續(xù)想改進(jìn)可以把ROI提取換成輕量級分割模型這塊寫進(jìn)“未來展望”里會讓論文的延展性更好。3.3 檢驗指標(biāo)規(guī)則校驗與異常標(biāo)記檢驗指標(biāo)是四路輸入中“數(shù)值密集度”最高的一路也是最容易出亂子的。用戶上傳一張體檢報告照片OCR識別出來的數(shù)字經(jīng)常缺單位或錯位直接塞給LLM會產(chǎn)生離譜幻覺。我在這路輸入上堅持“寧缺毋濫”的原則先做規(guī)則校驗不合格的字段寧可丟棄也不能硬傳給模型。def validate_lab_indicators(indicators: dict) - dict: 校驗檢驗指標(biāo)單位歸一化 范圍合法性判斷 異常標(biāo)記 輸入格式: {項目: {value: 數(shù)值, unit: 單位}} REFERENCE_RANGES { 白細(xì)胞計數(shù): (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 { 白細(xì)胞計數(shù): 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, ) # 物理合理性檢查數(shù)值不可能為負(fù)數(shù)或超出人類極限 if value 0 or value 2000: print(f[WARN] 非法數(shù)值: {item}{value}) continue low, high REFERENCE_RANGES[item] # 異常標(biāo)記低于下限/高于上限/正常 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這個函數(shù)的核心價值體現(xiàn)在三處REFERENCE_RANGES定義的是“參考范圍”論文里必須標(biāo)注來源是臨床指南或教材不能自己編物理合理性檢查里的value 2000是兜底過濾防OCR識別錯位status字段設(shè)計成low/high/normal三態(tài)而非直接寫“異常”是把判斷權(quán)留給LLM系統(tǒng)只做數(shù)據(jù)標(biāo)記。異常標(biāo)記之后的融合策略也很關(guān)鍵不是所有維度都要喂給LLM。我的原則是“有異常才強調(diào)正常值只做概要”。當(dāng)檢驗指標(biāo)超過10項時如果全部拼接進(jìn)PromptLLM的注意力會被正常值稀釋。我會把異常項單獨挑出加上一句“以下指標(biāo)超出參考范圍”再附帶全部指標(biāo)的JSON概要。4. 核心診療引擎Prompt編排、醫(yī)學(xué)知識庫與LLM的協(xié)作4.1 從多模態(tài)輸入到結(jié)構(gòu)化Prompt特征怎么喂給模型這是整套系統(tǒng)技術(shù)含量最高的模塊。LLM本身不理解“多模態(tài)”它只理解文本。所以你的工程能力體現(xiàn)在把四種輸入形態(tài)統(tǒng)一轉(zhuǎn)成文本特征并用一種讓LLM容易遵循的結(jié)構(gòu)排列出來。我習(xí)慣把Prompt分成四段系統(tǒng)角色定義、當(dāng)前用戶狀態(tài)、知識庫檢索結(jié)果可選、輸出格式約束。下面是一個可替換的構(gòu)造函數(shù)def build_medical_prompt( user_profile: dict, cleaned_symptom: str, tongue_features: dict, lab_indicators: dict, retrieved_knowledge: list ) - str: 構(gòu)造最終發(fā)送給LLM的Prompt retrieved_knowledge: RAG檢索結(jié)果切片列表 # 第一段角色定位——明確邊界禁止越權(quán)診斷 system_role ( 你是一名健康管理助手你的任務(wù)是基于用戶提供的主訴、 體征數(shù)據(jù)和檢驗指標(biāo)給出健康風(fēng)險提示與就醫(yī)建議。 你不是執(zhí)業(yè)醫(yī)師不能給出確診結(jié)論。若信息不足 必須主動詢問或建議就醫(yī)。 ) # 第二段用戶基礎(chǔ)檔案摘要 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]}。 # 第三段癥狀、舌象、檢驗指標(biāo) status_block ( f主訴癥狀{cleaned_symptom}\n f舌象特征{tongue_features.get(tongue_color, 未知)} f{tongue_features.get(coating, 未知)}\n f檢驗指標(biāo)關(guān)注異常項\n ) # 只把異常指標(biāo)詳細(xì)列出正常項一筆帶過 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 以下是檢索到的醫(yī)學(xué)參考資料請優(yōu)先依據(jù)它們\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, 當(dāng)前狀態(tài) status_block, knowledge_block, output_constraint ]) return prompt這段代碼的設(shè)計意圖是讓LLM明確三件事第一它不能被當(dāng)做人——system_role里的“不能給出確診結(jié)論”既是產(chǎn)品合規(guī)要求也是論文里“安全性設(shè)計”章節(jié)的素材第二它的注意力被引導(dǎo)到異常項而非全部數(shù)據(jù)——[異常high]這種顯式標(biāo)記比單純數(shù)值更能觸發(fā)模型的敏感度第三它的輸出被強制約束成JSON——這樣后續(xù)才能自動化解析、落庫到diagnosis_result表。這里有一個經(jīng)驗性的細(xì)節(jié)suggestions字段我故意用中文鍵而非英文字段因為絕大多數(shù)中文醫(yī)療語料訓(xùn)練出的模型對中文JSON鍵名的一致性更好如果你用riskLevel這種駝峰格式偶爾會出現(xiàn)模型輸出和你的解析代碼不匹配的問題。4.2 知識庫檢索與召回讓LLM依據(jù)指南而不是憑空編RAG模塊在畢設(shè)里的實現(xiàn)并不需要多高的復(fù)雜度但需要把鏈路跑通。我在這個系統(tǒng)里用的檢索鏈路是醫(yī)學(xué)文檔 → 文本切片 → Embedding向量化 → 向量檢索 → TopK結(jié)果拼進(jìn)Prompt。切片策略是RAG工程里最玄學(xué)的部分但也是論文里最好寫參數(shù)分析的部分。我的默認(rèn)配置是切片大小500字符重疊50字符。太大切片內(nèi)容容易被無關(guān)信息稀釋太小語義不完整。重疊50字符是為了避免恰好把一個完整概念切斷在切片邊界。from typing import List def chunk_text(doc: str, chunk_size: int 500, overlap: int 50) - List[str]: 文本切片函數(shù)按段落優(yōu)先、長度兜底的策略 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 # 當(dāng)前累積加段落仍小于切片上限繼續(xù)累積 if len(current) len(para) 1 chunk_size: current para \n else: # 先把當(dāng)前切片截斷到上限然后保留重疊部分重新累積 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這個切片函數(shù)的關(guān)鍵在于“段落優(yōu)先”策略先按換行符切段只有段落長度超過閾值時才硬切。這樣做比純按字符長度切片的效果明顯要好因為醫(yī)學(xué)文檔的段落本身就承載了完整語義。知識庫的內(nèi)容從哪里來畢設(shè)場景里最方便的是把《內(nèi)科學(xué)》常見病章節(jié)的電子版、藥品說明書公開數(shù)據(jù)、以及體檢報告常見指標(biāo)解讀整理成Markdown文檔按疾病類型分目錄存放。這里有一個合規(guī)細(xì)節(jié)論文里要寫清楚知識來源不要直接引用受版權(quán)保護(hù)的整本教材。我一般建議用公開指南摘要和科普級別內(nèi)容答辯時更安全。4.3 輸出后校驗與LLM-as-judge讓演示結(jié)果可復(fù)現(xiàn)把模型輸出直接落庫不是好習(xí)慣。我一般會在模型返回后加三道校驗第一道是JSON語法解析校驗很多模型偶爾會輸出多余的前導(dǎo)文字或末尾句號解析失敗就要求模型重試一次第二道是枚舉字段校驗比如risk_level必須嚴(yán)格是low/medium/high之一出現(xiàn)其他值就拋出不兼容錯誤第三道是規(guī)則校驗比如用戶所有指標(biāo)正常且主訴為“無不適”時risk_level不應(yīng)為high。這三道校驗可以在論文里寫成“輸出魯棒性設(shè)計”是一塊能體現(xiàn)工程素養(yǎng)的內(nèi)容。每次從模型返回的結(jié)果都先過這三個關(guān)卡過了才寫入diagnosis_result表不過就觸發(fā)自動重試。LLM-as-judge 是最近在AI應(yīng)用層非常流行的質(zhì)量驗證方法放在這里用性價比極高拿一個額外的模型可以是同一個模型的另一個實例也可以是一個輕量模型去給主模型的輸出打分判斷是否有邏輯矛盾或遺漏關(guān)鍵項。這在答辯演示時是個很漂亮的加分項——你可以在PPT里放兩列主模型的輸出、評判模型的打分。import json def validate_and_judge(model_output: str) - dict: 輸出后處理先解析JSON再規(guī)則校驗 # 清理模型輸出中的多余字符兼容常見非嚴(yán)格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非法風(fēng)險等級: {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%的不穩(wěn)定輸出。答辯前用固定測試集跑一遍所有輸出都無異常時演示才不會有“現(xiàn)場翻車”的風(fēng)險。5. 畢業(yè)設(shè)計避坑與排查從數(shù)據(jù)到答辯的五個高頻翻車點5.1 多模態(tài)接口超時前端頻繁報錯現(xiàn)象圖像上傳后前端等很久沒有響應(yīng)最后直接超時語音轉(zhuǎn)寫偶爾也卡住用戶以為系統(tǒng)崩了。原因這三個操作都是計算密集型的——圖片特征提取、ASR轉(zhuǎn)寫、LLM推理——如果后端是同步阻塞邏輯一個請求占住線程其他請求全部排隊。解決把耗時操作全部改為異步任務(wù)。后端用FastAPI的BackgroundTasks或獨立的消息隊列Celery或簡單的Redis隊列前端提交后先拿到一個任務(wù)ID然后輪詢或WebSocket推送結(jié)果。我的做法是更粗暴但更穩(wěn)的方案圖片和語音預(yù)處理直接同步執(zhí)行控制在500ms以內(nèi)LLM推理設(shè)計為30秒超時配合前端loading文案“AI醫(yī)生正在分析請稍候”用戶在這個場景下普遍有耐心等10秒以上。5.2 同樣的輸入兩次給的結(jié)論不一樣現(xiàn)象答辯前一天演示還很正常第二天跑同一個測試用例輸出的建議內(nèi)容變了甚至風(fēng)險等級都不同。原因大模型推理本身帶有隨機性temperature參數(shù)沒有設(shè)置為0或者遠(yuǎn)程API在頻繁請求時自動調(diào)整了采樣參數(shù)。解決所有醫(yī)療場景的推理請求temperature固定設(shè)為0或接近0的值關(guān)閉隨機采樣同時把隨機種子seed固定。如果你調(diào)用的是云端API要看服務(wù)商文檔確認(rèn)是否支持seed參數(shù)。還有一招后悔藥把每次的模型輸出連同輸入一起存庫答辯時如果評委要求看一致性直接展示歷史記錄比口頭解釋更有說服力。5.3 RAG檢索總召回不到相關(guān)內(nèi)容醫(yī)療回答出現(xiàn)幻覺現(xiàn)象知識庫里明明有高血壓管理章節(jié)用戶問“血壓高怎么辦”檢索結(jié)果卻返回了“糖尿病飲食建議”最后LLM給出的答案出現(xiàn)明顯編造。原因最常見的根源是切片時把大標(biāo)題和正文切斷了Embedding向量丟失了語義錨點。比如“高血壓”這個標(biāo)題落在切片A末尾“患者飲食建議”落在切片B開頭切片B的向量就無法和查詢建立關(guān)聯(lián)。解決把文檔切片策略從“按長度硬切”改成“按語義塊切”。保留Markdown各級標(biāo)題作為切片的元數(shù)據(jù)在切片內(nèi)容前面拼上標(biāo)題路徑。這個做法在向量檢索里叫做metadata augmentation用大白話說就是讓每個切片知道自己屬于哪一章檢索時順手過濾掉不屬于該疾病章節(jié)的無關(guān)結(jié)果。5.4 答辯演示時網(wǎng)絡(luò)波動整個系統(tǒng)癱掉現(xiàn)象到了演示節(jié)點訪問大模型API的請求超時或返回限流錯誤前端白屏演示中斷。原因畢業(yè)設(shè)計答辯現(xiàn)場用的往往是大樓公用WiFi對境外或高并發(fā)API的限制很嚴(yán)格而且現(xiàn)場多人同時用網(wǎng)帶寬極不穩(wěn)定。解決準(zhǔn)備兩層降級方案。第一層是本地模型兜底——在答辯用的筆記本上部署一個小模型比如幾GB的量化模型網(wǎng)絡(luò)API失敗時自動切換到本地推理速度稍慢但能跑通全流程。第二層是“預(yù)錄演示視頻”法把完整操作流程提前錄制成高清視頻放在本地現(xiàn)場如果網(wǎng)絡(luò)確實不行直接播放視頻并同步講解。這兩層方案我都試過實際體驗上本地模型兜底更自然評委不會覺得你在逃避演示。5.5 論文查重偏高AI生成的痕跡明顯現(xiàn)象論文提交查重后重復(fù)率超過30%標(biāo)注的AI痕跡檢測為高風(fēng)險。原因畢設(shè)系統(tǒng)相關(guān)的章節(jié)用了太多套話模板比如“隨著人工智能技術(shù)的飛速發(fā)展”這類開頭在知網(wǎng)庫里同質(zhì)化嚴(yán)重加上從LLM生成內(nèi)容里直接摘錄的段落未改寫。解決論文敘事從“技術(shù)棧羅列”改成“問題驅(qū)動”。每一章開頭先寫“這里遇到了什么問題現(xiàn)有方案為什么不夠”再寫“我采用了什么方案參數(shù)怎么定的”。比如第2章不要寫“該系統(tǒng)采用FastAPI框架”改寫成“最初使用Flask搭建后端但異步任務(wù)增多后出現(xiàn)阻塞現(xiàn)象調(diào)研后改用FastAPI的異步支持”。敘述方式的變化會顯著降低查重率同時讓論文看起來有真實決策過程。6. 從系統(tǒng)到答辯固定測試用例與匯報PPT的關(guān)鍵技巧6.1 固定測試集一致性驗證與效果演示兩用系統(tǒng)開發(fā)完成后我強烈建議你建一個固定測試集至少包含10~20個病例場景。每個場景寫清楚四路輸入的標(biāo)準(zhǔn)值主訴文本、語音轉(zhuǎn)寫文本、舌象描述特征、檢驗指標(biāo)JSON、預(yù)期輸出等級。這個測試集有三個用途。第一功能性回歸測試——每次改完代碼后跑一遍確保沒有把之前能跑通的場景改壞。第二一致性驗證——固定temperature0后連續(xù)跑三次相同輸入檢查輸出是否一致。第三答辯演示素材——挑其中3個最典型的病例做演示路徑一個低風(fēng)險、一個中風(fēng)險、一個高風(fēng)險覆蓋全部輸出形態(tài)。我設(shè)計測試集時有一條血淚經(jīng)驗不要只設(shè)計“典型癥狀”用例也一定要混入“信息不足”的用例。比如只給一句“我最近睡不好”沒有補充數(shù)據(jù)系統(tǒng)應(yīng)返回“需要更多癥狀細(xì)節(jié)建議補充睡眠時長、是否伴有其他不適”而不是硬著頭皮給建議。這種信息不足場景的處理方式往往是答辯時評委最欣賞的部分因為大多數(shù)人的畢設(shè)都做成了“有輸入必輸出”的機器人。6.2 PPT敘事線讓評委在5分鐘里看清你的工作量匯報PPT是畢業(yè)設(shè)計的最終呈現(xiàn)載體大多數(shù)人會犯同一個毛病按系統(tǒng)模塊一頁一頁平鋪上來講數(shù)據(jù)庫建了幾張表中間貼代碼截圖最后放運行截圖。這種PPT的信息密度很低評委看不出你的思考。我用的敘事線是“痛點→矛盾→方案→實證”四段式。開頭第一頁直接拋出一個場景用戶拿著一份體檢報告和一張舌象照片面對通用大模型得到的回答是孤立的、割裂的無法形成綜合判斷。第二頁指出當(dāng)前方案的局限——純LLM有幻覺且不消化多模態(tài)輸入微調(diào)又成本過高。第三頁亮出你的系統(tǒng)架構(gòu)圖重點標(biāo)注“多模態(tài)預(yù)處理RAG結(jié)構(gòu)化輸出”這條主線。之后每一頁都在回答“這個模塊解決了上一頁的哪個矛盾”。PPT里有一個細(xì)節(jié)技巧值得壓軸使用放一張“接口調(diào)用參數(shù)表”列出不同temperature值和不同TopK檢索數(shù)量下同一測試用例的生成結(jié)果對比。這張表直觀展現(xiàn)了你不只是把模型接進(jìn)去還做了參數(shù)級別的測試與調(diào)優(yōu)。論文里同樣的數(shù)據(jù)放在實驗章節(jié)簡直是一魚兩吃。這次做這個項目到最后我已經(jīng)記不清為 RAG 召回率低調(diào)了多少次切片參數(shù)半夜盯著日志看“知識庫檢索為空”的報錯看了多少遍。但有一段代碼習(xí)慣我始終沒丟所有配置項——切片大小、重疊長度、temperature、seed、參考范圍閾值——全部集中在一個config.yaml里每次實驗換參都強制記錄一條實驗日志。答辯時評委問我“你這些參數(shù)是拍腦袋定的嗎”我直接翻出實驗日志表橫豎都是一張表說服力遠(yuǎn)超口頭解釋。希望你做完這個項目之后也把“留實驗記錄”的習(xí)慣帶走它比這一個畢設(shè)項目本身更值錢。希望幫到你。本文還有配套的精品資源點擊獲取