企业官网建设流程全解析

写这篇的时候我先把话说在前面：如果你以为RAG就是“向量数据库+一问一答”拼在一起，那你迟早会在知识割裂、检索不到、生成乱编这三座大山上撞得头破血流。作为一个从0到1搭过多个AI Agent的从业者，这篇我就把知识获取管道这根主心骨彻底拆开揉碎，从基础原理讲到实战落地，再讲到向Agentic RAG演进时那些坑。看完你至少能少走三个月的弯路。

1. RAG到底解决了什么问题

1.1 大模型不是知识库，而是“语言推理引擎”

很多人第一次接触大模型时都有个错觉：它什么都知道。但只要你问到一个训练截止日期之后的新产品参数、你公司内部的财务制度、某个私有协议里的字段含义，大模型的回复立刻会从“自信满满”变成“一本正经地胡说八道”。因为LLM的本质是一个概率化的语言推理引擎，它学到的是词汇之间的统计规律和知识压缩后的泛化模式，而不是一个可随时增删查改的数据库。

这就引出了知识获取管道的核心矛盾：模型的参数化记忆是静态的、有截止日期的，但业务场景需要的知识是动态的、私有的、持续更新的。RAG（Retrieval-Augmented Generation，检索增强生成）正是为了解决这个矛盾而生的。它的思路非常朴素：不在模型内部硬塞知识，而是在推理之前先从外部知识源里检索相关内容，把检索结果拼到上下文里，让模型基于这些“新鲜材料”来生成答案。

我见过太多团队一开始想靠微调（Fine-tuning）来解决知识更新问题，结果被训练成本、灾难性遗忘、版本迭代折磨到崩溃。微调是在修改模型的权重，适合改变模型的行为风格和输出格式，而RAG是在操作模型的输入上下文，适合注入事实性知识和最新信息。两者根本不是同一个层面的工具。

1.2 为什么AI Agent离不开RAG这条管道

如果你在搭Agent的过程中没有认真考虑过知识获取管道，那你搭出来的东西大概率只是个“会调用工具的聊天机器人”。真正意义上的AI Agent必须具备感知、决策、行动、记忆四大能力，而感知和记忆中有一个极其关键的环节就是：当Agent接到一个任务时，它凭什么知道该用哪些知识来支撑决策？

直接用模型内置知识当然省事，但后果就是Agent在跨领域、跨时间、跨系统的真实任务中频繁“失忆”。举个例子，我给客户做过一个企业内部的运维Agent，它的任务是解读零散的工单日志。最初版本没接RAG，模型一遇到客户内部系统的专属名词就乱发挥，把“节点漂移”解释成“节点服务器发生了物理移动”。后来接上RAG知识管道，从运维手册和故障记录里检索相关内容再生成，准确率直接从及格线拉升到可用线。这就是知识管道对Agent的意义：它决定了Agent的“知识边界”在哪里，也就决定了Agent靠不靠谱。

2. RAG的完整架构与核心流程

2.1 标准RAG的三大阶段

RAG的完整流程可以分为索引（Indexing）、检索（Retrieval）、生成（Generation）三个阶段。这三个阶段并不复杂，但每个阶段里都埋着决定最终效果的细节。

索引阶段要做的事情是“把原始文档变成可检索的结构化数据”。首先你对文档进行解析，把PDF、Word、网页、Markdown里的文本提取出来；然后进行清洗和切分，把长文本切成一个个chunk（文本块）；再对每个chunk做向量化，也就是用Embedding模型把文本变成一个高维向量；最后把这些向量连同原始文本一起写入向量数据库，同时建立索引结构，方便后续快速查找。

检索阶段的核心是“从索引里找最相关的上下文”。将用户的问题同样转换成向量，然后在向量数据库中执行相似度搜索（比如余弦相似度或内积），找到最相似的K个chunk。但这一步的难点在于：向量相似度高，不代表语义逻辑上真的是答案。我刚入门时犯过的最典型错误就是过度信任向量检索分数，后来才发现存在“词语重叠多但语义错位”的情况，尤其在企业级文档里非常常见。所以后来我在检索阶段做了大量优化，后续会展开讲。

