一、RAG的基础概念
1.RAG是什么？
RAG即Retrieval（检索） Augment（增强） Generation（生成），就是如单词所示，分为三个步骤来进行。
2.为什么需要RAG？
1.企业内部有很多不可以公开的信息文档，仅限内部使用，如果需要针对特定的需求去做一个大模型，是很有必要针对企业内部的信息建立一个知识库，方面内部使用的。
2.假设如今使用一个LLM的商用大模型，它的训练都说一些通识，针对某些特定的领域和需求其实是很不完善的，这时候使用这些大模型得到的回答质量就会很低。假如你把一个几千页的需求文档，丢上去，Token如流水，这样完成事情的成本也高的离谱。
就这两条原因，搭建一个内部的知识库是非常有必要！
3.RAG的工作流程
既然要建立自己的知识库，肯定得输入自己内容的知识，所以第一步肯定就是准备自己私有的知识内容。
（1）数据准备------分片和建立索引
这一步，我们不可能把一整个文档丢进去，这样上下文早就爆炸了，因此我们需要对一些数据进行分片和建立索引
这个方式就有很多，我们可以按照字数来切、按照段落来切、甚至按照章节来切，将 PDF、Markdown、Word 等格式的文档提取为纯文本，并按固定长度或语义段落切割成独立的"文本块"（Chunk）。设置重叠度（Overlap）防止上下文信息中断。
切完之后为了方便模型检索，肯定需要建立索引，利用 Embedding 模型（如 bge-large-zh、text-embedding-3）将文本块转化为多维向量，从而捕捉语义关系。
因为我们最终的目的是让大模型能看得懂 不是人能看得懂，所以对于分好切片和添加好索引后的数据，我们需要做一个向量空间的转化，这个过程就叫做Embedding（索引）。
关于Embedding的概念，大家可以上网搜索详细了解，这里就不过多赘述。反正其核心目的就是让语义相近的词语让它们空间中更加接近
经过Embedding后，我们的向量数据库就相当于建立完成了
以上核心目的就是将很长的文章和文档转化为模型便于管理的碎片知识，防止上下文爆炸。
建立好我们的向量数据库后，后面我们向大模型提问问题。
用户提问时，通过余弦相似度找到关联度最高的文本块；再结合 Reranker（重排模型）剔除干扰信息。就类似于模型就会在内部解一道数学题，即计算相似度，来找用户问题最接近的答案，即挑选出评分最高、与用户问题接近的top K个文本片段，再把这Top K个片段单独取出来（此过程叫做召回和重排）
然后将这Top K个片段作为Context与用户的问题打包再一起，组成一个Prompt提示词，在 System Prompt 中加入限定语句（如"仅基于提供的资料回答，若资料中无相关信息请回答不知道"），极大降低大模型幻觉率。然后结合这个提示词与精准的资料，给出一个靠谱的答案（这个过程就叫做增强与生成）
这个就是RAG的整个流程了
看上去很简单是吧，但是别急，一堆坑等着我们。
2.RAG落地的难点
1.文档解析
现实中的文档不仅仅是纯文本，更多是扫描件、PDF、PPT，其中包含了大量的表格和复杂的图表（如电路图）。
传统的文本提取器在面对这些版面时，往往会将表格拆得七零八落，变成毫无逻辑的字符乱码。
左侧展示了使用"标准解析器（Standard Parser）"处理一份含有表格和电路图的文档。结果是一堆毫无语义的字符噪音（""#... Null... Error""），原始的逻辑结构完全丢失。
右侧则是解决方案：采用专用版面分析模型 + Custom OCR + RLHF，成功识别了表格结构，并将电路图也转化为结构化的文字描述。"
落地痛点：
-
表格数据丢失： 比如财务报表，传统解析一锅端，LLM 根本不知道哪一列对应哪一行。
-
非文本信息缺失： 产品手册里的结构图、原理图是核心知识，如果无法解析为文字，系统对这块知识就是"盲区"。
-
噪音干扰： 解析出的乱码会被当做知识存入，直接污染知识库。
2.颗粒度
我们无法将整本手册直接喂给 LLM，需要将文档"切片"（Chunking）。切太大了，噪音太多，LLM 找不到重点；切太小了，语义就会碎片化，上下文丢失。
图中显示了一把剪刀（象征切片策略）将一段文字从中间切断。第一部分是"关于张三的故事..."，第二部分是"...他去了商店..."。
问：这里的"他"是谁？ 答案在第一部分，但因为被切开了，第二部分就成了无主句，产生了"语义链接丢失（Semantic Link Lost）"和巨大的红色问号。
落地痛点：
-
代词指代不明： 就像图中例子，"他、它、该公司"如果切到了相邻的 Chunk，检索回来的 Chunk 就失去了准确语义。
-
逻辑割裂： 一个完整的步骤（如：1. 打开电源；2. 按启动键）如果被切分在两个不同的向量里，用户问"如何启动"时，可能只能检索到步骤2，导致回答不完整。
-
噪音： 切太大，比如整页切，用户问一个具体小问题，检索回来几千字无关内容，干扰 LLM 生成。
3.检索准确率
朴素RAG仅仅依靠简单的向量相似度检索（Naive Rag），在面对海量或相似知识时，召回的内容往往不够精准，甚至召回一堆不相关的内容。
落地痛点：
-
语义混淆： 不同产品手册里可能都有"重置系统"的方法。用户问"如何重置"，朴素检索可能召回了不相关型号产品的重置方法。
-
精准度决定生死： 如图片配文所说，"检索准确率直接决定了 RAG 结果的生死"。找错了知识，LLM 再强大也只能一本正经地胡说八道。
-
需要二次精筛： 仅仅靠 Embedding 距离还不够，必须通过混合检索（加上关键词）和 Rerank（重排模型）来提高 Top-K 的含金量。
4.用户提问的模糊性
我们假设用户会精准描述问题，但现实中，用户往往是口语化、指代不明、语义模糊的。
系统必须进行查询重写（Query Rewrite），利用上下文和 LLM 将其转化为右侧绿色框的可执行查询
落地痛点：
-
口语化： 用户的提问往往不带专业术语，如问"手机不亮了怎么办"而不是"手机屏幕故障排查"。
-
多轮对话指代： 连续对话中，用户会说"那它的续航呢？"（这里的"它"指代上一轮对话的产品），必须结合上下文补充完整。
-
意图重构： 必须将用户的模糊意图转化为对知识库有效的结构化查询，否则检索回来的内容将毫无用处。
总结
正如"RAG冰山模型"所示，真正的技术壁垒并不在于水面之上的架构搭建或 Demo 演示，而深深隐匿于水面之下的工程细节中。
一个高可用、真正落地的 RAG 系统，其核心竞争力取决于数据清洗的净度、分片策略的精度、多路召回的广度以及持续工程调优的深度。
本视频的截图全部来自学习课程