RAG 基础：让智能体拥有知识
大模型的知识停留在训练截止日，无法覆盖私有文档与实时数据。RAG（Retrieval-Augmented Generation，检索增强生成）的做法是：先到外部资料里检索相关内容，再把资料拼进提示词，让模型"看着资料回答"。智能体由此获得"查资料"的能力，而不是凭空编造。
为什么 Agent 需要 RAG
智能体常要回答公司制度、产品手册、用户手册等私有问题，这些不在模型训练数据里。硬答会幻觉，把整本手册塞进提示词又超窗口。RAG 只取"相关片段"，成本低、可更新、能标注出处，是生产环境的主流方案。
核心三步：嵌入、向量检索、拼接上下文
RAG 一句话流程：把文档切成块并转成向量存库；用户提问时把问题也转成向量，在库里找最接近的若干块；把命中的块拼进提示词交给模型。
流程五步
一个标准 RAG 管线通常走五步：
- 采集：收集中英文文档、网页、PDF；
- 清洗：去页眉页脚、去重、转纯文本；
- 分块：把长文切成适合检索的块；
- 嵌入入库：每块用嵌入模型转向量，存入向量库；
- 检索增强：查询时召回相关块，拼进提示词生成答案。
嵌入 Embedding 是什么
嵌入是把文本变成一串数字向量，语义相近的文本向量距离也近。"苹果好吃吗"与"苹果的口感"向量接近，与"苹果手机"则较远。嵌入模型与对话模型是两类模型，一般分开调用：
# 以 OpenAI 兼容接口为例
resp = client.embeddings.create(model="text-embedding-3-small", input=["北京天气"])
vec = resp.data[0].embedding # 一串浮点数，如 1536 维
print(len(vec))
# 输出：1536
分块 Chunking 的概念
文档要先切成小块再嵌入：块太大，检索定位不准且浪费 token；块太小，上下文不完整。常用策略是按标题/段落切分，或定长切分并留少量重叠（overlap）：
def chunk(text, size=500, overlap=50):
return [text[i : i + size] for i in range(0, len(text) - overlap, size - overlap)]
# 输出：得到若干 500 字左右、前后重叠 50 字的文本块
向量库选型
向量数据库负责"存向量 + 按相似度召回"，常见选型一句话概括：
| 工具 | 一句话定位 |
|---|---|
| Chroma | 轻量嵌入式，适合原型与小项目，pip 即装即用 |
| FAISS | Meta 开源的向量索引库，性能高，需自行管理元数据与持久化 |
| Milvus | 分布式向量数据库，支持海量数据与生产级部署 |
| pgvector | PostgreSQL 插件，让传统关系库顺带拥有向量检索能力 |
"检索增强"对 Agent 的三种用法
- 预取上下文：对话前先按用户问题检索，把资料随第一轮请求一起发给模型，实现简单；
- 检索即工具：把"搜索知识库"封装成函数调用工具，由模型自主决定何时搜、搜什么；
- 循环检索：模型先搜一轮，发现资料不足再改写查询继续搜，属于进阶的 Agentic RAG。
小结
RAG 让智能体从"背知识"变成"查知识"：文档分块后嵌入向量库，提问时召回相关块拼入上下文。三种用法中"检索即工具"最能发挥 Agent 主动性，将在后续章节展开。