【手搓 Agent 第2.1关】搭建 Agent 进阶能力：RAG（上）

Stage 1 我们从零手写搭建了具备对话交互、结构化输出、工具调用、循环防护的最小 Agent，完成了智能体的基础运行闭环。但目前的原生 Agent 仍存在三大核心短板：无法调用专业业务工具、没有长效外部知识库、不具备持续记忆能力，完全无法适配企业级落地场景。

因此我们正式进入 Stage 2 进阶能力搭建阶段，本阶段将补齐企业级 Agent 必备的三大核心能力：RAG 检索增强、自定义工具系统、长效记忆模块，彻底摆脱大模型原生缺陷，让基础 Agent 迭代为可落地、可复用、可迭代的专业智能体：

本篇作为 Stage2 开篇，优先攻坚最核心的知识库能力——RAG 检索增强生成。

大模型天生存在知识滞后、幻觉编造、上下文受限、无法溯源等致命缺陷，这也是纯原生 LLM 很难落地生产场景的核心原因。而 RAG 检索增强生成，是低成本、高效率解决模型幻觉、更新实时知识、赋能私有知识库问答的最优方案，也是所有企业智能体、知识库问答系统的底层核心架构。

本篇专注夯实 RAG 全套底层理论。我们从 LLM 固有缺陷出发，拆解 RAG 的核心原理、三代技术范式，横向对比 Prompt 工程、RAG、微调三大优化方案的适用场景，同时梳理全套专业核心名词，为后续手写实操、工业级落地筑牢理论基础。

一、检索增强生成（RAG）前言

1. LLM 的缺陷分析

试想这样一个例子，有人问了你这样一个问题：木星有多少颗卫星？可能你之前曾经看到过有人说，木星有 92 颗卫星，于是你就自信地回答说 92 颗。但实际上，当你上网一搜，被网上众多消息迷住眼睛，看得头晕眼花，最后勉强确定最新消息说木星有 95 颗卫星，你知道的 92 颗卫星已经是过时的消息了。这种情况也出现在大模型身上。

大语言模型（LLM, Large Language Model） 在近几年展现了惊人的语言理解与生成能力，但它们并非完美无缺。它们也会和人类犯一样的错误。

  • 比如说，它们的知识库里的信息是过时的，但它们并不知道，就会自信地告诉你一个错误的、过时的答案。
  • 再比如说，它们可能干脆就不知道答案，但是以为自己知道，于是自信地编出一个驴唇不对马嘴的答案。
  • 继续比如说，这些答案它们说不出一个具体的来源，甚至当你给它一大段信息让它阅读并回答时，它也很难给出一个确定的答案，就像你也不知道你知道的“木星有92颗卫星”是从哪里看到的、搜索起来也很费劲一样。

总的来说，大语言模型有以下局限性：

局限 解释
知识时效性不足 LLM 的知识来自训练语料，通常存在时间“冻结点”，无法自动更新
幻觉问题（Hallucination） 模型可能生成看似合理但事实错误的内容
缺乏可控性 模型回答往往是“黑箱式”的，难以保证引用来源或解释推理过程
上下文窗口限制 输入长度有限，难以直接处理大规模文档或数据库

因此，单纯依赖大语言模型并不足以满足高可靠性场景的需求。我们需要一种方法，既能发挥 LLM 的语言生成能力，又能引入外部的、可更新的知识库来弥补它的不足——这就是 检索增强生成（RAG） 出现的背景。

2. RAG 的定义

检索增强生成（Retrieval-Augmented Generation, RAG） 是一种结合信息检索与文本生成的混合范式。其核心思想是：

  • 检索：从外部知识库（文档、数据库、向量库等）中找到与用户问题相关的内容。
  • 增强：将检索到的内容作为额外上下文，拼接到提示词中。
  • 生成：LLM 在增强后的上下文基础上生成答案。

这样，RAG 既能利用 LLM 的语言生成能力，又能借助外部知识库保证答案的准确性、时效性和可解释性。

