最近在技术社群里被问得最多的问题几乎都和 RAG 有关。有人问“为什么我的大模型应用已经接了向量数据库回答还是像在编故事”也有人问“RAG 知识库到底能不能存图片”“RAG 的瓶颈到底在哪”。这些问题背后其实都指向同一个核心很多人把 RAG 和大模型的关系理解成了“拼装组件”却忽略了它们之间真正的协作逻辑。RAGRetrieval-Augmented Generation检索增强生成本质上是在大模型外部挂了一个动态知识源它不修改模型参数而是在模型生成之前先检索相关内容再让模型基于这些检索结果作答。这个机制看起来简单实际落地时却牵扯到知识边界、上下文窗口、嵌入模型、向量索引、混合检索、重排等一系列工程问题。如果不把这些关系理顺就算把组件全部接上效果也一定不会好。这篇文章适合正在做知识库问答、企业私有化部署、文档对话应用的开发者也适合准备从零搭建 RAG 系统的架构师和项目负责人。我会从 RAG 和大模型的底层关系讲起结合真实落地时的选型、参数配置和踩坑经验把 RAG 从原理到实践彻底讲透。1. RAG 与大模型到底在解决什么问题1.1 大模型的幻觉与知识时效短板在解释关系之前先说一件很基本的事情大模型本身其实是一个静态的概率模型。它的知识全部来自预训练阶段见到的语料一旦训练完成新的事实、新的文档、企业内部的数据对它来说都是不存在的。你可以把预训练想象成一个学生考前突击背诵了大量书籍但考试时是闭卷。很多团队希望大模型能回答基于内部知识库的问题却忘了它根本没读过这本“内部教材”。这个问题带来的直接后果是知识时效性差。预训练语料有截止日期模型对截止日期之后发生的事情一无所知。比如你问它公司上个月刚发布的新版报销制度它大概率会用几年前的老制度来“脑补”因为那是它在训练语料里见过的最接近的信息。这种问题不是靠增加模型参数量能解决的因为参数已经固定了你能做的只是换一个更大的模型或者让模型在生成时能接触到新知识。再说幻觉。幻觉来自大模型生成文本的本质它在每一个 token 上都是按概率选取的。如果某个问题触发了它众多训练样本中相似但不一致的模式模型就会平滑地编出一个看起来合理的答案。很多场景下你问它一个内部标准文件里才有的数据它不知道就会用通用知识中的类似信息去填补。这也是为什么光靠大模型本身很难根治“一本正经地胡说八道”的问题。模型不是故意撒谎它只是没有足够的事实依据来约束生成方向。1.2 把 RAG 理解成大模型的“外挂记忆”RAG 解决的正是静态知识和动态知识之间的矛盾。它的核心思路是让大模型在回答问题前先从外部知识库里检索出与问题最相关的文档片段把这些片段作为附加的上下文一起喂给大模型。模型的参数没有任何变化但输入的信息从“只有训练时见过的静态记忆”变成了“实时检索的动态记忆”。这个关系可以用一个很简单的类比来记大模型是一个擅长答题的考生RAG 是考场里允许翻阅的参考书。没有 RAG考生只能靠记忆硬答容易答错或者编出答案有了 RAG考生先翻书找到相关章节再组织语言正确率自然会大幅提升。所以 RAG 并不是给大模型打补丁的简单附加组件而是重新定义了大模型应用的输入边界。有人会把 RAG 理解成“双方是合作关系”我更喜欢说它是一种“主从关系”。大模型是主体负责推理和生成RAG 是从属的检索层任务是为大模型提供高质量的上下文材料。如果检索不到相关内容或者检索出来的内容本身是噪音大模型再强也容易被带偏。所以理解这层关系的核心是知道优化 RAG 的重点不在模型本身而在检索质量和上下文组织上。2. RAG 系统的核心组件与工作流程2.1 离线索引让知识变成可被检索的向量RAG 系统的第一个阶段是离线索引任务是把手头的 PDF、Word、Markdown、网页抓取内容等原始文档加工成能快速检索的索引。这个阶段包含三个环节内容解析、文本切分、向量化。内容解析是第一步也是最容易被忽略的一步。比如 PDF 里的表格直接抽取出来往往会变成一堆混乱字符如果不做表格结构重组后面的检索几乎拿不到像样的片段。再比如 Word 文档里的图片说明、页眉页脚这些噪声会让切分出来的文本块语义不够连贯。我的习惯是在解析阶段就做一遍结构化处理表格转成简单的文本描述去掉页眉页脚尽量保留标题层级信息。这一步做得好后面的检索效果就有了根基。然后是文本切分。切分的目标是把长文档拆成适合检索和生成的块。块太大向量检索的语义会被稀释块太小又可能丢失上下文关联。实践中常见的做法是按固定字符数切分比如每 512 个 token 一块同时让相邻块之间有重叠通常重叠 20 到 100 个字符。效果更好一点的做法是优先按标题、章节、段落等结构边界切分这对 Markdown 文档特别友好。LangChain 里的 RecursiveCharacterTextSplitter 大多时候就是用来做这件事的你也可以自己写一个简化版本def split_text(text, chunk_size500, overlap50): chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) start end - overlap return chunks实际项目里不会真的这么粗糙但核心逻辑就是这样拿一个滑动窗口在文本上移动让每个块都保留一点前后文的线索。之后要用嵌入模型把每个文本块转换成一串浮点向量也就是向量化。这一步的关键是离线嵌入和在线查询时必须使用同一个嵌入模型并且尽量保持输入规则一致否则向量空间不对齐召回效果会很差。向量化完成后把向量连同原始文本、文档来源、页码等元数据一起存入向量数据库离线索引阶段就结束了。这里顺便提一下大模型本身并不直接“阅读”文档它看到的是经过解析和切分后的文本块。这也是为什么很多团队问“大模型如何理解文档”时答案往往不是去调模型而是先把文档处理管线做好。2.2 在线检索从问题到相关片段当用户提问时系统进入在线检索阶段。用户的问题通常是短文本你需要用同一个嵌入模型把问题也转成向量然后在向量数据库里做相似度检索。最常用的相似度计算方式是余弦相似度值越接近 1 表示越相关。检索时指定 Top-K比如返回最相关的 3 到 5 个片段。这里有一个很重要的工程细节只看相似度排序是不够的你需要设一个相似度阈值。比如低于 0.75 的片段就不要返回给大模型否则模型会把一堆不相关的文本硬塞进上下文反而干扰判断。我见过很多 RAG 效果差的案例最后查下来都是因为没有做阈值过滤几乎每次都把向量数据库里距离最近但实际不相关的文本全部喂给模型结果模型被噪音带偏。另外元数据过滤也是提升检索质量的常用手段。比如知识库里有不同年份的合规文件当用户问的是“今年的报销标准”时可以在检索前先按日期元数据筛掉去年的文档再做向量相似度计算。这相当于给检索加了一个前置漏斗召回出来的内容会干净很多。2.3 在线生成提示词里的“参考资料”检索到相关片段后系统要把这些片段和用户的原始问题一起组装成一个新的提示词交给大模型生成答案。这一步看似简单但提示词的组织方式直接决定了模型是否会严格使用检索到的内容。一个常见的提示词模板是这样的根据以下参考资料回答用户问题。 如果你无法从参考资料中找到答案请直接回答“我不知道”不要编造。 参考资料 {检索到的片段 1} {检索到的片段 2} 用户问题{question}可以看到RAG 的生成阶段本质上是一个“带上下文的问答任务”。这时候大模型的上下文窗口长度就变成了一个约束。窗口太小检索结果多了会被截断窗口太大处理速度变慢成本也会上升。所以实际落地时要根据场景平衡如果是客服类场景通常给 3 到 5 个片段就够如果是法律条款类场景可能需要更多片段但也不要无脑塞满上下文。从整个流程可以看到RAG 和大模型的关系并不是割裂的。检索结果的质量决定了生成阶段的上限而提示词的组织方式又决定了检索结果能否被充分使用。任何一个环节脱节最终反映出来的都是“大模型回答不准”的表面现象。3. 决定检索质量的工程细节3.1 嵌入模型与向量数据库的选择嵌入模型决定了检索的上限。对中文场景过去用得较多的是 BGE-large-zh 或 M3E 这类开源模型最近也有不少团队直接用 OpenAI 的 text-embedding-3-small效果稳定但需要考虑数据传输和成本。如果做企业私有化部署我建议优先选择开源嵌入模型放在本地 GPU 上跑这样既能避免敏感数据出网也方便和本地部署的大模型搭配使用。对于 Java 技术栈的团队LangChain4j 也可以用来快速搭建 RAG 流程省去很多重复工作。向量数据库的选择依据主要是数据量和并发。如果只是个人项目或小团队原型Chroma 或 FAISS 就够了如果数据量在百万级别且需要高并发查询建议使用 Qdrant 或 Milvus如果技术栈本来就是 PostgreSQL那 pgvector 是最省事的选择。我在项目里见过有人直接用通用关系型数据库硬扛向量检索效果非常糟糕向量索引的类型和搜索算法都是专门的通用关系型数据库很难直接扛住。方案适合场景特点部署方式Chroma原型、单机小数据简单易用依赖少嵌入式 / 本地FAISS研究、离线检索性能高但需要自己维护索引本地库Qdrant生产、高并发支持丰富的过滤条件Rust 实现Docker / 集群Milvus大规模生产分布式能力强组件较多集群pgvector已有 PostgreSQL 的团队与业务数据在同一个存储中数据库插件3.2 切分策略、重叠与元数据管理切分策略是 RAG 效果的隐形决定因素。很多人花大量时间调模型最后发现问题出在切分导致的召回质量差。长文档切分时一定要考虑语义完整性如果在句子中间切断检索到的片段可能只有半句话模型拿到手也看不懂。我的经验是优先用段落边界或标题层级切分。比如 Markdown 文档按二级标题拆成章节每个章节再按段落拆成 300 到 500 字左右的块。如果文档结构不明显就退而求其次用递归字符切分先按段落分再按句子分并保证相邻块有重叠。与切分紧密相关的是元数据管理。元数据包括文档名称、来源链接、页码、所属分类、更新日期等。检索时可以拿元数据做过滤条件也可以在结果展示时帮用户做溯源。这里有一个很实用的设计叫父文档检索索引时把文档拆成两层大块用来给大模型做上下文小块用来做向量检索。当小块命中时把所在的大块返回给模型。这样既能提高检索精确度又避免上下文信息缺失。这个方案在实测里对长文档的问答效果提升非常明显。3.3 混合检索与重排提升召回的组合拳纯向量检索有个明显短板对精确匹配不敏感。比如用户查的是某个文件的编号向量语义检索可能会把编号和其他相似文本混在一起效果很差。而传统的 BM25 关键词检索恰恰擅长这种精确匹配。所以现在主流的 RAG 系统基本都会做混合检索向量检索和关键词检索同时跑再合并两路结果。合并时可以简单对分数做加权也可以使用 RRFReciprocal Rank Fusion这类经典算法。我习惯先用 RRF 把两路结果的排序融合再交给一个重排模型精排。重排模型通常是交叉编码器会把查询和每个候选片段一起输入计算相关性分数。它比单纯看向量相似度准确很多但速度慢只适合对少量候选做精排。推荐的流程是向量召回 20 条BM25 召回 20 条合并去重后用重排模型取前 5 条。这一步做完最终喂给大模型的内容质量会有非常直观的提升。4. RAG 与微调的定位和组合4.1 微调增强的是行为能力RAG 提供的是事实知识很多人在做知识库问答时都会问用 RAG 还是微调这个问题本身就有点误导。微调是改大模型的参数改变模型的输出行为RAG 是在输入侧做文章给模型提供额外的参考信息。两者解决的是不同维度的问题。举一个具体例子如果你希望模型用客服口吻回答问题并且习惯在回答前先做情绪安抚那微调非常合适。如果你希望模型能回答公司内部最新产品手册里才有的功能细节RAG 是首选。产品手册会频繁更新你不可能为了一个新版本就重新微调一遍模型。更现实的做法是用一个通用底座模型加上 RAG 注入动态知识再用少量微调让模型学会特定表达风格。4.2 什么场景应该优先选 RAG什么场景需要微调这个问题我经常给团队一个简单的判断标尺知识会不会经常变如果会用 RAG。回答风格是否需要高度统一如果需要用微调。两者都占就一起用。展开来说企业知识问答、技术文档客服、法律法规检索、医疗知识库这类场景数据是动态更新的用户还希望看到答案来源RAG 比微调合适得多。而代码生成助手需要严格遵循团队的代码规范摘要助手需要固定输出格式这些更依赖模型的行为能力微调效果更直接。注意这两者并不互斥。我实际做项目时更倾向于叠加使用先用微调让模型学会“引用参考资料回答”的行为再用 RAG 把参考资料动态喂给它。在这样的架构里微调承担的是“怎么回答”的任务RAG 承担的是“回答什么”的任务各管一段反而更清晰。5. 常见误区、瓶颈与高频问题排查5.1 RAG 知识库能存图片吗这个问题被问得非常频繁直接给结论传统 RAG 知识库本身是为文本设计的但通过一定处理图片是可以被用起来的。如果向量数据库只支持文本嵌入图片需要先转成文字才能进知识库。常见做法有两个一是用 OCR 把图片里的文字提取出来存成文本字段二是用多模态大模型对图片生成一段描述文本再把描述文本向量化。这样用户提问时系统就能检索到与图片内容相关的文字描述并在答案里返回图片路径。如果希望直接做“以文搜图”或者“以图搜图”那就需要引入多模态嵌入模型比如 CLIP。这类模型可以把图片和文本映射到同一个向量空间用户用文字描述图片内容系统就能检索到视觉上匹配的图片。但这种方案的工程复杂度明显更高需要对图片做预处理、向量化、存储普通场景不建议一上来就上多模态 RAG。最轻量的做法是把图片关联的文本描述保存到 RAG 知识库里用户问到某类图片时系统返回相关描述和图片路径基本能满足大部分业务需求。5.2 RAG 的性能瓶颈到底在哪里RAG 的瓶颈不是单点问题我把它分成四类来看。第一类是召回瓶颈。文档切分和嵌入模型决定了召回的上限。切分没有保留语义完整性检索出来的片段答非所问知识库里的文本和用户问题的表达方式相差太远向量相似度也会很低。第二类是上下文瓶颈。大模型上下文窗口有限检索出的相关内容可能被截断或遗漏。第三类是数据更新瓶颈。知识库文档更新后如果没有及时重建索引检索到的仍然是旧内容。第四类是评测瓶颈。很多团队没有一套标准测试集去衡量召回和生成效果改了一版参数却不知道效果到底是变好还是变差。针对这些瓶颈建议先把切分策略跑通用一批人工标注的问答对来评测检索召回前 10 条的准确率。然后叠加混合检索和重排把精确匹配和语义召回的优势都用上。数据更新流程要做版本控制每次更新后重新执行索引任务。最关键的是建立一个小型评估集定期做回归测试这样才能知道每次改动到底有没有效。5.3 落地时的踩坑清单和排查思路最后分享一些我实际踩过的坑基本都是常规文档里不会写的东西。第一不要把整个长文档直接塞进提示词。超过上下文窗口后模型会丢失重点回答质量急剧下降。正确的做法是检索相关片段按相关性排序后再拼接。第二注意提示词指令冲突。比如你既告诉模型“必须基于参考资料回答”又在系统提示词里要求它“尽情发挥创造力”模型就会很矛盾。系统提示词和 RAG 的回答要求必须保持一致。第三文档里的表格和图片很容易被忽略。很多知识库的关键信息就在表格里如果解析时没有专门处理表格检索就永远找不到正确答案。建议在解析阶段对表格做结构化转换把表格内容转成清晰的文本描述。第四一定要做评估集。我见过太多项目调了三天提示词凭感觉觉得效果变好了最后用标准测试集一测准确率反而下降了。没有评估就没有优化方向这是 RAG 项目里最重要的一条经验。做 RAG 这几年我最大的感受是它和大模型的关系并不是“组件与组件”的拼装而是“检索重塑输入”的关系。很多团队花大量时间调大模型参数最后发现效果上不去的真正原因是文档解析不干净、切分策略不合理、没有做重排。如果你也在做类似项目建议先从检索侧入手拿一批最头疼的问题去测召回效果再回头调整生成提示词。这条路径走通之后再回头看 RAG 和大模型的关系会比任何概念解释都清楚。
RAG实战指南：大模型外挂知识库的原理与工程落地
最近在技术社群里被问得最多的问题几乎都和 RAG 有关。有人问“为什么我的大模型应用已经接了向量数据库回答还是像在编故事”也有人问“RAG 知识库到底能不能存图片”“RAG 的瓶颈到底在哪”。这些问题背后其实都指向同一个核心很多人把 RAG 和大模型的关系理解成了“拼装组件”却忽略了它们之间真正的协作逻辑。RAGRetrieval-Augmented Generation检索增强生成本质上是在大模型外部挂了一个动态知识源它不修改模型参数而是在模型生成之前先检索相关内容再让模型基于这些检索结果作答。这个机制看起来简单实际落地时却牵扯到知识边界、上下文窗口、嵌入模型、向量索引、混合检索、重排等一系列工程问题。如果不把这些关系理顺就算把组件全部接上效果也一定不会好。这篇文章适合正在做知识库问答、企业私有化部署、文档对话应用的开发者也适合准备从零搭建 RAG 系统的架构师和项目负责人。我会从 RAG 和大模型的底层关系讲起结合真实落地时的选型、参数配置和踩坑经验把 RAG 从原理到实践彻底讲透。1. RAG 与大模型到底在解决什么问题1.1 大模型的幻觉与知识时效短板在解释关系之前先说一件很基本的事情大模型本身其实是一个静态的概率模型。它的知识全部来自预训练阶段见到的语料一旦训练完成新的事实、新的文档、企业内部的数据对它来说都是不存在的。你可以把预训练想象成一个学生考前突击背诵了大量书籍但考试时是闭卷。很多团队希望大模型能回答基于内部知识库的问题却忘了它根本没读过这本“内部教材”。这个问题带来的直接后果是知识时效性差。预训练语料有截止日期模型对截止日期之后发生的事情一无所知。比如你问它公司上个月刚发布的新版报销制度它大概率会用几年前的老制度来“脑补”因为那是它在训练语料里见过的最接近的信息。这种问题不是靠增加模型参数量能解决的因为参数已经固定了你能做的只是换一个更大的模型或者让模型在生成时能接触到新知识。再说幻觉。幻觉来自大模型生成文本的本质它在每一个 token 上都是按概率选取的。如果某个问题触发了它众多训练样本中相似但不一致的模式模型就会平滑地编出一个看起来合理的答案。很多场景下你问它一个内部标准文件里才有的数据它不知道就会用通用知识中的类似信息去填补。这也是为什么光靠大模型本身很难根治“一本正经地胡说八道”的问题。模型不是故意撒谎它只是没有足够的事实依据来约束生成方向。1.2 把 RAG 理解成大模型的“外挂记忆”RAG 解决的正是静态知识和动态知识之间的矛盾。它的核心思路是让大模型在回答问题前先从外部知识库里检索出与问题最相关的文档片段把这些片段作为附加的上下文一起喂给大模型。模型的参数没有任何变化但输入的信息从“只有训练时见过的静态记忆”变成了“实时检索的动态记忆”。这个关系可以用一个很简单的类比来记大模型是一个擅长答题的考生RAG 是考场里允许翻阅的参考书。没有 RAG考生只能靠记忆硬答容易答错或者编出答案有了 RAG考生先翻书找到相关章节再组织语言正确率自然会大幅提升。所以 RAG 并不是给大模型打补丁的简单附加组件而是重新定义了大模型应用的输入边界。有人会把 RAG 理解成“双方是合作关系”我更喜欢说它是一种“主从关系”。大模型是主体负责推理和生成RAG 是从属的检索层任务是为大模型提供高质量的上下文材料。如果检索不到相关内容或者检索出来的内容本身是噪音大模型再强也容易被带偏。所以理解这层关系的核心是知道优化 RAG 的重点不在模型本身而在检索质量和上下文组织上。2. RAG 系统的核心组件与工作流程2.1 离线索引让知识变成可被检索的向量RAG 系统的第一个阶段是离线索引任务是把手头的 PDF、Word、Markdown、网页抓取内容等原始文档加工成能快速检索的索引。这个阶段包含三个环节内容解析、文本切分、向量化。内容解析是第一步也是最容易被忽略的一步。比如 PDF 里的表格直接抽取出来往往会变成一堆混乱字符如果不做表格结构重组后面的检索几乎拿不到像样的片段。再比如 Word 文档里的图片说明、页眉页脚这些噪声会让切分出来的文本块语义不够连贯。我的习惯是在解析阶段就做一遍结构化处理表格转成简单的文本描述去掉页眉页脚尽量保留标题层级信息。这一步做得好后面的检索效果就有了根基。然后是文本切分。切分的目标是把长文档拆成适合检索和生成的块。块太大向量检索的语义会被稀释块太小又可能丢失上下文关联。实践中常见的做法是按固定字符数切分比如每 512 个 token 一块同时让相邻块之间有重叠通常重叠 20 到 100 个字符。效果更好一点的做法是优先按标题、章节、段落等结构边界切分这对 Markdown 文档特别友好。LangChain 里的 RecursiveCharacterTextSplitter 大多时候就是用来做这件事的你也可以自己写一个简化版本def split_text(text, chunk_size500, overlap50): chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) start end - overlap return chunks实际项目里不会真的这么粗糙但核心逻辑就是这样拿一个滑动窗口在文本上移动让每个块都保留一点前后文的线索。之后要用嵌入模型把每个文本块转换成一串浮点向量也就是向量化。这一步的关键是离线嵌入和在线查询时必须使用同一个嵌入模型并且尽量保持输入规则一致否则向量空间不对齐召回效果会很差。向量化完成后把向量连同原始文本、文档来源、页码等元数据一起存入向量数据库离线索引阶段就结束了。这里顺便提一下大模型本身并不直接“阅读”文档它看到的是经过解析和切分后的文本块。这也是为什么很多团队问“大模型如何理解文档”时答案往往不是去调模型而是先把文档处理管线做好。2.2 在线检索从问题到相关片段当用户提问时系统进入在线检索阶段。用户的问题通常是短文本你需要用同一个嵌入模型把问题也转成向量然后在向量数据库里做相似度检索。最常用的相似度计算方式是余弦相似度值越接近 1 表示越相关。检索时指定 Top-K比如返回最相关的 3 到 5 个片段。这里有一个很重要的工程细节只看相似度排序是不够的你需要设一个相似度阈值。比如低于 0.75 的片段就不要返回给大模型否则模型会把一堆不相关的文本硬塞进上下文反而干扰判断。我见过很多 RAG 效果差的案例最后查下来都是因为没有做阈值过滤几乎每次都把向量数据库里距离最近但实际不相关的文本全部喂给模型结果模型被噪音带偏。另外元数据过滤也是提升检索质量的常用手段。比如知识库里有不同年份的合规文件当用户问的是“今年的报销标准”时可以在检索前先按日期元数据筛掉去年的文档再做向量相似度计算。这相当于给检索加了一个前置漏斗召回出来的内容会干净很多。2.3 在线生成提示词里的“参考资料”检索到相关片段后系统要把这些片段和用户的原始问题一起组装成一个新的提示词交给大模型生成答案。这一步看似简单但提示词的组织方式直接决定了模型是否会严格使用检索到的内容。一个常见的提示词模板是这样的根据以下参考资料回答用户问题。 如果你无法从参考资料中找到答案请直接回答“我不知道”不要编造。 参考资料 {检索到的片段 1} {检索到的片段 2} 用户问题{question}可以看到RAG 的生成阶段本质上是一个“带上下文的问答任务”。这时候大模型的上下文窗口长度就变成了一个约束。窗口太小检索结果多了会被截断窗口太大处理速度变慢成本也会上升。所以实际落地时要根据场景平衡如果是客服类场景通常给 3 到 5 个片段就够如果是法律条款类场景可能需要更多片段但也不要无脑塞满上下文。从整个流程可以看到RAG 和大模型的关系并不是割裂的。检索结果的质量决定了生成阶段的上限而提示词的组织方式又决定了检索结果能否被充分使用。任何一个环节脱节最终反映出来的都是“大模型回答不准”的表面现象。3. 决定检索质量的工程细节3.1 嵌入模型与向量数据库的选择嵌入模型决定了检索的上限。对中文场景过去用得较多的是 BGE-large-zh 或 M3E 这类开源模型最近也有不少团队直接用 OpenAI 的 text-embedding-3-small效果稳定但需要考虑数据传输和成本。如果做企业私有化部署我建议优先选择开源嵌入模型放在本地 GPU 上跑这样既能避免敏感数据出网也方便和本地部署的大模型搭配使用。对于 Java 技术栈的团队LangChain4j 也可以用来快速搭建 RAG 流程省去很多重复工作。向量数据库的选择依据主要是数据量和并发。如果只是个人项目或小团队原型Chroma 或 FAISS 就够了如果数据量在百万级别且需要高并发查询建议使用 Qdrant 或 Milvus如果技术栈本来就是 PostgreSQL那 pgvector 是最省事的选择。我在项目里见过有人直接用通用关系型数据库硬扛向量检索效果非常糟糕向量索引的类型和搜索算法都是专门的通用关系型数据库很难直接扛住。方案适合场景特点部署方式Chroma原型、单机小数据简单易用依赖少嵌入式 / 本地FAISS研究、离线检索性能高但需要自己维护索引本地库Qdrant生产、高并发支持丰富的过滤条件Rust 实现Docker / 集群Milvus大规模生产分布式能力强组件较多集群pgvector已有 PostgreSQL 的团队与业务数据在同一个存储中数据库插件3.2 切分策略、重叠与元数据管理切分策略是 RAG 效果的隐形决定因素。很多人花大量时间调模型最后发现问题出在切分导致的召回质量差。长文档切分时一定要考虑语义完整性如果在句子中间切断检索到的片段可能只有半句话模型拿到手也看不懂。我的经验是优先用段落边界或标题层级切分。比如 Markdown 文档按二级标题拆成章节每个章节再按段落拆成 300 到 500 字左右的块。如果文档结构不明显就退而求其次用递归字符切分先按段落分再按句子分并保证相邻块有重叠。与切分紧密相关的是元数据管理。元数据包括文档名称、来源链接、页码、所属分类、更新日期等。检索时可以拿元数据做过滤条件也可以在结果展示时帮用户做溯源。这里有一个很实用的设计叫父文档检索索引时把文档拆成两层大块用来给大模型做上下文小块用来做向量检索。当小块命中时把所在的大块返回给模型。这样既能提高检索精确度又避免上下文信息缺失。这个方案在实测里对长文档的问答效果提升非常明显。3.3 混合检索与重排提升召回的组合拳纯向量检索有个明显短板对精确匹配不敏感。比如用户查的是某个文件的编号向量语义检索可能会把编号和其他相似文本混在一起效果很差。而传统的 BM25 关键词检索恰恰擅长这种精确匹配。所以现在主流的 RAG 系统基本都会做混合检索向量检索和关键词检索同时跑再合并两路结果。合并时可以简单对分数做加权也可以使用 RRFReciprocal Rank Fusion这类经典算法。我习惯先用 RRF 把两路结果的排序融合再交给一个重排模型精排。重排模型通常是交叉编码器会把查询和每个候选片段一起输入计算相关性分数。它比单纯看向量相似度准确很多但速度慢只适合对少量候选做精排。推荐的流程是向量召回 20 条BM25 召回 20 条合并去重后用重排模型取前 5 条。这一步做完最终喂给大模型的内容质量会有非常直观的提升。4. RAG 与微调的定位和组合4.1 微调增强的是行为能力RAG 提供的是事实知识很多人在做知识库问答时都会问用 RAG 还是微调这个问题本身就有点误导。微调是改大模型的参数改变模型的输出行为RAG 是在输入侧做文章给模型提供额外的参考信息。两者解决的是不同维度的问题。举一个具体例子如果你希望模型用客服口吻回答问题并且习惯在回答前先做情绪安抚那微调非常合适。如果你希望模型能回答公司内部最新产品手册里才有的功能细节RAG 是首选。产品手册会频繁更新你不可能为了一个新版本就重新微调一遍模型。更现实的做法是用一个通用底座模型加上 RAG 注入动态知识再用少量微调让模型学会特定表达风格。4.2 什么场景应该优先选 RAG什么场景需要微调这个问题我经常给团队一个简单的判断标尺知识会不会经常变如果会用 RAG。回答风格是否需要高度统一如果需要用微调。两者都占就一起用。展开来说企业知识问答、技术文档客服、法律法规检索、医疗知识库这类场景数据是动态更新的用户还希望看到答案来源RAG 比微调合适得多。而代码生成助手需要严格遵循团队的代码规范摘要助手需要固定输出格式这些更依赖模型的行为能力微调效果更直接。注意这两者并不互斥。我实际做项目时更倾向于叠加使用先用微调让模型学会“引用参考资料回答”的行为再用 RAG 把参考资料动态喂给它。在这样的架构里微调承担的是“怎么回答”的任务RAG 承担的是“回答什么”的任务各管一段反而更清晰。5. 常见误区、瓶颈与高频问题排查5.1 RAG 知识库能存图片吗这个问题被问得非常频繁直接给结论传统 RAG 知识库本身是为文本设计的但通过一定处理图片是可以被用起来的。如果向量数据库只支持文本嵌入图片需要先转成文字才能进知识库。常见做法有两个一是用 OCR 把图片里的文字提取出来存成文本字段二是用多模态大模型对图片生成一段描述文本再把描述文本向量化。这样用户提问时系统就能检索到与图片内容相关的文字描述并在答案里返回图片路径。如果希望直接做“以文搜图”或者“以图搜图”那就需要引入多模态嵌入模型比如 CLIP。这类模型可以把图片和文本映射到同一个向量空间用户用文字描述图片内容系统就能检索到视觉上匹配的图片。但这种方案的工程复杂度明显更高需要对图片做预处理、向量化、存储普通场景不建议一上来就上多模态 RAG。最轻量的做法是把图片关联的文本描述保存到 RAG 知识库里用户问到某类图片时系统返回相关描述和图片路径基本能满足大部分业务需求。5.2 RAG 的性能瓶颈到底在哪里RAG 的瓶颈不是单点问题我把它分成四类来看。第一类是召回瓶颈。文档切分和嵌入模型决定了召回的上限。切分没有保留语义完整性检索出来的片段答非所问知识库里的文本和用户问题的表达方式相差太远向量相似度也会很低。第二类是上下文瓶颈。大模型上下文窗口有限检索出的相关内容可能被截断或遗漏。第三类是数据更新瓶颈。知识库文档更新后如果没有及时重建索引检索到的仍然是旧内容。第四类是评测瓶颈。很多团队没有一套标准测试集去衡量召回和生成效果改了一版参数却不知道效果到底是变好还是变差。针对这些瓶颈建议先把切分策略跑通用一批人工标注的问答对来评测检索召回前 10 条的准确率。然后叠加混合检索和重排把精确匹配和语义召回的优势都用上。数据更新流程要做版本控制每次更新后重新执行索引任务。最关键的是建立一个小型评估集定期做回归测试这样才能知道每次改动到底有没有效。5.3 落地时的踩坑清单和排查思路最后分享一些我实际踩过的坑基本都是常规文档里不会写的东西。第一不要把整个长文档直接塞进提示词。超过上下文窗口后模型会丢失重点回答质量急剧下降。正确的做法是检索相关片段按相关性排序后再拼接。第二注意提示词指令冲突。比如你既告诉模型“必须基于参考资料回答”又在系统提示词里要求它“尽情发挥创造力”模型就会很矛盾。系统提示词和 RAG 的回答要求必须保持一致。第三文档里的表格和图片很容易被忽略。很多知识库的关键信息就在表格里如果解析时没有专门处理表格检索就永远找不到正确答案。建议在解析阶段对表格做结构化转换把表格内容转成清晰的文本描述。第四一定要做评估集。我见过太多项目调了三天提示词凭感觉觉得效果变好了最后用标准测试集一测准确率反而下降了。没有评估就没有优化方向这是 RAG 项目里最重要的一条经验。做 RAG 这几年我最大的感受是它和大模型的关系并不是“组件与组件”的拼装而是“检索重塑输入”的关系。很多团队花大量时间调大模型参数最后发现效果上不去的真正原因是文档解析不干净、切分策略不合理、没有做重排。如果你也在做类似项目建议先从检索侧入手拿一批最头疼的问题去测召回效果再回头调整生成提示词。这条路径走通之后再回头看 RAG 和大模型的关系会比任何概念解释都清楚。