传统数据库与向量数据库的使用差异

原始图示

结构化查询和语义近邻搜索适合不同问题，RAG 中常常组合使用。

查询方式差异

传统数据库通过结构化字段做精确查询，典型写法是 SELECT ... WHERE id = ...。只要条件明确、字段规范，它能给出确定结果，适合订单、账户、库存、交易、权限等场景。

向量数据库通过语义相似度查找近邻。它不要求文本完全相同，而是根据向量距离找到最相似的内容。用户问“公司年假规则”，文档写“带薪休假制度”，向量检索仍然可能召回。

这两种数据库的差异不是谁替代谁，而是各自解决不同问题。RAG 系统中常见做法是先用结构化条件过滤租户、部门、权限、文档状态，再在过滤后的集合中做向量检索。

数据组织差异

传统数据库以表、行、列组织数据。字段类型明确，约束清晰，适合事务一致性和复杂统计。向量数据库以向量、文本和 metadata 组织数据，核心能力是高维近似最近邻搜索。

例如电影数据可以在关系型数据库里保存电影名、导演、类型、评分；也可以把电影描述转换成向量保存到向量库里。关系型数据库适合查询“评分大于 8 的电影”，向量库适合查询“和星际冒险氛围相近的电影”。

协同方式

生产架构里不要把所有东西都塞进向量库。向量库里的 metadata 应该服务过滤和召回，而不是承担完整业务数据模型。完整业务对象仍然应该保存在主库中，向量库保存可检索片段和必要过滤字段。

当用户发起问题时，可以先根据权限从业务库得到可访问数据集，再把这些条件作为 metadata filter 传给向量库。检索返回 chunk 后，再根据 source_id 回查主库展示完整来源。

源码示例

# 结构化条件负责“能不能看”，向量检索负责“像不像”
filter_expr = {
    "tenant_id": "acme",
    "department": "finance",
    "status": "published",
}

docs = vectorstore.similarity_search(
    "差旅交通票据提交规范",
    k=5,
    filter=filter_expr,
)

拓展

可以从三个方向继续扩展：第一，把当前组件放回完整 RAG 链路中观察，不只看单点能力；第二，为每次参数变化建立固定问题集，避免凭感觉判断效果；第三，把来源、版本、权限、时间和评估结果写入 metadata 或日志，让线上问题能追溯。

这类基础能力越早规范，后面接入多查询、重排、混合检索、父文档检索和权限隔离时越省力。

最新版 LangChain 用法提示

最新版 LangChain 把很多集成拆到独立包中。通用抽象来自 langchain_core，社区向量库多在 langchain_community，云厂商向量库可能在独立包里。新项目要优先查看对应集成包的当前 API，并使用 as_retriever()、invoke() 等 Runnable 风格接口。

常见问题

这类组件应该先在什么规模上验证？

先用一小批真实文档和真实问题验证，而不是直接全量入库。验证时至少观察三类结果：检索是否命中正确片段、返回片段是否包含足够上下文、最终回答是否严格基于证据。

只看相似度分数够不够？

不够。相似度分数只能说明向量距离，不代表答案一定正确。还要看 chunk 是否完整、metadata 是否正确、过滤条件是否过严或过松，以及 Prompt 是否要求模型只根据上下文回答。

参数应该怎么调？

先固定评测问题集，再一次只改一个变量，例如 chunk 大小、overlap、top_k、Embedding 模型或过滤条件。每次改动都记录召回命中率、答案准确率、延迟和成本。

面试题

1. RAG 链路里最容易被忽略的工程点是什么？

最容易被忽略的是数据处理和评估。很多问题不是 LLM 不会答，而是文档解析错误、chunk 切坏、metadata 丢失、向量版本混乱、检索过滤条件错误，导致模型拿不到正确证据。

2. 为什么不能只依赖 LLM 自身参数记忆？

参数记忆存在知识过期、领域知识缺失、事实边界不清和不可追踪的问题。RAG 通过检索外部证据，把回答范围约束在可追踪内容上，适合企业知识库、产品文档和实时资料问答。

3. 如何判断一个 RAG 系统的问题出在检索还是生成？

先直接查看检索返回的文档。如果返回内容已经不相关，问题在加载、切分、Embedding、向量库或 Retriever；如果返回内容正确但回答错误，问题多半在 Prompt、上下文压缩、引用组织或模型输出约束。

生产问题排查

问题	常见原因	处理方式
回答看起来合理但没有依据	Prompt 没要求基于上下文，或检索片段不相关	增加拒答策略、引用来源、检索结果抽样检查
召回结果经常跑偏	chunk 过短、Embedding 模型不适合、query 表达不完整	调整切分策略，评估 Embedding，必要时做查询改写
命中了旧内容	文档更新后没有重新入库，或缓存没有区分版本	使用文档 hash、版本号、更新时间和重建任务
多租户数据串库	metadata filter 缺失或字段设计不严谨	强制 tenant_id / dataset_id 过滤，并做权限测试
成本增长明显	重复 Embedding、top_k 过大、无缓存	增加缓存、批处理、限流和调用统计
延迟不稳定	向量库网络抖动、LLM 响应慢、检索链路串行	并行化可并行步骤，增加超时、重试和降级策略