其实RAG也是智商税，聊聊他与AI知识库的关系

上周写了一篇AI知识库的文章：聊聊与一体机同等级的智商税：AI知识库

事实上，文章对于AI知识库是稍带了点否定的色彩，因为单独的知识库毫无意义，但企业本身并不知道要什么，根据我实际咨询下来，其实他们要的是能借用知识库解决问题的Agent。

只不过，有点尴尬且以外的是：下来后就有10多个粉丝咨询如何搭建知识库的事，最终居然还成了2单，我最终发现，貌似AI知识库也挺好的...

其中，关于咨询知识库的同学，最容易卡壳的地方其实是RAG，他们对这个东西有些一知半解，所以今天我们还是对他进行下简单介绍。

RAG（Retrieval Augmented Generation, 检索增强生成）是一种技术框架。借用之前其他PPT里面的一张图：

其核心在于每次与模型对话的时候，先根据对话的内容，在本地数据库（一般来说是向量库）筛选出于对话相关的素材；

而后将这些素材进行相关整理，一起放到提示词中做模型调用，其目的是为了提升模型的输出质量或者降低模型幻觉。以下是其大概的流程图，包括两个部分，第一是构建向量知识库，第二是检索调用流程。

事实上，极端情况下你如果不想自己做这个工作，完全可以先从DeepSeek获取下相关信息，去ChatGPT调用数据...

unsetunset构建向量知识库unsetunset

RAG的第一步是构建向量知识库，这一步主要是通过将文档或数据转化为向量形式（如通过嵌入模型生成），使得信息能够高效存储和检索。

向量库通常采用例如FAISS、Pinecone等向量检索技术，用于支持快速的相似性检索。

首先，要准备数据源，虽然PDF、Word等格式都可以，但常用的还是接口的方式，结构化的数据比较友好，向量库和模型在数据质量这里都是一样的，吃的垃圾吐出来的一定是垃圾...

所以，基本数据大概率会进行一些数据清洗，比如去除一些无关内容、长文本分段处理、去重...

而后便需要进行文本分块了，这里分块的目的是为了防止文本过长导致的检索噪声，提升检索相关性。

一般来说，有三种分块策略：

1. 固定长度分块：适合通用文本（如每500字符一段）；
2. 语义分块：按段落、句子或主题分割（适合技术文档）；
3. 自定义分块：按章节标题、表格、代码块分割；

怎么说呢，分块的质量也会对检索结果有影响，这里可以人做，也可以AI做，只不过完全AI做的话，可能整个又变成黑盒了...

再进一步便可以进行向量化了，常用的文本嵌入模型有BERT、GPT、Sentence-BERT（SBERT）等。

选择合适的模型时，需要考虑嵌入的质量、计算性能以及任务的要求：

1. BERT / RoBERTa：这类模型在处理上下文信息时表现出色，适用于句子级别的向量化；
2. Sentence-BERT (SBERT)：特别优化了句子级别的嵌入，适合文本相似度计算；

另外也可以选择一些专有模型做向量化，比如医学、法律等垂直领域专用模型（如BioBERT），以下是一段简单的代码：

from transformers import BertTokenizer, BertModel
import torch

# 加载预训练模型和tokenizer
tokenizer = BertTokenizer.from_pretrained('bert-base-uncased')
model = BertModel.from_pretrained('bert-base-uncased')

# 输入文本
text = "This is an example sentence."

# 编码文本
inputs = tokenizer(text, return_tensors='pt')

# 获取模型输出（文本的嵌入）
with torch.no_grad():
    outputs = model(**inputs)

# 获取[CLS] token的输出作为文本嵌入
embedding = outputs.last_hidden_state.mean(dim=1)
print(embedding)

向量生成结束后，便可以存储到向量数据库了，常用的存储和检索工具有：

1. FAISS ：一个由Facebook开发的高效相似性搜索库，支持多种索引方法，适用于大规模向量数据；
2. Pinecone：一个向量数据库服务，提供全托管的向量搜索能力；
3. Weaviate：支持基于知识图谱和嵌入向量的搜索；
4. Milvus：一个开源的向量数据库，专为大规模数据集设计，支持高效的检索和分析；

选择好向量库后，只需要存储进去即可...

import faiss
import numpy as np

# 假设已生成的文本嵌入保存在一个numpy数组中
embedding = np.array([embedding.numpy()])  # 转换为numpy数组

# 创建FAISS索引
dim = embedding.shape[1]  # 向量维度
index = faiss.IndexFlatL2(dim)  # 使用L2距离度量

# 将嵌入向量添加到索引中
index.add(embedding)

