企业官网建设流程全解析

这两年只要打开技术社区，满屏都是AI Agent和RAG，热搜词里也全是“rag是什么”“ai agent入门”“rag实战”这类问题。但说实话，我问过身边不少正在做知识库问答、企业搜索、自动化办公流程的朋友，大多数人对这两者的理解还停留在“RAG就是向量数据库检索，Agent就是能自动调用工具的大模型”这个层面。真到了要动手做项目、要应对评测、要回答面试官追问的时候，才发现里面坑比想象中多得多。

这篇文章不打算从概念PPT讲起，我会直接拆解一个真实项目的思考链路：怎么判断该用RAG、怎么把向量化流程做到能上线、Agent什么时候该介入、评估指标到底怎么算才不糊弄人。内容会结合我实际做过的知识库问答项目和一些最近的热门方向（比如ontology RAG、graph RAG、agentic RAG）来聊，希望能帮正在入门或者卡在某个环节的朋友把整条线捋顺。

1. 先搞明白这套组合到底解决了什么问题

1.1 RAG不是“查资料”，而是给大模型加装“可验证的记忆”

很多人一上来就纠结“RAG和微调哪个好”，这其实是个伪命题。RAG的核心价值不是让模型“记住”更多知识，而是把“知识的存储”和“知识的生成”分开管理。模型本身的参数空间是有限的，你不可能把几千份企业文档全部塞进权重里，就算塞得进去，也没法保证它不会在关键时刻一本正经地编造出处。RAG的思路更像给大模型配了一个随时可以翻阅的档案柜，回答问题时先查档案，再基于查到的内容组织答案。

但这里有一个关键点：RAG的好坏不取决于模型本身，而取决于档案柜的整理方式。同样是拿LangChain搭一套检索问答，为什么有人做出来准确率能到90%，有人做出来连50%都不到？差距基本都出在索引构建的细节上。热词里提到的“rag向量化流程”“如何创建精准的rag”，本质上就是在问同一件事：怎么把文档变成模型真正能高效利用的检索单元。

1.2 Agent解决的是“多步骤任务”，不是“单次问答”

AI Agent和RAG经常被放在一起讨论，是因为它们确实天然互补。RAG管的是“系统该怎么回答”，Agent管的是“系统该怎么做”。举个例子，用户问“帮我看看最近三个月哪个产品的投诉率最高，分析一下原因”，纯RAG能做的是把相关文档片段检索出来拼成答案，但“先查投诉数据表、再定位产品线、再汇总原因”这一个完整流程，需要Agent来规划执行步骤、调用不同工具、最后汇总结果。

我见过不少失败的Agent项目，失败原因几乎都一样：把该用RAG解决的检索问题硬套上Agent多轮规划，结果模型在规划上消耗了大量Token，还经常把步骤拆错。反过来说，只做RAG不做Agent，遇到需要联动多个数据源的任务就会显得非常笨拙。所以理解两者边界比学会技术本身更重要，这也是面试官最喜欢挖的深层问题。

1.3 从热搜词看当前社区的关注重点

把热搜词整体扫一遍，有几个信号值得注意：一是“rag知识库指标有哪些”“rag测评怎么做”这类评估类问题热度很高，说明很多人已经过了“能跑通”的阶段，开始关心“怎么证明它真的好用”；二是“ontology rag”“graph rag”“agentic rag”这些进阶概念频繁出现，意味着单纯拼向量相似度的做法已经满足不了复杂业务；三是“针对3gpp协议的rag”“银行rag”这种垂直场景词出现，说明RAG开始进入对准确性要求非常高的行业。这篇文章后续会重点覆盖这三个方向。

2. 向量化流程中那些决定成败的细节

2.1 切分策略比Embedding模型选择更影响效果

很多新手在做RAG时，把大部分精力花在挑选Embedding模型上，这其实是个误区。向量模型的差异在同等量级下通常不会特别悬殊，真正能拉开差距的是文本切分方式。热词里专门有“rag向量化流程”，可见大家对这块的困惑程度不低。

先看切分粒度的问题。按固定字符数硬切（比如512字符一段）看起来简单，但很容易把一句话拦腰截断，或者把一个完整的业务表格碎片化，导致检索出来的片段语义不完整。我比较推荐的做法是结构化切分优先：Markdown或HTML文档优先按标题层级切，PDF优先按段落边界切，代码库优先按函数或类切。这样切出来的每个片段本身就是“一个意思完整表达”，检索命中率会明显提高。

