企业官网建设流程全解析

上个月和一个做内部知识库的同事聊天，他开玩笑说：大模型像个无所不知的优等生，你问他开放问题，他能答出全世界的百科，唯独说不出你们部门刚更新的报销流程。这句话背后的痛感太真实了。静态参数化的模型，知识截止在训练集，内部业务信息一个字都没见过。要让它回答私有域的问题，最直接的路不是重新训练，而是让它在生成答案之前先去查库、再去组织语言，这条路就是 RAG（Retrieval-Augmented Generation，检索增强生成）。

RAG 不是新词，2020年左右就有学术团队把检索和生成拼在一起做开放域问答，但最近这一轮讨论明显走出了论文圈子，变成每个做知识库、做客服助手、做行业问答的人都要评估的候选方案。这篇内容不打算铺开讲浮在表面的概念，而是把架构演进的几个关键节点、真正落地时绕不开的核心模块，以及我自己在排查问题时的完整思路拆开来说。适合正在做 RAG 选型、已经搭上线但效果不理想、以及想搞清楚“为什么别人说 RAG 好用”的朋友参考。

1. 为什么 RAG 会在这一轮爆发：它解决的是模型的三个硬伤

1.1 闭卷考试和开卷考试的区别

很多人第一次接触 RAG 时会觉得，这无非是“搜索出来塞给模型”，没什么技术含量。但理解 RAG 的价值，最好先理解大模型生成答案的模式。传统大模型是闭卷考试：所有知识都存在于训练时固化下来的参数里。你输入问题，模型根据参数里的隐性知识现场作答。问题在于闭卷考试有三个天然短板——知识陈旧、缺乏私有数据、容易凭印象编造。

知识陈旧好理解，训练语料往往滞后数月甚至数年。缺乏私有数据则更致命：企业内部的操作手册、项目复盘、客服话术，几乎不可能大规模进到预训练语料里。最容易出问题的其实是第三个短板：模型在遇到不熟悉的内容时，不会老老实实说“不知道”，而是会调用相似记忆片段拼接出一个看起来像模像样的答案，这就是幻觉。

RAG 相当于把闭卷考试改成开卷考试。模型不是凭记忆硬写，而是先从外部知识源里检索出若干相关段落，把这些段落作为上下文参考，再结合问题给出答案。这样一来，知识来源从静止的参数变成动态的索引，私有数据可以随时入库，答案也更容易溯源。

1.2 一个最小可行示例帮你建立直觉

我用一个简化流程说明 RAG 在做什么，这个流程在后续章节还会反复出现。假设你要回答“2024年公司差旅补贴标准是多少”，传统做法直接问模型，模型可能完全不认识这家公司。RAG 的做法分四步：

1. 把公司制度文档切片存入向量库，预先构建索引。
2. 用户提问时，把问题转换成向量，去库里做最近邻搜索。
3. 拿到分数最高的几段，和原始问题一起拼进提示词。
4. 模型根据拼好的上下文生成最终答案，并在答案后给出引用来源。

这个流程把“检索”和“生成”串成一个完整链路，因此叫检索增强生成。它的前提是：检索系统确实能找到相关内容。如果搜出来的是无关段落，那么生成阶段怎么补救也无济于事。所以在后续讨论中，我会反复回到一个核心判断：RAG 系统的上限，首先由检索质量决定，其次才是生成策略。

1.3 它能落地的场景比想象中宽泛

RAG 能爆发，不只是因为概念优雅，而是因为它覆盖了相当多实际业务诉求。最典型的是企业知识库问答，把分散在文档库、Wiki、工单记录里的信息统一变成问答入口。第二类是客服助手，用历史客户对话和商品文档辅助回答，减少人工介入。第三类是行业情报和合规审查，需要对照最新法规、行业报告给出可引用的判断，而不是纯粹依赖模型记忆。

还有一个容易被忽略的场景：开发者用它做数据脱敏后的内部研发文档问答。研发团队经常有大量设计文档和技术方案散落在不同仓库，模型训练时完全没见过，新人入职后靠 RAG 就能直接检索历史决策背景。这个场景的价值不在于单次回答有多惊艳，而在于让组织积累的知识真正流动起来。

2. 架构演进：从“搜索然后拼接”到“按需调度的智能体”

2.1 第一阶段：朴素的检索-拼接范式

