我家樓下的垃圾分類督導(dǎo)員阿姨盯了我半分鐘就因?yàn)槲遗e著一個(gè)沾了油污的外賣盒不知道該往哪個(gè)桶里扔。那一刻我意識(shí)到垃圾分類這事兒看著簡(jiǎn)單真到手里全是知識(shí)盲區(qū)。后來(lái)我干脆寫了個(gè)基于 Django 圖像識(shí)別的智能垃圾分類系統(tǒng)用手機(jī)拍張照片傳到網(wǎng)頁(yè)上后端模型判斷出這是可回收物還是廚余垃圾連置信度和投放建議一起返回。這篇文章就把整個(gè)設(shè)計(jì)與實(shí)現(xiàn)過(guò)程拆開來(lái)講技術(shù)選型的理由、模型怎么訓(xùn)練、Django 里怎么封裝推理邏輯、ORM 怎么查詢和刪除記錄再疊加部署排坑的實(shí)操經(jīng)驗(yàn)。適合正在做 Django 項(xiàng)目實(shí)戰(zhàn)的新手也適合想把深度學(xué)習(xí)模型接進(jìn) Web 系統(tǒng)、但還沒(méi)找到完整路徑的同學(xué)。1. 項(xiàng)目起點(diǎn)與選型思路這套系統(tǒng)解決了誰(shuí)的痛點(diǎn)動(dòng)手之前我認(rèn)真想了一下這套系統(tǒng)到底要給誰(shuí)用、解決什么問(wèn)題、以及為什么要用 Django 而不是更輕的框架。很多畢設(shè)開始得很倉(cāng)促上來(lái)就找數(shù)據(jù)集、跑模型Web 端隨便選個(gè)框架寫個(gè)上傳頁(yè)面最后再拼裝起來(lái)。結(jié)果模型精度挺高接口卻慢得沒(méi)法看數(shù)據(jù)庫(kù)表也拍腦袋設(shè)計(jì)演示的時(shí)候翻車。所以這個(gè)項(xiàng)目的第一步不是寫代碼而是把需求邊界劃清楚。1.1 需求本質(zhì)不是“識(shí)別垃圾”而是“幫人做投放決策”垃圾分類的難點(diǎn)不在“認(rèn)識(shí)物品”而在“歸類到對(duì)應(yīng)垃圾桶”。比如一個(gè)礦泉水瓶是可回收物但你要是往里面扔了半瓶剩奶茶嚴(yán)格說(shuō)它屬于污損塑料投放邏輯就變了。系統(tǒng)里我設(shè)計(jì)了兩個(gè)層級(jí)圖像識(shí)別模型先輸出細(xì)分類比如“塑料瓶”“紙板箱”“香蕉皮”“廢電池”等具體類別然后由一份映射表將細(xì)分類歸入四分類體系可回收物、廚余垃圾、有害垃圾、其他垃圾。這套設(shè)計(jì)的價(jià)值在于前端展示時(shí)用戶看到的是“這是塑料瓶可回收物置信度 92%”而不是冷冰冰的“Class 7”。細(xì)分類也方便以后擴(kuò)展——比如統(tǒng)計(jì)哪種垃圾識(shí)別錯(cuò)誤率最高再針對(duì)性補(bǔ)充訓(xùn)練數(shù)據(jù)。1.2 為什么選擇 Django 而不是 Flask 或 FastAPI圖像識(shí)別模型通常用 Python 生態(tài)訓(xùn)練Web 端也必須用 Python 才能把模型加載和業(yè)務(wù)邏輯放進(jìn)同一個(gè)進(jìn)程里這時(shí)候 Django 和 Flask 之間需要做個(gè)取舍。我最終選了 Django原因很實(shí)際自帶 Admin 后臺(tái)和 ORM能快速搭建記錄查詢、用戶管理、數(shù)據(jù)統(tǒng)計(jì)頁(yè)面不用重復(fù)造輪子模板系統(tǒng)加上 Django REST Framework 可以同時(shí)支持服務(wù)端渲染和純 API 兩種交互模式后期改成小程序端也方便項(xiàng)目結(jié)構(gòu)強(qiáng)制按 app 劃分模型推理、垃圾識(shí)別、用戶臺(tái)賬可以拆得比較干凈符合課程設(shè)計(jì)和工程化的評(píng)分要求生態(tài)成熟資料多遇到問(wèn)題搜索“django 執(zhí)行查詢 刪除對(duì)象”“django 創(chuàng)建 app”這類關(guān)鍵詞能找到大量已踩坑記錄。當(dāng)然如果你的目標(biāo)是極致的并發(fā)性能FastAPI 的異步特性確實(shí)更有優(yōu)勢(shì)但在這個(gè)場(chǎng)景里模型推理本身是 CPU 重負(fù)載任務(wù)Web 框架的差異遠(yuǎn)小于推理耗時(shí)的差異。為了讓前后端職責(zé)清晰我可以用 Django 提供 API配合前端頁(yè)面調(diào)用這也是后面會(huì)講到的方案。1.3 圖像識(shí)別方案自己訓(xùn)練 CNN 還是遷移學(xué)習(xí)圖像識(shí)別這塊新手常見(jiàn)的誤區(qū)是一上來(lái)就搭建一個(gè) 10 層左右的 CNN用幾百?gòu)垐D跑幾十個(gè) epoch然后發(fā)現(xiàn)準(zhǔn)確率上不去。實(shí)際上在中小規(guī)模數(shù)據(jù)集上自己做訓(xùn)練很難趕上成熟的預(yù)訓(xùn)練模型。我采用遷移學(xué)習(xí)方案以 MobileNetV2 的預(yù)訓(xùn)練權(quán)重作為特征提取器替換最后的全連接分類層在垃圾分類數(shù)據(jù)集上做微調(diào)。MobileNetV2 的優(yōu)勢(shì)是模型體積小、推理速度快CPU 環(huán)境也能跑到幾十毫秒到幾百毫秒。在畢設(shè)演示場(chǎng)景里用戶上傳圖片后等 2 秒是可以接受的但模型文件超過(guò) 500MB 就不太體面了。EfficientNet 在同樣精度下也不差但轉(zhuǎn)換和部署時(shí)對(duì) tf 版本兼容性的要求更嚴(yán)格。為了穩(wěn)我選了 MobileNetV2實(shí)測(cè)下來(lái) Top-1 準(zhǔn)確率在 90% 左右已經(jīng)足夠支撐演示和日常自測(cè)。1.4 整體模塊劃分系統(tǒng)整體分為三個(gè)大的功能域項(xiàng)目里對(duì)應(yīng)三個(gè) Django appgarbageImage或者叫common負(fù)責(zé)圖像上傳、預(yù)處理、調(diào)用模型、返回識(shí)別結(jié)果records負(fù)責(zé)識(shí)別歷史記錄的新增、查詢、刪除、導(dǎo)出對(duì)應(yīng) ORM 操作部分users負(fù)責(zé)用戶登錄注冊(cè)和權(quán)限控制識(shí)別記錄需要關(guān)聯(lián)到當(dāng)前用戶避免互相看到對(duì)方數(shù)據(jù)。數(shù)據(jù)庫(kù)層面識(shí)別記錄表是核心。每個(gè)記錄保存原始圖片、模型輸出的細(xì)分類標(biāo)簽、映射后的四分類類別、置信度、創(chuàng)建時(shí)間。這樣一個(gè)表就把整個(gè)業(yè)務(wù)閉環(huán)串起來(lái)了用戶上傳圖片系統(tǒng)返回結(jié)果結(jié)果寫入數(shù)據(jù)庫(kù)用戶可以在歷史記錄頁(yè)查詢或刪除。2. 圖像識(shí)別模型訓(xùn)練數(shù)據(jù)集處理、遷移學(xué)習(xí)與導(dǎo)出的坑很多人做這類項(xiàng)目時(shí)間花在寫 Web 頁(yè)面上模型處只用了官方示例權(quán)重甚至隨機(jī)初始化權(quán)重導(dǎo)致識(shí)別效果像抽盲盒。我來(lái)把模型訓(xùn)練這一環(huán)的關(guān)鍵操作拆開這部分是識(shí)別系統(tǒng)好用與否的地基。2.1 數(shù)據(jù)集怎么找、怎么清洗公開的垃圾分類數(shù)據(jù)集有不少我用的是一份覆蓋幾十個(gè)細(xì)分類的數(shù)據(jù)集圖片數(shù)量在幾萬(wàn)張量級(jí)。如果你沒(méi)有現(xiàn)成數(shù)據(jù)集也可以找 TrashNet 這類公開垃圾分類數(shù)據(jù)集作為底座再補(bǔ)充一些手機(jī)拍攝的實(shí)物圖。數(shù)據(jù)集處理需要注意三個(gè)點(diǎn)清除無(wú)效圖片下載下來(lái)的壓縮包里經(jīng)常出現(xiàn)損壞的、尺寸為 0 的文件訓(xùn)練前統(tǒng)一檢查按類別平衡樣本量類別之間數(shù)量差距過(guò)大會(huì)導(dǎo)致模型對(duì)大類別有偏向建議每個(gè)類別至少保留 200 張以上不足的部分靠數(shù)據(jù)增強(qiáng)補(bǔ)足統(tǒng)一預(yù)處理邏輯訓(xùn)練時(shí)圖片被縮放到224x224推理時(shí)也必須走完全一樣的縮放和歸一化流程前后不一致是“訓(xùn)練挺好、上線拉胯”的頭號(hào)原因。2.2 遷移學(xué)習(xí)的具體做法模型結(jié)構(gòu)我用的是 TensorFlow/Keras 的 MobileNetV2 預(yù)訓(xùn)練版本把include_topFalse去掉自帶的分類層然后接一個(gè)GlobalAveragePooling2D再加一個(gè)Dropout最后接Dense分類層。這里為什么要用GlobalAveragePooling2D而不是直接Flatten因?yàn)?MobileNetV2 輸出特征圖是7x7x1280直接 Flatten 會(huì)產(chǎn)生 6 萬(wàn)多個(gè)參數(shù)不僅容易過(guò)擬合還讓模型變大。而全局平均池化把每個(gè)通道壓縮成一個(gè)數(shù)值參數(shù)量小得多效果反而更穩(wěn)這也是遷移學(xué)習(xí)實(shí)踐中的常見(jiàn)做法。代碼大致是這樣from tensorflow.keras.applications import MobileNetV2 from tensorflow.keras import layers, models base_model MobileNetV2( weightsimagenet, include_topFalse, input_shape(224, 224, 3) ) base_model.trainable False model models.Sequential([ base_model, layers.GlobalAveragePooling2D(), layers.Dropout(0.3), layers.Dense(len(class_names), activationsoftmax) ]) model.compile( optimizeradam, losscategorical_crossentropy, metrics[accuracy] )第一步先凍結(jié)底層只訓(xùn)練新加的分類頭等分類頭收斂后再把base_model的后面十幾層解凍用很小的學(xué)習(xí)率微調(diào)。這樣既保留底層通用的紋理與形狀特征又能讓高層特征更貼合垃圾圖片的細(xì)節(jié)差異。2.3 訓(xùn)練參數(shù)與精度實(shí)測(cè)訓(xùn)練腳本里我用ImageDataGenerator做數(shù)據(jù)增強(qiáng)包括隨機(jī)旋轉(zhuǎn)、翻轉(zhuǎn)、縮放、亮度調(diào)整增強(qiáng)后的圖片按8:2劃分訓(xùn)練集和驗(yàn)證集。推薦參數(shù)如下參數(shù)設(shè)置說(shuō)明輸入尺寸224x224x3與預(yù)訓(xùn)練模型一致批量大小32顯存不足時(shí)降到 16第一階段學(xué)習(xí)率1e-3只訓(xùn)練分類頭快點(diǎn)收斂第一階段輪數(shù)30觀察驗(yàn)證集是否過(guò)擬合第二階段學(xué)習(xí)率1e-5微調(diào)預(yù)訓(xùn)練層避免破壞已有特征第二階段輪數(shù)10精度提升主要看這一步我在自己機(jī)器上跑完驗(yàn)證集準(zhǔn)確率大約在 92%單張圖片 CPU 推理均值在 0.4 秒左右。如果硬件資源有限也可以減少微調(diào)輪數(shù)或把 Dropout 調(diào)高一些防止過(guò)擬合。2.4 模型導(dǎo)出的格式坑訓(xùn)練完成后保存模型可能遇到兩類典型問(wèn)題使用model.save(garbage_model.h5)保存的 H5 文件在后端load_model時(shí)提示找不到自定義層。解決辦法是保存時(shí)把自定義層注冊(cè)到custom_objects或者在保存前把模型結(jié)構(gòu)全部轉(zhuǎn)成原生 Keras 層序列化方式TensorFlow 版本和 NumPy 版本不兼容加載模型時(shí)直接報(bào)numpy.core.multiarray failed to import。這類問(wèn)題優(yōu)先檢查requirements.txt里的版本組合比如 TensorFlow 2.10 搭配numpy1.24.3通常沒(méi)問(wèn)題但換上更高版本 NumPy 就會(huì)翻車。我在項(xiàng)目里最終導(dǎo)出的是 H5 格式因?yàn)楹蠖俗鲞M(jìn)度演示時(shí)最直觀。如果后續(xù)有部署到手機(jī)端或?yàn)g覽器端的想法可以再轉(zhuǎn)成 TFLite那樣量化后的模型更小、推理更快。3. Django 后端集成模型封裝、ORM 查詢刪除與圖片上傳模型訓(xùn)練只是起點(diǎn)真正讓系統(tǒng)完整的是 Django 后端。這一章我重點(diǎn)講模型怎么封裝進(jìn)視圖、接口怎么設(shè)計(jì)、以及熱搜詞里頻繁出現(xiàn)的“django 執(zhí)行查詢-刪除對(duì)象”到底在項(xiàng)目里怎么落地。3.1 為什么不能在視圖里直接 load_model新手最常見(jiàn)的寫法是from tensorflow.keras.models import load_model def classify(request): model load_model(garbage_model.h5) ...這個(gè)寫法有兩個(gè)問(wèn)題。第一每次請(qǐng)求都會(huì)重新加載一次上百 MB 的模型文件用戶多點(diǎn)兩下服務(wù)器內(nèi)存直接爆炸第二并發(fā)請(qǐng)求時(shí)可能同時(shí)觸發(fā)多次加載造成重復(fù)占用資源。正確做法是讓模型作為進(jìn)程級(jí)單例存在在模塊導(dǎo)入時(shí)加載一次所有請(qǐng)求共享同一個(gè)模型實(shí)例。Django 里實(shí)現(xiàn)單例最省事的方式是用functools.lru_cache或者全局變量。示例# garbage_prediction/service.py from functools import lru_cache from tensorflow.keras.models import load_model lru_cache(maxsize1) def get_model(): model load_model(models/garbage_model.h5) return model這樣第一個(gè)請(qǐng)求進(jìn)來(lái)時(shí)加載模型后續(xù)請(qǐng)求直接復(fù)用。如果你用的是 Gunicorn 多 worker 部署每個(gè) worker 進(jìn)程會(huì)各自加載一份模型所以內(nèi)存消耗要按“worker 數(shù) x 模型大小”提前估算。3.2 預(yù)測(cè)模塊封裝把預(yù)處理、推理、結(jié)果映射放進(jìn)一個(gè)函數(shù)識(shí)別業(yè)務(wù)不能直接寫在views.py里那樣會(huì)讓視圖變得又長(zhǎng)又難測(cè)試。我單獨(dú)建了一個(gè)service.py負(fù)責(zé)圖片預(yù)處理、模型推理和類別映射。import numpy as np from PIL import Image def preprocess_image(img): img img.resize((224, 224), Image.LANCZOS) arr np.array(img, dtypenp.float32) if arr.shape[-1] 4: arr arr[:, :, :3] arr arr / 255.0 arr np.expand_dims(arr, axis0) return arr def predict_batch_garbage(image): model get_model() arr preprocess_image(image) probs model.predict(arr, verbose0)[0] idx int(np.argmax(probs)) confidence float(probs[idx]) subclass_name index_to_subclass[idx] category subclass_to_category[subclass_name] return subclass_name, category, confidence這里有個(gè)細(xì)節(jié)如果上傳的是 PNG 透明圖PIL 讀取后可能有 4 個(gè)通道必須在預(yù)處理里截?cái)喑?RGB否則模型輸入尺寸對(duì)不上。另外Image.open拿到的是文件句柄對(duì)象讀圖片前要確認(rèn)file.seek(0)否則可能出現(xiàn)“讀出來(lái)的圖一直是第一張”的詭異問(wèn)題。3.3 數(shù)據(jù)庫(kù)設(shè)計(jì)與“查詢-刪除對(duì)象”實(shí)操識(shí)別記錄表的設(shè)計(jì)決定了查詢和刪除好不好寫。我定義的模型如下from django.conf import settings from django.db import models class GarbageRecord(models.Model): user models.ForeignKey( settings.AUTH_USER_MODEL, nullTrue, blankTrue, on_deletemodels.SET_NULL ) image models.ImageField(upload_togarbage/%Y%m/) subclass models.CharField(max_length32) category models.CharField(max_length16) confidence models.FloatField() created_at models.DateTimeField(auto_now_addTrue)Django ORM 的查詢和刪除正是很多剛?cè)腴T Django 的人卡住的地方。這里給一份常用操作清單# 查詢最近 10 條記錄 GarbageRecord.objects.filter(userrequest.user).order_by(-created_at)[:10] # 條件查詢只看置信度高于 0.9 的廚余垃圾記錄 GarbageRecord.objects.filter( userrequest.user, category廚余垃圾, confidence__gte0.9 ) # 聚合統(tǒng)計(jì)按類別統(tǒng)計(jì)條數(shù) from django.db.models import Count GarbageRecord.objects.values(category).annotate(totalCount(id)) # 刪除單個(gè)對(duì)象 record GarbageRecord.objects.get(pk1) record.delete() # 按條件批量刪除 GarbageRecord.objects.filter( userrequest.user, category可回收物, confidence__lt0.7 ).delete()特別注意on_delete的選取。用戶被刪時(shí)如果希望保留這條識(shí)別記錄就選SET_NULL如果想同步清空用戶產(chǎn)生的所有記錄則用CASCADE。我在項(xiàng)目中選SET_NULL因?yàn)樽R(shí)別記錄本身有分析價(jià)值用戶解綁后數(shù)據(jù)仍應(yīng)保留。另外一個(gè)容易被忽視的是“軟刪除”。首頁(yè)的歷史記錄里我其實(shí)不建議直接物理刪除而是加一個(gè)is_active布爾字段執(zhí)行刪除操作時(shí)改為is_activeFalse列表查詢時(shí)統(tǒng)一過(guò)濾掉。這樣用戶誤刪后還能找回?cái)?shù)據(jù)庫(kù)里數(shù)據(jù)也不會(huì)因?yàn)轭l繁物理刪除而產(chǎn)生大量碎片。3.4 圖片上傳接口的設(shè)計(jì)與安全校驗(yàn)接口采用POST /api/classify/前端用 FormData 上傳圖片字段image。Django 視圖里有三步校驗(yàn)不能省import uuid from PIL import Image as PILImage from django.core.files.uploadedfile import InMemoryUploadedFile from rest_framework.decorators import api_view from rest_framework.response import Response api_view([POST]) def classify_image(request): upload request.FILES.get(image) if not upload: return Response({error: 缺少圖片}, status400) if upload.size 5 * 1024 * 1024: return Response({error: 圖片不能超過(guò)5MB}, status400) try: image PILImage.open(upload) image.verify() upload.seek(0) except Exception: return Response({error: 文件不是有效圖片}, status400) subclass, category, confidence predict_batch_garbage(image) record GarbageRecord.objects.create( userrequest.user if request.user.is_authenticated else None, imagesave_upload(upload), subclasssubclass, categorycategory, confidenceconfidence ) return Response({ subclass: subclass, category: category, confidence: round(confidence, 4) })save_upload里我沒(méi)有直接用原始文件名而是用uuid.uuid4().hex os.path.splitext(name)[1]重新生成文件名。中文文件名、路徑穿越、文件名沖突全部靠這一行解決。3.5 Django 項(xiàng)目初始化的基礎(chǔ)流程如果你對(duì)這個(gè)項(xiàng)目還不熟先按這個(gè)順序把環(huán)境搭起來(lái)這個(gè)流程覆蓋了熱搜詞里大部分內(nèi)容# 1. 創(chuàng)建虛擬環(huán)境并安裝依賴 python -m venv venv source venv/bin/activate pip install django4.2 tensorflow-cpu2.10.0 pillow10.1.0 # 2. 創(chuàng)建項(xiàng)目與 app django-admin startproject garbage_project . python manage.py startapp garbage_prediction python manage.py startapp records # 3. 在 settings.py 中注冊(cè) app、配置數(shù)據(jù)庫(kù)連接和 MEDIA 路徑 # 4. 生成遷移并創(chuàng)建管理員 python manage.py makemigrations python manage.py migrate python manage.py createsuperuser新手容易犯的錯(cuò)是忘記把garbage_prediction和records加進(jìn)INSTALLED_APPS結(jié)果執(zhí)行makemigrations時(shí)提示沒(méi)有變化。還有Django 4.0 之后csrf_protect的邏輯沒(méi)有變化但如果你用 DRF 的api_view它默認(rèn)就走了 CSRF 豁免前端傳X-CSRFToken的代碼可能需要根據(jù)實(shí)際配置調(diào)整。4. 前端交互上傳、拍照、Canvas 壓縮與識(shí)別反饋閉環(huán)后端模型再準(zhǔn)前端交互做得生硬演示效果也會(huì)打折扣。我這一版前端沒(méi)有使用復(fù)雜的框架就是 Django 模板 原生 JavaScript。上傳方式分兩種相冊(cè)選圖和攝像頭拍照。4.1 相冊(cè)上傳與 Ajax 提交頁(yè)面里放一個(gè)隱藏的input typefile用戶點(diǎn)上傳按鈕后觸發(fā)文件選擇。拿到文件后先做壓縮再提交這一步是很多項(xiàng)目忽略的。手機(jī)拍出來(lái)的圖動(dòng)輒 3MB 以上如果不壓縮直接傳給后端不僅網(wǎng)絡(luò)慢PIL 讀取和模型 resize 也會(huì)拖慢響應(yīng)。壓縮代碼我放在前端 Canvas 里async function compressImage(file, maxWidth 800, quality 0.8) { const img await createImageBitmap(file); const scale Math.min(1, maxWidth / img.width); const canvas document.createElement(canvas); canvas.width img.width * scale; canvas.height img.height * scale; const ctx canvas.getContext(2d); ctx.drawImage(img, 0, 0, canvas.width, canvas.height); return new Promise((resolve) { canvas.toBlob(resolve, image/jpeg, quality); }); }壓縮后的圖片寬度控制在 800 像素以內(nèi)識(shí)別精度基本不受影響但傳輸和推理時(shí)間大幅下降。然后在fetch中提交const formData new FormData(); formData.append(image, compressedBlob, capture.jpg); fetch(/api/classify/, { method: POST, headers: { X-CSRFToken: csrftoken }, body: formData }) .then(response response.json()) .then(data renderResult(data));記得在頁(yè)面加載時(shí)從 cookie 里取csrftoken否則 Django 會(huì)回 403。如果你配置了 DRF也可以直接設(shè)置SessionAuthentication之外的認(rèn)證方式但最簡(jiǎn)單可靠的還是把 token 加進(jìn)請(qǐng)求頭。4.2 攝像頭拍照識(shí)別攝像頭拍照在電腦上演示效果很好但有一個(gè)坑getUserMedia要求頁(yè)面必須在localhost或 HTTPS 環(huán)境下才能調(diào)用。Django 開發(fā)服務(wù)器用http://localhost:8000沒(méi)問(wèn)題但如果你用 IP 地址在局域網(wǎng)里訪問(wèn)攝像頭就會(huì)以權(quán)限不足為由拒絕打開。拍照流程是const video document.getElementById(cameraStream); const stream await navigator.mediaDevices.getUserMedia({ video: { facingMode: environment } }); video.srcObject stream; await video.play();用戶點(diǎn)擊“拍照”時(shí)用canvas.drawImage(video, 0, 0, width, height)截取當(dāng)前畫面然后同樣走toBlob壓縮流程。拍完別忘了stream.getTracks().forEach(track track.stop())不然攝像頭指示燈會(huì)一直亮著用戶體驗(yàn)很糟糕。4.3 識(shí)別結(jié)果展示與二次確認(rèn)反饋結(jié)果展示區(qū)我用一張卡片展示三個(gè)信息細(xì)分類名稱、四分類標(biāo)簽、置信度。置信度低于 0.6 時(shí)把結(jié)果用黃色框標(biāo)出提示“該結(jié)果置信度較低請(qǐng)換一個(gè)角度重新拍攝或上傳更清晰的圖片”。這樣即使用戶拍到一張光線很差的圖片被誤判他也不會(huì)直接覺(jué)得系統(tǒng)是壞的而是會(huì)主動(dòng)調(diào)整拍攝方式。同時(shí)我在結(jié)果卡片下方放了兩個(gè)按鈕“標(biāo)記正確”和“標(biāo)記錯(cuò)誤”。用戶點(diǎn)了標(biāo)記后前端發(fā)一個(gè)POST /api/feedback/請(qǐng)求后端把這些反饋記錄下來(lái)。這些數(shù)據(jù)回頭可以導(dǎo)出作為下一輪模型迭代擴(kuò)充訓(xùn)練集的重要來(lái)源。這個(gè)功能在畢設(shè)答辯時(shí)是加分項(xiàng)因?yàn)樗f(shuō)明你考慮到了模型持續(xù)優(yōu)化而不是交一個(gè)靜態(tài)演示。5. 部署上線與性能優(yōu)化從“本機(jī)能跑”到“別人能用”開發(fā)階段用python manage.py runserver沒(méi)有任何問(wèn)題但真正把系統(tǒng)給別人演示時(shí)必須面對(duì)并發(fā)、靜態(tài)文件處理、數(shù)據(jù)庫(kù)連接等一系列問(wèn)題。這一章節(jié)把從零部署到服務(wù)器上能穩(wěn)定訪問(wèn)的全過(guò)程梳理一遍。5.1 依賴版本與部署前檢查清單先看依賴組合。我的requirements.txt如下django4.2.7 djangorestframework3.14.0 tensorflow-cpu2.10.1 Pillow10.1.0 numpy1.24.3 gunicorn21.2.0 whitenoise6.6.0TensorFlow 2.10 在 Python 3.11 上的兼容性并不理想建議使用 Python 3.8 或 3.10 環(huán)境。如果你的 TensorFlow 版本升級(jí)到 2.13 以上NumPy 版本限制可以放寬具體以導(dǎo)入時(shí)是否報(bào)錯(cuò)為準(zhǔn)。部署前檢查清單settings.py中DEBUG FalseALLOWED_HOSTS里寫入服務(wù)器 IP 或域名DATABASES如果繼續(xù)用 SQLite只適合低并發(fā)演示如果想更穩(wěn)一點(diǎn)換成 PostgreSQL靜態(tài)文件收集python manage.py collectstatic圖片上傳目錄MEDIA_ROOT要有寫入權(quán)限并且不能用rbind這種容易被忽略的權(quán)限問(wèn)題攔住。5.2 Gunicorn 與 WhiteNoise 靜態(tài)文件方案服務(wù)器上我選擇了 Gunicorn 作為 WSGI 服務(wù)器配合 WhiteNoise 處理靜態(tài)文件Nginx 只做反向代理和 HTTPS 終結(jié)。好處是項(xiàng)目結(jié)構(gòu)簡(jiǎn)單單個(gè) Django 進(jìn)程就能服務(wù)靜態(tài)資源不需要單獨(dú)配一套復(fù)雜的 Nginx 靜態(tài)文件路徑。啟動(dòng)命令gunicorn garbage_project.wsgi:application \ --workers 3 \ --threads 2 \ --bind 0.0.0.0:8000 \ --timeout 60注意--timeout 60是必須的。模型推理在 CPU 上最壞情況可能超過(guò) 30 秒Gunicorn 默認(rèn) 30 秒超時(shí)會(huì)直接殺掉 worker用戶看到的就是 500 錯(cuò)誤。我這個(gè)配置里3 個(gè) worker 意味著內(nèi)存峰值約等于 3 份模型大小加 Django 基線內(nèi)存服務(wù)器內(nèi)存最好預(yù)留 3GB 以上。5.3 推理性能實(shí)測(cè)與常見(jiàn)坑我在 2C4G 的輕量服務(wù)器上實(shí)測(cè)單次識(shí)別請(qǐng)求的總耗時(shí)分布環(huán)節(jié)耗時(shí)圖片上傳與反序列化約 80ms圖片校驗(yàn)與預(yù)處理約 20msMobileNetV2 推理約 400ms結(jié)果寫入數(shù)據(jù)庫(kù)約 20ms響應(yīng)返回約 10ms總耗時(shí)在 0.5 秒左右作為單用戶演示完全沒(méi)問(wèn)題。但如果短時(shí)間內(nèi)有幾十個(gè)人同時(shí)上傳三個(gè) worker 會(huì)很快被推理任務(wù)占滿其他請(qǐng)求只能排隊(duì)。這時(shí)候的優(yōu)化思路有兩種把高并發(fā)的圖片接收與低并發(fā)的模型推理拆開用消息隊(duì)列如 Redis RQ異步處理識(shí)別任務(wù)前端輪詢獲取結(jié)果不要用 SQLite 存高速寫入的識(shí)別記錄換成 PostgreSQL 或者先寫內(nèi)存表再定期落庫(kù)。第二種方案涉及異步流程代碼復(fù)雜度會(huì)上升不建議在基礎(chǔ)版本里做。我更推薦的做法是把識(shí)別歷史記錄和畫像統(tǒng)計(jì)分開識(shí)別時(shí)只寫一條輕量記錄不需要在請(qǐng)求里做復(fù)雜事務(wù)。5.4 我踩過(guò)的幾個(gè)坑匯總給你這些坑我都實(shí)際踩過(guò)按影響程度排序問(wèn)題現(xiàn)象解決辦法TensorFlow 與 NumPy 版本沖突導(dǎo)入 tf 時(shí)報(bào) numpy 初始化錯(cuò)誤鎖定numpy1.24.3或用更高版本 tf 搭配新版 numpy上傳超大圖片網(wǎng)頁(yè)請(qǐng)求發(fā)送很久沒(méi)響應(yīng)前端 Canvas 壓縮到 800px 內(nèi)后端限制 5MB中文文件名上傳到對(duì)象存儲(chǔ)亂碼后端用 UUID 重命名原文件名寫入字段DEBUGFalse 后樣式丟了頁(yè)面光禿禿一片安裝 whitenoise 并執(zhí)行 collectstatic攝像頭黑屏getUserMedia 報(bào)權(quán)限錯(cuò)誤必須用 localhost 或 HTTPS 訪問(wèn)不能用局域網(wǎng) IPSQLite 被并發(fā)寫鎖多用戶同時(shí)識(shí)別時(shí)偶發(fā) “database is locked”生產(chǎn)環(huán)境切 PostgreSQL5.5 前端加一層輪詢的輕量方案如果你想在不上消息隊(duì)列的前提下緩解等待體驗(yàn)可以在前端識(shí)別時(shí)先拿到一個(gè) task 號(hào)后端把圖片存下來(lái)立刻返回“識(shí)別中”然后再由前端每隔 0.5 秒請(qǐng)求一次/api/classify/result/獲取結(jié)果。這樣即使推理時(shí)間超過(guò) 30 秒用戶也不會(huì)看到一個(gè)一直轉(zhuǎn)圈的請(qǐng)求超時(shí)頁(yè)面。后端實(shí)現(xiàn)上任務(wù)結(jié)果可以先存在內(nèi)存字典或緩存里鍵是 task 號(hào)值是識(shí)別結(jié)果。識(shí)別完成后由后臺(tái)線程把結(jié)果寫入GarbageRecord同時(shí)更新緩存。前端輪詢拿到結(jié)果后再渲染頁(yè)面。這個(gè)方案只增加少量代碼就能讓體驗(yàn)提升一個(gè)檔次。寫在最后這套系統(tǒng)還能怎么迭代做完這個(gè)項(xiàng)目我最大的體會(huì)是圖像識(shí)別只占系統(tǒng)復(fù)雜度的一小部分真正花時(shí)間的是把模型、Web、數(shù)據(jù)庫(kù)、交互這四層擰在一起。最難調(diào)試的往往不是模型精度而是文件上傳類型判斷、CSRF token 配置、靜態(tài)文件收集這些看似不起眼的小細(xì)節(jié)。如果后續(xù)你想繼續(xù)擴(kuò)展可以在三個(gè)方向上迭代一是接入語(yǔ)音播報(bào)識(shí)別結(jié)束后直接告訴用戶應(yīng)該投哪個(gè)桶這對(duì)老人和小孩更友好二是按地理位置記錄投放點(diǎn)結(jié)合歷史識(shí)別數(shù)據(jù)生成小區(qū)垃圾分類熱力圖這會(huì)讓系統(tǒng)從“工具”變成“數(shù)據(jù)產(chǎn)品”三是把模型換成 TFLite 并部署到手機(jī)端配合前端攝像頭實(shí)現(xiàn)完全離線的垃圾分類助手不需要服務(wù)器也能工作。每個(gè)方向單獨(dú)拆出來(lái)都是一篇完整的實(shí)戰(zhàn)文章但骨架始終是這個(gè)項(xiàng)目搭起來(lái)的東西。對(duì)新手來(lái)說(shuō)先把這篇文章里的鏈路完整走通一遍后面再談優(yōu)化也不遲。