RAG 基础入门：从知识获取管道到最小实现

这一篇终于写到 RAG 了。做 AI Agent 开发绕不开一个问题模型怎么拿到它没学过、没见过的那部分知识。模型参数固化之后知识就停在训练那一刻企业内部最新的规章制度、产品手册、业务数据它一概不知道。RAGRetrieval-Augmented Generation就是当前最主流的知识获取管道——先检索外部资料再把资料拼进 Prompt让模型基于事实回答。这其实就是给 Agent 加了一套“查资料再发言”的机制。如果你正准备从 0 到 1 搭一个 Agent或者想让模型能回答私有知识库里的问题这篇就是基础中的基础。我会从 RAG 的定位、链路拆解一直讲到最小可运行的代码和实战排坑尽量让每个环节都能直接落地。1. 知识获取管道为什么是 Agent 的刚需RAG 的定位先说一个我常用来类比的事。不要把大模型当成全知全能的数据库它更像一个“读过很多书但没上过班”的新人。你问它常识它能头头是道你问它上个月你们公司的考勤制度改成什么样了它大概率只能编。这个“编”不是模型故意骗你是因为它的知识全部来自训练语料训练截止之后的、非公开的、仅存于企业内部的资料对它来说就是盲区。RAG 解决的就是这个盲区问题。它的思路很朴素回答之前先去一个外部资料库里把最相关的内容检索出来然后把检索结果和问题一起丢给模型。模型不需要“记住”企业的私有资料只需要做一个阅读理解。你给它什么材料它就基于什么材料答题。这个“先检索再生成”的过程就是我们说的知识获取管道。1.1 模型“记忆”的边界在哪里要理解 RAG得先接受一个反共识的事实模型没有靠谱的长期记忆能力。这里说的记忆不是聊天里那种上下文记忆而是知识层面的记忆。模型对世界的理解被压缩在参数里参数无法低成本地更新。你想让它知道一个最新规定不可能像改配置一样改参数只能通过 Prompt 喂给它或者提前在资料库里准备好。所以实践中Agent 的信息来源通常被拆成三层。第一层是模型自身参数里的通用知识第二层是会话里暂时保存的上下文和记忆第三层是外部检索管道——RAG、API 调用、数据库查询、甚至搜索工具。RAG 是第三层里最常见的一种实现它专门负责把“非结构化文本资料”变成可被模型引用的知识。我在实际项目里有个很深的感受如果 Agent 要处理的业务问题高度依赖“最新、私域、细节”的知识不带 RAG 的方案基本没法用。比如员工问“今年的报销标准是什么”模型没训过今年的制度你再怎么调 Prompt 也调不出来。这时正确的做法不是重新训练模型而是让 Agent 先去资料库捞到今年的制度文件再把它塞进上下文里。1.2 RAG 在 Agent 里的分工Agent 和 RAG 的关系可以理解成“大脑”和“资料助手”。Agent 负责拆解任务、决定下一步动作RAG 则是一个随时可调用的资料查询子系统。用工具调用的视角看RAG 就是一个“检索工具”Agent 发现任务需要知识支撑时就触发这个工具去查资料。这个分工决定了设计思路。RAG 管的是“哪段资料最相关”Agent 管的是“什么时候查、怎么用查到的资料”。很多初学者会把 RAG 当成整个 Agent 的全部恨不得所有问题都先去向量库里检索一遍这是不对的。通用常识类问题模型自己就能答只有涉及私有知识、实时知识、长尾知识时才值得走检索管道。过度检索反而会把无关片段混进上下文干扰模型判断。还有一点RAG 不是微调的平替它们的职责不一样。微调是让模型改变“说话方式”或适应特定输出格式RAG 是给模型“临时递资料”。知识更新频繁、希望答案可溯源的场景RAG 有压倒性优势如果模型始终要输出某种固定的、私有化的风格微调才更合适。对大多数 Agent 场景来说先做 RAG不够再用微调补是成本最低的路径。2. RAG 基础链路拆解离线索引、在线检索、生成RAG 看起来只有“检索生成”两步实际落地要拆成三段离线索引Indexing、在线检索Retrieval、生成Generation。离线索引是把原始文档切成小块、转成向量、存进向量库在线检索是拿到 Query 后从向量库召回最相关的块生成是把召回结果和问题一起交给模型产出答案。贯穿这三段的是“嵌入向量Embedding”这个概念。你可以把 Embedding 理解成“语义坐标”。每个文本片段都会被映射成一个高维向量语义相近的内容在向量空间里距离也近。“苹果”和“水果”在距离上会比“苹果”和“挖掘机”更近。机器不识字它只能通过这些向量之间的距离来判断两段话是否相关。这就是为什么 RAG 能做语义检索它不再依赖关键词是否一个字不差地出现。2.1 离线索引阶段加载、切分、向量化离线索引的第一件事是把文档加载进来。PDF、Word、Markdown、HTML、数据库字段格式五花八门不同加载器解析出来的文本质量差别很大。PDF 尤其容易踩坑扫描件不经过 OCR 根本拿不到文字排版复杂的表格转出来经常是一团乱码。我的建议是基础阶段先把资料整理成干净文本或 Markdown格式越统一后续检索效果越稳。加载完成之后是切分Chunking。这一步非常重要却最容易被轻视。模型上下文窗口有限你不能把整本手册直接扔进去所以要把文档切成几百字的小块检索时只取最相关的几块。切分有两个关键参数chunk_size 是每块大概多长chunk_overlap 是相邻块之间的重叠长度。为什么要重叠因为一个知识点可能恰好被切块边界从中间劈开前面那块缺了后半句后面那块没有前半句重叠能让上下文尽量保持完整。切分策略没有绝对标准。固定按字符切是最省事的但语义上很粗糙按 Markdown 标题、段落、代码块结构切通常效果更好。我在多数项目里会先用 RecursiveCharacterTextSplitter把“空行”作为第一优先级不行再按句子边界切保证文本结构基本不被破坏。块大小建议在 300 到 800 字之间具体要看你的业务资料类型这一点在后面参数部分会细说。切分完的每一块文本要交给 Embedding 模型转成向量。Embedding 模型决定了检索质量的上限选型时要关注语义能力、向量维度、对中文的支持程度。市面上常见的有 OpenAI 的 text-embedding-3-small、国产的 bge 系列、通义千问的文本向量模型等。向量化完成后连同原始文本和元数据一起存入向量库比如 FAISS、Chroma、Milvus 等。FAISS 适合本地轻量起步Milvus 适合数据量大、需要分布式部署的业务场景。2.2 在线检索阶段语义召回和相似度计算到了在线检索环节用户问题会先被转成同样的向量然后在向量库里做近邻查找。最常用的距离指标是余弦相似度简单说就是比较两个向量的方向是否一致。取值范围通常在 -1 到 1 之间越接近 1 表示越相关。实际项目中相关片段的相似度经常会落在 0.6 到 0.8 区间低于 0.5 的片段基本可以视为不相关但具体阈值要拿自己的数据实测才知道。在线检索还要决定召回多少块这个数量通常叫 Top-K。K 太小资料可能漏掉关键信息K 太大无关内容混进来反而稀释上下文。基础配置一般取 3 到 5 个再配合一个重排Rerank步骤做二次筛选。Rerank 的原理是先用向量检索粗召回一批候选再用一个专门的排序模型对这些候选逐一打分挑出真正最匹配的内容。基础阶段的 RAG 可以不做 Rerank但如果你发现命中率上不去这往往是一个有效的升级点。向量库内部也不是傻傻地全库比对。为了在百万级向量里快速查找主流向量库会构建索引结构常见的有 HNSW、IVF 等。HNSW 的原理像给向量建了一张多层的“跳表”查找很快但建索引时内存占用高一些IVF 把向量聚类分桶先定位到桶里再搜索。初学者不需要过度纠结内部算法但要知道索引类型会影响召回速度和召回率后续数据量上来了这是必须关注的性能因素。2.3 生成阶段把资料变成答案检索完成后系统会把召回片段、用户问题、以及一段系统指令组装成一个 Prompt交给 LLM 生成答案。这里最简单的原则是把我给你的资料里有的内容写清楚资料里没提到就老老实实说不知道。我在项目里用的 Prompt 核心逻辑通常就三句话少了哪句都可能多一层幻觉风险。第一个要点是明确“上下文来源”。在 Prompt 里标清楚哪些文本是检索出来的参考资料哪些是用户问题模型才不容易把资料内容和自己参数里的记忆混在一起。第二个要点是拒绝“无中生有”。要求模型在资料覆盖不到时直接说“未找到相关信息”而不是强行凑一个答案。第三个要点是尽量让答案引用来源编号比如“根据资料[1]”这能让后续人工核查方便很多。生成阶段还有一个 token 预算问题。模型一次能处理的长度有限检索进来的每个块都要占用上下文空间所以你不能无限加大。合理的做法是提前算出“检索内容最多占多少字”把它作为硬性上限超出就截断或减少 K。上下文一满模型要么把旧信息忘掉要么输出质量明显下降这在长对话场景里尤其明显。3. 从零搭建一个最小可用的 RAG 管道讲完链路是时候动手了。我会用一个最小示例带你跑通整个 RAG 流程这也是我在多个 Agent 项目里验证过的基础骨架。先说明一下我这里用的是 LangChain 作为编排工具但你完全可以用裸代码手写一个简版管道核心就三步把文档切成块、把块向量化、把检索结果拼进 Prompt。框架只是加速过程不是必需品。3.1 选型原则与运行环境准备技术选型要先看你的约束。如果数据必须留在本地、公司有数据安全要求就用本地向量库加开源 Embedding 模型如果对效果要求高、愿意走云服务可以选商用 API。最怕的是在起步阶段引入大量基础设施数据量只有几万条先搭一套分布式向量集群纯属自找麻烦。我建议第一版追求“能跑通、能改”后面再考虑性能扩展。本地轻量起步的组合是LangChain FAISS HuggingFaceEmbeddings 任意国产或开源 LLM。如果你想先跑通也可以把 LLM 换成 OpenAI 或国内大模型 API原理完全一样。这里有一个发布前必须注意的经验Embedding 模型一经选定正式数据就不要轻易更换。历史入库的向量是旧模型生成的换了模型新旧向量不在同一语义空间检索效果会变得混乱。真要换只能重新全量向量化一次。运行环境最好统一用 Python 3.9 以上先安装必要依赖比如 langchain、langchain-community、faiss-cpu、langchain-openai或者对应的国产模型 SDK。我的习惯是先建一个虚拟环境避免依赖冲突。至于数据准备一个 docs 目录放知识文件起步阶段放两三个 txt 或 md 就够重点是理解流程而不是数据量。3.2 最小实现代码骨架下面这段代码演示的是最核心的四步加载、切分、向量化入库、检索问答。我用了 FAISS 做本地向量库Embedding 模型先用 OpenAI 接口示例你如果本地部署把 embeddings 那两行换成开源模型即可。from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.vectorstores import FAISS from langchain_openai import OpenAIEmbeddings, ChatOpenAI from langchain.chains import RetrievalQA from langchain.prompts import PromptTemplate # 1. 加载文档 loader TextLoader(docs/knowledge.txt, encodingutf-8) docs loader.load() # 2. 切分每块 500 字块间重叠 50 字 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , , , ] ) chunks splitter.split_documents(docs) print(f切分后共 {len(chunks)} 块) # 3. 向量化并写入向量库 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore FAISS.from_documents(chunks, embeddings) retriever vectorstore.as_retriever(search_kwargs{k: 4}) # 4. 定制一个“只依据资料回答”的 Prompt prompt_template 请仅根据以下资料回答问题。 如果资料中没有相关信息请直接回答“资料中没有找到相关内容”不要编造。 资料 {context} 问题{question} prompt PromptTemplate.from_template(prompt_template) qa_chain RetrievalQA.from_llm( llmChatOpenAI(modelgpt-4o-mini, temperature0), retrieverretriever, promptprompt, return_source_documentsTrue ) result qa_chain.invoke(今年报考条件有什么变化) print(result[result])跑完这段你会看到两个结果一个是模型生成的答案一个是它命中的原始资料块。我强烈建议你在项目里保留“查看命中资料块”的能力排查答错问题时第一件事就是看召回对不对——如果召回的资料本身就是错的模型答什么都白搭。需要特别说明的是LangChain 的版本迭代很快方法名和 import 路径在未来很可能变化。如果你跑这段代码报错找不到类或函数不要慌基本都是包版本导致的去对应版本文档里查一下最新路径就行。代码骨架里的核心思想——切分、向量化、检索、拼 Prompt——在任何框架里都通用。3.3 关键参数怎么定搭建完骨架最常被追问的是参数怎么调。这里我把几个关键参数整理成一张速查表标注了典型取值和经验方向。注意没有绝对正确的一组参数必须基于你的数据实测。参数常见取值调大/调小的影响我的经验方向chunk_size300-800字调大召回更完整但容易引入噪声调小语义碎片化先按 500 起步按业务资料调chunk_overlap50-150字调大能缓解切块割裂但增加重复通常是 chunk_size 的 10%-20%Top-K3-5 个调大覆盖更多候选但上下文膨胀调小更精准但可能漏基础用 4配 rerank 再加到 8-10Embedding 维度如 1024/1536维度影响存储和检索速度按模型选不要自己硬调检索阈值0.5-0.7用于过滤低相关结果先记录相似度分布再定阈值我在第一次搭 RAG 时最容易犯的错误是“万物皆调大”。K 调大、切片调大结果上下文满得快模型答得又慢又乱。后来我给自己定了个节奏先用一套保守参数跑通再拿一批真实问题做评测看回答质量、检索命中率、token 消耗一次只改一个参数。这样改出的参数你才知道是哪一步带来的收益。另外embedding 计算成本也不可忽视。文本向量化是相对耗时的操作如果每次问答都对同样的文档重新向量化会很浪费。项目里应该把向量库持久化到磁盘下次直接加载只有新文档进来时才增量更新。FAISS 的 save_local 和 load_local 方法就是干这个的别在线上每次现算。4. 实操中的常见问题与排查技巧RAG 项目真正难的不是把代码跑通而是把效果调到可用。下面这几个问题几乎每个 RAG 项目都会遇到我把排查思路和解决办法整理出来希望能帮你少走弯路。4.1 检索命中率低答案牛头不对马嘴最典型的症状是模型答得很流畅但内容明显不对或者引用的资料根本不是用户问的。问题通常不在模型而在检索。第一步先看召回的资料块——如果 K 个块里没有一个和问题真正相关那就说明前面的索引阶段出了问题。常见的元凶有三个。一是切块太碎或太整语义被拆散或混杂二是 Query 和文档的用词差异大纯向量检索管不住三是 Embedding 模型本身对中文、专业术语理解不够强。针对这三个原因我会依次做几件事调整 chunk_size 和 overlap开启混合检索把关键词匹配和向量召回的结果做融合升级更强的 Embedding 模型或加 rerank。一个非常实用的做法是给检索质量建个“体检指标”。提前准备几十个业务问题人工标注每个问题对应的正确文档块然后跑一遍检索统计“正确答案出现在前 K 个召回结果里”的比例也就是常说的 hit rate。这个数字不达标就不要急着调生成 Prompt先把检索修好。我在项目里测下来基础 RAG 的 hit rate 普遍在 60% 到 80% 之间加上 rerank 或混合检索后能上一个台阶。4.2 上下文窗口被撑爆速度慢另一个高频问题是上下文长度爆了或者响应慢到让人崩溃。根源大部分是“塞了太多内容进来”。有些同学觉得知识越多越好K 设成 10chunk_size 设成 1200一次检索带回上万字模型窗口再怎么大也扛不住。而且向量检索本身也会因为候选过多而变慢。对策分三层。第一层是压缩输入减少 K、减小块大小、过滤低相似度片段。第二层是引入 rerank粗召回多取一点精排序只留 3 到 5 个既保证覆盖率又控制上下文。第三层是缓存和增量Embedding 结果缓存起来向量库只对新增文档更新避免每次查询都做全量计算。如果这些都不够才考虑垂直切分资料库或升级向量库配置。这里想强调一个容易被忽视的问题Agent 的多轮对话里历史消息也在占上下文。RAG 检索回来的资料只是上下文的一部分如果对话历史已经很长就要先做历史摘要或截断否则系统会先被历史撑爆而不是被检索内容撑爆。4.3 知识更新滞后与多种召回手段知识更新是个绕不开的运营问题。企业文档每天都在变向量库里却还存着旧版本模型引用的可能是已经失效的制度。解决思路是给每个文档块带上版本号或更新时间每次更新资料时先按文档标识把旧向量删掉再写入新向量。这个“删旧增新”的动作必须做成标准化流程否则时间一长库里全是废旧数据。还要纠正一个思维误区RAG 不等于向量检索。向量检索擅长处理非结构化语义检索但结构化的最新数据比如数据库里的价格、库存、订单状态更适合让 Agent 直接调用 SQL 查询或者 API 工具。知识获取管道本身应该是多路的向量库负责语义资料数据库负责结构化事实搜索工具负责实时信息。基础篇里先聚焦向量检索到了 Agent 进阶你会更明白“工具调用”和“RAG”如何配合。进阶方向上你可以了解两个概念Agentic RAG 是让 Agent 自主决定是否检索、检索几次、要不要换关键词重试把检索从“单次工具调用”升级成“带反馈的循环”GraphRAG 则是先对文档做实体和关系抽取再以图结构辅助检索适合需要回答跨文档、关系型问题的场景。这些都是 RAG 基础之上的扩展但前提是你先把基础链路掌握扎实。4.4 实操问题排查速查表最后把前面遇到的高频问题汇总成一张表方便你对照排查。症状可能原因排查步骤解法答案与资料不符检索召回错误块打印 source_documents 看召回内容调 chunk / 换 embedding / 加 rerank模型总是编造Prompt 缺少“不知道就直说”约束检查 prompt 是否限定资料范围在 Prompt 中显式要求不编造上下文频繁超限K 太大或 chunk 太长统计单次检索的 token 数减小 K、分块压缩历史新知识查不到向量库未更新或 Query 太偏检查数据更新时间、检索分数删旧增新或做 query 改写中文检索效果差Embedding 不支持中文语义用几个典型问题做 hit rate 测试换成 bge-m3 等中文能力强的模型响应慢全库扫描或重复向量化检查向量库规模和缓存换索引类型、加缓存、增量更新我在实际项目中养成的一个习惯是所有向量块都带上来源文档 ID、原始页码或章节名这些元数据。一旦答案有争议我能直接回溯到原始文档而不是漫无目的地重新跑一遍。另一个习惯是给检索效果做小规模回归测试每次改参数后在固定问题集上重新测一遍防止“修好一个问题、带崩一类问题”。最后分享一个小技巧搭建 RAG 时先别急着追求花哨功能老老实实做一次“人工小样本评测”。挑 20 个真实业务问题把答案和命中的资料都记下来人工看一遍。这一遍会比你调一整天的参数都有收获。你在看那 20 条样本时会看到很多数字之外的细节比如某个问题总是被同一段噪声干扰某类专业术语完全没被检索出来。只有看到这些你才知道下一步该优化哪里。把这条知识管道打扎实Agent 后续的表现会给你省下大量返工时间。