简介一个基于Java与Vue的向量数据库语义检索与相似文档查重系统完整设计实例面向具备Java和Vue基础的后端工程师、架构师及NLP方向技术人员。该方案融合BERT文本向量化、Milvus向量数据库近邻检索及前后端分离架构覆盖文档上传、语义索引、查重分析到结果可视化全流程可用于学术查重、企业知识产权保护、网络内容监控等场景。包体为单个docx文档大小81KB内含完整代码示例、数据库设计、GUI设计思路及模块划分目录结构从项目背景、架构设计、模型描述到代码实现逐层展开便于按需查阅。文档重点讲解文本预处理、向量化嵌入、向量批量入库、相似度计算等核心逻辑并给出多格式文档解析、智能分段、自适应阈值及高亮比对报告等功能说明。已有153人学习/下载适合需要落地语义检索与查重系统的开发者作为设计参考与代码模板。1. 把关键词匹配换成语义向量JavaVue 做文档查重系统的第一性思考传统文档查重只要换个说法、调个语序关键词匹配就直接失效这是自然语言处理领域最典型的痛点。这套基于 Java Spring Boot Vue Milvus 向量数据库的语义检索与相似文档查重系统核心思路是把文本用 BERT 类模型映射成高维稠密向量再用余弦相似度做近似最近邻检索从根源上绕开「字面相同才判重」的缺陷。适合有 Java 和 Vue 基础的工程师想从零搭一套包含文档上传、文本向量化、向量检索、查重报告生成全流程的可运行系统。它不是一套纯研究 demo而是把工程落地需要的数据库表、API 规范、前后端代码、部署注意点都补齐了的完整实例拿来改改就能接业务。2. 架构与技术选型为什么语义查重必须上向量数据库而不是 ES 倒排索引2.1 从 TF-IDF 到 BERT 向量语义匹配的底层逻辑变化传统检索走的是倒排索引你搜「苹果价格」文档里必须出现「苹果」和「价格」这两个词才能命中。但用户真实场景里文档 A 写「iPhone 15 售价」文档 B 写「苹果手机多少钱」这两句话在关键词层面几乎零重合却在语义层面高度一致。这就是倒排索引的天花板。这套系统把文本先经过 BERT 模型做 embedding每个句子变成一个固定维度的向量常见是 768 维或 1024 维。「iPhone 15 售价」和「苹果手机多少钱」在向量空间里的距离会很近因为模型在预训练阶段已经学会了这两个表达在语义上等价。查重逻辑从「词面是否重合」变成「向量距离是否够近」这就是本质区别。工程实现上embedding 生成走了三步。第一步是文档预处理把 PDF、DOCX、TXT 解析成纯文本第二步是分段因为整篇文档做一次 embedding 会丢失局部语义一般按段落或固定窗口切成 200~500 字的分段第三步是调用嵌入 API 或本地模型生成向量。我一般习惯把分段文本和向量一起存 MySQL向量单独存 Milvus两边用分段 ID 关联这样查重报告里能精确到「第几段相似」。2.2 Milvus 对比 FAISS 和 Chroma为什么选它而不是别人向量检索组件有 FAISS、Chroma、Milvus 可选这套系统落地选的是 Milvus。三者的取舍我的理解是这样的。FAISS 是 Meta 开源的库检索速度极快但它本质是库不是服务数据持久化、多副本、水平扩展都要自己实现。Chroma 胜在轻量适合单机和小规模 demo但大规模数据下的性能调优空间小。Milvus 是云原生架构把向量索引、分片、查询都做成了分布式服务自带 SDK还支持标量过滤和向量检索的混合查询。从工程角度查重系统不只是「算个相似度」还需要按文档 ID 过滤、按时间范围过滤、批量写入向量、查询进度追踪这些如果用 FAISS 得自己写一堆胶水代码但在 Milvus 里是内置能力。要重点说的是Milvus 的 collection 设计要提前想清楚shards 数量和 index 类型在数据量上来之后改起来非常费劲第一次建 collection 时就要按目标数据量估算。2.3 系统整体架构Spring Boot 做服务端Vue 做交互层这套系统的架构是标准的前后端分离但重点不在「分离」本身而在数据流向怎么设计。前端 Vue 负责文档上传、查重任务发起、结果展示和高亮比对。上传的文件先到 Spring Boot 后端后端做完解析、分段、向量化把原始文件和向量分别入库。查重任务发起后后端把文件的所有分段向量拿去 Milvus 做相似度检索拿到候选结果回到 MySQL 里补充元数据文档标题、作者、上传时间最后按阈值过滤生成查重报告。前端只通过 REST API 和 WebSocket 拿数据。模块划分上后端主要分了这样几块文件解析模块、文本分段模块、向量化模块调嵌入 API、Milvus 操作模块、查重任务调度模块、报告生成模块。每一块的职责单一这个设计在部署和排错时会省很多事。2.4 嵌入模型的选择本地部署还是 API 调用这是一个成本问题向量化模型是语义查重的关键。原项目的代码里预留了两种方式一种是调用本地的 text2vec 或 BERT 服务另一种是调第三方嵌入 API。我的建议是如果你的文档量一天不超过几万段调 API 更划算因为不用维护 GPU 服务但数据量大且涉及隐私必须本地部署。嵌入维度是第一个坑。不同模型的输出维度不一样BERT base 是 768 维text2vec-large-chinese 是 1024 维而 Milvus 的 collection 在创建时就要指定维度。如果后面换模型导致维度变了老数据要么重新向量化要么做降维对齐。这套系统的代码里向量化模块单独抽了一层接口换模型时只需要改实现类不用动 Milvus 的读写逻辑。3. 后端核心实现从文档上传到向量入库的完整链路3.1 文档解析与文本标准化PDF、DOCX、TXT 的坑要分开踩文档解析是整套系统的第一个不稳定点。TXT 文件最省心直接按编码读但 PDF 和 DOCX 各有各的坑。PDF 解析我踩过最大的坑是「扫描件」。PDF 分两种文字型 PDF文本可以直接抽取扫描型 PDF实际是图片必须走 OCR否则抽出来是空白。原项目里 PDF 用的抽取方案基于 Apache PDFBox对文字型 PDF 效果可以但碰到扫描件会翻车。处理办法是加一道判断抽取出来的文本长度占页面内容比例过低就自动转向 OCR 接口。DOCX 解析相对简单本质是 ZIP 包里的 XML 文件用 POI 的 XWPFWordExtractor 就能抽出文本。代码实现public String extractDocx(MultipartFile file) throws IOException { XWPFDocument document new XWPFDocument(file.getInputStream()); XWPFWordExtractor extractor new XWPFWordExtractor(document); String text extractor.getText(); extractor.close(); document.close(); // 清理多余空行统一换行符避免分段时被空白干扰 text text.replaceAll(\r\n, \n) .replaceAll([ \t], ) .replaceAll(\n{2,}, \n) .trim(); return text; }这段代码做完两件事抽取 DOCX 全部文本然后做标准化清理。注意replaceAll(\n{2,}, \n)是为了把多个连续空行压缩成一个不然分段算法会把大量空行当成独立的「空段落」跑一遍向量化既浪费算力又污染索引。抽取后的文本先落库存一份原始内容方便后续排查解析是否有误。3.2 分段策略200 字一段比整篇一向量靠谱得多拿到纯文本后不能直接整篇做 embedding原因很简单文档动辄几千字语义被平均了查重时无法定位到具体位置。分段是查重精度的隐形决定因素。常见做法是按段落切分再按最大长度合并。这套系统里的分段逻辑是先按\n拆段每段如果超过 500 字再按标点符号切。核心参数是两个maxSegmentLength和overlapLength。public ListString segmentText(String text, int maxLength, int overlap) { ListString segments new ArrayList(); String[] paragraphs text.split(\n); StringBuilder current new StringBuilder(); for (String para : paragraphs) { if (current.length() para.length() maxLength current.length() 0) { segments.add(current.toString()); // 保留末尾 overlap 长度的内容让上下文信息不丢 String tail current.substring(Math.max(0, current.length() - overlap)); current new StringBuilder(tail); } current.append(para).append(\n); } if (current.length() 0) { segments.add(current.toString()); } return segments; }maxSegmentLength我一般设在 200~300 字太短语义不完整太长定位不精确。overlap设 50 字让相邻分段有部分重叠避免语义恰好被切在中间。这个细节直接决定查重报告里「相似段落」的边界是否合理。分好的每段分配一个段 ID后面向量化、入库、查重都基于这个 ID 做关联。3.3 文本向量化封装嵌入接口隐藏底层模型差异向量化模块不应该跟具体的模型耦合。这段代码用策略模式把嵌入逻辑抽象出来换模型时只改实现类。如果调本地模型服务走 HTTP如果调云端 API走 SDK但业务层的调用方式完全不用改Service public class EmbeddingService { private final RestTemplate restTemplate; Value(${embedding.api.url}) private String embeddingUrl; Value(${embedding.api.dimension}) private int dimension; public ListFloat getEmbedding(String text) { MapString, String request new HashMap(); request.put(text, text); // 调用嵌入服务返回的是 JSON 数组 ResponseEntityListFloat response restTemplate.postForEntity( embeddingUrl /encode, request, (ClassListFloat)(Class?)List.class); ListFloat vector response.getBody(); if (vector null || vector.size() ! dimension) { throw new RuntimeException(Embedding result dimension mismatch, expected dimension but got vector.size()); } return vector; } }这里有一个非常值得写的参数dimension必须校验。如果嵌入服务切了模型向量维度从 768 变成 1024Milvus 不会直接报错但检索结果会全乱。上线前写一个启动自检先拿一条样本文本跑一遍向量化确认维度对了再放量。3.4 Milvus 入库与索引构建nlist 和 nprobe 决定检索速度和召回率向量生成后要写入 Milvus。这里要建两个东西Collection 和 Index。Collection 相当于关系数据库的表Index 决定检索效率。这套系统里建 Collection 的代码参数要细说public void createCollection(String collectionName, int dimension) { FieldType idField FieldType.newBuilder() .setName(id) .setDataType(DataType.Int64) .setPrimaryKey(true) .setAutoID(false) .build(); FieldType docIdField FieldType.newBuilder() .setName(doc_id) .setDataType(DataType.Int64) .build(); FieldType segmentIdField FieldType.newBuilder() .setName(segment_id) .setDataType(DataType.Int64) .build(); FieldType vectorField FieldType.newBuilder() .setName(embedding) .setDataType(DataType.FloatVector) .setDimension(dimension) .build(); CreateCollectionParam param CreateCollectionParam.newBuilder() .withCollectionName(collectionName) .withDescription(document embedding collection) .withShardsNum(2) .addFieldType(idField) .addFieldType(docIdField) .addFieldType(segmentIdField) .addFieldType(vectorField) .build(); milvusClient.createCollection(param); }字段设计上doc_id用来关联 MySQL 的文档表segment_id关联分段表。建索引时nlist参数我建议设 1024 或 2048nprobe设 16 或 32这是一套实用经验——太大的话检索慢太小了召回率低。插入向量用批量方式单条插入在海量数据面前就是灾难。3.5 相似度计算与查重核心逻辑阈值怎么定能查多细查重核心逻辑是从 Milvus 查出候选集再用相似度阈值过滤。Milvus 默认支持的相似度度量方式是余弦相似度或 IP 内积这套系统用的是余弦。查重时的查询参数nprobe用的是 16返回的 TopK 取 10——多取几个候选再用精确的余弦计算过滤掉误召回的结果。两个文档的相似度我认同的做法是「分段对分段」去比而不是整篇比。文档 A 的每个分段去检索找到语义相近的候选段如果相似度超过阈值就记录一对相似分段。最终文档级相似度 相似分段数 / 总分段数。public MatchResult similarityCheck(Long docIdA, Long docIdB) { ListDocumentSegment segmentsA segmentMapper.findByDocId(docIdA); ListDocumentSegment segmentsB segmentMapper.findByDocId(docIdB); int matched 0; ListSegmentPair pairs new ArrayList(); for (DocumentSegment segA : segmentsA) { for (DocumentSegment segB : segmentsB) { float score cosineSimilarity(segA.getVector(), segB.getVector()); if (score similarityThreshold) { matched; pairs.add(new SegmentPair(segA, segB, score)); } } } double overlap segmentsA.isEmpty() ? 0 : (double) matched / segmentsA.size(); boolean isDuplicate overlap duplicateThreshold; return new MatchResult(pairs, overlap, isDuplicate); }阈值参数有两个similarityThreshold控制「段落相似」的判定一般取 0.82~0.9duplicateThreshold控制「文档查重」判定一般取 0.3~0.5。这两组值我后面会专门展开讲因为它们直接决定误报率和漏报率的平衡。4. 前端 Vue 与 API 协同从文件上传到查重报告高亮展示的完整交互链路4.1 文件上传与任务进度轮询比 WebSocket 更适合查重场景前端上传文件用的是 Vue 组件 Element UI后端接口是 POST/api/document/upload用 MultipartFile 接收。上传成功后返回文档 ID前端拿到这个 ID 立即触发查重任务。查重是个耗时的异步操作需要设计任务进度查询。这里没走 WebSocket用的是轮询——理由很简单查重任务分钟级起步不是毫秒级推送WebSocket 维护长连接的成本不值当。前端把查重任务 ID 拿到后每隔两秒调一次 GET/api/check/status/{taskId}接口看状态码从RUNNING到SUCCESS的流转同时把进度百分比渲染到进度条上。// Vue 组件中发起轮询 startPolling(taskId) { this.timer setInterval(async () { const res await axios.get(/api/check/status/${taskId}) this.progress res.data.progress this.status res.data.status if (res.data.status SUCCESS || res.data.status FAILED) { clearInterval(this.timer) if (res.data.status SUCCESS) { this.loadResult(taskId) } } }, 2000) }轮询间隔 2 秒是比较平衡的取值1 秒太频繁会打爆后端接口5 秒以上用户会感觉进度条卡顿。要注意清理定时器否则组件销毁后 setInterval 还在跑会触发已销毁组件的状态更新报错。这是 Vue 前端非常常见的「内存泄漏 控制台报错」来源。4.2 查重结果可视化相似段高亮比对长什么样查重结果展示有很多现成组件这套系统里用了 Diff 高亮的方式。后端返回的比对结果是一个 JSON 数组前端拿到后渲染左右两栏左边是源文档右边是检索命中的相似文档。相似片段用黄色底纹标出点击片段能弹出浮层显示两段文本的相似度评分和具体命中范围。template div classdiff-container div classdiff-panel left div v-forseg in sourceSegments :keyseg.id :class{ highlight: seg.highlight } clickselectSegment(seg) {{ seg.text }} /div /div div classdiff-panel right div v-forseg in targetSegments :keyseg.id :class{ highlight: seg.highlight } clickselectSegment(seg) {{ seg.text }} /div /div /div /template这里的高亮不是简单地对文本染色而是按「分段命中」粒度渲染。高亮判定依据是后端返回的matched字段前端只做展示不做相似度计算这个边界要守住。前端做后端的事是这类项目最常见的架构腐化起点。4.3 后端接口安全校验JWT 拦截器里最容易漏掉白名单前后端分离项目必配 JWT 认证。这套系统的拦截器实现里有一个细节值得提配置放行白名单时要特别小心OPTIONS请求——浏览器跨域预检不发 Authorization 头如果拦截器没放行 OPTIONS用户在登录页都跨不过去但奇怪的是用 Postman 测又正常。Configuration public class WebInterceptorConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(jwtInterceptor) .addPathPatterns(/api/**) .excludePathPatterns(/api/user/login, /api/user/register, /error) .excludePathPatterns(/**/*.html, /js/**, /css/**, /img/**) .excludePathPatterns(/api/**/*, /favicon.ico); } }还有两个建议一是把excludePathPatterns里的静态资源路径和业务路径彻底分开别用通配符一刀切二是接口层再做一层越权校验——用户只能查重自己上传的文档后端要校验登录用户 ID 和文档的 owner_id 是否一致否则单靠 JWT 是挡不住水平越权的。4.4 API 接口规范请求和响应体设计的两个可复用模板整套系统的接口文档定义得很完整这里挑查重任务的核心接口来讲。发起查重任务的请求体{ docId: 1024, targetCollection: doc_embedding, threshold: 0.85, checkScope: ALL }checkScope可以选ALL全库查重或SELECTED指定对比文档集合这个参数在业务场景里很重要——高校查重往往只要求跟往届论文库比不要求跟全网比。响应体统一用code message data结构避免各写各的{ code: 200, message: success, data: { taskId: 8888, status: RUNNING, progress: 0 } }这套接口设计规范的好处是前端处理异常时只需要判code ! 200不用为每个接口写一套错误处理逻辑。如果做成状态码碎片化的风格每个接口传自己的错误码前端维护成本会直线上升查重系统这种受关注度高的产品接口稳定比花哨更重要。5. MySQL 表设计与避坑指南从建表 SQL 到七个高频故障的排查记录5.1 核心表结构文档表、分段表、向量关联表的取舍系统用 MySQL 存结构化业务数据Milvus 存向量。MySQL 里的表设计围绕四类核心对象展开用户、文档、分段、查重任务与结果。文档表CREATE TABLE document ( id BIGINT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(255) NOT NULL, file_path VARCHAR(500) NOT NULL, file_type VARCHAR(20) NOT NULL COMMENT pdf/docx/txt/md, file_size BIGINT NOT NULL, status TINYINT DEFAULT 0 COMMENT 0上传中 1解析完成 2向量化完成 3失败, owner_id BIGINT NOT NULL COMMENT 上传用户ID, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_owner_created (owner_id, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;文件不直接存 MySQL只存路径。文件本体放磁盘或 OSS库表里留file_path字段这样查重系统集成到别的业务里时可以无缝切换到第三方存储。需要注意status字段非常关键是排查问题的第一入口——文档在哪个环节挂的看状态就一目了然。文档分段表CREATE TABLE doc_segment ( id BIGINT AUTO_INCREMENT PRIMARY KEY, doc_id BIGINT NOT NULL, segment_index INT NOT NULL COMMENT 分段序号, segment_text TEXT NOT NULL, word_count INT NOT NULL, vector_id BIGINT NOT NULL COMMENT 对应Milvus中的主键ID, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_doc_id (doc_id), INDEX idx_vector_id (vector_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这张表是 MySQL 和 Milvus 的桥vector_id指向 Milvus 中该分段向量记录的 ID。每次查重分词时先用 Milvus 返回的vector_id反查 MySQL 拿原始文本才能做高亮展示。这张表设计时segment_text字段把TEXT和VARCHAR混用的坑填上短段落存 VARCHAR 会导致索引膨胀全部用 TEXT 更省心。查重结果表CREATE TABLE check_result ( id BIGINT AUTO_INCREMENT PRIMARY KEY, task_id BIGINT NOT NULL, source_doc_id BIGINT NOT NULL, target_doc_id BIGINT NOT NULL, similarity DOUBLE NOT NULL, matched_segments INT NOT NULL COMMENT 命中分段数, total_segments INT NOT NULL, detail_json JSON COMMENT 分段命中明细前端高亮依赖此字段, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_task_id (task_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;detail_json字段直接存 JSON不拆表这是刻意为之。匹配明细里的结构是嵌套的文档 A 的段 3 命中文档 B 的段 5 和段 7拆成关系表会非常啰嗦查询时还要 JOIN 很多次。JSON 字段配合前端解析简单直接。5.2 避坑记录一PDF 扫描件全空白向量库里进了一堆空向量现象上传的 PDF 显示解析成功但向量库里的向量全是零向量查重结果几乎为 0跟随机匹配没区别。原因扫描版 PDF 根本不存在文本层PDFBox 抽出来的文本为空字符串空字符串经过 tokenizer 后也可能产出向量但不是有效语义向量。解决解析完文本先做长度校验text.length() 20的文档直接标记为「需 OCR」不能进向量化流程。OCR 方案一般接云端接口把 PDF 转成图片再逐页识别识别结果存回document表替换原始文本。这个校验写进DocumentParser里任何格式都过这一关。5.3 避坑记录二Milvus 查询巨慢问题出在索引没建现象数据量才 10 万条查重一次要 3 秒以上完全不可用。原因Milvus collection 建好后没建索引向量检索退化成暴力的全量比对百万级数据量直接卡死。这是最容易犯的错误——建 collection 不等于建索引两个是独立操作。解决写入数据前先建索引HNSW 类型参数M 16efConstruction 200。查询参数nprobe设为 16。建索引后首次查询会触发索引构建需要等一会儿之后查询延迟降到 200ms 以内。这段命令要写进部署脚本不能靠手工点控制台。5.4 避坑记录三换 embedding 模型后向量维度对不上报错不提示现象从 text2vec 换到 BGE-large 模型后写入 Milvus 时部分数据写入失败部分成功检索结果混乱。原因text2vec 输出 768 维BGE-large 输出 1024 维Milvus collection 创建时维度写死了 768高维向量要么被截断要么写入失败。解决在 embedding 服务里做维度校验不一致时直接抛异常拒绝写入。同时把 collection 的维度参数配置化放在application.yml里换模型时第一件事改配置而不是改代码。5.5 避坑记录四前端进度条卡 99%是查重任务抛了异常没落库现象进度条走到 99% 就不再动前端一直轮询任务不结束也不报错。原因查重逻辑里查完向量后就生成报告但报告生成代码抛了异常查重任务没走到最终的「更新状态为 SUCCESS」那个方法状态停留在 RUNNING。解决查重任务全程加 try-catch-finallyfinally 里必须更新任务状态为 SUCCESS 或 FAILED异常信息写进task表的error_msg字段。这样前端轮询时只要看到 FAILED 或定时拉取 error_msg就能给用户明确提示而不是让用户对着假进度条干等。5.6 避坑记录五JWT 拦截器放行路径写错文档上传接口返回 401现象前端能登录但一调上传接口就返回 401 Unauthorized用 Postman 带 Token 调也 401。原因拦截器把/api/document/upload拦截了同时excludePathPatterns里配置的放行规则没覆盖到上传这个路径文档上传附件时把 Token 放在 Header 里但 Spring 的拦截器匹配顺序或路径规则出了问题。解决确认拦截器路径规则放行规则里明确加上/api/user/login,/api/user/register。同时在拦截器里加一个「Token 为空时直接放行注册和登录以外的 OPTIONS 请求」——注意不是放行所有 OPTIONS而是放行不携带 Token 且路径不在白名单里的 OPTIONS 预检。这段逻辑写不对跨域问题和 401 会交替出现。6. 进阶技巧阈值自适应和索引参数调优让查重系统更合业务胃口固定阈值 0.82 在真实业务里会翻车。不同领域文档的语义密度差异巨大法律文书用词规范两篇正常文本的余弦相似度也可能在 0.7 以上而技术博客用词发散同主题文档可能只有 0.55 的相似度。服务不同业务线时0.82 对法律文书会产生大量误报对技术博客又是漏判。这套系统需要把阈值做成动态的。我推荐用「统计基线 标准差偏移」的方式做自适应阈值定期跑一批已知不相似的历史文档统计它们的段落相似度分布算出均值和标准差阈值取均值 2 倍标准差。这样不用人工干预每个业务域有自己的阈值。public double adaptiveThreshold(String businessType) { // 统计该业务线最近 1000 对非重复文档的相似度均值 Stats stats checkResultMapper.getStatsByBusinessType(businessType); double mean stats.getMean(); double stddev stats.getStddev(); return mean 2 * stddev; }这样改完法律文书库里词的相似度 0.72 可能就算重复因为该业务线的基线均值是 0.68而技术博客库里 0.63 才算重复因为基线值是 0.59。误报率能降一半以上。上线时建议先在灰度环境跑两周把历史查重任务全部重跑一遍统计新阈值下的命中率变化再切全量。这里给两个调优基线一是nprobe跟数据量的关系大致是nprobe越大召回率越高但延迟线性增长搜索前用 32 验证精度线上用 16 保延迟二是 HNSW 的M默认 16 即可efConstruction从 200 降到 128 对索引构建速度提升比较明显召回率损失在 1% 以内适合文档量很大的场景。这套系统整体拆下来架构和代码本身并不复杂真正的复杂度全部藏在边界条件和参数调优里。我接手这类项目后养成了一个习惯任何文档解析、向量化、检索的代码改动都强制跑一遍「最小验证集」——准备三对文档一对明显重复、一对语义改写、一对与主题无关每次改完代码先过这三对再放量。从那以后查重系统的线上回归基本没再翻过车这套验证流程也变成了团队接手所有 NLP 服务的第一课希望帮到你。本文还有配套的精品资源点击获取
