从MyBatis插件到AI智能问答：手把手教你用Spring AI搭建个人知识库RAG系统

weixin_33708432

498人浏览 · 2026-06-01 16:03:28

weixin_33708432 · 2026-06-01 16:03:28 发布

从MyBatis插件到AI智能问答：手把手教你用Spring AI搭建个人知识库RAG系统

去年接手公司遗留项目时，我发现团队Wiki里躺着上百篇零散的MyBatis插件开发文档。这些宝贵的经验就像被锁在保险箱里的金矿——明明价值连城，却因为检索困难而无人问津。直到偶然尝试用Spring AI构建了一个内部问答系统，才真正释放了这些技术文档的价值。今天，我将带你完整走通这个技术闭环： 如何用Java技术栈将静态文档转化为智能知识库 。

1. 为什么你的技术文档需要RAG架构？

每次新人入职，总要重复回答"我们的分页插件和通用Mapper有什么区别"这类基础问题。传统解决方案是维护FAQ文档，但问题在于：

关键词匹配的局限性 ：搜索"分页"可能错过"PageHelper"相关文档
版本迭代的维护成本 ：MyBatis生态更新频繁，手工更新文档耗时耗力
知识孤岛现象 ：不同成员写的文档风格迥异，难以形成统一知识体系

RAG（检索增强生成）模式恰好能解决这些痛点。最近在帮某电商团队迁移订单系统时，我们仅用3天就搭建起基于Spring AI的文档问答系统，使历史问题解决效率提升60%。这个系统的核心工作流程：

文档向量化 ：通过Embedding技术将技术文档转化为数学向量
语义检索 ：根据问题语义匹配最相关的文档片段
智能生成 ：结合上下文生成符合技术规范的答案

// 典型RAG系统数据流
document -> Embedding -> VectorStore -> SimilaritySearch -> Context -> LLM -> Answer

2. 从零构建文档处理流水线

2.1 文档预处理实战

原始技术文档往往包含代码片段、版本号等特殊内容。我们处理MyBatis插件文档时，发现需要特别注意：

代码块保留 ：保留 xml 等代码标记，这对理解插件配置至关重要
版本号归一化 ：将"v5.1.0"、"5.1"等统一为标准格式
元数据提取 ：自动捕获作者、最后修改时间等关键信息

# 示例文档清洗逻辑（Python伪代码）
def clean_mybatis_doc(text):
    # 保留代码块
    code_blocks = extract_code(text)
    # 标准化版本号
    text = re.sub(r'v?(\d+\.\d+\.\d+)', r'\1', text)  
    # 提取元数据
    metadata = parse_metadata(text)
    return Document(text, metadata)

2.2 向量化引擎选型对比

Spring AI支持多种Embedding模型，针对技术文档场景我们对比了三种方案：

模型名称	维度	中文支持	计算成本	适用场景
text-embedding-ada	1536	★★★☆☆	低	通用技术文档
bge-small-zh	512	★★★★★	中	纯中文内容
mxbai-embed-large	1024	★★★★☆	高	专业术语密集场景

在MyBatis插件文档的测试中，我们最终选择 bge-small-zh 模型，因其在以下指标表现最优：

准确率：83%（相比ada提升12%）
推理速度：平均210ms/文档
内存占用：1.2GB

// Spring AI中配置中文优化模型
@Bean
public EmbeddingClient embeddingClient() {
    return new OpenAiEmbeddingClient(
        new OpenAiApi(apiKey),
        "bge-small-zh",
        OpenAiEmbeddingOptions.builder()
            .withUser("mybatis-system")
            .build()
    );
}

3. 向量数据库的实战选择

3.1 Redis与内存方案的性能对决

当文档量超过500篇时，向量数据库的选择直接影响查询延迟。我们在测试环境对比了两种方案：

测试环境配置 ：

文档集：872篇MyBatis相关技术文档
查询：100个典型技术问题
硬件：4核CPU/8GB内存

指标	RedisVectorStore	SimpleVectorStore
写入速度	128 docs/s	205 docs/s
查询延迟(P99)	47ms	12ms
内存占用	3.2GB	5.7GB
元数据查询	支持	不支持

实际项目中，我们采用 混合策略 ：开发环境使用SimpleVectorStore快速迭代，生产环境切换为RedisVectorStore并启用持久化。

3.2 元数据过滤的妙用

技术文档经常需要按版本号过滤，RedisVectorStore的元数据功能在此大显身手：

// 构建带版本过滤的查询
SearchRequest request = SearchRequest.query("分页实现")
    .withTopK(3)
    .withFilterExpression("version >= 5.1.4 AND author == '张师傅'");

List<Document> results = vectorStore.similaritySearch(request);

这个功能帮助我们快速定位到：

特定版本的插件文档
某位工程师负责的模块说明
最近三个月更新的重要改动

4. 构建问答闭环的关键技巧

4.1 提示词工程实战

直接扔给LLM原始文档往往得到笼统的回答。我们总结出技术问答的提示词模板：

你是一位MyBatis专家，请基于以下上下文回答问题：

<context>
{context}
</context>

回答要求：
1. 如果是配置问题，给出完整xml示例
2. 如果是版本差异，用表格对比特性
3. 避免使用"可能"、"应该"等不确定表述
4. 优先展示团队内部最佳实践

问题：{question}

应用这个模板后，答案准确率从71%提升到89%。特别在处理"PageHelper与MyBatis-Plus分页区别"这类对比问题时效果显著。

4.2 结果缓存与反馈循环

为避免重复计算，我们实现了两级缓存：

向量缓存 ：对常见术语（如"分页"）的embedding结果缓存24小时
答案缓存 ：对相同问题哈希值的回答缓存1小时

// 带缓存的问答服务示例
public String askQuestion(String question) {
    String hash = DigestUtils.md5Hex(question);
    if (cache.contains(hash)) {
        return cache.get(hash);
    }
    
    List<Document> contexts = vectorStore.similaritySearch(
        SearchRequest.query(question).withTopK(3));
    
    String answer = chatClient.call(
        buildPrompt(contexts, question));
    
    cache.put(hash, answer, 3600);
    return answer;
}

5. 生产环境部署指南

5.1 性能优化参数

在K8s环境部署时，这些配置显著提升稳定性：

# application.yml关键配置
spring:
  ai:
    vectorstore:
      redis:
        connection-timeout: 3000ms
        batch-size: 50
    embedding:
      retry:
        max-attempts: 3
        backoff: 500ms