企业官网建设流程全解析

这两年RAG已经从“能做个问答Demo”走到了“能不能扛住线上业务”的考验期。我接触过不少团队，本地Jupyter跑得眉飞色舞，一到生产就卡住：检索出来的文档不相关、回答偶尔一本正经地胡说八道、换一次数据就要人工评估几十条回复。最近我系统性梳理了一个生产级Agentic RAG的完整落地路径，它不只是一套代码，而是一整套工程方法论：如何设计Agent自主规划检索策略、如何区分向量库/知识图谱/结构化库的适用场景、如何建立评估体系、上线后如何监控和排查。这篇文章相当于这套方法论的核心章节提炼，适合正在做知识库问答、企业信息检索、智能客服、报告生成，并且已经不满足于“能跑”的开发和架构同学。

1. Agentic RAG是什么，跟传统RAG差在哪

1.1 先搞明白传统RAG的边界：检索写死在哪里，问题就出在哪里

传统RAG的流程大家都熟：文档切块、embedding入库、用户问题也转成向量、取top_k、拼prompt、让大模型生成。优点是非常简单，工程上很容易落地，但问题恰恰藏在“简单”里——它把“检索什么”这一步写死成了“永远找语义最接近的几段文字”。你问什么都一样，先把问题向量化，然后去向量库里捞，捞回来就拼给模型，模型只能用这些材料作答。这个流程对“这个政策文件里关于报销的规定是什么”之类的问题足够用，但一碰到需要判断、组合、换路线的复杂问题，立刻捉襟见肘。

举个例子，用户问“我们Q3营收比Q2增长了多少”。传统RAG会去抓一段看起来跟“营收”相关的文字，但它不会想到先去查结构化财务表，也不会意识到这个问题需要一次数值计算。更麻烦的是，如果top_k里没有正确答案，它不会重试，而是硬着头皮编一个。很多人遇到的“RAG瓶颈”，根源就在这里：检索策略单一、没有反馈回路、错了也不会回头。你换更大的模型、更好的embedding，都治标不治本，因为决策逻辑没有变。

1.2 Agentic RAG的核心能力：把检索策略的选择权交给LLM

Agentic RAG的关键改变，是让大模型自己决定“怎么查”。它先分析问题类型，把它路由到不同工具上——可能是向量检索、SQL查询、知识图谱查询或者外部API；拿到结果后还会做一次验证，如果发现答案没找到，它会换个关键词重新检索，或者改走其他工具。你可以把它理解成一个老练的助理，而不是一个只会伸手拿书的人。助理会先判断这是个什么问题，该查档案室还是查财务系统，查完之后还会看一眼资料够不够用，不够就换一种查法。

工程上做这件事需要三块东西。第一块是工具注册表（Tool Registry），把每个检索能力包装成带名字、带描述的API，LLM才知道什么场景该调用哪个。第二块是状态管理，用一个状态机或者图来约束Agent的步骤，避免它在工具调用之间无限循环。第三块是决策策略，什么时候停、什么时候换路、什么时候把问题转给人工，这些边界不写死，Agent就会变得不可控。LangGraph、LlamaIndex的Agent模块、甚至自研状态机都能做，框架本身不重要，重要的是状态和边界设计。

1.3 为什么这套能力值得当成一门课来系统学

最近搜“rag教程”“rag框架”的人很多，但真正卡住大家的已经不是怎么调库，而是怎么让一套RAG系统稳定地跑在线上。Agentic RAG尤其要注意——它多出来的每一层智能，都会带来多一次的故障可能。把production和agentic放在一起，就意味着你不能再用demo思维写代码。输入要有防护，输出要有校验，每一步都要可观测、可回滚。这是一套之前做普通CRUD或传统RAG时很少涉及的工程能力，所以它值得被当成一门课来对待，而不是“装个包跑通就完事”。下文我会按生产落地的真实顺序，把检索、知识库选型、评估、部署各环节的关键决策拆开讲。

2. 生产化才是真难点：demo能跑，线上为什么卡住

2.1 检索质量一到生产就失灵：三个典型原因和排查路径

很多人到了production阶段遇到的第一个问题：本地测试时检索结果好好的，上生产后同样的问法，召回的内容变成了垃圾。原因通常有三类。第一是数据变了——生产库里的文档数量级、语言分布、格式多样性，和本地那几百个测试文件完全不是一个量级。第二是切分参数没调，很多教程默认chunk_size=500、overlap=50，但生产文档里如果表格多、代码多、中英混排多，这个默认值很可能把关键信息从中间切断。第三是embedding模型和领域不匹配，通用模型在专业术语密集的场景下，召回效果会肉眼可见地变差。

