RAG 向量数据库入门：从 Embedding 到检索增强生成

摘要：RAG（Retrieval-Augmented Generation，检索增强生成）是大模型应用落地中最常见的技术架构之一。它通过 Embedding、向量数据库、相似度检索、元数据过滤、混合检索、Rerank 和 Prompt 组装，让大模型在回答问题前先找到可靠资料，再基于资料生成答案。本文面向初学者，重新梳理 RAG 与向量数据库的核心概念、工作流程、系统架构、工程选型、评估指标和实战 Demo，帮助读者从“知道 RAG 是什么”走到“能搭一个可用的 RAG 系统”。

写在前面：RAG 解决的不是“模型不聪明”，而是“模型没资料”

很多人第一次做大模型应用，会直接把问题丢给模型：

请问我们公司的报销流程是什么？

如果模型没有看过公司的制度文档，它只能根据训练语料里的通用知识回答。它可能说得很流畅，甚至看起来很专业，但具体到“报销是否需要审批”“发票提交期限”“特殊场景怎么处理”这些细节时，很容易答错。这就是企业大模型应用最常见的问题：模型很会组织语言，但它不知道你的私有知识。

RAG 的思路很朴素：先把相关资料找出来，再让模型基于资料回答。它像一次开卷考试。

普通大模型问答是闭卷考试，模型只能靠记忆；RAG 是开卷考试，系统先翻书，找到相关段落，再让模型组织答案。

RAG（Retrieval-Augmented Generation） 可以拆成三部分：

• Retrieval：检索，从知识库里找资料。

• Augmented：增强，把检索到的资料补充给模型。

• Generation：生成，让模型基于资料回答。

所以，RAG 的核心不是让模型背下所有知识，而是在回答时把正确上下文送到模型面前。

注意，这里有一个很重要的边界：RAG 可以降低幻觉风险，但不能彻底消灭幻觉。如果检索错了、文档本身错了、Prompt 约束不够清楚，模型仍然可能答错。

一、RAG 为什么会成为大模型应用的基础架构

大模型有几个天然限制，这些限制正好对应 RAG 的价值。

第一，模型知识可能过时。

模型训练完成后，它的参数不会自动知道最新政策、最新产品文档、最新代码和最新业务规则。如果公司昨天刚改了退款流程，模型今天不会凭空知道。

第二，私有知识不在模型里。

企业内部制度、客服工单、合同条款、代码仓库、数据库字段说明、项目会议纪要，通常不会出现在通用模型训练数据中。这些知识要么通过检索提供，要么通过工具调用提供。

第三，上下文窗口有限。

即使模型支持很长上下文，也不代表可以每次把整个知识库塞进去。这样成本高、速度慢，而且会引入大量无关信息，让模型更难抓住重点。

第四，业务回答需要可追溯。

企业场景里，答案不只是“看起来合理”，还要能说明依据来自哪里。RAG 可以把引用来源返回给用户，让答案有迹可循。

因此，在知识库问答、客服助手、代码助手、制度查询、合同审查、运维问答、产品文档助手等场景里，RAG 往往是比“纯聊天模型”更稳妥的方案。

可以把 RAG 的价值概括成一句话：让大模型不再凭空回答，而是基于可检索、可更新、可追溯的资料回答。

二、RAG 的两条链路：离线建库和在线问答

一个典型 RAG 系统通常分成两条链路：

第一条是离线建库链路，负责把资料变成可检索的知识库：

第二条是在线问答链路，负责在用户提问时找到资料并生成答案：

简化成一句话：先把知识变成可检索的向量，再在提问时找出相关知识喂给模型。

这里面最容易被初学者忽略的是：RAG 不只是“接一个向量数据库”。向量数据库只是其中一环。真正影响效果的因素包括：

• 文档解析是否干净。

• 切块是否合理。

• Embedding 模型是否适配业务语言。

• 检索策略是否只依赖向量。

• metadata 是否包含权限、版本、时间。

• Rerank 是否能把好证据排到前面。

