企业官网建设流程全解析

P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看， 传送门https://blog.csdn.net/HHX_01

前言

大模型很聪明，这点我不否认。但它聪明得很"局部"：你问它"公司退款几天到账"，它敢根据训练数据给你编一个答案，语气比你们老板还笃定。

所以有了 RAG（Retrieval-Augmented Generation，检索增强生成）。说白了就一句话：让模型在回答之前，先翻书，再答题。

你把它理解成开卷考试就行：普通大模型闭卷，全靠记忆硬扛；RAG 是给模型递小抄，先查资料，再照着资料写答案。

1. 一句话理解 RAG

核心流程长这样：

用户提问 → 从知识库检索相关资料 → 筛选出少量可靠原文 → 问题和原文一起交给大模型 → 大模型生成答案

注意，它既不是重新训练模型，也不是把整个知识库打包发给模型。真要把整库都塞给模型，破产的不是模型，是你的 Token 余额——按字收费的知识库，是给家里有矿的人准备的。

2. 先看大局：RAG 就俩阶段

离线阶段：把知识库建好；在线阶段：检索资料并生成答案。

一个负责囤货，一个负责卖货。中间要是断了档，前面囤再多也是库存积压。

3. 离线阶段：知识库是怎么建成的

3.1 解析原始资料

企业里的数据来源五花八门：PDF、Word、Excel，产品说明和操作手册，内部 Wiki，数据库记录，客服 FAQ，网页和接口。

系统要做的，是把正文、标题、表格和层级关系提取出来，同时把页眉、页脚、导航栏和重复内容这些噪声清掉。

这一步很重要：输入是错的，后面模型再强也白搭。这就跟你炒菜一样，食材都馊了，就别怪大厨手艺不行。

3.2 把长文档切成 Chunk

一份几十页的文档，一般不会整体存成一个检索单元，而是拆成多个文本片段，也就是 Chunk。比如：

退款规则.md Chunk 1：退款申请条件 Chunk 2：退款审核流程 Chunk 3：退款到账时间 Chunk 4：特殊情况处理

为什么要切？两个原因：一个问题通常只跟文档里的一小部分有关；整篇塞进模型上下文，既浪费 Token，又稀释重点。

但 Chunk 不是越小越好。切太小，语义不完整；切太大，无关内容跟着混进来。这跟切西瓜一个道理：切太小全是皮，切太大一口塞不下。切分策略直接决定 RAG 的最终效果，属于那种"看着不起眼、翻车全怪它"的环节。

3.3 给每个 Chunk 加 Metadata

除了原文，每个 Chunk 通常还带点元数据：

{"documentId":"refund-policy-2026","title":"退款到账时间","department":"finance","tenantId":"1001","securityLevel":2,"updatedAt":"2026-09-01"}

这些东西用来干嘛？用户权限过滤、租户隔离、按部门检索、排除过期文档、展示答案的引用来源。

说句实在话：生产环境里，权限过滤的重要性往往不低于检索准确率。你答得再准，把 A 部门的工资单答给 B 部门，第二天你面对的可能就不是代码评审，而是检讨书评审。

3.4 用 Embedding 模型生成向量

Embedding 模型会把文本转换成一组数字：

"退款一般在 3～5 个工作日到账" ↓ [0.018, -0.231, 0.764, ...]

这些数字表达的是文本的语义特征。语义相近的内容，在向量空间里的距离通常也比较近。所以下面三句话文字不一样，但可能被检索到一起：

退款多久到账 退款到账时间 退款几天能收到

说白了，Embedding 就是把文字翻译成坐标。模型可能看不懂中文，但它知道这两句话"住隔壁"。

但注意：Embedding 向量不是答案，也不代表模型学会了这段内容。它只是帮你把语义相近的文本捞出来。

3.5 写入向量数据库

最终存进去的通常不只是向量，而是：

向量 + 原始文本（或文本 ID）+ 文档来源 + 权限信息 + 其他 Metadata

到此，离线知识库准备完毕。接下来轮到在线阶段表演。

4. 在线阶段：用户提问后发生了什么

假设用户问了一句：退款需要多久才能到账？

4.1 客户端只负责提交问题

客户端一般只提交这些东西：

{"question":"退款需要多久才能到账？","conversationId":"c-123"}

同时携带用户登录凭证。

客户端不应该：下载整个知识库、自己过滤知识库内容、保存模型或知识库密钥、决定用户有没有权看某份文档。

