向量数据库在 RAG 中的作用

向量数据库解决的是 RAG 语义召回的问题。它负责保存向量和 payload，并把相似片段按条件过滤出来。

在 Way To Agent 的知识体系里，这篇文章关注的是向量数据库为什么需要保存向量和 payload，以及它和 PostgreSQL、文档站搜索的边界。它要回答的是“向量库负责什么，不负责什么”。

向量库到底负责什么

向量库在 RAG 里只做三件事：

• 保存 chunk 对应的向量。
• 按问题向量召回候选片段。
• 按 payload 里的元数据做过滤。

它不负责业务主数据，不负责用户体系，也不负责把答案展示给前端。很多系统把向量库想成“更高级的数据库”，问题就从这里开始：一旦把不属于它的职责塞进去，后面索引重建、文档版本切换、权限过滤和引用追踪都会变得混乱。

一次召回怎么发生

向量数据库的工作方式是把问题向量化，再按相似度和过滤条件召回候选片段。

用户输入
  -> 业务上下文与权限判断
  -> 数据、检索、Prompt 或工具编排
  -> 模型调用或确定性服务执行
  -> 结构化校验、引用、日志和反馈

真正决定它是否好用的，不只是“能不能搜到相似内容”，而是召回结果能不能继续进入后续链路：能不能过滤失效内容，能不能对应到正确文档版本，能不能回到前端引用。

payload 为什么关键

很多人第一次接触向量库时，只盯着 vector 本身，觉得 payload 只是附带字段。这是误判。

在生产 RAG 里，payload 往往比向量更决定系统边界。至少要包含：

chunk_id
doc_id
doc_version_id
source_url
heading_path
visibility
is_active
category / tags

没有这些字段，召回结果就很难继续做三件事：

• 过滤不该出现的内容
• 回到原文展示引用
• 在日志和评估里复现一次回答到底用了什么

向量决定“像不像”，payload 决定“能不能用”。

它和 PostgreSQL 的边界

最容易犯的错，是把向量库当成主数据系统。

更稳的边界应该是：

PostgreSQL：文档、版本、任务、用户、额度、日志、业务关系
向量库：chunk 向量、召回过滤字段、最小引用字段

这条边界的价值在于：

• 文档更新时，可以先改业务状态，再决定何时重建向量索引
• 向量索引损坏或重建时，不会把主数据一起拖垮
• 召回结果返回后，仍然可以回到业务库取更完整的展示和审计信息

向量库应该是检索基础设施，不应该是业务真相来源。

最常见的误解

• 只要有向量检索，就等于有 RAG。
• payload 只是附属字段，少存一点也没关系。
• 向量库可以顺手兼任文档主库。
• 召回质量不好，只需要换更强的 embedding 模型。

怎么排查

当向量数据库相关功能表现不稳定时，不要先猜模型不好。更有效的排查顺序是：

输入是否明确
上下文是否正确
权限与数据范围是否匹配
Prompt / 工具 / 检索配置是否符合预期
模型调用是否超时、限流或输出不合规
日志、引用和评估样例是否能复现问题

如果问题出在“召回到了，但用不了”，优先查 payload；如果问题出在“压根召回不到”，再去看 embedding、过滤和 topK。

一句话结论

向量数据库在 RAG 中的作用的核心不是记住一个名词，而是理解它在 AI 应用链路中的责任边界。向量库不是业务数据库，业务事实仍应放在 PostgreSQL 等主数据系统中。

上手前先画清楚

1. 画清楚哪些字段在业务库，哪些字段在向量库。
2. 标出一次召回后，结果如何回到原文和日志。
3. 明确索引重建时，谁负责状态切换和版本一致性。

继续阅读

04-rag/001-what-is-rag.md
04-rag/002-rag-architecture.md
04-rag/003-document-parsing.md