写在前面
春节前后事情扎堆，工作和生活都忙得不可开交。好不容易喘口气，我就动手折腾了一个与 RAG 相关的小项目。
项目规模不大，但完整走一遍流程之后，我对 RAG 的理解确实清晰了不少。所以想写几篇文章，试着用大白话把 RAG 这件事讲清楚。
如果你对这个词感到好奇，或者想深入了解它如何运作，希望这个系列能给你带来一些实实在在的启发。
本篇是系列的上篇，主要聚焦于 RAG 是什么、为什么需要它，以及其最核心的基础——离线数据处理的关键步骤。下篇则会详细拆解在线检索与生成的环节。
01 先认清现实：大模型的能力边界
在深入探讨 RAG 之前，我们有必要先达成一个共识：以 ChatGPT、文心一言等为代表的大语言模型，并非全知全能的神仙。
它们至少存在三个明显的短板：
| 问题类型 |
具体表现 |
| 不知道私有信息 |
你们公司的内部制度、未公开的产品规格文档，模型在训练时从未见过，自然无法给出准确回答。 |
| 会产生“幻觉” |
模型可能会“一本正经地胡说八道”，生成看似合理但事实错误的答案，这是目前大模型公认的技术难题。 |
| 垂直领域深度不足 |
面对医学、法律、金融等高度专业化的问题时，其回答可能停留在科普层面，缺乏专业深度和准确性。 |
那么，如何弥补这些缺陷呢？思路很直接：给模型“开小灶”，为它提供相关的“参考资料”。这种“先检索资料，再基于资料生成答案”的技术框架，就是 检索增强生成（RAG）。
02 RAG 到底是什么？一句话讲清
RAG，全称 Retrieval-Augmented Generation，中文译为“检索增强生成”。这个名词听起来有些高大上，但核心思想一句话就能说清：
让大模型先查资料，再回答问题。
整个 RAG 的工作流程通常分为两个相对独立的阶段：
| 阶段 |
核心任务 |
通俗比喻 |
| 离线数据处理 |
提前将各类文档资料进行整理、处理，构建成结构化的“知识库”。 |
相当于把常见问题与答案汇编成一本《标准答案手册》。 |
| 在线检索匹配 |
当用户提问时，系统先从知识库中检索出最相关的资料片段，再将这些片段连同问题一起交给大模型生成最终答案。 |
如同客服接到问题后，先翻阅手册找到依据，再组织语言回复客户。 |
本文将重点解析 离线数据处理 这一阶段，即如何将你手中的原始资料，转化为大模型能够高效利用的“知识库”。
03 场景代入：一个客服的“效率革命”
为了更直观地理解，让我们代入一个具体的场景。
🎬 场景设定：你是一名客服专员
假设你是公司的客服人员，每天需要处理大量客户咨询。很快你发现，许多问题其实是重复的：
- “产品怎么退货？”
- “保修期是多久？”
- “如何申请开发票？”
于是，你做了一个聪明的决定：将常见问题及其标准答案整理成一个 Excel 表格。以后再遇到同类问题，直接复制粘贴，效率大大提升。
😫 遇到的新问题
然而，随着时间推移，新的烦恼出现了：
- 表格越来越长，每天在浩瀚的行列中搜寻答案，视觉疲劳严重。
- 客户的提问方式五花八门，明明答案就在表里，却因为关键词不匹配而搜不到。
- 维护成本变高，每次产品更新，都需要手动同步多个地方的答案。
这时你可能会想：要是能有个 AI 助手，能自动理解问题、精准查找表格并生成回复，该多好？
🎉 RAG 登场！
此时，RAG 技术恰好能完美地解决你的痛点。它正是为了实现“基于专属资料库的智能问答”而设计的。那么，具体如何利用 RAG 来改造工作流呢？关键在于第一步：把散乱的资料变成 AI 能理解的“知识库”。
04 离线数据处理：打造专属知识库的四步法
第一步：收集原材料
首先，你需要汇集所有可能用到的资料，这些就是知识库的“原材料”。通常包括：
- 你积累的《常见问题 & 标准答案》Excel 表格。
- 公司产品的官方说明书、技术文档（PDF、Word格式）。
- 产品图片、宣传册等其他相关材料。
第二步：文档解析——让机器“读懂”资料
收集来的资料格式各异，机器需要统一“理解”它们。这一步主要是格式转换：
| 文件类型 |
典型处理方式 |
| 图片（扫描件、截图） |
使用 OCR（光学字符识别）技术，提取图片中的文字信息。 |
| PDF / Word / 网页 |
将其内容转换为 Markdown 或纯文本格式。 |
为什么偏爱 Markdown？ 因为 Markdown 的标题、列表、代码块等语法自带清晰的结构信息，能帮助大模型更好地理解文档的层次和重点，有利于后续的检索与理解。
第三步：文档清洗——去除杂质与噪音
解析出来的文本往往包含一些“杂质”，影响后续处理质量，需要进行清洗：
- 冗余格式：多余的空格、无意义的换行符。
- 识别错误：OCR 过程可能产生的错别字（如“已”识别成“己”）。
- 无关内容：文档的页眉、页脚、广告等与核心业务无关的信息。
- 乱码与特殊符号：转换过程中产生的无法识别的字符。
清洗的目的在于获得干净、规整的文本数据，减少检索时的干扰，提升准确性。
第四步：文档分块——决定成败的关键步骤
这是离线处理中最重要、最需要技巧的一环。分块策略的好坏，直接决定了后续检索效果的上限。
为什么要分块？
- 提升检索精准度：如果直接将一整篇长达数十页的文档存入知识库，当用户提问一个具体细节时，检索系统相当于在“大海捞针”，很难精准定位到包含答案的特定段落。将文档切成语义连贯的小块后，检索目标更明确，命中率更高。
- 适配模型上下文限制：大模型有固定的“上下文窗口”（即一次能处理的最大文本长度）。将超长的文档直接送入模型，它可能“顾头不顾尾”，无法有效利用全部信息。将信息分块输入，确保每次提供给模型的上下文都在其能力范围内。
分块有哪些实用技巧？
| 核心原则 |
具体解释 |
举例说明 |
| 保证语义完整性 |
尽量确保一个“块”包含一个相对完整的语义单元或主题。 |
✅ 正确：将“退货政策”整个小节作为一块。
❌ 避免：把“退货需在商品签收后7天内提出……”这句话从中间切断分到两个块。 |
| 使用重叠窗口 |
相邻的块之间可以保留一小部分重叠内容（如前一块的后两句作为下一块的开头），这有助于模型理解上下文之间的关联，防止信息割裂。 |
块1结尾：“……以上是会员等级说明。”
块2开头：“会员等级说明。不同等级享受的权益如下：……” |
| 特殊内容整体保留 |
对于代码片段、表格、数学公式等具有严密结构的内容，应尽量保持其完整性，单独成块。 |
✅ 正确：将一段完整的函数定义和实现代码放在一起。
❌ 避免：把函数声明和函数体分割到两个不同的块中。 |
重要提醒：分块没有“标准答案”
⚠️ 必须认识到，不存在一个适用于所有场景的“黄金分块规则”。业务类型、文档性质、问答形式的不同，都会影响最佳的分块大小和策略。
例如，技术API文档可能适合按函数/接口分块，而一篇分析报告可能适合按章节分块。这是一个需要结合业务实际进行反复试验和调优的过程。多尝试不同的分块大小、重叠策略和切分依据（按段落、按标题、按句子），并通过实际的问答效果来评估和选择最优方案。在构建复杂系统时，可能会借助 LangChain 等框架提供的多种文本分割器来实验。
05 小结回顾
我们来梳理一下本篇的核心内容：
- 正视局限：大语言模型存在知识盲区（私有信息）、幻觉问题和垂直领域深度不足的短板。
- 理解 RAG：RAG 是一种“检索+生成”的框架，通过先检索相关资料再生成答案，来弥补大模型的上述不足。其流程分为离线的知识库构建和在线的检索生成两大部分。
- 掌握离线处理四步法：这是构建 RAG 系统的基石。
- 收集：汇集所有相关的原始资料。
- 解析：通过 OCR、格式转换等方式，让机器可读。
- 清洗：去除文本中的噪音和无关信息，保证数据质量。
- 分块：将长文档切分为语义完整的片段，这是影响后续检索效果最关键的一步，需根据业务场景精心设计和调试。
06 下篇预告
本篇详细讲解了如何“磨刀”——即离线准备知识库数据。这是整个 RAG 系统能够高效、准确运行的基石。
在下一篇中，我们将深入“砍柴”的环节——在线检索与生成。届时将探讨：当用户提出一个问题时，系统如何从知识库的海量文本块中快速找到最相关的内容？又如何将这些内容巧妙地组合并交给大模型，最终生成一个准确、流畅的答复？
如果你在构建自己的知识库过程中遇到了具体问题，或想了解更多实战技巧，欢迎在 云栈社区 的 技术文档 板块与更多开发者交流讨论。敬请期待下一篇章。
发表于 1 小时前
|
查看: 2|
回复: 0