RAG 最早期的形态，我习惯叫它“朴素 RAG”。它的逻辑非常直白：拿到问题，去向量库搜，取前 k 条结果，拼成一段长上下文，扔给模型生成。这个范式能跑通，但在真实场景里会暴露出大量问题。

问题出在三个环节。第一，用户的真实提问往往模糊，比如“这个功能线上出故障了怎么办”，如果不做意图改写，直接用原始语句去向量检索，召回出来的片段相关性很低。第二，固定取前 k 条可能导致关键信息落在第 k+1 条被漏掉，取多了又会把无关信息塞爆上下文。第三，原始顺序直接决定了模型阅读顺序，而向量检索返回的结果是无序的，模型看到一段不连贯的段落拼盘，理解力会明显下降。

我早期做这类实验时经常遇到一种诡异情况：检索结果明明命中了一句话，但生成的答案就是不用它，反而去自由发挥。后来定位到原因是上下文顺序太乱，模型把检索段落当成了可有可无的背景噪音。这个现象是朴素 RAG 效果不稳定的重要来源。

2.2 第二阶段：模块化 RAG，把链路拆开逐个优化

针对朴素 RAG 的短板，工程社区很快演化出模块化 RAG。它的核心思路是：不再把检索和生成当作两个黑盒，而是把链路拆成查询改写、路由判断、多路召回、重排、上下文压缩、生成约束等多个可独立优化的模块。

以查询改写为例。用户在问“最近的数据同步为什么老是延迟”时，如果直接把这句话交给向量检索，效果可能一般，因为“最近”不是语义特征。常见的改写策略包括：

• 问题补全：把口语化问题补充成更完整的陈述句。
• 同义扩写：将关键实体扩展出多个说法，提高召回覆盖面。
• 子问题拆分：把复合问题拆成几个独立子问题分别检索。

通过这些策略，检索阶段的输入质量被显著提高。模块化 RAG 的另一个重要组件是重排。向量检索擅长做语义联想，但对精细的相关性排序不够敏感。通常做法是先靠向量召回候选集，再用交叉编码器或更精细的排序模型对候选集重新打分，从而把最相关的片段顶到最前面。重排这个动作虽然多了一次计算，但在真实场景中带来的准确率提升非常可观。

模块化 RAG 最大的价值是把“能用”推向“好用”。每一处信号损失都有对应模块去补偿，整条链路从单一管道变成一组可替换、可测试的工具链。

2.3 第三阶段：智能体化和增强型检索

再往后演进，RAG 不再是写死在代码里的四条流水线，而是变成大模型驱动的智能体能自主调用的一组工具。我把它称为“按需调度的 RAG”。在这种架构里，模型不只是在最后一步生成答案，而是先观察任务，决定该不该检索、该检索哪些系统、是不是要检索多轮。

举个例子。用户问：“对比一下 A 方案和 B 方案在容灾能力上的差异，并给出我们的历史选择偏向。”朴素 RAG 可能只做一次检索就开答。智能体化 RAG 会先把问题拆成 A 方案容灾、B 方案容灾、历史决策记录三个子任务，分别路由到对应索引，拿到结果后再做汇总判断；如果首轮检索结果不足，它还会用已有信息构造二次查询继续补充。类似“规划-检索-反思-再检索”的循环在较复杂问答里表现明显更好。

这个阶段还出现了把图谱结构和向量检索结合的做法，通过实体关系扩展上下文，解决多跳推理问题。向量检索适合语义相关性，知识图谱适合结构路径，两种手段组合能够覆盖更多类型的问题。演进到这里，RAG 已经从“一个工具”变成“一组能力组件”。

我把三个阶段的差异整理成一个对照表：

这张表也说明了一个原则：演进不是代码层面的简单替代，而是把复杂度从提示词里挪进可控的系统模块中，让每一层都可以单独观测和优化。

3. 一个生产级 RAG 系统绕不开的核心要点解析

3.1 切分策略：手感很像切菜，切得太粗太细都不行

很多人做 RAG 的第一个失败项目，不是死在模型选型，而是死在切分（chunking）。切分决定了一个文档片段里包含多少上下文。如果切得太小，比如一行一行切，检索时很难找回完整的语义单元；如果切得太大，比如整篇文档一个片段，向量之间互相稀释，检索准确率同样下降。

