Rag引入 - 技术栈

什么是 RAG

RAG 全称Retrieval-Augmented Generation，检索增强生成

原理：大模型生成回答前，先从外部知识库检索相关信息，结合检索内容输出答案。
核心目的：解决大模型幻觉问题，提升专业领域回答准确度。
极简概括：核心 = 检索 + 生成，模型不再仅凭自身训练数据作答，而是先调取资料再回答。

RAG 使用场景

适配需要事实性、专业性、时效性知识支撑的业务，实现知识更新、领域专精能力：

1、企业知识问答 / 智能客服

企业内部私有化资料（产品说明书、员工规范、业绩报表等）搭建专属知识库，客服智能体实时调取内部事实信息，输出专业准确答复。

2、安全分析与情报检索

依托威胁情报、漏洞、安全日志搭建知识库，落地能力：

APT 攻击链分析
威胁情报分析
CVE 安全漏洞解读

价值：安全分析师用自然语言快速检索、分析、产出报告，提升威胁处置效率。

3、法律、医疗、金融等专业领域问答

行业痛点：知识迭代快、专业术语多、回答错误代价极高；传统大模型受训练时间与数据范围限制，无法同步新规、新指南。

RAG 作用：充当大模型知识外挂，持续灌入新知识，稳定输出高质量专业问答。

RAG 主要流程

以用户提问为分界，分为两大阶段：

构建索引

第一步：构建索引（离线预处理，提问前完成）

操作流程：文档预处理 → 文档分片 → 向量化 → 生成知识库索引

关键原则：GIGO（垃圾进，垃圾出）

源头数据质量是决定最终检索效果的第一要素，后续检索优化无法弥补原始劣质数据带来的缺陷，索引质量直接决定检索上限。

检索生成

第二步：检索生成（用户提问时实时执行）
匹配知识库中和用户问题相似度最高的文本块（chunk）
将检索到的文本块注入大模型上下文，作为参考依据
大模型结合参考资料生成最终回答

索引构建

索引构建是 RAG 两大流程的第一步，在用户提问前离线执行，负责对知识库文档完成全流程加工，是后续检索生成环节的基础。

知识库索引的质量直接决定最终的检索效果。

该环节遵循核心原则：垃圾进，垃圾出（Garbage In, Garbage Out, GIGO）

------ 数据源头的质量是影响最终检索效果的最重要因素，无论后续检索环节做何种优化，都无法弥补劣质源头数据带来的效果缺陷。

完整的索引构建分为四个环节：文档预处理 → 文档分片 → 向量化 → 生成索引并存入向量数据库。

文档预处理

定义：将原始文档进行加载、解析，转换为可统一处理的标准化格式的过程。
执行步骤
- 文档加载与格式统一：按不同文档类型完成加载，统一转换为标准的document格式。
- 无效内容清洗：去除文档中冗余无效信息，包括多余的空格、换行符、无意义的特殊符号、重复内容等。
- 文本格式规范化：对文本格式做统一处理，例如统一编码格式、统一大小写等。
核心目标：保障后续 "分片" 和 "向量化" 在干净的数据上执行，从源头上保证知识库索引的质量。

文档分片

定义与目的：文档分片指将完整长文档按照一定规则切分为多个较小的文本片段（chunk）。

大模型存在上下文窗口大小限制，无法直接处理整篇长文档；

分片后检索时仅返回与用户问题最相关的文本块，而非整篇文档，保障检索精准度与可用性。
整文档不做分片的缺陷

如果直接将整篇文档生成一个向量，检索时会出现两个核心问题：
- 召回不准：文档篇幅过长、语义混杂，匹配时会出现 "多少都有点相关" 的问题，导致回答无法命中重点。
- 上下文占用溢出：检索返回的全文内容体积过大，会挤占大模型的上下文窗口；若超出上下文长度限制，会触发模型报错。
常见分片方式

包含固定大小分片、递归分片（按特殊符号分段）、文档分片、语义分片、智能分片等；所有分片方式的最终目标，都是将完整文档切分为多个独立的文本块（chunk）。

向量化（Embedding）

数据清洗与分片完成后，每个文本块都需要转换为高维数值向量，这个过程即为向量化。向量化的核心目的是：让文本的语义可以被机器理解，并支持相似度比较。

向量的基础概念

数学定义：向量（欧几里得向量 / 几何向量）是具有大小（magnitude）和方向的量，可形象表示为带箭头的线段 ------ 箭头指向代表向量方向，线段长度代表向量大小。
语义向量本质：是一个具备大小和方向的多维数值数组，在大模型体系中，向量的每个维度都对应某一种 "语义特征"。

