作者：Lei阅读 --

别把向量数据库当知识库：RAG、Agent 记忆和知识库的一条主线

用一条“外部知识如何进入模型上下文”的主线，拆清向量数据库、RAG、Agent 知识库、Agent 记忆、Embedding、Retriever、Reranker、GraphRAG、BookRAG、A-RAG 等概念分别在系统里负责什么。

AIRAGAgent记忆

这几个词最容易被混成一锅粥：向量数据库、RAG、Agent 知识库、Agent 记忆、Embedding、Retriever、Reranker、GraphRAG、BookRAG、A-RAG/Agentic RAG、Adaptive RAG、长上下文、知识图谱、上下文工程。它们不是同一层东西，也不是互相替代的竞品。它们围绕的是同一个核心问题：模型这一次回答/行动时，应该把哪些外部信息放进上下文？

一句话主线

LLM 自己的参数记忆是“脑子里学过的大概世界”；RAG 和 Agent 记忆是在运行时把外部事实搬进当前上下文；向量数据库只是其中一种高效找相似内容的仓库；知识库是被治理过的资料系统；Agent 记忆是会随交互更新的个人化/任务化知识。

你只要抓住“外部知识进入上下文”这条线，概念就不会乱。

flowchart LR
  A[原始资料/交互记录] --> B[解析、清洗、切分]
  B --> C[Embedding / 关键词 / 层级 / 实体关系]
  C --> D[索引层：向量库、倒排索引、目录树、图数据库]
  D --> E[Retriever / Agent 召回候选]
  E --> F[Reranker / 过滤 / 权限]
  F --> G[上下文组装]
  G --> H[LLM 回答或 Agent 行动]
  H --> I[记忆写入：事实、经验、规则]
  I --> D

这张图里，每个热词只占一个位置。

先补一点向量直觉

“向量”不用想复杂，先把它当成一组坐标。

比如有三段话：

  • A：怎么申请报销？
  • B：员工差旅费用如何走报销流程？
  • C：今天晚饭吃什么？

Embedding 模型会把每段文字变成一串数字。数字本身人看不懂，但它们在空间里的距离有意义：A 和 B 的位置会更近，A 和 C 的位置会更远。

最小例子可以想成二维坐标：

文本“报销相关”“餐饮闲聊”
A0.90.1
B0.80.2
C0.10.9

当用户问“差旅票据怎么处理”，系统把问题也变成坐标，再找离它最近的资料。真实系统不是二维，而是几百到几千维。相似度也通常不是肉眼看表，而是用余弦距离、内积、L2 距离这类度量。

关键点：Embedding 不是知识库，它只是把内容变成适合搜索的形状。

Google 的 Embeddings 课程把 embedding 解释为把高维稀疏特征翻译成低维空间，便于模型处理；Cohere 文档也把 embedding 说成把文本转成数值数据，用来做相似搜索。这两个说法都指向同一件事：把“语义”变成“可计算的距离”。

把几个核心词放回各自位置

1. 向量数据库：负责“存向量、按相似度快速找”

向量数据库干的事很窄：存 embedding、建索引、按距离找最近的内容，并支持元数据过滤、更新、删除、扩容、权限等工程能力。

代表：

类型代表适合记法
托管向量数据库Pinecone面向生产 AI 检索的托管服务
开源/云原生向量库Milvus, Weaviate, Qdrant大规模向量搜索、过滤、混合检索
开发友好/本地原型Chroma快速把 embedding 检索跑起来
传统数据库扩展pgvector直接在 Postgres 里做向量相似搜索

它们解决的是“怎么找得快、找得稳、找得可运维”。但它们通常不负责判断文档是否可信、该不该写入、权限如何解释、答案怎么组织。

所以不要说“我做了一个向量数据库，所以我有 RAG 了”。准确说法是：我有了 RAG 里的一个可能索引后端。

2. 知识库：负责“哪些资料算数，以及怎么被治理”

知识库比向量数据库大一圈。它关心的是：

  • 资料从哪里来：PDF、网页、Confluence、Notion、S3、数据库、客服记录。
  • 资料是否可信：版本、来源、作者、更新时间、权限。
  • 怎么处理资料：解析、清洗、切块、去重、加 metadata。
  • 怎么检索资料：关键词、向量、混合搜索、图关系、过滤、重排。
  • 怎么证明答案：引用、出处、命中片段、审计日志。

代表：