再看切分之后的“单元粒度”问题。有些场景下需要把多个小片段合并成一个更大的上下文单元。比如一份合同涉及甲方义务、乙方义务、违约责任三个板块，如果切成三块分别向量化，检索“如果乙方延迟交付该怎么办”时可能只召回违约责任那一块，缺少必要的上下文。这时候可以做“父文档召回”：先用小子块匹配向量相似度，命中后返回其所属的完整父文档作为上下文喂给模型。这是工程上非常实用的技巧。

2.2 召回数量、重排序和Dense Vector的配合

召回阶段直接返回Top-K个相似片段然后拼给模型，这种方案在小规模Demo里能用，真实项目里基本跑不通。原因很简单，向量相似度高不等于语义相关性高，尤其当文档库里存在大量相似表述时，排在前面的几个片段很可能讲的是同一件事的不同变体，信息冗余会让模型抓不住重点。

我的经验是走“召回+重排序”的两段式流程。第一段用Dense Vector Search（也就是热词里反复出现的dense vector search）召回30到50个候选片段，保证召回率；第二段用交叉编码器类的重排序模型对候选片段做精细化打分，取前3到5个作为最终上下文。重排序模型比双塔结构的向量模型更精细，代价是速度慢，所以只对第一段召回的小候选集跑，性能完全扛得住。

还要注意一个很多人忽略的细节：重排序之后的得分是不能跨查询直接比较的，不同查询的得分分布可能差异很大。所以不要试图设定一个全局阈值来决定“多少分以上才输入给模型”，而是固定取Top-N个片段更稳妥。

2.3 索引更新与数据版本管理

RAG系统上线后最容易被忽视的是索引更新问题。文档库不是静态的，合同会改版、产品文档会新增、公告会删除，如果索引不跟着变，模型会一直基于旧内容在回答。增量更新的方法是记录每个文档的哈希值或版本号，检测到变化后只对该文档涉及的切分块重新Embedding并更新向量库。

这点在银行这类真实业务场景中特别关键。热词里有“银行rag”，金融行业对数据一致性和合规审计要求极高，如果你不能说明当前模型回答用的到底是哪一版文档，审计根本没法定论。所以从设计一开始就要给每个片段打上文档来源、版本号、入库时间标签，这样才能在输出答案时附上可靠的引用链路。

3. RAG和Agent结合的三种主流形态

3.1 最简单的形态：RAG作为Agent的工具

第一种形态是把“检索增强问答”整体封装成一个工具，Agent在规划时决定是否需要调用检索工具，检索结果返回后由Agent整合成最终回答。这种方案适合任务本身以对话为主、偶尔需要外部知识的场景。

实现上有个很重要的设计点：工具的Description要写清楚“什么时候该调用、什么时候不该调用”。LLM的工具调用依赖对工具描述的语义理解，如果你的工具描述写得太宽泛，Agent会在每个问题上都先检索一遍，浪费大量时间和Token；写得太狭窄又会在真正需要时漏掉调用。我会在描述里明确说明“当用户询问政策、流程、规格、合同相关内容时使用本工具，涉及简单问候或通用常识时不要使用”。

3.2 agentic RAG：让模型自己决定怎么查

热词里的“agentic rag”是今年讨论度很高的方向。它的核心区别是：传统RAG不管问题多复杂都只做一次查询，而agentic RAG让模型根据问题自动拆解出多个子查询，甚至决定查询哪个数据源。

举个实际项目里的例子，用户问“对比一下A产品和B产品在功耗、价格、开发难度上的差异”，传统RAG会拿整个问题去做一次向量检索，结果很可能只召回偏A或偏B的片段。agentic RAG的做法是把问题拆成若干个子问题，分别检索相关信息，再由模型汇总对比。这种方案对复杂问题提升效果非常显著，但代价是需要更精细的提示词来约束拆解逻辑，同时对Token消耗也更敏感。

实现agentic RAG时我建议不要一上来就追求全自动。先用带固定框架的提示词，让模型基于“FACT-CHECK和SUBQUERY两种模式”做决策：需要事实核实时走检索子流程，需要多维度回答时先输出子查询列表，再并行查找。跑稳之后再逐步放开自由度。

3.3 进一步升级：从Graph RAG到Ontology RAG

