【收藏起来】六步搞定RAG系统：构建AI的“记忆宫殿“，解决大模型痛点

原创于 2025-11-04 13:00:00 发布 · 1k 阅读

CC 4.0 BY-SA版权

文章标签：

本文详细介绍了RAG（检索增强生成）技术的实战构建过程，通过六步流程（文档加载、文本分块、信息嵌入、向量存储、信息检索、答案生成）解决大语言模型的"幻觉"和"选择性失忆"问题。作者提供了完整的开源实现，让读者能够亲手构建属于自己的RAG系统，为AI添加外部记忆能力，使回答更加准确可靠，并能够基于特定知识库进行推理。这不仅是技术教程，更是通往更强大、更可信AI应用的关键一步。

蓝图：构建一个RAG系统的六脉神剑

在动手之前，我们先回顾一下RAG系统的核心流程，整个过程可以清晰地分为六个关键步骤：

文档加载 (Loading)： 为AI“喂食”知识，这是所有智慧的源头。
文本分块 (Splitting)： 庖丁解牛，将大块知识“切片”，方便AI消化。
信息嵌入 (Embedding)： 将文字翻译成AI能懂的“密码”——向量。
向量存储 (Storage)： 为这些“密码”建造一座高效的“记忆宫殿”。
信息检索 (Retrieval)： 当问题传来，精准地在宫殿中找到相关线索。
答案生成 (Generation)： 让AI拿着“参考资料”开口说话，给出最终答案。

接下来，让我们卷起袖子，逐一攻破这六大关卡。

第一步：文档加载

万丈高楼平地起，RAG系统的地基，就是高质量的知识源。如果源头的数据都无法被正确解析，那么后续无论模型多强大、算法多精妙，都只是在“垃圾”上做文章，结果自然是“垃圾进，垃圾出”。

在我构建的这个RAG系统中，我设计了两种“喂食”路径：

本地投喂：直接从你的电脑目录中批量加载文件。
网络爬取：给定一个网址，系统会自动抓取网页内容。

一个关键的设计决策是：无论源文档是PDF、Word还是HTML，我选择将它们统一解析成Markdown格式。

为什么是Markdown？因为它不仅仅是纯文本，它保留了文档的结构化信息（如标题、列表、粗体等）。这就像给AI的食物不仅有营养，还分好了主食、配菜和汤，后续进行“文本分块”时，我们就能利用这些结构信息，切分得更合理、更符合语义。

实战小贴士：在真实项目中，你会遇到各种“千奇百怪”的文档格式。通用的解析方案是起点，但针对特定格式（如复杂的财务报表PDF）进行深度定制的解析，是提升最终效果的必经之路。

第二步：文本分块

文档成功加载后，我们得到了一篇篇完整的长文。但大模型就像一个“短期记忆”的学生，一次性塞给他太多东西，他会记不住、也无法聚焦。因此，我们需要对知识进行“切片”处理。

为什么必须分块？

聚焦主题：让每个文本块尽可能只讨论一个核心主题，避免信息交叉干扰。
突破限制：每个大模型都有其上下文窗口（Context Window）的长度限制，分块可以确保输入内容不“超载”。

分块不是简单地“一刀切”，不同的切法，效果迥异。以下是几种主流的“刀法”：

按页分块 (Page-based)： 简单粗暴，适合保留原始版面（如PDF页码），但容易割裂上下文。
固定大小 (Fixed-size)： 像用模具切饼干，保证每块大小均匀。缺点是可能在句子或段落中间无情地“腰斩”，破坏语义完整性。
按结构分块 (Recursive/Semantic)： 这是更高级的“刀法”。它会尊重文本的自然结构，优先按段落、再按句子进行切分。这种方式能最大程度地保留语义的连贯性，是我在这个项目中主要采用的策略。
按语义分块 (Semantic-based)： 终极“刀法”，借助AI的理解能力来识别文本的语义边界。它能更好地处理主题切换、逻辑关联，确保每一块都是一个“意义单元”。

选择合适的分块策略，是决定检索质量的第一个关键胜负手。

第三步：信息嵌入

文本块准备就绪，现在我们要把它们翻译成AI能理解的语言。这种语言不是英文也不是中文，而是一种数学语言——向量（Vectors）。

