企业级RAG问答系统构建与优化实战

1. 企业级RAG问答系统实现全记录

去年接手公司内部知识库优化项目时，我发现工程师们宁愿在聊天工具里反复询问同事，也不愿查阅已经整理好的技术文档。这种现象促使我开始思考：如何让静态文档"活"起来？经过三个月的迭代，我们基于Spring AI Alibaba ReactAgent和Qdrant构建的RAG问答系统，最终将文档利用率提升了60%。下面分享这套系统的完整实现思路和实战经验。

1.1 技术选型背后的考量

选择Spring AI Alibaba ReactAgent作为Agent框架，主要基于三个实际考量：

1. 与现有Java技术栈无缝集成，团队学习成本低
2. 支持动态工具注册和调用，适合需要多次检索的业务场景
3. 阿里巴巴开源的ReactAgent在中文场景表现优于LangChain

向量数据库选用Qdrant而非Milvus，则是出于以下对比：

提示：企业级选型要特别注意技术债务风险。我们曾测试过直接调用OpenAI Embedding+PGVector的方案，虽然开发快但存在数据出境风险，最终放弃。

1.2 系统架构全景图

整个系统采用分层设计，各模块职责明确：

code复制[文档接入层] --> [预处理流水线] --> [增强索引层] 
    --> [混合检索引擎] --> [问答生成层]

核心处理流程耗时分布（实测数据）：

• 文档清洗：15%总耗时
• 智能分块：25%总耗时
• 向量化入库：40%总耗时
• 检索生成：20%总耗时

2. 文档处理的关键实践

2.1 多源数据接入方案

我们对接了三种文档来源：

1. 语雀知识库（通过OpenAPI）
2. Confluence文档（使用REST API）
3. 本地Markdown文件（定期同步）

语雀API调用示例：

java复制YuqueClient client = new YuqueClient(TOKEN);
List<YuqueDocument> docs = client.getRepoDocuments(NAMESPACE)
    .stream()
    .filter(doc -> "published".equals(doc.getStatus()))
    .collect(Collectors.toList());

遇到的坑：Confluence的HTML内容包含大量样式标签，需要用Jsoup清洗：

java复制String cleanContent = Jsoup.parse(rawHtml)
    .select("div.content")
    .text()
    .replaceAll("\\s+", " ");

2.2 文档分块的黄金法则

经过20+次调整，我们总结出最佳分块策略：

1. 结构感知分块：

   • 保留文档目录层级关系
   • 标题自动成为chunk的元数据
   • 代码块保持完整不分割

2. 动态分块算法：

java复制public List<Chunk> splitDocument(Document doc) {
    if (doc.length() < 800) return List.of(fullDocChunk);
    
    List<Section> sections = parseHeadings(doc);
    if (!sections.isEmpty()) {
        return splitBySections(sections);
    }
    
    return splitByParagraphs(doc);
}

3. 上下文继承机制：
   每个chunk都携带父级标题链，例如：

code复制[产品手册] > [安装指南] > [Docker部署]

实测发现：带上下文的chunk在检索准确率上比普通分块高37%

3. 增强索引的工程实现

3.1 多维度特征提取

除了原始文本，我们提取了三种增强特征：

1. 关键词抽取：
   采用TF-IDF结合TextRank的混合算法：

python复制def extract_keywords(text):
    tfidf = TfidfVectorizer().fit([text])
    tr = TextRank().analyze(text)
    return list(set(tfidf.top_terms(5) + tr.top_terms(3)))

2. 摘要生成：
   先用规则方法生成候选句，再用模型优化：

java复制String summary = SummaryGenerator.generate(content)
    .filter(sent -> sent.length() > 15)
    .limit(3)
    .collect(Collectors.joining("。"));

3. 实体识别：
   使用HanLP识别技术术语：

java复制List<String> entities = HanLP.segment(content)
    .stream()
    .filter(term -> "nt".equals(term.nature))
    .map(term -> term.word)
    .distinct()
    .collect(Collectors.toList());

3.2 向量化最佳实践

我们测试了三种embedding方式：

最终选择text2vec-large，虽然速度慢但准确率高。存储时采用"特征拼接法"：

java复制String vectorContent = String.join("\n", 
    chunk.getTitle(),
    String.join(",", chunk.getKeywords()),
    chunk.getSummary(),
    chunk.getContent()
);
float[] vector = embeddingModel.embed(vectorContent);

4. 混合检索系统设计

4.1 双路检索架构