语义越相似的文本，其向量在高维空间中的 "距离" 越近。
维度示例：
- 一维向量：[3]，对应数轴上从原点到 3 的带箭头线段
- 二维向量：[3, 4]，对应二维平面上从原点到 (3,4) 的带箭头线段
- 三维向量：[3, 4, 5]，对应三维空间中从原点到 (3,4,5) 的带箭头线段

文本转向量的原理

文本转向量的过程也叫做Embedding，本质是通过向量模型将文本 "投影" 到高维向量空间中。

向量的每个维度都代表文本在对应 "语义方向" 上的权重，例如：

第 1 维：是否包含 "人物"
第 2 维：是否涉及 "动作"
第 3 维：是否包含 "时间"

最终每一段文本都会被转换为高维空间中的一个坐标点，从而支持数学层面的相似度计算与比较。

向量相似度计算方法

（1）余弦相似度（Cosine Similarity）

计算公式：
核心逻辑：通过两个向量的夹角判断相似程度，夹角越小，向量越 "同方向"，语义越相似。
取值范围与含义：取值区间为
复制代码
```
[-1, 1]
```
- 1：两个向量方向完全一致，语义高度相似
- 0：两个向量正交，无语义相关性
- -1：两个向量方向完全相反，语义相反
特点与适配：仅关注向量方向，不受向量长度（文本长短）影响，是最常用的文本语义相似度查询方法，特别适配文本语义匹配场景。
行业支持：Milvus、Pinecone、FAISS、Pgvector 等绝大多数向量数据库，都支持并默认使用余弦相似度查询。

（2）欧几里得距离（Euclidean Distance）

核心逻辑：计算高维空间中两个点之间的直线距离，距离越小，相似度越高。
适用场景：主要应用于具备几何意义的场景，例如图像相似度分析，文本匹配场景使用较少。

（3）点积（Dot Product）

计算公式：若向量 (A = $a_1,a_2,a_3$ )，(B = $b_1,b_2,b_3$ )，则
核心逻辑：可理解为两个向量在同一方向上的重叠程度；向量越长、方向越一致，点积数值越大；方向相反时点积为负数，向量垂直时点积为 0。
特点：是最简单、最高效的相似度计算方法，直接计算两个向量的内积；数值越大，代表两个向量越相似。
典型应用：Transformer 的注意力机制，就是通过点积计算注意力权重。

补充：除此之外还有皮尔逊相关系数、杰卡德相似系数等计算方式，在文本相似度场景中应用较少，主流方案为余弦相似度。

相似度匹配直观示例

以二维坐标系简化演示（实际为高维空间）：

已有三个文本对应向量："小明爱吃西瓜""小明喜欢打篮球""今天天气真好"；用户查询 Query 为 "小明爱吃什么？"，对应虚线向量。

"小明爱吃西瓜" 与 Query 向量夹角非常小，余弦相似度接近于 1，语义最相关。
"小明喜欢打篮球" 与 Query 向量夹角较大，余弦相似度低，语义相关度弱。
"今天天气真好" 与 "小明爱吃西瓜" 语义完全不相关，余弦值接近 - 1。

生成索引与向量数据库存储

生成索引的必要性

向量化完成后，每个文本块（chunk）都对应一个高维向量。若仅将向量存储在内存中，无法支持快速查询与比较；因此需要将文本内容与高维语义向量做持久化存储，通过向量数据库构建索引结构，为后续的检索生成环节提供相似度查询能力。

向量数据库

定义：一类专门用于存储、管理和检索高维向量数据的数据库。
与传统数据库的区别：不同于 MySQL 等传统数据库基于 "精确匹配" 的查询逻辑，向量数据库通过计算向量之间的相似度，实现 "语义检索"。

向量数据库存储内容（以 Pgvector 为例）

Pgvector 是 PostgreSQL 的向量扩展版本，单条向量数据包含 4 类核心信息：

embedding_id：主键，作为每条向量数据的唯一标识。
embedding：高维语义向量，承载文本的语义信息，用于索引的相似度匹配查询。
text：原始文本块，是检索后提供给大模型做参考的实际内容；高维向量仅作为相似度查询的索引，大模型需要基于原始文本块才能实现回答效果增强。
metadata：元数据，支持检索时的精准过滤、分组与来源追溯；例如可通过文件名、时间戳等维度过滤，提升特定场景下的检索精准度。