• Prompt 是否要求模型基于证据回答。

• 是否有评估集判断优化是否有效。

如果把 RAG 当成一条链路看，就会发现很多线上问题并不是模型能力差，而是链路里某一环没有处理好。

三、Embedding、向量和相似度检索：RAG 的底层语言

RAG 之所以能“按语义找资料”，核心依赖 Embedding。Embedding 是把文本、图片、音频、代码等数据转换成向量的过程。在 RAG 里，最常见的是文本 Embedding。

例如一句话：Redis 如何避免缓存穿透？经过 Embedding 模型后，会变成类似这样的数组：

[0.012, -0.083, 0.145, ..., 0.027]

真实向量通常有几百到几千维。这些数字不是随机的，Embedding 模型会把语义相近的文本映射到距离更近的位置。比如：

如何避免缓存穿透？

缓存不存在的数据怎么处理？

这两句话字面不同，但语义接近，它们的向量距离应该更近。而：Redis 持久化怎么配置？和缓存穿透的语义距离就应该更远。这就是向量检索的基础。

3.1 相似度怎么算

向量之间是否相似，通常通过距离或相似度函数计算。常见方法有三种：

第一种， Cosine Similarity，余弦相似度。

它关注两个向量方向是否接近，不太关心向量长度。文本语义检索里很常见。

第二种， Dot Product，点积。

它计算两个向量的乘积和，有些 Embedding 模型会针对点积进行训练。

第三种， Euclidean Distance，欧氏距离。

它计算两个向量在空间里的直线距离，距离越小越相似。

具体选择哪一种，最好看 Embedding 模型和向量数据库的推荐配置，不要随手乱选。因为不同模型训练时优化的相似度目标可能不同。

3.2 为什么需要 ANN 索引

如果知识库只有几百条数据，直接计算每个向量和用户问题的距离也能接受。但如果知识库有几百万、几千万甚至上亿个 chunk，全量计算就太慢了。这时就需要 ANN（Approximate Nearest Neighbor，近似最近邻）索引。

ANN 的目标不是每次都找出数学上绝对最近的向量，而是在速度和准确率之间做平衡，快速找出足够接近的候选结果。常见索引包括：

• HNSW。

• IVF。

• PQ。

• DiskANN。

初学阶段不需要立刻深入每一种索引的实现细节，但要理解一个事实：向量数据库之所以能在大规模数据下快速检索，靠的不只是“存向量”，还靠索引结构。

3.3 选择 Embedding 模型时看什么

初学者可以先看四个指标：

1. 语义效果：能不能找回真正相关的内容。

2. 维度大小：维度越大，存储和计算成本越高。

3. 多语言能力：中文、英文、混合文本效果如何。

4. 成本和延迟：批量建库和在线查询都要花钱、花时间。

Embedding 模型选错，后面的向量数据库再强也救不回来。

四、向量数据库到底做什么

向量数据库负责存储、索引和检索向量。它通常保存三类信息：id、vector、metadata。

一条向量记录大概长这样：

  {
    "id": "policy-2026-001#chunk-12",
    "vector": [0.012, -0.083, 0.145],
    "metadata": {
      "title": "2026 报销制度",
      "department": "finance",
      "created_at": "2026-01-10",
      "permission": "employee"
    },
    "text": "员工报销需要在发票开具后 30 天内提交..."
  }

当用户提问时，系统把问题也转成向量，然后在向量数据库里找“距离最近”的内容。这就是相似度检索。

4.1 向量数据库和普通数据库有什么不同

普通数据库擅长精确查询：

SELECT * FROM docs WHERE id = 1001;

或者结构化过滤：

SELECT * FROM docs

WHERE department = 'finance'

AND created_at >= '2026-01-01';

向量数据库擅长相似度查询：

找出和这句话语义最接近的 10 段文本

它解决的是“意思相近”的问题，而不是“字段完全相等”的问题。不过，在真实 RAG 系统里，向量检索和结构化过滤通常要一起用。例如用户问：

销售部门的差旅报销标准是什么？

