簡介本資源為基于BERT的深度學習文本相似度檢測系統(tǒng)畢業(yè)設計源碼包面向計算機相關專業(yè)學生及NLP入門開發(fā)者可用于畢業(yè)設計、課程設計或文本語義匹配實踐。系統(tǒng)以Python 3.6.8開發(fā)采用BERT預訓練模型完成語義理解與相似度評估后端結合MySQL 5.7存儲數(shù)據(jù)前端頁面與PyCharm開發(fā)環(huán)境配套覆蓋搜索引擎、自動問答、推薦系統(tǒng)等典型應用場景。壓縮包共389個文件約52.19MB包含72個py源碼、35個js腳本、15個html頁面及18個css樣式文件另有數(shù)據(jù)庫sql、說明文檔docx與pdf、模型相關zip及圖片資源前后端與數(shù)據(jù)庫結構完整。項目說明文檔記錄了開發(fā)背景、設計思路、系統(tǒng)架構與運行環(huán)境源碼目錄便于理解實現(xiàn)機制數(shù)據(jù)庫文件提供建表與數(shù)據(jù)基礎。目前已有78人學習適合需要完整賽題方案、排錯思路與目錄結構參考的讀者。1. 文本相似度檢測系統(tǒng)從 BERT 到前后端落地的完整路徑很多做畢業(yè)設計的同學一看到文本相似度檢測就覺得無非是算個余弦相似度但真正動手才發(fā)現(xiàn)兩個句子長度不一樣怎么辦同義詞替換后相似度驟降怎么處理前端怎么把一段文本傳給后端模型MySQL 里到底存什么這些問題不解決系統(tǒng)就跑不起來。這個標題指向的是一套完整的工程方案——用 BERT 做語義向量化配合 Python 后端提供推理接口前端做交互展示MySQL 存儲檢測記錄最終交付一個可演示、可復現(xiàn)的文本相似度檢測系統(tǒng)。它適合正在做 NLP 方向畢業(yè)設計、需要一套能跑通全流程參考方案的開發(fā)者也適合想理解模型怎么變成系統(tǒng)這個跨越過程的同學。接下來我會把選型理由、代碼實現(xiàn)、參數(shù)配置和踩坑經(jīng)驗逐層拆開講。2. BERT 做文本相似度的原理與模型選型為什么不用 TF-IDF2.1 從詞袋模型到語義向量的本質(zhì)差異TF-IDF 和 Word2Vec 是很多人最先接觸的方案。TF-IDF 把文本當成詞頻統(tǒng)計向量兩個句子只要用詞不同哪怕意思一樣相似度也會很低。比如如何學習編程和怎樣入門寫代碼TF-IDF 算出來幾乎不相關。Word2Vec 稍好一些詞級別有語義但它是靜態(tài)詞向量——蘋果在吃蘋果和蘋果發(fā)布會里向量完全一樣句子級別的語義就丟失了。BERT 的核心優(yōu)勢在于它是動態(tài)編碼的。同一個詞在不同上下文里產(chǎn)生的向量不同而且 BERT 輸出的[CLS]token 向量或者池化后的句向量天然攜帶整句語義。做相似度檢測時把兩個句子分別編碼成固定維度向量再算余弦相似度就能捕捉到表述不同但含義接近的情況。常見做法是取 BERT 最后一層的[CLS]向量做句表示或者對所有 token 的輸出做 mean pooling。實踐中 mean pooling 在相似度任務上通常比[CLS]更穩(wěn)因為[CLS]在預訓練時主要服務于分類任務未必是句語義的最優(yōu)摘要。2.2 模型選型中文場景下的實際考量做中文文本相似度模型選擇直接決定效果上限。以下是幾種常見方案的實際對比模型參數(shù)量中文效果推理速度CPU適用場景bert-base-chinese110M良好約 200ms/對畢設首選資料多bert-base-multilingual-cased178M一般約 350ms/對需要多語言時輕量級蒸餾模型60M左右中等約 80ms/對對速度敏感時領域微調(diào)后的 BERT110M優(yōu)秀約 200ms/對有標注數(shù)據(jù)時對于畢業(yè)設計場景我一般建議從bert-base-chinese起步。原因很直接中文預訓練充分、HuggingFace 上文檔齊全、社區(qū)踩坑記錄多出了問題容易搜到答案。如果答辯時被問到為什么不用更大的模型可以從參數(shù)量與部署成本的平衡角度回答。注意不要一上來就追求 SOTA 效果。畢設的核心是展示完整的技術鏈路和工程能力模型選型合理、系統(tǒng)跑得通、有對比實驗比盲目堆大模型更有說服力。2.3 相似度計算方式的選擇拿到兩個句向量之后計算相似度有幾種方式余弦相似度最常用對向量長度不敏感值域 [-1, 1]適合歸一化后的向量歐氏距離值域 [0, ∞)需要額外做歸一化映射到 [0,1]曼哈頓距離對異常維度更魯棒但解釋性不如余弦實際工程中余弦相似度是默認選擇。代碼實現(xiàn)上先對向量做 L2 歸一化然后點積就是余弦相似度省去除法運算import torch import torch.nn.functional as F from transformers import BertTokenizer, BertModel # 加載預訓練模型和分詞器 model_name bert-base-chinese tokenizer BertTokenizer.from_pretrained(model_name) model BertModel.from_pretrained(model_name) model.eval() # 推理模式關閉 dropout def get_sentence_embedding(text): 將單句文本編碼為固定維度向量使用 mean pooling inputs tokenizer( text, return_tensorspt, paddingTrue, truncationTrue, max_length128 # 超過128個token截斷 ) with torch.no_grad(): # 不計算梯度節(jié)省內(nèi)存 outputs model(**inputs) # mean pooling對所有token的輸出取平均排除padding位置 attention_mask inputs[attention_mask] token_embeddings outputs.last_hidden_state # 擴展mask維度以匹配embedding維度 mask_expanded attention_mask.unsqueeze(-1).expand(token_embeddings.size()).float() sum_embeddings torch.sum(token_embeddings * mask_expanded, dim1) sum_mask torch.clamp(mask_expanded.sum(dim1), min1e-9) sentence_embedding sum_embeddings / sum_mask # L2歸一化后續(xù)點積即余弦相似度 sentence_embedding F.normalize(sentence_embedding, p2, dim1) return sentence_embedding def compute_similarity(text_a, text_b): 計算兩段文本的余弦相似度 emb_a get_sentence_embedding(text_a) emb_b get_sentence_embedding(text_b) # 歸一化后點積等于余弦相似度 similarity torch.sum(emb_a * emb_b, dim1) return similarity.item() # 測試 score compute_similarity(如何學習編程, 怎樣入門寫代碼) print(f相似度: {score:.4f})這段代碼的關鍵點有三個。第一attention_mask的處理——如果不排除 padding 位置短句的向量會被大量零向量稀釋導致相似度計算偏差。第二max_length128是權衡太長會拖慢推理太短會截斷信息中文場景下 128 個 token 大約覆蓋 200 多個漢字對大多數(shù)句子夠用。第三F.normalize之后用點積代替余弦公式減少一次除法運算批量計算時效率提升明顯。參數(shù)調(diào)整建議如果句子普遍較長比如段落級比對把max_length提到 256 或 512但要注意顯存占用會平方級增長。如果部署在 CPU 上且對延遲敏感可以降到 64犧牲一些長句精度換速度。3. 后端服務搭建Flask 接口設計與模型加載策略3.1 項目結構規(guī)劃一個清晰的項目結構能讓后續(xù)維護和答辯演示都省心。我一般會這樣組織text_similarity_system/ ├── app.py # Flask 主入口 ├── model/ │ ├── __init__.py │ ├── encoder.py # BERT 編碼邏輯 │ └── similarity.py # 相似度計算 ├── db/ │ ├── __init__.py │ ├── models.py # SQLAlchemy 數(shù)據(jù)模型 │ └── init_db.py # 建表腳本 ├── static/ # 前端靜態(tài)資源 ├── templates/ # HTML 模板 ├── requirements.txt └── config.py # 配置參數(shù)模型加載放在應用啟動時完成不要每次請求都重新加載。BERT 模型加載一次大約需要 2-5 秒取決于磁盤速度如果放在請求處理函數(shù)里每次調(diào)用都要等這個時間用戶體驗極差。3.2 Flask 接口實現(xiàn)from flask import Flask, request, jsonify, render_template from model.similarity import compute_similarity from db.models import db, SimilarityRecord import config app Flask(__name__) app.config[SQLALCHEMY_DATABASE_URI] config.DATABASE_URI app.config[SQLALCHEMY_TRACK_MODIFICATIONS] False db.init_app(app) app.route(/) def index(): 渲染前端頁面 return render_template(index.html) app.route(/api/similarity, methods[POST]) def api_similarity(): 文本相似度檢測接口 data request.get_json() # 參數(shù)校驗 text_a data.get(text_a, ).strip() text_b data.get(text_b, ).strip() if not text_a or not text_b: return jsonify({code: 400, msg: 文本不能為空}), 400 if len(text_a) 500 or len(text_b) 500: return jsonify({code: 400, msg: 文本長度不能超過500字}), 400 # 計算相似度 try: score compute_similarity(text_a, text_b) except Exception as e: return jsonify({code: 500, msg: f計算失敗: {str(e)}}), 500 # 判定等級 if score 0.85: level 高度相似 elif score 0.65: level 中度相似 else: level 低度相似 # 寫入數(shù)據(jù)庫 record SimilarityRecord( text_atext_a, text_btext_b, scoreround(score, 4), levellevel ) db.session.add(record) db.session.commit() return jsonify({ code: 200, data: { score: round(score, 4), level: level, record_id: record.id } }) app.route(/api/history, methods[GET]) def api_history(): 查詢歷史檢測記錄 page request.args.get(page, 1, typeint) per_page request.args.get(per_page, 10, typeint) pagination SimilarityRecord.query.order_by( SimilarityRecord.created_at.desc() ).paginate(pagepage, per_pageper_page, error_outFalse) records [{ id: r.id, text_a: r.text_a[:50], # 截斷展示 text_b: r.text_b[:50], score: r.score, level: r.level, created_at: r.created_at.strftime(%Y-%m-%d %H:%M:%S) } for r in pagination.items] return jsonify({ code: 200, data: { records: records, total: pagination.total, pages: pagination.pages } }) if __name__ __main__: with app.app_context(): db.create_all() # 首次運行自動建表 app.run(host0.0.0.0, port5000, debugFalse)接口設計上有幾個值得注意的決策。第一相似度閾值 0.85 / 0.65 不是拍腦袋定的而是根據(jù)實際測試數(shù)據(jù)調(diào)整的——BERT 中文模型在語義相近的句對上通常給出 0.8 以上的分數(shù)而完全不相關的句子一般在 0.3-0.5 之間。第二文本長度限制 500 字是防止惡意長文本拖垮服務同時也和前端輸入框的maxlength屬性保持一致。第三歷史記錄接口做了分頁避免一次性返回大量數(shù)據(jù)導致前端卡頓。3.3 數(shù)據(jù)庫表設計from flask_sqlalchemy import SQLAlchemy from datetime import datetime db SQLAlchemy() class SimilarityRecord(db.Model): 相似度檢測記錄表 __tablename__ similarity_record id db.Column(db.Integer, primary_keyTrue, autoincrementTrue) text_a db.Column(db.Text, nullableFalse, comment文本A) text_b db.Column(db.Text, nullableFalse, comment文本B) score db.Column(db.Float, nullableFalse, comment相似度分數(shù)) level db.Column(db.String(20), nullableFalse, comment相似等級) created_at db.Column(db.DateTime, defaultdatetime.now, comment創(chuàng)建時間) def __repr__(self): return fRecord {self.id}: {self.score}表結構保持簡單只存必要字段。text類型用Text而不是String(255)因為用戶可能輸入較長文本。created_at用datetime.now而不是datetime.utcnow因為畢設演示通常面向國內(nèi)用戶本地時間更直觀。注意MySQL 建庫時字符集務必用utf8mb4否則遇到 emoji 或生僻字會報錯。建庫語句CREATE DATABASE similarity_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;4. 前端交互與聯(lián)調(diào)從輸入框到結果展示的完整鏈路4.1 頁面結構與交互邏輯前端不需要太復雜核心是一個輸入?yún)^(qū)、一個結果展示區(qū)、一個歷史記錄列表。用原生 HTML CSS JavaScript 就夠了不必引入 Vue 或 React——畢設答辯時老師更關心功能是否完整而不是用了什么框架。!DOCTYPE html html langzh-CN head meta charsetUTF-8 title文本相似度檢測系統(tǒng)/title style .container { max-width: 800px; margin: 40px auto; padding: 0 20px; } .input-group { margin-bottom: 16px; } textarea { width: 100%; height: 100px; padding: 10px; border: 1px solid #ddd; border-radius: 6px; resize: vertical; } .btn { padding: 10px 32px; background: #4a6cf7; color: #fff; border: none; border-radius: 6px; cursor: pointer; font-size: 16px; } .btn:disabled { background: #aaa; cursor: not-allowed; } .result { margin-top: 24px; padding: 20px; background: #f5f7ff; border-radius: 8px; display: none; } .score { font-size: 36px; font-weight: bold; color: #4a6cf7; } .level { font-size: 18px; margin-top: 8px; } .history { margin-top: 40px; } .history table { width: 100%; border-collapse: collapse; } .history th, .history td { padding: 10px; border-bottom: 1px solid #eee; text-align: left; font-size: 14px; } /style /head body div classcontainer h1文本相似度檢測/h1 div classinput-group textarea idtextA placeholder請輸入文本A maxlength500/textarea /div div classinput-group textarea idtextB placeholder請輸入文本B maxlength500/textarea /div button classbtn idsubmitBtn onclickcheckSimilarity()開始檢測/button div classresult idresult div classscore idscoreValue--/div div classlevel idlevelValue--/div /div div classhistory h2歷史記錄/h2 table thead trth文本A/thth文本B/thth相似度/thth等級/thth時間/th/tr /thead tbody idhistoryBody/tbody /table /div /div script async function checkSimilarity() { const textA document.getElementById(textA).value.trim(); const textB document.getElementById(textB).value.trim(); if (!textA || !textB) { alert(請?zhí)顚憙啥挝谋?; return; } const btn document.getElementById(submitBtn); btn.disabled true; btn.textContent 檢測中...; try { const resp await fetch(/api/similarity, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ text_a: textA, text_b: textB }) }); const data await resp.json(); if (data.code 200) { document.getElementById(result).style.display block; document.getElementById(scoreValue).textContent (data.data.score * 100).toFixed(1) %; document.getElementById(levelValue).textContent data.data.level; loadHistory(); // 刷新歷史記錄 } else { alert(data.msg || 檢測失敗); } } catch (err) { alert(網(wǎng)絡錯誤請稍后重試); } finally { btn.disabled false; btn.textContent 開始檢測; } } async function loadHistory() { const resp await fetch(/api/history?page1per_page10); const data await resp.json(); if (data.code ! 200) return; const tbody document.getElementById(historyBody); tbody.innerHTML data.data.records.map(r tr td${r.text_a}/td td${r.text_b}/td td${(r.score * 100).toFixed(1)}%/td td${r.level}/td td${r.created_at}/td /tr ).join(); } // 頁面加載時拉取歷史記錄 loadHistory(); /script /body /html前端邏輯很直白用戶輸入兩段文本點擊按鈕后 POST 到后端接口拿到相似度分數(shù)和等級后展示同時刷新歷史記錄表格。按鈕在請求期間禁用防止重復提交。maxlength500和后端校驗保持一致避免用戶輸入超長文本后被后端拒絕卻不知道為什么。4.2 聯(lián)調(diào)時最容易卡住的三個點第一個是跨域問題。如果前端用 Live Server 跑在 5500 端口后端跑在 5000 端口瀏覽器會攔截請求。解決辦法有兩種一是后端加 CORS 頭二是把前端頁面直接放在 Flask 的templates目錄下由 Flask 渲染。畢設場景我推薦第二種省去跨域配置的麻煩。第二個是 JSON 解析失敗。Flask 的request.get_json()在請求頭沒有Content-Type: application/json時會返回None然后.get()就報錯。前端fetch里必須顯式設置這個頭或者后端用request.get_json(forceTrue)強制解析。第三個是模型首次推理特別慢。BERT 模型第一次前向傳播時需要初始化一些計算圖結構可能比后續(xù)推理慢 3-5 倍。解決辦法是在應用啟動后先跑一次預熱推理# 在 app.run 之前執(zhí)行一次預熱 with app.app_context(): db.create_all() # 預熱模型 _ compute_similarity(預熱文本, 預熱文本) print(模型預熱完成)5. 避坑與排查那些讓系統(tǒng)跑不起來的細節(jié)5.1 模型加載報 OOM 或顯存不足現(xiàn)象啟動 Flask 時拋出RuntimeError: CUDA out of memory或者進程被系統(tǒng) kill。原因BERT-base 模型加載到 GPU 大約占 400-500MB 顯存如果同時有其他進程占用或者批量推理時 batch size 設得太大就會溢出。解決畢設場景直接用 CPU 推理即可model.to(cpu)顯式指定。CPU 單次推理約 200ms對演示完全夠用。如果必須用 GPU把 batch size 設為 1并在推理后用torch.cuda.empty_cache()釋放緩存。5.2 相似度分數(shù)普遍偏高或偏低現(xiàn)象任意兩句話算出來都在 0.7 以上或者明明意思相近卻只有 0.4。原因前者通常是沒用 mean pooling 而是直接取了[CLS]向量后者可能是max_length設得太小導致長句被截斷或者沒有做 L2 歸一化。解決統(tǒng)一用 mean pooling L2 歸一化。如果分數(shù)整體偏高檢查是否在model.eval()模式下推理——訓練模式下的 dropout 會讓向量隨機波動。如果分數(shù)整體偏低把max_length從 128 提到 256 試試。5.3 MySQL 連接超時導致接口 500現(xiàn)象系統(tǒng)跑了一段時間后接口開始報OperationalError: (2006, MySQL server has gone away)。原因MySQL 默認wait_timeout是 8 小時連接池里的空閑連接被服務端斷開但客戶端不知道繼續(xù)用舊連接就報錯。解決在 SQLAlchemy 配置里加pool_pre_pingTrue每次從連接池取連接前先 ping 一下失效就重建app.config[SQLALCHEMY_ENGINE_OPTIONS] { pool_pre_ping: True, pool_recycle: 3600, # 1小時回收一次 pool_size: 5, max_overflow: 10 }5.4 中文輸入導致數(shù)據(jù)庫亂碼現(xiàn)象歷史記錄里中文顯示成???或亂碼。原因建庫時沒指定utf8mb4或者連接字符串沒加charset參數(shù)。解決連接字符串寫成mysqlpymysql://user:passhost/dbname?charsetutf8mb4同時確認建庫語句用了CHARACTER SET utf8mb4。5.5 前端請求一直 pending 最后超時現(xiàn)象點擊檢測按鈕后轉圈很久最后報網(wǎng)絡錯誤。原因Flask 默認單線程處理請求如果模型推理阻塞了主線程后續(xù)請求全部排隊。開發(fā)模式下app.run()默認threadedTrue但如果用了 gunicorn 且 worker 數(shù)為 1同樣會阻塞。解決開發(fā)時確認app.run(threadedTrue)部署時 gunicorn 至少開 2 個 worker或者用--threads 4參數(shù)。更徹底的做法是把模型推理放到獨立進程通過隊列通信但畢設場景沒必要做到這個程度。6. 進階技巧讓相似度檢測更準的幾個實用手段6.1 用對比學習微調(diào)提升領域效果預訓練 BERT 在通用語料上表現(xiàn)不錯但如果你的畢設場景是特定領域比如法律文書、醫(yī)療問答通用模型的相似度判斷可能不夠準。這時候可以用對比學習做微調(diào)構造正樣本對語義相同和負樣本對語義不同用 triplet loss 或 cosine embedding loss 訓練。from torch.optim import AdamW from transformers import get_linear_schedule_with_warmup # 假設 train_dataloader 返回 (anchor, positive, negative) 三元組 optimizer AdamW(model.parameters(), lr2e-5, weight_decay0.01) scheduler get_linear_schedule_with_warmup( optimizer, num_warmup_steps100, num_training_steps1000 ) model.train() for epoch in range(3): for batch in train_dataloader: anchor_emb get_sentence_embedding(batch[anchor]) pos_emb get_sentence_embedding(batch[positive]) neg_emb get_sentence_embedding(batch[negative]) # triplet loss: 讓 anchor 與 positive 更近與 negative 更遠 pos_sim torch.sum(anchor_emb * pos_emb, dim1) neg_sim torch.sum(anchor_emb * neg_emb, dim1) loss torch.clamp(neg_sim - pos_sim 0.3, min0).mean() loss.backward() optimizer.step() scheduler.step() optimizer.zero_grad()關鍵參數(shù)學習率用 2e-5BERT 微調(diào)的標準起點margin 設 0.3表示正負樣本相似度至少差 0.3訓練輪數(shù) 2-3 輪即可太多會過擬合。微調(diào)數(shù)據(jù)不需要太多每個類別幾百對就能看到明顯提升。6.2 緩存高頻查詢結果如果系統(tǒng)會被反復查詢相同的文本對加一層緩存能顯著降低響應時間。用 Python 內(nèi)置的functools.lru_cache最簡單from functools import lru_cache lru_cache(maxsize1000) def cached_similarity(text_a, text_b): 帶緩存的相似度計算相同輸入直接返回緩存結果 return compute_similarity(text_a, text_b)maxsize1000表示緩存最近 1000 組結果。注意這個裝飾器要求參數(shù)可哈希字符串天然滿足。如果文本很長緩存會占內(nèi)存可以改用 Redis 做外部緩存并設置過期時間。6.3 批量推理提升吞吐當需要一次性比對多組文本時逐對計算效率很低。把文本對拼成 batch 一起推理GPU 上能快 5-10 倍def batch_similarity(pairs, batch_size16): 批量計算文本對相似度 results [] for i in range(0, len(pairs), batch_size): batch pairs[i:ibatch_size] texts_a [p[0] for p in batch] texts_b [p[1] for p in batch] # 分別編碼兩組文本 emb_a get_sentence_embedding_batch(texts_a) emb_b get_sentence_embedding_batch(texts_b) # 逐對計算余弦相似度 sims torch.sum(emb_a * emb_b, dim1) results.extend(sims.tolist()) return resultsbatch_size根據(jù)顯存調(diào)整CPU 上建議 8-16GPU 上可以到 64 甚至 128。注意get_sentence_embedding_batch需要對整個 batch 做 padding確保所有序列長度一致。6.4 一個容易被忽略的驗證方法答辯前一定要做一輪人工驗證準備 20-30 組文本對人工標注相似/不相似然后跑系統(tǒng)看準確率。如果準確率低于 80%檢查是不是閾值設得不合理或者模型選型有問題。這個驗證過程本身也是答辯時的加分項——說明你不僅跑通了系統(tǒng)還做了效果評估。我自己的習慣是每次改完模型或參數(shù)先跑這 30 組驗證集確認沒有退化再繼續(xù)。這個習慣幫我省了很多改了一個地方結果整體效果崩了卻不知道的后悔藥。希望幫到你。本文還有配套的精品資源點擊獲取