企业官网建设流程全解析

做RAG项目做得越多，越容易陷入一个怪圈：明明把PDF全塞进向量库，也换了更大的模型，可一问到跨章节、需要推理的问题，结果还是答非所问。不少朋友私下问我：RAG不是检索增强生成吗，怎么越做越像“检索增加负担”？这一章《深入浅出RAG——第14章：高级 RAG 技术》就专门聊这个问题。不回避瓶颈，不讲空泛概念，重点说清从“能跑”到“好用”的那几步。无论你是在搭本地知识库，还是准备上GraphRAG、Agentic RAG，这篇都值得先花十分钟读完。

1. 从朴素RAG到高级RAG：瓶颈出在哪里

1.1 朴素RAG的四个典型症状

很多团队的第一版RAG，流程基本是一样的：文档切块 -> Embedding -> 存入向量库 -> 用户提问 -> 向量检索 -> 把Top K片段拼进Prompt -> 交给大模型生成。这个流程跑通很容易，但效果往往不稳定，常见的症状有四个。

第一个是召回率不达标，也就是Hit Rate偏低。用户问“合同里关于违约金的计算方式”，我们检索回来的Top 5片段里可能只有一段真正有用，甚至一段都没有。这种情况和分块方式、Embedding模型选择、查询词表述都有关系，不是换个更大模型就能解决的。

第二个是知识割裂。同一份材料被切成几百个碎片后，A段落讲“采购流程”，B段落讲“验收标准”，中间的逻辑关系被切断了。用户问“采购后多久必须验收”，要求模型同时看到这两块内容，可向量检索通常只会召回其中一块，答案自然不完整。“知识割裂”是我这几年听到最多的吐槽，也是高级RAG要重点解决的问题。

第三个是上下文被无关片段挤占。向量检索本质上是一种近似最近邻搜索，它只看语义相似度，不看“片段之间的逻辑关系”。结果就是用户问A问题，系统把A的周边内容也当补药塞进Prompt，把本来就不长的上下文窗口塞满，大模型的注意力被稀释，回答变得啰嗦甚至跑偏。

第四个是指标好看但体验很差。评测时只算命中率，发现分数提升了；真正用起来，答案还是长、空、答非所问。这说明一个问题：RAG的效果链路很长，检索只是前半段，组织信息和生成表达同样关键。

1.2 检索质量决定了RAG的上限

朴素RAG最大的误区是把大模型当成主角，把检索当成背景板。实际恰恰相反：对RAG系统来说，检索质量决定了效果上限，生成质量只是在下限附近做修补。用大白话说，你给了模型一堆不相关的材料，它再聪明也只能“戴着镣铐跳舞”。

Token级别上，如果检索回来的信息本身就是错的，那模型之后生成的所有推理都是基于错误前提。我在调RAG时有一条经验：先单独调检索，再让大模型决定怎么组织语言。把检索部分的Hit Rate和重排序后的精确度提上去，再回头看最终答案，往往会有“什么都没改，但效果突然好了”的错觉。这不是错觉，是之前的检索环节在拖后腿。

高级RAG的本质，就是在检索之前、检索之中、检索之后做更精细的编排。不是某一个花哨组件，而是整条链路的工程化。

2. 模块化RAG：把检索链路拆成可调优的积木

2.1 索引、检索、重排序、生成的模块化思路

朴素RAG把“检索 + 生成”当成一个黑盒，高级RAG的第一步是拆开它。模块化RAG的概念就是从工程实践里来的——你可以像搭积木一样，分别替换Embedding模型、分块策略、检索方式、重排序器和生成策略，每块都能单独调优。这样做的好处是出问题时能快速定位：是召回不好，还是排序不好，还是生成不好。

具体拆下来，一条典型的模块化RAG链路至少分四段：

• 索引（Indexing）：文本清洗、解析、结构识别、分块、向量化。这里的决策直接决定后面能召回什么。
• 检索（Retrieval）：包括向量检索、关键词检索、混合检索，以及可选的查询改写、查询路由。
• 重排序（Reranking）：对检索回来的候选片段做二次排序，把最相关的排到前面。
• 生成（Generation）：把筛选后的片段组织成上下文，配合提示词生成答案。

