向量数据库与 RAG 的基础认知

当 2023 年大家真正把大模型往业务里接时，很快就会撞上一堵墙：模型很强，但它并不知道你公司的资料、文档、规则和业务上下文。

RAG 开始火，就是因为它正好补这块短板。它本质上不是让模型“更聪明”，而是让模型在回答前先拿到更相关的外部知识。

为什么要先理解检索，再理解生成

RAG 这个词很容易让人把注意力放在“生成”上，但真正决定效果的，往往是前面的检索环节。

一条基础链路通常是：

1. 文档切分
2. 向量化
3. 检索相似片段
4. 把片段连同问题一起喂给模型

如果检索出来的上下文本身不对，后面的回答大概率也不会好。

向量数据库解决了什么

传统关键词检索当然有用，但在自然语言问答里，用户表达方式经常和原文不完全一致。向量检索的价值，就是把“语义相近”这件事纳入匹配逻辑。

这也是为什么 2023 年之后，向量数据库一下进入了很多工程团队的视野。

不要一开始就神化 RAG

RAG 很有用，但它并不是万能解法。它更适合：

• 问答知识库
• 帮助中心检索
• 文档辅助生成

不太适合：

• 强事务决策
• 没有稳定知识源的场景
• 完全实时变动但又没更新链路的数据

真正的工程难点在哪里

很多人以为难点是“选哪种向量数据库”，其实更难的是：

• 文档怎么切
• 元数据怎么组织
• 命中结果怎么重排
• 知识什么时候更新

这些问题决定了 RAG 是能长期维护，还是只能演示。

小结

2023 年 RAG 变热，不是因为它听起来高级，而是因为它确实解决了大模型与私有知识脱节的问题。先把它理解成“检索增强的回答链路”，再往里做工程细化，会更稳。