当前位置：首页 > news >正文

RAG 是什么？为什么大模型需要外挂知识库？

news 2026/6/14 1:21:27

大模型很强。它会写代码，会总结，会分析，会对话。

但它有三个硬伤：不知道你的私有数据，训练知识会过期，上下文窗口也不是无限大。

RAG 就是为了解决这三个问题。它不是让模型重新训练一次，也不是把所有资料都塞给模型。它的核心动作很简单：回答之前，先去知识库里找资料。

RAG = 检索 + 生成。检索负责找依据，生成负责把依据说成人话。

一、为什么大模型需要外挂知识库？

先看一个真实场景。

你问模型：“我们公司 2026 年最新版报销制度里，差旅住宿标准是多少？”

模型如果没有接入你的内部制度文档，它只能猜。猜得再像，也不是答案。

这就是裸调模型的风险：回答流畅，不代表回答正确。

1. 模型知识会过期

大模型的训练数据通常有截止时间。训练之后发生的新政策、新公告、新产品文档，它天然不知道。

LangChain 官方 Retrieval 文档也明确指出，LLM 有两个关键限制：上下文有限，以及训练知识是静态的；Retrieval 通过在查询时获取外部知识来解决这些问题。

2. 模型不知道你的私有数据

企业真正有价值的数据，往往不在公开互联网里。比如：合同、制度、客服 FAQ、订单状态、研报库、内部知识库、产品手册、故障工单。

这些内容不能指望模型“天生知道”。必须在用户提问时动态检索。

3. 模型上下文不是无限大

就算你有 10 万页文档，也不能全部塞进 Prompt。上下文窗口再大，也不是数据库。

RAG 的做法是：只找和当前问题最相关的几段资料，把它们作为上下文交给模型。

二、RAG 的本质：不是训练模型，而是给模型递资料

很多人第一次听 RAG，会误以为它是微调模型。不是。

微调是改变模型参数。RAG 不改模型参数。RAG 是在模型回答前，把相关资料临时放进上下文。

这就像考试。微调是让学生重新学习。RAG 是允许学生开卷查资料。

三、LangChain 里的 RAG 组件地图

LangChain 做 RAG，不是一个神秘黑盒。它把整个流程拆成了一组小组件。

组件	作用	通俗理解
Document Loader	读取外部资料	PDF、网页、Word、Markdown、数据库
Document	标准文档对象	page_content、metadata、id
Text Splitter	切分长文档	把大文档切成可检索小块
Embedding	文本向量化	把文本变成数字向量
Vector Store	存储与相似度搜索	Milvus、Chroma、FAISS、Qdrant、ES Vector
Retriever	检索入口	输入问题，返回 Document 列表
Prompt	组织上下文	把问题和资料拼成模型输入
Model	生成答案	基于资料回答，而不是凭空编

四、RAG 的最小单位 Document

在 LangChain 里，RAG 不是直接处理“PDF 文件”。PDF、网页、Markdown、数据库记录，最后都要转换成 Document。

Document 是 RAG 里的最小知识单元。它一般代表一个文档片段，也就是我们常说的 Chunk。

源码里，Document 继承自 BaseMedia。BaseMedia 提供 id 和 metadata，Document 自己提供 page_content。

# 简化后的源码结构，不是完整源码
class BaseMedia:
id: str | None
metadata: dict
class Document(BaseMedia):
page_content: str
type: Literal["Document"] = "Document

这里要抓住一个核心点：Document 不是 Message。

Message 是模型对话里的消息。Document 是检索流水线里的资料。

这两个概念不能混。前面第四章讲过 Messages；这一章讲的是知识库里的 Document。

五、VectorStore 做了什么？

VectorStore 是向量数据库的统一抽象。

它的任务不是生成答案。它只负责两件事：存文档，搜相似文档。

从源码看，VectorStore 把 Document 拆成 texts 和 metadatas，再交给具体向量库实现。

# 简化后的源码逻辑
texts = [doc.page_content for doc in documents]
metadatas = [doc.metadata for doc in documents]
vectorstore.add_texts(texts, metadatas, ids=ids)

这一步很关键。

模型看的是文本，向量库搜的是向量，但工程系统追踪的是 metadata。

所以生产环境里，metadata 不能随便写。至少要有 source、page、title、doc_id、created_at、version 等字段。否则模型答错了，你根本追不回来源。

六、Retriever 为什么是 RAG 的核心入口？

Retriever 是 RAG 运行时的入口。

用户提问后，Retriever 接收 query，返回一组 Document。

LangChain 官方也把 Retriever 定义为：输入非结构化查询，输出 Document 列表。它比 Vector Store 更通用，因为它不一定自己存文档。

BaseRetriever 继承 RunnableSerializable，所以它天然支持 invoke、ainvoke、batch、abatch。

这就是 LangChain 的工程味道：Retriever 不是孤立工具函数，而是可组合、可追踪、可异步、可批处理的 Runnable。

# 简化后的源码执行链
result = retriever.invoke("用户问题")
# invoke 内部大致做三件事：
# 1. 准备 config / callbacks / metadata
# 2. 触发 on_retriever_start
# 3. 调用 _get_relevant_documents(query)
# 4. 触发 on_retriever_end，返回 List[Document]

所以自定义 Retriever 的核心不是重写 invoke，而是实现 _get_relevant_documents。

你可以把 ES 检索、数据库检索、API 搜索、图数据库检索、混合检索都封装成 Retriever。

七、VectorStoreRetriever 只是一个路由器

很多人以为 VectorStoreRetriever 很复杂。其实它的核心很直白。

VectorStore.as_retriever() 会返回一个 VectorStoreRetriever。这个对象保存了 vectorstore、search_type、search_kwargs。

源码里支持三类常用搜索方式：

similarity：普通相似度搜索，适合大多数基础 RAG。

similarity_score_threshold：带分数阈值，只保留超过相关度的结果。

mmr：最大边际相关性，既看相关性，也看结果之间的多样性。

# 简化后的源码逻辑
if search_type == "similarity":
docs = vectorstore.similarity_search(query, **kwargs)
elif search_type == "similarity_score_threshold":
docs = vectorstore.similarity_search_with_relevance_scores(query, **kwargs)
elif search_type == "mmr":
docs = vectorstore.max_marginal_relevance_search(query, **kwargs)

这段逻辑很短，但很重要。

RAG 的效果，很多时候不是模型不行，而是这里的参数没调好：k 太小，召回不全；k 太大，噪声太多；没有 filter，跨业务文档乱召回；没有阈值，低相关资料也进了 Prompt。