- 什么是 RAG？
RAG（Retrieval-Augmented Generation，检索增强生成） 是一种将 信息检索 与 大语言模型（LLM）生成 结合的系统设计模式。其核心思想是：在回答用户问题之前，先从外部知识库中检索相关文档片段，再将检索结果作为上下文注入 Prompt，由 LLM 基于「问题 + 检索上下文」生成答案。
经典定义来自 Lewis 等人（2020）：用检索到的文档增强语言模型的输入，从而提升知识密集型任务的表现，并降低幻觉。
- RAG 的应用场景
| 场景 | 说明 |
|---|---|
| 智能客服 | 基于产品手册、FAQ 回答用户咨询 |
| 企业知识库 | 内部制度、流程、技术文档问答 |
| 文档助手 | 合同、研报、论文等长文档问答与摘要 |
| 代码助手 | 结合代码库 / API 文档做检索式问答 |
| 垂直领域问答 | 医疗、法律、金融等需引用权威资料的场景 |
- 为什么需要 RAG？
3.1 传统检索方式的局限
| 方式 | 特点 | 局限 |
|---|---|---|
| 关键词检索（BM25 等） | 精确匹配词项 | 难以理解同义表达与语义 |
| 全文检索 | 覆盖整篇文档 | 难以定位细粒度相关片段 |
| 纯向量检索 | 语义相似度匹配 | 对专有名词、编号等字面匹配较弱 |
传统检索 只返回文档列表，无法像对话一样组织自然语言答案；用户仍需自行阅读与归纳。
3.2 仅使用 LLM 的局限
LLM 的本质是 基于上下文预测下一个 Token，在缺少外部事实支撑时容易出现：
-
幻觉（Hallucination）：编造不存在的事实或引用
-
知识过时：训练数据有截止时间，无法反映最新信息
-
无法访问私有数据：企业内网文档、个人资料未参与训练
-
上下文与成本约束：整库文档无法全部塞进上下文窗口；Token 越多，延迟与费用越高
RAG 通过 「先检索、再生成」，把回答锚定在可核查的外部片段上，在效果、成本与可控性之间取得平衡。
- RAG 核心流程
RAG 通常分为 两条生命周期：离线索引构建（Indexing） 与 在线查询应答（Query / Inference）。
4.1 第一阶段：离线数据准备（Indexing Pipeline）
将私有知识沉淀为可检索的向量索引。
原始文档
→ 加载与解析（Load & Parse）
→ 清洗与结构化（Clean）
→ 文档切分（Chunking）
→ 向量化（Embedding）
→ 写入向量库并建立索引（Index + Metadata）
| 步骤 | 说明 |
|---|---|
| 加载与解析 | 从 PDF、Word、网页、数据库等抽取纯文本；复杂版式需 OCR、表格解析 |
| 清洗 | 去噪、统一编码、去重、保留标题层级与来源等元数据 |
| 切分（Chunking） | 按固定长度、段落、标题或语义边界切成 Chunk；常配合 Overlap（重叠） 避免语义在边界被截断 |
| 向量化 | 使用 Embedding 模型将每个 Chunk 映射为稠密向量 |
| 存储与索引 | 写入向量数据库（如 Milvus、Qdrant、Pinecone、pgvector 等），并保存文档 ID、页码、权限等 元数据（Metadata） 供过滤 |
4.2 第二阶段：在线用户提问（Query Pipeline）
用户发起问题后的标准链路如下（粗筛与精筛是同一检索链路上的两档，而非两套独立系统）。
用户问题
→ [可选] 查询改写 / 分类（Query Rewrite / HyDE 等）
→ 问题向量化（Query Embedding）
→ 检索（Retrieval）
├─ 向量相似度检索（Dense）：余弦相似度、点积等
├─ [可选] 关键词检索（Sparse）：BM25 等
└─ [推荐] 混合检索（Hybrid Search）+ 权限过滤（ACL Filter）
→ Top-K 粗筛（召回候选 Chunk）
→ [可选] 重排（Rerank，Cross-Encoder 等）→ 精筛 Top-N
→ Prompt 组装（Augmentation：问题 + 检索片段 + 系统指令）
→ LLM 生成回答
→ [可选] 后处理：引用标注、安全过滤、拒答策略
流程说明（纠正常见误解）：
- 相似度检索 是手段，向量检索 是其实现方式之一；在线阶段是对 问题向量 与 库中 Chunk 向量 做近邻搜索，而不是再次对原始文档做全量向量化。
- Top-K 负责 召回（Recall），追求「尽量不漏」；Rerank 负责 精排（Precision），用更强但更慢的模型对少量候选重新打分。
- 欧氏距离 与 余弦相似度 在向量已归一化时往往等价；工程上更常用余弦相似度或内积。
- 关键组件速览
| 组件 | 作用 |
|---|---|
| Embedding 模型 | 文本 ↔ 向量，索引与查询须使用 同一模型（或兼容版本） |
| 向量数据库 | 高效近似最近邻（ANN）搜索，支持元数据过滤 |
| 检索器（Retriever） | 执行 Dense / Sparse / Hybrid 检索 |
| 重排模型（Reranker） | 对 Query–Document 对精细打分，提升 Top 结果相关性 |
| Prompt 模板 | 约束 LLM 仅依据给定上下文作答，并要求标注来源 |
| 生成模型（LLM） | 综合上下文生成最终自然语言回答 |
- 难点与工程技巧
6.1 文档类型多样化
PDF、Word、Excel、PPT、扫描件、图片等格式各异。需通过解析器、OCR、表格识别等手段做 数据清洗与结构化；解析质量直接决定 RAG 上限，这一步不可忽视。
6.2 文档切分（Chunking）
| 问题 | 后果 |
|---|---|
| Chunk 过大 | 噪声多、相似度区分度下降、易超出上下文 |
| Chunk 过小 | 语义不完整、回答缺乏必要背景 |
建议：结合文档结构（标题、段落）切分；设置合理 chunk_size 与 chunk_overlap；对代码、表格等特殊内容单独策略处理。
6.3 用户问题口语化
口语、省略、多义词会导致检索偏差。可采用：
- Query Rewrite：用 LLM 将口语问题改写为更利于检索的表述
- HyDE（Hypothetical Document Embeddings）：先生成假设性答案再取向量检索
- Query Decomposition：将复杂问题拆成子问题分别检索
6.4 混合检索（Hybrid Search）
生产环境常将 向量检索（语义） 与 BM25 等关键词检索（字面） 结合，再经 融合打分（如 RRF） 取并集，兼顾「意思相近」与「专有名词精确命中」。
6.5 模型选型
需综合考量：Embedding 与 LLM 的效果、幻觉率、推理延迟、Token 成本、是否支持长上下文、私有化部署与合规要求等。
6.6 评估与可观测性
- 检索与生成应分开评估：Recall@K、MRR 看检索；答案忠实度、引用正确性看生成
- 记录每次查询的检索片段、Prompt、模型版本，便于回归与排错
- 业界经验：多数 RAG 失败根因是检索错了上下文，而非生成模型本身能力不足
- 数据权限实现
企业知识库、多部门协作等场景下，RAG 必须保证 用户只能检索并看到其有权限访问的文档，否则会出现越权泄露。权限控制应贯穿 索引写入 与 在线检索 全链路，且以 检索前过滤 为主，不能依赖 LLM「自觉保密」。
7.1 设计原则
| 原则 | 说明 |
|---|---|
| 最小权限 | 默认不可见，仅显式授权的资源可进入检索结果 |
| 检索前过滤 | 在向量库 / 检索引擎侧用过滤条件缩小候选集，避免无权 Chunk 进入 Prompt |
| 权限与内容同源 | ACL 来自业务系统（HR、OA、文档库），索引时写入，变更时同步更新 |
| 租户隔离 | 多租户场景下 tenant_id 与业务权限一并作为硬过滤条件 |
| 可审计 | 记录用户身份、命中的文档 ID、过滤条件，满足合规与追责 |
7.2 权限模型（常见维度）
用户身份（User ID）
├─ 所属组织 / 部门（dept_id）
├─ 角色（role：admin、employee、guest）
├─ 用户组 / 岗位（group_id）
└─ 租户（tenant_id，SaaS 多租户）
文档 / Chunk 元数据
├─ owner_id、dept_id
├─ visibility：public / internal / confidential
├─ allowed_roles、allowed_user_ids、allowed_dept_ids
└─ 密级、项目 ID、数据域标签
- RBAC（基于角色）：按角色映射可读文档集合，实现简单，适合层级清晰的组织。
- ABAC（基于属性）：按用户属性 + 资源属性动态判断，适合跨部门、项目制权限。
- 文档级 vs Chunk 级：权限通常挂在 文档 上，索引时将同一 ACL 复制到每个 Chunk 的 metadata；若同一文档内段落权限不同，需按段落切分并分别打标。
7.3 离线阶段：索引时写入权限元数据
在 向量化入库 时，为每个 Chunk 附带权限相关字段，与向量一并存储：
{
"chunk_id":"doc_1001_c003",
"text":"...",
"tenant_id":"t_001",
"doc_id":"doc_1001",
"dept_id":["d_sales","d_hr"],
"visibility":"internal",
"allowed_roles":["employee","manager"],
"allowed_user_ids":[],
"security_level":2,
"updated_at":"2026-05-01T10:00:00Z"
}
同步策略：
- 文档授权变更 → 更新源系统 ACL → 增量更新 向量库中对应 Chunk 的 metadata（或删除后重新索引）
- 用户离职 / 角色调整 → 由 IAM 驱动，无需改 Chunk 内容，仅在线查询时用最新身份计算过滤条件
7.4 在线阶段：检索时强制过滤
用户请求进入检索前，由 鉴权服务 解析当前用户可访问范围，生成 过滤表达式，与向量检索一并下发：
用户提问 + JWT / Session
→ 鉴权：解析 user_id、tenant_id、roles、dept_ids
→ 生成 filter（如 tenant_id == X AND (dept_id IN [...] OR allowed_user_ids CONTAINS user_id)）
→ 向量检索 Top-K（仅在 filter 命中的子集内做 ANN）
→ Rerank → Prompt → LLM
向量库侧实现（以常见能力为例）：
| 方式 | 适用场景 |
|---|---|
| Metadata Filter | 单库多文档，按 tenant_id、dept_id、role 等字段过滤（Milvus、Qdrant、Elasticsearch 等均支持） |
| 分 Collection / 分 Index | 租户或事业部完全隔离，物理隔离，运维成本高但边界清晰 |
| 多路检索 + 权限交集 | Hybrid 检索时，Dense / Sparse 两路均带相同 filter，避免一路绕过权限 |
注意： 过滤必须在 ANN 查询参数 中生效（Pre-filter），不能先 Top-K 再内存过滤，否则无权但相似度高的 Chunk 可能先被召回并进入 Rerank，存在泄露风险。
7.5 典型实现架构
┌─────────────┐ ┌──────────────┐ ┌─────────────────┐
│ SSO / IAM │────▶│ RAG API 网关 │────▶│ 权限解析服务 │
│ (OAuth/SAML)│ │ (校验 Token) │ │ (用户→filter) │
└─────────────┘ └──────┬───────┘ └────────┬────────┘
│ │
▼ ▼
┌──────────────┐ ┌──────────────┐
│ 检索服务 │◀───────│ ACL 缓存/DB │
│ filter+Top-K │ │ (与 OA 同步) │
└──────┬───────┘ └──────────────┘
▼
┌──────────────┐
│ 向量数据库 │
│ chunk+metadata│
└──────────────┘
- 网关层：校验 Token，拒绝未登录请求；不向 LLM 传递其他用户的身份信息。
- 权限解析服务：将「用户 → 可访问 dept/role/doc 列表」转为检索 filter；可对热点用户 ACL 做短时缓存，但须设 TTL 并在权限变更时失效。
- 文档源系统：Confluence、SharePoint、自研 OA 等作为 权限真源，通过 webhook 或定时任务同步到 RAG 索引。
7.6 生成与展示层的安全补充
| 环节 | 做法 |
|---|---|
| Prompt | 仅注入已通过权限过滤的 Chunk；系统提示中要求不得推测未提供文档中的敏感内容 |
| 引用与下载 | 返回的 doc_id、链接需二次校验用户是否仍有权访问该文档 |
| 拒答策略 | 过滤后无召回时，返回「未找到您有权限的相关资料」，避免暗示存在无权文档 |
| 日志脱敏 | 审计日志记录 doc_id、chunk_id，避免记录完整机密正文 |
7.7 常见风险与对策
| 风险 | 对策 |
|---|---|
| 先召回后过滤，Top-K 含无权 Chunk | 使用向量库 带 filter 的查询 API，或分租户独立索引 |
| 元数据过期，用户已失去权限仍能检索 | ACL 变更触发 metadata 更新；在线侧用 IAM 实时身份 + 短 TTL 缓存 |
| 多租户 filter 写错 | 强制所有请求带 tenant_id，集成测试覆盖越权用例 |
| Prompt 注入诱导模型「忽略权限」 | 权限不交给模型判断；检索层硬过滤 + 输出层不返回未授权引用 |
| 管理员误将机密库设为 public | 入库前校验 visibility；敏感库单独 Collection + 审批流 |
- 最佳实践小结
-
先证明检索有效，再优化生成
-
索引与查询使用 一致的 Embedding 模型
-
为 Chunk 保留 来源、页码、权限 等元数据，检索时必须带权限 filter
-
默认采用 Hybrid + Top-K + 轻量 Rerank 作为生产基线
-
Prompt 中明确要求：仅依据上下文回答，不知道则说明
-
文档或 ACL 变更 后需及时 更新索引元数据或 Re-index
-
从简单链路起步，再逐步加入改写、HyDE、多路检索等增强模块
-
企业场景务必实现第 7 节数据权限，并以越权检索用例纳入回归测试
这里给大家精心整理了一份全面的AI大模型学习资源，包括：AI大模型全套学习路线图（从入门到实战）、精品AI大模型学习书籍手册、视频教程、实战学习、面试题等，资料免费分享！
👇👇扫码免费领取全部内容👇👇
1. 成长路线图&学习规划
要学习一门新的技术，作为新手一定要先学习成长路线图，方向不对，努力白费。
这里，我们为新手和想要进一步提升的专业人士准备了一份详细的学习成长路线图和规划。可以说是最科学最系统的学习成长路线。
2. 大模型经典PDF书籍
书籍和学习文档资料是学习大模型过程中必不可少的，我们精选了一系列深入探讨大模型技术的书籍和学习文档，它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。（书籍含电子版PDF）
3. 大模型视频教程
对于很多自学或者没有基础的同学来说，书籍这些纯文字类的学习教材会觉得比较晦涩难以理解，因此，我们提供了丰富的大模型视频教程，以动态、形象的方式展示技术概念，帮助你更快、更轻松地掌握核心知识。
4. 2026行业报告
行业分析主要包括对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。
5. 大模型项目实战
学以致用 ，当你的理论知识积累到一定程度，就需要通过项目实战，在实际操作中检验和巩固你所学到的知识，同时为你找工作和职业发展打下坚实的基础。
6. 大模型面试题
面试不仅是技术的较量，更需要充分的准备。
在你已经掌握了大模型技术之后，就需要开始准备面试，我们将提供精心整理的大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。
7. 资料领取：全套内容免费抱走，学 AI 不用再找第二份
不管你是 0 基础想入门 AI 大模型，还是有基础想冲刺大厂、了解行业趋势，这份资料都能满足你！
现在只需按照提示操作，就能免费领取：
👇👇扫码免费领取全部内容👇👇
扫一扫
3470
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