# 查询
D, I = index.search(embedding, k=5)  # 查询与当前向量最相似的5个向量
print(I)

至此，整个构建向量知识库就结束了，这也是很多粉丝搞不懂的地方，但其实却非常简单...

因为文本分块策略在构建向量知识库时非常关键，它直接影响到信息的存储和检索效率，这里再简单说说。

unsetunset文本分块unsetunset

在构建向量库时，不同的分块策略适合不同的应用场景，因此在选择分块策略时要根据文本的特点、任务要求和数据的规模来权衡。

固定长度分块

固定长度分块（例如，每500字符或1000字符为一段）通常比较简单，适用于不需要特别考虑上下文的场景。

由于每个块的长度相同，检索时可以快速地进行向量化和匹配。

但这种粗暴的做法可能导致的问题也不少：

第一，固定长度的文本分块无法保证文本的语义完整性，尤其在包含多个复杂概念的长段落或多轮对话中。

分块可能会将相关的句子分割成不同的块，导致语义的中断或上下文信息丢失。

第二，无法处理结构化信息，对于一些需要更细致语义理解的任务，固定长度分块可能不适用，因为它忽略了语境中的语法、句法和主题信息。

综上，在简单的文档检索场景下固定长度分块是比较常用的（比如外包场景...）。

语义分块

语义分块通过分析文档中的段落、句子或主题来确定分块的位置，这样每个分块会包含完整的语义单元，避免了像固定长度分块那样的语义丢失问题。

对于具有较为复杂和多样化内容的文档，语义分块能够更好地捕捉上下文信息，如技术文档、论文、长篇文章等。

只不过语义分块依赖于对文本的深入理解，可能需要模型来分析和划分文本，这增加了计算成本和实现难度，还有知识碎片化等问题，但一定会比固定分块好。

他比较适合涉及复杂概念和多层次知识的文档，语义分块可以确保每个分块包含完整的知识单元。

自定义分块

自定义分块允许根据文本的具体特点来选择分块方式，比如按章节标题、代码块、表格等进行分块，这样能够精准地控制分块的方式，使得每个分块都能最大程度地保留文档的结构和逻辑。

这种方式虽然效果好，但需要对文档进行深入的分析和处理，尤其是针对不规则格式的文档，分块规则可能需要进行动态调整。

对于结构化文档（如法律合同、技术手册等），自定义分块可以最精确地保持原文结构并提高检索效率。

其次，很多粉丝对向量化的过程以及模型调优的意义是什么不太明白，这里也做简要说明。

unsetunset模型调优unsetunset

这里举个例子，假如我们有一段医学文本：患者诊断为糖尿病，使用胰岛素治疗并定期监测血糖水平。

对于这段文本，若我们直接使用一个在通用语料上预训练的模型（例如BERT），模型可能会将其转化为一个向量，但这个向量所捕捉到的医学特征可能不够精确，因为BERT是基于大量的非专业文本进行训练的，可能没有在医学文本上见过很多具体的医学术语。

这里可能的问题是：预训练的BERT模型会理解“糖尿病”这一词汇，但它不一定能精确理解胰岛素治疗或血糖监测这些医学术语背后的具体含义。

模型可能无法准确捕捉到“胰岛素治疗”和“血糖监测”之间的关系，或者它可能没有很好地理解它们在临床环境中的重要性。

所以，如果业务场景是医疗行业，便有两个选择：

1. 第一，选择垂直医疗模型做向量化；
2. 第二，对模型进行领域微调；

通过将模型暴露于大量的医学文献或病例报告中，使其能够学习到更多医学领域的知识和术语。

微调的过程中，模型将专注于如何更准确地表示医学专业术语及其关系，从而优化“糖尿病”、"胰岛素"和“血糖监测”这些概念之间的向量表示。

向量化本质上是信息转换，即将文本转化为固定维度的向量，模型本身并不会增加或减少信息。

然而，向量化过程的效果高度依赖于模型对文本的理解能力，特别是在专业领域或特定任务中。

这里模型调优的作用就体现出来了：让你的向量知识库更精准，毕竟好的输入才有好的输出。

这里再举个例子，如果当前公司要做一个内部知识库，期望使用RAG技术，那么直接去做向量化，很可能效果很差，其原因是向量化的过程中，模型根本不认识公司那些黑话！

这里最后再多嘴一句：向量化过程中，核心是对知识的整理和编码，而检索过程中则通过向量之间的相似度来找出最相关的内容。让我再详细地解释一下这个过程。

向量化的核心：知识的整理与表示！

向量化的目标并不是单纯地将单一的句子转化为一个向量，而是将文本中包含的知识和信息通过模型转化为高维向量（嵌入）。