Graph RAG和Ontology RAG本质上都是想解决同一个问题：纯向量检索抓不住实体之间的多跳关系。比如“这个漏洞影响了哪些产品线？这些产品线的哪些客户群体风险最高？”如果文档里没有直接出现完整句子，向量检索很难通过语义相似度把这条关系链拉出来。Graph RAG的做法是先构建知识图谱，把实体和关系存成节点和边，检索时借助图遍历能力找到多跳关联。

Ontology RAG则更进一步，不只是实体关系，还把领域概念体系、属性约束和逻辑关系也构建进来。热词里“ontology rag”单独占了一条，说明关注的人已经不少。实际做的时候，我建议从轻量起步：用LLM从文档中抽取实体关系对，存入图数据库（比如Neo4j），检索时混合使用向量相似度和图遍历结果。不要一开始就想构建一个完美的领域本体，那是一个会在评审阶段永远完不成的艺术品。

4. 测评不是走形式，指标要能指导改进

4.1 该看哪些指标：检索质量与生成质量要分开评

热词里有“rag测评怎么做”“rag知识库指标有哪些”，这确实是个特别容易被糊弄过去的环节。我见过太多项目在汇报时说“准确率85%”，细问之下发现这个准确率只是“模型自认为答案正确”，完全没有量化检索质量。

一个可靠的RAG评估体系应该分成两层。第一层是检索质量：命中率（正确答案有没有进召回列表）、MRR（第一个正确答案排在第几位）、NDCG（排序质量）。第二层是生成质量：忠实度（答案是否完全基于检索到的上下文）、相关性（答案是否在回答用户问题）、完整性（是否覆盖问题所有方面）。两层分开测，才能定位问题到底出在检索环节还是生成环节。

4.2 评估数据集怎么构建

评估数据集的构建质量直接决定测评结果是否可信。最笨但最有效的方法是：从真实业务里抓取高频问题，然后人工标注参考答案以及命中的文档片段。一个项目准备100到200条高质量测试样本远比自动生成5000条噪声数据有价值。

如果预算有限，退而求其次的做法是用LLM生成初稿，再由人工基于文档修正。要注意的是，评估集需要覆盖边界情况：单文档可回答的简单问题、跨文档需要整合的复杂问题、完全没出现在知识库中的超纲问题。最后一种尤其重要，它测试的是“系统在不知道时能不能诚实说不知道”，这是RAG区别于纯生成模型的关键优势。

4.3 从指标到改进：一个排查实例

我做过一个合同问答项目，初期忠实度指标只有六十多分，症状是模型经常把合同A的条款安到合同B上。先测检索质量，发现MRR其实还行，说明正确答案基本能召回，但Top-1经常不是正确答案。加装重排序模型后，忠实度提升了十几个百分点。

后来又有新问题：涉及金额比较的问题会漏数据。排查后发现是切分时把表格拆乱了，金额数字和产品名称被切到了不同片段。改成表格按行切分后，问题彻底解决。这个案例想说明的是，评估指标体系的意义在于帮你定位问题环节，而不是给你一个用来汇报的“好看分数”。

5. 从零搭建时的技术选型和避坑经验

5.1 框架选择：LangChain、Spring AI还是自研

热词里有“langchain rag”也有“java rag”“spring ai 2.0 rag实例”，说明Java技术栈在RAG项目里的需求非常大。框架选择的逻辑很简单：如果是快速验证想法，LangChain最方便，组件丰富、社区案例多，半天就能跑通一个Demo；如果是在大型Java企业里做正规项目，建议直接用Spring AI 2.0，它能让你以Spring生态的方式管理大模型调用、向量库连接和Agent流程，团队维护成本低很多。

但如果项目涉及到非常定制化的评估流程、特殊的权限体系或者复杂的多数据源联动，我不太建议完全依赖重量级框架，而是用框架处理基础链路，核心逻辑自己封装。框架的好处是快速启动，框架的坏处是你得跟着它的抽象走，等你想做点超越框架假设的事情时，改造成本会很高。

5.2 向量数据库选型视角

选向量数据库时，别光看榜单上的Recall数字，更要看运维成本、权限体系和生态成熟度。小项目用开源的Chroma或Qdrant足够，数据量到了千万级别以上可以考虑Milvus。企业级项目如果已经有ES基础设施，直接在ES里加向量检索能力可能比另起炉灶更划算，毕竟运维一套分布式组件的人力成本很高。

还要特别提醒：合规背景下数据不能出内网的项目，一定要确认向量数据库支持纯内网部署和细粒度权限控制，热词里的“银行rag”对这一点的要求几乎是一票否决制。

5.3 Embedding模型的实践心得