这个翻译过程，我们称之为信息嵌入（Embedding）。

你可以把嵌入模型想象成一个超级翻译官。它阅读每一个文本块，然后将其内涵的“意义”映射到高维空间中的一个具体坐标点。这个坐标点，就是向量。在这个空间里，意思相近的文本块，它们的坐标点也彼此靠近。

在这个RAG系统中，我集成了灵活的嵌入模型选项，给予你充分的选择权：

商业API模型：如OpenAI的text-embedding-3-large，效果出众，按量付费。
开源本地模型：如Hugging Face社区的sentence-transformers，或是国内顶尖的BGE、通义千问（Qwen）系列模型。这些模型可以免费部署在本地，保障数据私密性，但需要一定的硬件资源。

通过切换不同的嵌入模型，你可以直观地感受到它们在语义捕捉能力上的细微差别，这是一个非常有价值的对比实验。

第四步：向量存储

现在，我们手握成千上万个代表知识的向量。下一步，就是为它们建造一座能够被快速检索的“记忆宫殿”——向量数据库（Vector Database）。

向量数据库的核心能力，就是在亿万个向量中，光速找出与目标向量最“相似”（即空间距离最近）的那些。

选择哪座“宫殿”，取决于你的需求和场景：

轻量级选手 (适合入门与原型)：

Faiss：Meta出品，快如闪电，是一个纯粹的相似性搜索库，非常适合在本地快速验证想法。
Chroma：为开发者体验而生，主打“开箱即用”，让你能以最少代码启动一个向量存储服务。

生产级巨头 (适合大规模部署)：

Milvus：云原生、分布式设计，为海量数据和高并发场景而生，是构建企业级RAG的可靠选择。

我的建议是：在开发和调试阶段，使用Faiss或Chroma，它们能让你把精力聚焦在流程本身。当你的系统准备好走向生产环境时，再无缝切换到像Milvus这样更健壮、可扩展的数据库。

第五步：信息检索

万事俱备，只欠东风。当用户提出问题时，激动人心的“寻宝”时刻到来了。

我们的系统会做两件事：

将用户的问题也通过同一个嵌入模型，“翻译”成一个查询向量（Query Vector）。
拿着这个查询向量，冲进我们的“记忆宫殿”（向量数据库），寻找与之最相似的文本块向量。

这个过程就像在巨大的图书馆里，根据一本书的“风格”和“主题”，迅速找到书架上与它最匹配的其他几本书。

为了让“寻宝”过程更可控，我设置了几个关键的调节旋钮：

返回数量 (Top-K)： 指定返回最相关的几个结果。我通常默认设置为3，这意味着为AI提供3条最关键的参考线索。
相似度阈值 (Similarity Threshold)： 设定一个“相关度”门槛，比如50%。只有相似度得分高于这个值的文本块才会被召回，有效过滤掉不相干的噪音。
最小字数 (Minimum Characters)： 避免返回一些过于零碎或无意义的短文本片段。

这些参数的微调，对最终生成答案的质量有着直接且显著的影响。

第六步：生成答案

我们手上已经有了与用户问题最相关的几段“参考资料”。最后一步，就是让大模型（LLM）这位“总指挥”登场。

系统会自动构建一个精巧的提示词（Prompt），它的结构通常是这样的：

# 指令
请根据下面提供的上下文信息，简洁、准确地回答用户的问题。
如果上下文中没有足够信息，请直接说“根据现有资料，我无法回答该问题”。
# 上下文信息
[这里会插入从向量数据库中检索到的文本块1]
---
[这里会插入从向量数据库中检索到的文本块2]
---
[这里会插入从向量数据库中检索到的文本块3]
# 用户问题
[这里会插入用户的原始问题]

这个过程，完美模拟了我们人类的**“开卷考试”**。LLM不再是凭空“记忆”来回答，而是基于我们提供的、高度相关的上下文信息来进行总结、推理和组织语言。

这不仅极大地降低了“胡说八道”的概率，更让它有能力回答那些它“从未学过”的、特定于我们知识库的问题。

同样，生成答案的LLM也可以自由配置，无论是调用外部API还是使用本地部署的模型，你都可以接入进来，比较不同模型在“阅读理解”和“语言组织”能力上的表现。