Skip to main content

企业RAG优化实战：从能用到好用的工程化演进

· 6 min read
James Zheng
James Zheng
Javaer

随着技术的发展，RAG（Retrieval-Augmented Generation，检索增强生成）几乎成为企业AI应用的标准架构。

然而很多团队上线后会发现：

  • 检索结果不准确
  • 明明知识库里有答案却找不到
  • 上下文过长导致成本升高
  • 用户反馈效果时好时坏

实际上，企业RAG的难点并不在于搭建一个Demo，而在于如何持续优化召回率和答案准确率。

本文结合实际项目经验，介绍企业RAG系统常见的优化方案，以及背后的工程实现思路。

1 Chunk大小如何确定

Chunk（文本切片）是影响RAG效果最关键的因素之一。

很多初学者直接采用：

每500个字符切一块

这种方式虽然简单，但往往效果并不好。

Chunk过小的问题​

例如：

订单已发货。

物流单号：
SF123456789

预计3天送达。

如果切片长度过小：

Chunk1:
订单已发货

Chunk2:
物流单号：SF123456789

Chunk3:
预计3天送达

用户提问：

订单什么时候到？

可能只召回Chunk3。

模型缺少上下文。

Chunk过大的问题​

如果一个Chunk包含：

商品介绍
物流政策
售后政策
优惠券规则
会员权益

Embedding会变得不聚焦。

用户问：

如何退货？

召回结果可能包含大量无关信息。

企业常用策略​

Fixed Size​

固定长度切分

Chunk Size = 500~1000 Tokens
Overlap = 100~200 Tokens

适合：

  • FAQ
  • 产品说明书
  • 运营文档

Sliding Window​

滑动窗口切分

Chunk1 0~500

Chunk2 400~900

Chunk3 800~1300

保留上下文连续性。

适用于：

  • 长文档
  • 技术手册
  • 法律合同

Semantic Chunk​

基于语义切分

例如：

# 售后政策

...
...

# 物流规则

...
...

按标题进行切分。

优点：

  • 语义完整
  • Embedding质量高
  • 召回更准确

实际经验​

企业项目中通常采用：

标题切分
+
滑动窗口
+
最大Token限制

组合方案。

效果往往优于单纯固定长度切分。

2 Hybrid Search

很多团队上线后发现：

只做向量检索

效果并不好。

原因在于：

Embedding擅长理解语义。

但不擅长精确匹配。

典型实现：

BM25
ElasticSearch
OpenSearch

例如：

用户搜索：

SKU123456

向量模型未必理解SKU。

但关键词检索能够精准命中。

流程：

Query
 ↓
Embedding
 ↓
向量检索
 ↓
TopK

适用于：

快递太慢

召回：

物流延迟
配送超时
运输异常

等语义相近内容。

生产环境通常采用：

BM25
+
Vector Search

架构如下：

用户问题

      ↓

BM25召回
--------
向量召回

      ↓

 Merge

      ↓

 ReRank

优势：

  • 提高召回率
  • 减少漏召回
  • 提升长尾问题覆盖率

3 ReRank原理

很多团队误以为：

TopK检索结果
直接喂给LLM

即可。

实际上这是效果下降的重要原因。

为什么需要ReRank​

假设用户提问：

水果不甜怎么办？

检索返回：

A 商品种植基地介绍

B 水果糖度标准

C 售后赔付规则

向量相似度：

A 0.82

B 0.81

C 0.80

差距非常小。

真正最有价值的是：

C 售后赔付规则

但可能排在最后。

ReRank流程​

Query

 +
 
Candidate Docs

      ↓

Cross Encoder

      ↓

重新打分

      ↓

TopN

常见模型​

开源：

  • BGE-Reranker
  • BCE-Reranker

商业：

  • Cohere Rerank

效果提升​

实际项目中：

仅向量召回

准确率：
70%左右

加入ReRank：

80%~90%

属于投入产出比最高的优化手段之一。

4 查询改写（Query Rewrite）

用户的问题往往并不适合直接检索。

例如：

这个东西为什么还没到？

Embedding很难理解：

这个东西

指什么。

Query Rewrite流程​

原始问题

 ↓

LLM改写

 ↓

检索

例如：

这个东西为什么还没到

改写为：

订单物流延迟原因是什么

多轮对话场景​

用户：

苹果怎么样？

助手：

甜度较高。

用户：

那坏了怎么办？

改写后：

苹果收到后腐烂怎么办

才能正确检索。

企业实现​

通常增加一个轻量模型：

Rewrite Model

负责：

  • 指代消解
  • 上下文补全
  • 同义词扩展

降低检索难度。

5 多路召回

大型知识库中，单一路径召回往往不够。

企业通常采用：

Multi Retrieval

常见召回源​

FAQ知识库​

运营维护

商品知识库​

商品属性
商品卖点

售后知识库​

退货规则
赔付规则

业务数据库​

实时查询：

订单状态
物流状态
库存状态

多路召回架构​

     用户问题

        ↓

  Intent Router

        ↓

 FAQ | 商品 | 售后

        ↓

     Merge

        ↓

     ReRank

工程实现​

常见做法：

CompletableFuture

并行召回：

faqRetriever.retrieve();

productRetriever.retrieve();

aftersaleRetriever.retrieve();

最终聚合。

这样能够将整体耗时控制在：

200~500ms

以内。

6 线上效果评估

很多团队上线后面临的问题：

用户说不好用

但不知道哪里出了问题。

因此必须建立评估体系。

Retrieval指标​

Recall@K​

正确答案是否被召回

Recall@5

Recall@10

MRR​

Mean Reciprocal Rank

衡量正确结果排名。

NDCG​

考虑排序质量。

适用于：

ReRank评估

Generation指标​

Answer Correctness​

答案正确率

Groundedness​

答案是否来自知识库

用于评估幻觉。

Faithfulness​

回答是否忠于检索内容。

A/B实验​

线上通常同时运行：

方案A
旧检索策略

方案B
新检索策略

比较：

  • 点击率
  • 采纳率
  • 用户满意度
  • 人工评分

总结

企业RAG的优化，本质上是一个搜索工程问题，而不仅仅是大模型问题。

一个成熟的RAG系统通常包含：

Chunk优化
        ↓
Hybrid Search
        ↓
Query Rewrite
        ↓
多路召回
        ↓
ReRank
        ↓
Prompt组装
        ↓
LLM生成
        ↓
效果评估

对于Java工程师而言，真正的竞争力不在于调用一次大模型API，而在于构建一套可扩展、可观测、可持续优化的RAG工程体系。

当知识库规模从几百篇文档增长到几十万篇文档时，决定系统效果的往往不是模型参数，而是检索链路上的每一个工程细节。