为什么 RAG 不等于向量数据库

前言

很多开发者第一次接触 RAG 时，会形成一个简单理解：

RAG = 向量数据库 + 大模型

这个理解不能说完全错误，但非常不完整。

向量数据库只是 RAG 系统中的一个组件。

真正的 RAG 系统包含：

• 数据处理
• 文档切分
• Embedding
• 检索
• 重排序
• 上下文构造
• 模型生成
• 引用溯源
• 结果评估
• 权限控制
• 成本优化

如果只把文档丢进向量数据库，然后让模型回答，很容易得到一个“看起来能用，但实际不稳定”的系统。

本文重点讲清楚：

为什么 RAG 不等于向量数据库，以及一个成熟 RAG 系统应该如何设计。

什么是 RAG？

RAG 全称是 Retrieval-Augmented Generation。

中文通常翻译为：

检索增强生成。

它的核心思想是：

在模型回答前，先从外部知识库中检索相关内容，再将检索结果作为上下文交给模型生成答案。

也就是说：

模型不是单纯依赖自身知识回答，而是结合外部资料回答。

基本流程：

用户问题
↓
检索系统
↓
召回相关文档
↓
构造上下文
↓
大模型生成回答

为什么需要 RAG？

大模型有几个天然限制。

1. 不知道私有数据

模型不知道企业内部文档、产品说明、项目代码、用户合同、历史工单。

这些数据必须外部提供。

2. 知识可能过时

模型训练数据有时间边界。

而业务知识每天都可能变化。

3. 容易幻觉

当模型不知道答案时，可能生成看似合理但实际错误的内容。

4. 上下文长度有限

不能把所有资料一次性塞进模型。

RAG 的作用就是解决这些问题。

它让模型在回答前先“查资料”。

向量数据库在 RAG 中扮演什么角色？

向量数据库主要负责：

根据用户问题，找到语义相近的文档片段

例如用户问：

如何配置 Nginx 支持 SSE？

向量数据库可能返回：

• Nginx 反向代理配置
• proxy_buffering off
• SSE 流式输出说明

这一步叫召回。

但召回只是 RAG 的一部分。

如果召回内容不准确，模型会回答错误。

如果召回内容准确但上下文拼接混乱，模型也可能回答错误。

如果没有权限过滤，还可能泄露数据。

所以 RAG 不只是向量检索。

一个完整 RAG 系统的组成

1. 数据接入层

数据来源可能包括：

• PDF
• Word
• Markdown
• HTML
• 数据库
• Notion
• Git 仓库
• API
• 客服工单

不同数据源需要不同解析方式。

PDF 可能存在表格、页眉、页脚、图片。

网页可能存在导航栏、广告、无关链接。

代码仓库需要保留目录结构。

如果数据接入阶段质量差，后面再强的模型也救不了。

2. 数据清洗层

原始数据通常不能直接进入知识库。

需要清洗：

• 删除广告
• 删除重复页脚
• 去掉无意义空行
• 修复乱码
• 合并断裂段落
• 保留标题层级
• 删除重复内容

例如很多 PDF 每页都有公司名称、页码、版权声明。

如果不清理，检索结果会充满噪音。

3. 文档切分层

Chunk 策略直接影响 RAG 效果。

常见错误是：

按固定长度硬切。

例如每 500 字切一段。

这种方式简单，但容易切断语义。

更好的方式是结合：

• 标题
• 段落
• 列表
• 语义边界
• 代码块
• 表格

例如技术文档可以按标题层级切：

一级标题
↓
二级标题
↓
正文内容

这样每个 chunk 更完整。

4. Embedding 层

Embedding 层负责将 chunk 转为向量。

需要注意：

• 选择合适的 Embedding 模型
• 保持模型版本一致
• 保存原文和 metadata
• 记录文档版本
• 支持重新索引

如果后期更换 Embedding 模型，旧向量和新向量不能随便混用。

否则检索效果可能变差。

5. 检索层

检索层不应该只有向量检索。

成熟系统通常采用混合检索：

向量检索
+
关键词检索
+
过滤条件

为什么？

因为不同问题适合不同检索方式。

语义类问题适合向量：

如何提升网站速度？

精确类问题适合关键词：

错误码 E1027 是什么意思？

权限类问题需要过滤：

只搜索当前用户有权限访问的文档

6. 重排序层

向量数据库返回的 top 10 不一定就是最适合给模型的 top 10。

因此常见做法是：

先召回较多内容。

