1. 项目缘起当16G内存遇上Milvus的“胃口”最近在折腾一个私域文档的智能搜索与问答系统核心架构是经典的RAG检索增强生成。向量数据库这块我毫不犹豫地选了Milvus毕竟它在业界的口碑和性能有目共睹。本地开发环境是一台配置还不错的笔记本16G内存想着跑个Standalone模式的Milvus处理几千条文档的向量应该绰绰有余吧现实很快给了我一个下马威。项目刚跑起来索引还没建完风扇就开始狂转。打开任务管理器一看好家伙一个milvus-standalone的Docker容器内存占用轻轻松松就飙到了8个G以上再加上Spring Boot应用、Ollama跑的大模型16G内存瞬间告急整个系统卡得不行频繁触发OOM内存溢出。这让我不得不停下来思考对于一个轻量级的、面向个人或小团队的私有化知识库应用动用Milvus这样的“重型武器”是不是有点“杀鸡用牛刀”了它的资源消耗尤其是内存对于资源受限的环境来说成了一个实实在在的门槛。我的需求其实很明确能对本地文档Markdown、PDF、Word等进行切分、向量化然后存储起来支持基于语义的相似度检索最后结合本地部署的大模型比如通过Ollama跑的Llama 3、Qwen等进行智能问答。整套系统需要能在一台普通的开发机或小型服务器上顺畅运行。Milvus的强大毋庸置疑但它为大规模、高并发场景设计的架构带来了相对较高的基础资源开销。Standalone模式虽然简化了部署但其内存占用对于我这种场景来说依然显得过于“沉重”。于是我开始寻找更轻量级的替代方案。目标很清晰一个内存占用小、部署简单、能和Spring Boot生态特别是Spring AI轻松集成并且具备基本向量检索能力的组件。在这个过程中我注意到了几个关键词Lucene、Spring AI Alibaba以及一个名为opencode的新兴工具。Lucene作为老牌全文检索库其新版本是否支持向量检索Spring AI Alibaba作为对Spring AI的阿里云扩展会不会有更接地气的向量存储方案而opencode这个号称能“重写”代码的AI编程助手能否帮我快速验证和实现新的技术选型这便构成了本次探索的起点。2. 技术选型权衡从Milvus到更轻量的方案当Milvus因资源问题成为瓶颈时重新评估技术栈是必然的。我的核心需求是向量存储与检索而非Milvus提供的分布式、高可用、高性能等企业级特性。因此选型的焦点落在了轻量、易集成、够用这三个原则上。2.1 为什么是Lucene首先考虑的是Apache Lucene以及构建在其之上的搜索引擎如Elasticsearch或Solr。Lucene 9.x版本之后官方引入了KnnVectorField开始原生支持向量搜索。这是一个非常重要的信号。优势极致轻量如果直接使用Lucene库你可以将其嵌入到你的Java应用中。它只是一个JAR包内存管理完全由你的JVM控制没有独立的进程开销。索引文件就在本地磁盘检索时按需加载内存占用非常可控。无缝集成对于Spring BootJava技术栈来说引入Lucene就像引入一个普通依赖一样简单。不需要部署额外的服务没有网络开销调试也方便。成熟稳定Lucene是全文检索领域的基石经历了无数项目的考验其索引机制、文件格式都非常可靠。功能复合除了向量检索Lucene强大的文本分析分词、同义词等能力可以同时用于文档的全文检索实现“向量关键词”的混合搜索提升召回质量。挑战与考量需要手动管理你需要自己处理索引的创建、更新、删除和查询逻辑。这比直接调用Milvus的API要更底层但也意味着更高的灵活性和控制力。性能调优向量检索的性能特别是近似最近邻搜索ANN依赖于选择的算法如HNSW。Lucene提供了HNSW的实现但相关参数如M,ef_construction,ef_search需要根据数据规模和精度要求进行调整这有一定的学习成本。生态工具相比Milvus有Attu这样的可视化工具直接使用Lucene缺乏开箱即用的管理界面索引状态需要通过代码或命令行工具查看。尽管有挑战但对于我的场景——数据量在十万级以下、单机部署、追求极致轻量——直接使用Lucene的向量能力是一个非常有吸引力的方向。它完美避开了Milvus独立服务的内存开销问题。2.2 Spring AI Alibaba 与 Spring AI 的角色Spring AI项目旨在为AI应用开发提供统一的抽象层比如它定义了VectorStore接口让开发者可以灵活切换底层的向量数据库Milvus、Redis、PGVector等。而Spring AI Alibaba是阿里云提供的扩展主要集成了阿里云的通义千问等大模型以及一些云服务。在我的新架构里它们的角色是Spring AI提供Document、VectorStore等核心抽象。我的目标是实现一个基于Lucene的VectorStore实现类。这样我的业务代码如文档入库、检索只需要面向Spring AI的接口编程与底层存储解耦。Spring AI Alibaba在这个项目中我主要关注其是否提供了更轻量或更易用的向量存储方案。经过查阅目前它主要还是对接阿里云的服务。对于纯本地、私有化部署直接使用Lucene并实现Spring AI的VectorStore接口是更直接和可控的方案。2.3 Ollama的坚守与优化大模型部分我依然选择Ollama。它实在太方便了一条命令就能在本地拉起一个模型服务。之前遇到的“Ollama下载太慢”的问题可以通过配置国内镜像源完美解决。例如在启动Ollama前设置环境变量export OLLAMA_HOST0.0.0.0 # 如果需要远程访问 # 对于下载可以修改 ~/.ollama/models/manifests/registry.ollama.ai/config.json 或使用第三方镜像站或者更简单的方法是先通过其他方式如学术资源下载好模型文件.bin或.gguf格式然后使用ollama create命令从本地文件创建模型。这彻底解决了网络依赖问题。Ollama作为本地模型推理引擎资源占用相对固定且可预测取决于模型大小是我技术栈中确定的一环。2.4 opencode本次重构的“加速器”最后谈谈标题中的主角之一opencode。它不是一个运行时组件而是一个AI编程助手工具。你可以把它想象成一个深度集成在IDE如VSCode里能理解你整个项目上下文并能根据自然语言指令直接生成或修改代码的“超级Copilot”。在本次“重写”过程中opencode扮演了关键角色快速原型验证当我想验证“用Lucene实现VectorStore是否可行”时我不需要从头去翻Lucene那复杂的API文档。我可以直接对opencode说“基于Spring AI的VectorStore接口用Lucene 9.x的KnnVectorField实现一个简单的向量存储类包含add和similaritySearch方法。”它能快速生成一个可运行的代码骨架极大降低了探索新技术的初始成本。代码重构与填充在确定了Lucene方案后大量的样板代码如索引配置、文档字段定义、向量转换逻辑可以通过opencode快速生成。我只需要描述清楚业务逻辑“将Spring AI的Document对象中的embedding向量存入Lucene的KnnVectorField并把文本内容存入TextField”它就能生成对应代码我在此基础上进行调试和优化即可。解决具体问题遇到诸如“Lucene HNSW参数如何设置”、“如何合并向量搜索和关键词过滤”这类具体问题时直接询问opencode它能给出针对性的代码示例或解释比泛泛地搜索网络效率高很多。注意opencode这类工具并非万能。它生成的代码需要你具备足够的专业知识去审查、测试和调整。它最适合的场景是你已经明确了技术方案和设计思路用它来加速实现过程避免重复的体力劳动。你不能指望它替你做出技术决策。综上我的新方案技术栈确定为Spring Boot Spring AI (VectorStore抽象) 自实现的Lucene VectorStore Ollama (本地大模型)。opencode作为辅助开发工具贯穿全程。这个组合彻底移除了Milvus这个“内存大户”将所有资源消耗都纳入单个JVM进程的管理范围非常适合16G甚至更低内存的环境。3. 核心实现构建基于Lucene的轻量级VectorStore确定了技术路线接下来就是动手实现。核心目标是创建一个实现Spring AI中VectorStore接口的类底层使用Apache Lucene。3.1 环境与依赖准备首先在pom.xml中引入关键依赖dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-core/artifactId version0.8.1/version !-- 请使用最新稳定版 -- /dependency !-- Lucene 核心与向量搜索模块 -- dependency groupIdorg.apache.lucene/groupId artifactIdlucene-core/artifactId version9.10.0/version /dependency dependency groupIdorg.apache.lucene/groupId artifactIdlucene-queryparser/artifactId version9.10.0/version /dependency dependency groupIdorg.apache.lucene/groupId artifactIdlucene-analyzers-common/artifactId version9.10.0/version /dependency !-- 高维向量支持HNSW算法在此模块 -- dependency groupIdorg.apache.lucene/groupId artifactIdlucene-backward-codecs/artifactId version9.10.0/version /dependency注意lucene-backward-codecs包含了用于向量搜索的KnnVectorField和Lucene99HnswVectorsFormat等必要的编解码器。3.2 设计LuceneVectorStoreSpring AI的VectorStore接口主要定义了add、similaritySearch、delete等方法。我们的实现类LuceneVectorStore需要关注以下几个核心部分索引目录与配置决定索引存储在文件系统的哪个路径并配置索引写入器IndexWriter和搜索管理器SearcherManager。文档模型映射如何将Spring AI的Document对象包含id、内容、元数据和嵌入向量映射到Lucene的org.apache.lucene.document.Document。向量搜索如何使用KnnVectorField进行近似最近邻搜索。以下是核心代码结构的详解3.2.1 初始化与配置Component public class LuceneVectorStore implements VectorStore { private final Path indexPath; private final IndexWriter indexWriter; private final SearcherManager searcherManager; private final int embeddingDimension; // 向量维度例如384或768 public LuceneVectorStore(Value(${lucene.vectorstore.path:./lucene-index}) String indexDirPath, Value(${lucene.vectorstore.dimension:384}) int dimension) throws IOException { this.embeddingDimension dimension; this.indexPath Paths.get(indexDirPath); Files.createDirectories(this.indexPath); // 1. 配置索引 IndexWriterConfig iwc new IndexWriterConfig(new StandardAnalyzer()); // 使用支持向量的最新格式 iwc.setCodec(new Lucene99Codec()); // 其他优化配置比如设置使用复合文件格式减少文件数量 iwc.setUseCompoundFile(true); // 2. 创建IndexWriter FSDirectory directory FSDirectory.open(this.indexPath); this.indexWriter new IndexWriter(directory, iwc); // 3. 创建SearcherManager用于多线程安全搜索 this.searcherManager new SearcherManager(this.indexWriter, true, true, null); } }这里的关键是Lucene99Codec它确保了索引能够处理KnnVectorField这种特殊的字段类型。embeddingDimension必须与你使用的嵌入模型如text-embedding-3-small是1536维输出的维度严格一致否则在写入和搜索时会报错。3.2.2 实现add方法存储文档与向量Override public void add(ListDocument documents) { Listorg.apache.lucene.document.Document luceneDocs documents.stream().map(this::toLuceneDocument).collect(Collectors.toList()); try { // 删除已存在的相同ID的文档实现更新语义 Term idTerm new Term(id, documents.get(0).getId()); // 简单示例实际需遍历 indexWriter.updateDocuments(idTerm, luceneDocs); indexWriter.commit(); // 提交更改 searcherManager.maybeRefreshBlocking(); // 刷新搜索器使新文档可被搜索 } catch (IOException e) { throw new RuntimeException(Failed to add documents to Lucene index, e); } } private org.apache.lucene.document.Document toLuceneDocument(Document aiDocument) { org.apache.lucene.document.Document doc new org.apache.lucene.document.Document(); // 1. 存储唯一ID doc.add(new StringField(id, aiDocument.getId(), Field.Store.YES)); // 2. 存储文本内容用于可能的关键词检索或展示 doc.add(new TextField(content, aiDocument.getContent(), Field.Store.YES)); // 3. 存储向量 ListDouble embedding aiDocument.getEmbedding(); if (embedding ! null embedding.size() embeddingDimension) { float[] vector new float[embeddingDimension]; for (int i 0; i embeddingDimension; i) { vector[i] embedding.get(i).floatValue(); } // 创建KnnVectorField。参数字段名向量数组向量类型默认FLOAT32 KnnVectorField vectorField new KnnVectorField(embedding, vector, VectorSimilarityFunction.COSINE); doc.add(vectorField); } else { throw new IllegalArgumentException(Embedding dimension mismatch or null.); } // 4. 存储元数据例如可将元数据序列化为JSON存入StoredField MapString, Object metadata aiDocument.getMetadata(); if (metadata ! null !metadata.isEmpty()) { try { String metaJson new ObjectMapper().writeValueAsString(metadata); doc.add(new StoredField(metadata, metaJson)); } catch (JsonProcessingException e) { // 处理异常 } } return doc; }这里有几个实操要点向量维度校验必须校验传入的向量维度与初始化时设定的embeddingDimension是否一致。这是最常见的错误来源之一。向量相似度函数VectorSimilarityFunction.COSINE指定使用余弦相似度。Lucene还支持EUCLIDEAN欧氏距离和DOT_PRODUCT点积。这需要与你生成嵌入向量时使用的相似度计算方式对齐通常都是余弦相似度。字段存储策略StringField和TextField的Field.Store.YES表示将原始值存储在索引中以便搜索后能直接获取。KnnVectorField本身不存储原始向量值出于效率考虑但索引了向量用于搜索。更新逻辑示例中使用了updateDocuments它先删除所有包含指定Term的文档再添加新文档。这要求你的Document对象有一个稳定的ID。如果只是单纯追加可以用addDocuments。3.2.3 实现similaritySearch方法执行向量检索这是最核心的部分我们使用Lucene的KnnVectorQuery进行近似最近邻搜索。Override public ListDocument similaritySearch(SearchRequest request) { try { // 1. 获取搜索器 IndexSearcher searcher searcherManager.acquire(); try { // 2. 构建查询向量 ListDouble queryEmbedding request.getQueryEmbedding(); if (queryEmbedding null || queryEmbedding.size() ! embeddingDimension) { throw new IllegalArgumentException(Invalid query embedding.); } float[] queryVector new float[embeddingDimension]; for (int i 0; i embeddingDimension; i) { queryVector[i] queryEmbedding.get(i).floatValue(); } // 3. 创建KnnVectorQuery // 参数字段名查询向量返回结果数k过滤查询这里为null表示不过滤 Query vectorQuery new KnnVectorQuery(embedding, queryVector, request.getTopK()); // 4. 可选结合关键词过滤Metadata过滤 Query finalQuery vectorQuery; if (request.getFilterExpression() ! null !request.getFilterExpression().isEmpty()) { // 这里需要解析FilterExpression并构建对应的Lucene Query如TermQuery // 例如过滤 metadata.source manual Query filterQuery new TermQuery(new Term(metadata.source, manual)); finalQuery new BooleanQuery.Builder() .add(vectorQuery, BooleanClause.Occur.MUST) .add(filterQuery, BooleanClause.Occur.FILTER) // FILTER子句不参与评分 .build(); } // 5. 执行搜索 TopDocs topDocs searcher.search(finalQuery, request.getTopK()); // 6. 转换结果 ListDocument results new ArrayList(); for (ScoreDoc scoreDoc : topDocs.scoreDocs) { org.apache.lucene.document.Document hitDoc searcher.doc(scoreDoc.doc); Document aiDoc toAiDocument(hitDoc); // 可以设置相似度分数Lucene的score可能与余弦相似度有转换关系 // aiDoc.setScore(scoreDoc.score); results.add(aiDoc); } return results; } finally { searcherManager.release(searcher); } } catch (IOException e) { throw new RuntimeException(Similarity search failed, e); } } private Document toAiDocument(org.apache.lucene.document.Document luceneDoc) { Document aiDoc new Document(luceneDoc.get(content)); aiDoc.setId(luceneDoc.get(id)); // 从StoredField中还原元数据 String metaJson luceneDoc.get(metadata); if (metaJson ! null) { try { MapString, Object metadata new ObjectMapper().readValue(metaJson, new TypeReferenceMapString, Object() {}); aiDoc.setMetadata(metadata); } catch (JsonProcessingException e) { // 处理异常 } } // 注意这里无法还原embedding向量因为KnnVectorField不存储原始值。 // 如果后续需要重排re-ranking需要重新计算或从其他途径获取。 return aiDoc; }关键点解析KnnVectorQuery这是执行ANN搜索的核心。它使用底层HNSW图进行高效检索。request.getTopK()决定了返回的最相似文档数量。过滤Filtering在实际应用中我们经常需要在向量搜索的基础上进行属性过滤如“只搜索某类文档”。Lucene的BooleanQuery可以很好地组合KnnVectorQuery和传统的TermQuery、RangeQuery等。使用BooleanClause.Occur.FILTER可以让过滤条件不影响相关性评分只做筛选效率更高。分数ScoreKnnVectorQuery返回的scoreDoc.score并不是直接的余弦相似度。它是一个基于向量距离的内部评分。如果你需要向用户展示相似度百分比可能需要进行额外的转换或者直接使用向量距离。一个常见的做法是如果业务上不需要精确的相似度数值可以忽略这个分数或者用它做相对排序。向量还原如注释所述KnnVectorField为了效率不存储原始向量。这意味着通过similaritySearch返回的Document对象其embedding字段是空的。如果你的下游流程如某些重排算法需要用到原始向量你需要考虑其他方案比如将向量同时存储在一个StoredField中但这会显著增加索引大小或者维护一个外部的ID到向量的映射。3.3 HNSW参数调优与性能考量Lucene底层使用HNSWHierarchical Navigable Small World算法来加速向量搜索。在创建KnnVectorField时我们可以通过FieldType设置一些关键参数这些参数直接影响索引构建速度、索引大小和搜索精度/速度FieldType vectorFieldType new FieldType(KnnVectorField.TYPE); vectorFieldType.setVectorDimensions(embeddingDimension); vectorFieldType.setVectorSimilarityFunction(VectorSimilarityFunction.COSINE); // 设置HNSW参数 vectorFieldType.setHnswM(16); // 每个节点在图中连接的边数默认16。越大图越稠密精度越高但索引越大、构建越慢。 vectorFieldType.setHnswEfConstruction(100); // 构建时动态候选列表大小默认100。越大构建质量越高、越慢。 // 创建字段 KnnVectorField vectorField new KnnVectorField(embedding, vector, vectorFieldType);hnswM控制HNSW图中每个顶点即每个向量的最大连接数。增加M会提高搜索精度和召回率但也会增加索引大小和构建时间。对于千万级以下的数据16或32通常是足够的起点。hnswEfConstruction在构建索引时用于选择邻居的候选集大小。增加此值可以构建出质量更高的图从而提升搜索精度但同样会减慢索引速度。对于搜索阶段KnnVectorQuery内部也有一个efSearch参数目前Lucene API似乎未直接暴露可能使用内部默认值或通过IndexSearcher设置。它控制搜索时遍历的候选节点数量影响搜索速度和精度。一般来说efSearch值越大搜索越精确但也越慢。实操心得对于中小规模数据集比如10万条以内使用Lucene的默认HNSW参数通常就能获得不错的效果。如果你的数据量很大或者对搜索精度有极致要求才需要仔细调优这些参数。一个实用的方法是先用默认参数构建索引并测试如果召回率不达标再逐步调高M和efConstruction。记住调优是一个在精度、速度、内存/磁盘开销之间权衡的过程。4. 集成Spring AI与Ollama搭建完整RAG流水线实现了轻量级的向量存储后下一步就是将其接入Spring AI的抽象层并与Ollama大模型串联形成完整的RAG问答链路。4.1 配置Spring AI的EmbeddingClient与ChatClient首先我们需要一个Embedding模型将文本转换为向量。这里可以选择云服务如OpenAI、通义千问或本地模型。为了完全私有化我选择在本地用Ollama运行一个嵌入模型。假设我们运行了nomic-embed-text模型一个不错的开源嵌入模型。在application.yml中配置spring: ai: ollama: base-url: http://localhost:11434 # Ollama服务地址 embedding: model: nomic-embed-text # 用于向量化的模型 chat: model: llama3.2:1b # 用于对话的模型可按需选择然后在Spring Boot中注入对应的ClientRestController public class RagController { private final EmbeddingClient embeddingClient; private final VectorStore vectorStore; // 这里就是我们实现的LuceneVectorStore private final ChatClient chatClient; public RagController(EmbeddingClient embeddingClient, VectorStore vectorStore, ChatClient chatClient) { this.embeddingClient embeddingClient; this.vectorStore vectorStore; this.chatClient chatClient; } // ... 后续方法 }Spring AI会自动根据配置创建Ollama的EmbeddingClient和ChatClient。4.2 实现文档入库流程入库流程包括文档加载、文本分割、向量化、存储。public void ingestDocument(String filePath) { // 1. 加载文档 (这里以文本文件为例实际可使用Tika、Apache POI等处理PDF/DOCX) String content Files.readString(Path.of(filePath)); // 2. 文本分割 (使用Spring AI提供的简单分割器) TextSplitter splitter new TokenTextSplitter(); // 或RecursiveCharacterTextSplitter ListString segments splitter.split(content, 500); // 按500 tokens分割 // 3. 批量向量化 (减少网络/进程间调用) ListEmbedding embeddings embeddingClient.embed(segments); // 4. 构建Document对象并存储 ListDocument documents new ArrayList(); for (int i 0; i segments.size(); i) { Document doc new Document(segments.get(i)); doc.setEmbedding(embeddings.get(i).getEmbedding()); // 设置向量 doc.getMetadata().put(source, filePath); doc.getMetadata().put(chunk_index, i); documents.add(doc); } vectorStore.add(documents); }注意事项文本分割是RAG效果的关键。分割过细会丢失上下文过粗则可能包含无关信息干扰检索。TokenTextSplitter基于token数量分割更贴合大模型上下文但需要知道模型的tokenizer。RecursiveCharacterTextSplitter按字符递归分割更通用。需要根据你的文档类型和内容特点进行调整比如可以尝试按段落、标题进行分割。4.3 实现问答检索与生成流程这是RAG的核心用问题检索相关文档片段并将其作为上下文喂给大模型生成答案。public String ask(String question) { // 1. 将问题向量化 Embedding questionEmbedding embeddingClient.embed(question); // 2. 向量检索 SearchRequest request SearchRequest.query(questionEmbedding.getEmbedding()) .withTopK(5) // 检索最相关的5个片段 .withSimilarityThreshold(0.7); // 可选相似度阈值 // 注意LuceneVectorStore需要处理withSimilarityThreshold可能需要自定义查询或后过滤 ListDocument relevantDocs vectorStore.similaritySearch(request); // 3. 构建提示词Prompt StringBuilder contextBuilder new StringBuilder(); for (Document doc : relevantDocs) { contextBuilder.append(doc.getContent()).append(\n---\n); } String promptTemplate 请基于以下上下文信息回答问题。如果上下文信息不足以回答问题请直接说“根据提供的信息无法回答”。 上下文 %s 问题%s 答案 ; String finalPrompt String.format(promptTemplate, contextBuilder.toString(), question); // 4. 调用大模型生成答案 ChatResponse response chatClient.call(new Prompt(finalPrompt)); return response.getResult().getOutput().getContent(); }关键点与优化相似度阈值withSimilarityThreshold是Spring AISearchRequest的一个参数但我们的LuceneVectorStore实现需要处理它。由于Lucene的KnnVectorQuery返回的是内部评分而非直接相似度实现阈值过滤有两种方式后过滤先检索出更多结果比如TopK20然后在内存中计算每个结果与查询向量的余弦相似度需要存储原始向量或重新计算再过滤掉低于阈值的。这会增加计算开销。近似过滤如果对阈值要求不严格可以忽略此参数或者尝试将阈值映射到Lucene的score上需要实验确定映射关系。对于轻量级应用可以先不做严格阈值过滤依靠TopK来控制返回数量。提示词工程提示词模板对答案质量影响巨大。示例中是一个基础模板。更好的实践包括指令明确“基于上下文”、防止幻觉“无法回答则说明”、指定输出格式等。可以尝试不同的模板观察效果。上下文长度管理检索到的多个文档片段拼接后可能超过大模型的上下文窗口。需要在拼接前计算总token数并进行截断或智能选择。重排序Re-ranking简单的向量相似度检索可能不是最优的。可以引入一个轻量级的重排序模型如BGE-Reranker对TopK例如20个的初步结果进行重新打分再选取前几个作为最终上下文。这能显著提升答案相关性但会增加延迟。对于资源敏感的环境需要权衡。4.4 资源管理与优化索引持久化与加载LuceneVectorStore的索引文件保存在本地磁盘。应用重启后只需要重新打开FSDirectory和IndexWriter即可无需重新向量化和入库。内存控制Lucene搜索时会将部分索引数据加载到内存以提高速度。你可以通过IndexWriterConfig和IndexSearcher的设置来控制内存使用例如调整RAMBufferSizeMB。对于16G内存的机器将JVM堆内存设置为8G-Xmx8g留给Lucene和Ollama足够的内存空间通常运行流畅。异步处理文档入库特别是向量化是耗时操作。应该将其设计为异步任务避免阻塞主请求。可以使用Spring的Async或消息队列。错误处理与监控添加完善的日志记录索引大小、搜索耗时、Ollama调用状态等。这对于排查问题和性能调优至关重要。通过以上步骤我们成功用Lucene替换了Milvus构建了一个完全在本地、内存占用可控的私域文档智能问答系统。整个应用以一个Spring Boot进程为核心整合了文本处理、向量检索和本地大模型推理非常适合个人开发者、小团队或对数据隐私要求高的场景进行部署和二次开发。在下一篇文章中我们将深入探讨系统优化、高级检索技巧如混合搜索、多路召回以及如何利用opencode等工具进一步提升开发效率。