这四段之间不是简单的线性流水线，而是可以相互反馈的。比如我发现在某个业务里，改了分块策略后重排序的效果大幅提升，这其实是在索引阶段解决了“片段信息密度”问题。

很多团队做高级RAG时，容易一上来就上最复杂的组件。我的建议是反过来的：先把四段各自量化，每个模块定一个指标。检索看召回和命中，重排序看排序质量，生成看答案忠实度。哪个指标不达标就去动哪个模块，而不是盲目加东西。模块化最大的价值不是炫技，而是让调优有方向。

2.2 混合检索和重排序的落地配方

我在实际项目里最常用也最稳的配方，是“BM25 + 向量检索 + RRF + Reranker”。先分别用关键词和向量各自召回Top 50，然后用RRF（Reciprocal Rank Fusion）把两个结果融合到Top 20，最后送进一个重排序模型取Top 5。

为什么要这么做？向量检索擅长“语义相似”，但不擅长“精确词匹配”。比如用户搜“LG-2024-001号合同”，Embedding模型可能觉得它和“合同”最相似，而BM25能精确抓住这个编号。反过来，用户问“有没有那种很难做的谈判”，BM25找不全同义词，向量检索却能理解“难搞的客户”和“很难做的谈判”是同一回事。两者互补后，召回覆盖率会明显上升。

RRF的原理很简单，它不对分数做统一归一化，而是看每个文档在两个结果列表里的排名，用1/(k+rank)累计分数。这样做的好处是：不依赖两种检索分数的数值范围，鲁棒性很强。我通常在RRF之后接一个重排序模型，常见选择包括bge-reranker-base、Cohere Rerank这类。重排序模型本质上是“深度语义匹配”，它能把真正和问题相关的片段顶到前面，过滤掉向量检索带来的噪声。

这个环节有几个容易踩的坑。第一，Top K返回的候选越多，重排序阶段的成本越高，一般控制在50~100条候选比较合理。第二，混合检索不是简单“两个都跑一遍就完事”，还必须注意每种检索返回的元数据是否完整，比如章节号、页码、来源文档，否则后面做引用和溯源会非常痛苦。第三，RRF里的参数k通常设60，但如果你发现长尾查询效果差，可以试着调小，这个参数会影响长排名的权重。

3. 知识割裂的解法：GraphRAG与本体RAG

3.1 GraphRAG：从“文档碎片”到“实体关系网”

普通RAG把文档切成块，等于把一本书拆成单页放进文件夹。检索时，系统只看到单页，永远看不到“第3章的内容在第2章有铺垫”这种跨页关系。GraphRAG的思路是：不只存文本块，还要把文档里的实体和关系抽出来，构成一张知识图谱。

举个实际例子。一份企业内部制度包含“采购流程”“付款条件”“违约责任”三个章节，用户问“不按时付款会违反哪一条流程”。普通RAG可能召回“付款条件”里的某一句话，而GraphRAG会先在图谱里定位“付款”这个实体，找到“付款与违约之间的关系”，再顺着关系找到对应的流程节点和制度条款。

GraphRAG的落地通常分四步：从文档中抽取实体、关系和属性；构建图结构；对图做社区检测或聚类，生成社区摘要；检索时用图结构辅助定位，或者直接让图谱参与上下文构建。这里面实体抽取的质量几乎决定了一切，用大模型自动抽取时，需要设计好Schema（实体类型、关系类型），并做好去重和实体对齐。不然你会得到一张节点冗余、关系混乱的“脏图”。

GraphRAG的好处是可以回答“关系型问题”和“全局性问题”，比如“列举所有与项目延期相关的风险因素”。但注意，它不是银弹。图谱构建成本高、更新难，如果你的知识库只是几十篇FAQ文档，用户问题也都是单一事实型，那硬上GraphRAG就是给自己找不自在。

3.2 本体RAG：先定义领域“骨架”，再谈检索