我给一个常用的经验尺度：普通叙述性文档，500到1000字左右是安全区间；技术手册和操作步骤，可以按 Markdown 标题结构切，保证每个片段逻辑完整；表格类内容最好整体保留，因为表格一旦被切断，语义就碎掉了。

更讲究的做法是重叠切分。相邻两端保留50到100字的重叠，可以在检索命中后片段时，让下一片段仍然携带上文信息，防止信息被硬切边界截断。我见过不少案例，仅仅引入重叠切分，就显著改善了中段信息的召回率。

3.2 索引层：向量不是万能的，混合检索才更稳

切分完成之后是 Embedding（向量化）。近两年几乎每隔一段时间就有新的向量模型发布，它们的通用能力确实在变强，但选型时还要注意领域贴合度。财务政策和医学文献的语义空间差异很大，通用向量模型未必能精准区分术语细节。有条件的话，用一批本领域问答对做一次小规模评测，比盲目追新版更有价值。

向量检索擅长语义相近，但有时过度“语义化”反而丢失关键词命中。比如搜“服务不可用”，用户可能期望精确看到“HTTP 503”相关日志，语义检索却可能召回一堆关于可用性设计的宏观讨论。这时候就需要混合检索：同时跑关键词检索和向量检索，再把两路结果做融合排序。

融合排序的核心是分数归一化。关键词检索和向量检索的分数不在同一个尺度上，不能直接相加。常用做法是先用排名位置转换成倒数排名，再按权重加权，比如取 K=60 做倒数融合，也可以给两路分别设置权重，通常向量略高于关键词。条件允许的话，在切分片段上记录标题层级，还可以在融合时给深层次小节加权，让更具体的片段优先上浮。

3.3 重排与上下文组装：决定模型“真正读到什么”

检索完成只是第一步，如何把候选片段交给模型，直接决定最终输出质量。我强烈建议在向量检索之后加一个专门的重排阶段。重排模型比向量检索更精细，可以把明显不相关的结果清掉，把真正命中的片段顶到最前面。代价是推理时间更长，所以一般只对前 50 到 100 个候选做重排，而不是全量重排。

上下文组装也有门道。不要把检索段落简单按顺序堆上去。较好的做法是：

1. 去重，把重复表达的片段合并。
2. 对候选片段按相关性降序排列，并按来源文档聚类，避免同一文档的多段内容打乱次序。
3. 在每段前加上小标题或元信息，例如“来源：xx文档，章节：xx”，帮助模型理解上下文边界。
4. 严格控制放入提示词的 token 上限，超出的部分必须截断，而不是无脑塞满。

组装顺序为什么重要？模型阅读理解有先后偏好，放在越靠前的内容权重越高。我曾经测试过：同一个检索结果集合，仅仅是调整段落顺序，答案正确率就能差出十几个百分点。这是很多人忽视的隐形杠杆。

3.4 生成与引用：让答案变得更可信，也让排查更容易

生成阶段不是简单把提示词丢给模型就完事。要让 RAG 真正为业务产生价值，必须建立可追溯的引用机制。实现方式是在提示词里明确要求“只基于以下上下文回答，并在句子末尾标注对应片段编号”。模型输出时，我们可以建立答案句子与检索片段之间的映射关系。

这样做有两个直接好处。对用户而言，每条关键语句都能溯源，信任度大幅提升。对开发者而言，当出现幻觉或错误答案时，可以快速定位是检索不到信息，还是检索到了但模型没正确理解，还是生成阶段胡编。引用机制是把 RAG 从玩具变成生产工具的一个关键设计，不能省略。

3.5 评估与观测：没有指标体系的 RAG 就是盲人摸象

最后但往往最容易被忽略的是评估。很多人搭完链路之后凭感觉判断效果，然后陷入无休止的改参数循环。正确做法是准备一批带标准答案的评测题，自动跑一遍，输出几个关键指标：检索阶段看召回率、命中位置；生成阶段看忠实度、答案正确性、引用覆盖率。

更进一步的观测还包括失败样本分析。定期把回答质量差的案例捞出来，看看是切分不当、检索排序靠后，还是生成时把检索内容忽略掉了。建立“指标得分 + 失败样本案例”的闭环，才能让系统持续变好。

我见过不少团队把大量精力花在调模型提示词上，结果最后发现问题的根源只是索引里某个字段没更新。有了自动评估链路，这类低级问题几分钟就能暴露。