类型代表适合记法
云厂商托管知识库Amazon Bedrock Knowledge Bases托管 RAG，把数据源、向量存储、检索、生成串起来
应用平台知识库Dify Knowledge给 AI 应用接入私有资料
开发框架数据层LlamaIndex面向文档摄取、索引、查询的 RAG 数据框架

一句话：向量数据库是仓库的一种货架；知识库是带来源、权限、清洗、检索策略和审计的资料系统。

3. RAG：负责“问的时候先查，再带证据生成”

RAG 是 Retrieval-Augmented Generation，检索增强生成。它不是某个数据库，也不是某个框架，而是一种运行时模式：

  1. 用户提问。
  2. 系统用问题去知识源里检索相关内容。
  3. 把检索结果放进 prompt/context。
  4. LLM 基于这些证据回答。

Lewis 等人的 RAG 论文把它描述成把参数记忆和非参数记忆结合起来：模型参数里有通用语言能力，外部索引里放可更新的知识。

这句话非常重要：

RAG 不是让模型“记住”新知识，而是在回答这一刻把外部知识“带进考场”。

代表：

类型代表适合记法
RAG/Agent 编排LangChain Retrieval, Haystack把加载、检索、重排、生成做成管道或组件
RAG 数据框架LlamaIndex更强调数据接入、索引、查询接口
图增强 RAGMicrosoft GraphRAG用知识图谱处理复杂关系和全局总结类问题
结构化/智能化 RAGBookRAG, A-RAG, Adaptive RAG修正 naive RAG 的固定切块、固定召回和固定流程

如果一个系统只把文档塞进长 prompt，而没有检索，也可以回答，但它不是典型 RAG；如果只做相似搜索但不让 LLM 基于结果生成，也只是语义搜索。

4. Retriever 和 Reranker：负责“先多捞，再精排”

生产 RAG 很少只做一次“向量最相似 top 5”。更常见的是两段：

  • Retriever：先尽量把可能相关的材料捞出来，追求召回率。
  • Reranker：再用更贵但更准的模型重新排序，追求精度。

LangChain 的 retriever 文档强调，retriever 是“给一个非结构化查询，返回文档”的接口；它可以由向量库构成，但不等于向量库。Cohere 的 Rerank 文档则把 reranker 放在候选文档之后，用来输出更准确的相关性排序。

为什么需要两段？因为第一段要快，第二段要准。向量搜索可能把“语义像但不回答问题”的段落捞出来；reranker 会更细地比较“这个段落是否真的回答这个问题”。

5. 混合检索：负责“语义相似 + 精确命中”

纯向量检索擅长同义改写：

  • 用户问：“怎么请年假？”
  • 文档写：“员工带薪休假申请流程。”

但它可能不擅长精确符号：

  • 报错码：E-1027
  • 产品型号：KGP-PAY-VA-01
  • 合同条款：Section 4.2

所以很多系统会把向量检索和关键词/BM25 检索合起来，再做融合排序。Weaviate、Qdrant、Chroma 等都在强调 hybrid search 或多种搜索能力。生产经验上，只要资料里有代码、型号、姓名、条款、票据号，混合检索就很重要。

6. GraphRAG / BookRAG / A-RAG：负责“别把资料拍平成一堆 chunk”

到这里，naive RAG 的问题已经很清楚：它默认“资料是一堆平铺片段，用户问题只需要一次 top-k 检索”。真实资料不是这样。

一本书有章、节、段落；一份制度有总则、例外、附录；一个客户案例有公司、合同、联系人、投诉、时间线；一次复杂问答可能要先搜关键词，再读章节，再沿实体关系追一跳。于是 RAG 开始往四个方向升级：

分支它修正 naive RAG 的哪条假设一句话记法
GraphRAG资料不只是片段，还有实体、关系、社区和全局结构按“关系路径”找证据
BookRAG长文档不是平铺文本，而是天然有目录层级按“目录树 + 实体图”找证据
A-RAG / Agentic RAG检索流程不该写死，模型可以自己决定下一步查什么按“搜索动作路径”找证据
Adaptive RAG / ARAG不是每个问题都需要同样深度的检索按“问题复杂度”分配检索预算

所以，把 BookRAG 和 A-RAG 直接理解成“更合理的 GraphRAG”不够准确。更好的上位概念是：结构化检索或检索规划。

GraphRAG 的结构来自实体关系图；BookRAG 的结构来自文档目录树和实体图的绑定；A-RAG 的结构来自 Agent 可调用的多粒度检索工具；Adaptive RAG 的结构来自“先判断问题需不需要检索、需要几轮、需要多深”的策略选择。

