1. RAG 到底解决了什么问题Agent 的知识天花板做 AI Agent 的人迟早会撞上一堵墙模型再聪明也没法知道你的私有数据。这个系列前面几篇聊了 Agent 的规划、工具调用但一直有个问题悬着——Agent 依赖的知识到底从哪来这就是这篇要讲的“知识获取管道”也就是 RAG。RAG 全称 Retrieval-Augmented Generation检索增强生成核心就一句话让模型在回答之前先去知识库里查资料再把查到的内容作为依据来作答。在 Agent 架构里RAG 不是可选项而是必需品。没有管道Agent 就只能靠模型肚子里那点训练时的记忆遇到新增知识、私有文档、实时数据立刻打回原形。先说个直观的类比。你让一个刚毕业的实习生直接处理公司几十年的业务档案他肯定懵——因为没学过也不知道去哪查。但如果你给他一个档案室、一套检索目录告诉他“先查再答”他的表现会立刻上一个台阶。RAG 干的就是给模型配档案室这件事。模型的“记忆”是训练时固化下来的截止日期一过就断档而 RAG 让模型每次答题前都可以实时翻阅“参考资料”相当于把一次性考试变成了开卷考试。这个系列能走到第四篇说明你已经认可一个前提Agent 本质上是“模型 规划 工具 记忆”的组合体。工具负责行动规划负责拆解目标而 RAG 负责喂给模型高质量的证据。没有知识获取管道Agent 的规划再漂亮也是空中楼阁因为每一步决策都可能建立在幻觉之上。举个例子你让 Agent 帮你写一份某产品的竞品分析如果它没有接入任何检索管道它只能凭训练数据里的印象编写出来的东西看似流畅实则经不起推敲。接上 RAG 之后它能先检索内部资料库、产品文档、历史报告再基于这些真实材料组织答案可信度完全是两个量级。还要澄清一个常见误区很多人以为 RAG 只是“给 LLM 加个搜索引擎”这是个低估。RAG 是一整套知识获取管道包括文档怎么切、向量怎么算、相似度怎么排序、多路结果怎么融合、答案怎么溯源——任何一个环节掉链子最终回答质量都会大打折扣。这篇我会从架构设计讲到代码实现再把我实际踩过的坑一并交代清楚适合两种人看一是刚入门、想搞清楚 RAG 原理的开发者二是已经跑通 Demo但效果不稳定、想系统调优的从业者。2. 管道四段式设计与技术选型思路2.1 一条管道分四段采集、加工、索引、检索很多教程一上来就讲向量数据库和 Embedding容易让新手误以为 RAG 的重点在“存”和“查”。实际上我建议你把 RAG 理解成一条完整的流水线分四段采集Ingestion把散落在各处的内容收拢进来可能是 PDF、Word、Markdown、HTML、数据库记录甚至是音视频转写文本。加工Processing清理噪声、识别标题结构、去除页眉页脚再把长文档切成模型友好的片段。这段决定了后续检索质量的上限。索引Indexing把加工好的片段向量化存进向量库同时保留原文、元数据和倒排索引。检索Retrieval收到用户问题后把问题也向量化召回相关片段再经过排序、重排、拼接交给 LLM 生成答案。理解整条链路有个好处遇到效果问题时你能按分段定位瓶颈而不是盲目调 Prompt。我见过太多人一问“为什么答不对”就急着换 Embedding 模型结果问题出在文档切分上——原文被拦腰截断关键信息在切缝里丢了召回率自然上不去。2.2 技术选型框架、向量库、Embedding 怎么互相匹配选型这一步最容易犯的错是“看哪个火用哪个”。我给的选型逻辑很简单按团队情况和应用场景分三层层次可选方案我的建议框架LangChain / LlamaIndex / Spring AI / 自研快速验证选 LangChain生产环境重控制力选自研向量库Chroma / FAISS / Milvus / pgvector / Qdrant数据量小选 Chroma 或 pgvector量大、要高并发选 MilvusEmbeddingBGE / M3E / text-embedding / 通义 / 智谱中文场景优先 BGE 系列或国产商用接口兼顾效果与成本先解释框架。LangChain 胜在生态全、文档多、上手快适合一周内出 Demo。但它的抽象层很厚调试时你常常要穿过几层封装才能看到真实数据流。Spring AI 适合 Java 技术栈的团队最近也很活跃。如果团队有精力我推荐在流程稳定后做一层薄封装自己控制切分、检索和 Prompt 拼接长期维护成本反而低。选框架的核心判断标准不是功能多少而是出问题时你能否在一小时内定位到根因。向量库的选择取决于规模和运维能力。个人项目和几十万条以内的知识库Chroma 或 FAISS 完全够用pgvector 适合不想额外引入组件的团队直接复用 PostgreSQL数据一致性处理也省心到了千万级向量、多租户、高并发的场景才需要 Milvus 这种专业服务。Embedding 模型这里多说一句别迷信某个排行榜你要用自己的语料去做评测。通用榜单测的是平均能力你的业务术语、文档风格、语言混杂程度都会影响实际效果。中文场景我实测 BGE 系列效果稳定而纯英文或者代码文档比较多的场景OpenAI 的 embedding 模型和开源模型各有胜负必须拿真实数据跑一轮再定。2.3 一个反直觉的结论复杂方案不等于好效果我见过不少团队一上来就上 GraphRAG、加知识图谱、上 Agentic RAG美其名曰“架构先进”。这里必须泼盆冷水RAG 的效果瓶颈往往在基础环节而不在高级特性。GraphRAG 的确能在处理强关系型知识比如实体网络、多跳推理时表现出色但它的构建成本和更新成本都很高你首先要确认自己的场景是不是真的需要关系推理。如果只是“产品手册问答”、“规章制度查询”老老实实把切分做好、把检索调准效果就能超过绝大多数花架子方案。单项技术的选择要回到业务目标来判断。你做的是客服问答高频问题就那么几十类一个带关键词匹配 向量召回的管道就能解决 80% 的需求你做的事故复盘分析需要跨文档关联和时序推理才需要考虑更高级的图谱方案。存量和增量数据规模、更新频率、回答延迟要求这些指标决定了方案的复杂度上限。记住一个原则先跑通最简单的全链路再根据实际效果误差去叠加复杂度。3. 核心细节解析切分、Embedding、召回与重排的实操要点3.1 文档切分粒度、重叠与结构化解析切分是 RAG 里最不起眼、却最影响效果的一环。切大了片段里塞满无关内容向量表示被稀释召回精度下降切小了语义不完整上下文信息丢失模型拿到片段后拼不出完整逻辑。拿产品文档举例一个段落可能同时包含功能描述、参数表格和使用注意事项如果你按固定长度 500 字硬切极可能把一个完整的表格说明拆到两个片段里每条都不完整检索时自然答不全。我实测下来中文场景比较稳的起点是chunk_size 300 ~ 500 字overlap 50 ~ 100 字。这个组合能覆盖大多数说明文和问答场景。但固定窗口只是兜底方案更好的做法是“语义切分”优先按 Markdown 标题、段落、列表、表格边界来切让每个片段尽量是完整的语义单元。比如用 LangChain 的RecursiveCharacterTextSplitter分隔符优先级设为[\n\n, \n, 。, , , ]它会尽量在句号或段落边界处切断而不是凭空拦腰截断。还需要特别注意表格类内容。文本切分器对表格天然不友好一个 10 行 5 列的参数表被切成几段后就废了。我的做法是文档预处理阶段先识别表格区域把表格转成“字段名值”这样的key-value句式或者结构化的 Markdown 表格行再作为独立片段存入。经验是这类结构化内容单独处理、单独索引检索时按需拼回上下文比混在文本里统一切效果要好得多。3.2 Embedding 模型怎么选、要不要微调、维度对效果的影响Embedding 的作用是把文本变成向量让语义相近的句子在向量空间里离得近。听起来很美妙但有几个容易忽略的工程细节。第一是输入长度上限。多数 Embedding 模型有最大 token 限制比如 512 或 8192。你的 chunk 如果超出上限会被截断等于切分做了无用功。所以切分参数和 Embedding 模型的最大输入长度要匹配。第二是要不要微调。只有在你检索的语料高度专用比如医疗病历、法律文书、军工标准且通用模型明显召不准时才值得考虑微调。微调 Embedding 需要高质量的querypositive passagenegative passage三元组数据准备成本很高。判断是否值得微调有个信号用你的真实问题跑一轮检索看 Top-5 结果里相关文档占比如果低于 50%先别急着微调回去检查切分和召回策略大概率是这两个环节出了问题。第三是向量维度。维度越高理论上表达能力越强但存储开销和检索延迟也会上升。BGE-large 是 1024 维BGE-small 是 512 维实际上升后你会发现对绝大多数知识库问答场景512 维完全够用。我之前维护过一个 200 万条的文档库把 Embedding 模型从 1024 维换成 512 维后召回效果几乎没变检索速度提升了约 40%。3.3 Top-K 怎么设、为什么需要 RerankTop-K 是最容易被拍脑袋设置的参数。设小了正确答案可能被截在门外设大了大段无关内容灌进 Prompt模型注意力被稀释还浪费 token。我的经验值是先按窗口大小倒推 Top-K 和自己场景的答案长度需求。比如你的 chunk 是 400 字想让模型基于 3 个片段作答那 Top-3 就够但如果同一份材料的内容被切碎了、分散在不同片段里Top-3 可能不够需要 Top-5 甚至 Top-8。只靠 Top-K 向量召回是不够的因为向量检索的排序是基于语义距离它有盲区。比如用户问“报销流程是什么”向量召回可能会把“差旅报销注意事项”排在最前面而把真正的“报销流程详解”排在后面。这就是 Rerank重排的用武之地召回阶段用向量模型做粗筛保证候选集够宽精排阶段用交叉编码器或更精确的排序模型对候选片段和问题做逐对打分把最相关的排到最前面。一句话概括向量模型负责“捞”Rerank 模型负责“选”。实现层面LangChain 里的ContextualCompressionRetrieval配合CrossEncoderReranker是常见方案。BGE-reranker 这类开源模型可以本地跑效果远好于直接在向量库里用分数硬截断。需要注意的是 Rerank 是过一遍候选集会引入延迟所以一般只在 Top-20 以内做重排而不是对全量结果。3.4 混合检索关键词和向量的互补逻辑向量检索擅长语义匹配但有个天生弱点对精确词、代码标识符、型号字符串不敏感。你问“GTX-2000 型探测器的量程是多少”如果文档里恰好是“GTX2000”和“量程范围”分散出现向量检索很可能把它们当作不同语义处理。这时候要靠 BM25 这类传统关键词检索来兜底它做词频和倒排匹配对精确词非常可靠。所以行业里的标准姿态是混合检索Hybrid Search向量召回 关键词召回两路结果合并去重再用 Rerank 统一排序。比例上怎么调取决于语料性质——技术文档、代码、产品手册这类强术语内容关键词检索权重可以提到 0.4 ~ 0.5通用知识、口语化问答类场景向量权重占主导。代码实现可以用 LangChain 的EnsembleRetriever给 BM25Retriever 和 VectorStoreRetriever 分别设权重。这个组合在实际项目里比单路召回见效快得多也是我认为 RAG 调优里“性价比最高”的改动。4. 从零搭一套最小 RAG 管道的完整实操4.1 环境和数据准备这一节我们直接落地一套最小可跑的 RAG 管道。我尽量用最简单的代码避免过度封装让你能看清每一步在干什么。环境要求Python 3.10安装langchain、langchain-community、chromadb、bge-reranker对应的依赖库Embedding 用 BGE-small 或任意你手上可用的模型。数据准备这里我用一个虚拟的《设备巡检操作手册》语料包含设备启动步骤、安全注意事项、故障处理流程三个主题大约 100 行 Markdown 文本。真实项目里这一步对应的是把内部文档、数据库导出、爬取的网页内容统一落盘到某个文件夹。pip install langchain langchain-community chromadb sentence-transformers这里提醒一下环境干净与否直接影响排错效率。我建议用虚拟环境不要图省事装到全局 Python 里。另外Chroma 本地模式会在磁盘上建目录存放向量数据注意给它一个独立的存储路径避免和代码目录混在一起。4.2 最小实现代码与逐步说明整个管道分三步切分、入库、检索回答。第一步读取文档并用递归切分器做切分from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter loader TextLoader(manual.md) docs loader.load() splitter RecursiveCharacterTextSplitter( chunk_size400, chunk_overlap80, separators[\n\n, \n, 。, , , ] ) chunks splitter.split_documents(docs) print(f原始文档数: {len(docs)}, 切分片段数: {len(chunks)})切分参数按前文说的原则来调。这段代码输出的片段数量值得看一眼通常你会希望切出来的片段数在合理范围——太多说明 chunk_size 过小太少说明可能切不动长文本。第二步初始化 Embedding 和向量库把片段向量化并写入 Chromafrom langchain_community.embeddings import HuggingFaceBgeEmbeddings from langchain_chroma import Chroma embedding HuggingFaceBgeEmbeddings( model_nameBAAI/bge-small-zh-v1.5, encode_kwargs{normalize_embeddings: True} ) vectorstore Chroma.from_documents( documentschunks, embeddingembedding, persist_directory./chroma_db )注意normalize_embeddingsTrue这个参数。归一化之后计算余弦相似度会更快而且如果后面要做多路召回的分数融合统一量纲也更方便。第三步建立混合检索器并拼接上下文交给模型回答from langchain.retrievers import EnsembleRetriever from langchain_community.retrievers import BM25Retriever from langchain_core.prompts import ChatPromptTemplate from langchain.chains.combine_documents import create_stuff_documents_chain from langchain.chains import create_retrieval_chain bm25_retriever BM25Retriever.from_documents(chunks) bm25_retriever.k 5 vector_retriever vectorstore.as_retriever(search_kwargs{k: 5}) ensemble_retriever EnsembleRetriever( retrievers[bm25_retriever, vector_retriever], weights[0.4, 0.6] ) prompt ChatPromptTemplate.from_template( 你是一名设备运维专家。请根据下面的资料回答用户的问题。 如果资料不足以支撑答案请直接说明“根据现有资料无法完整回答”。 资料 {context} 问题{input} )用 LangChain 的create_retrieval_chain把检索和生成串起来即可。这里 Prompt 里加了“资料不足就直说”的约束这条约束非常关键能明显减少模型“硬编”幻觉答案的倾向。跑一轮测试输入“设备启动前需要检查哪些项目”观察返回结果是否引用了正确的片段内容。4.3 实测记录从“答不对”到“能引用”我把这套最小管道跑了一遍记录了几个典型问题。初始状态是纯向量检索Top-K 设为 3没有 Rerank。第一个问题是“启动设备前要确认接地线是否连接”我检索到的 Top-3 片段里只有一条和接地相关其余两条是故障处理段的无关内容模型回答含糊带过。这个案例暴露的其实是切分问题启动步骤和安全注意事项挨在一起固定 400 字窗口把两条内容混在了同一个片段里。调整方案把 chunk_size 降到 300提高 overlap 到 80同时给安全注意事项段落单独加了 Markdown 标题让递归切分器能顺着标题边界切。第二次测试接地问题召回了两个相关片段回答明显更准确。接着我加了 BM25 关键词检索做混合测试“接地线”这种精确词召回稳定了很多——向量检索对“接地线”这个词的语义邻居可能飘到“线缆接驳”之类的内容而 BM25 能精准命中原文。最后加上 Rerank 模型重排 Top-10回答质量又上了一个台阶。整个调优过程验证了前文的判断基础环节的改进效果远大于换更贵的模型。5. 常见问题与排查技巧实录5.1 命不中先查切分再查 Embedding“检索不到相关内容”是最高频的问题排查顺序很重要。我排错时固定按这个清单走看切分结果把切出来的片段随机抽 10 条人工读一遍。如果片段断句奇怪、信息残破问题一定出在切分策略上而不是检索上。看召回原始分数把向量检索的相似度分数打出来。如果 Top-1 的分数都不高比如低于 0.5说明 Embedding 模型对这批语料的区分度不够考虑换模型或做微调。试关键词检索用 BM25 单独跑同一问题。如果关键词能命中、向量命不中说明语义匹配逻辑有问题可能是语料措辞和问题差异太大也可能是 Embedding 模型语料领域不符。检查数据入库确认你查的内容真的进了库。听起来像废话但我踩过不止一次坑——数据库连错环境、文档路径写错、增量任务没跑成功白折腾一晚上。这套流程能覆盖 90% 的“命不中”问题。关键心态是不要一上来就推给模型能力先证明数据确实存在且可召回再讨论模型怎么用。5.2 答非所问上下文与 Prompt 的配合有时候碎片确实召回了但模型给的答案还是不对这时候问题往往出在“上下文组织”和 Prompt 上。常见情况是Top-K 设得太大5 个片段里有 2 个相关、3 个陪跑模型分不清主次。我建议按 Top-K 召回后先看前三名片段的相关性如果前三名都不靠谱优先调切分和重排而不是继续加大 Top-K。上下文堆得越多模型越容易迷失。另一个坑是 Prompt 没有交代“资料不足就承认”。不给约束时模型会被训练习惯驱动强行用训练知识脑补结果就是答非所问。我在这套管道里加的约束语“如果资料不足以支撑答案请直接说明”看似简单实测能把幻觉率降一半还多。还可以进一步让 Prompt 要求模型在回答中标注引用的片段来源比如“依据设备巡检手册-第3章安全注意事项”这样既方便人工校验也为后续做答案溯源留了口子。5.3 知识更新索引同步与缓存策略RAG 管道上线后绕不开一个问题文档改了索引怎么办最粗暴的做法是全量重建数据量小没问题但百万级文档全量重算 Embedding 的成本很高。我的做法是分层处理结构化数据数据库、工单走增量任务按更新时间戳只处理变更行非结构化文件走文件指纹Hash检测文件没变就跳过变了才重新切分入库。同时在向量库里记录每批数据的 source 元数据万一要清理某批历史数据按元数据删除即可。还有缓存层的问题。高频问题比如“报销标准”、“请假流程”每次重新走检索和生成纯粹浪费资源。我常用的策略是对问题和答案做语义缓存——把用户问题向量化后先查缓存库命中就直接返回历史答案未命中才走完整 RAG 流程。缓存命中率通常在重复咨询多的企业场景能到 30% 以上对成本和响应速度都是实打实的改善。注意缓存要有单独的过期策略别让新知识进来后用户还查到一个月前的旧答案。5.4 性能问题召回慢、并发撑不住最后聊性能。单用户 Demo 没人关心毫秒级延迟但一上线就有多个人同时用问题会集中爆发。第一个常见瓶颈是向量检索Chroma 在小数据量时跑得飞快但到百万级向量后暴力检索的延迟会显著上升。换用专业向量库Milvus、Qdrant并做好索引参数HNSW 的 M 和 efSearch是正路。第二个瓶颈是 Embedding 计算如果有新文档持续入库Embedding 推断会成为 CPU/GPU 热点。我的建议是把 Embedding 服务独立出来跟前端检索链路解耦入库流程可以异步排队别让索引任务占用了在线检索的资源。还有一个容易被忽视的坑是Rerank 环节的并发放大。一次查询进入 Rerank 时如果候选集是 20 条就要跑 20 次交叉编码器推理延迟叠加很可观。解决思路是给 Rerank 加独立的推理服务并限制候选集大小或者只在高置信度无法判断时才启用重排。上线前做一轮压测很值得用小流量脚本模拟 10 个并发用户的查询模式把检索时延、Rerank 时延、生成时延分别打出来哪个环节耗时最长一目了然再针对性地优化那一层。最后分享一个我反复用到的检查习惯不管管道搭得多复杂我每次排查 RAG 效果问题都会先问自己三个问题数据真的切对了吗检索真的召到关键片段了吗Prompt 真的告诉模型该做什么、不该做什么了吗按这个顺序查绝大多数问题能定位到根因而不是在高级组件里折腾。还有一个值得养成的操作习惯把每次检索的中间结果可视化。我通常在调试期打印出“原始问题、Top-5 片段、片段来源、相似度分数”这四列信息跑几条真实问题一眼就能看出问题出在切分、召回还是排序。这个习惯救了我很多次也建议你现在就在自己的管道里加上这段调试代码。RAG 没有银弹但把基础环节打磨扎实它给你的回报会远超预期。