RAG（检索增强生成）— 知识整合

整合自 12 篇小红书帖子 | 整合时间：2026-04-25

概述

RAG（Retrieval-Augmented Generation，检索增强生成）是一种让大语言模型"带着小抄去考试"的技术——先从外部知识库检索相关资料，再将资料与用户问题一起交给大模型生成答案。它解决的是大模型知识过时、上下文有限、私有数据缺失三大痛点。

然而，RAG 在生产环境中远非万能。当文档量从几百涨到几万，检索准确性急剧下降；简单的向量相似度搜索在需要精确匹配的场景下表现糟糕；"RAG 已死"的争论在社区中持续发酵，Agent + 文件系统的方案正在挑战传统 RAG 的地位。

核心概念

什么是 RAG

RAG 的核心思路：先检索，再生成。它不是训练新模型，而是在推理时为模型提供外部知识。

大模型的三大短板，RAG 逐一应对：

• 上下文有限：DeepSeek-R1 满血版上下文上限 128K tokens，不能无限输入
• 知识过时：训练数据截止后的新知识，模型一概不知
• 私有数据缺失：企业内部文档、专业知识模型从未见过

RAG 的完整工作流程

RAG 的流程可以分为三大阶段：

1. 索引阶段（离线）

• 文本分块（Chunking）：将长文档切分成较小的段落。方式包括按段落、句子数量、固定字数等
• 向量化（Embedding）：每个 chunk 通过 embedding 模型转化为向量，用数字表达语义
• 构建索引：将向量存入向量数据库（如 Qdrant、Chroma、Milvus）

2. 检索阶段（在线）

• 用户问题同样通过 embedding 转为向量
• 与数据库中的向量匹配，选出 top-k 个最相关的 chunk
• 可选：使用 Reranking 模型对初步结果重新排序

3. 生成阶段

• 将精选 chunk 与用户问题拼成完整提示词
• 交给大模型生成最终答案

关键组件

深度解析

检索层：RAG 的命门

多篇帖子一致指出，RAG 系统的核心问题不在生成层，而在检索层。

文档量增长后的召回衰退：当文档从几百篇涨到几万篇，高维向量空间从稀疏变为稠密，召回率迅速下降。语义接近但不相关的内容会被错误召回。

纯向量检索的可靠性问题：单纯依赖向量相似度的检索在需要精确匹配的场景下表现很差。评论中有人指出"生产环境检索的时候，单纯向量检索的可靠性太差了，面对必须准确检索的场景，就见了鬼了"。

Embedding 的语义偏差：像"我喜欢音乐"与"我以前喜欢音乐"，人类觉得含义不同，但向量可能非常接近。私有词汇（企业专有术语）在通用 embedding 模型中没有有效表示，导致生成的向量是分离的，检索结果混乱。

混合检索与 Reranking

社区推荐的检索架构演进路线：

1. 基础方案：纯向量检索（embedding 语义匹配）
2. 进阶方案：混合检索 = embedding 语义匹配 + BM25 关键词匹配，用 RRF（Reciprocal Rank Fusion）融合
3. 高阶方案：混合检索 + Reranker 深度语义匹配

评论中有人实践后建议："先用 RRF 做混合检索，如果还有需求再套 reranker 做深度语义匹配"。

RAG 的 MoE 思路

高赞评论提出：RAG 也需要做 MoE（混合专家）。核心思路：

• 将知识库按元数据做标签分离（领域/部门/文档类型）
• 在意图路由节点识别问题意图，改写 query
• 不同领域分别召回，最后去重和重排

本质上是上下文工程——不是一股脑塞给模型，而是精细化地选择"喂什么"。

Chunking 的艺术

Chunking 是 RAG 中最容易被忽视但影响最大的环节：

• 太短：信息零散，上下文丢失
• 太长：语义不集中，向量匹配不准
• 切分不当：破坏上下文语义完整性，导致指代混乱、逻辑断裂

推荐做法：从大到小构建标签，在观点级抽取合适的文档，在文档级抽取合适的章节和段落，最后再重排。

RAG 不擅长的场景

多篇帖子明确指出 RAG 的局限：

• 全局理解任务：问"这篇文档的核心观点是什么？"——把 100 段拆分后模型只看 5 段，无法理解全貌
• 细粒度精确查询：如产品 BOM 清单、代码引用，RAG 表现很差
• 统计与聚合：RAG 的原理决定了不适合做统计和高层级总结
• 超长 Prompt 的注意力丢失：塞入过多上下文导致大模型注意力涣散

简历优化：别只写"熟悉 RAG"

面试视角的提醒：简历上不能只写"熟悉 RAG"，要具体写明优化方向：

• Chunking 策略优化
• 混合检索（向量 + BM25）
• Reranking 重排
• Query 改写/扩展
• 意图路由与多库检索
• 上下文窗口管理

不同观点与争议

[争议] RAG 已死？

正方观点（RAG 将被替代）：

• Claude Code 放弃了 RAG，转而让 Agent 直接操作文件系统
• Agent + grep/glob/正则匹配，让模型自己决定看哪几行，比预检索更灵活
• 传统"一搜一答"的 RAG 太简单，工业级需求远远超出
• 长上下文模型（百万 token 级别）可能让 RAG 不再必要

反方观点（RAG 仍有价值）：

• Agent 也有幻觉，也会抓取错误数据
• 把全文档塞给模型的 token 成本和耗时不可接受
• "grep 能解决扫描完整文档所有语义的工作？"——Agent 不能替代语义理解
• 工业级 RAG 远不止简单向量检索，Agent 和 RAG 可以结合
• 长上下文 ≠ 注意力有效，塞入越多上下文，注意力越容易溃散

社区共识：不是 RAG 死了，而是"简单的 RAG"不够用了。未来的方向是 Agentic RAG——让 Agent 动态决定何时检索、检索什么、如何组合。

[争议] GraphRAG 是救星吗？

有人建议用 GraphRAG 解决传统 RAG 的全局理解问题。但质疑者指出：

• GraphRAG 底层节点检索依然依赖向量相似度模型
• 成本高昂：每问一个问题就要跑一遍文档，token 消耗巨大
• 适合特定场景（如知识图谱完善的企业），不是通用方案

实践要点

入门学习路线

1. HelloAgent：了解大体架构
2. All in RAG：学习 RAG 常用方法思路
3. 动手做项目，遇到疑惑再深入学习
4. 参考优秀开源项目

生产环境 RAG 优化清单

1. 数据清洗：垃圾进，垃圾出——这是最容易被忽略的环节
2. Query 改写：让大模型先把用户问题扩展成更具体的子问题，再用子问题去检索
3. 意图路由：不同类型问题走不同检索路径，建不同的专业库
4. 混合检索：向量语义 + BM25 关键词，用 RRF 融合
5. Reranking：召回后加一层精排，选择最贴近意图的 chunk
6. K 值取舍：top-k 默认 5，在覆盖率和不引入噪声之间取舍
7. 分层架构：复杂任务拆成多层，一层判断合法，一层计算结果——不要把所有逻辑塞进一个 Prompt
8. Embedding 微调：私有词汇多时，考虑微调 embedding 模型
9. 工具选择：Faiss→Milvus（规模化阶段）、RAGFlow（开箱即用方案）

多模态内容处理

文档中的图片、表格、流程图：

• 用 OCR 抽取图片文字
• 用多模态模型理解图像内容
• 表格可转为 JSON 格式再处理
• LangChain 集成了不少文档预处理工具

本内容由 KnowledgeMine 自动整合，仅供参考