你刚才说的“最小化路径、最优路径获取精准知识”是一个很好的直觉，但这里的“路径”不一定是图算法里的最短路径。更准确地说，它追求的是：

用最少的无关上下文、最少的无效检索步骤，拿到足够支撑回答的证据。

这条证据路径可能是：

  • 目录路径：书 → 章 → 节 → 段落；
  • 关系路径：客户 → 合同 → 投诉 → 风险事件；
  • 动作路径：关键词搜 → 读 chunk → 语义搜 → 重排；
  • 预算路径：简单问题不查，长尾问题查，复杂问题多轮查。

一句话：这些新 RAG 分支不是都在变成 GraphRAG，而是在反对同一个粗糙默认值：把一切资料拍平成 chunk，然后一次 top-k 定生死。

7. Agent 知识库：负责“Agent 可调用的领域资料”

Agent 知识库本质上还是知识库，但使用者从“普通聊天机器人”变成了“会规划、会调用工具、会执行步骤的 Agent”。

差别在于：

  • 普通 RAG：问一次，查一次，答一次。
  • Agent + 知识库：Agent 在多步任务中决定什么时候查、查哪个库、查完是否继续调用工具。

比如一个报销 Agent 不只是回答“差旅标准是多少”，它还会：

  1. 查制度知识库。
  2. 查员工所在城市和职级。
  3. 判断票据是否缺失。
  4. 调用报销系统创建草稿。
  5. 把执行过程和待办写回任务状态。

这时知识库是 Agent 的一个工具，而不是全部系统。

8. Agent 记忆：负责“把交互中产生的新事实沉淀下来”

Agent 记忆和知识库最容易混。我的区分是：

知识库主要回答“世界/公司/领域里本来就存在什么”；记忆主要回答“这个用户、这个任务、这个 Agent 过去发生过什么，以及以后应该怎么做”。

LangChain 的 memory 文档沿用人类记忆分类：semantic memory 记事实，episodic memory 记经历，procedural memory 记规则。放到 Agent 里，可以这样理解：

记忆类型记什么例子
短期/工作记忆当前对话、当前计划、当前中间结果“我正在帮用户写博客，已完成资料检索”
语义记忆稳定事实和偏好“Lei 喜欢先搞清底层逻辑，再看代表工具”
情节记忆曾经发生过的任务轨迹“上次调试 Mermaid 渲染时，是测试脚本先暴露问题”
程序记忆做事规则和技能“发布博客前要跑 validate、site-ops、mermaid、build”

代表：

类型代表适合记法
框架内记忆LangGraph/LangMem给 Agent 提供长期记忆、提示优化、存储集成
独立记忆层Mem0面向 Agent/App 的持久记忆层
图记忆Zep / Graphiti用带时间的知识图谱组织 Agent 记忆
状态化 AgentLetta / MemGPT把上下文窗口看成有限资源，做分层记忆管理

这里有一个很重要的反直觉点：Agent 记忆不是“把聊天记录全塞进向量库”。

那样会产生三个问题：

  • 噪声越来越多：每句话都被当成同等重要事实。
  • 旧事实覆盖不了新事实：用户以前说“我用 Python”，后来改用 TypeScript，系统可能同时捞出两条。
  • 错误会复读：一次错误经验被记住后，未来相似任务会重复这个错误。

所以好的记忆系统要有“写入策略”：什么值得记、记成什么结构、什么时候过期、冲突时谁优先、错误经验怎么删除。

一条更强的内在逻辑：上下文预算管理

现在把所有概念压成一条主线：

LLM 每次真正能使用的，不是“所有知识”，而是“当前上下文窗口里的知识”。

于是所有系统都在争夺同一个目标：用有限上下文承载最有用的证据。

层次解决的问题典型组件
知识生产哪些资料值得进系统文档、网页、数据库、业务事件、聊天记录
知识表示怎么让机器能找embedding、关键词、实体、关系、metadata
知识存储怎么存和索引向量库、搜索引擎、图数据库、对象存储、Postgres
知识召回怎么先找到候选retriever、query rewrite、hybrid search、GraphRAG、BookRAG
检索规划要不要查、查几轮、查到什么粒度Adaptive RAG、Agentic RAG、A-RAG
知识排序怎么把最相关的排前面reranker、过滤、权限、时间衰减
上下文组装怎么塞进模型输入prompt template、引用、摘要、压缩、去重
生成/行动怎么回答或执行LLM、Agent loop、工具调用
记忆更新哪些新事实要沉淀memory writer、reflection、fact extraction、delete/update
质量控制怎么知道有没有用eval、命中率、引用准确率、人工反馈、日志

