向量数据库：别把相似搜索当成可信答案

今天先记住

向量数据库（Vector Database）在 Agent 系统里不是“记忆大脑”，而是 RAG 的检索货架：它负责把资料片段、向量、来源、时间、权限等信息放在一起，让 Agent 能按语义相似度取候选材料。真正能不能回答，还要看过滤、排序、重排和使用证据的方式。

它在大地图里的位置

还是这条链路：

txt

用户目标
  -> 上下文 / 记忆
  -> 规划 / 决策
  -> 工具调用 / 外部系统
  -> 执行 / 观察结果
  -> 评估 / 修正
  -> 最终输出

前两天讲 RAG 和 Embedding。今天把镜头再往工程层落一点：Embedding 把文本变成语义坐标，向量数据库负责存这些坐标，并在查询时找出“距离近”的片段。

所以它位于“上下文 / 记忆”进入模型之前。它不替模型思考，也不替系统判断权限；它只决定哪些材料有资格进入下一步。

它到底是什么

最小的向量数据库可以理解成三列数据：

文档片段：比如一段 Markdown、一次任务摘要、一条接口说明。
向量：这段文字的语义坐标。
元数据：文件路径、日期、标题、用户、权限、来源类型、版本号。

查询时，系统先把用户问题转成向量，再找相近片段。但工程上不能只看“相似”。如果用户问“今天的课程下一篇写什么”，相似度可能命中很多旧课；真正可用的结果还要按日期、目录、发布规则过滤，再按主题连续性排序。

为什么 Agent 里会用到它

Agent 经常需要在大量外部资料里临时找依据：项目文档、代码说明、用户长期记忆、任务日志、历史课程。全部塞进 prompt 会挤爆上下文；每次纯关键词搜索又容易漏掉同义表达。

向量数据库的价值，是把“语义找回”和“结构化边界”放到同一层。比如找“工具调用失败后怎么办”，语义搜索能命中“重试、回滚、错误中间件”；元数据过滤能排除旧版本文档、无权限记录和不属于当前项目的笔记。

它避免的具体失败不是抽象的“回答不准”，而是：取回过期规则、混用别人的记忆、把标题相似但主题不同的文章塞进上下文。

怎么判断它有没有用

如果资料量已经超过一次上下文能稳定容纳的范围，并且用户问法常常和资料写法不同，向量数据库有用。

如果你查的是精确 ID、文件名、订单号、配置 key，先用结构化查询或全文搜索，别硬上向量。

如果资料有时间、权限、项目归属，向量库必须存元数据并支持过滤；只返回 top-k 相似片段是不够的。

如果系统无法展示“命中了什么、为什么能用、哪些被过滤掉”，这个检索层就不可审计，也很难修错。

一个小例子

txt

Input:
用户说：“生成 2026-07-21 的 AI Agent Daily，接着上一课讲，不要重复。”

Process:
1. 系统查询 ai-agent 文档索引。
2. 向量相似度命中 RAG、Embedding、长期记忆几篇旧课。
3. 元数据过滤只保留 ai-agent 目录、日期早于 2026-07-21 的文章。
4. 按日期和框架顺序判断：上一课是 Embedding，今天应讲向量数据库。

Output:
选题变成“向量数据库”；
上下文只放入上一课标题、框架路径和少量相关片段；
不会把“长期记忆”误当成今天主线。

这个例子可以拿来判断真实系统：如果它只会返回“最相似的 5 段”，但不能按日期、目录、权限过滤，那它只是会找相似文字，还不是一个可用于 Agent 决策的检索层。

常见误区

以为向量数据库等于长期记忆。长期记忆是内容治理，向量数据库只是索引和检索基础设施。
以为 top-k 越大越稳。取回太多会把噪音塞进上下文，让模型忽略真正约束。
以为相似度分数就是可信度。相似只说明像，不说明新、不说明有权限、不说明适用于当前任务。
以为换更强 embedding 模型就能解决全部问题。切块、元数据、过滤和评估样本同样会决定效果。

今天自测

向量数据库和 Embedding 分别解决哪一步？
为什么 Agent 检索用户记忆时必须带权限和时间过滤？
如果 RAG 总是拿到相似但过期的资料，你会先改向量模型，还是先检查元数据过滤？

向量数据库：别把相似搜索当成可信答案 ​

今天先记住 ​

它在大地图里的位置 ​

它到底是什么 ​

为什么 Agent 里会用到它 ​

怎么判断它有没有用 ​

最近冒出来的词 ​

一个小例子 ​

常见误区 ​

今天自测 ​