排查思路也别急着怀疑模型，先把一次query的检索结果赤裸裸地打出来。看top_k里到底有没有相关内容：如果没有，那是上游检索问题，跟生成模型无关；如果有但回答错了，才是下游生成问题。这一步分层，能把排查时间缩短一半。另外我建议在本地起一个和生产一致的检索函数，单独做召回测试，不要让Agent流程混进来干扰判断。

2.2 没有评估体系，优化就是赌运气：RAGAS与Golden Set

生产化最容易被跳过的环节是评估。demo阶段你看三五个回复觉得“还行”，但线上成百上千的query，你根本不知道哪些在退化，哪些在变好。RAG圈现在提到评估，基本都会拿RAGAS那套指标说事：faithfulness（忠实度，回答有没有被检索内容支撑）、answer relevance（答案相关性，回答有没有直接回应问题）、context relevance（上下文相关性，检索出来的上下文是否够用）。指标是工具，但更关键的是先攒一个Golden Set——50到100条覆盖核心业务场景的“问题-参考答案-应引用文档”。这个数据集看起来费时间，实际上是你后续所有迭代的锚点。

我见过太多团队花三周优化检索算法，结果因为评估集没建，根本看不出优化是正向还是负向。先花一周把评估集和评测脚本跑起来，再谈优化，这是production项目最值得的一笔投资。没有评估体系的Agentic RAG，就是在黑箱里调参，靠感觉上线，迟早出事故。

2.3 成本、延迟和数据更新：Agent多出来的每一轮调用都要付钱

Agentic RAG的token消耗是传统RAG的2到5倍，这是很多人没提前算的一笔账。一次查询可能触发多轮工具调用，每轮都是一次大模型请求。生产里必须做三件事：一是设定迭代上限，例如最多调用4次工具，超过就降级到简单模式；二是模型分级，规划用小规格模型做路由和意图识别，只有最终生成才调用大模型；三是对检索结果做缓存，相同或相似问题的embedding和检索结果缓存起来，能拦掉大量重复计算。

延迟也一样，不得不在效果和体验之间取舍。比如top_k取20再加rerank到5，效果比直接top_k取5好，但延迟多200ms，这个trade-off要在评估阶段定下来，而不是上线后被用户吐槽了才来调。还有一个经常被忽略的问题——数据更新。生产知识库不可能永远不变，新增文档、过期文档、删除文档，各自要有更新策略。文档更新后索引要重建，否则Agent检索到的还是旧版本答案，最容易出事故。

3. 知识库形态怎么选：向量库、知识图谱和结构化库是不同工具

3.1 向量库、知识图谱、结构化库的核心区别与应用场景

这个主题最近讨论很多，因为RAG做深了你会发现“向量库包打天下”是不成立的。三种形态实际上是三类工具，适用场景完全不同。

很多人问“rag知识库和结构知识库区分以及应用场景”，本质上是没分清意图类型。政策问答、语义搜索这类问题，向量库最合适，因为它不需要你提前定义数据模型；但“上个月华东区卖了多少台A型号”这种问题，向量库给不了精确数字，必须走结构化数据。知识图谱则解决另一类问题：“哪些供应商同时给A和B供货”“这个变更会影响哪些下游系统”，这类关系型问题用向量检索只能得到零散文档，用KG能直接沿关系边跳出来。

3.2 什么场景值得上知识图谱和本体：关系推理与路径约束

上不上KG，判断标准很实际：你的问题里有没有“关系”。如果用户会问“这个流程涉及哪些系统、对应负责人是谁”，向量检索大概率只能给你一些不相关的材料，而KG可以直接给出关系路径。另一个判断点是是否需要约束推理路径。比如金融风控场景，必须走“客户-产品-风险等级”这样的既定链路，这时候在KG上套一层本体（Ontology）就很有价值。本体定义了概念与关系的schema，LLM先生成结构化查询再执行，而不是自由发挥，这能显著降低幻觉，也是现在ontology rag被反复提起的原因。

但我也劝一句：如果业务问题全是纯文本问答，没有复杂关系和多跳，先别急着建KG。图谱的构建和维护成本远比向量库高，数据没有清晰实体关系时，建出来也是一个没人维护的死图。生产里我见过太多团队跟风建图谱，最后因为实体对齐做不好，查询结果还不如纯向量检索，白费三个月时间。

3.3 生产环境的混合检索架构：让Agent自己决定查哪条路

