1. 什么是传统 RAG检索增强生成Retrieval-Augmented Generation简称 RAG是一种将信息检索与大语言模型生成相结合的技术范式。它的核心思想是在模型回答用户问题之前先从外部知识库中检索出与问题最相关的文档片段再将这些片段作为上下文注入提示词Prompt引导大语言模型基于“查到的资料”生成答案。传统的 RAG通常指的是Naive RAG朴素 RAG这一经典实现路线。它的整体流程相对直接索引构建、向量检索、上下文拼接、答案生成。虽然近年来出现了 GraphRAG、Agentic RAG、Self-RAG 等更复杂的演进形态但传统 RAG 依然是理解这一领域的最佳起点也是很多中小规模知识问答系统落地时的首选方案。传统 RAG 缓解了大语言模型的三个核心痛点知识时效性问题模型训练数据存在截止时间RAG 通过检索最新文档补足外部知识。幻觉问题让模型基于检索到的真实资料作答而非仅凭参数记忆“编造”答案。私有知识利用问题企业内部的制度、手册、专有文档无法直接参与模型训练RAG 提供了一种低成本接入方式。2. 传统 RAG 的整体架构传统 RAG 项目通常由离线与在线两条链路组成整体架构可以抽象为“准备知识”和“回答提问”两个阶段。文档库文档切分文本向量化向量数据库索引用户提问问题向量化向量相似度检索Top-K 文档片段拼接 Prompt大语言模型生成答案返回用户上图可以分为两个部分离线索引阶段上半部分对文档进行预处理、切分、向量化并写入向量数据库。在线检索阶段下半部分将用户问题向量化从向量库中召回相关片段再交给 LLM 生成答案。这种“检索 生成”的解耦设计使得知识库可以随时更新而无需重新训练模型这也是 RAG 相比微调Fine-tuning的最大优势之一。3. 核心工作流程3.1 文档加载与解析传统 RAG 项目通常从多种来源采集文档常见的类型包括纯文本文件TXT、MarkdownPDF 文档Word 文档HTML 网页结构化数据数据库导出内容在实际项目中文档解析需要处理表格、图片、页眉页脚等噪声信息。对于扫描版 PDF 或图片文档还需预先进行 OCR 识别将图片中的文字提取为可用文本。3.2 文档切分Chunking文档切分是将长文档拆解为适合检索和 LLM 上下文窗口的小片段。切分策略直接影响检索质量常见方案包括固定长度切分按固定字符数或 Token 数切分实现简单但可能切断语义。按段落或标题切分利用文档结构切分保留更完整的语义单元。重叠切分在相邻片段之间保留一定重叠避免关键信息被截断在边界处。一个典型的切分示例为每段 500 字符相邻片段重叠 50 字符。切分后的片段被称为 Chunk是后续向量化和检索的最小单元。3.3 文本向量化Embedding文本向量化的作用是将自然语言文本映射为高维空间中的向量使语义相近的文本在向量空间中距离更近。传统 RAG 项目通常使用预训练的 Embedding 模型完成这一转换主流选择包括OpenAI 的text-embedding-ada-002开源模型 BGE、M3E中文场景常用的bge-large-zh等向量化的对象包括两个方面索引阶段对每个文档 Chunk 生成向量存入向量数据库。查询阶段对用户问题生成向量用于后续相似度检索。3.4 向量检索向量检索是 RAG 引擎的核心能力之一。系统将问题向量与向量库中的文档向量进行相似度计算返回最相近的 Top-K 个片段。常用的相似度度量方式包括余弦相似度Cosine Similarity欧氏距离Euclidean Distance内积Inner Product在工程实现中向量检索通常由专门的向量数据库承担例如方案特点FaissMeta 开源的高性能向量检索库适合本地部署Milvus分布式向量数据库支持大规模数据Chroma轻量级适合原型开发Pinecone云托管向量数据库开箱即用Elasticsearch 向量插件适合已有 ES 体系的企业3.5 Prompt 拼接与答案生成检索完成后系统将 Top-K 文档片段与用户问题一起组装成最终 Prompt再调用大语言模型生成答案。一个典型的 Prompt 模板如下你是一个知识库问答助手。请严格依据以下参考资料回答用户问题 如果资料中没有相关信息请明确回答“暂无相关信息”不要编造内容。 参考资料 {context} 用户问题{question} 你的回答这种模板设计有两个关键目的明确要求模型“依据资料作答”以降低幻觉概率。为无法回答的场景预留退出路径避免模型强行编造。4. 传统 RAG 的技术栈一个完整的传统 RAG 项目通常涉及以下技术组件文档解析PyMuPDF、pdfplumber、python-docx、BeautifulSoup文档切分LangChain 的RecursiveCharacterTextSplitter、LlamaIndex 的SentenceSplitter向量化OpenAI Embedding API、sentence-transformers向量存储Chroma、FAISS、Milvus大模型接口OpenAI API、通义千问、文心一言或本地部署模型编排框架LangChain、LlamaIndex或自行编写的轻量编排逻辑以 Python 为例一个最小化的传统 RAG 项目示例代码结构如下# 1. 文档加载与切分fromlangchain.text_splitterimportRecursiveCharacterTextSplitter chunksRecursiveCharacterTextSplitter(chunk_size500,chunk_overlap50).split_documents(documents)# 2. 向量化并写入向量库fromlangchain.vectorstoresimportChromafromlangchain.embeddingsimportOpenAIEmbeddings vectorstoreChroma.from_documents(documentschunks,embeddingOpenAIEmbeddings())# 3. 检索相关片段retrievervectorstore.as_retriever(search_kwargs{k:4})docsretriever.get_relevant_documents(user_question)# 4. 拼接 Prompt 并生成答案context\n\n.join([d.page_contentfordindocs])promptbuild_prompt(context,user_question)answerllm.generate(prompt)5. 传统 RAG 的适用场景传统 RAG 在以下场景中表现良好适合作为第一版落地实现企业内部知识库问答规章制度、操作手册、FAQ 的智能问答。客服辅助系统从产品文档中检索答案辅助人工客服回复。文档摘要与信息查询从大量报告中快速查找关键信息。学习辅助工具基于教材、讲义进行知识点答疑。对于知识结构相对扁平、答案集中在少量文档片段中的任务传统 RAG 通常能以较低成本获得不错的回答质量。6. 传统 RAG 的局限与不足尽管传统 RAG 实现简单、见效快但它也存在一些公认的短板6.1 检索质量受限传统 RAG 本质上依赖单个问题向量与文档片段向量的相似度检索。当问题表述与文档用词不一致或问题需要跨多个片段进行推理时检索召回率会明显下降。6.2 缺乏多跳推理能力对于“A 公司去年的营收是多少相比 B 公司有何差距”这类需要跨文档比较、聚合的问题传统 RAG 很难通过单轮检索直接获取完整答案。6.3 知识库规模越大检索精度越低当知识库规模增大、文档片段数量增多时如何从海量候选中精准召回 Top-K 片段成为主要瓶颈容易出现“召回不相关片段”或“遗漏关键片段”的情况。6.4 无法利用结构化关系传统 RAG 将所有知识扁平化为文本片段忽略了实体之间的关系、文档的层级结构等结构化信息。这也是后续 GraphRAG 等方案兴起的重要动因。7. 从传统 RAG 到进阶 RAG为了弥补传统 RAG 的不足学术界和工业界发展出了一系列改进方案HyDE假设性文档嵌入先用 LLM 根据问题生成一段假设答案再拿假设答案去检索缓解问题与文档表述不一致的问题。Rerank重排序先粗召回较多候选片段再用交叉编码器进行精排提升 Top-K 片段的相关性。Self-RAG让模型在生成过程中自行判断是否需要检索并对检索结果进行反思与筛选。GraphRAG构建知识图谱利用实体和关系进行结构化检索提升多跳推理能力。8. 总结传统 RAG 是大语言模型应用工程化的重要起点。它以“文档切分 向量检索 Prompt 增强生成”的清晰链路用较低成本缓解了模型的私有知识接入与幻觉抑制问题适合作为知识问答类项目的第一版实现。理解传统 RAG 的工作流程和局限是进一步学习 Rerank、Self-RAG、GraphRAG、Agentic RAG 等进阶技术的基础。对于大多数初期项目而言传统 RAG 依然是一个务实且高效的选型方向。