3. RAG 的三大范式

RAG 的发展大致可以分为三个层次（或范式）：

范式 核心特征 优点 局限
Naive RAG 简单检索 + 拼接上下文 实现容易，适合做原型（初步模型） 检索粗糙，易受噪声干扰
Advanced RAG 引入重排序、过滤、动态上下文选择 提高相关性与答案质量 架构更复杂，需额外计算
Agentic RAG 多智能体协作，带推理链与任务分解 可处理复杂问题，具备自适应能力 设计难度高，计算开销大

我们可以将 Naive RAG 的核心流程拆解为四个步骤：

  1. 准备目标文档（Load）：收集你希望大模型“参考”的资料，比如产品手册、论文、FAQ 等，并导入大模型。
  2. 文档切片（Split）：将长文档切成小块（chunk），便于后续处理。
  3. 向量化（Embed & Store）：将每个文本块转化为向量（embedding），存入向量数据库。
  4. 问答检索（Query）：用户提问时，从向量库中找出最相关的文本块，拼接到 Prompt 中交给大模型生成答案。

4. Prompt 工程 vs RAG vs Fine-tuning

除了 RAG 之外，提升大语言模型能力的常见手段还包括 Prompt 工程 和 Fine-tuning。三者在原理、成本和适用场景上各有不同。

先前的文章里介绍过Prompt工程，此处不再赘述，只简单介绍Fine-tuning。Fine-tuning是在预训练模型基础上，用特定领域数据继续训练，让模型更适应某个任务或领域。可以理解为让一个刚毕业的高中生选择某个专业（如医学），然后进行学习训练，最终成为专业的医生。接下来，我们将比较这三者的差别。

方法 是否改动模型 成本 知识更新 优势 局限 典型场景
Prompt 工程 ❌ 不改动 低 无法更新知识 简单灵活，快速试验 效果不稳定，难以解决知识缺失 原型验证、轻量级应用
RAG ❌ 不改动 中 更新知识库即可 时效性强，可解释性好 依赖检索质量，架构更复杂 企业知识库问答、科研助手
Fine-tuning ✅ 改动 高 需重新训练 针对性强，性能提升大 成本高，更新慢 专业化任务（法律、医疗、金融）

选择 Prompt 工程、RAG 还是 Fine-tuning，取决于你的任务复杂度、数据可控性和资源预算。一般建议：轻量任务优先 Prompt 工程，知识密集型任务用 RAG，高精度定制任务考虑 Fine-tuning。

5. RAG 相关关键名词解释速览

专有名词 名词释义
Chunking（分块） 将长文档切割为多个短文本单元的处理流程，解决大模型上下文长度限制问题，分为手工切分、固定长度滑窗切分、语义切分三类。
Chunk 文档分块后得到的独立短文本单元，是知识库存储、检索、向量化的基础最小单元。
Embedding（向量化） 通过预训练模型将自然语言文本转换为多维数字向量的过程，语义相近的文本向量空间距离更近，用于实现语义检索。
Retrieval（检索） 用户提问后，从知识库 / 向量库中匹配、筛选相关性最高 Chunk 的流程，分为基础关键词暴力检索、向量语义检索两种形式。
Grounded Answer（带引用的回答） 强制大模型仅依据给定参考资料生成答案，同时约束模型标注信息来源，杜绝凭空编造内容的输出范式。

二、本篇总结 & 下期预告

本篇我们完整吃透了 RAG 的底层逻辑、技术演进与场景选型，厘清了检索增强生成的核心价值与边界。但理论认知无法替代实操落地，我们尚未真正搭建可运行的 RAG 流程。

下一篇 Stage 2 - RAG 中篇，我们将脱离所有框架依赖，手写极简原生 RAG 沙盒案例，从零实现文本切片、关键词检索、增强提示词组装、溯源问答的完整流程，用最轻量化的代码帮你明白 RAG 真实数据流转逻辑。

posted @ 2026-08-11 20:18  Alkaid2077  阅读(0)  评论(0)    收藏  举报