系统不仅要找语义相关的内容，还要过滤：

department = sales

permission <= 当前用户权限

status = active

version = latest

这就是 metadata 过滤的意义。

4.2 向量数据库怎么选

向量数据库大致可以分成四类。

第一类，关系型数据库扩展，比如 PostgreSQL + pgvector。

优点是容易接入现有系统，适合数据量不大、团队已经熟悉 PostgreSQL 的场景。缺点是当向量规模、召回性能和多租户隔离要求变高时，需要更谨慎地设计索引和扩展方案。

第二类，搜索引擎扩展，比如 Elasticsearch、OpenSearch。

优点是关键词检索能力强，适合 Hybrid Search。缺点是如果主要压力来自大规模向量检索，要关注索引性能和成本。

第三类，专用向量数据库，比如 Milvus、Qdrant、Weaviate。

优点是面向向量检索设计，索引、过滤、扩展能力更完整。缺点是需要额外维护一套基础设施。

第四类，云厂商托管服务。

优点是上手快、运维少，适合快速验证和业务初期。缺点是成本、可控性、迁移能力要提前评估。

初学者建议：

• 个人 Demo：可以用本地向量库、SQLite 扩展或轻量服务。

• 小型项目：PostgreSQL + pgvector 或托管向量库都可以。

• 企业知识库：重点关注权限过滤、增量更新、混合检索、备份恢复和可观测性。

• 大规模检索：需要重点评估索引性能、分片、扩容、延迟和成本。

五、文本切块、元数据过滤和 Hybrid Search：决定能不能找对资料

很多 RAG 效果问题，不是出在大模型，而是出在检索前。

5.1 文本切块为什么重要

大模型不能直接对整本手册、整套制度、整个代码仓库做向量检索。通常需要先把文档切成 chunk。

切块太小，会丢上下文。例如：员工报销需要在发票开具后 30 天内提交。如果前后关于“适用范围”“特殊审批”的内容被切到其他 chunk，模型可能回答不完整；

切块太大，又会带入太多无关信息，影响检索精度，也浪费 Prompt token。

常见切块策略包括：

• 按固定长度切。

• 按标题和段落切。

• 按 Markdown / HTML 结构切。

• 按语义相似度切。

• parent-child chunk：小块用于检索，大块用于回答。

初学者可以先从结构化切块开始：优先保留标题、段落、列表、表格和代码块的完整性，不要一上来就只按字符数硬切。

5.2 元数据过滤：别让模型看到不该看的内容

向量相似度只知道“语义像不像”，不知道“用户有没有权限看”。所以每个 chunk 都应该带 metadata，例如：

  {
    "doc_id": "finance-policy-2026",
    "title": "财务报销制度",
    "department": "finance",
    "version": "2026",
    "permission": "employee",
    "created_at": "2026-01-10",
    "status": "active"
  }

在线检索时，应该先按权限、租户、版本、状态、时间等条件过滤，再做相似度检索或重排。否则很容易出现两类问题：

• 用户看到不该看的内部资料。

• 系统引用了过期文档或错误版本。

在企业场景里，metadata 不是可选项，而是 RAG 系统的基本安全边界。

5.3 Hybrid Search：关键词和向量一起用

只用向量检索，经常会漏掉精确匹配信息。例如：

• 错误码。

• API 名称。

• 配置项。

• 类名。

• 法条编号。

• 产品型号。

这些内容在语义向量里未必稳定，但关键词检索很擅长。

Hybrid Search 的思路是把向量检索和关键词检索结合起来：

例如用户问：错误码 E1029 是什么意思？这类问题优先应该靠关键词命中，而不是只靠语义相似度。

生产系统里，Hybrid Search 通常比纯向量检索更稳。

六、Rerank、Prompt 和引用：决定答案质量的最后一公里

初始检索返回的 topK，不一定就是最适合放进 Prompt 的 topK。向量数据库主要负责快速召回候选内容，但它的相似度分数不一定等于“这段内容能回答问题”。这就是 Rerank 的价值。