例如 top 30。

再使用 reranker 重新排序。

最终选出 top 5。

重排序可以显著提升回答质量。

尤其在企业知识库、代码库问答中非常重要。

7. 上下文构造层

很多 RAG 系统失败在这一步。

即使召回内容正确，如果上下文拼接方式混乱，模型仍然可能回答不好。

上下文应包含：

• 明确的系统指令
• 用户问题
• 相关资料
• 资料来源
• 回答规则
• 不知道时如何处理

例如：

请只基于资料回答。
如果资料中没有答案，请明确说明无法确认。
不要编造不存在的信息。
回答后列出引用来源。

这类规则非常重要。

8. 生成层

生成层才是大模型发挥作用的地方。

但这里要注意：

RAG 系统不是让模型自由发挥。

而是让模型基于检索资料回答。

如果模型偏离资料，就会产生幻觉。

因此 Prompt 中应约束：

• 不要编造
• 不要使用资料外信息
• 不确定就说明不确定
• 引用对应来源

9. 引用溯源

一个好的 RAG 系统应该告诉用户：

答案来自哪里。

例如：

参考资料：
1. 《Nginx 配置手册》第 3 节
2. 《AI Chat 系统部署文档》第 5 节

没有引用来源的知识库回答，很难建立信任。

尤其在企业、法律、财务、医疗、技术文档场景中，溯源非常重要。

10. 结果评估

很多开发者做完 RAG 后，只凭感觉判断效果。

这是不够的。

应该建立评估集。

例如准备 100 个真实问题：

问题
标准答案
期望引用
难度等级

每次优化 chunk、embedding、rerank、prompt 后，都用同一批问题测试。

否则无法判断系统是否真的变好。

RAG 常见误区

误区一：文档越多越好

不是。

低质量文档越多，噪音越多。

RAG 更需要高质量知识库，而不是无限堆资料。

误区二：topK 越大越好

不是。

召回内容太多，会导致：

• 上下文变长
• 成本增加
• 噪音增加
• 模型注意力分散

通常需要根据场景测试。

不是固定 topK=10 就一定最好。

误区三：只要用了向量数据库就不会幻觉

错误。

如果检索不到答案，模型仍然可能编造。

因此必须在 Prompt 中明确：

资料中没有答案时，请回答无法确认。

同时最好增加置信度判断。

误区四：RAG 可以替代数据库查询

不可以。

如果用户问：

这个月订单总额是多少？

这不是向量检索问题。

应该查询数据库。

RAG 适合非结构化知识问答，不适合所有任务。

误区五：忽略更新机制

知识库不是一次导入就结束。

需要处理：

• 文档新增
• 文档修改
• 文档删除
• 版本更新
• 重新索引

否则用户可能查到过期答案。

成熟 RAG 系统推荐架构

数据源
↓
解析器
↓
清洗器
↓
Chunk 切分
↓
Embedding
↓
向量数据库
↓
关键词索引
↓
用户问题
↓
权限过滤
↓
混合检索
↓
重排序
↓
上下文构造
↓
大模型生成
↓
答案溯源
↓
日志与评估

这个流程看起来复杂，但每一层都有存在价值。

项目初期可以简化，但不能完全忽略。

如何从简单 RAG 演进到成熟 RAG？

第一阶段：简单版本

适合个人项目。

Markdown 文档
↓
Chunk
↓
Embedding
↓
向量检索
↓
大模型回答

先跑通流程。

第二阶段：增强检索

增加：

• metadata
• 权限过滤
• 关键词搜索
• topK 调整

提高准确率。

第三阶段：引入重排序

使用 reranker 提升召回质量。

尤其适合文档较多的系统。

第四阶段：增加评估集

用真实问题测试。

不要凭感觉优化。

第五阶段：生产化

加入：

• 日志
• 缓存
• 限流
• 成本统计
• 版本管理
• 异常处理

这时才算接近可长期运行的 RAG 系统。

总结

RAG 不等于向量数据库。

向量数据库只是 RAG 的检索组件之一。

真正的 RAG 系统是一整套工程体系。

它包括：

• 数据处理
• 检索策略
• 上下文构造
• 模型生成
• 权限控制
• 引用溯源
• 效果评估
• 成本控制

如果只关注向量数据库，很容易做出一个演示效果不错，但真实使用不稳定的系统。

一个可靠的 RAG 系统，核心不是“把文档存进去”，而是“让模型在正确的时间，用正确的资料，给出可验证的回答”。