这就是我会选择的核心理解框架：不要按产品名记，按“上下文预算管理”记。

向量数据库回答“我怎么快速找到相似片段”；RAG 回答“我怎么把找到的片段变成有证据的回答”；知识库回答“哪些片段可被信任和引用”；Agent 记忆回答“哪些交互经验要影响未来”；GraphRAG 回答“当片段不够、关系更重要时，怎么按实体和社区组织知识”；BookRAG 回答“当文档本身有目录层级时，怎么别把层级打碎”；A-RAG/Adaptive RAG 回答“检索流程和检索预算能不能让模型动态决定”。

用一个报销 Agent 例子串起来

假设你要做一个公司报销 Agent。用户问：

我下周去新加坡见客户，机票和住宿标准怎么算？上次我说过我偏好靠近会场的酒店。

这句话里其实混了三类信息。

第一类是公司制度：差旅标准、城市等级、职级额度、审批流程。这应该来自知识库，资料源可能是公司制度 PDF、HR Wiki、财务系统配置。

第二类是语义搜索：用户没说“差旅政策 v3.2 第四条”，只说“机票和住宿标准”。系统要用 embedding 和检索，把相关条款找出来。这一步可能用向量数据库，也可能加 BM25，因为“新加坡”“职级”“住宿标准”这些词需要精确命中。

第三类是用户偏好：“偏好靠近会场的酒店”。这不是公司制度，而是用户过去交互里形成的Agent 记忆。它可能被记成结构化事实：

{
  "user": "Lei",
  "preference": "出差订酒店时优先靠近会场",
  "source": "conversation",
  "updatedAt": "2026-07-20"
}

Agent 真正回答前，应该组合两种证据：

  • 从知识库/RAG 找到“新加坡差旅标准”。
  • 从记忆库找到“用户订酒店偏好”。

最后回答时，模型上下文里应该有：

用户问题
+ 制度片段：新加坡/海外差旅/机票/住宿标准
+ 用户记忆：订酒店偏好靠近会场
+ 当前任务约束：只给建议，不直接下单，必要时确认日期和预算

这个例子说明一个关键点：RAG 和记忆不是替代关系，而是经常要一起进入上下文。

GraphRAG、BookRAG 和 Agentic RAG 什么时候上场？

普通 RAG 检索的是“片段”。但有些问题不是片段能直接解决的：

  • “这个客户过去三个月的所有投诉和续约风险有什么关系？”
  • “哪些团队在同一个项目里反复因为同类依赖阻塞？”
  • “这家公司内部政策的例外条款集中在哪些业务线？”

这类问题需要看实体、关系、时间和群组。GraphRAG 的思路是先从文本里抽取实体和关系，形成知识图谱，再用图结构辅助检索、总结和推理。Microsoft GraphRAG 文档强调，它用知识图谱改善复杂信息上的问答表现。

但不是所有“更聪明的 RAG”都该叫 GraphRAG。更细一点：

  • GraphRAG：问题横跨很多实体和关系，比如客户、合同、风险、团队、依赖链。
  • BookRAG：资料本身像书、手册、教材、制度汇编，有很强的章/节/小节层级。
  • Agentic RAG / A-RAG：问题需要边搜边判断，模型应该能自己选择关键词检索、语义检索、读 chunk、继续追问。
  • Adaptive RAG / ARAG：问题难度差异很大，系统应该先判断“要不要检索、检索多深”，而不是每次都跑同一条重流程。

简单判断：

  • 问“哪段文档回答这个问题”优先用普通 RAG。
  • 问“很多对象之间有什么关系和模式”考虑 GraphRAG/知识图谱。
  • 问“一本手册里的答案在哪个章节、哪个细粒度段落”考虑 BookRAG 这类层级文档 RAG。
  • 问“检索路线本身需要多轮探索”考虑 Agentic RAG/A-RAG。
  • 问“简单问题不想浪费检索成本，复杂问题又不能少查”考虑 Adaptive RAG/ARAG。
  • 问“用户过去发生过什么，且时间顺序重要”考虑带时间的 Agent 记忆，比如 Zep/Graphiti 这类方向。

长上下文会不会替代 RAG？

不会完全替代，但会改变边界。

长上下文让你能一次塞更多内容，减少检索复杂度。但它没有自动解决这些问题：

  • 哪些资料是最新版本？
  • 哪些资料用户有权限看？
  • 哪些片段应该引用？
  • 大量内容里哪些最相关？
  • 生成结果是否真的基于证据？
  • 旧记忆和新记忆冲突时谁赢？