真正上生产，大多数知识库系统是混着用的。主检索仍然是向量库，因为覆盖度最高、成本最低；同时把关键实体的关系抽到KG里，做实体链接和关系查询；结构化数据继续留在库里，通过text-to-SQL工具暴露给Agent。谁来决定走哪条路？Agent本身。它先做路由判断，再决定调用哪个工具；多轮检索时还可以把结果做交叉核对，比如SQL查到数据后，回到文档库取一段上下文做支撑说明。

这套架构对中小团队并不友好，所以我建议从简到繁：第一版只上向量库+结构化库，跑通评估后再加KG。大多数项目的检索瓶颈在召回质量，而不在关系推理，先把常规路径做好，再谈高级能力。混合架构不是炫技，是问题本身复杂到单一路径解决不了时才需要的方案。

4. 从本机原型到生产部署的实操路线

4.1 Mac本机快速搭建RAG知识库：Ollama+Chroma的十分钟方案

很多人在搜“怎么在mac上搭建rag知识库”，我直接给一条可行的本机路线。前提是你有一台Apple Silicon的Mac，建议内存16GB以上。第一步安装Ollama，一条命令：brew install ollama，然后拉取模型：ollama pull qwen2.5:14b（负责生成）和ollama pull bge-m3（负责embedding）。bge-m3在中文场景下表现比较均衡，Alibaba的嵌入模型也可以替换，关键是跟你的文档语料语言匹配。

向量库本机先用Chroma或FAISS，Chroma更省事，数据落盘在本地目录。用LlamaIndex或者LangChain把流程串起来，我用LlamaIndex写一个最小可运行示例：

from llama_index.core import VectorStoreIndex, SimpleDirectoryReader from llama_index.embeddings.ollama import OllamaEmbedding from llama_index.llms.ollama import Ollama from llama_index.core.settings import Settings Settings.embed_model = OllamaEmbedding( model_name="bge-m3", base_url="http://localhost:11434" ) Settings.llm = Ollama( model="qwen2.5:14b", temperature=0.1 ) documents = SimpleDirectoryReader("./data").load_data() index = VectorStoreIndex.from_documents( documents, chunk_size=512, chunk_overlap=64 ) query_engine = index.as_query_engine(similarity_top_k=6) response = query_engine.query("你准备好的测试问题") print(response)

这个示例只有十几行，但它把你的本机RAG跑起来了。chunk_size=512和overlap=64是我踩过比较多轮的起点，适合中文文档；如果文档结构性强，比如大量表格和清单，建议降到256。跑起来之后别急着换框架，先看检索效果，再往Agent方向扩展。注意Apple Silicon上Ollama默认占内存不小，跑14B模型同时开浏览器和IDE可能会卡，建议把模型量化版本换成qwen2.5:14b-instruct-q4_K_M，体感会好很多。

4.2 Agentic流程的工程拆分：把智能拆成四个可维护状态

把RAG升级成Agentic，不用一步到位，我习惯拆成四个可控组件。一是路由（Router），先判断问题意图：是事实问答、关系查询、数值统计，还是闲聊。路由可以用小模型加few-shot提示来做，不需要大模型。二是检索（Retriever），按路由结果调用不同工具，每个工具必须有清晰的名字和描述，LLM才知道什么时候该用。三是验证（Validator），拿到检索结果后，让模型判断“这些上下文是否足以回答问题”，不足则触发二次检索或改写query，最多循环N次。四是回答（Responder），用最终上下文生成答案，带引用，还可以做一次自检。

伪代码把调度逻辑写出来：

def agentic_answer(question: str, tools: dict) -> str: intent = route(question) # 1 路由 max_iterations = 3 for _ in range(max_iterations): context = tools[intent].retrieve(question) # 2 检索 if len(context) == 0: question = rewrite_query(question) # 重写query后继续 continue verified = validate(question, context) # 3 验证 if verified["sufficient"]: break return answer(question, context) # 4 回答

这套拆法的好处在于每个环节都能单独打日志、单独评估，出问题时能定位到具体节点，而不是在一条深不可测的Agent链时排查。实际项目里，Agentic最容易犯的毛病是死循环——工具调用失败后反复重试。max_iterations一定要设限，超限后走fallback路径，比如直接返回几条相关文档链接，或者转人工。

4.3 生产级评估能力：先攒一套回归集，再谈上线