检索生成

检索生成是 RAG 两大流程的第二步，在用户提问时实时处理，完整流程分为

用户提问 → 内容召回 → 上下文融合 → 内容生成四个环节。

用户提问

用户提出具体的问题或请求（例如："本公司某员工本季度绩效如何"），该查询是后续检索、生成全流程的起点。

内容召回

定位与作用：指从知识库中匹配出与用户问题最相关的文本块（chunk），是检索生成的第一步，也是直接影响整个 RAG 系统回答准确性的核心环节。
核心检索方式：向量相似度检索
- 第一步：将用户问题进行向量化（Embedding），得到问题对应的语义向量表示。
- 第二步：在向量数据库中，通过余弦相似度、点积相似度等算法执行相似度查询，匹配出语义最接近的文本块。
- 第三步：返回 Top-K 个检索结果（通常取最相似的 3~5 个 chunk）。

上下文融合

核心价值 ：内容召回仅负责定位相关资料，上下文融合则是让大模型正确使用资料生成答案的关键，该过程通过Prompt（提示词）工程实现，是决定最终回答质量的关键步骤。
实现逻辑：将检索到的相关文档片段，和用户的原始查询拼接组合为一个增强版提示词，最终将增强提示词作为大模型的输入。
标准拼接示例：

根据以下信息回答问题：

[检索结果1] ...
[检索结果2] ...

问题：本公司某员工本季度绩效如何？

内容生成

生成逻辑：大模型接收上下文融合后的增强提示词，依托检索到的知识内容（相当于 "知识外挂"）生成最终回答，可有效减少大模型的幻觉问题。
元数据的附加价值：若知识库元数据中配置了文件名、参考链接等信息，大模型生成答案时可同步附带引用来源、参考链接，进一步提升回答的可信度。

使用 LlamaIndex 构建一个简单的 RAG 系统

LlamaIndex 是一个专为大语言模型设计的数据连接与检索框架，

其核心目标是让 LLM 能够高效、准确地访问和利用私有或结构化 / 非结构化的外部数据。

它在构建基于私有知识库的问答系统、智能客服、文档摘要、RAG（Retrieval-Augmented Generation）等应用中扮演关键角色。

主要功能

数据索引构建：支持将各种格式的数据（如 PDF、Word、网页、数据库、API 等）转换为 LLM 可理解的索引结构（如向量索引、树状索引、关键词表等）。
高效检索：提供多种查询引擎（如向量相似性搜索、混合检索、子问题分解等），从索引中快速找出与用户问题最相关的上下文。
与 LLM 无缝集成：自动将检索到的上下文注入提示（prompt），供 LLM 生成准确、基于事实的回答。
支持多种数据源和格式：内置对文件（PDF、TXT、DOCX）、数据库、Notion、Slack、Web 页面等的支持。
模块化与可扩展：允许自定义文档加载器、文本分割器、嵌入模型、LLM 后端等组件。

核心价值与优势

主要作用

解决 LLM 的 "幻觉" 问题：通过提供真实、相关的上下文，减少模型编造答案。
打通私有数据与通用 LLM：无需微调模型，即可让 LLM 回答企业内部文档中的问题。
简化 RAG 架构开发：封装了从数据加载 → 分块 → 嵌入 → 存储 → 检索 → 生成的完整流程。

为什么要用

开箱即用：几行代码即可搭建一个基于私有文档的问答系统。
灵活性高：支持自定义嵌入模型（如 OpenAI、HuggingFace、本地模型）、LLM（如 GPT、Claude、Llama 3）等。
社区活跃、文档完善：由 LlamaIndex Inc. 维护，更新频繁，生态丰富。
与 LangChain 互补：LlamaIndex 更专注于数据索引与检索，而 LangChain 更侧重于 Agent 和工作流编排，两者常结合使用。

LlamaIndex 使用

python 复制代码

from llama_index.core import VectorStoreIndex, SimpleDirectoryReader
from llama_index.embeddings.dashscope import DashScopeEmbedding
from llama_index.llms.dashscope import DashScope
import os

DASHSCOPE_API_KEY = "sk-xx"

# 1. 加载文档（假设当前目录下有 data/ 文件夹，内含 .txt 或 .pdf 文件）
documents = SimpleDirectoryReader("data").load_data()

# 2. 设置嵌入模型（用于生成向量）
embed_model = DashScopeEmbedding(
    model_name="text-embedding-v2",  # 可选："text-embedding-v1" 或 "text-embedding-v2"
    api_key=DASHSCOPE_API_KEY
)