mermaid复制graph TD
    A[用户查询] --> B{Query Rewrite}
    B --> C[向量检索]
    B --> D[BM25检索]
    C --> E[RRF融合]
    D --> E
    E --> F[结果去重]
    F --> G[最终排序]

核心参数配置：

yaml复制retrieval:
  vector:
    top_k: 15
    similarity_threshold: 0.78
  keyword:
    top_k: 10
  fusion:
    method: rrf
    k: 60

4.2 查询改写策略

实现对话上下文感知的改写：

java复制public String rewriteQuery(String currentQuery, List<ChatMessage> history) {
    if (history.size() > 2) {
        String lastAnswer = history.get(history.size()-1).getContent();
        return currentQuery + "[上下文]" + lastAnswer;
    }
    return currentQuery;
}

典型改写案例：

code复制原始查询："这个参数怎么设置？"
改写后："[上下文]您说的是数据库连接池大小参数吗？这个参数怎么设置？"

5. Agent问答系统实现

5.1 ReactAgent核心配置

java复制@Bean
public ReactAgent qaAgent(ChatModel chatModel, VectorSearchTool searchTool) {
    return ReactAgent.builder()
        .name("QA-Agent")
        .model(chatModel)
        .methodTools(searchTool)
        .maxIterations(3)
        .stopOnObservation(true)
        .build();
}

工具注册关键点：

• 每次检索会记录搜索词和结果数
• Agent可以基于上次结果调整搜索策略
• 最多进行3轮自主检索

5.2 回答生成策略

采用两阶段生成：

1. 检索验证阶段：

markdown复制检索到5个相关文档：
1. 《安装指南》第3章(匹配度87%)
2. 《常见问题》Q15(匹配度79%)
...
请确认是否需要更多信息？

2. 最终回答阶段：

markdown复制根据《安装指南》第3章建议：
1. 修改config.yaml中的pool_size
2. 建议值：生产环境50-100
3. 需要重启服务生效

[来源]：https://internal-docs/install#ch3

6. 性能优化实战

6.1 缓存设计

三级缓存架构：

1. 查询缓存：缓存原始query的检索结果（TTL=1h）
2. 改写缓存：缓存改写后query的检索结果（TTL=30min）
3. 答案缓存：缓存最终生成的回答（TTL=24h）

使用Caffeine实现：

java复制LoadingCache<String, List<Document>> cache = Caffeine.newBuilder()
    .maximumSize(10_000)
    .expireAfterWrite(30, TimeUnit.MINUTES)
    .build(query -> vectorSearch(query));

6.2 异步处理流水线

耗时操作异步化设计：

java复制CompletableFuture<List<Chunk>> chunkFuture = CompletableFuture
    .supplyAsync(() -> chunker.chunk(doc), ioExecutor);

CompletableFuture<List<Vector>> vectorFuture = chunkFuture
    .thenComposeAsync(chunks -> 
        CompletableFuture.supplyAsync(() -> 
            chunks.stream().map(embedder::embed).toList(),
            computeExecutor
        )
    );

线程池配置建议：

• IO密集型：线程数=CPU核心数×2
• 计算密集型：线程数=CPU核心数+1

7. 踩坑与解决方案

7.1 中文分词的坑

问题现象：
"Java线程池"被错误分词为["Java", "线", "程池"]

解决方案：
自定义Qdrant分词器配置：

json复制{
  "tokenizers": {
    "chinese": {
      "type": "jieba",
      "dict_path": "/path/to/user_dict.txt"
    }
  }
}

用户词典示例：

code复制线程池 n
连接池 n
SpringBoot n

7.2 向量漂移问题

问题现象：
相似文档的余弦相似度波动达±0.15

解决方案：

1. 实现embedding结果归一化

java复制float[] normalized = normalize(vector);

2. 定期重新embedding热点文档
3. 引入相似度校准层

8. 效果评估指标

我们建立了三维评估体系：

1. 检索层面：

   • MRR@5：0.82
   • Recall@10：0.91

2. 生成层面：

   • 答案准确率：89%
   • 引用准确率：93%

3. 业务层面：

   • 平均解决时间缩短40%
   • 重复提问减少65%

持续优化方法：

• 每周人工评估100个随机query
• 难点case加入回归测试集
• 每月更新embedding模型

这套系统已在内部运行8个月，处理了超过15万次查询。最大的体会是：RAG系统就像园丁，需要持续修剪（优化检索）和施肥（更新数据），才能保持旺盛的生命力。最近我们正在试验将用户反馈自动转化为训练数据的方法，或许下次可以分享这个方向的实践。