GraphRAG强调“有关系”，本体RAG则进一步强调“有规矩”。本体（Ontology）是对某个领域的概念、类型、属性和关系做的正式、显式规范。放到RAG里，就是用一套领域Schema去约束知识图谱的构建方式，而不是让模型随机发散。

比如医疗知识库，如果你定义好“疾病、症状、药物、禁忌症”这几类实体，以及“疾病有症状、药物禁忌疾病”这些关系，那么抽取出来的是一个结构清晰、逻辑统一的知识网络。用户问“某种药过敏怎么办”，系统可以沿着“药物 -> 禁忌症 -> 替代药物”的路径给出更准确的答案。

本体RAG和GraphRAG的区别，一句话总结：GraphRAG让你看到实体之间的关系，本体RAG让你知道这些关系应该是什么样、哪些关系值得建模。对企业知识库来说，建模前置可以减少图谱里大量无效关联，提升实体抽取的一致性和后续召回准确率。但同样，构建本体需要领域专家深度参与，成本比GraphRAG更高。

3.3 我的取舍经验：别为了“高端”而上图谱

我知道现在不少工程师一看到“GraphRAG”和“本体RAG”就兴奋，觉得不上图谱就不够高级。但根据我自己的项目经验，判断该不该上图谱，看两个条件就够：第一，用户问题是否需要多跳推理；第二，知识库本身是否存在强关联结构。

什么是多跳推理？比如“A项目的负责人与B项目的负责人在哪个项目上有合作”，这种问题需要跨越至少两个关系。如果用户大部分问题是一跳就能解决的，图谱带来的边际收益很小。反过来，如果知识库里的实体和关系本来就多且密，比如企业内部流程、产品研发文档、医学指南，图谱和本体能直接解决知识割裂问题。

我见过一个做得很好的案例：一个大型设备维修知识库，文档之间大量交叉引用，普通RAG召回率只有58%，错误答案几乎都是因为“知识点被切碎”。后来他们用领域本体重新构建图谱，再配合GraphRAG的社区摘要，召回率直接拉到了82%。但整个建模和抽取过程花了大约三周。要不要上图谱，本质上是在成本和收益之间做权衡。

4. Agentic RAG：让大模型自己编排检索动作

4.1 RAG智能体和一次性检索的区别

传统RAG是“用户问一次，系统检索一次，然后生成”。Agentic RAG（也叫RAG智能体）不一样，它让大模型像员工一样自己决定“该查什么、分几步查、要不要换个关键词再查、查完结果是否可信”。这个变化看起来只是自动化，实际上彻底改变了交互流程。

举个例子。用户问“过去三个季度每个季度的营收增长率分别是多少”。普通RAG可能直接检索“营收增长率”相关片段，结果只找到其中一个季度的信息。Agentic RAG会先把问题拆成三个子查询，逐个检索、逐个验证，最后汇总成完整答案。如果第一次检索结果不够，它还会改写查询词、换个知识库重试。这种“计划 -> 工具调用 -> 观察 -> 反思”的循环，正是Agentic RAG的核心。

Self-RAG、CRAG这类进阶方案也属于这个范畴。Self-RAG让模型在生成时自我反思“检索到的内容是否回答充分”，如果不够就再检索一次。CRAG专门做“检索结果有误”的纠正，引入一个评估器判断检索质量，如果低置信度就做额外的检索或知识重构。

4.2 一个可落地的Agentic RAG架构

在实际项目里，我不会让Agent完全自由发挥，而是给它搭一个“围栏”，让它在有限动作里做决策。一种比较稳的参考架构包括四个组件：路由、工具、记忆、评估。

• 路由（Router）：先判断用户问题是否需要外部知识。能直接回答的闲聊和常识问题，不走RAG；涉及知识库的才走检索。这一步能省不少token。
• 工具（Tools）：暴露给Agent的不是一个“检索函数”，而是多个精细动作。比如“查向量库”“查关键词库”“查图谱”“查某个数据库”。每个工具都有明确的描述，让模型知道该选哪个。
• 记忆（Memory）：在多轮对话里维护“已经查过什么、用户真正关心什么”，避免重复劳动和丢失上下文。
• 评估（Evaluator）：每轮检索后做一个质量评估，如果得分低，则触发重写查询、重检索等动作。

