在AI应用和知识库项目里摸爬滚打了一段时间后我越来越确认一个事情传统的数据库检索方式在面对语义搜索和文档智能问答这类需求时是真的不够用。你光靠关键词匹配和SQL的LIKE查询永远解决不了用户搜苹果但文档里写的是iPhone这种级别的语义问题。于是我把目光投向了向量数据库。之前网上搜资料90%的教程都是Python示例Java的完整实践案例少得可怜而且很多Demo代码根本跑不通。这篇就把我踩过坑、填过土之后的完整方案写出来讲清楚Java怎么接向量数据库、文档怎么切分、向量怎么生成、检索怎么实现以及一系列工程化细节。项目核心是解决文档检索与语义搜索这个场景适合正在搞RAG、智能客服、企业知识库的后端Java开发同学直接参考。1. 项目整体思路为什么Java后端需要一个向量层1.1 从关键词匹配到语义检索差的不是算法而是数据组织方式先讲个背景。我之前在做一个企业合同知识库仓库里有几百份PDF和Word文档。业务方的需求很朴素员工输入去年和华为签的采购合同里违约金比例是多少系统要快速给出答案。用传统的ES方案我只能做分词和倒排索引。违约金比例这种词如果合同原文写的是违约赔偿金那ES的精确分词基本就废了搜出来一堆不相关的东西。要想让系统懂语义核心思路是把文本变成高维向量然后在向量空间里计算距离和相似度。苹果和iPhone这两个词的文本形式差了十万八千里但它们的语义向量在空间里距离很近。这个能力不是靠算法而是靠预训练的Embedding模型和海量语料训练得到的。向量数据库干的事情就是把生成后的向量存起来并提供高效的近邻检索能力也就是ANNApproximate Nearest Neighbor。所以这个项目的架构其实很清晰文档进来之后先做切割切出来的每一段文本都过一遍Embedding模型生成一个几百维的Float数组然后连同原文和元数据一起写入向量数据库。查询的时候用户的问题同样过一遍Embedding模型再拿这个查询向量去库里做相似度搜索取TopK结果返回。整个过程Java这边全程参与不依赖任何Python微服务这也是这个项目最有价值的地方。1.2 技术栈选型与整体架构这个项目我用了Spring Boot 3.x Java 17作为基础后端框架向量数据库选了Milvus向量化模型选用本地部署的ONNX格式中文Embedding模型。之所以不选在线API是因为企业级知识库对数据出域很敏感合同、医疗、客服对话这类数据不适合直接提交给第三方API做词向量转换。本地化部署虽然要花一些时间配置环境但数据安全性可控而且调用延迟更低QPS起来了之后在线API的成本会很高本地模型更划算。整体流程分两条链路。写入链路解析文档 - 清洗文本 - 文档切分 - 生成向量 - 写入Milvus。查询链路接收用户问题 - 生成查询向量 - Milvus向量检索 - 按元数据过滤 - 结果重排 - 返回给上层业务。这两条链路在Java服务内完全闭环Milvus只负责当向量存储和检索引擎不承担任何业务逻辑。2. 向量数据库选型Java生态里最务实的几个选项2.1 主流向量数据库横向对比数据库部署复杂度Java SDK成熟度混合检索支持适用场景Milvus中依赖K8s或Docker官方Java SDK接口完整支持Meta过滤大规模向量检索、RAG专用Elasticsearch中自带集群能力原生Java客户端完善全文检索向量已有ES需要兼顾全文搜索Redis低官方Java客户端很成熟较弱小规模原型验证、缓存场景PostgreSQL pgvector低JDBC即可一般SQL灵活已有PG业务需要统一存储我最终选择了Milvus主要原因有三点。第一它是纯正的向量数据库对ANN算法、内存索引、分片策略的优化非常深入单机集群模式下千万级向量检索的延迟都能压在100毫秒左右。第二它的Java SDK不是社区热情产物而是官方维护的milvus-sdk-java接口设计思路和REST API差不多用起来比较顺手。第三它支持标量字段过滤我可以把合同ID、文档分类、上传时间这些业务属性存成标量字段检索时先过滤再搜大幅缩小向量搜索范围实用性非常强。2.2 为什么没选Elasticsearch和RedisES其实是很多团队的第一直觉毕竟大部分后端项目里ES已经在了再复用岂不是省事。但我在对比测试中发现了问题ES的向量检索kNN search在数据量超过百万级之后性能曲线下降得很明显而且ES的内存存储结构不如Milvus这种为向量设计的系统高效。另外一个问题是ES的向量能力在开源版本中支持得不够灵活一些高级参数如efConstruction、M需要配置深度调优对普通业务开发者来说门槛偏高。当然如果你的项目本身已经重度使用ES做全文检索而且数据量不大直接升级版本用ES的向量检索能力也完全合理这属于已有基础设施优先的策略。Redis做过一轮测试结论是仅适合Demo阶段或几百条数据的在线测试原因是它的向量模块是基于内存哈希结构的简单实现没有Milvus那样完善的索引和分段存储机制查询延迟虽然低但召回率不稳定。我在本地用一万条随机向量测过Redis的搜索召回率在80%左右Milvus在90%以上差距还是很明显的。3. 环境准备Milvus部署与Java工程搭建3.1 Docker方式快速部署Milvus Standalone很多教程一上来就推荐Milvus集群模式需要部署etcd、Pulsar、MinIO等一大堆组件直接把新人吓退。其实单机环境或者测试环境用Standalone模式就足够了Docker Compose一条命令就能把Milvus跑起来。我本地开发环境的docker-compose.yml关键部分是这样写的version: 3.5 services: etcd: image: quay.io/coreos/etcd:v3.5.5 environment: - ETCD_AUTO_COMPACTION_MODErevision - ETCD_AUTO_COMPACTION_RETENTION1000 - ETCD_QUOTA_BACKEND_BYTES4294967296 - ETCD_SNAPSHOT_COUNT50000 command: etcd -advertise-client-urlshttp://127.0.0.1:2379 -listen-client-urlshttp://0.0.0.0:2379 minio: image: minio/minio:RELEASE.2023-03-20T20-16-18Z environment: MINIO_ACCESS_KEY: minioadmin MINIO_SECRET_KEY: minioadmin command: minio server /minio_data --console-address :9001 milvus: image: milvusdb/milvus:v2.3.4 command: [milvus, run, standalone] environment: ETCD_ENDPOINTS: etcd:2379 MINIO_ADDRESS: minio:9000 ports: - 19530:19530 - 9091:9091 depends_on: - etcd - minio跑起来之后Milvus默认监听19530端口这就是gRPC通信的入口。Java SDK连接的就是这个端口。这里我踩过一个大坑Docker Desktop的版本如果太老etcd和minio这两个依赖容器的健康检查会一直不通过导致Milvus启动后连不上。解决方式是先把Docker Desktop升级到最新版然后用docker compose up -d依次启动最后用docker logs milvus看日志确认milvus started successfully再继续开发。3.2 Java工程引入Milvus SDK与连接工具类Maven里引入SDK非常简单需要注意版本号要对应你的Milvus服务端版本。我用的Milvus 2.3.4服务端对应的Java SDK版本是2.3.x。过新或过旧的客户端版本在gRPC协议对接时可能出现method not found或者属性字段不兼容的问题。dependency groupIdio.milvus/groupId artifactIdmilvus-sdk-java/artifactId version2.3.4/version /dependency连接Milvus这步网上很多老教程用的是MilvusServiceClient这个类在2.3.x版本中还是主流。我封装了一个Milvus配置类把连接参数放到application.yml里这样多环境切换比较省事Component public class MilvusClientFactory { private static MilvusServiceClient client; Value(${milvus.host:localhost}) private String host; Value(${milvus.port:19530}) private int port; PostConstruct public void init() { ConnectParam connectParam ConnectParam.newBuilder() .withHost(host) .withPort(port) .build(); client new MilvusServiceClient(connectParam); } public static MilvusServiceClient getClient() { return client; } }这里有个实际经验值得说一下MilvusServiceClient本身是线程安全的也就是说我可以在Service层直接通过静态方法获取实例然后用同一个实例并发查询不需要为每个请求新建连接。新建连接的开销很大每个连接底层都会创建gRPC Channel连接数一多Milvus服务端会报too many channels的错误。4. 文档预处理文本切分与向量生成4.1 文档切分策略固定窗口还是语义边界很多第一次做向量检索的同学会忽略文档切分直接把一整篇几千字甚至几万字的合同文档丢给Embedding模型生成向量。这会导致两个问题一是模型对超长文本的编码能力有限超过512个token之后后面的内容信息会被严重稀释语义向量几乎全是噪音二是检索的粒度太粗用户问违约金的计算基数是多少返回的是一整篇合同向量后端根本不知道应该拿哪一段去再加工和回答。所以切分是必须的这是所有RAG管道里最影响检索质量的步骤之一。我实践下来中文场景最稳妥的策略是分层切分先按语义结构切出章节块比如按二级标题、按空行分出来的段落如果某个语义块仍然超过设定的最大长度再按固定窗口二次切分同时保留一定的重叠区域。固定窗口的大小设置要考虑Embedding模型的上下文长度我用的是BGE-small-zh它的最大长度是512个token中文场景下我通常把窗口设为200到300个字重叠区域设为50个字左右。过长会导致语义信息截断过短会导致块与块之间上下文断裂。切分代码我用Java实现了一个简单的DocumentSplitter核心逻辑是按\n\n先分段落再根据长度决定是否二次切分public ListDocChunk split(String text, int maxLength, int overlap) { ListDocChunk chunks new ArrayList(); String[] sections text.split(\\n\\n); for (String section : sections) { section section.trim(); if (section.isEmpty()) continue; if (section.length() maxLength) { chunks.add(new DocChunk(section)); } else { int start 0; int end Math.min(start maxLength, section.length()); while (start section.length()) { String chunkText section.substring(start, end); chunks.add(new DocChunk(chunkText)); if (end section.length()) break; start Math.max(0, end - overlap); end Math.min(start maxLength, section.length()); } } } return chunks; }实际项目中文本清洗很重要常见要做的处理包括去掉PDF解析产生的多余换行符、把全角标点统一成半角、把空白字符正则替换、识别并剔除页眉页脚。这些不做切出来的块经常是一半正文一半页脚向量检索效果会大打折扣。我个人曾经因为漏掉页眉清理导致检索结果里高频出现某个固定公司名一度以为模型出了问题排查半天才意识到是页眉污染了向量。4.2 Embedding模型选择与Java端加载向量生成是整个链路中的核心计算环节。最开始我想偷懒直接调云端API但考虑到数据合规和延迟最终采用本地部署ONNX模型。Java端做推理我选了ONNX Runtime它对Java的支持比较完善而且不需要额外开启Python环境的依赖。模型我用的是BGE-small-zh-v1.5它对中文语义检索的效果在同等体积模型里表现很好输出维度是512维。下载下来之后会得到一个.onnx文件和一个vocab.txt词表。加载模型和生成向量的核心代码是这个样子public class EmbeddingService { private OrtSession session; private OrtEnvironment env; private BertTokenizer tokenizer; public void loadModel(String modelPath) throws OrtException { env OrtEnvironment.getEnvironment(); OrtSession.SessionOptions options new OrtSession.SessionOptions(); options.setOptimizationLevel(OrtSession.SessionOptions.OptLevel.ALL_OPT); session env.createSession(modelPath, options); tokenizer new BertTokenizer(vocab.txt); } public float[] embed(String text) throws OrtException { ListString tokens tokenizer.tokenize(text); // 对BGE模型需要添加 [CLS] 和 [SEP] 标记 long[] inputIds new long[tokens.size()]; long[] attentionMask new long[tokens.size()]; // 填充inputIds... OnnxTensor inputIdsTensor OnnxTensor.createTensor(env, inputIds, new long[]{1, tokens.size()}); OnnxTensor attentionMaskTensor OnnxTensor.createTensor(env, attentionMask, new long[]{1, tokens.size()}); MapString, OnnxTensor inputs new HashMap(); inputs.put(input_ids, inputIdsTensor); inputs.put(attention_mask, attentionMaskTensor); OrtSession.Result results session.run(inputs); // 获取last_hidden_state取[CLS]位置的向量 } }这段代码只是核心逻辑的示意实际用的时候有很多细节尤其是分词和Tensor的shape转换。但我要强调一个更关键的坑BGE系列模型在检索场景下必须添加指令前缀中文对应的前缀是为这个句子生成表示以用于检索相关文章查询侧和文档侧都要加上否则检索效果会退化得非常明显。我一开始没加前缀测试的时候Top5的命中率只有30%加了之后直接到85%以上差距非常夸张。如果你不想在Java里折腾ONNX Runtime的tokenizer也可以用另一种务实方案单独写一个Python小服务部署Embedding模型Java通过gRPC或HTTP调用。但这样架构上多了一个服务部署复杂度上升而且Python服务的守护、重启、版本管理都成了新的问题。我后来还是走回了Java直接加载ONNX模型的路线虽然技术栈稍微硬核一点但一劳永逸部署就一套Java服务。5. 核心实现Collection定义、数据写入与语义检索5.1 Milvus集合定义与文档写入链路Milvus里的Collection可以理解成关系型数据库里的表字段定义好了之后写入向量就必须严格按照字段来。我的集合设计是这样的字段名类型说明idInt64自增主键docIdVarChar原始文档的唯一标识contentVarChar当前chunk的纯文本内容categoryVarChar文档分类用于标量过滤embeddingFloatVector(512)语义向量创建Collection代码如下public void createCollection(String collectionName) { FieldType idField FieldType.newBuilder() .withName(id).withDataType(DataType.Int64) .withPrimaryKey(true).withAutoID(true).build(); FieldType docIdField FieldType.newBuilder() .withName(docId).withDataType(DataType.VarChar).withMaxLength(256).build(); FieldType contentField FieldType.newBuilder() .withName(content).withDataType(DataType.VarChar).withMaxLength(65535).build(); FieldType categoryField FieldType.newBuilder() .withName(category).withDataType(DataType.VarChar).withMaxLength(128).build(); FieldType embeddingField FieldType.newBuilder() .withName(embedding).withDataType(DataType.FloatVector).withDimension(512).build(); CreateCollectionParam createParam CreateCollectionParam.newBuilder() .withCollectionName(collectionName) .withDescription(知识库文档向量集合) .addFieldType(idField) .addFieldType(docIdField) .addFieldType(contentField) .addFieldType(categoryField) .addFieldType(embeddingField) .build(); milvusClient.createCollection(createParam); }字段维度这个细节特别容易出错模型的输出维度、创建Collection时指定的维度、以及实际写入向量的长度三者必须完全一致。我在项目里遇到过一把情况是模型输出的实际维度是512但我创建Collection时误写成了768插入的时候报float vector dim check failed排查了快一个小时才意识到是字段定义写错了。建议你在代码里把维度定义成常量不要散落在各处。写入链路我建议用批量插入Milvus对大批量写入的吞吐性能远好于逐条插入。我封装好的批量写入逻辑是把一组文档chunk的向量和元数据都组装好一次性提交public void upsertChunks(ListDocChunk chunks, String docId, String category) { ListListFloat vectors new ArrayList(); ListString contents new ArrayList(); ListString docIds new ArrayList(); ListString categories new ArrayList(); for (DocChunk chunk : chunks) { float[] vector embeddingService.embed(chunk.getText()); vectors.add(toFloatList(vector)); contents.add(chunk.getText()); docIds.add(docId); categories.add(category); } InsertParam insertParam InsertParam.newBuilder() .withCollectionName(COLLECTION_NAME) .withFields(Map.of( docId, docIds, content, contents, category, categories, embedding, vectors )) .build(); RMutationResult response milvusClient.insert(insertParam); if (response.getStatus() ! R.Status.Success.getCode()) { throw new RuntimeException(Milvus insert failed: response.getMessage()); } }这里面有个性能相关的经验批量插入时一次插多少个合适我的建议是500到1000条chunk为一批太少会频繁触发网络往返和Milvus内部的数据落盘太多则容易导致内存峰值和请求超时。我实际测过1000条512维向量单次插入耗时大概200毫秒左右吞吐足够了。5.2 语义检索API与混合检索方案写入完成之后查询才是真正见真章的地方。查询侧处理流程没那么复杂核心就是把用户输入的问题用同一个Embedding模型转成向量然后调用Milvus的search接口搜TopK但有几个容易被忽略的工程细节要做好。我实现了一个searchSimilarDocs方法支持按分类过滤和TopK配置public ListSearchResult searchSimilarDocs(String query, String category, int topK) { float[] queryVector embeddingService.embed(query); SearchParam searchParam SearchParam.newBuilder() .withCollectionName(COLLECTION_NAME) .withVector(queryVector) .withTopK(topK) .withOutputFields(List.of(docId, content, category)) .build(); if (category ! null !category.isEmpty()) { searchParam.getSearchParams().put(category, category); // Milvus支持在搜索时用过滤表达式例如 category 合同 searchParam.setExpr(category \ category \); } RSearchResults response milvusClient.search(searchParam); SearchResults data response.getData(); ListSearchResult results new ArrayList(); for (SearchResults.SearchResult hit : data.getResults()) { SearchResult sr new SearchResult(); sr.setScore(hit.getScore()); sr.setContent((String) hit.getFieldData(content)); sr.setDocId((String) hit.getFieldData(docId)); results.add(sr); } // 按分数排序并返回 results.sort((a, b) - Float.compare(b.getScore(), a.getScore())); return results; }这里有几个要点。第一个是相似度度量的选择BGE模型推荐用CosineMilvus创建Collection和索引时都要设置成MetricType.COSINE这样才能保证检索分数语义正确。第二个是过滤表达式如果业务上允许按分类过滤一定要先过滤再检索不要拿全量向量撞一次再在业务层过滤那样又慢又浪费算力。第三个是搜索结果的排序Milvus返回的结果本身是有序的但我在代码里还是做了一次排序兜底保证逻辑清晰。另外如果你要做的不是单纯的向量检索而是全文语义混合检索那Milvus也支持在同一个Collection上做标量过滤和向量搜索的组合。但如果你想同时做BM25关键词召回和向量召回那需要自己写一部分逻辑把ES的BM25分数和Milvus的向量分数做加权融合。我在项目中做过的方案是ES做关键词召回Milvus做向量召回两条结果按rank fusion算法合并这个效果在长尾query上会明显好于单一检索方式。不过为了控制篇幅混合检索的细节这次不展开讲后面单独开一篇来写。6. 上线之后踩过的坑索引、性能与工程化细节6.1 忘记建索引导致的百万级数据全表扫描这是我在Milvus上踩过最疼的坑。一开始我只创建了Collection并写入数据没有单独建索引结果查询速度一开始还行数据量到几十万之后单条查询耗时直接飙到3秒以上。Milvus如果不对向量字段建索引搜索就会退化成暴力扫描本质上就是全量计算相似度数据量越大越慢。后来我把索引改成HNSW建索引的代码如下public void createIndex(String collectionName) { CreateIndexParam indexParam CreateIndexParam.newBuilder() .withCollectionName(collectionName) .withFieldName(embedding) .withIndexType(IndexType.HNSW) .withMetricType(MetricType.COSINE) .withExtraParam({\M\: 16, \efConstruction\: 200}) .build(); RRpcStatus response milvusClient.createIndex(indexParam); }HNSW索引的两个核心参数是M和efConstruction。M代表每个节点的最大连接数M越大表示图越密集召回率越高但内存和索引构建时间也会增加一般取16或32。efConstruction是构建时的动态列表长度越大索引质量越高但构建越慢200是一个比较平衡的选择。查询时还有一个ef参数我会在SearchParam里单独配置它控制查询时的搜索范围越大召回越高但延迟越高。我的建议是召回优先场景ef设64或128延迟敏感场景设32。关于建索引还有一个坑如果你先写入数据再建索引当数据量很大的时候建索引过程非常耗内存和CPU生产环境最好在Collection创建好之后就立即建索引然后再灌数据。Milvus是支持在写入过程中增量构建索引的但如果先灌数据再触发建索引遇到大数据量会产生明显的IO抖动。6.2 Java工程化里的数据一致性、并发与超时问题在实际接入过程中数据处理链路长不像单表CRUD那么简单有几点工程化细节值得单独记一笔。首先是写入一致性的保障。我的场景是从消息队列里消费到文档后先解析、切分、向量化再写入Milvus。如果向量化或写入过程中服务重启了那这条文档数据就丢了。为了避免这个问题我加了一个文档状态表用MySQL记录每个文档的切分数量、向量化状态和写入状态。流程是接收文档 - 创建状态记录PENDING - 切分向量化 - 写Milvus - 更新状态为SUCCESS。下一次启动时扫描状态为PENDING的文档重新处理一遍这样既保证了最终一致性又不会重复写入大量数据。其次是并发问题。Java这边用了线程池并发处理文档切分和向量化但在调用ONNX模型做推理时OrtSession不是线程安全的并发推理需要做同步或者用线程局部变量。我的土办法是每线程一个Session实例这样既避免了锁竞争又充分利用了多核CPU。MilvusClient倒是线程安全的可以直接并发调用但要注意控制并发度我压测下来8到16个并发写入或查询线程都比较稳定再高容易触发Milvus端的连接池瓶颈。最后是超时和重试。Milvus的网络交互是gRPC超时时间默认比较长但业务接口不能让用户等太久。我给检索接口设置了一个超时器超过2秒就暂时返回服务繁忙或走降级策略避免把连接池拖死。同时每次写入操作都加了失败重试逻辑重试三次间隔指数退避。这里我踩过的一个小坑是Milvus的insert操作不是幂等的如果客户端写超时后重试服务端可能已经写入成功导致同一条chunk插了两遍。解决方法是插入前生成一个业务侧唯一ID写入时用这个ID作为主键靠autoID就不行要自己指定ID这样重复插入就能被主键冲突挡住。6.3 检索效果调优从糟糕结果到可用状态项目上线之后我调了一段时间的检索效果。要知道向量检索不是接完就完事的效果好坏受切分粒度、向量模型、查询侧文本处理、TopK参数等多重因素影响。这里把几个性价比最高的优化手段按优先级列一下优化项具体操作效果提升切分窗口从500字降到200到300字中检索粒度更精准添加指令前缀BGE模型查询和文档侧都加前缀极大命中率翻倍元数据过滤检索时优先按category过滤高缩小搜索范围结果重排序Top10召回后按原文轻量rerank高最后一条内容质量决定用户体验去掉停用词查询文本清理的、了、呢小但稳定重排序这步我很推荐做。最简单的方式是Milvus先招回Top20然后把这20条chunk的文本和用户问题再做一次余弦相似度重算取更精确的Top5返回给上游做答案生成。因为Milvus的ANN搜索本身是近似的Top20的精度可能不如Top5但重排序能把这部分误差纠回来。我实际体验下来重排序后的结果比直接Top5的满意度要高不少而且实现成本很低几十行代码的事。有个建议是把重排序逻辑和Milvus搜索解耦独立成一个RerankService方便后续升级成CrossEncoder模型而不是每次都做余弦重算。如果你有精力做CrossEncoder的重排序会更专业模型效果相比普通余弦相似度有明显代差。6.4 快速排错速查表最后把这段时间遇到的典型问题整理成一个速查表方便大家少走弯路现象大概率原因解决方式milvus connect failDocker依赖容器etcd/minio没起用docker compose up -d全部拉起确认健康状态创建Collection报维度错误模型输出维度与Collection定义不一致打印模型输出shape与字段dimension对齐查询结果为空没有写入数据或expr过滤条件太严格先去掉过滤条件测试再用collection stats验证数据量查询速度突然变慢向量字段没建索引创建HNSW或IVF索引等待索引就绪插入时返回主键冲突自增ID被关闭且业务侧指定了重复ID检查ID生成逻辑或改用autoIDJava进程内存溢出批量插入数据量过大每次插入控制在1000条以内及时释放list结果语义相关性差没加BGE指令前缀或切分窗口过大按上文添加前缀缩短切分窗口还有一个小细节Milvus的collection如果删除重建之前的数据就彻底没了所以生产环境一定不要在生产connection上随便执行dropCollection。我在开发环境就手滑过一次结果整个知识库的向量数据全部清空重新跑了一遍全量入库流程白白浪费了一个下午。结尾分享这套Java接向量数据库的方案已经在我的知识库项目里稳定跑了两个多月文档入库量累计超过20万条chunk单次查询平均耗时120毫秒左右数据安全性也因为全本地化模型而得到了保障。我个人实操中的体会是向量数据库本身不难接难的是把文档怎么切、向量怎么生成、检索怎么调优这套链路想明白。如果你也在做类似项目建议先拿一个小数据集从切分和模型的前缀效果开始做起把每一步的结果都打印出来看一眼不要等到全链路完成再一起调试那是灾难。最后再分享一个小技巧每次修改切分策略或模型后别急着全量更新索引先选一个真实用户查询用新方案跑一遍对比一下返回的Top5结果效率最高。
Java接入Milvus实现语义搜索：文档智能检索全链路实战
在AI应用和知识库项目里摸爬滚打了一段时间后我越来越确认一个事情传统的数据库检索方式在面对语义搜索和文档智能问答这类需求时是真的不够用。你光靠关键词匹配和SQL的LIKE查询永远解决不了用户搜苹果但文档里写的是iPhone这种级别的语义问题。于是我把目光投向了向量数据库。之前网上搜资料90%的教程都是Python示例Java的完整实践案例少得可怜而且很多Demo代码根本跑不通。这篇就把我踩过坑、填过土之后的完整方案写出来讲清楚Java怎么接向量数据库、文档怎么切分、向量怎么生成、检索怎么实现以及一系列工程化细节。项目核心是解决文档检索与语义搜索这个场景适合正在搞RAG、智能客服、企业知识库的后端Java开发同学直接参考。1. 项目整体思路为什么Java后端需要一个向量层1.1 从关键词匹配到语义检索差的不是算法而是数据组织方式先讲个背景。我之前在做一个企业合同知识库仓库里有几百份PDF和Word文档。业务方的需求很朴素员工输入去年和华为签的采购合同里违约金比例是多少系统要快速给出答案。用传统的ES方案我只能做分词和倒排索引。违约金比例这种词如果合同原文写的是违约赔偿金那ES的精确分词基本就废了搜出来一堆不相关的东西。要想让系统懂语义核心思路是把文本变成高维向量然后在向量空间里计算距离和相似度。苹果和iPhone这两个词的文本形式差了十万八千里但它们的语义向量在空间里距离很近。这个能力不是靠算法而是靠预训练的Embedding模型和海量语料训练得到的。向量数据库干的事情就是把生成后的向量存起来并提供高效的近邻检索能力也就是ANNApproximate Nearest Neighbor。所以这个项目的架构其实很清晰文档进来之后先做切割切出来的每一段文本都过一遍Embedding模型生成一个几百维的Float数组然后连同原文和元数据一起写入向量数据库。查询的时候用户的问题同样过一遍Embedding模型再拿这个查询向量去库里做相似度搜索取TopK结果返回。整个过程Java这边全程参与不依赖任何Python微服务这也是这个项目最有价值的地方。1.2 技术栈选型与整体架构这个项目我用了Spring Boot 3.x Java 17作为基础后端框架向量数据库选了Milvus向量化模型选用本地部署的ONNX格式中文Embedding模型。之所以不选在线API是因为企业级知识库对数据出域很敏感合同、医疗、客服对话这类数据不适合直接提交给第三方API做词向量转换。本地化部署虽然要花一些时间配置环境但数据安全性可控而且调用延迟更低QPS起来了之后在线API的成本会很高本地模型更划算。整体流程分两条链路。写入链路解析文档 - 清洗文本 - 文档切分 - 生成向量 - 写入Milvus。查询链路接收用户问题 - 生成查询向量 - Milvus向量检索 - 按元数据过滤 - 结果重排 - 返回给上层业务。这两条链路在Java服务内完全闭环Milvus只负责当向量存储和检索引擎不承担任何业务逻辑。2. 向量数据库选型Java生态里最务实的几个选项2.1 主流向量数据库横向对比数据库部署复杂度Java SDK成熟度混合检索支持适用场景Milvus中依赖K8s或Docker官方Java SDK接口完整支持Meta过滤大规模向量检索、RAG专用Elasticsearch中自带集群能力原生Java客户端完善全文检索向量已有ES需要兼顾全文搜索Redis低官方Java客户端很成熟较弱小规模原型验证、缓存场景PostgreSQL pgvector低JDBC即可一般SQL灵活已有PG业务需要统一存储我最终选择了Milvus主要原因有三点。第一它是纯正的向量数据库对ANN算法、内存索引、分片策略的优化非常深入单机集群模式下千万级向量检索的延迟都能压在100毫秒左右。第二它的Java SDK不是社区热情产物而是官方维护的milvus-sdk-java接口设计思路和REST API差不多用起来比较顺手。第三它支持标量字段过滤我可以把合同ID、文档分类、上传时间这些业务属性存成标量字段检索时先过滤再搜大幅缩小向量搜索范围实用性非常强。2.2 为什么没选Elasticsearch和RedisES其实是很多团队的第一直觉毕竟大部分后端项目里ES已经在了再复用岂不是省事。但我在对比测试中发现了问题ES的向量检索kNN search在数据量超过百万级之后性能曲线下降得很明显而且ES的内存存储结构不如Milvus这种为向量设计的系统高效。另外一个问题是ES的向量能力在开源版本中支持得不够灵活一些高级参数如efConstruction、M需要配置深度调优对普通业务开发者来说门槛偏高。当然如果你的项目本身已经重度使用ES做全文检索而且数据量不大直接升级版本用ES的向量检索能力也完全合理这属于已有基础设施优先的策略。Redis做过一轮测试结论是仅适合Demo阶段或几百条数据的在线测试原因是它的向量模块是基于内存哈希结构的简单实现没有Milvus那样完善的索引和分段存储机制查询延迟虽然低但召回率不稳定。我在本地用一万条随机向量测过Redis的搜索召回率在80%左右Milvus在90%以上差距还是很明显的。3. 环境准备Milvus部署与Java工程搭建3.1 Docker方式快速部署Milvus Standalone很多教程一上来就推荐Milvus集群模式需要部署etcd、Pulsar、MinIO等一大堆组件直接把新人吓退。其实单机环境或者测试环境用Standalone模式就足够了Docker Compose一条命令就能把Milvus跑起来。我本地开发环境的docker-compose.yml关键部分是这样写的version: 3.5 services: etcd: image: quay.io/coreos/etcd:v3.5.5 environment: - ETCD_AUTO_COMPACTION_MODErevision - ETCD_AUTO_COMPACTION_RETENTION1000 - ETCD_QUOTA_BACKEND_BYTES4294967296 - ETCD_SNAPSHOT_COUNT50000 command: etcd -advertise-client-urlshttp://127.0.0.1:2379 -listen-client-urlshttp://0.0.0.0:2379 minio: image: minio/minio:RELEASE.2023-03-20T20-16-18Z environment: MINIO_ACCESS_KEY: minioadmin MINIO_SECRET_KEY: minioadmin command: minio server /minio_data --console-address :9001 milvus: image: milvusdb/milvus:v2.3.4 command: [milvus, run, standalone] environment: ETCD_ENDPOINTS: etcd:2379 MINIO_ADDRESS: minio:9000 ports: - 19530:19530 - 9091:9091 depends_on: - etcd - minio跑起来之后Milvus默认监听19530端口这就是gRPC通信的入口。Java SDK连接的就是这个端口。这里我踩过一个大坑Docker Desktop的版本如果太老etcd和minio这两个依赖容器的健康检查会一直不通过导致Milvus启动后连不上。解决方式是先把Docker Desktop升级到最新版然后用docker compose up -d依次启动最后用docker logs milvus看日志确认milvus started successfully再继续开发。3.2 Java工程引入Milvus SDK与连接工具类Maven里引入SDK非常简单需要注意版本号要对应你的Milvus服务端版本。我用的Milvus 2.3.4服务端对应的Java SDK版本是2.3.x。过新或过旧的客户端版本在gRPC协议对接时可能出现method not found或者属性字段不兼容的问题。dependency groupIdio.milvus/groupId artifactIdmilvus-sdk-java/artifactId version2.3.4/version /dependency连接Milvus这步网上很多老教程用的是MilvusServiceClient这个类在2.3.x版本中还是主流。我封装了一个Milvus配置类把连接参数放到application.yml里这样多环境切换比较省事Component public class MilvusClientFactory { private static MilvusServiceClient client; Value(${milvus.host:localhost}) private String host; Value(${milvus.port:19530}) private int port; PostConstruct public void init() { ConnectParam connectParam ConnectParam.newBuilder() .withHost(host) .withPort(port) .build(); client new MilvusServiceClient(connectParam); } public static MilvusServiceClient getClient() { return client; } }这里有个实际经验值得说一下MilvusServiceClient本身是线程安全的也就是说我可以在Service层直接通过静态方法获取实例然后用同一个实例并发查询不需要为每个请求新建连接。新建连接的开销很大每个连接底层都会创建gRPC Channel连接数一多Milvus服务端会报too many channels的错误。4. 文档预处理文本切分与向量生成4.1 文档切分策略固定窗口还是语义边界很多第一次做向量检索的同学会忽略文档切分直接把一整篇几千字甚至几万字的合同文档丢给Embedding模型生成向量。这会导致两个问题一是模型对超长文本的编码能力有限超过512个token之后后面的内容信息会被严重稀释语义向量几乎全是噪音二是检索的粒度太粗用户问违约金的计算基数是多少返回的是一整篇合同向量后端根本不知道应该拿哪一段去再加工和回答。所以切分是必须的这是所有RAG管道里最影响检索质量的步骤之一。我实践下来中文场景最稳妥的策略是分层切分先按语义结构切出章节块比如按二级标题、按空行分出来的段落如果某个语义块仍然超过设定的最大长度再按固定窗口二次切分同时保留一定的重叠区域。固定窗口的大小设置要考虑Embedding模型的上下文长度我用的是BGE-small-zh它的最大长度是512个token中文场景下我通常把窗口设为200到300个字重叠区域设为50个字左右。过长会导致语义信息截断过短会导致块与块之间上下文断裂。切分代码我用Java实现了一个简单的DocumentSplitter核心逻辑是按\n\n先分段落再根据长度决定是否二次切分public ListDocChunk split(String text, int maxLength, int overlap) { ListDocChunk chunks new ArrayList(); String[] sections text.split(\\n\\n); for (String section : sections) { section section.trim(); if (section.isEmpty()) continue; if (section.length() maxLength) { chunks.add(new DocChunk(section)); } else { int start 0; int end Math.min(start maxLength, section.length()); while (start section.length()) { String chunkText section.substring(start, end); chunks.add(new DocChunk(chunkText)); if (end section.length()) break; start Math.max(0, end - overlap); end Math.min(start maxLength, section.length()); } } } return chunks; }实际项目中文本清洗很重要常见要做的处理包括去掉PDF解析产生的多余换行符、把全角标点统一成半角、把空白字符正则替换、识别并剔除页眉页脚。这些不做切出来的块经常是一半正文一半页脚向量检索效果会大打折扣。我个人曾经因为漏掉页眉清理导致检索结果里高频出现某个固定公司名一度以为模型出了问题排查半天才意识到是页眉污染了向量。4.2 Embedding模型选择与Java端加载向量生成是整个链路中的核心计算环节。最开始我想偷懒直接调云端API但考虑到数据合规和延迟最终采用本地部署ONNX模型。Java端做推理我选了ONNX Runtime它对Java的支持比较完善而且不需要额外开启Python环境的依赖。模型我用的是BGE-small-zh-v1.5它对中文语义检索的效果在同等体积模型里表现很好输出维度是512维。下载下来之后会得到一个.onnx文件和一个vocab.txt词表。加载模型和生成向量的核心代码是这个样子public class EmbeddingService { private OrtSession session; private OrtEnvironment env; private BertTokenizer tokenizer; public void loadModel(String modelPath) throws OrtException { env OrtEnvironment.getEnvironment(); OrtSession.SessionOptions options new OrtSession.SessionOptions(); options.setOptimizationLevel(OrtSession.SessionOptions.OptLevel.ALL_OPT); session env.createSession(modelPath, options); tokenizer new BertTokenizer(vocab.txt); } public float[] embed(String text) throws OrtException { ListString tokens tokenizer.tokenize(text); // 对BGE模型需要添加 [CLS] 和 [SEP] 标记 long[] inputIds new long[tokens.size()]; long[] attentionMask new long[tokens.size()]; // 填充inputIds... OnnxTensor inputIdsTensor OnnxTensor.createTensor(env, inputIds, new long[]{1, tokens.size()}); OnnxTensor attentionMaskTensor OnnxTensor.createTensor(env, attentionMask, new long[]{1, tokens.size()}); MapString, OnnxTensor inputs new HashMap(); inputs.put(input_ids, inputIdsTensor); inputs.put(attention_mask, attentionMaskTensor); OrtSession.Result results session.run(inputs); // 获取last_hidden_state取[CLS]位置的向量 } }这段代码只是核心逻辑的示意实际用的时候有很多细节尤其是分词和Tensor的shape转换。但我要强调一个更关键的坑BGE系列模型在检索场景下必须添加指令前缀中文对应的前缀是为这个句子生成表示以用于检索相关文章查询侧和文档侧都要加上否则检索效果会退化得非常明显。我一开始没加前缀测试的时候Top5的命中率只有30%加了之后直接到85%以上差距非常夸张。如果你不想在Java里折腾ONNX Runtime的tokenizer也可以用另一种务实方案单独写一个Python小服务部署Embedding模型Java通过gRPC或HTTP调用。但这样架构上多了一个服务部署复杂度上升而且Python服务的守护、重启、版本管理都成了新的问题。我后来还是走回了Java直接加载ONNX模型的路线虽然技术栈稍微硬核一点但一劳永逸部署就一套Java服务。5. 核心实现Collection定义、数据写入与语义检索5.1 Milvus集合定义与文档写入链路Milvus里的Collection可以理解成关系型数据库里的表字段定义好了之后写入向量就必须严格按照字段来。我的集合设计是这样的字段名类型说明idInt64自增主键docIdVarChar原始文档的唯一标识contentVarChar当前chunk的纯文本内容categoryVarChar文档分类用于标量过滤embeddingFloatVector(512)语义向量创建Collection代码如下public void createCollection(String collectionName) { FieldType idField FieldType.newBuilder() .withName(id).withDataType(DataType.Int64) .withPrimaryKey(true).withAutoID(true).build(); FieldType docIdField FieldType.newBuilder() .withName(docId).withDataType(DataType.VarChar).withMaxLength(256).build(); FieldType contentField FieldType.newBuilder() .withName(content).withDataType(DataType.VarChar).withMaxLength(65535).build(); FieldType categoryField FieldType.newBuilder() .withName(category).withDataType(DataType.VarChar).withMaxLength(128).build(); FieldType embeddingField FieldType.newBuilder() .withName(embedding).withDataType(DataType.FloatVector).withDimension(512).build(); CreateCollectionParam createParam CreateCollectionParam.newBuilder() .withCollectionName(collectionName) .withDescription(知识库文档向量集合) .addFieldType(idField) .addFieldType(docIdField) .addFieldType(contentField) .addFieldType(categoryField) .addFieldType(embeddingField) .build(); milvusClient.createCollection(createParam); }字段维度这个细节特别容易出错模型的输出维度、创建Collection时指定的维度、以及实际写入向量的长度三者必须完全一致。我在项目里遇到过一把情况是模型输出的实际维度是512但我创建Collection时误写成了768插入的时候报float vector dim check failed排查了快一个小时才意识到是字段定义写错了。建议你在代码里把维度定义成常量不要散落在各处。写入链路我建议用批量插入Milvus对大批量写入的吞吐性能远好于逐条插入。我封装好的批量写入逻辑是把一组文档chunk的向量和元数据都组装好一次性提交public void upsertChunks(ListDocChunk chunks, String docId, String category) { ListListFloat vectors new ArrayList(); ListString contents new ArrayList(); ListString docIds new ArrayList(); ListString categories new ArrayList(); for (DocChunk chunk : chunks) { float[] vector embeddingService.embed(chunk.getText()); vectors.add(toFloatList(vector)); contents.add(chunk.getText()); docIds.add(docId); categories.add(category); } InsertParam insertParam InsertParam.newBuilder() .withCollectionName(COLLECTION_NAME) .withFields(Map.of( docId, docIds, content, contents, category, categories, embedding, vectors )) .build(); RMutationResult response milvusClient.insert(insertParam); if (response.getStatus() ! R.Status.Success.getCode()) { throw new RuntimeException(Milvus insert failed: response.getMessage()); } }这里面有个性能相关的经验批量插入时一次插多少个合适我的建议是500到1000条chunk为一批太少会频繁触发网络往返和Milvus内部的数据落盘太多则容易导致内存峰值和请求超时。我实际测过1000条512维向量单次插入耗时大概200毫秒左右吞吐足够了。5.2 语义检索API与混合检索方案写入完成之后查询才是真正见真章的地方。查询侧处理流程没那么复杂核心就是把用户输入的问题用同一个Embedding模型转成向量然后调用Milvus的search接口搜TopK但有几个容易被忽略的工程细节要做好。我实现了一个searchSimilarDocs方法支持按分类过滤和TopK配置public ListSearchResult searchSimilarDocs(String query, String category, int topK) { float[] queryVector embeddingService.embed(query); SearchParam searchParam SearchParam.newBuilder() .withCollectionName(COLLECTION_NAME) .withVector(queryVector) .withTopK(topK) .withOutputFields(List.of(docId, content, category)) .build(); if (category ! null !category.isEmpty()) { searchParam.getSearchParams().put(category, category); // Milvus支持在搜索时用过滤表达式例如 category 合同 searchParam.setExpr(category \ category \); } RSearchResults response milvusClient.search(searchParam); SearchResults data response.getData(); ListSearchResult results new ArrayList(); for (SearchResults.SearchResult hit : data.getResults()) { SearchResult sr new SearchResult(); sr.setScore(hit.getScore()); sr.setContent((String) hit.getFieldData(content)); sr.setDocId((String) hit.getFieldData(docId)); results.add(sr); } // 按分数排序并返回 results.sort((a, b) - Float.compare(b.getScore(), a.getScore())); return results; }这里有几个要点。第一个是相似度度量的选择BGE模型推荐用CosineMilvus创建Collection和索引时都要设置成MetricType.COSINE这样才能保证检索分数语义正确。第二个是过滤表达式如果业务上允许按分类过滤一定要先过滤再检索不要拿全量向量撞一次再在业务层过滤那样又慢又浪费算力。第三个是搜索结果的排序Milvus返回的结果本身是有序的但我在代码里还是做了一次排序兜底保证逻辑清晰。另外如果你要做的不是单纯的向量检索而是全文语义混合检索那Milvus也支持在同一个Collection上做标量过滤和向量搜索的组合。但如果你想同时做BM25关键词召回和向量召回那需要自己写一部分逻辑把ES的BM25分数和Milvus的向量分数做加权融合。我在项目中做过的方案是ES做关键词召回Milvus做向量召回两条结果按rank fusion算法合并这个效果在长尾query上会明显好于单一检索方式。不过为了控制篇幅混合检索的细节这次不展开讲后面单独开一篇来写。6. 上线之后踩过的坑索引、性能与工程化细节6.1 忘记建索引导致的百万级数据全表扫描这是我在Milvus上踩过最疼的坑。一开始我只创建了Collection并写入数据没有单独建索引结果查询速度一开始还行数据量到几十万之后单条查询耗时直接飙到3秒以上。Milvus如果不对向量字段建索引搜索就会退化成暴力扫描本质上就是全量计算相似度数据量越大越慢。后来我把索引改成HNSW建索引的代码如下public void createIndex(String collectionName) { CreateIndexParam indexParam CreateIndexParam.newBuilder() .withCollectionName(collectionName) .withFieldName(embedding) .withIndexType(IndexType.HNSW) .withMetricType(MetricType.COSINE) .withExtraParam({\M\: 16, \efConstruction\: 200}) .build(); RRpcStatus response milvusClient.createIndex(indexParam); }HNSW索引的两个核心参数是M和efConstruction。M代表每个节点的最大连接数M越大表示图越密集召回率越高但内存和索引构建时间也会增加一般取16或32。efConstruction是构建时的动态列表长度越大索引质量越高但构建越慢200是一个比较平衡的选择。查询时还有一个ef参数我会在SearchParam里单独配置它控制查询时的搜索范围越大召回越高但延迟越高。我的建议是召回优先场景ef设64或128延迟敏感场景设32。关于建索引还有一个坑如果你先写入数据再建索引当数据量很大的时候建索引过程非常耗内存和CPU生产环境最好在Collection创建好之后就立即建索引然后再灌数据。Milvus是支持在写入过程中增量构建索引的但如果先灌数据再触发建索引遇到大数据量会产生明显的IO抖动。6.2 Java工程化里的数据一致性、并发与超时问题在实际接入过程中数据处理链路长不像单表CRUD那么简单有几点工程化细节值得单独记一笔。首先是写入一致性的保障。我的场景是从消息队列里消费到文档后先解析、切分、向量化再写入Milvus。如果向量化或写入过程中服务重启了那这条文档数据就丢了。为了避免这个问题我加了一个文档状态表用MySQL记录每个文档的切分数量、向量化状态和写入状态。流程是接收文档 - 创建状态记录PENDING - 切分向量化 - 写Milvus - 更新状态为SUCCESS。下一次启动时扫描状态为PENDING的文档重新处理一遍这样既保证了最终一致性又不会重复写入大量数据。其次是并发问题。Java这边用了线程池并发处理文档切分和向量化但在调用ONNX模型做推理时OrtSession不是线程安全的并发推理需要做同步或者用线程局部变量。我的土办法是每线程一个Session实例这样既避免了锁竞争又充分利用了多核CPU。MilvusClient倒是线程安全的可以直接并发调用但要注意控制并发度我压测下来8到16个并发写入或查询线程都比较稳定再高容易触发Milvus端的连接池瓶颈。最后是超时和重试。Milvus的网络交互是gRPC超时时间默认比较长但业务接口不能让用户等太久。我给检索接口设置了一个超时器超过2秒就暂时返回服务繁忙或走降级策略避免把连接池拖死。同时每次写入操作都加了失败重试逻辑重试三次间隔指数退避。这里我踩过的一个小坑是Milvus的insert操作不是幂等的如果客户端写超时后重试服务端可能已经写入成功导致同一条chunk插了两遍。解决方法是插入前生成一个业务侧唯一ID写入时用这个ID作为主键靠autoID就不行要自己指定ID这样重复插入就能被主键冲突挡住。6.3 检索效果调优从糟糕结果到可用状态项目上线之后我调了一段时间的检索效果。要知道向量检索不是接完就完事的效果好坏受切分粒度、向量模型、查询侧文本处理、TopK参数等多重因素影响。这里把几个性价比最高的优化手段按优先级列一下优化项具体操作效果提升切分窗口从500字降到200到300字中检索粒度更精准添加指令前缀BGE模型查询和文档侧都加前缀极大命中率翻倍元数据过滤检索时优先按category过滤高缩小搜索范围结果重排序Top10召回后按原文轻量rerank高最后一条内容质量决定用户体验去掉停用词查询文本清理的、了、呢小但稳定重排序这步我很推荐做。最简单的方式是Milvus先招回Top20然后把这20条chunk的文本和用户问题再做一次余弦相似度重算取更精确的Top5返回给上游做答案生成。因为Milvus的ANN搜索本身是近似的Top20的精度可能不如Top5但重排序能把这部分误差纠回来。我实际体验下来重排序后的结果比直接Top5的满意度要高不少而且实现成本很低几十行代码的事。有个建议是把重排序逻辑和Milvus搜索解耦独立成一个RerankService方便后续升级成CrossEncoder模型而不是每次都做余弦重算。如果你有精力做CrossEncoder的重排序会更专业模型效果相比普通余弦相似度有明显代差。6.4 快速排错速查表最后把这段时间遇到的典型问题整理成一个速查表方便大家少走弯路现象大概率原因解决方式milvus connect failDocker依赖容器etcd/minio没起用docker compose up -d全部拉起确认健康状态创建Collection报维度错误模型输出维度与Collection定义不一致打印模型输出shape与字段dimension对齐查询结果为空没有写入数据或expr过滤条件太严格先去掉过滤条件测试再用collection stats验证数据量查询速度突然变慢向量字段没建索引创建HNSW或IVF索引等待索引就绪插入时返回主键冲突自增ID被关闭且业务侧指定了重复ID检查ID生成逻辑或改用autoIDJava进程内存溢出批量插入数据量过大每次插入控制在1000条以内及时释放list结果语义相关性差没加BGE指令前缀或切分窗口过大按上文添加前缀缩短切分窗口还有一个小细节Milvus的collection如果删除重建之前的数据就彻底没了所以生产环境一定不要在生产connection上随便执行dropCollection。我在开发环境就手滑过一次结果整个知识库的向量数据全部清空重新跑了一遍全量入库流程白白浪费了一个下午。结尾分享这套Java接向量数据库的方案已经在我的知识库项目里稳定跑了两个多月文档入库量累计超过20万条chunk单次查询平均耗时120毫秒左右数据安全性也因为全本地化模型而得到了保障。我个人实操中的体会是向量数据库本身不难接难的是把文档怎么切、向量怎么生成、检索怎么调优这套链路想明白。如果你也在做类似项目建议先拿一个小数据集从切分和模型的前缀效果开始做起把每一步的结果都打印出来看一眼不要等到全链路完成再一起调试那是灾难。最后再分享一个小技巧每次修改切分策略或模型后别急着全量更新索引先选一个真实用户查询用新方案跑一遍对比一下返回的Top5结果效率最高。