这些向量不仅仅反映了每个词的字面意义，还包含了词之间的关系、上下文信息以及相关的背景知识。

在专业领域的向量化（如医学领域）时，向量不仅会表达单个词汇的意义，还会将相关概念之间的关系编码在向量中。

例如，“胰岛素治疗”这个概念在向量空间中会被表示为一个包含多个层面信息的向量，它可能包括“胰岛素”、“血糖控制”、“糖尿病管理”等相关知识。

这种向量会将这些信息整合在一起，而不仅仅是对一个单独的词或句子的简单表示。

这也就是为什么专业模型（如BioBERT）能更好地表示医学领域的知识，因为它会学习如何将医学术语之间的复杂关系和领域知识嵌入到向量中。

所以，在做向量化之前，可能还需要整理大量的文档对模型进行微调...

而这里就引出了RAG最核心的问题：既然RAG需要微调效果才能好，那我直接用微小调模型替代RAG就好了，为什么还要用向量知识库呢？

unsetunset微调 VS RAGunsetunset

怎么说呢？RAG和模型微调本质上是两种互补的技术路线，而非非此即彼的关系。

它们的取舍取决于具体场景需求，有几个核心点：

一、动态知识库

RAG的向量库可以随时更新（例如新增文档、修正错误），无需重新训练模型。例如：

1. 企业知识库每天新增100篇文档，只需增量更新向量库，检索时自动包含最新内容；
2. 医疗指南每年更新，RAG可直接替换旧版向量库，无需调整模型；

二、零样本学习

RAG通过检索外部知识（比如联网），能回答模型从未见过的领域问题（如新兴技术术语）。

反而微调更依赖精通数据，更新起来不如RAG技术灵活，这里还要考虑训练数据外的边缘数据不被识别的长尾问题。

综上，虽然RAG效果好依赖于模型调优，但他在知识高频更新、需覆盖长尾问题的场景（如客服系统、法律咨询）更友好。

而，垂直基座模型是比较多的，而且这个数据怎么都不会被浪费，微调算是一次性工作。

三、知识容量与模型能力问题

向量库可存储TB级文本（如全部医学文献），而模型参数通常仅容纳GB级知识。

另一方面，虽然可以去微调参数小的模型，但我们知道逻辑上参与越大模型能力越强...

四、可靠性

另一方面，RAG的答案可追溯。

他是基于检索到的文档片段，可标注引用来源（如“根据2023年《XX指南》第5章...”），适合法律、医疗等高风险场景。

这真的是没有幻觉的，而模型幻觉这个是没法避免的，不能持续在AI应用上加黑盒。

接下来，我们来聊聊检索问题...

unsetunsetRAG检索unsetunset

RAG的核心优势之一在于通过检索机制增强生成模型的输出。

检索部分的基本任务是根据当前的查询内容，从知识库中快速找到与之最相关的信息，该过程通常包括以下几个主要步骤：

一向量检索

向量库中的每个文档或数据片段都有一个相应的向量表示，这些向量会在检索过程中作为查询的候选集。

当查询向量被生成后，系统会通过相似度计算（例如，余弦相似度或L2距离）将查询向量与向量库中的每个文档向量进行比较，从而找到最相似的文档。

这些文档就是最相关的候选材料，后续将作为生成模型的输入。

二、排序与过滤

检索到的文档并不一定都与查询内容高度相关，这里涉及到了召回率。

因此，检索后的文档还需要进行排序和过滤，这一过程中，我们通常会根据文档与查询之间的相似度分数、文档来源的权威性、上下文的一致性等标准对文档进行排序。

最终，最相关的几个文档会被选中，作为输入传入生成模型。

三、重组提示词

对检索到的文档进行处理，注入到提示词中，模型通过结合检索到的文档信息和查询的背景，生成最终的回答或文本。

由于生成模型在此时已有大量外部知识作为背景支撑，能够有效降低模型幻觉的发生，提升生成的准确性和可用性。

检索出来其实也会有很多优化策略，但是其核心依旧是在构建向量知识库那里，这里后续大家慢慢理解吧...

unsetunset结语unsetunset

今天，我们简单探讨了AI知识库的构建与RAG技术的应用，重点分析了如何通过向量化和检索机制提升AI模型的表现，并解决模型幻觉的问题。

通过精确的文本分块和向量化过程，我们能够在大规模数据中提取相关知识，确保AI能够提供更精准、更可靠的回答。

另外，在RAG的基础上后续又提出了KAG，以及近期模型增强后甚至有大模型上下文具有惊人的100M，在这个趋势下，也许向量化的意义正在降低...