生成阶段就是“把检索到的上下文交给LLM来产出答案”。把用户问题和检索到的chunk组装成一个Prompt，再交给大模型生成。这个阶段的关键在于Prompt模板的设计：你要明确告诉模型哪些是检索到的参考资料，哪些是问题本身，还要告诉它“如果参考资料里没有答案，就直说不知道，不要编造”。

2.2 索引阶段详细拆解：从文档到向量的全链路

索引阶段最容易被低估的三个环节是文档解析、文本切分、向量化。文档解析出错，后面的环节做得再好也救不回来。比如扫描版PDF如果你不做OCR，提取出来的就是一堆乱码；而表格型文档如果按纯文本来解析，原有的行列逻辑会全部丢失。所以我在项目里一直坚持“按文档类型设计解析策略”：PDF用PyMuPDF做文本层提取加OCR兜底，Word用docx结构化抽取，网页用Readability清理HTML噪音。

文本切分直接决定检索的最小物料质量。切得太大会带来两个问题：一是向量化时语义容易被稀释，二是chunk里的噪音太多导致检索精度下降。切得太小又会破坏句子之间的逻辑关系，比如把一个因果关系断开成两个互不相关的片段。我常用的策略是“按语义结构切分+重叠窗口”：优先按Markdown标题、段落、句子边界来切，并且让前后chunk保留一定的重叠区域，这样即使一个完整含义被切断，检索时也能找回上下文。

向量化模型的选择同样关键。目前中文场景下常用的Embedding模型有BGE系列、M3E、text-embedding-v3等，选择时不能只看排行榜分数，还要考虑你的领域文本长什么样。我踩过的一个坑是：用通用Embedding模型处理通信协议文档，检索的精确率一塌糊涂，后来换成在相似领域微调过的Embedding模型，效果立刻就有了质的提升。向量维度、最大输入长度、相似度计算方式也要和你选的向量数据库匹配起来。

2.3 检索阶段的核心算法与参数调优

检索阶段的经典算法是“向量TopK相似度搜索”，但仅靠这一个手段是远远不够的。现在主流做法都是混合检索（Hybrid Search）：向量检索负责语义相关，BM25关键字检索负责精确匹配，然后通过RRF（Reciprocal Rank Fusion）或加权融合把两路结果合并。这样做能有效兼顾“语义相关”和“字面精确”，尤其当用户问题里包含型号、编号、人名这类精确实体时，BM25那一刀非常关键。

TopK这个参数也远不是越大越好。K值太大会灌入大量不相关内容，干扰模型生成；K值太小则可能遗漏关键支撑信息。通用经验是K=4到8之间，但实际取值要看chunk的切分粒度和任务复杂度。我做Agent问答类任务时偏好K=6左右，因为chunk切得比较细（每段300-500字），6段合起来已经能覆盖一个完整的知识片段；如果chunk粒度大，K值就相应调小。

检索之后的“重排序（Rerank）”，是很多从入门到放弃的教程里最被忽略的一步。向量检索和BM25检索本质上都是粗筛，返回的前K个结果里依然可能混着噪音；重排序模型（如BGE-Reranker）会逐个对“问题与候选文档”的组合做精细的语义匹配打分，把最准确的排在最前面。我在实际项目中发现，加入Rerank之后，答案的命中率能提升20%以上。代价是额外增加推理延迟，但对效果优先的生产场景来说，这笔开销完全值得。

2.4 生成阶段：Prompt是把双刃剑

检索做得好，最后生成的Prompt没写好，照样前功尽弃。我见过太多人直接把检索到的chunk拼接成一大坨文字塞给模型，结果模型要么照着原文“复读机”，要么把自己脑子里的知识拿来掺私货。