所以长上下文更像“更大的工作台”，RAG/知识库/记忆是“怎么把正确材料拿上工作台”的方法。

常见误区

误区一：向量数据库 = 知识库。

不对。向量库只负责一种索引和搜索能力。知识库还要管来源、权限、版本、metadata、清洗、引用和质量。

误区二：RAG = Agent 记忆。

不对。RAG 通常偏读，读外部资料来回答当前问题；记忆还要写，且要处理长期演化、用户偏好、任务经验、冲突和遗忘。

误区三：把聊天记录 embedding 一下就是长期记忆。

这是最危险的简化。长期记忆应该是筛选、抽取、合并、更新后的结果，而不是无限增长的对话垃圾桶。

误区四：top-k 越大越好。

不一定。召回太多会挤占上下文，让模型在噪声里迷路。生产系统通常需要 query rewrite、metadata 过滤、rerank、摘要、去重和引用控制。

误区五：RAG 能保证不幻觉。

不能。RAG 只能给模型更好的证据入口。模型仍可能误读证据、忽略证据、过度推断。所以要做引用、答案评估、拒答策略和人工反馈闭环。

怎么选型：先问你到底缺哪一层

如果你只是想做“文档问答 demo”，选：

  • Chroma 或 pgvector；
  • 一个 embedding 模型；
  • LangChain 或 LlamaIndex；
  • 简单 top-k 检索。

如果你要做“公司内部知识助手”，重点不是换更贵的向量库，而是补：

  • 文档权限；
  • metadata；
  • 增量更新；
  • 混合检索；
  • reranker；
  • 引用和日志；
  • 离线评估集。

如果你要做“能长期陪用户工作的 Agent”，重点是：

  • 短期状态和长期记忆分开；
  • 用户事实、任务经历、行为规则分开；
  • 记忆写入要经过筛选；
  • 旧记忆可更新、可删除、可审计；
  • 记忆召回不能压过当前任务证据。

如果你要做“复杂关系分析”，再考虑：

  • 知识图谱；
  • GraphRAG；
  • 实体消歧；
  • 时间线；
  • 社区总结；
  • 图检索 + 向量检索的组合。

如果你要做“书、手册、制度、教材问答”，重点是：

  • 保留目录层级；
  • 让 chunk 能回到章、节、标题；
  • 抽实体关系但不要丢掉文档结构；
  • 查询时先定位章节，再读细节；
  • BookRAG 这类“目录树 + 实体图 + Agent 查询”的思路会比纯向量 top-k 更贴近资料形态。

如果你要做“复杂问题自动探索”，重点是：

  • 把关键词检索、语义检索、chunk read 暴露成工具；
  • 允许 Agent 多轮改写查询；
  • 让系统能判断什么时候停止检索；
  • 用检索 token、命中证据、引用质量评估成本收益。

最后用四句话收束

  1. Embedding 是翻译器：把文本、图片、代码等变成可比较的数字。
  2. 向量数据库是索引仓库：让相似搜索变快、变稳、可扩展。
  3. RAG 是运行模式：每次回答前先检索，再把证据塞进上下文。
  4. Agent 记忆是可演化资产：把交互中值得复用的事实、经历和规则沉淀下来，影响未来任务。

真正的总开关只有一个：当前这次模型调用，应该带什么上下文？

能回答这个问题，你就能判断每个名词该放在哪里，也能判断一个系统到底缺的是向量库、知识库、检索策略、重排器、图谱，还是记忆写入规则。

自检问题

读完以后，可以用这几个问题检查自己是否真的懂了：

  • 如果我换掉 Pinecone 改用 pgvector，RAG 架构一定变了吗？
  • 如果我的 Agent 能查公司制度，但不会记住用户偏好，它有知识库还是有记忆？
  • 如果系统总是召回相似但不回答问题的片段，我该优先换向量库、调切块，还是加 reranker？
  • 如果问题需要跨几十份文档总结关系，为什么普通 top-k RAG 可能不够？
  • 如果资料是一整本手册，为什么“按目录先粗定位、再读小节”可能比直接向量搜段落更稳？
  • 如果一个问题很简单，为什么 Adaptive RAG 可能选择不检索？
  • 如果一条用户偏好后来改变了，记忆系统应该新增一条，还是更新/失效旧事实？

能把这些问题答清楚，这块概念就基本通了。

资料锚点