这些活儿都应该在服务端干。客户端就是个传话筒，你可以让它传话，但别让它当家。真让它自己过滤知识库，它连自己是哪个版本的程序都说不清楚。

4.2 服务端先处理一遍问题

RAG 后端收到问题后，可能先做：错别字修正、指代消解、多轮对话补全、查询改写、关键词提取、租户和用户权限解析。

举个例子，用户追问：那节假日呢？

系统会结合上一轮对话，把它改写成：退款在节假日期间需要多久才能到账？

这个环节相当于给问题"补全主语"。不然模型收到一句"那节假日呢？"，很可能以为你在问它今天放不放假。

4.3 把问题转换成查询向量

"退款需要多久才能到账？" ↓ Query Embedding

然后用查询向量去知识库里找距离较近的文档向量。

4.4 召回候选资料

向量数据库可能返回类似这样的结果：

0.92 退款一般在 3～5 个工作日到账 0.86 节假日期间退款可能顺延 0.78 退款申请提交后进入审核 0.61 发票通常在订单完成后开具

这个阶段通常会适当多取一些，比如 Top-K 取 20 条。原因很简单：初次检索讲究"宁滥勿缺"，后面还有层层筛选等着呢。

有些系统还会同时跑关键词检索。向量检索擅长语义相近，关键词检索擅长编号、名称和专业术语。两者结果合并，就是混合检索。

5. 相似度不会直接生成答案

这是 RAG 里最容易误解的地方，我必须单独拉出来讲。

相似度的作用是：决定哪些资料更值得交给大模型阅读。它并不直接决定最终答案怎么写。

相似度检索 → 选择参考资料 大模型 → 阅读参考资料并生成答案

相似度是 0.92，不意味着模型会按 92% 的权重抄这句话。这个分数只是给候选资料排序用的，相当于老师批卷前先按名字排个序——排前面的不一定分高，分高的也不一定排前面。

最终答案仍然是模型根据 Prompt，一个字一个字"猜"出来的。

6. 为什么还需要过滤和 Rerank

向量检索快是快，但初次返回的内容不一定准。所以候选资料还要过几道关。

6.1 权限过滤

用户所属租户必须匹配 用户部门必须具备访问权限 文档安全等级不能超过用户等级

权限过滤必须在资料发给模型之前完成。否则，就算页面没展示敏感引用，敏感内容也已经进过模型了。这就像你把工资单递给同事看了一眼再收回来——收回来也没用了，人家已经看到了。

6.2 Metadata 过滤

系统还能限定：只检索当前产品、只检索已生效的规则、排除过期文档、只查指定业务类型。相当于给检索加了一堆"硬性条件"，不符合的直接出局。

6.3 Rerank 重排

Rerank 模型会把用户问题和每个候选片段放在一起，重新判断相关性。典型流程：

向量数据库快速召回 20 条 ↓ Rerank 精确重新排序 ↓ 选择最终 3～5 条

你可以把向量检索理解成海选，把 Rerank 理解成决赛。海选的时候谁都能上，决赛的时候评委把明显凑数的全刷掉。

7. 最终发送给大模型的到底是什么

系统不会把整个向量数据库发给模型。一般只发：系统回答规则、用户问题、筛选出的少量原文、必要的对话历史。

比如这样：

系统规则： 你只能根据参考资料回答。 如果参考资料不足，请明确回答无法确定。 回答时标注资料编号，不要自行补充业务规则。 用户问题： 退款需要多久才能到账？ 参考资料： [1] 退款审核通过后，一般在 3～5 个工作日到账。 [2] 如遇法定节假日，到账时间可能顺延。

模型最后生成：退款审核通过后，一般会在 3～5 个工作日到账；如遇法定节假日，到账时间可能顺延。[1][2]

所以更准确的说法是：服务端先筛好"指定阅读"，模型再照着组织答案。不是把图书馆搬过去，而是递上几页重点，还贴好了标签。

8. 各个组件分别负责什么

组件	主要职责
客户端	提交问题、携带用户凭证、展示答案和引用
业务后端	鉴权、检索编排、Prompt 组装和异常处理
Embedding 模型	将问题或文档转换为语义向量
向量数据库	快速召回相似的候选资料
Rerank 模型	对候选资料进行更精确的重新排序
大模型	阅读最终原文并生成答案

简单概括：后端负责调度，向量数据库负责初筛，Rerank 负责精选，大模型负责写作文。你负责验收，以及验收时血压升高。

9. 用伪代码看一次完整调用

不考虑具体框架，一次问答大致长这样：