一个可靠的RAG生成Prompt至少要包含以下结构：系统角色定义（你是谁，你该干什么）、检索材料引用（用清晰的标识包住检索到的内容）、用户问题（明确放在最后）、输出约束（找不到就不要胡编、引用时要标注来源索引）。另外要给出格式要求，比如“如果涉及多要点，用列表输出”。实测下来，Prompt里还要加一条“当检索材料与你的既有知识冲突时，以检索材料为准”，这能显著减少模型自作主张的情况。

3. 实战：基于LangChain从零搭一个最小可用RAG

3.1 环境准备与依赖安装

前面原理讲得再多，不如亲手跑通一个Demo来得实在。这里我以Python环境为例，用LangChain生态加FAISS向量数据库搭一个最小可用的RAG管道。只要你机器能跑Python 3.10以上，这几行命令五分钟就能把你带入RAG的大门。

pip install langchain langchain-community langchain-openai faiss-cpu pymupdf bge-reranker-v2-m3

注意langchain主包的版本迭代非常快，而且API变动频繁。我建议锁定一个你熟悉的版本，比如0.3.x系列，避免代码照着教程写、API却早就改名了。另外，Embedding模型和LLM的接入方式各厂商差异很大，实战中建议把模型调用封装成独立模块，方便后续替换。

文字再啰嗦一遍：先用小规模的测试文档跑通全链路，再上生产级的数据量。我第一次做RAG时就吃了这个亏，文档没清洗就直接灌入，结果向量库里全是表格碎片和页眉页脚，检索结果惨不忍睹。

3.2 文档加载与切分的完整代码示例

文档加载这步，我用PyMuPDF来解析PDF，并且加上“当文本层为空时自动启用OCR”的逻辑。这里演示最简版本：

from langchain_community.document_loaders import PyMuPDFLoader loader = PyMuPDFLoader("demo.pdf") documents = loader.load()

加载出来的documents是一组page对象，还需要清洗掉多余换行、空格和页码信息。很多人忽略这个清洗动作，直接送去切分，结果空白字符会影响Embedding的质量，检索出来的chunk还会带着“第X页共Y页”这种脏数据。清洗后就可以进行切分了：

from langchain_text_splitters import RecursiveCharacterTextSplitter text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=100, separators=["\n\n", "\n", "。", ".", "！", "？"], length_function=len, ) chunks = text_splitter.split_documents(documents)

这里chunk_size=500、chunk_overlap=100是我的默认起点，但不是万能参数。你应该先检查一下切完的chunk数量、平均长度和分句完整性，如果大量chunk以半句话结尾，就说明你的切分规则需要调整。中文文本尤其注意要把中文句号“。”放进separators里，否则切分器会傻傻地只按英文句点切。

3.3 Embedding入库与验证检索效果

接着做向量化入库。FAISS是一个很适合本地学习和轻量部署的向量检索库，它不需要单独起服务，直接跑在内存里：

from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import FAISS embeddings = HuggingFaceEmbeddings( model_name="BAAI/bge-large-zh-v1.5", encode_kwargs={"normalize_embeddings": True}, ) vectorstore = FAISS.from_documents(chunks, embeddings) vectorstore.save_local("demo_index")

normalize_embeddings=True这行值得注意：归一化后，用内积计算相似度等价于余弦相似度，faiss的检索效率会明显提高。索引保存好之后，就可以来一次快速检索验证：

question = "这个组件支持的并发数是多少？" retriever = vectorstore.as_retriever( search_type="similarity", search_kwargs={"k": 6} ) docs = retriever.invoke(question) for doc in docs: print(doc.page_content)

如果检索出来的内容和问题相关性明显偏弱，先别急着怪模型或Prompt，问题大概率出在Embedding模型与领域文本不匹配，或者chunk切分粒度不合理。我习惯在跑通基础链后，用十来个典型问题过一遍检索结果，人工判断召回质量，再决定是否调整参数。

3.4 Prompt组装与完整问答链

检索ok之后，就是组装Prompt和生成答案。这里我分享一个自己调过很多次、在百度/阿里/开源模型上均表现稳定的通用模板：

