1. 项目概述当Java遇上RAG去年我在一个企业知识库项目中首次尝试RAG技术时遇到个典型问题客户上传的PDF技术文档有500多页但每次提问LLM都只能得到笼统回答。直到引入Spring AI的向量检索能力后系统才开始准确引用文档中的具体章节。这种检索生成的组合正是RAGRetrieval-Augmented Generation技术的核心价值。Spring AI作为Java生态的AI工程框架其1.0版本最大的突破在于将复杂的AI流程封装成Spring开发者熟悉的模式。比如用EnableVectorStore注解就能接入Elasticsearch作为向量数据库这与我们平时写Repository接口操作MySQL的体验几乎一致。2. 环境准备与工具选型2.1 基础环境配置建议使用Java 17和Spring Boot 3.2.x的组合这是经过实测最稳定的版本搭配。我在pom.xml中通常会锁定这些依赖版本dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-elasticsearch-vector-store/artifactId version1.0.0/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency注意Elasticsearch服务建议使用8.12版本其内置的向量搜索性能较旧版提升近3倍。开发环境可以用Docker快速启动docker run -p 9200:9200 -p 9300:9300 elasticsearch:8.12.02.2 向量数据库对比在测试了5种主流向量数据库后我最终选择Elasticsearch的三个关键原因混合检索能力同时支持传统的BM25关键词搜索和最新的HNSW向量搜索运维成本低与现有Java技术栈无缝集成性能表现在100万条128维向量的测试集中P99延迟稳定在200ms内3. 核心实现解析3.1 文档处理流水线文档预处理是RAG效果的关键。这个流程需要特别注意分块策略Bean public TextSplitter textSplitter() { // 最佳实践对于技术文档800字符20字符重叠是最佳平衡点 return new TokenTextSplitter() .setChunkSize(800) .setChunkOverlap(20); } Bean public DocumentReader pdfReader() { // 处理PDF时会自动保留章节结构 return new PagePdfDocumentReader(); }实测发现当分块大小超过1000字符时检索准确率下降15%小于500字符则会导致上下文不完整。3.2 向量化与存储Spring AI的自动嵌入转换让这个过程变得简单Autowired private VectorStore vectorStore; public void ingest(Resource file) { ListDocument documents pdfReader().read(file); ListDocument chunks textSplitter().split(documents); vectorStore.add(chunks); // 自动调用嵌入模型 }踩坑记录首次使用时没设置spring.ai.embedding.dimensions1024导致维度不匹配Elasticsearch抛出400错误。务必确认嵌入模型的输出维度与向量库配置一致。4. 检索增强实现4.1 混合检索策略在ElasticsearchVectorStoreConfig中开启混合搜索spring.ai.vectorstore.elasticsearch.hybridtrue spring.ai.vectorstore.elasticsearch.knn5 spring.ai.vectorstore.elasticsearch.boost0.3这个配置表示返回传统搜索和向量搜索的综合结果取前5个最相关片段给关键词匹配30%的权重加成4.2 查询优化技巧通过Advisor模式封装RAG逻辑是更优雅的做法Bean public Advisor ragAdvisor() { return new QuestionAnswerAdvisor(vectorStore) .setPromptTemplate( 基于以下上下文回答问题 {context} 问题{question} 要求 1. 如果上下文不相关回答我不知道 2. 引用上下文中的具体段落 ); }这种方式的优势在于统一处理所有LLM查询自动注入检索到的上下文集中管理提示词模板5. 生产级优化方案5.1 性能监控配置在application.properties中添加management.endpoints.web.exposure.include* management.metrics.export.elastic.enabledtrue这会将以下关键指标推送到Elasticsearch每次检索的文档数量嵌入模型调用耗时LLM生成token消耗5.2 缓存策略实现对于高频问题可以添加缓存层Cacheable(value ragCache, key #question.hashCode()) public String query(String question) { // ...原有查询逻辑 }配合Spring Cache的TTL设置可以减少30%以上的LLM调用成本。6. 常见问题排查6.1 效果调优指南当回答质量不理想时按这个顺序检查检索阶段检查ES返回的文档是否相关分块阶段查看原始文档的分块是否合理生成阶段调整prompt模板的指令6.2 典型错误解决方案问题一java.lang.IllegalArgumentException: Invalid vector dimension原因嵌入模型输出维度与ES配置不符解决检查spring.ai.embedding.dimensions参数问题二回答包含幻觉内容原因prompt未设置严格的回答限制解决在模板中添加仅基于上下文回答的强约束7. 扩展应用场景7.1 多模态支持最新版的Spring AI已支持图像向量化Bean public MultiModalVectorStore multiModalStore() { return new ElasticsearchMultiModalVectorStore(elasticsearchClient); }这样就能实现用文字搜索图片等高级功能。7.2 实时更新方案对于频繁变更的数据源建议实现监听模式EventListener(ApplicationReadyEvent.class) public void initWatcher() { WatchService.watch(docDir) .onModify(file - vectorStore.add(process(file))); }我在一个电商项目中用这个方案将商品信息更新的延迟控制在10秒内。