简介这份DOCX文档面向计算机相关专业毕业设计学生与自然语言处理入门者围绕基于Python的文本相似度计算系统给出论文式方案参考可帮助解决选题立意、系统设计和论文结构搭建等问题。压缩包共1个DOCX文件约749KB主体为毕业设计论文文档包含中英文摘要、目录、绪论、可行性分析等章节并展开文本清洗与分词、TF-IDF关键词提取、词向量表构建、余弦相似度计算、Django可视化界面及MySQL数据存储等实现思路。文中还围绕不同文本数据集设置实验测试与结果评估说明系统在准确性、鲁棒性方面的表现便于读者理解从预处理到相似度展示的完整流程也可为梳理算法模块、完善系统设计说明、撰写同类课题和控制论文章节篇幅提供参照。已有138人学习适合需要借鉴毕设框架、技术方案与论文组织方式的中高级读者。1. 从两段文本有多像说起这套系统到底在算什么做毕业设计选题时文本相似度计算系统这几个字看起来很好懂真动手才发现坑在定义上什么叫像字面重合多少算像语义相近但用词完全不同算不算像某高校的 A 同学开题时最初的方案是直接调一个现成库算个分数打印出来被导师一句那你的系统做了什么问住了。这套基于 Python 的文本相似度计算系统要解决的不是算一个数而是把清洗、分词、向量化、相似度度量、结果可视化这条链路做成一个能登录、能比对文本与文件、能挂接新闻库的完整 Web 系统。它适合正在做自然语言处理方向毕业设计或课程设计、手里有一点 Django 基础但不知道工程该怎么拆的人也适合要交付一个可演示原型的技术方案负责人。2. 需求与技术选型为什么最终落在 Django jieba 余弦相似度需求不写清楚后面所有章节都是空转。这套系统的需求来源很具体用户打开网页两个输入框各贴一段文字点一下一秒内看到一个 0 到 1 之间的相似度分数外加一张能看懂的可视化图进阶一点上传一个 txt 文件系统拿它跟新闻库里的每条记录比一遍返回最像的那条。围绕这个动作功能清单、技术栈和指标才有落点。2.1 从用户动作拆出的功能清单把用户会做什么列出来功能需求自然浮现。第一类是比对文本框对文本框、文件对文本框、文件对新闻库。第二类是管理新闻条目的增删改查这一块保证系统里有可比对的语料不至于演示时只有两条假数据。第三类是账户注册、登录、个人信息做毕设可以简化为单角色但必须有因为要体现数据隔离和历史记录。功能需求落到具体条目上通常是这几条提供余弦相似度、编辑距离、Jaccard 相似度可选欧氏距离、曼哈顿距离多种度量方式并可切换完成文本清洗、分词、去停用词、词性标注的预处理链路把结果以分数加图表的形式可视化保留每次计算的历史记录便于回看。性能需求那几条也别写成套话。响应时间定在 1 秒内是合理的因为单次比对的计算量本身很小瓶颈往往在分词初始化和数据库查询上处理能力要覆盖中英文混合文本和不同长度文本长文本几千字不能直接把浏览器卡死稳定性要求 24 小时可运行对应的是异常捕获和超时处理不是真的去压测七天七夜。可靠性需求里数据安全这一条在课程设计层面落到密码哈希存储、CSRF 防护、上传文件类型白名单三件事上就够了。提示需求章节写支持多种文本类型时一定要在实现里给出对应的判断分支否则答辩时被追问英文怎么分的词会很难看。2.2 技术选型的取舍B/S 架构与全开源栈选题关键词里常混着 jsp、java 这类词但技术栈一旦定了 Python 系就别在文档里左右横跳。这套系统用的是 B/S 架构浏览器端 HTML CSS JavaScriptBootstrap 负责样式Ajax 负责异步提交服务端 Python Django数据落地 MySQL。为什么是 Django 而不是 FlaskFlask 更轻适合做单文件小服务但毕业设计要交的是系统需要用户体系、后台管理、ORM、表单校验、CSRF 防护这些现成件。Django 自带 admin 后台新闻条目可以直接在后台维护省掉一整块增删改查界面的工作量自带的 Form 和 ModelForm 还能顺手把输入校验做了。为什么是 MySQL 而不是 SQLiteSQLite 零配置本地演示完全够用但论文里写高性能、高可靠性就需要一个能撑住这个描述的东西MySQL 支持多用户并发连接、有独立的用户权限体系答辩时说得通。而且 Django 切换数据库只改 settings 里的 ENGINE本地开发用 SQLite、交付时切 MySQL 也是一条退路。中文分词为什么是 jiebaNLTK 和 spaCy 处理英文很顺中文分词并不擅长。jieba 支持精确模式、全模式、搜索引擎模式还能加载自定义词典对人工智能文本相似度这类领域词能保住不被切碎。英文侧继续用 NLTK 做停用词过滤和词干化两边各司其职。选型点候选方案最终选择决定性理由Web 框架Flask / DjangoDjango自带用户体系与后台减少重复开发数据库SQLite / MySQLMySQL支持并发连接符合系统级描述中文分词jieba / HanLPjieba轻量、可加载自定义词典、文档全英文处理NLTK / spaCyNLTK停用词表与词干化接口成熟前端原生 / BootstrapBootstrap表单与栅格开箱即用省样式时间2.3 性能与可靠性指标怎么定得住指标要能测。把1 秒内响应拆开看分词初始化jieba 首次加载词典约 0.3 到 0.8 秒可以放到应用启动时预热、文本向量化百字级文本毫秒级、数据库写入一次 insert、前端渲染。真正容易超时的是文件分析场景——上传一个 500KB 的 txt如果按行切分成上千段逐条比对新闻库同步请求必卡。常见的做法是给文件分析加两道闸上传文件大小限制在 2MB 以内比对时只取文件的前 N 段比如 20 段参与计算结果取最高分。这不是偷懒是在能演示和不卡死之间取的平衡方案文档里如实写出来反而是加分项说明你知道瓶颈在哪。可靠性方面需要兜住三类异常空输入或全停用词导致向量模长为 0除零、数据库连接断开、上传非 txt 文件。前两个用 try/except 加前置校验第三个用文件后缀白名单。这三条写进代码里比在文档里写十句具有较高的容错性更有说服力。3. 总体设计四层结构与五张核心表的职责划分总体设计要能画出两张图一张是分层数据流一张是 ER 图。画不出来说明还没想清楚。这套系统的骨架是经典三层加一层算法层——表现层负责输入与展示应用层负责请求调度与权限领域层放预处理、特征提取、相似度计算数据层管 MySQL 与文件存储。四层之间单向依赖算法层不碰 request 对象这样算法可以单独跑单元测试。3.1 分层与数据流一次点击之后的六步用户在文本框里贴两段话点击开始计算接下来发生六件事浏览器用 Ajax 把两段文本 POST 到/api/similarity/Django 的 URLconf 路由到视图函数视图先做参数校验非空、长度上限调用预处理模块各自产出词列表调用特征提取模块把两份词列表映射到同一词表空间得到两个等长向量调用相似度模块算分写入历史记录表返回 JSON前端拿到分数渲染仪表盘和词云。这里有个设计细节值得强调两份文本必须映射到同一个词表空间。很多人第一次写会各自建词袋向量长度都不一样余弦相似度根本没法算。正确做法是先取两份文本词集合的并集作为词表再分别统计词频这样两个向量天然等长对齐。用户输入 → 参数校验 → 清洗 → 分词 → 去停用词 → 构建共享词表 → 向量化(TF-IDF加权) → 余弦/Jaccard/编辑距离 → 结果落库 → JSON 返回 → 前端可视化文件分析走的是同一套流程只是输入源换成了文件读取比对目标换成了新闻表里的全量记录循环调用相似度函数后取 top-1 和 top-3。3.2 数据库设计从 ER 图落到建表语句ER 图里通常有四个实体用户、文本记录、新闻、操作日志。用户与文本记录是一对多用户与操作日志是一对多新闻独立成表供比对。再加一张停用词表方便后台维护词典。字段不用多够用就行。-- 文本比对记录表每次计算落一条支持历史回看 CREATE TABLE tb_compare_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL COMMENT 所属用户, text_a TEXT NOT NULL COMMENT 文本A原文, text_b TEXT NOT NULL COMMENT 文本B原文, algorithm VARCHAR(20) NOT NULL DEFAULT cosine COMMENT cosine/jaccard/edit, score DECIMAL(6,4) NOT NULL COMMENT 相似度分数 0-1, cost_ms INT DEFAULT 0 COMMENT 耗时毫秒, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_user_time (user_id, create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT文本比对记录; -- 新闻语料表文件分析时的比对目标库 CREATE TABLE tb_news ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(200) NOT NULL, content TEXT NOT NULL, category VARCHAR(50) DEFAULT default, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, FULLTEXT KEY ft_content (title, content) WITH PARSER ngram ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT新闻语料;utf8mb4这个字符集不是可选项中文、emoji、生僻字都靠它用utf8会在某些四字节字符上报错。score用DECIMAL(6,4)而不是FLOAT是为了回看历史时不会出现0.8999999这种显示。新闻表上的ngram全文索引是给后续扩展留的口子当前版本用不上也不影响。停用词表设计成id word lang三列lang区分中英文管理员在 Django admin 里增删程序启动时一次性加载进内存的 set避免每次分词都查库。3.3 模块间的接口约定与异常边界模块之间靠函数签名说话不靠全局变量。预处理模块对外只暴露cut_words(text: str) - list[str]特征提取暴露build_vectors(docs: list[list[str]]) - tuple[list, list]返回词表和向量矩阵相似度模块暴露四个函数每个都接收向量或字符串返回 float。异常边界定在视图层算法层内部不吞异常遇到空输入直接返回空列表或 0.0由视图决定给用户什么提示。这样算法层可以被单元测试直接调用不会因为request对象缺失而报错。这一点在答辩现场很实用——评委问你怎么保证算法正确你可以当场跑一个不含 Django 的测试脚本。4. 核心实现预处理流水线、向量化与四种相似度算法实现章节是整篇方案里最该写厚的地方。预处理和向量化决定了分数准不准相似度算法决定了分数怎么解释视图与前端决定了这套东西能不能被叫作系统。4.1 文本预处理流水线清洗、分词、去停用词、词干化预处理做四件事顺序不能乱先清洗掉 HTML 标签和标点再分词然后过滤停用词和单字英文额外做词干化。清洗放在分词前是因为标点会被 jieba 切成独立 token事后过滤不如事前删掉干净。# core/preprocess.py import re import jieba # 启动时加载一次避免每次请求重复读盘 jieba.load_userdict(dict/domain_words.txt) # 领域词文本相似度、词向量、余弦 STOP_WORDS {w.strip() for w in open(dict/stopwords_cn.txt, encodingutf-8)} def clean_text(raw: str) - str: 去标签、去符号只保留汉字、字母、数字 raw re.sub(r[^], , raw) # HTML 标签 raw re.sub(r[^\u4e00-\u9fa5a-zA-Z0-9], , raw) # 非文字字符 return re.sub(r\s, , raw).strip() def cut_words(text: str) - list: 中文精确模式分词 停用词过滤 text clean_text(text) if not text: return [] tokens jieba.lcut(text, cut_allFalse) # 单字信息量低直接丢弃停用词表命中则丢弃 return [w for w in tokens if len(w) 1 and w not in STOP_WORDS]cut_allFalse是精确模式全模式会把中华人民共和国切成中华/华人/人民/共和/共和国召回高但噪音大相似度计算用不到。len(w) 1这条过滤对中文很关键单字在短文本里会造成大量假重合A 同学的第一版没加这行两段毫不相干的文字能算出 0.4。停用词表建议 1200 到 2000 行覆盖虚词、代词、语气词、常见副词网上现成的表拿来改一改即可注意补上然后以及进行这类在技术文本里高频但无区分度的词。英文侧用 NLTK 的word_tokenize加PorterStemmer把 running/runs/ran 归到同一词根减少词形变化带来的假不相似。词干化不要用词形还原lemmatization后者依赖词性标注慢且容易在中文混合文本上出错。4.2 特征提取从词袋到 TF-IDF 加权词袋模型是最朴素的向量化方式建一个词表每篇文本按词出现与否填 0/1。原文设计里用的是这种标记法实现简单、可解释性强缺点是丢掉词频信息——一段话里算法出现十次和出现一次权重居然一样。实际交付时通常做一层加权。两种做法都值得写进方案一是词频TF统计每个词在本文本中出现的次数二是 TF-IDF用词频 × log(总文档数 / 含该词的文档数)把的是这类到处都有的词的权重压下去。import math from collections import Counter def build_vectors(docs: list, corpus_size: int None) - tuple: docs: 已分词的文档列表如 [[文本,相似度], [余弦,相似度]] 返回 (词表, 向量列表)向量与词表顺序严格对齐 vocab sorted({w for doc in docs for w in doc}) # 并集词表保证等长 index {w: i for i, w in enumerate(vocab)} # 文档频率用于 IDF语料只有两篇时加平滑避免除零 df Counter() for doc in docs: for w in set(doc): df[w] 1 n corpus_size or len(docs) vectors [] for doc in docs: tf Counter(doc) vec [0.0] * len(vocab) for w, c in tf.items(): idf math.log((n 1) / (df[w] 1)) 1 # 平滑 IDF vec[index[w]] (c / len(doc)) * idf # 归一化词频 × IDF vectors.append(vec) return vocab, vectorsbuild_vectors的入参是分词结果列表而不是原始文本这样预处理和向量化彻底解耦单元测试可以传入手工构造的词列表。corpus_size参数是给文件分析场景留的——比对 200 条新闻时IDF 应该基于 201 篇文档算而不是基于当前这两篇否则 IDF 完全失真。这个参数漏掉长文本比对新闻库的排序会明显偏。sorted()排序词表这步别省。Python 的 set 迭代顺序在不同进程里不一致不排序会导致同一个请求里两次构建的词表错位向量对齐就废了这类 bug 在本地测不出来换台机器就翻车。4.3 四种相似度度量的实现与选型建议系统对外宣称支持余弦、Jaccard、编辑距离、欧氏距离、曼哈顿距离实际每个的适用面差别很大方案里要说清什么时候用哪个。import numpy as np def cosine(a, b) - float: 余弦相似度关注方向不关注长度适合主题级比较 va, vb np.array(a), np.array(b) denom np.linalg.norm(va) * np.linalg.norm(vb) if denom 0: # 空文本或全停用词 return 0.0 return float(np.dot(va, vb) / denom) def jaccard(a: set, b: set) - float: Jaccard集合交并比适合关键词重合度 if not a or not b: return 0.0 return len(a b) / len(a | b) def edit_ratio(s1: str, s2: str) - float: 编辑距离归一化适合短文本、拼写纠错类场景 m, n len(s1), len(s2) if m 0 or n 0: return 0.0 prev list(range(n 1)) for i in range(1, m 1): cur [i] [0] * n for j in range(1, n 1): cost 0 if s1[i - 1] s2[j - 1] else 1 cur[j] min(prev[j] 1, cur[j - 1] 1, prev[j - 1] cost) prev cur return 1 - prev[n] / max(m, n)余弦相似度是默认选项它对文本长度不敏感一段 50 字和一段 500 字讲同一件事分数依然会高这在新闻推荐场景正是想要的。Jaccard 只看集合不看词频短文本上区分度更好但对重复强调不敏感一段话把某个词重复二十遍不会提升分数。编辑距离是字符级的中文里我喜欢你和我不喜欢你只差一个字得分 0.8语义却完全相反所以它只适合标题级短文本比对长文本上必须禁用否则会成为答辩现场的黑匣子。注意编辑距离在长度超过 200 字的文本上复杂度是 O(m×n)同步请求里跑一次可能就要几百毫秒务必在视图层加长度阈值超长时自动降级到余弦。4.4 Django 视图、表单与前端可视化落地后端视图的职责就三件校验、调用、落库返回。用 Django 的 Form 做第一道校验比在视图里手写 if 干净。# similarity/views.py from django.http import JsonResponse from django.views.decorators.http import require_POST from core.preprocess import cut_words from core.vector import build_vectors from core.metrics import cosine, jaccard require_POST def similarity_api(request): text_a request.POST.get(text_a, ).strip() text_b request.POST.get(text_b, ).strip() algo request.POST.get(algorithm, cosine) # 前置校验空值、超长直接拒绝不打到算法层 if not text_a or not text_b: return JsonResponse({code: 400, msg: 两段文本都不能为空}) if len(text_a) 5000 or len(text_b) 5000: return JsonResponse({code: 400, msg: 单段文本限 5000 字以内}) words_a, words_b cut_words(text_a), cut_words(text_b) vocab, (va, vb) build_vectors([words_a, words_b]) if algo jaccard: score jaccard(set(words_a), set(words_b)) else: score cosine(va, vb) CompareRecord.objects.create( user_idrequest.user.id, text_atext_a, text_btext_b, algorithmalgo, scoreround(score, 4) ) return JsonResponse({code: 200, score: round(score, 4), keywords: [vocab[i] for i in np.argsort(va)[-5:]][::-1]})require_POST这个装饰器挡住 GET 请求避免别人直接敲地址栏触发计算np.argsort(va)[-5:]取权重最高的五个词作为关键词回传前端可以直接渲染词云不用二次请求。返回结构统一成{code, msg, score, keywords}前端只写一套错误处理逻辑。前端用 Bootstrap 的栅格摆两个 textarea右侧一个结果卡。提交走 Ajax不刷新页面// static/js/similarity.js document.getElementById(calcBtn).addEventListener(click, async () { const form new FormData(document.getElementById(simForm)); const resp await fetch(/api/similarity/, { method: POST, headers: { X-CSRFToken: form.get(csrfmiddlewaretoken) }, body: form }); const data await resp.json(); if (data.code ! 200) { alert(data.msg); return; } // 分数映射成环形进度0 → 0deg1 → 360deg const deg Math.round(data.score * 360); document.getElementById(gauge).style.background conic-gradient(#4e73df ${deg}deg, #e3e6f0 ${deg}deg); document.getElementById(scoreText).textContent (data.score * 100).toFixed(1) %; });X-CSRFToken这行是必须的Django 默认开启 CSRF 防护Ajax 提交漏了它就会稳定返回 403这是新手最容易卡住的一个点。conic-gradient做环形仪表盘不需要引入图表库一行 CSS 解决比 ECharts 轻得多毕设演示完全够用。文件分析页再加一个input typefile accept.txt后端读文件时按errorsignore解码防止 GBK 编码的 txt 直接抛异常。5. 避坑与排查这套系统最容易翻车的五个地方以下五条都是这套系统在真实推进中反复出现的故障按现象 → 原因 → 解决的顺序写可以直接对照排查。5.1 算法与数据层面的三个坑坑一短文本相似度虚高两段无关的话也能算出 0.6 以上。现象是测试时随便输入两句毫不相干的中文分数依然不低演示时很尴尬。原因有三层词袋向量在维度稀疏时两句话合起来才几十个词大量维度都是 0余弦相似度天然偏高没有去停用词虚词贡献了主要重合单字没过滤的了这类字符级重合被算作相似。解决方式是三管齐下——停用词表补全、len(w) 1过滤单字、向量改用 TF-IDF 加权而非 0/1 标记。改完再测无关文本的分数通常会掉到 0.1 以下区分度立刻出来。坑二中文领域词被切碎文本相似度变成文本/相似度。现象是关键词提取结果里全是碎片词用户看着莫名其妙。原因是 jieba 的默认词典以通用语料训练词向量余弦相似度停用词这类专业组合不在其中HMM 会按统计概率切分。解决办法是jieba.load_userdict()加载自定义词典词典文件每行一个词可带词频和词性比如文本相似度 10 n。词频给大一点10 到 100能提高该词被整体切出的概率。这个动作要放在应用启动时执行一次放在函数里重复调用会拖慢响应。坑三空输入、纯符号输入导致 500 错误。现象是用户手滑只输入几个标点就点计算页面直接抛出ZeroDivisionError或ValueError: max() arg is an empty sequence。原因是清洗后词列表为空向量模长为 0除零或者编辑距离里取了空序列的 max。解决分两道视图层做非空校验并返回友好提示算法层每个函数入口加防御模长为 0 返回 0.0集合为空返回 0.0。防御性代码不丢人现场演示时用户永远会输入你想不到的东西。5.2 工程与部署层面的两个坑坑四MySQL 存取中文变问号或者报Incorrect string value。现象是后台录入的新闻标题在页面上显示成???或者插入含 emoji 的文本时报编码错误。原因是建库时用了utf8MySQL 里的 utf8 实际是 utf8mb3最多三字节四字节字符存不进去另一种情况是连接层字符集没设。解决要同时改三处建库建表语句写DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_general_ciDjango 的settings.py里OPTIONS增加charset: utf8mb4已有表用ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4迁移。改完记得重启服务配置不会热加载。坑五Ajax 提交稳定返回 403控制台看不到有用的报错。现象是页面上点按钮没反应Network 面板里/api/similarity/的状态码是 403响应体是一段 HTML 错误页。原因是 Django 的 CSRF 中间件要求 POST 请求携带 token而 Ajax 请求默认不带表单里的隐藏字段。解决办法是从表单里取csrfmiddlewaretoken放到请求头X-CSRFToken或者用csrf_exempt关掉不推荐等于把防护删了。如果取了 token 还是 403检查CSRF_COOKIE是否被浏览器拦截以及模板里有没有渲染{% csrf_token %}——忘了写这一行form.get(csrfmiddlewaretoken)取到的是 null。排查手法上养成两个习惯一是在视图入口打一行logger.info记录入参长度和算法选择出问题时看日志比断点快二是准备一个绕过 Django 的命令行测试脚本直接python -c调用cut_words和cosine能把是算法错了还是框架配置错了这个问题一刀切开。6. 验收与答辩用一张测试矩阵证明系统真的能跑验收不是我自己点了一遍没报错而是有一张能拿给评委看的表。测试用例按功能、边界、异常三类设计每条写明输入、预期、实际、结论。功能类测三种算法在同一对文本上的分数差异、文件分析能否返回最匹配的新闻边界类测空输入、单字符、5000 字长文本、纯英文、中英混合异常类测非 txt 文件上传、未登录访问接口、超长文本。用例编号场景输入预期结果TC-01余弦计算两段同义不同表述的文本分数 0.5 以上TC-02余弦计算两段完全无关文本分数 0.15 以下TC-03算法切换同一对文本切 Jaccard分数低于余弦但排序一致TC-04空输入一段为空返回 400 与中文提示TC-05长文本单段 5000 字响应时间 1 秒内页面不卡死TC-06文件分析上传 100KB txt返回 top-1 新闻标题与分数TC-07异常文件上传 .docx前端拦截并提示仅支持 txtTC-08权限未登录直接访问接口302 跳转登录页性能这一栏别只写满足要求用 Django Debug Toolbar 或time.time()打点把一次请求的耗时拆成预处理、向量化、计算、落库四段记录下来附在文档里。评委看到预处理 12ms、计算 3ms、数据库 8ms这种具体数字比看响应迅速四个字有说服力得多。答辩演示控制在三分钟第一分钟讲清输入两段文本、得到分数和可视化这个主流程直接用一对准备好的样例跑通第二分钟演示文件分析重点展示返回的最匹配新闻条目证明系统有语料库、不是空壳第三分钟打开历史记录页说明每次计算都落库、能回看体现数据设计。预留一分钟应对提问最常被问的三个问题是余弦相似度为什么对长度不敏感、停用词表怎么来的、如果换成深度学习模型你的架构要改哪里前两个答案在预处理和向量化章节里第三个诚实回答算法层是独立模块换模型只改特征提取这一层视图和表结构不动这个答案本身就是分层设计的好处。从那以后我每次交付这类系统都强制先跑一遍边界用例再进演示环境——空输入、超长文本、非目标格式文件这三个是现场翻车率最高的。测试矩阵不是给老师看的作业是给自己留的后悔药。希望帮到你。本文还有配套的精品资源点击获取