收藏！小白程序员轻松入门RAG知识库构建，让大模型更懂你的私有数据

ai绘画-安安妮

711人浏览 · 2026-04-03 10:55:37

ai绘画-安安妮 · 2026-04-03 10:55:37 发布

不算啥指南，只是一些自己认为不熟练的内容做一个新的整理。

RAG 与大模型的调用关系：完整请求流程

很多同学会困惑：一个用户请求进来，什么时候调用 RAG，什么时候直接问大模型？ 这其实是个流程设计问题，我梳理一下标准的调用链路：

典型的请求处理流程

什么时候会触发 RAG？

[!tip]一句话总结：当问题答案需要「你的私有知识库信息」时，才需要调用 RAG。如果问题能用大模型的通用知识回答，就不用调用。

具体来说，以下场景一定会触发 RAG：

场景	例子	是否触发RAG
企业内部政策合规问题	“我们公司年假规定是几天？”	✅ 必须触发
产品文档/手册查询	“这款手机的保修政策是什么？”	✅ 必须触发
合同条款查询	“这份合同里关于违约金怎么规定的？”	✅ 必须触发
基于私有数据的分析	“帮我分析下上个月销售数据中top3商品有什么特点？”	✅ 必须触发
通用知识问题	“Python怎么定义一个类？”	❌ 直接问大模型
创意生成	“帮我写一封节日祝福邮件”	❌ 直接问大模型
推理计算	“1+2+3…+100等于多少？”	❌ 直接问大模型

RAG 在整个架构中的位置

从分层架构角度看，RAG 其实是大模型的一个"上下文增强插件"：

用户问题 → RAG 负责"找知识"：从你的私有知识库中召回和问题相关的片段
RAG 找到的知识 + 用户问题 → 一起喂给大模型：大模型负责"懂语言、组织回答"
大模型基于检索到的知识生成答案 → 返回用户

[!info] 核心关系 RAG 不替代大模型，而是增强大模型。RAG 负责解决"知识陈旧、知识私有、来源可追溯"这几个问题，大模型仍然负责自然语言理解和生成。

两种常见的调用模式

1. 先检索再生成（最常用）

用户问：退货时运费谁承担？↓去RAG知识库检索 → 找到"七天无理由退货，买家承担运费；质量问题商家承担"↓把问题 + 检索结果拼起来："""已知信息：{{检索结果}}请根据上面的信息回答用户问题：{{用户问题}}"""↓调用大模型生成回答

2. 渐进式检索（进阶）如果问题复杂，大模型先分析问题，分解成几个子问题，然后多次调用 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)  # 模型说需要，触发 RAGelse:    directly_answer(user_question)        # 模型说不需要，直接回答

在这里插入图片描述

举个例子：

用户问 "我们公司年假有几天？" → 模型一看这是公司内部政策，大模型不可能知道 → 输出 NEED_RAG
用户问 "Python怎么写循环？" → 模型一看这是通用编程知识 → 输出 NO_RAG

优点：实现简单，准确率不错；缺点：1) 多调用一次大模型增加延迟；2) 分类提示词冗余（每轮重复传输50-100 tokens）；3) 多轮对话时上下文爆炸，10轮对话就浪费500+ tokens，加速达到窗口限制。

方法二：向量相似度匹配

把用户问题向量化，去知识库比对比对：如果能找到相似度超过阈值的 chunk，就触发 RAG；找不到就直接回答。

# 1. 用户问题向量化question_embedding = embed_model.embed(user_question)# 2. 去向量库找最相似的 top1top_result = vector_db.search(question_embedding, top_k=1)max_similarity = top_result[0].similarity# 3. 阈值判断if max_similarity > threshold:  # 比如阈值设 0.7    trigger_rag_retrieval(user_question)  # 找到相关知识，触发 RAGelse:    directly_answer(user_question)        # 找不到，说明不需要

优点：不需要多调用一次大模型，速度快。

⚠️ 这个方法真正的陷阱：它用「检索环节的副产品」来决定是否触发RAG

RAG检索本身有召回率和排序质量问题（比如应该召回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（懒人大法）

很多生产系统直接选择：不管用户问什么，都先检索一遍知识库，然后把检索结果拼进去。

如果没找到相关内容，大模型发现检索结果没用，自然会用自己的知识回答。

# 所有请求都走一遍 RAGretrieved_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个工作日内发电子发票”，必须把Q+A合并成一个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）：对于剩下几份看起来也相关的文件，你会拿着客户的具体问题，自己先快速、仔细地对比一遍，看看哪个文件能最完美地回答问题。最后，你只把最匹配的那一两份核心材料递给老板。

总结： 好的检索策略，就是让你从一个只会“搜索”的普通助手，升级成一个懂得“筛选”和“排序”的金牌助手。这样，大模型拿到的永远是“含金量”最高的材料，最终生成的答案自然就更准确、更可靠。

RAG 效果的评估与迭代

构建了RAG系统后，如何衡量“建得好不好”并持续优化呢？这就需要一套科学的评估体系。

一个完整的RAG评估应关注以下几个核心指标：

召回率（Context Recall）：衡量检索系统是否成功召回了所有相关信息。即“找得全不全”。
精确率（Context Precision）：衡量召回的知识中，有多少是与问题真正相关的。即“找得准不准”。
答案相关性（Answer Relevance）：衡量大模型生成的答案是否切中用户问题。
忠实度（Faithfulness）：衡量答案是否完全基于所提供的上下文知识，没有“胡编乱造”。

在实践中，通常需要构建一个评测集（黄金数据集），包含一系列标准问答对和相关的知识源。通过自动化地运行评测集，我们就能量化地追踪系统在优化（例如更换嵌入模型、调整检索策略）前后的表现变化，从而实现数据驱动的迭代优化。像Ragas、ARES这样的开源框架，都提供了实现上述评估的工具。

再说说企业的真实应用场景

智能客服可以把RAG集成到系统里，知识库放产品手册、FAQ，秒级响应还准确；知识管理系统里，把合同、政策文档喂给RAG，找条款比翻文档快10倍；数据分析助手更实用——把数据库表结构、字段说明放进知识库，用户问“上个月销量top3的商品”，AI能直接生成SQL查询，不用懂代码。

最后给大家提几个“避坑提醒”：第一，文档质量是基础——用标准格式（PDF、Markdown），结构清晰，扫描件一定要OCR处理；第二，别贪“大模型”——中文场景用bge就够，高参模型效果好但成本高，除非是专业领域；第三，安全要盯紧——知识库本地部署，加权限控制，别让敏感数据泄露；第四，定期优化——根据用户反馈调整切块策略、检索权重，比如用户总问“退货运费”，就把客服话术的权重再调高些。