上线前最重要的一件事，是把评估跑成自动化流程。我建议建一个Golden Set，每条包含三样东西：问题、期望答案要点、应当覆盖的引用文档。数量不用多，50到100条，但要覆盖生产真实query的分布。跑评测时，自动记录三个维度：忠实度，看回答里的关键论点是否都能在引用里找到；答案相关性，看回答对问题的命中程度；引用命中率，看系统引用的文档和Golden Set标注的参考文档重叠度。

评估分两套跑。离线回归，每次改动索引、提示词、切分参数后，批量跑一遍Golden Set，对比分数变化；在线抽查，线上流量按一定比例采样，人工标注回答质量。没有这两套机制，任何“效果优化”都是在赌运气。有人会觉得100条太少，实际上100条精心设计的集子已经能拦住80%的明显回归，关键是问题要覆盖不同意图类型，别只挑简单的。

5. 生产环境的常见问题与排查经验

5.1 检索为空、答非所问、幻觉：三类问题的排查顺序

上线之后一定会有反馈，归纳起来三类：检索为空、答非所问、幻觉。我按优先级给你一个排查顺序。检索为空：先看检索引擎的原始输出，top_k是不是真没召回。如果没召回，多半是query的表达方式和文档的语言风格差太远，试试改写query、加同义词、上混合检索（向量+BM25）；如果召回了一堆但都不相关，检查chunk_size和embedding模型，考虑换领域模型或加rerank。

答非所问：多半是prompt和温度设置问题。生成温度降到0.1左右，system prompt里明确写“如果上下文不足，直接说不知道”。另外Agent路由错了也常见——问统计问题却跑了文档检索，问语义问题却走了SQL，这种要去路由模块的日志里看意图判断结果。幻觉：第一防线是强制引用，要求回答必须标注来源，只允许基于引用内容下结论；第二防线是前面说的Validator，检索内容不足时不生成；第三防线才是换更好的模型。一个容易被忽略的坑：多个来源互相矛盾。比如文档A说流程是三步，文档B说四步，模型会择优或者拼凑。这种需要在路由阶段识别冲突性问题，把两边的信息都检索出来，让答案在最后注明“不同文档存在差异，需人工确认”。

5.2 知识库能不能存图片：多模态资料的正确入库姿势

很多人搜“rag知识库能存储图片嘛”，直接回答：能，但你要分清存的是什么。向量库本身不存图片原文件，它存的是图片输入到多模态模型（比如CLIP、SigLIP）生成的向量，以及图片的元数据。原文件放对象存储，比如S3、OSS或者MinIO，向量库里存embedding和对象地址。检索时先向量召回，再按地址从对象存储拉原图展示。

实际项目里图片类资料常见几种形态：产品图、扫描文档、幻灯片截图、PDF里的图表。处理方式也不同：产品图可以用图文混合索引，问“红色款有没有现货”时，既检索产品描述文本也检索图片向量；扫描件和PDF里的图表，则先OCR转成文本再入库，效果通常比直接向量化图片更好、更省钱。我的建议是能不上多模态就不上，多模态RAG的成本和延迟都会增加；但如果业务确实需要，就按“向量+对象存储+元数据”三条腿来搭，别想着把所有图片二进制塞进向量库。

5.3 可观测性设计：上线后如何定位是哪个环节坏了

Agentic RAG上线后，你不可能像调试单体应用那样直接打断点，必须提前把可观测性设计进去。我推荐用OpenTelemetry做链路追踪，每个环节（路由、检索、验证、生成）都打一个span，记录耗时和输入输出摘要。如果一个query变慢，追踪里能直接看到卡在哪一轮检索；如果回答质量下滑，能回看是哪一步把错误上下文带了进来。

工具上，LangSmith和Langfuse这类平台可以直接跟LangChain/LlamaIndex集成。不上这些平台也得有结构化日志，至少把每一次tool call的query、检索结果数量和token消耗记录下来。没有日志的Agent系统，故障排查会是一场灾难——你根本不知道Agent在内部做了多少次“思考”，也不知道是哪次思考带偏了方向。可观测性是生产化和demo最明显的分界线，demo里你人可以盯着看，生产里机器必须替你盯着。

最后说点个人体会。我做知识库项目这几年，最大的感受是：成功上线Agentic RAG的关键，不在Agent的“智能”有多惊艳，而在能不能把不确定性管理好。先用最小的可运行版本跑通，把评估集建起来，把日志铺齐，再慢慢加自主决策能力。每一步都要问自己：这一层智能会不会让系统更不可控？如果会，就先想想兜底方案。希望这篇拆解能帮你在production这条路上少踩一些坑——毕竟，“能跑”和“能上线”之间，隔着的不是模型能力，而是工程修养。