不知道大家有没有一种感觉，RAG从诞生之初，就一直处于一种“既生又死”的状态，今天某人宣称有一个新实践可以干掉RAG，结果大家试了试发现还是不能取代RAG。过了一段时间又有人说一种新的实践可以取代RAG，RAG又“死”了，结果没几天，大家还是乖乖的用回RAG。就像是GTA6一样，每隔一段时间就是一个循环。

但是R星现在终于确定了发售日期（希望如此），而skill的出现似乎真的杀死了RAG 吗？

似乎不是的，个人用下来感觉skill看起来和RAG确实很像，都是精简提炼某个领域的最佳实践或者指导，然后喂给大模型，但是但是，skill相对固定，如果是知道自己要做什么，那么skill确实好用。但是遇到一个庞大的企业知识库，skill就显得不那么灵活了。

---

在前两篇文章中，我和大家讨论了

• 为什么 Agent 相比单个 LLM 和 Workflow 更强

• 为什么 Agent 需要 Memory 才能处理长期任务

本篇文章会和大家探讨一下AI内容质量工程，RAG是如何提升生产质量的。我们先从一个问题入手：

即使模型很强，回答依然经常不准确。

例如：

• 企业内部知识问答

• 技术文档查询

• 产品使用说明

• 公司政策问答

如果直接让大模型回答，大模型往往会：

• 编造不存在的内容

• 使用过时的知识

• 回答与实际文档不一致

这种现象通常被称为 “幻觉（Hallucination）”。

而解决这个问题最常见的方法，就是 Retrieval-Augmented Generation（RAG）。

一、为什么大模型的回答会不靠谱

1.知识是静态的

虽然模型训练的时候数据量很大，但是这些数据往往都是公开的一些数据，模型训练完成之后无法自动获取新知识，无法更新企业内部数据，无法访问私有数据库。 所以模型在回答涉及到一些企业私有的问题时往往效果很差。

2.知识是模糊的

即使模型知道相关知识，也可能只是模糊理解。

例如：

Kafka 如何保证消息不丢失？

模型可能回答：

• replication

• ack机制

• leader follower

但并不一定符合你公司内部的具体配置。

3.模型倾向于“编造答案”

当模型不知道答案时，往往不会直接说："我不知道"

而是会生成一个看起来合理但实际上错误的回答。

这就是所谓的 幻觉。

二、RAG解决的核心问题

RAG 的核心思想非常简单：

在生成回答之前，先从外部知识库中检索相关信息，再让模型基于这些信息回答。

基本流程如下：

用户问题
   │
向量化 (Embedding)
   │
向量检索 (Vector Search)
   │
相关文档
   │
拼接到 Prompt
   │
LLM 生成答案

这样做的好处是：

• 模型回答基于真实文档

• 可以接入私有知识库

• 知识可以动态更新

因此 RAG 成为目前企业 AI 系统中最常见的架构之一。

三、为什么很多RAG系统效果依然很差？

1. 用户问题 ≠ 检索 Query

一个经常被忽略的问题是：用户提出的问题，并不一定适合作为检索语句。

例如用户问：

这个系统为什么会 OOM？

但知识库中的文档可能是：

JVM 内存溢出的常见原因

虽然两者语义相关，但表达方式完全不同。

在这种情况下，直接把用户问题进行向量化检索，很可能无法找到真正相关的文档。

因此很多工业级 RAG 系统都会增加一个步骤：

Query Rewrite（查询重写）

也就是在检索之前，通过模型或规则对问题进行改写，例如：

系统OOM原因
JVM OOM原因
Java内存溢出问题

这样可以显著提高检索召回率。

---

2. 文档切分（Chunking）方式不合理

RAG 系统在构建知识库时，通常需要把长文档拆分成多个小块（chunk）。

很多系统为了简单，直接按照固定长度切分，例如：

每1000 token切一段

这种方式实现起来很简单，但往往会破坏文档的语义结构。

例如一段技术文档可能包含：

函数说明
代码示例
参数解释

如果在切分时把这些内容拆散，就可能出现这样的情况：

• 检索到了代码，但没有说明

• 检索到了说明，但没有代码

最终导致模型获得的上下文是 不完整的。

更合理的做法通常包括：

• 按章节或标题切分

• 按语义段落切分

• 对代码块进行完整保留

这样可以保证每个 chunk 本身就是一个相对完整的信息单元。

---

3. TopK结果不一定是最相关的

向量检索的结果通常是：

TopK 相似度文档

但需要注意的是，embedding 相似度只是一个粗粒度的语义相似度判断，并不能完全等同于“相关性”。

在实际系统中，经常会出现这样的情况：

• Top5 中只有 1~2 篇文档真正相关

• 其他文档只是语义相似，但内容并不匹配

因此在企业 RAG 系统中，通常会增加 Rerank（重排序） 阶段。

整体流程会变成：

Vector Search(向量搜索) → Top50
        ↓
      Rerank(重排序)
        ↓
       Top5

Rerank 模型会重新评估：

query 与 document 的相关性

从而筛选出真正最有价值的文档。

---

4. 上下文噪声污染

很多初级 RAG 系统在拿到检索结果之后，会直接把所有文档拼接进 Prompt，例如：

Top5 文档 → 全部加入上下文

但这样做往往会带来新的问题。

如果上下文中包含：

• 弱相关信息

• 重复信息

• 甚至相互矛盾的内容

模型在生成回答时就可能产生混乱。

因此在成熟的 RAG 系统中，还会增加一个重要步骤：

Context Filtering / Context Compression

也就是对检索到的文档进行筛选和压缩，只保留真正有价值的信息。

这样既可以减少 token 消耗，也能提升模型的理解效率。

5.知识库本来的质量就不高

出现这种问题，赶紧把文档复杂人揪出来打一顿吧。

四、目前我自己实践的RAG架构

                  用户问题(User Query)
                       │
                       ▼
                提示词改写(Query Rewrite)
                       │
                       ▼
              混合搜索(Hybrid Retrieval)
         (Vector + Keyword Search)
                       │
                       ▼
                Top 50 Documents
                       │
                       ▼
                     重排序(Rerank)
                       │
                       ▼
                 Top 5 Documents
                       │
                       ▼
              上下文压缩(Context Compression)
                       │
                       ▼
                       LLM
                       │
                       ▼
                     Answer

五、Agentic RAG

之前的文章中我向大家介绍了为什么Agent能够比LLM有更好的生成效果，其中Agent有一个重要的能力就是会搜集补充信息，和RAG相结合流程变成：

User Question
      │
      ▼
     Agent
      │
      ├─ Retrieval
      │
      ├─ Reasoning
      │
      ├─ Retrieval
      │
      ▼
    Final Answer

这种方式支持：

复杂问题拆解
动态检索

Agent自主搜集信息的能力再加上RAG就能产生更好的生成结果。

---

本文是本系列的第三篇内容，后端我会和大家分享内容安全，多模态Agent构建，文件系统等领域的实践，感兴趣点个赞吧。