前言：
本节讲述了RAG基本的框架，以及基本原理
RAG（检索增强生成）工作原理
那么，RAG 系统是如何实现“参数化知识”与“非参数化知识”的结合呢？如下图所示，其架构主要通过两个阶段来完成这一过程：
（1）检索阶段：寻找“非参数化知识”
- 知识向量化：嵌入模型（Embedding Model） 充当了“连接器”的角色。它将外部知识库编码为向量索引（Index），存入向量数据库。
- 语义召回：当用户发起查询时，检索模块利用同样的嵌入模型将问题向量化，并通过相似度搜索（Similarity Search），从海量数据中精准锁定与问题最相关的文档片段。
（2）生成阶段：融合两种知识
- 上下文整合：生成模块接收检索阶段送来的相关文档片段以及用户的原始问题。
- 指令引导生成：该模块会遵循预设的 Prompt 指令，将上下文与问题有效整合，并引导 LLM（如 DeepSeek）进行可控的、有理有据的文本生成。
为什么要使用 RAG？
在选择具体的技术路径时，一个重要的考量是成本与效益的平衡。通常，我们应优先选择对模型改动最小、成本最低的方案，所以技术选型路径往往遵循的顺序是提示词工程（Prompt Engineering） -> 检索增强生成（RAG） -> 微调（Fine-tuning）。
下面对这三个技术选型做一个通俗解释：
提示词工程
做法：不改变模型本身，只是通过精心设计输入给模型的指令（提示词），比如把问题写更清楚、提供几个例子（Few-shot），引导模型直接输出想要的结果。
优点：零成本、即时生效、无需技术资源。
适用：简单任务、快速验证、模型已具备基础能力的情况。
检索增强生成
做法：在让模型生成答案前，先从外部知识库（比如公司内部文档、数据库）里快速搜索相关信息，把这些信息“塞进”提示词里，让模型基于这些资料来回答。
优点：比微调成本低、知识可更新、能解决“幻觉”（胡编乱造）问题。
适用：问答系统、需要引用最新或私有知识、模型本身不擅长该领域但只需“查资料”就能解决的任务。
微调
做法：用一批针对特定任务的“问题-答案”数据，对模型进行额外的训练，调整模型内部的参数，让它“学会”新的行为模式或风格。
优点：效果最深、模型能真正改变行为逻辑、提升成功率最高。
缺点：成本高（需要GPU算力）、需要准备高质量数据集、时间较长。
适用：任务有特定格式、语调或复杂规则，且前两种方法都达不到效果要求时。
基于此，我们的选择路径就清晰了：
- 先尝试提示工程：通过精心设计提示词来引导模型，适用于任务简单、模型已有相关知识的场景。
- 再选择 RAG：如果模型缺乏特定或实时知识而无法回答，则使用 RAG，通过外挂知识库为其提供上下文信息。
- 最后考虑微调：当目标是改变模型“如何做”（行为/风格/格式）而不是“知道什么”（知识）时，微调是最终且最合适的选择。例如，让模型学会严格遵循某种独特的输出格式、模仿特定人物的对话风格，或者将极其复杂的指令“蒸馏”进模型权重中。
RAG 的出现填补了通用模型与专业领域之间的鸿沟，它在解决如表 1-2 所示 LLM 局限时尤其有效：
| 问题 | RAG的解决方案 |
|---|---|
| 静态知识局限 | 实时检索外部知识库，支持动态更新 |
| 幻觉（Hallucination） | 基于检索内容生成，错误率降低 |
| 领域专业性不足 | 引入领域特定知识库（如医疗/法律） |
| 数据隐私风险 | 本地化部署知识库，避免敏感数据泄露 |
如何上手 RAG？
我这里需求是
部署方便快捷
了解底层原理，后续要进行底层优化，所以需要编写代码
所以我选择的部署方案是：
核心技术栈选型表
为了兼顾“学习底层原理”和“部署极其方便”，本项目的技术栈如下：
| 模块 | 选型决定 | 为什么这么选？（决策逻辑） |
|---|---|---|
| 开发框架 | 原生 Python 控制流 + 辅以基础 LangChain | 不使用 LangChain 的高级封装链（如 RetrievalQA）。我们将自己写 for 循环拼接 Prompt，自己调用 LLM，以此彻底搞懂上下文是如何被喂给大模型的。LangChain 只用来做苦力活（如文档读取和分块）。 |
| 向量数据库 | ChromaDB 或 FAISS (本地化方案) | 极其轻量 它们不需要像 MySQL 或 Redis 那样单独启动一个数据库服务进程。只需 pip install chromadb，向量数据会直接以 SQLite 文件形式保存在你的项目文件夹里。迁移和部署只需打包整个文件夹即可。 |
| 模型接入 | 云端 API (推荐 DeepSeek / 智谱 / 阿里) | 放弃本地部署开源大模型（如 Llama3），因为那需要极其昂贵的 GPU 算力，且部署极不方便。调用国产大模型 API 速度快、成本低（几乎免费），让你的应用可以部署在任何一台便宜的 1 核 2G 轻量云服务器上。 |
| 后端服务 | FastAPI | Python 生态中最快、最现代的 Web 框架，几行代码就能把你的 RAG 核心逻辑包装成流式输出 (SSE) 的 API 提供给前端。 |
| 评估工具 | Ragas (后期引入) | 纯代码框架，方便我们在本地用脚本批量跑测试，量化调整 Chunk Size 和 Top-K 带来的影响。 |
具体环境配置留到下一节再统一讲述
如果只想快速部署项目的可以选择一个开源架构dify等等来快速落地项目
RAG技术前景
虽然随着模型上下文的暴涨，显得rag技术好像不如提示词一样简单快捷，但是 RAG 已死是一个伪命题。
相反，RAG 作为一个概念活得很好，它正在像 Transformer 一样，成为一个不断吸收新技术、不断进化的基础架构范式。它的生命力，正在于它的“面目全非”和“包罗万象”。而本教程的目标，就是绘制出这张描绘 RAG 全貌的清晰地图，当我们可以解构它的每一个模块、理解它的每一种可能性时，RAG 也好，LKE 也罢，这些都无关紧要。我们要做的就是通过 RAG 这道经典例题来学习和拓展（将 LLM 的内在参数化知识与外部非参数化知识相结合）这类题型的解题思路。
下一节我们将讲述具体的环境配置过程，从电脑上配置一个rag基础环境
- 本文链接： http://example.com/2026/04/25/AI/code/RAG/RAG底层原理2_RAG理论基石/
- 版权声明： 本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
欢迎关注我的其它发布渠道