我用LangChain的Agent或自研状态机实现过类似流程。关键不是Agent框架选什么，而是你要设计好“动作空间”。动作越具体，模型越容易做出正确决策。比如提供“查供应商库”和“查一般知识库”两个工具，就比一个“search”接口要可靠得多。

4.3 实操心法：给Agent加护栏，防止失控循环

Agentic RAG最大的风险不是“不动”，而是“乱动”。模型会在一轮轮检索里越跑越远，最后生成一个看起来很有道理、其实完全偏题的答案，而且Token成本高得吓人。我在这上面栽过跟头，后来养成了几个习惯。

第一，必须有最大迭代次数限制。我通常把单轮问题的检索循环上限控制在3~5次。超过次数就中止循环，直接基于当前结果生成，并使用“根据现有资料，我未能完整回答”这样的提示。这比让Agent死磕更可靠。

第二，路由优先于检索。很多问题根本不需要外挂知识，但Agent会为了“展示工具能力”强行检索。所以路由层要用一个轻量分类器或者强规则去拦截，让闲聊归闲聊，知识库归知识库。

第三，日志和Trace一定要打全。Agent每步调用了哪个工具、输入输出是什么、得分多少，全部记录下来。否则出现问题你都不知道是路由错了、工具错了还是评估错了。我用LangSmith和Phoenix都做过追踪，能极大缩短排查时间。

5. 零基础复刻：Ollama + 简易本地RAG知识库

5.1 为什么要用Ollama做本地RAG

不少读者问过我怎么搭本地知识库。原因无外乎两种：数据敏感，不能上传到第三方API；或者是想控制成本，不想按Token付费。Ollama是目前对新手最友好的本地模型运行工具，没有之一。它能一键下载和管理模型，自动把模型跑在CPU或GPU上，并提供兼容OpenAI的接口，后面接RAG非常方便。

我为什么推荐“Ollama + 简易RAG”而不是一上来就搞Kubernetes和分布式向量库？因为第一步是把链路跑通，不是堆基建。本地模型的效果虽然和GPT-4级别有差距，但配合轻量级向量库，完全够做一个可复现的Demo或内部知识库。等你验证了“这个方向可行”，再考虑换更好的Embedding模型和更强的推理模型也不迟。

本地RAG链路里有两个模型：Embedding模型和生成模型。Ollama都支持。新手容易忽略Embedding模型的重要性，总觉得“生成模型大就完事了”。其实在小知识库场景下，Embedding模型的效果直接影响检索质量，建议至少挑一个中文效果过得去的嵌入模型，比如bge-m3或nomic-embed-text。

5.2 一步步串起来：嵌入、向量库、大模型

下面这套流程我复制过很多遍，零基础可以直接照做。假设你已经装好Ollama，打开终端按顺序执行就行。

第一步，拉取需要的模型。我一般拉一个生成模型和一个嵌入模型：

ollama pull qwen2.5:7b ollama pull bge-m3

第二步，准备一个Python脚本，读取本地文本。先安装几个库：

pip install chromadb langchain langchain-community ollama

第三步，把文档切成片段，并存进向量库。我这里的代码写了注释，方便新手照抄：

from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma # 读取文件并切块 loader = TextLoader("knowledge.txt") documents = loader.load() splitter = RecursiveCharacterTextSplitter( chunk_size=500, # 每个片段最大字符数 chunk_overlap=80, # 相邻片段重叠字符数 separators=["\n\n", "\n", "。", "！", "？"] ) chunks = splitter.split_documents(documents) # 用Ollama的bge-m3做向量化，存入Chroma embedding = OllamaEmbeddings(model="bge-m3") vectorstore = Chroma.from_documents( documents=chunks, embedding=embedding, persist_directory="./my_local_rag_db" )

第四步，检索并交给大模型生成答案：

