Java实现论文查重系统：中文分词、N-Gram与相似度算法实战指南

简介一份基于Java的论文查重系统完整源码包面向计算机相关专业学生、Java开发者与文本相似度检测初学者。系统核心采用SimHash算法计算原文与待检测论文之间的相似度输出重复率结果支持文件输入输出和命令行参数指定路径并包含性能分析与单元测试模块。资源共65个文件体积约461KB主要包含11个Java源文件、11个class编译产物、15个xml工程配置、10个txt测试语料、11张png示意图及1个md说明文档目录结构清晰可导入IntelliJ IDEA直接运行。已有110人学习该项目可作为课程设计或毕业设计的参考实现帮助读者掌握SimHash指纹去重、命令行交互、JUnit 4.12单元测试内置10余个用例以及JProfiler性能瓶颈定位等技能适合算法学习与工程实践快速上手。1. 基于 Java 的论文查重系统真正值钱的不是相似度算法而是文本处理边界我见过不少基于 Java 的论文查重系统源码真正能拿自己的论文集跑一遍还不翻车的没几个。原因不是相似度算法写得烂而是中文论文在变成向量之前很多人根本没想清楚该切什么、滤什么、留什么。论文查重不是字符串找相同它要把复述、换词、语序调整之后的句子也捞出来。这要求你先做中文分词、抽 N-Gram 特征再算余弦相似度或 SimHash。这篇博文写给打算自己搭一套查重工具的人不管是课程设计、公司内部文档去重还是想理解商业查重系统的工作方式Java 生态里都有现成的分词器可借力剩下的麻烦基本集中在工程边界和参数上。2. Java 论文查重的地基文本预处理、N-Gram 与相似度算法选型2.1 中文分词为什么绕不开字符串直接比对在论文场景下崩得很快论文正文是连续的中文文本“本文提出一种基于深度学习的检测方法”在字符层面上没有天然空格。直接对原字符串做包含匹配只能抓住逐字相同的片段只要作者把“提出”改成“给出了”字符匹配立刻失效。所以行业里的通用做法是先用中文分词器把句子切成词序列再在词序列上抽特征。Java 生态里常见的选择是 HanLP 或 IK Analyzer。下面这段代码以 HanLP 的StandardTokenizer为例做最基础的中文分词并过滤掉停用词import com.hankcs.hanlp.tokenizer.StandardTokenizer; import com.hankcs.hanlp.seg.common.Term; import java.util.ArrayList; import java.util.Arrays; import java.util.HashSet; import java.util.List; import java.util.Set; public class TextSplitter { private static final SetString STOP_WORDS new HashSet(Arrays.asList( 的, 了, 和, 在, 是, 我, 有, 与, 及, 等, 中, 也, 不 )); public static ListString tokenize(String text) { ListString result new ArrayList(); ListTerm terms StandardTokenizer.segment(text); for (Term term : terms) { String word term.word; if (word.length() 2) continue; // 过滤单字 if (STOP_WORDS.contains(word)) continue; // 过滤停用词 result.add(word); } return result; } }这里有两个参数值得说明word.length() 2会过滤掉“了”“的”这类单字但也会过滤掉英文单词“AI”“RPC”这种有实义的两字符缩写。如果你处理的是计算机类论文建议把长度条件改成同时保留“非中文长度 2”的词。停用词表我习惯控制在 100 个以内只滤掉最没区分度的虚词停用词过多会把“提出”“方法”这种论文高频实义动词也滤掉反而让抄袭句变得看不见。2.2 三种相似度算法的选型对比余弦、SimHash、编辑距离有了词序列后算相似度有三条常见路线余弦相似度、SimHash、编辑距离。它们的定位完全不同直接决定了系统能回答“哪一篇和哪一篇像”还是“这一段是不是抄了某一句”。算法特征粒度适合场景主要风险余弦相似度词频/特征向量段落级或全文级比对短文本特征稀疏结果不稳定SimHash64 位哈希指纹海量文档粗筛长文特征被稀释无法定位具体句编辑距离字符级标题、摘要、单句比较长文本算力开销为 O(n*m)不可扩展论文查重源码里一般会把 SimHash 和余弦相似度组合起来用。SimHash 先把文档压成一个只有 64 位的指纹把相似度比较变成汉明距离比较适合在几十万篇资料库里先排除掉明显无关的文档。剩下候选对再用余弦相似度做精确复核。如果直接用编辑距离遍历整个语料库时间矩阵很快会撑爆内存。2.3 为什么还要 N-Gram换词描述后连续碎片才是证据很多抄袭不是整句复制而是把句子主干换掉一半比如“本系统采用 Java 语言开发”改成“开发本系统时使用了 Java 技术”。分词后两组词列表相似度可能只有 0.3但它们在字面连续片段的维度上有大量重叠。所以我会在词特征之外叠加 N-Gram 特征。N-Gram 是把词序列按固定窗口滑动的组合N2 叫 bigramN3 叫 trigram。以下代码生成词级别的 bigrampublic static SetString ngrams(ListString tokens, int n) { SetString grams new HashSet(); for (int i 0; i tokens.size() - n; i) { grams.add(String.join(, tokens.subList(i, i n))); } return grams; }用Set而不是List保存 N-Gram是因为同一句话里重复出现的“系统 提出”“系统 提出”只算一个特征避免因为一句话反复说“系统提出”把相似度拉高。N 的取值也很关键N2 时召回高少量无关文本也可能误伤N3 更精确但对短句会丢失特征。论文正文我一般取 N2并把词向量和 bigram 向量合并后一起参与余弦计算。3. 用 Java 手写查重核心分词、向量化与余弦相似度完整实现3.1 最小工程结构和 Maven 依赖拿到一个“基于 Java 的论文查重系统源码”最关心的核心模块其实只有三个部分文本读取、特征提取、相似度计算。为了让这个路径可复现我建议工程结构拆成四个包reader负责读文件vectorizer负责清洗和分词similarity放余弦与 SimHashcli放命令行入口。Maven 里不用引入重量级搜索引擎只放一个分词器依赖就够了dependency groupIdcom.hankcs/groupId artifactIdhanlp/artifactId versionportable-1.8.4/version /dependencyportable-1.8.4是 HanLP 的一个轻量发布版自带核心词典不需要额外下载模型文件。如果你的项目想要更细颗粒度的自定义词典可以换成带data的完整版但那种版本体积大、启动慢不适合放进课程设计或工具型源码里。3.2 把文本清洗、分词和向量生成封装成一个工具类文本清洗不能只做一次trim()。论文都是 Word 文档导出的文本里面有无处不在的换行、全角空格、弯引号、编号“1.2.3”、参考文献里的[12]。这些噪声不清理干净后续跑出来的相似度会被大量无效字符拉偏。以下代码把清洗、去停用词、加 bigram 特征做成一个TextVectorizer工具类import com.hankcs.hanlp.HanLP; import java.util.ArrayList; import java.util.Arrays; import java.util.HashMap; import java.util.HashSet; import java.util.List; import java.util.Map; import java.util.Set; public class TextVectorizer { private static final SetString STOP_WORDS new HashSet(Arrays.asList( 的, 了, 和, 在, 是, 我, 有, 与, 及, 等, 中, 也, 不, 个, 我们, 他们, 通过, 进行, 都, 就 )); public static MapString, Integer vectorize(String text) { String normalized text.toLowerCase() .replaceAll([\\p{Punct}\\p{IsPunctuation}\\s], ); ListString tokens new ArrayList(); for (Term term : HanLP.segment(normalized)) { String word term.word; if (word.length() 2 || STOP_WORDS.contains(word)) { continue; } tokens.add(word); } MapString, Integer vec new HashMap(); for (String token : tokens) { vec.merge(token, 1, Integer::sum); } for (int i 0; i tokens.size() - 1; i) { String bigram tokens.get(i) tokens.get(i 1); vec.merge(bigram, 1, Integer::sum); } return vec; } }参数说明正则[\\p{Punct}\\p{IsPunctuation}\\s]会匹配中英文标点和所有空白符统一替换成单个空格。HanLP.segment在 2.x 版本里是标准入口返回分词结果。vec.merge(key, 1, Integer::sum)等价于“有这个 key 就加 1没有就放 1”用这一句代替了先containsKey再put的写法。bigram 权重默认等同于词权重如果发现查重结果对长句过于敏感可以把 bigram 的merge权重改成 0.5但要记得最后归一化。3.3 余弦相似度用稀疏向量避免内存爆炸两篇论文的特征向量如果都建模成完整的String[]一篇 5 万字的论文特征数量可能到四五千直接做密集数组比较没有问题。但当你把整个语料库几十万篇两两比较时内存开销就上去了。因此我一般用MapString, Integer表示稀疏向量只保存出现过的特征。余弦相似度的实现如下public class CosineSimilarity { public static double cosine(MapString, Integer v1, MapString, Integer v2) { if (v1.isEmpty() || v2.isEmpty()) return 0.0; MapString, Integer smaller v1.size() v2.size() ? v1 : v2; MapString, Integer larger smaller v1 ? v2 : v1; double dot 0; for (Map.EntryString, Integer entry : smaller.entrySet()) { Integer other larger.get(entry.getKey()); if (other ! null) { dot entry.getValue() * other; } } double norm norm(v1) * norm(v2); return norm 0 ? 0.0 : dot / Math.sqrt(norm); } private static double norm(MapString, Integer vector) { double sum 0; for (int value : vector.values()) { sum value * value; } return sum; } }这段代码会先遍历较小的向量通过larger.get(key)做常数级查询。这样点积计算次数是min(v1.size(), v2.size())而不是两个特征集合的笛卡尔积。norm方法里没有直接开方而是把两个范数的乘积先算出来再统一开方减少一次Math.sqrt调用。这个差异在单次比较中无所谓但用 for 循环跑一万对文档时能省出可感知的时间。3.4 跑通最小命令行示例两篇 txt 论文到底重多少有了向量化和余弦计算最小可运行入口就只剩下读文件和打印结果。下面这个PaperChecker类接收两个文本文件路径输出相似度分数和特征数量import java.nio.file.Files; import java.nio.file.Path; import java.util.Map; public class PaperChecker { public static void main(String[] args) throws Exception { if (args.length 2) { System.out.println(用法: java PaperChecker 论文1.txt 论文2.txt); return; } String text1 Files.readString(Path.of(args[0])); String text2 Files.readString(Path.of(args[1])); MapString, Integer v1 TextVectorizer.vectorize(text1); MapString, Integer v2 TextVectorizer.vectorize(text2); double score CosineSimilarity.cosine(v1, v2); System.out.printf(相似度: %.4f%n, score); System.out.println(特征数量: v1.size() / v2.size()); } }编译并运行mvn -q compile exec:java \ -Dexec.mainClasscom.example.checker.PaperChecker \ -Dexec.argsdoc1.txt doc2.txt如果手边没有 Maven也可以先mvn dependency:copy-dependencies拿到 HanLP 的 jar然后用javac -cp直接编译运行。看到输出相似度: 0.0000和特征数量: 0 / 0时先检查文本文件编码是不是 UTF-8以及是否全是难以读入的 PDF 复制乱码。这个最小系统已经能回答“两篇文章像不像”了但要扔进真实论文场景还需要处理阈值、性能和漏报。4. Java 论文查重的工程化阈值设置、SimHash 分桶与误判排错4.1 查重阈值怎么定才不会被论文答辩怼回来查重系统输出一个 0 到 1 的相似度分数后紧接着的问题就是“多高算抄袭”。这个阈值不能照搬商业系统因为商业平台有独立语料库和语义模型而你的系统特征集合是自己定的。我一般按下面的经验区间设置初值相似度区间判定建议处理动作0.00 - 0.20正常不提示0.20 - 0.40待观察标黄人工抽查重合句子0.40 - 0.60中风险标红生成详细重复片段报告0.60 - 1.00高风险阻断提交强制人工复核请注意这个表的前提是“同一学科领域的论文”。跨领域比较时“本文”“实验”“结果分析”这些高频词会拉高基础相似度所以阈值必须按目录分组后分别校准。工程化上建议把结果落库方便之后回看阈值调整前后的变化CREATE TABLE check_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, source_doc_id BIGINT NOT NULL, target_doc_id BIGINT NOT NULL, similarity DECIMAL(5,4) NOT NULL, decision VARCHAR(16) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );把每次查重的 source、target、score 和 decision 都存下来是调阈值最关键的一步。没有历史记录你就无法回答“为什么上周这个分数还是绿这周变成黄了”。4.2 语料变大后别再两两比较SimHash 分桶与粗筛精算你的源码如果只有几千篇论文暴力两两比较还扛得住。但到几万篇甚至几十万篇时O(n^2)的比较次数会直接把 CPU 打满。行业里普遍的做法是在余弦精算之前加一层 SimHash 粗筛。SimHash 的核心是先把特征映射成 64 位哈希按词频加权累加最后把正负号转成 0/1 指纹public class SimHash { public static String hash(MapString, Integer vec) { int[] v new int[64]; for (Map.EntryString, Integer entry : vec.entrySet()) { long h entry.getKey().hashCode(); int weight entry.getValue(); for (int i 0; i 64; i) { int bit (int) ((h i) 1L); v[i] (bit 1) ? weight : -weight; } } StringBuilder sb new StringBuilder(); for (int i 0; i 64; i) { sb.append(v[i] 0 ? 1 : 0); } return sb.toString(); } }这段代码里的是无符号右移避免hashCode()返回负数导致高位错误。实际生产环境我不会用 Java 自带的hashCode它分布不够均匀建议换 Guava 的Hashing.murmur3_32()。拿到 64 位指纹后把指纹切分 8 段每段作为一个桶的 key 存入HashMapString, ListDocFingerprint。查询时拿新文档的每一段去对应桶里找候选然后只对候选做余弦精算。这样配合阈值能让重查的规模从“全量两两比较”变成“桶内局部比较”。4.3 四个误判来源参考文献、代码块、表格和同义改写真实论文场景里最影响口碑的往往不是算法不强而是误判太蠢。我梳理过常见的四类问题误判场景现象处理方式参考文献不同论文的作者、年份、期刊名高度重合预处理阶段剥离参考文献段落或者单独建引用库代码块变量名、方法名相同但实现思路不同识别缩进或代码围栏跳过代码区域表格数字结构相同、数值相似数值列单独做归一化不参与正文向量同义改写“提出”改为“给出”整体语义相同叠加 N-Gram 与句法顺序特征参考文献误判是新手最容易踩的坑。很多论文的参考文献列表是从别的论文复制拼接的两篇论文可能正文毫无关系参考文献却高度重合直接把相似度拉到 0.3 以上。一个简单策略是正则匹配「参考文献」章节把后面的段落单独存到另一张表正文查重时不计入。代码块场景则适合用行首空格数和public、private、import这类特征判断。如果一篇论文里贴着 Spring 的ApplicationContext另一篇也贴同一段那只能说明都在写环境搭建不能证明正文抄袭。把这部分特征排除后分数才可信。5. 用“T 字回归法”验证 Java 查重系统改没改坏查重系统最难维护的不是算法而是你每次调完停用词、N-Gram 长度或阈值后没法确定是改好了还是改坏了。我自己的做法是一个固定输入、三条断言的回归测试被同事叫成“T 字回归法”取一段 30 字左右的核心句子构造复制版、同义改写版、无关版三份测试文本然后每次改动代码后跑一遍确认三条关系不破public class RegressionCheck { public static void main(String[] args) { String src 本系统基于 Java 实现论文查重核心算法支持中文分词与余弦相似度计算; String copy src; String rewrite 采用 Java 开发的论文查重程序使用中文分词与余弦相似度完成核心计算; String unrelated 今天天气很好适合出门跑步顺便买一杯咖啡; double s1 CosineSimilarity.cosine( TextVectorizer.vectorize(src), TextVectorizer.vectorize(copy)); double s2 CosineSimilarity.cosine( TextVectorizer.vectorize(src), TextVectorizer.vectorize(rewrite)); double s3 CosineSimilarity.cosine( TextVectorizer.vectorize(src), TextVectorizer.vectorize(unrelated)); System.out.printf(copy%.4f rewrite%.4f unrelated%.4f%n, s1, s2, s3); assert s1 0.9 : 完全复制必须被识别; assert s2 0.8 : 同义改写不能当成逐字复制; assert s3 0.2 : 无关文本分数不能过高; } }三条断言的阈值来自我自己的经验copy 必须高于 0.9rewrite 要低于 0.8unrelated 低于 0.2。如果你的系统跑完第一条不满足说明特征提取被破坏或 N-Gram 过长第三条不满足说明停用词表太短或者“系统”“算法”这类高频词权重失控。把这组测试文本固定成三个文件丢进src/test/resources/regression/目录每次跑mvn test时自动执行。如果你接手的源码里已经有查重记录表还可以再加一步“历史回归”找出上个月已经人工复核过的 50 对文档把查重系统现在跑出来的分数和历史人工结果做相关性对比。这样能直观看到阈值调整对“之前判定绿、现在判定黄”的文档影响有多大再决定要不要全局重跑一遍。T 字回归法的价值在于它把模糊的“感觉好多了”变成三个硬数字。每次改动分词、停用词或阈值后我只看copy是否保持高位、unrelated是否被压下去就能在五分钟内判断这次改动是否安全。本文还有配套的精品资源点击获取