传统 RAG 项目技术解析：从架构到落地实践

1. 什么是传统 RAG

检索增强生成（Retrieval-Augmented Generation，简称 RAG）是一种将信息检索与大语言模型生成相结合的技术范式。它的核心思想是：在模型回答用户问题之前，先从外部知识库中检索出与问题最相关的文档片段，再将这些片段作为上下文注入提示词（Prompt），引导大语言模型基于“查到的资料”生成答案。

传统的 RAG，通常指的是Naive RAG（朴素 RAG）这一经典实现路线。它的整体流程相对直接：索引构建、向量检索、上下文拼接、答案生成。虽然近年来出现了 GraphRAG、Agentic RAG、Self-RAG 等更复杂的演进形态，但传统 RAG 依然是理解这一领域的最佳起点，也是很多中小规模知识问答系统落地时的首选方案。

传统 RAG 缓解了大语言模型的三个核心痛点：

• 知识时效性问题：模型训练数据存在截止时间，RAG 通过检索最新文档补足外部知识。
• 幻觉问题：让模型基于检索到的真实资料作答，而非仅凭参数记忆“编造”答案。
• 私有知识利用问题：企业内部的制度、手册、专有文档无法直接参与模型训练，RAG 提供了一种低成本接入方式。

2. 传统 RAG 的整体架构

传统 RAG 项目通常由离线与在线两条链路组成，整体架构可以抽象为“准备知识”和“回答提问”两个阶段。

上图可以分为两个部分：

1. 离线索引阶段（上半部分）：对文档进行预处理、切分、向量化，并写入向量数据库。
2. 在线检索阶段（下半部分）：将用户问题向量化，从向量库中召回相关片段，再交给 LLM 生成答案。

这种“检索 + 生成”的解耦设计，使得知识库可以随时更新，而无需重新训练模型，这也是 RAG 相比微调（Fine-tuning）的最大优势之一。

3. 核心工作流程

3.1 文档加载与解析

传统 RAG 项目通常从多种来源采集文档，常见的类型包括：

• 纯文本文件（TXT、Markdown）
• PDF 文档
• 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等

向量化的对象包括两个方面：

1. 索引阶段：对每个文档 Chunk 生成向量，存入向量数据库。
2. 查询阶段：对用户问题生成向量，用于后续相似度检索。

3.4 向量检索

向量检索是 RAG 引擎的核心能力之一。系统将问题向量与向量库中的文档向量进行相似度计算，返回最相近的 Top-K 个片段。

常用的相似度度量方式包括：

• 余弦相似度（Cosine Similarity）
• 欧氏距离（Euclidean Distance）
• 内积（Inner Product）

在工程实现中，向量检索通常由专门的向量数据库承担，例如：

3.5 Prompt 拼接与答案生成

检索完成后，系统将 Top-K 文档片段与用户问题一起组装成最终 Prompt，再调用大语言模型生成答案。一个典型的 Prompt 模板如下：

你是一个知识库问答助手。请严格依据以下参考资料回答用户问题， 如果资料中没有相关信息，请明确回答“暂无相关信息”，不要编造内容。 参考资料： {context} 用户问题：{question} 你的回答：

这种模板设计有两个关键目的：

1. 明确要求模型“依据资料作答”，以降低幻觉概率。
2. 为无法回答的场景预留退出路径，避免模型强行编造。

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 chunks=RecursiveCharacterTextSplitter(chunk_size=500,chunk_overlap=50).split_documents(documents)# 2. 向量化并写入向量库fromlangchain.vectorstoresimportChromafromlangchain.embeddingsimportOpenAIEmbeddings vectorstore=Chroma.from_documents(documents=chunks,embedding=OpenAIEmbeddings())# 3. 检索相关片段retriever=vectorstore.as_retriever(search_kwargs={"k":4})docs=retriever.get_relevant_documents(user_question)# 4. 拼接 Prompt 并生成答案context="\n\n".join([d.page_contentfordindocs])prompt=build_prompt(context,user_question)answer=llm.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 依然是一个务实且高效的选型方向。