from langchain_community.chat_models import ChatOllama # 检索Top K，这里先用3，数据少可以放宽到5 retrieved = vectorstore.similarity_search("采购后多久需要验收？", k=3) # 把检索结果拼进Prompt context = "\n\n".join([doc.page_content for doc in retrieved]) question = "采购后多久需要验收？" prompt = f"""请根据下面的资料回答问题。如果资料中没有准确答案，请明确说不知道。 资料： {context} 问题：{question} """ # 本地生成 llm = ChatOllama(model="qwen2.5:7b") answer = llm.predict(prompt) print(answer)

这套流程跑通之后，你就拥有了一个完整的本地RAG知识库。注意几点：一是切块大小要根据文档结构调整，代码里的500字是通用值；二是嵌入向量和检索时的嵌入模型必须一致，否则向量空间对不上，这是我见过最多的低级错误；三是Chroma的持久化目录不要放在临时目录，否则重启就没了。

5.3 本地文本拆解工具怎么选

很多人在“文本拆解”这一步就卡住了。PDF、Word、扫描件、表格混在一个知识库里，Python里直接open()读不出来。我在本地RAG项目里常用这些工具，按场景分：

• 纯文本/TXT/MD：直接用内置文件读写，配合正则清洗。
• PDF：优先使用PyMuPDF或pdfplumber，能提取文本和表格；如果是扫描版PDF，需要OCR，推荐ocrmypdf或PaddleOCR。
• Word/Docx：用python-docx读取段落结构，保留标题层级。
• HTML：用BeautifulSoup或trafilatura提取正文，去除导航和广告。
• 复杂页面/幻灯片：可以试试unstructured，它对多种格式做了统一封装，适合批量处理。

有一个很实用的经验：拆解前先做“结构识别”。比如PDF里有章节目录，我会用PyMuPDF把目录提取出来，给每个片段额外打上“章节”标签。这个标签在后续混合检索和引用溯源时非常有用。

分块策略方面，不要盲目用小尺寸。我之前把500字当成金标准，结果发现对于代码、表格、合同条款，语义往往依赖上下文。现在更推荐“按结构边界分块”，比如按Markdown的##标题分，按PDF的章节分，按段落的逻辑边界分。同时设置适当的chunk_overlap，一般在10%到20%之间，太少会截断语义，太多会引入噪声。

6. 效果评估与调优：Hit Rate之外还要看什么

6.1 指标怎么算：Hit Rate、MRR、忠实性

做RAG不能只说“答案好像不错”，要用指标说话。最常用的检索指标是Hit Rate，说白了就是“前K个检索结果里是否包含正确答案”。如果你有N条测试问题，每条问题在Top K里能找到标准答案的占比，就是Hit Rate@K。

第二个常用指标是MRR（Mean Reciprocal Rank），它不只关心“有没有”，还关心“排第几位”。比如正确答案排在第一位，得分是1；排在第二位，得分是1/2；第三位是1/3。MRR越高，说明重排序效果越好。

生成侧，最重要的指标是“忠实性”（Faithfulness），即答案是否忠于检索到的上下文，有没有自己编造。忠实性可以人工评测，也可以用大模型打分。我的做法是准备一个几十条问题的评测集，自动跑一遍RAG，再让一个强模型对答案的“上下文一致性”和“答案完整性”打分。这个评测集一旦沉淀下来，之后每次改动都能看到量化结果，调优就不靠感觉了。

hit_rate相关的实现，简单版本是这样：

def hit_rate(predicted_docs, gold_doc_ids, k=5): hits = 0 for docs, gold_ids in zip(predicted_docs, gold_doc_ids): top_k_ids = [d.metadata["doc_id"] for d in docs[:k]] if any(gid in top_k_ids for gid in gold_ids): hits += 1 return hits / len(predicted_docs)

6.2 从“检索命中”到“答案可用”的调优清单

当我发现最终答案不理想时，会按下面这个顺序排查，能省不少时间：

