
在企业级应用开发中,我们习惯于将业务逻辑固化在代码里,数据沉淀在数据库中。但当大模型浪潮袭来,一个尴尬的困境浮现出来:传统应用积累了海量知识(文档、工单、FAQ),却无法被大模型有效利用。
直接调用大模型API的简单做法,很快暴露出两个致命问题:一是模型幻觉,模型可能“一本正经地胡说八道”;二是知识滞后,模型训练数据截止日期之后的新信息,它一概不知。
RAG(检索增强生成) 正是为此而生。它不是让大模型“凭空想象”,而是先到企业专属的知识库中检索相关片段,再将这些片段作为上下文“喂”给大模型,让它基于事实生成回答。这一架构有效解决了幻觉和知识滞后问题,让AI的回答“有据可查”。
对于存量Java应用而言,引入RAG的最大挑战并非算法,而是如何以低侵入、高可控的方式将AI能力融入现有技术栈。这正是Spring AI Alibaba框架的核心价值所在。
在AI开发几乎被Python垄断的当下,Spring AI Alibaba为Java生态提供了一条平滑的接入路径。其核心优势体现在三个层面:
RAG系统的检索效率直接决定最终体验。Milvus作为开源向量数据库的事实标准,具备以下关键能力:
对于传统应用的升级,我遵循“数据层独立、检索层封装、应用层无感”的原则,整体架构分为四层:
基础环境要求JDK 17+、Spring Boot 3.x。核心Maven依赖如下:
<!-- Spring AI Alibaba 核心 Starter -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-ai-alibaba-starter</artifactId>
<version>1.0.0</version>
</dependency>
<!-- Milvus Java 客户端 -->
<dependency>
<groupId>io.milvus</groupId>
<artifactId>milvus-client</artifactId>
<version>2.3.0</version>
</dependency>
<!-- 如使用Redis作为向量存储的备选方案,可引入 -->
<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-starter-vector-store-redis</artifactId>
</dependency>配置文件中接入通义千问模型:
spring:
ai:
dashscope:
api-key: ${DASHSCOPE_API_KEY}
chat:
options:
model: qwen-plus
milvus:
host: localhost
port: 19530
collection-name: knowledge_base
dimension: 768 # 与Embedding模型维度一致首先将企业存量文档转化为向量。以文本片段为例,使用Sentence-BERT或通义Embedding模型生成向量,存入Milvus:
@Service
public class KnowledgeIngestService {
@Autowired
private MilvusClient milvusClient;
public void ingestDocument(String docId, String content) {
// 1. 文本分块(实际项目建议按段落或语义切分)
List<String> chunks = splitText(content, 512);
// 2. 调用Embedding模型生成向量(示例调用Python Embedding服务)
List<float[]> embeddings = embeddingService.encode(chunks);
// 3. 构建Milvus插入请求
List<InsertParam.Field> fields = new ArrayList<>();
fields.add(InsertParam.Field.newBuilder("doc_id",
chunks.stream().map(c -> docId).collect(Collectors.toList())).build());
fields.add(InsertParam.Field.newBuilder("content", chunks).build());
fields.add(InsertParam.Field.newBuilder("embedding", embeddings).build());
milvusClient.insert(InsertParam.newBuilder()
.withCollectionName("knowledge_base")
.withFields(fields)
.build());
}
}这是RAG的核心流程,Spring AI Alibaba将其封装为清晰的Pipeline:
@Service
public class RagService {
@Autowired
private MilvusClient milvusClient;
@Autowired
private ChatModel chatModel; // Spring AI Alibaba 抽象
@Autowired
private EmbeddingService embeddingService;
public String ask(String userQuery) {
// 1. 用户Query向量化
float[] queryVector = embeddingService.encode(userQuery);
// 2. Milvus相似度检索(TopK=3)
SearchParam searchParam = SearchParam.newBuilder()
.withCollectionName("knowledge_base")
.withVectors(Collections.singletonList(queryVector))
.withLimit(3)
.withMetricType(MetricType.IP) // 内积相似度
.build();
SearchResult result = milvusClient.search(searchParam);
// 3. 提取检索到的文本片段作为上下文
List<String> contexts = extractContentFromResult(result);
String contextStr = String.join("\n---\n", contexts);
// 4. 构造Prompt,调用大模型生成回答
String prompt = String.format("""
请基于以下参考信息回答用户问题。
参考信息:
%s
用户问题:%s
回答(请简洁准确,仅基于参考信息):
""", contextStr, userQuery);
PromptTemplate template = new PromptTemplate(prompt);
return chatModel.call(template.create()).getResult().getOutput();
}
}这段代码的核心思想是:检索不是目的,而是为生成提供事实依据。通过将检索到的文档片段拼接到Prompt中,大模型的回答被“约束”在给定知识范围内,有效抑制了幻觉。
纯向量检索可能遗漏精确关键词匹配。生产环境中建议引入混合检索:向量检索召回语义相关结果,同时BM25等关键词检索召回精确匹配结果,经重排序(Re-ranking)模型合并后取TopK。
Milvus从2.4版本开始原生支持BM25+向量混合检索,其TEXT_MATCH过滤器实现精确匹配,再用BM25对匹配结果排序,同时满足“精准”与“智能”。
当RAG系统服务于企业内部多个部门(如HR、法务、研发)时,数据隔离成为刚需。Milvus提供了三种多租户策略:
策略 | 隔离粒度 | 最大租户数 | 适用场景 |
|---|---|---|---|
Database级 | 最强 | ~1,000 | 大型部门,需完全独立的数据模型 |
Collection级 | 中等 | ~10,000 | 标准SaaS场景,租户间结构一致 |
Partition Key级 | 逻辑隔离 | ~10,000,000 | 海量租户,成本敏感 |
对于企业内部知识库,Database级多租户最为合适——每个部门独立Database,既保证安全性,又允许各自定义Collection结构。
通过Spring AI Alibaba + RAG + Milvus的组合,我们以极低的代码改动为传统Java应用注入了AI能力。这套架构的核心价值在于:
未来,随着多模态RAG、实时知识同步、Agent工作流编排等能力成熟,传统应用的智能化将从“问答辅助”演进为“自主决策”。而今天基于Spring AI Alibaba的实践,正是这一演进中最扎实的起点。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。