1. 项目概述当Spring遇上向量数据库去年在重构企业知识管理系统时我第一次尝试将Spring Boot与Milvus向量数据库集成。原本需要3天才能完成的专利检索任务接入RAG架构后缩短到了20分钟。这种效率提升让我意识到传统关键词搜索已无法满足AI时代的检索需求。本文要探讨的正是如何用Spring生态构建支持语义搜索的AI应用。核心在于两个技术点向量数据库如Milvus/Qdrant/PGVector负责存储和检索嵌入向量RAG检索增强生成框架实现基于上下文的智能问答这种架构特别适合需要处理非结构化数据的场景比如企业级知识库的智能问答系统法律/医疗领域的专业文档检索电商产品的多模态搜索图文/视频关键提示选择向量数据库时Milvus适合超大规模向量1亿条Qdrant以易用性著称PGVector则能与现有PostgreSQL无缝集成。2. 核心架构设计解析2.1 技术栈选型考量在电商智能客服项目中我们最终选型如下// Spring AI核心依赖 implementation org.springframework.ai:spring-ai-openai-spring-boot-starter:0.8.0 implementation org.springframework.ai:spring-ai-pgvector-store:0.8.0 // 向量数据库配置 Bean public VectorStore vectorStore(DataSource dataSource) { return new PgVectorStore(dataSource); }选择PGVector的三大理由已有PostgreSQL基础设施无需额外维护支持混合查询向量结构化数据ACID事务保证数据一致性2.2 RAG工作流设计典型处理流程包含五个阶段文档预处理PDF/PPT解析用Apache Tika文本分块策略滑动窗口512token中文分词采用HanLP向量化编码# 使用OpenAI的text-embedding-3-small模型 embedding OpenAIEmbeddings(modeltext-embedding-3-small, dimensions768)向量存储索引类型选择IVF_FLAT适合中等规模数据集相似度度量用余弦相似度检索增强Retryable(maxAttempts3) public ListDocument semanticSearch(String query) { return vectorStore.similaritySearch(query); }生成应答采用LLM的system prompt约束输出格式注入检索到的文档作为上下文3. Spring AI集成实战3.1 环境配置要点在Spring Boot 3.2项目中配置PGVector# application.yml spring: datasource: url: jdbc:postgresql://localhost:5432/vectordb username: pgvector password: 123456 ai: vectorstore: pgvector: dimensions: 768 distance-type: cosine常见踩坑点PostgreSQL需安装vector扩展CREATE EXTENSION vector;表结构初始化脚本要包含vector类型字段JDBC驱动建议用42.6.0版本3.2 核心业务实现文档入库服务示例Service RequiredArgsConstructor public class DocumentService { private final VectorStore vectorStore; private final EmbeddingClient embeddingClient; Async public void ingestDocument(Path filePath) { // 文本提取与分块 ListTextSegment segments parseDocument(filePath); // 批量生成嵌入向量每批100条 IterableListTextSegment batches Iterables.partition(segments, 100); batches.forEach(batch - { ListEmbedding embeddings embeddingClient.embed(batch); vectorStore.add(embeddings, batch); }); } }性能优化启用Async异步处理时务必配置线程池Configuration EnableAsync public class AsyncConfig implements AsyncConfigurer { Override public Executor getAsyncExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(4); executor.setMaxPoolSize(8); executor.setQueueCapacity(500); executor.initialize(); return executor; } }4. 生产环境调优指南4.1 性能优化策略在日均千万级查询的系统中我们通过以下手段提升吞吐量优化方向具体措施效果提升索引优化改用HNSW索引QPS↑300%缓存策略对热点查询做Redis缓存延迟↓70%批量处理嵌入生成改用批量API成本↓60%硬件加速使用GPU加速Faiss响应时间↓90%4.2 典型问题排查问题1相似度分数异常低检查嵌入模型是否中英文混用验证文本分块是否包含完整语义确认distance-type配置cosine/euclidean问题2内存泄漏排查未关闭的PGConnection监控EmbeddingClient的请求批处理限制最大返回文档数建议≤20问题3响应不稳定为OpenAI客户端配置重试机制Bean public RetryTemplate retryTemplate() { return new RetryTemplateBuilder() .maxAttempts(3) .exponentialBackoff(1000, 2, 5000) .build(); }5. 进阶应用场景5.1 多模态搜索实现在商品检索系统中我们同时处理文本和图片// 图像特征提取 Bean public EmbeddingClient imageEmbeddingClient() { return new OpenAiImageEmbeddingClient(clip-vit-base-patch32); } // 跨模态搜索 public ListProduct searchByImage(MultipartFile image) { Embedding imageEmbedding imageEmbeddingClient.embed(image); return productRepository.findSimilarProducts(imageEmbedding); }5.2 Agentic RAG模式对于需要多步推理的场景采用Agent架构问题分解将复杂问题拆解为子问题定向检索针对每个子问题检索相关文档综合推理LLM整合所有上下文生成最终回答Agent public String handleComplexQuery(String question) { // 1. 问题分解 ListString subQuestions llmClient.decomposeQuestion(question); // 2. 并行检索 ListDocument contexts subQuestions.parallelStream() .flatMap(q - vectorStore.similaritySearch(q).stream()) .distinct() .toList(); // 3. 生成回答 return llmClient.generate(question, contexts); }6. 踩坑经验实录文本分块的艺术法律合同适合按条款分块保持条款完整技术文档适合按章节分块保留上下文对话记录适合按会话分块维持对话连贯混合搜索实践-- PGVector的混合查询示例 SELECT * FROM products WHERE category electronics ORDER BY embedding [0.1, 0.3, ...] LIMIT 10;成本控制技巧对小文本用text-embedding-3-small1/10成本实现嵌入结果缓存Redis TTL 24h对重复查询做去重处理经过三个季度的迭代我们的Spring AI系统成功将客户服务响应速度提升了8倍。最让我意外的是原本为内部知识管理设计的系统最终演化成了支持20业务线的智能中台。这或许就是技术演进的魅力——你永远不知道组合创新会带来怎样的化学反应。
