向量数据库

你想给 Agent 加"记忆",打开教程,第一步就是:装个向量数据库,选个嵌入模型,写分块逻辑。 我见过太多团队这么干,然后卡在"为什么它检索出来的东西牛头不对马嘴"上,卡好几周。 这里有个反常识的事实:2026 年真正在干活的 Agent——Claude Code、Cursor、Devin——它们理解你的代码库,靠的是 grep、读文件树、find,不是向量库。一个能调试整个工程的 Agent 都不需要语义检索,你那个客服机器人凭什么需要? 记忆不是一个"功能",是一条演进路径。绝大多数 Agent 走到第二级、第三级就够用了一辈子。向量库是这条路的终点,不是起点——而且很多人这辈子都到不了终点,也不需要到。 这条路长什么样 flowchart TD A[对话历史窗口原始消息全塞进 prompt] -->|上下文要满了| B[摘要压缩把旧消息缩成几句话] B -->|要记的事多且结构清晰| C[结构化记忆用户画像 / 事实表键值或 SQL] C -->|要回忆的东西多又模糊| D[向量检索嵌入 + 语义搜索] style A fill:#d6f5d6,stroke:#3c9e3c style B fill:#fdf3c2,stroke:#e8c83c style C fill:#fde7c2,stroke:#e8b23c style D fill:#f5d6d6,stroke:#c23c3c 绿色那级,90% 的 Agent 起步就够用。每往下一级,复杂度都明显涨一档。升级的触发条件很具体,不是"感觉该升了"就升。 下面一级一级讲。 第一级:对话历史窗口,够用就别折腾 最朴素的记忆:把这轮对话的所有消息,原封不动塞进 prompt。用户说一句、Agent 答一句,全在上下文里。 听起来太简单了,简单到不像"记忆系统"。但你得算一笔账:2026 年主流模型的上下文窗口普遍 20 万 token 起步,长的到 100 万。一轮普通的客服对话、一次代码调试会话、一场旅行规划,撑死了几千到几万 token。整段对话原样塞进去,窗口连一半都用不满。 这一级的好处不只是简单: 零信息损失。模型看到的是逐字原文,不是被你提炼过、可能丢了关键细节的二手货。 零检索错误。没有检索这一步,就没有"该召回的没召回"“召回一堆噪音"这类问题。 零额外基础设施。不用嵌入服务,不用向量库,不用同步任务。 什么时候该往下走?只有一个信号:上下文真的要满了。 不是"对话有点长了”,是你把 token 数打出来,发现已经吃掉窗口的 60%~70%,再聊下去要溢出。在那之前,任何"我们是不是该上个记忆框架"的讨论都是过早优化。 ...

三年前做一个带检索的 AI 功能,默认动作是去注册一个 Pinecone,或者在 k8s 上拉起一套 Milvus。“做向量检索就得有向量数据库”,这是当时的常识。 2026 年我不会这么干了。我现在的默认动作是反问一句:你的业务数据是不是已经在 Postgres 里了? 如果是,那大概率你不需要再多一个数据库——装个 pgvector 扩展就够了。 这不是图省事。这两年向量检索这个领域发生了一件挺反常识的事:专用向量数据库的护城河,被"在已有数据库里加一个向量列"这件事填掉了一大半。 这篇就讲清楚这件事是怎么发生的,以及——什么场景下你还是真的需要一个专用的。 向量检索这两年变了什么 先说结论:向量检索从"一项需要专门系统的黑科技",退化成了"一种索引类型"。 2022、2023 年的时候,向量检索确实特殊。HNSW 索引怎么建、近似最近邻(ANN)怎么调参、召回率和延迟怎么权衡,这些都是新东西,通用数据库根本不支持。你想做语义检索,除了上专用向量库没有别的选择。专用向量库的价值,很大程度上来自于"别人还做不了"。 到 2026 年,情况倒过来了。HNSW 这种图索引已经是成熟、公开、被反复实现的算法,不再是谁家的秘密。pgvector 作为 Postgres 扩展,把 HNSW 和 IVFFlat 索引、多种距离度量、半精度存储这些都做齐了;0.8 版本之后还补上了"迭代索引扫描"(iterative index scan),专门解决带过滤的向量查询里那个老大难问题——后面会细讲。 换句话说,“做向量检索"这件事本身,已经不构成开一个新数据库的理由了。 它现在更像是"我需要一个 JSON 字段"或者"我需要全文检索”——你的现有数据库基本都能干,只是早几年还不行。 专用向量库不是没价值了,而是价值的位置变了:它不再赢在"能不能做",而是赢在"做到什么规模、做得多快、过滤多复杂"。这是一个量变到质变的边界问题,而不是一个有无问题。 pgvector 为什么吃掉了大半场景 把向量检索塞进 Postgres,带来的好处不是"少装一个软件"这么肤浅。真正值钱的是下面三件事。 第一,数据不用搬,事务是一致的。 绝大多数 AI 功能不是孤立的——一段文档的 embedding,总是挂在某个用户、某个项目、某个权限边界下面。如果向量在专用库、业务数据在 Postgres,你就得自己维护两套数据的同步:文档删了,向量要跟着删;权限变了,检索结果要跟着变。这套同步逻辑写起来不难,但它是一类永远会出 bug 的胶水代码——双写失败、顺序错乱、补偿任务追不上。向量和业务数据待在同一个 Postgres 事务里,这一整类问题直接不存在。 第二,过滤就是普通的 SQL WHERE。 “找语义相近的文档,但限定这个用户、这个时间段、状态是已发布”——这种带元数据过滤的检索是 RAG 里的常态,几乎没有哪个真实业务是纯粹的全库 ANN。在 pgvector 里,这就是一条 SQL,WHERE 子句和向量排序写在一起,还能直接 JOIN 业务表。在专用向量库里,过滤得靠它自己那套 payload/metadata 过滤机制,表达能力通常比 SQL 弱,跨"表"的关联更是做不了。 ...

RAG是什么 一句话：先查资料，再回答问题。 大模型直接回答问题容易编造内容。RAG让它先从你的知识库里找到相关内容，再基于这些内容回答。 1 用户问题 → 搜索知识库 → 找到相关文档 → 喂给LLM → 生成答案 最简实现 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 from langchain.vectorstores import Chroma from langchain.embeddings import OpenAIEmbeddings from langchain.chat_models import ChatOpenAI # 1. 把文档切块并存入向量数据库 docs = load_and_split_documents("./docs") vectorstore = Chroma.from_documents(docs, OpenAIEmbeddings()) # 2. 检索相关内容 retriever = vectorstore.as_retriever(k=3) relevant_docs = retriever.get_relevant_documents("什么是RAG？") # 3. 生成答案 llm = ChatOpenAI() answer = llm.invoke(f""" 根据以下内容回答问题： {relevant_docs} 问题：什么是RAG？ """) 就这么简单。30行代码就能跑起来。 ...