RAG Retrieval-Augmented Generation 大模型检索增强生成一、为什么需要RAG？1.1、LLM的三大局限知识截止日期 Knowledge Cutoff训练数据有截止时间，模型无法感知新时间，询问最新信息时一无所知幻觉问题 Hallucination自信地输出错误信息，编造不存在的引用来源，无法区分已知与猜测上下文窗口有限 Context Window单次对话长度受限，无法直接塞入整个知识库，长文档需截断丢失信息核心矛盾：LLM的知识是静态且有限的，但现实世界的信息是动态且海量的1.2、传统方案的局限：Fine-tuning能解决吗？做法：把新知识重新训练进模型参数问题：训练成本极高更新周期长，无法实时容易遗忘原有能力需要大量标注数据RAG的解法：检索时带入真实文档–模型基于真实作答，而非凭空生成做法：检索外部文档，注入Prompt让模型参考作答优势：无需重新训练，即插即用知识库可实时更新答案可追溯到原始文档可灵活切换知识来源最佳实践：先用RAG快速验证价值，确认效果后，再考虑Fine-tuning优化表达风格如果说sft的效果与rag一致或者更优，则使用sft更好，因为sft不需要外挂一个rag，也就是不需要额外的运行资源，效率也会更高sft对大模型的要求没有rag的要求那么高。因为rag需要使用大模型进行总结。但是sft是专项训练好的，则不一定需要大模型，可以是小一点的大模型即可1.3、RAG的核心思路：查完资料再作答直觉类比：纯LLM，是闭卷考试只靠记忆作答若知识没有背过-编答案无法应对新题型RAG 开卷考试先查阅参考资料找到相关段落后作答答案可追溯原文出处RAG三个核心步骤索引 Index把知识库切片、向量化；存入向量数据库备查检索 Retrieve用户提问时，找出最相关的top-k文档片断生成 Generate将检索到的内容塞入Prompt，让LLM参考作答RAG = 让LLM站在实时知识库的肩膀上回答问题1.4、RAG整体架构总览完整流程分为：Indexing Pipeline 离线 和 Query Pipeline 在线。共享向量库。Indexing Pipeline 离线，一次性构建知识库原始文档（PDF/HTML）–文档加载（Loader）–文档分块（Chunking）–向量化(Embedding)–向量数据库（Vector Store）Query Pipeline 在线，用户每次查询时执行用户提问(Question) -- 查询向量化(embed) -- 相似检索(Retrieve) -- Prompt构造(Augment) -- LLM生成最终答案疑问：实际项目工程化的时候，是否每次请求LLM之前，都先做RAG呢？1.5、三种方案对比：何时用RAG？维度纯LLM+PromptFine-tuningRAG知识时效性 截止训练日期 重训才能更新 实时更新实施成本 零成本 高（GPU训练） 中（构建索引）知识容量 有限（上下文） 参数容量上限 几乎无限答案可追溯 无 无 可追溯原文幻觉风险 高 中 低适用场景 通用轻量问答 特定风格/格式调优 知识密集型问答二、知识库构建2.1、数据来源：知识库里可以放什么？非结构化文本(最常见)PDF/Word/TXT网页HTMLMarkdown文档邮件/会议记录结构化数据(需转文本)数据库表格（SQL）CSV/ExcelJSON/XMLAPI响应数据多模态内容（进阶方向）图片中的文字（OCR）表格截图图表说明（Caption）音频转文本对话与日志（高质量源）历史对话记录工单/反馈代码注释/文档知识问答对(QA)实践原则：先从最易解析的来源（PDF/TXT）开始，逐步扩展到结构化和多模态2.2、文本分块（Chunking）：为什么分块？怎么分？分块RAG效果最敏感的环节之一 — 块太大失去精准度，块太小丢失上下文为什么要分块？向量模型有输入长度限制精准检索需要粒度细的语义单元避免将整篇文档塞入Prompt（上下文 = 钱）Overlap（重叠窗口）是什么？相邻两块之间共享部分文字，防止关键信息被切割点截断。例：块1结尾64字符 = 块2开头64字符。三种分块策略对比固定大小分块实现简单、速度快可能截断句子破坏语义语义感知分块按段落/句子自然分割。这种的比较好，只是切分时需要调用大模型，进行语义切分。成本高、速度慢，但是效果可能是最好的。块大小不均，处理慢递归字符分块最常用，兼顾速度与质量。例如：第一章、第一节、第一小节 这种文档内的递归性的标志性信息，进行切分。依赖分割符，对表格无效最佳实践：RecursiveCharacterSplitter，chunk_size=512,overlap=50~100,按实验调整但是真实的三种分块策略不是互斥的，反而是灵活组合使用的。比如先固定大小分较大的块，再在块内按照递