Stringquestion=request.question();// 解析用户、租户和文档权限。AccessScopescope=permissionService.resolve(request.userId());// 从知识库中召回较多候选资料。Listcandidates=knowledgeBase.search(question,scope,20);// 删除无权限、已过期或者分数过低的资料。Listfiltered=documentFilter.filter(candidates,scope);// 对候选资料重新排序，并取最终五条。Listcontext=reranker.rerank(question,filtered).stream().limit(5).toList();// 没有可靠资料时停止回答，避免模型猜测。if(context.isEmpty()){return"现有资料不足，暂时无法确定。";}// 将规则、问题和原文组装成 Prompt。Promptprompt=promptBuilder.build(question,context);// 调用大模型生成最终答案。Stringanswer=chatModel.generate(prompt);// 返回答案以及对应的文档来源。returnresponseBuilder.build(answer,context);

这段代码体现了 RAG 的本质：

Retrieve：检索资料 Augment：把资料加入上下文 Generate：模型生成答案

三个词，一套流程，外面包装得再花哨，内核就是这么回事。

10. RAG 最容易翻车的七个地方

10.1 文档切分不合理

标题和正文被拆开，或者一条业务规则被切成几个不完整片段，检索结果就算看着相似，也可能答非所问。就像把"请勿践踏草坪"切成"请勿"和"践踏草坪"，路人看了可能更兴奋。

10.2 只用向量相似度

专有名词、错误码、订单号、精确编号，这些更适合关键词检索。所以生产系统基本都是混合检索。纯向量检索碰到订单号，就像让老外念你的身份证号，念得挺流畅，但一个都不对。

10.3 没有权限过滤

只追召回率、不带权限，就可能越权访问和数据泄露。检索系统漏一条资料顶多被骂，权限漏一条资料可能就得走流程了。

10.4 检索多少内容都塞给模型

内容太少可能漏答案，内容太多增加成本、延迟和干扰。Top-K 和最终 Top-N 应该拿测试集评估，而不是拍脑袋定。毕竟你拍脑袋定出来的数，最后大概率会拍到自己脸上。

10.5 没有拒答机制

资料不足还硬让模型回答，结果就是一本正经地编。一个靠谱的 RAG 系统，应该允许回答：根据当前知识库资料无法确定。

会拒答的模型才是好模型。硬编出来的答案，发出去是痛快，删帖的时候就不痛快了。

10.6 知识库没有及时更新

RAG 能读新知识，不代表它会自动知道知识变了。文档新增、修改、删除，都得同步更新索引。不然你以为它答的是新政策，其实它背的还是去年的旧课文。

10.7 不记录检索过程

出错的时候你得知道：用户原始问题是什么、改写后的查询是什么、召回了哪些片段、每条资料的分数是多少、最终给模型发了什么、模型引用了哪些资料。

不然问题一出来，你只能对着日志干瞪眼，像极了考试查分时发现分数不对，但卷子早被收走了。

11. 怎么评价一个 RAG 系统

RAG 不能只看"回答听起来是否自然"。至少得分开评估三块。

11.1 检索质量

正确资料有没有被召回、无关资料多不多、正确资料的排名够不够靠前、权限过滤对不对。

11.2 生成质量

答案有没有参考资料支持、有没有添加资料里不存在的内容、引用准不准、资料不足时有没有正确拒答。

11.3 工程指标

接口耗时、Token 消耗、知识库和模型调用成功率、超时降级和重试情况。

重点是：检索错误和生成错误必须分开定位。模型答错了，不一定是模型菜，也可能是系统根本没给它正确资料。这就跟外卖难吃一样，别急着骂骑手，也可能是后厨压根做错了菜。

12. 总结

RAG 不是什么神秘的新模型，它是一套"检索、上下文组装、模型生成"的工程流程。完整链路可以归纳成：

文档解析 → 文本切分 → Embedding → 向量入库 → 用户提问 → 相似度召回 → 权限过滤 → Rerank → 选择少量原文 → 组装 Prompt → 大模型生成 → 返回答案和引用

记住几个关键边界：

客户端只提交问题，不负责过滤知识库；相似度负责选资料，不直接生成答案；模型只接收筛选后的少量原文，不会读整个向量库；RAG 后端负责鉴权、检索编排、上下文组装和异常处理；资料不足时，靠谱的系统应该拒绝猜测。

一句话收尾：RAG 干的事，就是让模型学会"先翻书再答题"。书翻好了，答案自然稳；书没翻好，模型再聪明也是巧妇难为无米之炊。

P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/HHX_01