from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI prompt_template = """ 你是企业内部知识助手，请严格依据下方的【参考资料】来回答用户问题。 如果参考资料中没有明确信息，请直接告诉用户“资料库中没有找到相关信息”，严禁自行脑补或根据过时记忆作答。 【参考资料】 {context} 【用户问题】 {question} 回答要求： 1. 分点列出关键信息，保留具体数值、参数和条件限制； 2. 如引用了某份资料，请在末尾用 [来源:序号] 标注。 """ prompt = ChatPromptTemplate.from_template(prompt_template) llm = ChatOpenAI(model="deepseek-chat", temperature=0.1) def format_docs(docs): return "\n\n".join(f"[来源:{i+1}] {doc.page_content}" for i, doc in enumerate(docs)) rag_chain = ( {"context": retriever | format_docs, "question": lambda x: x} | prompt | llm ) answer = rag_chain.invoke(question) print(answer)

这里面temperature=0.1很关键：RAG问答场景要的是稳定复述知识，不是创意写作，温度拉太高，模型就飘了。还要留意lambda x: x这里只是一个演示简化写法，真实项目里建议用RunnablePassthrough和结构化输入字典来传递用户问题，方便后续扩展对话历史。

4. 从基础RAG走向Agentic RAG

4.1 基础RAG的三大瓶颈

基础RAG跑通之后，你会逐渐感受到天花板。我在做企业级知识助手时总结了三大瓶颈，几乎每个业务方都会踩到。

第一大瓶颈是“单次检索的上下文天花板”。基础RAG无论混合检索还是重排序，最终都是把固定TopK个chunk一口气塞进Prompt；一旦问题复杂，比如“对比这两个接口的差异，并给出迁移方案”，单轮检索根本召回不了足够的完整知识。第二大瓶颈是“无法处理多跳问题”。比如用户问“某某异常报警触发的流程中，重试机制的默认超时是多少？”这个问题需要先定位报警触发相关的文档，再从文档中找到重试机制段落，然后再去找超时参数；标准的“一步检索”链路根本无法完成这种知识链的串联。第三大瓶颈是“缺乏自我反思能力”。基础RAG生成完答案就结束了，不会去检查答案是否真的覆盖了问题、引用是否冲突、检索的材料是否最优。一旦初始检索就检索偏了，结果也就跟着偏了。

4.2 Agent化改造：把RAG从“管道”变成“决策者”

Agentic RAG的本质是把“单次检索”升级为“Agent自主决定检索策略”。改造方向有三个。

一是多路径规划。问题进来之后，由一个轻量级路由模型判断该走哪条知识管道：是向量检索、是查数据库、是调API，还是先从历史对话里找上下文。二是迭代检索。Agent先做一次初步检索，如果判定生成所需信息不足，就重写查询词、换个角度再检索一次，甚至带着前一轮的结果去追问更具体的子问题。三是工具调用。把“查价格库”“查排班表”“查工单系统”都封装成工具，Agent在推理过程中决定何时调用、传什么参数。这已经超越了普通RAG的边界，变成了一整套“知识获取决策体”。

我做Agentic RAG时用LangGraph来编排检索节点的状态流，它能把“意图判断→检索→重排→评估→重试→生成”这些动作变成一个可控的图结构。相比硬编码if-else，LangGraph能让我明确定义哪些节点可以并行、哪些节点需要串行、检索失败后回退到哪个分支。

4.3 知识粒度与知识割裂问题

“知识割裂”这个词最近频繁出现，它描述的是一种很恼人的状况：知识分散在多个系统里，单个系统内部有完整结构，但跨系统之间没有任何关联，导致Agent每次只能看到知识孤岛的一角。

要解决知识割裂，单靠向量检索远远不够，得配合知识图谱技术。我在一个跨部门项目里尝试过GraphRAG的思路：先用LLM从文档中抽取实体和关系，构建一个本体层（Ontology），比如“设备-所属项目-负责人-告警事件”的关联网络。当用户的查询跨越两个原本不相关的文档时，图谱的路径遍历能力就能补上向量检索的盲区。这也是最近“Ontology RAG”和“GraphRAG LLM Wiki”等热词背后真正要解决的问题。