6.1 为什么检索后还要重排

假设用户问：

员工离职后多久停用系统账号？

向量检索可能召回这些内容：

1. 员工账号权限申请流程。

2. 员工离职交接流程。

3. 离职员工账号停用规则。

4. 系统账号安全规范。

这些内容都相关，但真正能回答问题的是第 3 条。

Rerank 会用更精细的模型重新判断“问题”和“候选 chunk”的匹配程度，把真正能回答问题的内容排到前面。常见流程是：

Rerank 会增加成本和延迟，所以不一定每次都要用。比较适合这些情况：

• 多路召回结果混在一起。

• 用户问题较复杂。

• 初始召回结果分数接近。

• 业务对答案准确率要求高。

6.2 Prompt 不是越长越好

很多人以为把更多 chunk 塞给模型，答案就会更准。实际不一定。如果 Prompt 里有太多重复、冲突、过时或无关内容，模型反而更容易抓错重点。一个比较稳的 RAG Prompt 应该包含：

  你是一个企业知识库助手。
  请只根据给定资料回答问题。
  如果资料中没有答案，请明确说明“当前资料中没有找到依据”。
  回答时给出引用来源。
  
  用户问题：
  {question}
  
  参考资料：
  {retrieved_chunks}

这里有三个关键点：

1. 要求模型只基于资料回答。

2. 允许模型在证据不足时拒答。

3. 要求返回引用来源。

6.3 引用来源要可追溯

RAG 的一个重要价值是让答案有依据。因此 chunk 最好保留：

• 文档标题。

• 章节路径。

• 页码或段落位置。

• URL 或文档 ID。

• chunk ID。

这样当用户质疑答案时，可以追溯到原文，而不是只看到一段模型生成的自然语言。

七、RAG 系统架构与从零搭建 Demo

一个可用的 RAG 系统通常包含这些模块：

如果要从零搭一个最小 Demo，可以按下面步骤走。

1. 准备文档

先准备少量结构清晰的文档，比如：

• 公司报销制度

• 请假制度

• 产品 FAQ

• 接口说明文档

初学阶段不要一开始就塞几千份 PDF。先用 5 到 10 份质量较好的文档，把流程跑通。

2. 文档清洗和切块

清洗掉页眉、页脚、目录、广告、重复说明等噪声，然后按标题、段落、列表切块。每个 chunk 至少包含：

  {
    "chunk_id": "doc1#chunk3",
    "text": "报销申请需要在发票开具后 30 天内提交。",
    "metadata": {
      "title": "报销制度",
      "section": "提交时限",
      "permission": "employee"
    }
  }

3. 生成 Embedding

对每个 chunk 调用 Embedding 模型，生成向量。

注意要记录 Embedding 模型名称和版本。后续模型升级时，不能把不同模型生成的向量随意混在一起检索。

4. 写入向量数据库

把 chunk ID、向量、正文和 metadata 写入向量数据库。写入后可以先做几个固定问题测试：

• 报销需要多久内提交？

• 请假需要谁审批？

• 接口调用失败如何排查？

确认正确 chunk 能被召回。

5. 用户提问和检索

用户提问后，对问题生成向量，然后从向量数据库检索 topK。

如果有权限、版本、部门、语言等条件，要加 metadata filter。例如：

  permission <= 当前用户权限
  status = active
  version = latest

6. Rerank 和 Prompt 组装

如果召回结果较多，可以先 Rerank，再选出最相关的几段进入 Prompt。Prompt 中要包含：

• 用户问题。

• 检索到的资料。

• 回答规则。

• 引用格式。

• 证据不足时的拒答规则。

7. 生成答案并返回引用

最终让大模型基于资料回答。一个比较好的返回结果不只是答案，还应该有来源：

  根据《报销制度》“提交时限”章节，报销申请需要在发票开具后 30 天内提交。
  
  引用来源：
  - 报销制度 / 提交时限 / chunk-3

这样用户可以判断答案是否可信。

八、如何评估 RAG 效果

