1. 别把RAG当成“高级搜索”它是给大模型外挂了一个记忆体1.1 我一开始的理解错在哪把RAG和关键词搜索混为一谈RAG这三个字母这两年几乎成了“知识库”的代名词。我看到很多项目立项文档里写着“做个RAG知识库”但聊到具体实现时大部分人的第一反应是RAG是不是就是“先搜到相关文档再扔给模型总结一遍”这个理解不能说错但它漏掉了RAG最关键的部分——它不是一个搜索引擎的升级版而是给大模型装了一个有边界的、可随时替换的记忆体。我最初做RAG的时候也踩过这个认知坑。当时我在做一个内部文档问答系统想当然地把RAG拆成两个独立模块先用Elasticsearch做关键词检索再把命中片段拼到Prompt里请模型作答。结果跑完一轮测试发现效果极差。很多问题明明文档里有答案模型却答得含含糊糊更离谱的是有些问句里根本不含和文档重合的关键词比如用户问“我们公司报销流程卡在哪个环节”文档里写的是“财务审核阶段”关键词完全对不上ES一条都搜不出来。这个经历让我意识到RAG里的“检索”并不是传统意义上的“搜索”。它依赖的是语义检索——把用户问句和候选文档都映射到同一个向量空间里然后用距离来衡量相关性。也就是说RAG好不好用第一道关卡不在模型而在“你用什么办法把文档捞出来”。1.2 RAG的完整链路召回、注入、生成三个词拆开看抛开各种花哨概念RAG的完整链路其实就是三步召回Retrieval、注入Augmentation、生成Generation。召回是指从知识库里找出一批和相关问题最相关的文本片段正常会取top_k个比如5到8个。注入是指把检索到的文本按某种规则拼进Prompt告诉模型“你可以参考以下资料”。生成则是让大模型基于“参考资料用户问题你的指令”产出最终回答。听起来简单但每一步里都藏着决定成败的细节。比如召回阶段“检索回来的片段是否真的和问题对应”这件事依赖的是Embedding模型的质量和文本切分的方式注入阶段检索了10个片段是全塞进去还是只取前3个塞多了模型会分不清主次塞少了信息不够生成阶段如果不告诉模型“资料里没有就直说没有”它照样会一本正经地编答案。我见过很多新手跑通Demo后觉得“RAG不过如此”下结论下得太早了。跑通一个最小闭环只需要一小时但把召回质量从“能用”做到“好用”可能需要占用你80%的精力。下面几个部分我按自己踩坑的优先级来写。1.3 为什么不用微调替代RAG改文档比改模型快得多不少人在规划方案时会问既然想让模型知道我们公司的知识为什么不直接微调一个大模型这确实是个好问题。我的回答是微调适合“学说话的方式”RAG适合“查准某个事实”。拿我自己做过的客服知识库举例如果业务规则变了比如退款时限从7天改成15天用RAG的做法是改知识库文档里的那一段向量库增量更新问题就解决了。如果用微调你得准备一批新的训练样本、重新跑Fine-tune、做评估、再上线一个版本迭代少说一周。而且模型微调之后旧知识还在里面很容易出现“新旧规定混着答”的情况。所以RAG真正解决的是“私有知识时效性和可控性”的痛点。文档即知识改文档就是改模型的行为这个特性在真实业务场景里特别值钱。2. 检索端才是RAG的灵魂工程切分、向量化、存储与召回2.1 文本拆解chunking被严重低估chunk_size和overlap的实测体感整个RAG链路里最不出彩但影响最大的步骤我认为是文本切分。很多教程会把这段一笔带过但实际上切分方式直接决定了后续Embedding和检索的表现。先说为什么必须切。一个Embedding模型能处理的文本长度有限我常用的本地模型输入上限是512到2048个token。如果你拿一份50页的产品手册直接Embedding得到的是一个把全文档信息“揉成一团”的向量检索时问题向量和它做相似度计算结果几乎等于随机。所以必须把长文切成一个个语义相对完整的“块”。切分参数里有两个东西需要调chunk_size块的大小和overlap相邻块之间重叠的长度。我做了多组对比测试拿一份QA格式的运维手册来做实验切分方式单块长度重叠长度命中率体感按固定字符200切无重叠200字符0差答案经常被拦腰切断按固定字符500切重叠50500字符50中等绝大多数答案能完整命中按固定字符1000切重叠1001000字符100较差块内杂质太多检索不聚焦按语义段落递归切分动态50最好但也耗时更多我的经验是默认从chunk_size500、overlap50开始试这个组合适用于绝大多数技术文档。overlap不是可有可无的因为语义可能跨块比如“第一步是打开配置文件”在前一块末尾“接着修改第12行的参数”在下一块开头如果不重叠检索时单独看到任意一块都是不完整的。热词里有人问“有没有本地的RAG文本拆解工具”其实不需要专门工具LlamaIndex里的SentenceSplitter、LangChain里的RecursiveCharacterTextSplitter都是干这个的。我建议优先用“按递归分隔符切分”它会先按段落切再按句子切再按字符切语义完整性比纯固定长度好很多。2.2 Embedding模型选型决定“检索准不准”的隐形天花板Embedding模型负责把文本变成向量向量之间的相似度就是检索的依据。如果这一步不准后面所有的Rerank、Prompt优化都是在打补丁。我自己用过几类模型的感受如下nomic-embed-textOllama本地直接能拉下来跑起来几乎不占资源。英文表现不错中文属于“够用但不够好”。如果只是做技术Demo、验证流程用它起步完全没问题。bge-m3目前中文场景我比较推荐它对中文的支持明显更强而且支持同时输出密集向量和稀疏向量对后面做混合检索很有帮助。模型文件大概2GB左右普通笔记本能跑。text-embedding-3-small/large走OpenAI接口效果没得说中文也比很多开源模型好但私有化部署场景不适合用。bge-large-zh-v1.5专攻中文的老牌选手检索精度在不少公开榜单上依然能打缺点是只适合中文。选Embedding模型最容易犯的错是“只看排行榜分数”。真实业务里你的文档是中文技术文档、口语化客服记录还是英文论文最适合的模型完全不同。我现在的做法是拿自己的真实文档抽20个问题人工标注正确答案所在的段落然后分别用候选模型跑一遍召回看Top 5命中率。实测30分钟就能出结果比看任何榜单都有说服力。2.3 向量数据库怎么选我用FAISS、Chroma、Milvus的真实感受向量数据库负责把Embedding好的向量存起来并在检索时做最近邻搜索。热词里有人问“rag框架”其实向量库的选择本身就能决定这个项目的复杂度上限。我给自己的项目做过一次对比结论是这样的方案部署成本适合场景我实际遇到的情况FAISS极低一个Python库单机学习、原型验证检索很快但要自己管理索引的保存和加载Chroma低pip安装即可中小知识库、本地应用PersistentClient可以直接落盘体验很顺Milvus高需要Docker部署海量数据、高并发生产环境支持metadata过滤但小项目没必要上Qdrant中Docker或云服务需要复杂过滤条件的中大型项目Rust实现性能很稳Payload过滤方便如果你的知识库就几千个文档块我建议直接用Chroma或FAISS。我之前帮朋友做一个本地论文检索工具用的是Chroma索引落盘后启动秒加载完全够用。如果一上来就部署Milvus三件套光是运维组件就能绕晕。另外向量数据库不是越多功能越好。很多RAG项目真正需要的是“按来源过滤只查某一份文档”“按标签过滤”这种基础能力Chroma就已经支持了。别为了用分布式数据库而用分布式数据库。2.4 RAG知识库能存图片吗文本拆解工具与多模态的边界这是一个被问得非常多的问题RAG知识库能存储图片吗直接回答——传统的文本RAG不能但你可以用变通方案实现“图片进库”。图片和文字在嵌入空间里不是天然对齐的你不能把一张图片的原始二进制丢给文本Embedding模型。我试过的可行方案有几种第一种把图片变成“文字描述”再入库。用图像理解模型比如本地跑一个视觉模型对每张图片生成一段描述文字把这些描述文字做Embedding存入向量库检索命中后返回“图片文件路径描述文字”。这是成本最低、落地最快的方案你不需要更换现有RAG架构只是在文档预处理阶段加了一个环节。第二种用多模态Embedding模型比如CLIP类模型它能把图片和文本映射到同一个向量空间。查询时可以用文字搜到图片。这个方案更“正宗”但引入了一套新的嵌入模型体系复杂度高不少我建议先不考虑。第三种图片里嵌文字的情况比如截图、流程图、产品海报靠视觉理解模型把图片里的文字提取出来OCR再走文本RAG效果也很稳。所以如果你的业务知识库里确实有大量图片资料我的建议是先做OCR或图像描述把图片转成文本再进RAG。别一上来就追求“多模态RAG”这个概念工程上得不偿失。3. 检索到了不等于回答好生成端的“上下文使用方式”才是胜负手3.1 为什么召回文档一堆回答还是像没读过我调RAG的时候经常遇到一个奇怪现象日志里显示检索模块明明把5个片段都捞回来了而且肉眼看起来每个片段都沾边结果大模型给出的回答依然像没读过这些资料。排查到最后发现问题出在“内容太多了模型抓不到重点”。我们有个错觉认为给模型的资料越多回答就越可靠。实际上大模型面对一长串可能互相重叠、甚至互相矛盾的上下文时会出现“注意力稀释”。最典型的情况是5个检索片段里只有1个是真正切中问题的但其他4个都在讲相关但不完全对口的背景知识模型生成时被这些“关系不大的内容”带偏了。所以生成端的核心工程不是“有一个Prompt就能跑”而是做好注入内容的筛选和排序。我的做法是先在注入前做一次粗筛只保留和问题相似度最高的3到5块然后把最相关的放最前面。如果做了Rerank重排还要注意把重排后的得分写进Prompt模板让模型知道哪块内容优先级更高。3.2 我的Prompt模板强制引用来源与“宁缺毋滥”生成端的Prompt设计我踩过最大的坑是没有给模型“拒答的勇气”。默认情况下大模型有极强的“讨好型人格”你问它问题它拼了命也想给你一个完整回答哪怕知识库里根本没有相关内容。后来我总结出一套适合RAG场景的Prompt结构核心就三句话明确角色、给出资料、允许拒答。一个我实际在用的模板大概长这样你是企业内部知识库助手。请严格基于下面的资料内容回答问题。 资料 {context} 用户问题 {question} 要求 1. 回答必须来源于资料不要使用资料之外的常识。 2. 如果资料内容不足以回答请直接回复“知识库中没有找到相关信息”。 3. 每个结论后标注来源出处编号如[来源1]。 4. 不要编造数据不要自行推测。别小看这条要求我对比过“带拒答指令”和“不带拒答指令”的版本在测试集上前者把“胡说八道”的比率从30%降到了5%左右。尤其在企业内部知识库这种场景里模型答错比答“不知道”的代价大得多。3.3 Rerank重排召回50条里真正有用的可能只有5条很多RAG项目的检索结果是最原始的“向量相似度排序”。但这里有个很隐蔽的问题向量相似度是“文档块”与“问题”的全局相似度不是“这块内容里包含关键答案”的概率。一个文档块可能整体话题相关但关键答案藏在很角落里它的向量相似度反而不如另一块“看起来相关但没答案”的文本。解决这个问题的常用手段是Rerank重排序用一个专门的排序模型把检索回来的前几十条结果重新打分排序。说白了向量检索负责“快速筛出候选”Rerank负责“精确挑出答案”。这是一个经典的“粗排精排”架构搜索引擎多少年前就在用了。我实测过在纯向量召回Top 5命中率只有50%左右的数据集上加上Rerank之后Top 5命中率能提升到70%上下。而调用成本只是多跑一次小模型。Rerank模型可以选择本地推理的bge-reranker-v2-m3也有商用的接口优先考虑本地化。如果你用LangChain或LlamaIndexRerank通常只需要在检索器和最终合成器之间插入一个组件代码量不大但效果提升却肉眼可见。3.4 多轮对话隐藏在RAG的坑Query改写先于检索用户不会总是把话问完整。比如前面聊的是“报销流程”下一句问“那审批要多久”这里的“那”指代的是“报销审批”如果你直接把“那审批要多久”丢去检索向量匹配大概率会抓到一堆无关内容。这个问题的标准解法是Query改写也叫“对话式检索理解”。也就是说在进入检索模块之前先让大模型根据对话历史把当前问题补全成“完整问句”。比如把“那审批要多久”改写成“报销流程中财务审批环节需要多长时间”。我自己遇到过一个印象很深的案例用户连续问了十几个问题之后问了一句“这个呢”如果没有改写RAG直接懵了加了改写之后模型结合上文知道用户指的是“上一轮说过的某个设备的故障处理”检索准确率一下子从20%提到了80%。成本方面每次多一轮改写调用会多一点延迟但对效果提升来说完全值得。尤其在智能客服场景多轮对话几乎是标配。4. 零基础本地RAG实战Ollama LlamaIndex Chroma 三步跑通4.1 为什么选这套组合而不是大厂API方案热词里有“ollama 简易本地 rag 知识库【零基础可复制教程】”这正是我推荐很多新手起步的路线。选Ollama不是因为它能力最强而是因为它把本地模型部署这件事简化到了一条命令。你不需要手动配CUDA、不需要处理虚拟环境里的各种依赖Ollama会自动拉模型权重并在本地起一个兼容API。和LangChain4j的组合相比LlamaIndex在“文档到索引到问答”这条链路上封装得更薄、也更直观适合零基础用户先看懂RAG到底发生了什么。我写这篇文章时用的版本是LlamaIndex 0.10.x不同小版本API会有差异但核心逻辑不变。整条链路是Ollama负责提供Embedding模型和生成模型LlamaIndex负责做文档切分、向量化和检索问答Chroma负责向量落盘。全部运行在本地不需要联网调第三方接口也不涉及数据外发。4.2 环境准备一条命令拉起本地模型先装Ollama然后拉模型。我建议至少拉两个模型一个用于生成回答的对话模型一个用于文本向量化的Embedding模型。# 拉取生成模型我常用 qwen2.5:7b中文效果比较稳 ollama pull qwen2.5:7b # 拉取Embedding模型本地轻量首选 ollama pull nomic-embed-text然后安装Python依赖pip install llama-index llama-index-llms-ollama llama-index-embeddings-ollama chromadb到这里环境就准备好了。整个过程大概十几分钟主要看网络下载模型的时间。4.3 文档入库切分、向量化、落盘的代码骨架把一份PDF或TXT文档变成可检索的向量索引LlamaIndex的封装很简洁。我以一个data目录为例把文档放进去执行下面这段代码from llama_index.core import SimpleDirectoryReader, VectorStoreIndex, StorageContext from llama_index.core.node_parser import SentenceSplitter from llama_index.embeddings.ollama import OllamaEmbedding from llama_index.vector_stores.chroma import ChromaVectorStore import chromadb # 1. 读取文档 documents SimpleDirectoryReader(data).load_data() print(f加载了 {len(documents)} 份文档) # 2. 设置Embedding模型通过Ollama提供 embed_model OllamaEmbedding(model_namenomic-embed-text) # 3. 设置Chroma持久化存储 chroma_client chromadb.PersistentClient(path./chroma_db) chroma_collection chroma_client.get_or_create_collection(my_kb) vector_store ChromaVectorStore(chroma_collectionchroma_collection) storage_context StorageContext.from_defaults(vector_storevector_store) # 4. 构建索引LlamaIndex会用内置切分器自动分块 splitter SentenceSplitter(chunk_size512, chunk_overlap50) index VectorStoreIndex.from_documents( documents, embed_modelembed_model, storage_contextstorage_context, transformations[splitter], ) print(索引构建完成)这段代码跑完之后会在项目目录下生成一个chroma_db文件夹里面就是你的向量库。以后知识库内容有变化重新跑一次这段代码即可Chroma会按文档ID去重不会重复插入。4.4 问答闭环检索与生成最短可运行代码索引建好之后问答就变得非常简单了。LlamaIndex把“检索注入生成”封装成了as_query_engine你只需要指定生成时用哪个模型from llama_index.core import VectorStoreIndex from llama_index.llms.ollama import Ollama from llama_index.embeddings.ollama import OllamaEmbedding from llama_index.vector_stores.chroma import ChromaVectorStore import chromadb # 重新加载已有的Chroma存储 chroma_client chromadb.PersistentClient(path./chroma_db) chroma_collection chroma_client.get_or_create_collection(my_kb) vector_store ChromaVectorStore(chroma_collectionchroma_collection) # 组装索引 embed_model OllamaEmbedding(model_namenomic-embed-text) index VectorStoreIndex.from_vector_store(vector_store, embed_modelembed_model) # 配置生成模型 llm Ollama(modelqwen2.5:7b, request_timeout120.0) # 构建问答引擎指定检索条数 query_engine index.as_query_engine(llmllm, similarity_top_k5) # 提问 response query_engine.query(报销流程中财务审核需要多久) print(response)就这样一个完整的本地RAG已经可以用了。我做过一次最小测试放入3份常见的公司制度文档问“年假累计规则是什么”回答基本准确而且能定位到具体文档片段。如果你用的是Java技术栈对应方案是LangChain4j的Easy RAG模块它的思路和LlamaIndex一样把文档切分、向量化、检索、问答串成一条流水线感兴趣的同学可以直接按官方文档里的Easy RAG入门示例跑。代码骨架的差别只是语言层面的核心原理没有区别。5. RAG的瓶颈到底在哪来自真实项目中的失败案例与评测经验5.1 检索不到必然答不好但检索到了也一样会答砸我在做第一个RAG项目时最大的教训就是“检索到了照样会答砸”。有一个测试问题检索结果里明明有正确答案对应的文档块模型却给出了相反的回答。后来逐条排查才发现知识库里有新旧两版制度旧版写着“报销需人工审核”新版写着“报销自动通过”两块内容都被检索回来模型没分清新旧关系随机参考了旧的那条。这暴露了一个RAG的关键瓶颈文档块的语义独立性是假设出来的实际上文档之间有版本、有逻辑关联、还有相互矛盾。单纯靠向量相似度召回无法理解文档之间的时序和从属关系。解决思路通常有两个方向。一是增强切分阶段的能力把“版本号”“生效日期”这类元数据随文档块一起存起来在注入到Prompt时进行过滤二是在检索阶段引入业务规则比如按文档更新时间做加权让新版本优先。5.2 知识库的逻辑冲突RAG比模型更容易“左右互搏”很多人在讨论模型幻觉但RAG场景下更常见的问题是“知识库内部逻辑冲突”。知识库里不同作者写的文档用词不一致甚至口径不一致这在实际企业文档里非常普遍。比如A文档写“项目延期的处理流程是先报备再调整排期”B文档写“延期超过一周需要重新立项”。用户问“项目延期怎么办”时两个文档都被召回模型就会在回答里既提“先报备”、又提“重新立项”读者完全搞不清流程到底是什么。这种问题不是靠优化Prompt能解决的根源在知识库本身的治理。我现在做RAG项目都会专门安排一个“知识梳理”阶段把同主题文档合并、统一术语、标记冲突然后再入库。这一步虽然不属于技术编码但对最终效果的贡献可能超过任何模型调优。5.3 混合检索与重排序关键词和语义不是对手而是队友纯向量检索在专业术语、缩写、编号这些场景下经常失手。比如用户搜“CR-101错误码”向量检索可能把“CR”和“101”拆得支离破碎反而漏掉包含“CR-101”的精确匹配文档。这时候传统的BM25关键词检索反而更准。所以我在正式一点的RAG项目里越来越倾向于混合检索同时跑向量相似度检索和BM25关键词检索然后合并结果再做重排序。LlamaIndex里已经内置了QueryFusion之类的检索器封装LangChain也有对应的EnsembleRetriever。代码改动不大但能同时覆盖“语义相近但用词不同”和“精确匹配但向量表达弱”两类问题。5.4 没有评测集优化就是盲人摸象这条是我最想强调的经验。RAG项目的优化环节最怕什么最怕“我感觉效果好了一点”。感觉是不靠谱的因为你换了一个切分参数、换了一个Embedding模型效果可能在某些问题上提升在另一些问题上反而退化。没有统一的评测集你就无法判断到底该往哪个方向调。我现在做RAG第一步会先花时间构建一份评测问题集从真实用户提问中抽50到100条每一条标注“标准答案所在文档”和“正确答案摘要”。然后定义几个核心指标召回命中率检索结果Top 10里是否包含标准答案所在文档块答案准确率人工判断生成回答是否引用了正确内容拒答正确率无法回答时是否会说不知道每次改动之后跑一遍评测集记录指标变化。这个习惯帮我避免了很多“调参玄学”。说句实话RAG项目投入产出比最高的动作不是选更贵的模型而是先建评测集。5.5 RAG的边界什么时候不适合上RAG不是所有场景都适合RAG。如果你的问答高度依赖实时数据比如“当前库存多少”RAG不如直接查数据库如果你的问题是复杂的多步推理比如“对比三份合同里付款条款的差异”RAG单纯做相似度检索很难把需要对比的段落同时捞全如果你的知识库没有一个基础的文本结构全是扫描版且OCR都做不准RAG跑起来也会非常吃力。所以我现在接项目时会先问知识库的状态文档是否至少是数字化文本内容是否有清晰的结构章节、段落、标题更新频率多高如果三个回答都是“否”我会直接告诉对方先把数据治理做好再谈RAG。6. 从普通RAG到“RAG智能体”与Ontology RAG我的进阶路线6.1 RAG智能体和普通RAG不是一回事热词榜上“rag智能体”的热度一直不低。我认为它和普通RAG的本质区别在于普通RAG是“推翻检索结果给你看”智能体RAG是把检索工具交给模型自主调用。模型可以根据用户问题决定要不要检索、检索几次、是先查当前文档还是先查另一个系统。我做过一个对比实验普通RAG面对“综合A文档和B文档的信息回答”这种问题时经常只取到其中一份文档的内容而智能体形态下模型可以拆解成两步“先用A文档检索再用B文档检索然后汇总”回答质量明显更高。但代价是引入了Agent调用带来的不确定性和延迟。我的建议是新手先老老实实把普通RAG调好再考虑智能体形态。很多项目连检索命中率都没做到70%就急着上Agent结果只是把错误答案包装得更花哨。6.2 Ontology RAG和Wiki式知识库解决的是不同问题热词里还有“ontology rag”和“wiki和rag”。我个人的理解是Ontology RAG是在RAG之上增加了一层“概念关系图谱”比如“发票”和“报销”之间存在关联“采购合同”和“供应商”之间存在关联。普通向量检索只会找字面相似Ontology RAG会利用这些关系做多跳检索把隔着两层关系的知识也捞出来。Wiki式知识库则更像一类结构良好的数据源它有清晰的目录、页面分类和互相链接。用这种结构化的知识库做RAG切分和召回都会更顺利。所以“wiki和RAG”实际上是在问“知识源的组织形式如何影响RAG效果”答案很简单结构越清晰RAG越省力。我目前的路线是如果知识库是杂乱的文档集合先把Ontology或者人工标签体系加进去而不是一上来就追求复杂的图谱系统。哪怕只是在每个文档块上打一个“所属主题”的标签检索时按主题过滤效果就会提升不少。6.3 我的脚本式建议先跑通、再评测、后扩展如果让我给一个刚接触RAG的人排优先级我的建议是这样的第一步用Ollama加LlamaIndex跑通最小闭环重点体验“文档切分、向量检索、上下文注入、生成”这四个环节分别是什么感觉。第二步花时间做一份评测集至少50条问题并跑出每个环节的基线数据。这一步能帮你建立“不是凭感觉而是凭数据”的调优习惯。第三步根据评测结果补短板检索不行先看切分和Embedding模型生成不准先看Prompt模板和Rerank多轮对话差先做Query改写。第四步再考虑进阶方向混合检索、Agent调用、Ontology图谱、多模态入库按业务需求逐层加。我在实际项目里发现绝大多数RAG问题不是模型不够强而是检索这一段没做扎实。先把这段地基打好再谈花活比什么都管用。
1. 别把RAG当成“高级搜索”它是给大模型外挂了一个记忆体1.1 我一开始的理解错在哪把RAG和关键词搜索混为一谈RAG这三个字母这两年几乎成了“知识库”的代名词。我看到很多项目立项文档里写着“做个RAG知识库”但聊到具体实现时大部分人的第一反应是RAG是不是就是“先搜到相关文档再扔给模型总结一遍”这个理解不能说错但它漏掉了RAG最关键的部分——它不是一个搜索引擎的升级版而是给大模型装了一个有边界的、可随时替换的记忆体。我最初做RAG的时候也踩过这个认知坑。当时我在做一个内部文档问答系统想当然地把RAG拆成两个独立模块先用Elasticsearch做关键词检索再把命中片段拼到Prompt里请模型作答。结果跑完一轮测试发现效果极差。很多问题明明文档里有答案模型却答得含含糊糊更离谱的是有些问句里根本不含和文档重合的关键词比如用户问“我们公司报销流程卡在哪个环节”文档里写的是“财务审核阶段”关键词完全对不上ES一条都搜不出来。这个经历让我意识到RAG里的“检索”并不是传统意义上的“搜索”。它依赖的是语义检索——把用户问句和候选文档都映射到同一个向量空间里然后用距离来衡量相关性。也就是说RAG好不好用第一道关卡不在模型而在“你用什么办法把文档捞出来”。1.2 RAG的完整链路召回、注入、生成三个词拆开看抛开各种花哨概念RAG的完整链路其实就是三步召回Retrieval、注入Augmentation、生成Generation。召回是指从知识库里找出一批和相关问题最相关的文本片段正常会取top_k个比如5到8个。注入是指把检索到的文本按某种规则拼进Prompt告诉模型“你可以参考以下资料”。生成则是让大模型基于“参考资料用户问题你的指令”产出最终回答。听起来简单但每一步里都藏着决定成败的细节。比如召回阶段“检索回来的片段是否真的和问题对应”这件事依赖的是Embedding模型的质量和文本切分的方式注入阶段检索了10个片段是全塞进去还是只取前3个塞多了模型会分不清主次塞少了信息不够生成阶段如果不告诉模型“资料里没有就直说没有”它照样会一本正经地编答案。我见过很多新手跑通Demo后觉得“RAG不过如此”下结论下得太早了。跑通一个最小闭环只需要一小时但把召回质量从“能用”做到“好用”可能需要占用你80%的精力。下面几个部分我按自己踩坑的优先级来写。1.3 为什么不用微调替代RAG改文档比改模型快得多不少人在规划方案时会问既然想让模型知道我们公司的知识为什么不直接微调一个大模型这确实是个好问题。我的回答是微调适合“学说话的方式”RAG适合“查准某个事实”。拿我自己做过的客服知识库举例如果业务规则变了比如退款时限从7天改成15天用RAG的做法是改知识库文档里的那一段向量库增量更新问题就解决了。如果用微调你得准备一批新的训练样本、重新跑Fine-tune、做评估、再上线一个版本迭代少说一周。而且模型微调之后旧知识还在里面很容易出现“新旧规定混着答”的情况。所以RAG真正解决的是“私有知识时效性和可控性”的痛点。文档即知识改文档就是改模型的行为这个特性在真实业务场景里特别值钱。2. 检索端才是RAG的灵魂工程切分、向量化、存储与召回2.1 文本拆解chunking被严重低估chunk_size和overlap的实测体感整个RAG链路里最不出彩但影响最大的步骤我认为是文本切分。很多教程会把这段一笔带过但实际上切分方式直接决定了后续Embedding和检索的表现。先说为什么必须切。一个Embedding模型能处理的文本长度有限我常用的本地模型输入上限是512到2048个token。如果你拿一份50页的产品手册直接Embedding得到的是一个把全文档信息“揉成一团”的向量检索时问题向量和它做相似度计算结果几乎等于随机。所以必须把长文切成一个个语义相对完整的“块”。切分参数里有两个东西需要调chunk_size块的大小和overlap相邻块之间重叠的长度。我做了多组对比测试拿一份QA格式的运维手册来做实验切分方式单块长度重叠长度命中率体感按固定字符200切无重叠200字符0差答案经常被拦腰切断按固定字符500切重叠50500字符50中等绝大多数答案能完整命中按固定字符1000切重叠1001000字符100较差块内杂质太多检索不聚焦按语义段落递归切分动态50最好但也耗时更多我的经验是默认从chunk_size500、overlap50开始试这个组合适用于绝大多数技术文档。overlap不是可有可无的因为语义可能跨块比如“第一步是打开配置文件”在前一块末尾“接着修改第12行的参数”在下一块开头如果不重叠检索时单独看到任意一块都是不完整的。热词里有人问“有没有本地的RAG文本拆解工具”其实不需要专门工具LlamaIndex里的SentenceSplitter、LangChain里的RecursiveCharacterTextSplitter都是干这个的。我建议优先用“按递归分隔符切分”它会先按段落切再按句子切再按字符切语义完整性比纯固定长度好很多。2.2 Embedding模型选型决定“检索准不准”的隐形天花板Embedding模型负责把文本变成向量向量之间的相似度就是检索的依据。如果这一步不准后面所有的Rerank、Prompt优化都是在打补丁。我自己用过几类模型的感受如下nomic-embed-textOllama本地直接能拉下来跑起来几乎不占资源。英文表现不错中文属于“够用但不够好”。如果只是做技术Demo、验证流程用它起步完全没问题。bge-m3目前中文场景我比较推荐它对中文的支持明显更强而且支持同时输出密集向量和稀疏向量对后面做混合检索很有帮助。模型文件大概2GB左右普通笔记本能跑。text-embedding-3-small/large走OpenAI接口效果没得说中文也比很多开源模型好但私有化部署场景不适合用。bge-large-zh-v1.5专攻中文的老牌选手检索精度在不少公开榜单上依然能打缺点是只适合中文。选Embedding模型最容易犯的错是“只看排行榜分数”。真实业务里你的文档是中文技术文档、口语化客服记录还是英文论文最适合的模型完全不同。我现在的做法是拿自己的真实文档抽20个问题人工标注正确答案所在的段落然后分别用候选模型跑一遍召回看Top 5命中率。实测30分钟就能出结果比看任何榜单都有说服力。2.3 向量数据库怎么选我用FAISS、Chroma、Milvus的真实感受向量数据库负责把Embedding好的向量存起来并在检索时做最近邻搜索。热词里有人问“rag框架”其实向量库的选择本身就能决定这个项目的复杂度上限。我给自己的项目做过一次对比结论是这样的方案部署成本适合场景我实际遇到的情况FAISS极低一个Python库单机学习、原型验证检索很快但要自己管理索引的保存和加载Chroma低pip安装即可中小知识库、本地应用PersistentClient可以直接落盘体验很顺Milvus高需要Docker部署海量数据、高并发生产环境支持metadata过滤但小项目没必要上Qdrant中Docker或云服务需要复杂过滤条件的中大型项目Rust实现性能很稳Payload过滤方便如果你的知识库就几千个文档块我建议直接用Chroma或FAISS。我之前帮朋友做一个本地论文检索工具用的是Chroma索引落盘后启动秒加载完全够用。如果一上来就部署Milvus三件套光是运维组件就能绕晕。另外向量数据库不是越多功能越好。很多RAG项目真正需要的是“按来源过滤只查某一份文档”“按标签过滤”这种基础能力Chroma就已经支持了。别为了用分布式数据库而用分布式数据库。2.4 RAG知识库能存图片吗文本拆解工具与多模态的边界这是一个被问得非常多的问题RAG知识库能存储图片吗直接回答——传统的文本RAG不能但你可以用变通方案实现“图片进库”。图片和文字在嵌入空间里不是天然对齐的你不能把一张图片的原始二进制丢给文本Embedding模型。我试过的可行方案有几种第一种把图片变成“文字描述”再入库。用图像理解模型比如本地跑一个视觉模型对每张图片生成一段描述文字把这些描述文字做Embedding存入向量库检索命中后返回“图片文件路径描述文字”。这是成本最低、落地最快的方案你不需要更换现有RAG架构只是在文档预处理阶段加了一个环节。第二种用多模态Embedding模型比如CLIP类模型它能把图片和文本映射到同一个向量空间。查询时可以用文字搜到图片。这个方案更“正宗”但引入了一套新的嵌入模型体系复杂度高不少我建议先不考虑。第三种图片里嵌文字的情况比如截图、流程图、产品海报靠视觉理解模型把图片里的文字提取出来OCR再走文本RAG效果也很稳。所以如果你的业务知识库里确实有大量图片资料我的建议是先做OCR或图像描述把图片转成文本再进RAG。别一上来就追求“多模态RAG”这个概念工程上得不偿失。3. 检索到了不等于回答好生成端的“上下文使用方式”才是胜负手3.1 为什么召回文档一堆回答还是像没读过我调RAG的时候经常遇到一个奇怪现象日志里显示检索模块明明把5个片段都捞回来了而且肉眼看起来每个片段都沾边结果大模型给出的回答依然像没读过这些资料。排查到最后发现问题出在“内容太多了模型抓不到重点”。我们有个错觉认为给模型的资料越多回答就越可靠。实际上大模型面对一长串可能互相重叠、甚至互相矛盾的上下文时会出现“注意力稀释”。最典型的情况是5个检索片段里只有1个是真正切中问题的但其他4个都在讲相关但不完全对口的背景知识模型生成时被这些“关系不大的内容”带偏了。所以生成端的核心工程不是“有一个Prompt就能跑”而是做好注入内容的筛选和排序。我的做法是先在注入前做一次粗筛只保留和问题相似度最高的3到5块然后把最相关的放最前面。如果做了Rerank重排还要注意把重排后的得分写进Prompt模板让模型知道哪块内容优先级更高。3.2 我的Prompt模板强制引用来源与“宁缺毋滥”生成端的Prompt设计我踩过最大的坑是没有给模型“拒答的勇气”。默认情况下大模型有极强的“讨好型人格”你问它问题它拼了命也想给你一个完整回答哪怕知识库里根本没有相关内容。后来我总结出一套适合RAG场景的Prompt结构核心就三句话明确角色、给出资料、允许拒答。一个我实际在用的模板大概长这样你是企业内部知识库助手。请严格基于下面的资料内容回答问题。 资料 {context} 用户问题 {question} 要求 1. 回答必须来源于资料不要使用资料之外的常识。 2. 如果资料内容不足以回答请直接回复“知识库中没有找到相关信息”。 3. 每个结论后标注来源出处编号如[来源1]。 4. 不要编造数据不要自行推测。别小看这条要求我对比过“带拒答指令”和“不带拒答指令”的版本在测试集上前者把“胡说八道”的比率从30%降到了5%左右。尤其在企业内部知识库这种场景里模型答错比答“不知道”的代价大得多。3.3 Rerank重排召回50条里真正有用的可能只有5条很多RAG项目的检索结果是最原始的“向量相似度排序”。但这里有个很隐蔽的问题向量相似度是“文档块”与“问题”的全局相似度不是“这块内容里包含关键答案”的概率。一个文档块可能整体话题相关但关键答案藏在很角落里它的向量相似度反而不如另一块“看起来相关但没答案”的文本。解决这个问题的常用手段是Rerank重排序用一个专门的排序模型把检索回来的前几十条结果重新打分排序。说白了向量检索负责“快速筛出候选”Rerank负责“精确挑出答案”。这是一个经典的“粗排精排”架构搜索引擎多少年前就在用了。我实测过在纯向量召回Top 5命中率只有50%左右的数据集上加上Rerank之后Top 5命中率能提升到70%上下。而调用成本只是多跑一次小模型。Rerank模型可以选择本地推理的bge-reranker-v2-m3也有商用的接口优先考虑本地化。如果你用LangChain或LlamaIndexRerank通常只需要在检索器和最终合成器之间插入一个组件代码量不大但效果提升却肉眼可见。3.4 多轮对话隐藏在RAG的坑Query改写先于检索用户不会总是把话问完整。比如前面聊的是“报销流程”下一句问“那审批要多久”这里的“那”指代的是“报销审批”如果你直接把“那审批要多久”丢去检索向量匹配大概率会抓到一堆无关内容。这个问题的标准解法是Query改写也叫“对话式检索理解”。也就是说在进入检索模块之前先让大模型根据对话历史把当前问题补全成“完整问句”。比如把“那审批要多久”改写成“报销流程中财务审批环节需要多长时间”。我自己遇到过一个印象很深的案例用户连续问了十几个问题之后问了一句“这个呢”如果没有改写RAG直接懵了加了改写之后模型结合上文知道用户指的是“上一轮说过的某个设备的故障处理”检索准确率一下子从20%提到了80%。成本方面每次多一轮改写调用会多一点延迟但对效果提升来说完全值得。尤其在智能客服场景多轮对话几乎是标配。4. 零基础本地RAG实战Ollama LlamaIndex Chroma 三步跑通4.1 为什么选这套组合而不是大厂API方案热词里有“ollama 简易本地 rag 知识库【零基础可复制教程】”这正是我推荐很多新手起步的路线。选Ollama不是因为它能力最强而是因为它把本地模型部署这件事简化到了一条命令。你不需要手动配CUDA、不需要处理虚拟环境里的各种依赖Ollama会自动拉模型权重并在本地起一个兼容API。和LangChain4j的组合相比LlamaIndex在“文档到索引到问答”这条链路上封装得更薄、也更直观适合零基础用户先看懂RAG到底发生了什么。我写这篇文章时用的版本是LlamaIndex 0.10.x不同小版本API会有差异但核心逻辑不变。整条链路是Ollama负责提供Embedding模型和生成模型LlamaIndex负责做文档切分、向量化和检索问答Chroma负责向量落盘。全部运行在本地不需要联网调第三方接口也不涉及数据外发。4.2 环境准备一条命令拉起本地模型先装Ollama然后拉模型。我建议至少拉两个模型一个用于生成回答的对话模型一个用于文本向量化的Embedding模型。# 拉取生成模型我常用 qwen2.5:7b中文效果比较稳 ollama pull qwen2.5:7b # 拉取Embedding模型本地轻量首选 ollama pull nomic-embed-text然后安装Python依赖pip install llama-index llama-index-llms-ollama llama-index-embeddings-ollama chromadb到这里环境就准备好了。整个过程大概十几分钟主要看网络下载模型的时间。4.3 文档入库切分、向量化、落盘的代码骨架把一份PDF或TXT文档变成可检索的向量索引LlamaIndex的封装很简洁。我以一个data目录为例把文档放进去执行下面这段代码from llama_index.core import SimpleDirectoryReader, VectorStoreIndex, StorageContext from llama_index.core.node_parser import SentenceSplitter from llama_index.embeddings.ollama import OllamaEmbedding from llama_index.vector_stores.chroma import ChromaVectorStore import chromadb # 1. 读取文档 documents SimpleDirectoryReader(data).load_data() print(f加载了 {len(documents)} 份文档) # 2. 设置Embedding模型通过Ollama提供 embed_model OllamaEmbedding(model_namenomic-embed-text) # 3. 设置Chroma持久化存储 chroma_client chromadb.PersistentClient(path./chroma_db) chroma_collection chroma_client.get_or_create_collection(my_kb) vector_store ChromaVectorStore(chroma_collectionchroma_collection) storage_context StorageContext.from_defaults(vector_storevector_store) # 4. 构建索引LlamaIndex会用内置切分器自动分块 splitter SentenceSplitter(chunk_size512, chunk_overlap50) index VectorStoreIndex.from_documents( documents, embed_modelembed_model, storage_contextstorage_context, transformations[splitter], ) print(索引构建完成)这段代码跑完之后会在项目目录下生成一个chroma_db文件夹里面就是你的向量库。以后知识库内容有变化重新跑一次这段代码即可Chroma会按文档ID去重不会重复插入。4.4 问答闭环检索与生成最短可运行代码索引建好之后问答就变得非常简单了。LlamaIndex把“检索注入生成”封装成了as_query_engine你只需要指定生成时用哪个模型from llama_index.core import VectorStoreIndex from llama_index.llms.ollama import Ollama from llama_index.embeddings.ollama import OllamaEmbedding from llama_index.vector_stores.chroma import ChromaVectorStore import chromadb # 重新加载已有的Chroma存储 chroma_client chromadb.PersistentClient(path./chroma_db) chroma_collection chroma_client.get_or_create_collection(my_kb) vector_store ChromaVectorStore(chroma_collectionchroma_collection) # 组装索引 embed_model OllamaEmbedding(model_namenomic-embed-text) index VectorStoreIndex.from_vector_store(vector_store, embed_modelembed_model) # 配置生成模型 llm Ollama(modelqwen2.5:7b, request_timeout120.0) # 构建问答引擎指定检索条数 query_engine index.as_query_engine(llmllm, similarity_top_k5) # 提问 response query_engine.query(报销流程中财务审核需要多久) print(response)就这样一个完整的本地RAG已经可以用了。我做过一次最小测试放入3份常见的公司制度文档问“年假累计规则是什么”回答基本准确而且能定位到具体文档片段。如果你用的是Java技术栈对应方案是LangChain4j的Easy RAG模块它的思路和LlamaIndex一样把文档切分、向量化、检索、问答串成一条流水线感兴趣的同学可以直接按官方文档里的Easy RAG入门示例跑。代码骨架的差别只是语言层面的核心原理没有区别。5. RAG的瓶颈到底在哪来自真实项目中的失败案例与评测经验5.1 检索不到必然答不好但检索到了也一样会答砸我在做第一个RAG项目时最大的教训就是“检索到了照样会答砸”。有一个测试问题检索结果里明明有正确答案对应的文档块模型却给出了相反的回答。后来逐条排查才发现知识库里有新旧两版制度旧版写着“报销需人工审核”新版写着“报销自动通过”两块内容都被检索回来模型没分清新旧关系随机参考了旧的那条。这暴露了一个RAG的关键瓶颈文档块的语义独立性是假设出来的实际上文档之间有版本、有逻辑关联、还有相互矛盾。单纯靠向量相似度召回无法理解文档之间的时序和从属关系。解决思路通常有两个方向。一是增强切分阶段的能力把“版本号”“生效日期”这类元数据随文档块一起存起来在注入到Prompt时进行过滤二是在检索阶段引入业务规则比如按文档更新时间做加权让新版本优先。5.2 知识库的逻辑冲突RAG比模型更容易“左右互搏”很多人在讨论模型幻觉但RAG场景下更常见的问题是“知识库内部逻辑冲突”。知识库里不同作者写的文档用词不一致甚至口径不一致这在实际企业文档里非常普遍。比如A文档写“项目延期的处理流程是先报备再调整排期”B文档写“延期超过一周需要重新立项”。用户问“项目延期怎么办”时两个文档都被召回模型就会在回答里既提“先报备”、又提“重新立项”读者完全搞不清流程到底是什么。这种问题不是靠优化Prompt能解决的根源在知识库本身的治理。我现在做RAG项目都会专门安排一个“知识梳理”阶段把同主题文档合并、统一术语、标记冲突然后再入库。这一步虽然不属于技术编码但对最终效果的贡献可能超过任何模型调优。5.3 混合检索与重排序关键词和语义不是对手而是队友纯向量检索在专业术语、缩写、编号这些场景下经常失手。比如用户搜“CR-101错误码”向量检索可能把“CR”和“101”拆得支离破碎反而漏掉包含“CR-101”的精确匹配文档。这时候传统的BM25关键词检索反而更准。所以我在正式一点的RAG项目里越来越倾向于混合检索同时跑向量相似度检索和BM25关键词检索然后合并结果再做重排序。LlamaIndex里已经内置了QueryFusion之类的检索器封装LangChain也有对应的EnsembleRetriever。代码改动不大但能同时覆盖“语义相近但用词不同”和“精确匹配但向量表达弱”两类问题。5.4 没有评测集优化就是盲人摸象这条是我最想强调的经验。RAG项目的优化环节最怕什么最怕“我感觉效果好了一点”。感觉是不靠谱的因为你换了一个切分参数、换了一个Embedding模型效果可能在某些问题上提升在另一些问题上反而退化。没有统一的评测集你就无法判断到底该往哪个方向调。我现在做RAG第一步会先花时间构建一份评测问题集从真实用户提问中抽50到100条每一条标注“标准答案所在文档”和“正确答案摘要”。然后定义几个核心指标召回命中率检索结果Top 10里是否包含标准答案所在文档块答案准确率人工判断生成回答是否引用了正确内容拒答正确率无法回答时是否会说不知道每次改动之后跑一遍评测集记录指标变化。这个习惯帮我避免了很多“调参玄学”。说句实话RAG项目投入产出比最高的动作不是选更贵的模型而是先建评测集。5.5 RAG的边界什么时候不适合上RAG不是所有场景都适合RAG。如果你的问答高度依赖实时数据比如“当前库存多少”RAG不如直接查数据库如果你的问题是复杂的多步推理比如“对比三份合同里付款条款的差异”RAG单纯做相似度检索很难把需要对比的段落同时捞全如果你的知识库没有一个基础的文本结构全是扫描版且OCR都做不准RAG跑起来也会非常吃力。所以我现在接项目时会先问知识库的状态文档是否至少是数字化文本内容是否有清晰的结构章节、段落、标题更新频率多高如果三个回答都是“否”我会直接告诉对方先把数据治理做好再谈RAG。6. 从普通RAG到“RAG智能体”与Ontology RAG我的进阶路线6.1 RAG智能体和普通RAG不是一回事热词榜上“rag智能体”的热度一直不低。我认为它和普通RAG的本质区别在于普通RAG是“推翻检索结果给你看”智能体RAG是把检索工具交给模型自主调用。模型可以根据用户问题决定要不要检索、检索几次、是先查当前文档还是先查另一个系统。我做过一个对比实验普通RAG面对“综合A文档和B文档的信息回答”这种问题时经常只取到其中一份文档的内容而智能体形态下模型可以拆解成两步“先用A文档检索再用B文档检索然后汇总”回答质量明显更高。但代价是引入了Agent调用带来的不确定性和延迟。我的建议是新手先老老实实把普通RAG调好再考虑智能体形态。很多项目连检索命中率都没做到70%就急着上Agent结果只是把错误答案包装得更花哨。6.2 Ontology RAG和Wiki式知识库解决的是不同问题热词里还有“ontology rag”和“wiki和rag”。我个人的理解是Ontology RAG是在RAG之上增加了一层“概念关系图谱”比如“发票”和“报销”之间存在关联“采购合同”和“供应商”之间存在关联。普通向量检索只会找字面相似Ontology RAG会利用这些关系做多跳检索把隔着两层关系的知识也捞出来。Wiki式知识库则更像一类结构良好的数据源它有清晰的目录、页面分类和互相链接。用这种结构化的知识库做RAG切分和召回都会更顺利。所以“wiki和RAG”实际上是在问“知识源的组织形式如何影响RAG效果”答案很简单结构越清晰RAG越省力。我目前的路线是如果知识库是杂乱的文档集合先把Ontology或者人工标签体系加进去而不是一上来就追求复杂的图谱系统。哪怕只是在每个文档块上打一个“所属主题”的标签检索时按主题过滤效果就会提升不少。6.3 我的脚本式建议先跑通、再评测、后扩展如果让我给一个刚接触RAG的人排优先级我的建议是这样的第一步用Ollama加LlamaIndex跑通最小闭环重点体验“文档切分、向量检索、上下文注入、生成”这四个环节分别是什么感觉。第二步花时间做一份评测集至少50条问题并跑出每个环节的基线数据。这一步能帮你建立“不是凭感觉而是凭数据”的调优习惯。第三步根据评测结果补短板检索不行先看切分和Embedding模型生成不准先看Prompt模板和Rerank多轮对话差先做Query改写。第四步再考虑进阶方向混合检索、Agent调用、Ontology图谱、多模态入库按业务需求逐层加。我在实际项目里发现绝大多数RAG问题不是模型不够强而是检索这一段没做扎实。先把这段地基打好再谈花活比什么都管用。