# 3. 设置 LLM
llm = DashScope(model_name="qwen-max",
                temperature=0.1, api_key=DASHSCOPE_API_KEY)

# 4. 构建索引
index = VectorStoreIndex.from_documents(documents,
                                        embed_model=embed_model)

# 5. 创建查询引擎
query_engine = index.as_query_engine(llm=llm)

# 6. 提问
response = query_engine.query("请总结这份文档的主要内容。")
print(response)

优化方向

尽管以上代码实现了一个简单的 RAG，但是如果想要在生产或高要求场景下使用，还是有很多东西可以优化和增强的

文档分块（Chunking）策略优化
使用持久化向量数据库
查询优化
对话记忆
重排序
混合检索
多模态
RAG 效果测评

范式演进

Naive RAG（基础 RAG）

Naive RAG，也叫基础 RAG，是最基础、最标准的 RAG 实现方式。它完整体现了 "检索 + 生成" 的核心思想，没有加入复杂的优化策略。整个流程简单、直观，是体验 RAG 工作机制的最佳实践。

Advanced RAG（进阶型 RAG）

Advanced RAG 是在 Naive RAG 基础上发展而来的增强版本。它通过引入混合检索与各种优化策略，使 RAG 的召回准确率更高、回答更稳定，也是目前大部分企业生产环境中应用最多的一种 RAG 范式。

常见增强优化手段

混合检索（Hybrid Retrieval）：结合关键词检索（BM25/ES）与向量相似度检索，提升检索精确度；
重排序（Re-ranking）：对召回结果进行语义相关性评分后再重排序，过滤噪声文档，实现 "精筛选"；
上下文压缩（Context Compression）：对长文本进行摘要或关键信息提取，降低大模型的上下文处理压力；
多轮记忆（Conversation Memory）：支持多轮对话，让模型理解上下文语义；
问题重写（Query Rewriting）：挖掘用户问题的深层含义，对用户原始 Query 进行重写，将其改成语义更完整、信息更丰富的检索条件再执行查询。

总而言之，Advanced RAG 是让 RAG 从 "能用" 变为 "好用" 的关键阶段。

Modular RAG（模块化 RAG）

Modular RAG 是目前较新的工程化形态，它强调将 RAG 流程中的各个组件（如查询重写、检索、重排序、上下文融合、生成等）解耦为可独立配置、替换和组合的模块，从而提升系统的灵活性、可维护性和性能。

它将 RAG 的各个阶段（检索、重排、压缩、生成等）模块化封装，通过配置或编排进行灵活组合，实现更高的可维护性与跨任务复用能力。相比于 Naive RAG 的 "单流程"、Advanced RAG 的 "多优化"，Modular RAG 更强调系统的可扩展性、灵活性与可维护性。

典型模块划分

在这种架构中，RAG 通常会被拆分为多个独立模块：

查询转换模块（Query Transformation Module）：对原始查询进行改写、扩展或分解。
检索模块（Retrieval Module）：负责从知识库或外部源中检索候选内容；支持向量检索、关键词检索、混合检索等多种策略。
重排序模块（Re-ranking Module）：基于语义相关性或上下文权重对候选结果进行再排序。
上下文构建模块（Context Builder）：负责筛选、拼接、压缩检索结果，为模型提供最优上下文。
生成模块（Generation Module）：由大模型执行答案生成。
后处理模块（Post-processing Module）：对生成结果进行事实校验、格式优化或引用标注。
路由模块（Routing Module）：根据任务类型动态选择不同模块组合。

模块化设计的场景化价值

这种模块化设计让 RAG 系统具备 "积木式" 的可组合能力，可针对不同任务自由选择和组装模块，例如：

在安全情报场景下，可增加时效性筛选模块；
在法律或医疗场景中，可接入事实校验模块或引用验证模块；
在长文档处理场景，可加入上下文压缩模块。

Modular RAG 的优势

每个模块都可以单独优化或升级，无需重构整个系统，实现持续迭代与灵活扩展。
模块间通过标准化接口进行数据交互，职责边界明确，便于多人协作开发与版本管理。
支持多源异构数据源（如联网数据、知识图谱、API 等）、动态路由与复杂逻辑组合。
具备强大的灵活性，根据不同的任务目标自由组合，即可构建定制化的 RAG 流程。

总之，Modular RAG 让 RAG 从 "好用" 走向 "可扩展"，代表了企业级、系统化 RAG 应用的未来方向。