Spring AI + Milvus 实现 RAG，Java 生态的标准答案

Spring AI 是 Java 生态接入大模型的标准方案，搭配 Milvus 向量数据库就能搭一套完整的 RAG 系统。

依赖配置：

<dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-milvus-store</artifactId>
</dependency>

向量存储配置：

@Bean
public VectorStore vectorStore(MilvusVectorStoreConfig config) {
    return new MilvusVectorStore(config);
}

检索问答链：

@Bean
public RetrievalAugmentedAdvisor ragAdvisor(
        VectorStore vectorStore, ChatClient.Builder builder) {
    return RetrievalAugmentedAdvisor.builder()
        .vectorStore(vectorStore)
        .chatClientBuilder(builder)
        .build();
}

核心流程就三步：文档向量化存入 Milvus，用户问题转为向量检索相似片段，把检索结果作为上下文交给 LLM 生成回答。Spring AI 把这些封装成了 AutoConfiguration，配置好就能用。

RAG 系统的性能优化是一个系统工程。从文档处理到检索策略到生成融合，每个环节都可能成为瓶颈。文档切分是 RAG 的基础，切得太细检索精度高但上下文不完整，切得太粗上下文完整但检索精度低。实践中常用的策略是语义切分，根据文档的段落和标题结构来切分。检索策略的选择同样关键，纯向量检索无法处理精确匹配需求，全文关键词检索无法理解语义，混合检索可以兼顾两者。RRF 融合算法是目前最实用的混合检索结合方式，它不需要对两种检索的分数做归一化，直接基于排名位置做融合。Embedding 模型的选择直接影响检索质量，bge-m3 和 gte-qwen2 等中文优化模型可以让中文 RAG 系统的检索质量有明显提升。Reranker 可以在检索结果的 TOP-K 中做精排，尽管增加了系统复杂度和延迟，但对于需要高精度的场景来说，带来的提升是值得的。

AI 领域有一个普遍的趋势：技术进步的速度远超组织和个人的适应速度。这意味着今天的最佳实践可能在半年后就过时了。因此与其追求掌握某个特定技术的所有细节，不如培养快速学习和判断技术价值的能力。当一个新的框架或模型发布时，快速判断它对自己的工作有没有价值，值得花多少时间去学习。对于没有长期价值的热点，保持关注即可，不需要深入学习。对于有长期价值的趋势，投入足够的时间深入理解底层原理，而不仅仅是会使用工具。这种能力的培养需要持续阅读、实践和总结。每周花固定时间阅读技术博客和论文，每月做一个实践项目验证所学知识，每季度进行一次知识体系的复盘和重构。

在软件开发领域，有一条经验法则：任何在开发阶段看起来很聪明但让调试变得困难的做法，最终都不是好主意。这条法则在 AI 应用开发中尤其适用。AI 应用的不确定性比传统软件高得多，这意味着调试和排查问题的难度也大得多。因此 AI 应用的设计应该追求简单、透明、可追踪。简单意味着每个组件的职责清晰，组件之间的依赖关系明确。透明意味着系统的每个决策过程都可以被追溯和理解。可追踪意味着每次模型调用、每步推理过程都被记录在案。只有做到了这三条，你才能在系统出现问题时快速定位根因。

AI 项目的技术栈选择决定了开发效率和后期维护的成本。Python 是目前 AI 开发的主流语言，拥有最丰富的生态。TypeScript 在 AI 应用开发中也越来越流行，特别是在需要前后端一体化的场景中。选择技术栈时的核心原则是优先考虑团队熟悉的技术，减少学习成本。框架选择同理，LangChain 功能丰富但复杂度也高，直接调用 API 可能更可控。建议从最简单的方案开始，随着需求复杂度的增加逐步引入框架。过早的框架选择会让系统复杂度不必要地增加。