选Embedding模型的第一原则不是“排行榜最高”，而是“在你的领域数据上表现好”。通用场景用BGE、M3E这类中英文效果都不错的模型能省心不少；垂直领域（比如3GPP协议这种专业文档）如果想追求更高精度，可能需要基于领域语料做微调——不过前提是你的标注数据量足够，否则微调带来的提升可能非常有限。

一个容易被忽略的细节是：查询端和文档端可以用不同的Embedding模型或不同的指令前缀。很多模型（比如BGE系列）会在文档侧加“为这个句子生成表示以用于检索相关文章”的后缀，查询侧加“为这个句子生成表示以用于检索相关文章”，两侧策略不对称能显著提升检索效果。这个细节不少人不知道，实测收益很明显。

6. 聊几个新方向：Agent能力边界和2026年趋势

6.1 AI Coding Agent是不是被过度炒作了

热词里出现“ai coding agent 2026年8月 最新进展”，说明不少人在关注AI编码Agent。我的真实体会是，AI Coding Agent目前在“生成单元测试”“写样板代码”“解释陌生代码库”这些场景下确实能用，而且效率翻倍；但要让它独立负责一个需要强上下文理解、跨模块设计决策的完整功能开发，可靠性还远远不够。它的定位更接近“高级结对编程助手”，而不是“替代程序员”。

6.2 企业落地RAG/Agent时容易被忽略的“最后一公里”

很多RAG项目在评测阶段指标很好看，一上生产就崩，原因大多出在“最后一公里”：权限控制、数据更新、可观测性、成本控制。比如一个知识库里有不同部门的数据，如何保证模型不会把A部门的保密数据泄露给B部门的提问者？这在纯RAG架构里要靠检索前的权限过滤和检索后的内容再校验双重保障，但大多数Demo项目压根没考虑过这个层面的问题。

6.3 我对AI Agent 2026年发展趋势的看法

我个人判断，接下来一到两年几个方向会比较明显的趋势：

• 评估优先于模型：“哪个模型更强”这个问题的热度会下降，“如何科学评估业务效果”会变成更核心的议题
• 超长上下文和RAG互补而非替代：模型上下文窗口越来越长，但RAG在成本、可溯源、权限控制上的优势不会因此消失，两者会走向混合架构
• 标准化协议：MCP这类工具调用协议会逐渐成为Agent生态的事实标准，工具接入成本会大幅下降
• 可靠性和防幻觉将成为核心卖点：在严肃场景（金融、医疗、法律）里，谁能把幻觉率压得更低，谁就能拿下市场

这些方向其实从热搜词里就能看出端倪：大家已经在从“怎么搭一个RAG”转向“怎么把它做到专业可靠”。对刚入门的朋友我的建议是，先跟着这篇文章把RAG的向量化流程、检索评估闭环跑一遍，再逐步引入Agent行为规划，最后再考虑Graph或Ontology这些进阶方向。按这个顺序走，你不会被概念绕晕。

7. 最后分享几个实操中的小经验和习惯

在多个RAG项目落地之后，有几个习惯我一直保持，对避坑很有帮助。

第一个习惯是所有检索结果一律先看“原始命中片段”，不要只盯着最终答案。很多时候模型答错了，往下一查原因特别简单：检索回来的Top-1片段本身就是无关内容，或者内容对但排序放得太靠后。这种问题一眼就能定位，比反复调整提示词有效得多。

第二个习惯是给每个查询打上日志，记录检索命中率、重排序得分、模型输出完整内容。哪怕项目还在开发阶段，这些日志也是排查问题的金矿。等到上线后如果用户投诉回答质量，你有日志就能快速回放当时发生了什么，没有日志就只能靠猜。

第三个习惯是“先跑通，再优化，最后抽象”。很多团队卡在第一步太久，总希望架构一步到位、评估体系一步建全、Agent规划一步做到完全自主。但AI项目的特点就是不确定性极高，你花两周精心设计的Agent规划框架，实际跑起来可能发现用户根本不会那样提问。所以先以最快速度跑出一个小闭环，用真实数据驱动迭代，比任何精心前期的架构设计都更有价值。

RAG和AI Agent的组合目前仍然是一个“上限很高、下限很低”的领域。下限低，是因为很多人拿一套简单代码就去应付复杂业务问题；上限高，是因为优化空间巨大——无论检索质量、评估体系还是Agent规划策略，都有大量可以深挖的细节。希望这篇文章让你们少走一些弯路。