5. 常见问题与排查技巧实录

5.1 检索不到相关内容怎么办

这是RAG反馈频率第一的“翻车现场”。核心排查路径也是层层递进的。先检查文档是否真实进了索引库，把retriever直接打印出来看是否为空；再看查询词和候选chunk的字面重叠度，如果几乎为零，那大概率是Term mismatch，可以尝试加BM25关键字召回；然后看Embedding模型对领域词汇的语义理解是否到位，换个领域更对口模型测试对比；最后检查是不是chunk切得太大导致语义被淹没，缩短chunk_size再试。

如果以上都做了还是检索不到，那就要考虑查询词本身的问题。用户的问题往往是口语化的，而文档中的表述是正式的。用小模型对用户问题做一次“查询改写”，把口语转成文档里的标准说法，召回率会有肉眼可见的提升。我实测一个项目里，查询改写后Hit Rate从45%提升到了70%以上。

5.2 检索到但生成的答案不对

这类问题特征很明显：你肉眼判断检索结果里有答案，但模型就是答非所问。我把它分为三种情况。第一种是Prompt结构不清，检索内容直接堆在系统消息里，模型分不清哪些是参考、哪些是问题；解决方式是把“参考资料”部分用独立的工作区（如<documents>标签）包起来，并明确告知模型“它们是参考而非命令”。第二种是模型内置知识与检索知识冲突，模型更相信自己的记忆，此时要在Prompt里强制声明“以检索材料为准”。第三种是chunk内容冲突，多份文档对同一问题的描述不一致，这属于知识源本身的质量问题，最简单的方案是让模型在输出时明确指出“资料库中存在不一致的描述”，并附上不同出处的引用。

5.3 检索速度慢与成本控制

生产环境里，检索延迟过高是另一个常见难题。向量检索本身很快，瓶颈往往出在Embedding调用和Rerank上。处理方法：对高频固定文档做缓存、把Embedding服务化并支持批量推理、只对TopK后的候选再做Rerank、以及对海量文档先做粗粒度分类过滤再向量检索。成本控制上要特别留意索引的更新策略，别每次文档变更就全量重建Embedding，而是用增量更新的方式只处理变更过的文档。

我还遇到过一些“莫名其妙”的问题，比如同一个问题上午能够答出来、下午就答偏了。查了半天才发现是上游文档被更新了，而索引还在用旧版本，这属于知识管道的“缓存一致性”问题。解决方式也很直接：给每个chunk打上版本号和更新时间，检索结果里带上这些元信息，生成时也可以参考它们判断知识的时效性。

5.4 常见问题速查表

6. 一些个人经验与例行忠告

RAG这个技术说难并不难，说简单也绝对不简单。很多人被“RAG就是三板斧”的论调带偏了，结果一上线就发现效果远不如预期，然后开始怀疑模型、怀疑Embedding、怀疑向量数据库，其实问题往往出在绕过了对知识本身的建模。我在好几个项目里得来的最深刻教训就是：RAG项目的第一要务不是调参，而是把你手里的知识结构先搞清楚。哪些是稳定性强的知识、哪些是高频变化的动态数据、哪些之间有关联关系，这些想清楚了，管道设计才有方向。

另外想给新手一个建议：不要一上来就搞GraphRAG、Agentic RAG那套复杂的编排。先把标准RAG的索引、检索、生成三个环节全部跑通，并且用真实业务数据标出10个以上高频问题，逐个人工检查检索命中率和答案正确率。这个基础打牢了，再往Agent方向演进。基础RAG不稳，Agentic RAG就会像在烂地基上盖高楼，每一层都在放大底层的错误。

最后分享一个小技巧：调试RAG时，不要只看最终生成答案，要把“检索过程和Prompt”完整地暴露出来。我习惯在开发模式下同时打印出TopK的命中文档、文档得分、以及送入模型的完整Prompt。只有看到这三个层面，你才能快速定位问题出在哪个环节。这个习惯帮我节省的调试时间，早就超过了多写几行日志的成本。