本文详细介绍了RAG知识库构建的实用指南从调用链路、触发条件到架构位置帮助读者理解RAG与大模型的关系。文章还探讨了两种常见的调用模式并提供了四种判断是否触发RAG的方法。此外本文还深入分析了RAG构建的关键四步文档治理、切块策略、嵌入与向量库、检索策略以及RAG效果的评估与迭代。最后文章总结了RAG系统相关开源框架与技术栈为读者提供了实用的参考资料。RAG知识库构建的实用指南不算啥指南只是一些自己认为不熟练的内容做一个新的整理。RAG 与大模型的调用关系完整请求流程很多同学会困惑一个用户请求进来什么时候调用 RAG什么时候直接问大模型 这其实是个流程设计问题我梳理一下标准的调用链路典型的请求处理流程什么时候会触发 RAG[!tip]一句话总结当问题答案需要「你的私有知识库信息」时才需要调用 RAG。如果问题能用大模型的通用知识回答就不用调用。具体来说以下场景一定会触发 RAG场景例子是否触发RAG企业内部政策合规问题“我们公司年假规定是几天”✅ 必须触发产品文档/手册查询“这款手机的保修政策是什么”✅ 必须触发合同条款查询“这份合同里关于违约金怎么规定的”✅ 必须触发基于私有数据的分析“帮我分析下上个月销售数据中top3商品有什么特点”✅ 必须触发通用知识问题“Python怎么定义一个类”❌ 直接问大模型创意生成“帮我写一封节日祝福邮件”❌ 直接问大模型推理计算“123…100等于多少”❌ 直接问大模型RAG 在整个架构中的位置从分层架构角度看RAG 其实是大模型的一个上下文增强插件用户问题 → RAG 负责找知识从你的私有知识库中召回和问题相关的片段RAG 找到的知识 用户问题 → 一起喂给大模型大模型负责懂语言、组织回答大模型基于检索到的知识生成答案 → 返回用户[!info] 核心关系 RAG 不替代大模型而是增强大模型。RAG 负责解决知识陈旧、知识私有、来源可追溯这几个问题大模型仍然负责自然语言理解和生成。两种常见的调用模式**先检索再生成最常用用户问退货时运费谁承担 ↓ 去RAG知识库检索 → 找到七天无理由退货买家承担运费质量问题商家承担 ↓ 把问题 检索结果拼起来 已知信息 {{检索结果}} 请根据上面的信息回答用户问题{{用户问题}} ↓ 调用大模型生成回答**渐进式检索进阶如果问题复杂大模型先分析问题分解成几个子问题然后多次调用 RAG逐步检索最后综合答案。适合回答那种需要多文档交叉验证的复杂问题。一句话记住通用知识大模型直接搞定需要你的私有数据先走 RAG 检索一把。工程实现上怎么判断要不要触发 RAG刚才说的是逻辑判断在代码开发层面业界有几种成熟的判断方法方法一分类器判断最常用用一个小模型直接做二分类问题分类成「需要知识库」还是「不需要知识库」。模型怎么知道判断标准就是你靠 Prompt 教给它的# Prompt 模板让大模型自己判断 → 你把判断规则写在prompt里模型自然会按规则输出 classification_prompt f 用户问题: {user_question} 请判断这个问题是否需要查询企业内部知识库才能回答 - 如果需要私有知识、内部文档、产品信息、公司政策才能回答 → 输出 NEED_RAG - 如果是通用知识、创意生成、推理计算大模型本身训练数据里已经有了 → 输出 NO_RAG 只输出 NEED_RAG 或 NO_RAG不要输出其他内容。 # 调用小模型比如 GPT-3.5-turbo 就够了判断 → 模型会按照你给的规则输出 result call_llm(classification_prompt) # 模型输出就是 NEED_RAG 或者 NO_RAG你的代码根据这个字符串判断 if result NEED_RAG: trigger_rag_retrieval(user_question) # 模型说需要触发 RAG else: directly_answer(user_question) # 模型说不需要直接回答举个例子用户问我们公司年假有几天→ 模型一看这是公司内部政策大模型不可能知道 → 输出NEED_RAG用户问Python怎么写循环→ 模型一看这是通用编程知识 → 输出NO_RAG优点实现简单准确率不错缺点1) 多调用一次大模型增加延迟2) 分类提示词冗余每轮重复传输50-100 tokens3) 多轮对话时上下文爆炸10轮对话就浪费500 tokens加速达到窗口限制。方法二向量相似度匹配把用户问题向量化去知识库比对比对如果能找到相似度超过阈值的 chunk就触发 RAG找不到就直接回答。# 1. 用户问题向量化 question_embedding embed_model.embed(user_question) # 2. 去向量库找最相似的 top1 top_result vector_db.search(question_embedding, top_k1) max_similarity top_result[0].similarity # 3. 阈值判断 if max_similarity threshold: # 比如阈值设 0.7 trigger_rag_retrieval(user_question) # 找到相关知识触发 RAG else: directly_answer(user_question) # 找不到说明不需要优点不需要多调用一次大模型速度快。⚠️ 这个方法真正的陷阱它用「检索环节的副产品」来决定是否触发RAGRAG检索本身有召回率和排序质量问题比如应该召回top10但实际只召回top3而这个方法只看top1相似度就做二元决策 → 双重放大了检索问题例用户问退货运费规则本该召回10条相关条款但因检索不准只召回3条且top1相似度0.65低于0.7阈值你的系统会误判为不需要RAG → 直接让大模型瞎猜 → 回答错误 本质区别网上说的向量检索召回率低是RAG系统内部问题而这里的问题是前端判断逻辑放大了内部问题解决方案✅ 阈值调低比如0.5但会误判更多✅ 用top5平均分替代top1✅ 加一层元数据过滤比如如果问题含’退货’关键词强制触发) ✅ 采用混合搜索先用关键词如BM25或元数据过滤进行粗筛再在筛选出的小范围内做向量搜索能显著提升相关性。方法三关键词/规则匹配最简单粗暴预设一批关键词如果问题命中就触发 RAG。# 比如知识库是关于公司人事政策的 trigger_keywords [年假, 社保, 公积金, 加班, 请假, 工资, 合同] if any(keyword in user_question for keyword in trigger_keywords): trigger_rag() # 命中关键词触发 else: directly_answer()优点成本为0速度极快缺点灵活性差覆盖不全。适合场景非常固定的系统。方法四不管什么问题都触发 RAG懒人大法很多生产系统直接选择不管用户问什么都先检索一遍知识库然后把检索结果拼进去。如果没找到相关内容大模型发现检索结果没用自然会用自己的知识回答。# 所有请求都走一遍 RAG retrieved_chunks rag_retrieval(user_question) prompt build_prompt(user_question, retrieved_chunks) answer call_llm(prompt)优点代码最简单不会漏缺点不管要不要都检索浪费一点 token 和时间但现在向量检索都很快其实也花不了几个钱。这是目前很多产品的实际做法。[!tip] 我的推荐场景固定 → 方法三规则足够用追求性能 → 方法二向量相似度追求准确 → 方法一大模型分类不想瞎折腾 → 方法四全都检索最简单可靠RAG为啥是企业AI的“必选项”它能解决大模型的四大痛点不用重新训练更新知识库就能同步新内容答案基于检索到的文档能追溯来源减少“胡编”知识库可本地部署数据不出企业隐私有保障不用微调大模型成本比训练低太多。对企业来说这简直是“用得起、靠得住”的AI解决方案。RAG构建的“关键四步”文档治理你想让AI会回答什么得先给它“喂对”内容。很多企业的文档格式乱成一锅粥Word、PDF、网页、数据库混在一起还有大段装饰性文字、重复的FAQ。这里的窍门是“结构化优先”比如数据库里的商品SPU、知识表字段清晰上下文明确优先喂给AI弱结构化的文档比如用户手册得先清洗——用正则工具去掉没用的装饰统一格式把“七天无理由退货”和“7日退货”这类近义句归一化。别嫌麻烦这步做不好后面再努力也白搭。[备注] 到底什么是“结构化优先”这个原则的核心是优先处理那些格式清晰、自带“说明书”的数据。可以对比一下结构化数据可以想象成一张规整的Excel表格或JSON文件。数据有明确的“字段”Key和“内容”Value比如{问题: 退货运费谁承担, 答案: 质量问题商家承担...}。AI能100%理解每个部分的含义处理起来没有歧义质量非常高。非结构化数据指大段的Word/PDF/纯文本文档。信息都混在自然语言里比如文章中提到“它的价格是99元”程序需要复杂处理才能推断出价格和产品的对应关系更容易出错。“结构化优先”并非要求把所有东西都转成JSON而是建议在构建知识库时先从你手头最规整、最干净的数据如数据库、API、规整的CSV/JSON文件开始。这些是能最快提升问答准确率的“低垂的果实”。处理完这些后再投入精力去清洗和导入格式混乱的文档。切块策略把文档切成“语义完整的小块”是门技术活。块太大信息冗余检索慢块太小语义缺失AI理解不了。比如电商的FAQ文档“Q发票什么时候能开A发货后3个工作日内发电子发票”必须把QA合并成一个chunk要是分开AI准答不上。长文档超过512token的话就用“滑动窗口重叠”——比如从第100字切到612字下一块从512字开始保证语义连贯。值得注意的是对于包含表格、代码或图文混排的复杂文档简单的文本切块效果有限。这时可以考虑更高级的策略如基于版面分析的切块例如使用unstructured.io这类库能解析PDF/HTML的结构或语义切块Semantic Chunking即利用语言模型来识别文本中的语义断点确保切分的每个块都是一个完整的语义单元。嵌入与向量库这是RAG的“知识翻译机”和“ storage”。嵌入模型负责把文本变成“能被模型理解的向量”中文场景优先选bge-large-zh或bge-m3效果稳要服务海外就用OpenAI的多语言模型。别贪高维度维度越高向量库越占空间查询越慢。向量库选对了能省大心千条以下用FAISS够用要上生产环境Milvus或Qdrant更稳想做混合检索比如向量关键词用OpenSearch加Dense Retrieval插件AWS都在用这一套。检索策略这是RAG效果的“分水岭”。你用的不是大模型是“召回的上下文”所以得把对的chunk召回来还得排对序。比如电商用户问“退货运费怎么算”向量召回了3条内容商品页描述、客服话术、退货规则。这时候要给客服话术加更高的权重metadata标记因为客服话术更贴近用户问题要是相似度都高就用重排模型Reranker进行二次精排。重排Re-ranking 是提升检索质量的关键一步。它通常使用 Cross-encoder 模型该模型会同时处理用户问题和被召回的文档块输出一个更精确的相关性分数。这比向量检索使用Bi-encoder更慢但准确得多非常适合在向量检索召回比如top 20之后送入大模型之前做一次高质量的筛选排序。[备注] 模型类型辨析双塔模型 (Bi-encoder) vs 交叉编码器 (Cross-encoder)没错重排Re-ranking确实是需要再调用一次模型。这里需要区分两种模型双塔模型 (Bi-encoder)如bge-large-zh。它有两个独立的“塔”分别将问题和文档独立编码成向量然后计算向量间的相似度。这种方式速度快适合从海量数据中快速“海选”召回出可能相关的文档。但因为问题和文档没有直接交互对语义的理解不够精细。交叉编码器 (Cross-encoder)这是用于重排的模型。它会将问题和文档“拼接”起来一同输入模型进行计算。这使得模型能同时看到两者的完整上下文进行更深层次的交互和判断从而给出更精准的相关性排序。它准确率高但速度慢因此适合对“海选”出的一小批结果进行“精选”重排。简单说两者是互补关系双塔模型负责召回效率交叉编码器负责重排效果。真实场景里我们试过给Dify调检索策略——把“官方文档第三方内容”“最新内容旧内容”设为权重回答准确率直接提了30%。[备注] 如何理解“给Dify调检索策略”这句话这句话是“检索策略”部分一个非常画龙点睛的例子。它指的是在像Dify这样的LLM应用开发平台中通过设定权重让检索系统变得更“智能”。规则一“官方文档 第三方内容”含义告诉系统“官方发布的内容比第三方博客更可信”。实现为文档添加来源元数据如source: official并在检索时为来自官方来源的文档增加权重加分使其排名更靠前。规则二“最新内容 旧内容”含义告诉系统“时间越近的信息越有价值”。实现为文档添加发布日期元数据并让系统优先考虑日期更新的文档。总结 通过这种方式系统不再是简单地看“文字像不像”而是综合考虑了信息的“来源权威性”和“时效性”。这确保了提供给大模型的“原材料”质量更高从而大幅提升了最终答案的准确率。[备注] 金牌助理的比喻如果感觉上面的概念有点抽象我们可以用一个比喻来理解。想象一下大模型LLM是一位非常聪明但“健忘”的老板他懂天下事但完全不记得自己公司的内部资料。你就是老板的得力助手。当客户提问时老板会让你去资料库找相关规定。你的“检索策略”好坏决定了你是普通助手还是金牌助手。普通助手的做法没有策略在资料库里搜索关键词然后把找到的10份文件包括法务条款、网页说明、陈旧邮件等一股脑全抱给老板。老板看完会头大给出的答案不一定准。这就像最基础的向量检索只负责“找相关的”但不管哪个“最好”。金牌助手的做法有策略分清主次文档加权你早就知道客服内部的《FAQ》是回答客户问题的“标准答案”并提前给它贴了“高优先级”标签。找文件时你看到这个标签就直接把这份FAQ放在了最上面。优中选优重排 Re-ranking对于剩下几份看起来也相关的文件你会拿着客户的具体问题自己先快速、仔细地对比一遍看看哪个文件能最完美地回答问题。最后你只把最匹配的那一两份核心材料递给老板。总结 好的检索策略就是让你从一个只会“搜索”的普通助手升级成一个懂得“筛选”和“排序”的金牌助手。这样大模型拿到的永远简介文章中提到的实例一个上手简单、功能强大的LLM应用开发平台内置了完整的RAG引擎包括数据处理、检索、重排和评估等功能。GitHub:https://github.com/langgenius/dify2. 向量数据库 (Vector Database)用于存储文档向量化后的Embedding并提供高效的相似度检索。FAISS (Facebook AI Similarity Search)简介文章中推荐用于千条数据量以下的场景。它是一个高性能的向量相似度搜索库而不是一个完整的数据库服务。GitHub:https://github.com/facebookresearch/faissMilvus简介文章推荐的生产级向量数据库功能全面专为大规模向量检索设计。GitHub:https://github.com/milvus-io/milvusQdrant简介与Milvus类似是另一款流行的生产级向量数据库以其性能和易用性著称。GitHub:https://github.com/qdrant/qdrantOpenSearch简介一个开源的分布式搜索和分析引擎源自Elasticsearch。通过安装Dense Retrieval等插件可以实现关键词向量的混合检索。GitHub:https://github.com/opensearch-project/OpenSearch3. 嵌入与重排模型 (Embedding Reranker Models)这些模型负责将文本“翻译”成向量或对召回结果进行精排。它们通常托管在Hugging Face上。BGE (BAAI General Embedding) Models简介文章首推的中文场景嵌入模型如bge-large-zh-v1.5。由北京智源人工智能研究院BAAI开发效果稳健。Hugging Face:https://huggingface.co/BAAI/bge-large-zh-v1.5BGE Reranker Models简介与BGE嵌入模型配套的重排模型Cross-encoder。在你需要对召回结果进行二次精排时使用。Hugging Face:https://huggingface.co/BAAI/bge-reranker-large4. 文档处理与切块 (Document Processing Chunking)Unstructured.io简介文章中提到的用于“基于版面分析切块”的库。它能智能解析PDF、HTML、Word等复杂文档提取文本和表格等结构化内容。GitHub:https://github.com/Unstructured-IO/unstructured5. RAG 评估框架 (Evaluation Frameworks)用于科学地衡量RAG系统的性能实现数据驱动的优化。Ragas简介文章中提到的评估框架之一提供了一套完整的指标如忠实度、答案相关性等来评估RAG流水线的各个环节。GitHub:https://github.com/explodinggradients/ragasARES简介文章提到的另一个评估框架由斯坦福大学开发旨在通过模拟人工评估来自动化地评测RAG系统的准确性。GitHub:https://github.com/stanford-futuredata/ARES其实RAG没那么复杂关键是”贴着业务需求搭”——别追求”高大上”的技术能解决问题的才是好方案。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取 
长河君 · 2026/8/9 11:12:18 · 阅读 1.2k 收藏 | RAG知识库构建实用指南：小白也能轻松掌握大模型核心技术
本文详细介绍了RAG知识库构建的实用指南从调用链路、触发条件到架构位置帮助读者理解RAG与大模型的关系。文章还探讨了两种常见的调用模式并提供了四种判断是否触发RAG的方法。此外本文还深入分析了RAG构建的关键四步文档治理、切块策略、嵌入与向量库、检索策略以及RAG效果的评估与迭代。最后文章总结了RAG系统相关开源框架与技术栈为读者提供了实用的参考资料。RAG知识库构建的实用指南不算啥指南只是一些自己认为不熟练的内容做一个新的整理。RAG 与大模型的调用关系完整请求流程很多同学会困惑一个用户请求进来什么时候调用 RAG什么时候直接问大模型 这其实是个流程设计问题我梳理一下标准的调用链路典型的请求处理流程什么时候会触发 RAG[!tip]一句话总结当问题答案需要「你的私有知识库信息」时才需要调用 RAG。如果问题能用大模型的通用知识回答就不用调用。具体来说以下场景一定会触发 RAG场景例子是否触发RAG企业内部政策合规问题“我们公司年假规定是几天”✅ 必须触发产品文档/手册查询“这款手机的保修政策是什么”✅ 必须触发合同条款查询“这份合同里关于违约金怎么规定的”✅ 必须触发基于私有数据的分析“帮我分析下上个月销售数据中top3商品有什么特点”✅ 必须触发通用知识问题“Python怎么定义一个类”❌ 直接问大模型创意生成“帮我写一封节日祝福邮件”❌ 直接问大模型推理计算“123…100等于多少”❌ 直接问大模型RAG 在整个架构中的位置从分层架构角度看RAG 其实是大模型的一个上下文增强插件用户问题 → RAG 负责找知识从你的私有知识库中召回和问题相关的片段RAG 找到的知识 用户问题 → 一起喂给大模型大模型负责懂语言、组织回答大模型基于检索到的知识生成答案 → 返回用户[!info] 核心关系 RAG 不替代大模型而是增强大模型。RAG 负责解决知识陈旧、知识私有、来源可追溯这几个问题大模型仍然负责自然语言理解和生成。两种常见的调用模式**先检索再生成最常用用户问退货时运费谁承担 ↓ 去RAG知识库检索 → 找到七天无理由退货买家承担运费质量问题商家承担 ↓ 把问题 检索结果拼起来 已知信息 {{检索结果}} 请根据上面的信息回答用户问题{{用户问题}} ↓ 调用大模型生成回答**渐进式检索进阶如果问题复杂大模型先分析问题分解成几个子问题然后多次调用 RAG逐步检索最后综合答案。适合回答那种需要多文档交叉验证的复杂问题。一句话记住通用知识大模型直接搞定需要你的私有数据先走 RAG 检索一把。工程实现上怎么判断要不要触发 RAG刚才说的是逻辑判断在代码开发层面业界有几种成熟的判断方法方法一分类器判断最常用用一个小模型直接做二分类问题分类成「需要知识库」还是「不需要知识库」。模型怎么知道判断标准就是你靠 Prompt 教给它的# Prompt 模板让大模型自己判断 → 你把判断规则写在prompt里模型自然会按规则输出 classification_prompt f 用户问题: {user_question} 请判断这个问题是否需要查询企业内部知识库才能回答 - 如果需要私有知识、内部文档、产品信息、公司政策才能回答 → 输出 NEED_RAG - 如果是通用知识、创意生成、推理计算大模型本身训练数据里已经有了 → 输出 NO_RAG 只输出 NEED_RAG 或 NO_RAG不要输出其他内容。 # 调用小模型比如 GPT-3.5-turbo 就够了判断 → 模型会按照你给的规则输出 result call_llm(classification_prompt) # 模型输出就是 NEED_RAG 或者 NO_RAG你的代码根据这个字符串判断 if result NEED_RAG: trigger_rag_retrieval(user_question) # 模型说需要触发 RAG else: directly_answer(user_question) # 模型说不需要直接回答举个例子用户问我们公司年假有几天→ 模型一看这是公司内部政策大模型不可能知道 → 输出NEED_RAG用户问Python怎么写循环→ 模型一看这是通用编程知识 → 输出NO_RAG优点实现简单准确率不错缺点1) 多调用一次大模型增加延迟2) 分类提示词冗余每轮重复传输50-100 tokens3) 多轮对话时上下文爆炸10轮对话就浪费500 tokens加速达到窗口限制。方法二向量相似度匹配把用户问题向量化去知识库比对比对如果能找到相似度超过阈值的 chunk就触发 RAG找不到就直接回答。# 1. 用户问题向量化 question_embedding embed_model.embed(user_question) # 2. 去向量库找最相似的 top1 top_result vector_db.search(question_embedding, top_k1) max_similarity top_result[0].similarity # 3. 阈值判断 if max_similarity threshold: # 比如阈值设 0.7 trigger_rag_retrieval(user_question) # 找到相关知识触发 RAG else: directly_answer(user_question) # 找不到说明不需要优点不需要多调用一次大模型速度快。⚠️ 这个方法真正的陷阱它用「检索环节的副产品」来决定是否触发RAGRAG检索本身有召回率和排序质量问题比如应该召回top10但实际只召回top3而这个方法只看top1相似度就做二元决策 → 双重放大了检索问题例用户问退货运费规则本该召回10条相关条款但因检索不准只召回3条且top1相似度0.65低于0.7阈值你的系统会误判为不需要RAG → 直接让大模型瞎猜 → 回答错误 本质区别网上说的向量检索召回率低是RAG系统内部问题而这里的问题是前端判断逻辑放大了内部问题解决方案✅ 阈值调低比如0.5但会误判更多✅ 用top5平均分替代top1✅ 加一层元数据过滤比如如果问题含’退货’关键词强制触发) ✅ 采用混合搜索先用关键词如BM25或元数据过滤进行粗筛再在筛选出的小范围内做向量搜索能显著提升相关性。方法三关键词/规则匹配最简单粗暴预设一批关键词如果问题命中就触发 RAG。# 比如知识库是关于公司人事政策的 trigger_keywords [年假, 社保, 公积金, 加班, 请假, 工资, 合同] if any(keyword in user_question for keyword in trigger_keywords): trigger_rag() # 命中关键词触发 else: directly_answer()优点成本为0速度极快缺点灵活性差覆盖不全。适合场景非常固定的系统。方法四不管什么问题都触发 RAG懒人大法很多生产系统直接选择不管用户问什么都先检索一遍知识库然后把检索结果拼进去。如果没找到相关内容大模型发现检索结果没用自然会用自己的知识回答。# 所有请求都走一遍 RAG retrieved_chunks rag_retrieval(user_question) prompt build_prompt(user_question, retrieved_chunks) answer call_llm(prompt)优点代码最简单不会漏缺点不管要不要都检索浪费一点 token 和时间但现在向量检索都很快其实也花不了几个钱。这是目前很多产品的实际做法。[!tip] 我的推荐场景固定 → 方法三规则足够用追求性能 → 方法二向量相似度追求准确 → 方法一大模型分类不想瞎折腾 → 方法四全都检索最简单可靠RAG为啥是企业AI的“必选项”它能解决大模型的四大痛点不用重新训练更新知识库就能同步新内容答案基于检索到的文档能追溯来源减少“胡编”知识库可本地部署数据不出企业隐私有保障不用微调大模型成本比训练低太多。对企业来说这简直是“用得起、靠得住”的AI解决方案。RAG构建的“关键四步”文档治理你想让AI会回答什么得先给它“喂对”内容。很多企业的文档格式乱成一锅粥Word、PDF、网页、数据库混在一起还有大段装饰性文字、重复的FAQ。这里的窍门是“结构化优先”比如数据库里的商品SPU、知识表字段清晰上下文明确优先喂给AI弱结构化的文档比如用户手册得先清洗——用正则工具去掉没用的装饰统一格式把“七天无理由退货”和“7日退货”这类近义句归一化。别嫌麻烦这步做不好后面再努力也白搭。[备注] 到底什么是“结构化优先”这个原则的核心是优先处理那些格式清晰、自带“说明书”的数据。可以对比一下结构化数据可以想象成一张规整的Excel表格或JSON文件。数据有明确的“字段”Key和“内容”Value比如{问题: 退货运费谁承担, 答案: 质量问题商家承担...}。AI能100%理解每个部分的含义处理起来没有歧义质量非常高。非结构化数据指大段的Word/PDF/纯文本文档。信息都混在自然语言里比如文章中提到“它的价格是99元”程序需要复杂处理才能推断出价格和产品的对应关系更容易出错。“结构化优先”并非要求把所有东西都转成JSON而是建议在构建知识库时先从你手头最规整、最干净的数据如数据库、API、规整的CSV/JSON文件开始。这些是能最快提升问答准确率的“低垂的果实”。处理完这些后再投入精力去清洗和导入格式混乱的文档。切块策略把文档切成“语义完整的小块”是门技术活。块太大信息冗余检索慢块太小语义缺失AI理解不了。比如电商的FAQ文档“Q发票什么时候能开A发货后3个工作日内发电子发票”必须把QA合并成一个chunk要是分开AI准答不上。长文档超过512token的话就用“滑动窗口重叠”——比如从第100字切到612字下一块从512字开始保证语义连贯。值得注意的是对于包含表格、代码或图文混排的复杂文档简单的文本切块效果有限。这时可以考虑更高级的策略如基于版面分析的切块例如使用unstructured.io这类库能解析PDF/HTML的结构或语义切块Semantic Chunking即利用语言模型来识别文本中的语义断点确保切分的每个块都是一个完整的语义单元。嵌入与向量库这是RAG的“知识翻译机”和“ storage”。嵌入模型负责把文本变成“能被模型理解的向量”中文场景优先选bge-large-zh或bge-m3效果稳要服务海外就用OpenAI的多语言模型。别贪高维度维度越高向量库越占空间查询越慢。向量库选对了能省大心千条以下用FAISS够用要上生产环境Milvus或Qdrant更稳想做混合检索比如向量关键词用OpenSearch加Dense Retrieval插件AWS都在用这一套。检索策略这是RAG效果的“分水岭”。你用的不是大模型是“召回的上下文”所以得把对的chunk召回来还得排对序。比如电商用户问“退货运费怎么算”向量召回了3条内容商品页描述、客服话术、退货规则。这时候要给客服话术加更高的权重metadata标记因为客服话术更贴近用户问题要是相似度都高就用重排模型Reranker进行二次精排。重排Re-ranking 是提升检索质量的关键一步。它通常使用 Cross-encoder 模型该模型会同时处理用户问题和被召回的文档块输出一个更精确的相关性分数。这比向量检索使用Bi-encoder更慢但准确得多非常适合在向量检索召回比如top 20之后送入大模型之前做一次高质量的筛选排序。[备注] 模型类型辨析双塔模型 (Bi-encoder) vs 交叉编码器 (Cross-encoder)没错重排Re-ranking确实是需要再调用一次模型。这里需要区分两种模型双塔模型 (Bi-encoder)如bge-large-zh。它有两个独立的“塔”分别将问题和文档独立编码成向量然后计算向量间的相似度。这种方式速度快适合从海量数据中快速“海选”召回出可能相关的文档。但因为问题和文档没有直接交互对语义的理解不够精细。交叉编码器 (Cross-encoder)这是用于重排的模型。它会将问题和文档“拼接”起来一同输入模型进行计算。这使得模型能同时看到两者的完整上下文进行更深层次的交互和判断从而给出更精准的相关性排序。它准确率高但速度慢因此适合对“海选”出的一小批结果进行“精选”重排。简单说两者是互补关系双塔模型负责召回效率交叉编码器负责重排效果。真实场景里我们试过给Dify调检索策略——把“官方文档第三方内容”“最新内容旧内容”设为权重回答准确率直接提了30%。[备注] 如何理解“给Dify调检索策略”这句话这句话是“检索策略”部分一个非常画龙点睛的例子。它指的是在像Dify这样的LLM应用开发平台中通过设定权重让检索系统变得更“智能”。规则一“官方文档 第三方内容”含义告诉系统“官方发布的内容比第三方博客更可信”。实现为文档添加来源元数据如source: official并在检索时为来自官方来源的文档增加权重加分使其排名更靠前。规则二“最新内容 旧内容”含义告诉系统“时间越近的信息越有价值”。实现为文档添加发布日期元数据并让系统优先考虑日期更新的文档。总结 通过这种方式系统不再是简单地看“文字像不像”而是综合考虑了信息的“来源权威性”和“时效性”。这确保了提供给大模型的“原材料”质量更高从而大幅提升了最终答案的准确率。[备注] 金牌助理的比喻如果感觉上面的概念有点抽象我们可以用一个比喻来理解。想象一下大模型LLM是一位非常聪明但“健忘”的老板他懂天下事但完全不记得自己公司的内部资料。你就是老板的得力助手。当客户提问时老板会让你去资料库找相关规定。你的“检索策略”好坏决定了你是普通助手还是金牌助手。普通助手的做法没有策略在资料库里搜索关键词然后把找到的10份文件包括法务条款、网页说明、陈旧邮件等一股脑全抱给老板。老板看完会头大给出的答案不一定准。这就像最基础的向量检索只负责“找相关的”但不管哪个“最好”。金牌助手的做法有策略分清主次文档加权你早就知道客服内部的《FAQ》是回答客户问题的“标准答案”并提前给它贴了“高优先级”标签。找文件时你看到这个标签就直接把这份FAQ放在了最上面。优中选优重排 Re-ranking对于剩下几份看起来也相关的文件你会拿着客户的具体问题自己先快速、仔细地对比一遍看看哪个文件能最完美地回答问题。最后你只把最匹配的那一两份核心材料递给老板。总结 好的检索策略就是让你从一个只会“搜索”的普通助手升级成一个懂得“筛选”和“排序”的金牌助手。这样大模型拿到的永远简介文章中提到的实例一个上手简单、功能强大的LLM应用开发平台内置了完整的RAG引擎包括数据处理、检索、重排和评估等功能。GitHub:https://github.com/langgenius/dify2. 向量数据库 (Vector Database)用于存储文档向量化后的Embedding并提供高效的相似度检索。FAISS (Facebook AI Similarity Search)简介文章中推荐用于千条数据量以下的场景。它是一个高性能的向量相似度搜索库而不是一个完整的数据库服务。GitHub:https://github.com/facebookresearch/faissMilvus简介文章推荐的生产级向量数据库功能全面专为大规模向量检索设计。GitHub:https://github.com/milvus-io/milvusQdrant简介与Milvus类似是另一款流行的生产级向量数据库以其性能和易用性著称。GitHub:https://github.com/qdrant/qdrantOpenSearch简介一个开源的分布式搜索和分析引擎源自Elasticsearch。通过安装Dense Retrieval等插件可以实现关键词向量的混合检索。GitHub:https://github.com/opensearch-project/OpenSearch3. 嵌入与重排模型 (Embedding Reranker Models)这些模型负责将文本“翻译”成向量或对召回结果进行精排。它们通常托管在Hugging Face上。BGE (BAAI General Embedding) Models简介文章首推的中文场景嵌入模型如bge-large-zh-v1.5。由北京智源人工智能研究院BAAI开发效果稳健。Hugging Face:https://huggingface.co/BAAI/bge-large-zh-v1.5BGE Reranker Models简介与BGE嵌入模型配套的重排模型Cross-encoder。在你需要对召回结果进行二次精排时使用。Hugging Face:https://huggingface.co/BAAI/bge-reranker-large4. 文档处理与切块 (Document Processing Chunking)Unstructured.io简介文章中提到的用于“基于版面分析切块”的库。它能智能解析PDF、HTML、Word等复杂文档提取文本和表格等结构化内容。GitHub:https://github.com/Unstructured-IO/unstructured5. RAG 评估框架 (Evaluation Frameworks)用于科学地衡量RAG系统的性能实现数据驱动的优化。Ragas简介文章中提到的评估框架之一提供了一套完整的指标如忠实度、答案相关性等来评估RAG流水线的各个环节。GitHub:https://github.com/explodinggradients/ragasARES简介文章提到的另一个评估框架由斯坦福大学开发旨在通过模拟人工评估来自动化地评测RAG系统的准确性。GitHub:https://github.com/stanford-futuredata/ARES其实RAG没那么复杂关键是”贴着业务需求搭”——别追求”高大上”的技术能解决问题的才是好方案。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取