没有评估，就没有优化。RAG 评估至少要分成两层：检索评估和生成评估。

8.1 检索评估

检索评估关注“资料有没有找对”。常见指标包括：

Recall@K

正确 chunk 是否出现在前 K 个结果里。例如 Recall@5 表示正确答案是否在前 5 个召回结果中。

Precision@K

前 K 个结果里有多少是真正相关的。

MRR

第一个正确结果出现得越靠前，分数越高。

这些指标适合判断切块、Embedding、向量索引、Hybrid Search 和 Rerank 是否有效。

8.2 生成评估

生成评估关注“模型有没有基于资料答好”。常见指标包括：

Faithfulness

答案是否忠实于检索资料，有没有编造。

Answer Relevance

答案是否真正回答了用户问题。

Citation Accuracy

引用来源是否准确，是否能对应到原文。

在企业项目里，建议维护一个小型 gold set：

问题

标准答案

应该召回的文档或 chunk

允许的引用来源

每次调整 chunk size、Embedding 模型、topK、Rerank 或 Prompt，都跑一遍评估。否则很容易出现“这个样例变好了，另一个样例变差了”的情况。

九、常见失败原因与工程落地建议

RAG 系统常见失败原因，大多可以归到下面几类。

第一，文档质量差。

PDF 解析乱码、表格错位、页眉页脚混入正文，都会直接污染知识库。

第二，切块不合理。

chunk 太小会丢上下文，chunk 太大会影响召回精度。切块不是纯文本处理问题，而是业务建模问题。

第三，Embedding 模型不适配。

中文、英文、代码、专业术语、行业文档，对 Embedding 模型要求不同。模型选错，召回会很不稳定。

第四，只用向量检索。

错误码、字段名、接口名、编号、SKU 等内容，关键词检索往往更可靠。生产系统建议做 Hybrid Search。

第五，没有权限过滤。

如果 metadata 设计不好，模型可能引用用户无权访问的资料。这在企业知识库里是严重问题。

第六，没有 Rerank。

初始召回结果可能“语义相关但不能回答”。没有 Rerank 时，错误 chunk 很容易进入 Prompt。

第七，Prompt 塞太多。

上下文越多不一定越好。重复、冲突、过时内容会干扰模型判断。

第八，没有评估集。

没有 gold set，就无法判断一次优化到底是整体变好，还是只对几个样例有效。

工程落地建议

如果是第一次做 RAG，可以按下面优先级推进：

1. 先选一批高质量文档，不要一开始就全量导入。

2. 做结构化切块，保留标题、章节、来源和权限。

3. 选择适合业务语言的 Embedding 模型。

4. 向量检索先跑通，再补 metadata filter。

5. 对错误码、编号、接口名等场景加入关键词检索。

6. 结果不稳定时加入 Rerank。

7. Prompt 要支持引用和拒答。

8. 从第一天开始记录日志和 bad case。

9. 建一个小型评估集，优化前后都跑一遍。

最后要记住：向量数据库不是 RAG 的全部。

一个完整 RAG 系统至少包含：

• 文档治理。

• 切块策略。

• Embedding 模型。

• 向量索引。

• 关键词检索。

• metadata 过滤。

• Rerank。

• Prompt 约束。

• 引用追踪。

• 效果评估。

• 日志和监控。

• 权限和安全。

如果只关注“用了哪个向量数据库”，很容易忽略真正决定效果的部分。

结语：先让系统找对资料，再让模型说好话

RAG 的核心逻辑并不复杂：先检索，再生成。但要把它做稳，并不只是调一个 topK、接一个向量库、写一个 Prompt。

对于初学者来说，最好的学习路径不是先研究所有向量索引算法，而是先搭一个最小可用系统，理解每一步为什么存在。当你能解释“为什么这个问题没答对，是文档问题、切块问题、召回问题、排序问题，还是生成问题”时，才算真正入门 RAG。

一句话总结：

RAG 的目标不是让模型更会编，而是让模型基于正确资料回答。

先让系统找对资料，再让模型说好话。