4. 排查问题才是真正的考验：几种典型失败模式和解法

4.1 检索到的内容相关，但关键信息确实没被召回

这是最高频的失败模式，主要表现为：答案在胡编，但肉眼看去检索片段里似乎没有正确信息。排查时可以分几步走：

第一步，先看评估日志里检索返回的原始片段。如果片段里确实没有正确答案，说明问题在切分和索引。第二步，检查切分边界，看看正确答案是不是被切成了两半。第三步，尝试扩大候选集，比如从 top 5 扩到 top 20，再配合重排，看能否找回。第四步，测试关键词直查：如果关键词能搜到而向量搜不到，说明 Embedding 对专有名词的表达不够敏感，需要引入混合检索或领域相关向量模型。

这一类排查的关键是不要只看最终答案，要看检索中间结果。把链路中间变量输出出来，任何 RAG 问题都能迅速缩小范围。

4.2 关键技术点被淹没在长上下文里

另一种场景是：检索到的内容明明包含答案，但模型就是没提取出来。常见原因与上下文组装有关。一种情况是候选片段太多，模型被大量无关内容干扰；另一种情况是正确答案片段被排到了后部，被模型当成次要信息。

解法上，我通常会做三件事：第一，严格控制注入上下文的长度，只保留重排后分数最高的片段，不要迷信“给得越多越好”。第二，在提示词中明确指出优先依据前几条回答。第三，如果同一个信息散落在多个片段里，先在组装阶段做一次信息合并，把同源内容拼成一个整体段落，避免重复和碎片化。

如果上述操作都做了效果仍不好，就要考虑把问题拆小。一个复杂问题拆成多个子问题分别检索和回答，最后再整合，往往比一次塞进大上下文更有效。

4.3 检索逻辑对，但答案跨了多个跳转

还有很多问题不是简单的事实型问题，而是需要在多个文档片段之间做逻辑链推理。比如“这套系统的数据链路哪里最薄弱”就不是查一段就能回答的。朴素 RAG 面对这类问题时表现很差，因为每个片段只覆盖局部视角。

针对多跳问题，有几种策略可以叠加使用。一种是把文档中实体关系显式建模成图索引，在图结构上先做路径扩展，再和图谱结果融合。另一种是做迭代式检索：模型先根据第一轮结果判断还缺什么信息，再生成第二轮检索词，循环到信息充分为止。还有一种是引入“反思”模块，让模型对初步答案打标，确认哪些论断缺乏依据，再针对缺失部分定向补检。

这三种方法都意味着系统复杂度上升。我建议先判断业务里多跳问题占比有多高，如果占比不高一味追求复杂架构既贵又难维护。优先保障高频、简单问题稳定可靠，再逐步增强复杂问题处理能力。

4.4 想要的事实没问题，但模型仍然幻觉式输出

最诡异的情况是：上下文里白纸黑字写着答案，模型却输出了一段与上下文明显矛盾的内容。这种问题通常不完全出在 RAG 的检索层，而是生成阶段约束不足。

排查思路是：第一，确认提示词是否明确写了“如果上下文没有相关信息，直接回答未知”，别让模型有自由发挥的空间。第二，确认上述引用约束是否被模型忠实执行了，比如是否在输出中给出了对应编号，如果引用编号是凭空编的，说明生成约束已经失效。第三，检查模型温度参数，事实类任务最好降温到 0.1 到 0.3 之间，温度过高容易带来不必要的发散。

还要提一个容易被忽略的点：有些模型本身训练时使用的是指令跟随范式，如果系统提示不够强硬，模型会优先遵循用户问题而不是我们给的上文。需要把“只依据正确片段作答”写进系统提示，并且可以在 prompt 里对用户提问做隔离，让模型知道哪部分是待回答的问题、哪部分是参考资料，不能混为一谈。

5. RAG 的边界条件：什么时候该选择别的手段

5.1 静态知识且高频访问，不如先做一层缓存

RAG 的成本不低。每次请求都要先查询、再重排、再生成，链路延迟比单次生成高出不少。如果业务里的高频问题其实是固定知识，比如“退货政策是什么”，与其每次检索，不如把这类问题的固定答案做成缓存，或者在提示词里直接写死常见规则。把机械问题剥离之后，RAG 反而能专注于真正需要动态检索的复杂问题，质量和延迟都能提升。