• 先看检索Hit Rate@5：如果低于60%，优先优化分块策略、Embedding模型和混合检索。
• 再看重排序后的MRR@5：如果MRR偏低，说明Top K里虽然有正确答案，但它排太靠后，需要换重排序模型或调整候选数量。
• 然后看上下文是否截断：如果正确答案在最尾部被截掉了，加长chunk_size或调整生成阶段窗口长度。
• 最后看提示词：让大模型“严格基于资料回答，不要推测”，能减少幻觉。

我见过很多项目卡在“Hit Rate很高但答案很烂”。这时候往往是上下文组织问题：多个相似片段互相矛盾，或者关键证据藏在冗余文本里。一个技巧是给每个片段加“摘要前缀”，比如[合同-第3章-支付条款]，大模型看到这个标签后，理解力会明显提升。

6.3 RAG知识库能存图片吗？多模态的现实与误区

“RAG知识库能不能存图片”这个问题隔一段时间就有人问。直接回答：纯文本向量库不能直接存图片，图片本身没法变成向量存进同一个向量空间然后被RAG使用。但如果你只是想让知识库“包含”图片，有两条不同的路子。

一条路是走多模态RAG。用CLIP这类多模态Embedding模型把图片编码成向量，和文本向量放在同一个向量库里；生成时再把检索到的图片交给视觉大模型（比如GPT-4V、Qwen-VL）理解。这条路效果不错，但对本地部署的硬件要求高，不建议零基础一上来就做。

另一条路是“图随文存”。在文本片段里保留图片的引用路径或说明文字，向量库照样存文本，但检索回来时，系统能看到“这段是图，附件的路径在哪里”。这样在本地知识库中也能做到“看图答问”，只是需要你写代码把图片路径和文本片段关联起来。

我的建议是：如果你的知识库图片占比很大，优先考虑多模态RAG；如果只是偶尔有插图，用“图随文存”更省事。别被“多模态”三个字吓到，工程落地的关键永远是：先解决核心检索问题，再解决扩展问题。

7. 高级RAG工具链速览：LangChain4j Easy RAG与社区选择

写到这里，有人可能想知道具体怎么选框架。Python生态自不必说，LlamaIndex、LangChain、Haystack三足鼎立。如果你是Java背景，能从LangChain4j的Easy RAG模块找到不少便利。

LangChain4j本身是Java版的LangChain，Easy RAG是它内部封装的“零配置RAG管线”。我帮一个Java团队搭内部知识库时用过，体验是：你不用自己写繁琐的Loader和Splitter，定义一个DocumentSplitter、一个EmbeddingStore，再给一个答案格式模板，它就能把“读取 -> 切分 -> 向量化 -> 检索 -> 生成”串起来。适合那种想快速做一个RAG Demo、又不想引入一堆Python依赖的场景。

但这里有个提醒：任何框架的“Easy”模式都只适合跑通原型。等你开始调优时，还是得深入到底层参数。LangChain4j里重排序、查询改写、元数据过滤这些高级功能都是可以单独配置的，但官方文档里藏得比较深，需要耐心翻。别被“Easy”两个字骗了。

社区里还有一个越来越火的方案是graphrag，微软开源，可以直接把文档自动构建成图谱并生成社区摘要。我自己测试过，它对“全局性问题”回答效果确实比普通RAG好，但资源消耗不小，中文知识库还需要额外做分词和实体对齐。选不选它，看完前面的GraphRAG评估标准就清楚了。

8. 最后分享一个实战小技巧

我自己在多个RAG项目里坚持做的一件事，是在项目启动的第一周就建评测集。哪怕先手工整理30条问题和标准答案，也比“边做边测”强。评测集覆盖三类就够了：简单事实型、跨文档关联型、没有答案型。每一次改动都跑一遍这三类问题，记录Hit Rate、MRR和“不知道率”，你会非常清晰地看到每次优化的真实影响。

如果只记一个指标，我会选“不知道率”。一个敢说“我不知道”的RAG，比一个总是编造的RAG更值得信任。把这作为默认提示词的一部分，很多看似诡异的问题都会自动消失。高级RAG的技术更新很快，但这条调优方法一直没变：数据、指标、反馈，缺一不可。