5.2 模型自身的长上下文能力在增强，为什么还要 RAG？

近年来的大模型上下文窗口越来越大，有些人觉得可以直接把所有文档塞进上下文，不再需要检索。我认同长上下文能解决一部分问题，但也要看到三点：

一是成本呈线性甚至超线性增长，文档一多，显存和响应时间都无法接受。二是长上下文中检索不到目标信息时，模型依然会出幻觉，“长了”不代表“抓得准”。三是可追溯性差，直接把文档塞进去，引用管理难度会大幅上升。

所以更合理的思路是把两者当作互补：短文档、单轮问答，直接拼接上下文即可；长文档、私有知识库、需要稳定引用的场景，用 RAG 控制信息入口会稳妥得多。这个问题没有绝对答案，取决于业务对延迟、成本和可解释性的权衡。

5.3 判断收益和成本，“妙用”比“滥用”更有价值

RAG 并不是一切问题的银弹。如果知识密集、答案要求精密，那么微调可能比 RAG 更能拟合输出风格；如果任务是开放的创意写作，那根本不需要检索外部知识。选型时我会先问三个问题：

• 用户问的问题，答案是否存在可检索的静态资料里，还是需要模型现场推理？
• 答案是否需要严格可溯源，宁可答少也不可答错？
• 团队是否有精力维护索引、评估集和检索质量的持续优化？

如果这三个问题里有一个回答偏否，就要重新评估是否值得引入 RAG。把 RAG 用在每天高频、有明确资料支撑、却无法用规则解决的问答场景里，回报最明显；反过来，把 RAG 套到一个模型本身就能回答好的开放角色扮演场景里，往往是无意义地增加链路复杂度。

6. 动手落地前，我最想提醒的三件事

6.1 先跑通最小闭环，再谈优化

很多团队一上来就想搭一个全功能的智能体 RAG，让模型自动决定调用什么、什么时候停止。我的经验是，先做一个最朴素但完整的闭环：准备好文档、切分、向量化、检索、重排、生成、引用，把链路在代码层面跑通。这个最小闭环的意义不是做出炫酷效果，而是建立一套可观测的基线。有了基线，后续每一次改动都能拿出对比数据，而不是凭感觉反复横跳。

我在自己做的模拟项目里，第一步甚至连混合检索都没加，只靠向量检索加提示词约束，就已经能覆盖相当比例的问题。后续再逐步加入关键词检索、重排、查询改写，每一步的效果都用评估集验证。这样做看起来慢，实际是最快的落地方式。

6.2 把数据库更新也当作一等公民来设计

RAG 链路一旦接入真实业务，数据就会不断变化。今天入库的制度文档，下个月可能就更新了新政策。因此更新和删除是生产系统必须处理的话题，而不是可选优化。在向量库中，用文档 id 管理片段来源；更新文档时，需要将旧片段清空后再写入新片段，只靠追加会导致多个版本混存，让检索结果忽老忽新。

更细腻的做法是给片段打版本号和生效时间。回答问题时，如果命中了多版本片段，可以按时间戳把更权威或更新的版本排到前面。这个是很多项目上线后才踩到的坑，前置设计能省下大量返工成本。

6.3 内部文档问答的评测集要自己建

通用基准来自公开数据集，做参考可以，真正要上线还是要建自己的评测集。方法很朴素：从业务场景里收集高频问题，为每个问题标注出应该命中的文档片段和标准答案。标签数量和覆盖度可以逐步扩充，一开始有 50 条就能做有效回归。每改一次链路，都跑一遍评测集，对比关键指标，防止“修好一个问题却引入三个新问题”。

我自己每年都会遇到那么几个时刻：明明换了更先进的模型或检索方案，整体得分却反降。最后定位到的原因往往是评测集没覆盖到新的失败模式。评测集本身就是一套可沉淀的资产，值得团队持续维护。

回看整个 RAG 演进过程，给我的真实感受是：它之所以从学术概念变成工程热点，是因为它把一个系统性方案拆成了很多可独立把控的模块，每个模块都有改进空间，也都能被单独验证。对我而言，做 RAG 真正有挑战的并不是某一个算法有多深，而是能不能把从数据准备、切分、检索到生成、评估、更新的链路全部管好，让它变得可解释、可维护、能持续增长。希望这篇内容能帮你少走几步弯路。