企业官网建设流程全解析

1. RAG系统到底在解决什么问题

第一次接触RAG这个概念是在一个内部知识库项目里。当时团队想把一堆产品文档、会议纪要、客服记录做成一个能问答的系统，第一反应是直接丢给大模型。结果很快就撞墙了：模型对内部信息一无所知，问它某个产品的具体参数，它要么编一个看起来很像但完全错误的答案，要么干脆说“我不知道”。更麻烦的是，即使模型在训练时见过类似知识，也没法保证它用的是最新版本的内容。

这就是RAG要解决的核心矛盾：大模型的参数化知识是静态的、封闭的、有截止日期的，而真实业务里的知识是动态的、私有的、持续更新的。RAG的全称是Retrieval-Augmented Generation，检索增强生成。拆开看就是三个动作：先检索、再增强、后生成。检索是从外部知识库里找到和问题相关的内容片段，增强是把这些片段作为上下文塞进提示词里，生成是让模型基于这些上下文来回答。

很多人会把RAG和微调混为一谈，觉得要让模型懂私有知识就得去训练。实际上这两条路解决的问题不一样。微调改变的是模型的“行为方式”，比如让它学会某种输出格式、某种语气风格；RAG改变的是模型的“信息来源”，让它能引用外部事实。打个比方，微调像是送一个人去进修，改变他的思维方式；RAG像是给他配了一个随时能查的图书馆，改变他能接触到的资料。对于知识频繁更新的场景，RAG的性价比远高于反复微调。

这套系统适合谁来参考？如果你手头有一批结构或半结构化的文档，想让它们变得可问答；如果你已经在用大模型但被幻觉问题困扰；如果你想做一个客服助手、内部知识助手、文档分析工具，RAG都是当前最务实的起点。它不需要你从头训练模型，也不需要标注大量数据，核心工作量集中在知识库构建和检索质量调优上。

2. 整体架构设计与核心模块拆解

2.1 为什么选择“检索+生成”而不是纯生成

纯生成方案的问题在于不可控。模型的知识来自训练语料，你没法知道它到底记住了什么、记错了什么。在需要准确性的场景里，这种不可控是致命的。RAG的思路是把“知道什么”和“怎么表达”分开：知识库负责“知道什么”，模型负责“怎么表达”。这样一来，更新知识只需要更新知识库，不用动模型。

另一个考虑是成本。微调一个大模型需要GPU资源、训练时间、调参经验，而且每次知识更新都要重新训练。RAG的知识更新就是往向量库里加几条记录，几分钟就能完成。对于中小团队来说，这个差距是决定性的。

还有一个容易被忽略的点：可追溯性。RAG系统在回答时可以附带引用来源，用户能看到答案是从哪段文档里来的。这在企业场景里非常重要，因为没人会完全信任一个说不出依据的答案。

2.2 核心模块的职责划分

一个完整的RAG系统通常包含四个核心模块：

文档处理模块负责把各种格式的原始文档（PDF、Word、Markdown、HTML）解析成纯文本，然后按照一定策略切分成片段。这个模块的质量直接决定了后续检索的上限，因为如果切分把一段完整的意思切断了，检索出来的片段就是残缺的。

向量化模块负责把文本片段转换成向量表示。这里用的是嵌入模型，它把一段文字映射到一个高维空间里的点，语义相近的文字在空间里的距离也相近。嵌入模型的选择很关键，不同模型对中文、英文、代码的语义捕捉能力差异很大。

检索模块负责接收用户问题，把问题也向量化，然后在向量库里找最相近的片段。这里涉及相似度度量方式的选择、检索数量的设定、是否加关键词检索做混合召回等问题。

生成模块负责把检索到的片段和用户问题组装成提示词，调用大模型生成最终回答。提示词的设计直接影响回答质量，包括怎么组织上下文、怎么约束模型不要编造、怎么处理检索结果为空的情况。

2.3 数据流转的全链路

从用户输入一个问题到拿到回答，数据经历的路径大致是这样的：问题先被嵌入模型转成向量，然后在向量数据库里做相似度搜索，返回Top-K个最相似的片段。这些片段连同原始问题一起被填入提示词模板，发送给大模型。大模型生成回答后返回给用户。如果开启了引用功能，还需要把片段对应的原文位置信息一并返回。

这条链路里每个环节都有优化空间。嵌入模型可以换、切分策略可以调、检索数量可以改、提示词可以迭代。实际项目中，大部分调优工作都花在切分策略和检索质量上，因为这两块对最终效果的影响最大。

3. 知识库构建的关键细节

3.1 文档切分策略的取舍

切分是RAG系统里最容易被低估的环节。很多人直接按固定字数切，比如每500字一段，结果就是经常把一句话切成两半，或者把紧密相关的两段内容分到不同片段里。检索的时候，用户问一个问题，命中的片段可能只有半句话，模型拿到这种残缺上下文，回答质量自然好不了。

我试过几种切分策略，各有适用场景。固定长度切分最简单，实现成本最低，适合格式统一的文档，比如日志、结构化报告。按段落切分尊重文档的自然结构，适合文章、说明文档这类有明确段落的材料。按语义切分用嵌入模型判断相邻句子的语义相似度，在语义断层处切分，效果最好但计算成本最高。递归切分是折中方案，先按大分隔符切，如果某段还是太长再按小分隔符切，依次递归。

实际项目里我通常用递归切分加一个重叠窗口。重叠窗口的意思是相邻片段之间保留一部分重叠内容，比如每个片段500字，相邻片段重叠100字。这样做的好处是即使切分点落在关键信息中间，重叠部分也能保证信息不丢失。代价是存储和检索时会有些冗余，但相比信息丢失的代价，这点冗余完全可以接受。

切分长度没有万能值。中文场景下，300到800字是比较常见的范围。太短了语义不完整，太长了检索精度下降。建议先用300字试，根据实际问答效果再调整。

3.2 嵌入模型的选择考量

嵌入模型决定了文本被映射到向量空间后的语义表达能力。选模型时我主要看几个维度：语言支持、维度大小、推理速度、是否支持长文本。

中文场景下，有些模型对中文语义的捕捉明显好于其他模型。如果知识库里中英文混杂，就要选多语言能力均衡的。维度方面，常见的有384维、768维、1024维、1536维。维度越高表达能力越强，但存储和计算成本也越高。对于几万条片段的知识库，768维通常够用；如果知识库很大或者语义区分度要求高，可以考虑1024维以上。

推理速度经常被忽略。如果知识库有几十万条片段，每次新增文档都要重新嵌入，模型太慢会严重影响迭代效率。我一般会先用小模型快速验证流程，确认没问题后再换大模型做最终效果。

还有一个实际问题是嵌入模型和生成模型最好来自同一体系或者经过兼容性验证。有些嵌入模型产出的向量和某些生成模型的语义空间不匹配，会导致检索出来的片段虽然向量距离近，但实际语义相关性差。

3.3 向量数据库的选型对比

向量数据库的选择取决于数据规模、查询频率、部署方式和预算。我整理了一个对比表，覆盖几种常见方案：

小规模验证阶段，我通常用内存向量库快速跑通流程。到了生产环境，如果数据量在十万级以内，轻量嵌入式库基本够用。超过百万级或者有高并发需求，才需要考虑专用向量数据库。选型时不要一上来就追求最重的方案，很多项目根本到不了需要专用数据库的规模。

3.4 元数据设计的重要性

很多人只存文本和向量，忽略了元数据。元数据是附加在每条片段上的结构化信息，比如来源文档名、章节标题、创建时间、文档类型、权限标签等。这些信息在检索时可以用于过滤，在展示时可以用于引用。

举个例子，如果知识库里有多个产品线的文档，用户问的是A产品的问题，检索时就可以用元数据过滤掉B产品的片段，避免干扰。再比如，如果文档有版本区分，可以用时间元数据只检索最新版本。没有元数据的话，这些过滤都做不了，检索结果里会混入大量无关内容。

元数据设计的原则是：凡是可能用于过滤或展示的字段，都提前存进去。存储成本很低，但后期想补就很麻烦，因为要重新处理所有文档。

4. 检索与生成环节的实操要点

4.1 相似度检索的参数调优

检索环节最核心的参数是Top-K，也就是返回多少个最相似的片段。K太小，可能漏掉关键信息；K太大，会引入无关内容干扰模型，还会增加提示词长度和生成成本。

我的经验是先从K=5开始试。如果发现回答经常缺少某些信息，说明K太小，逐步加到8或10。如果发现回答里混入了不相关的内容，说明K太大，减到3或4。这个值没有标准答案，取决于知识库的密度和问题的复杂度。

相似度度量方式也有讲究。余弦相似度是最常用的，它只看向量方向不看长度，适合大多数文本场景。欧氏距离看的是绝对距离，对向量长度敏感。内积计算最快，但要求向量归一化。实际用哪种，取决于向量库的支持和嵌入模型的训练方式。大多数情况下余弦相似度是安全选择。

还有一个技巧是设置相似度阈值。如果所有返回片段的相似度都低于某个值，说明知识库里可能没有相关内容，这时候应该让模型回答“没有找到相关信息”，而不是硬编一个答案。阈值设多少需要根据实际数据分布来定，可以先观察一批问题的相似度分布，找一个明显的分界点。

4.2 混合检索的实践

纯向量检索有个短板：对精确匹配不敏感。比如用户问一个特定的错误码“ERR-4032”，向量检索可能返回一堆语义相近但错误码不同的片段。这时候关键词检索（BM25）就能派上用场，它对精确词项匹配很敏感。

混合检索的思路是同时跑向量检索和关键词检索，然后把两路结果融合。融合方式有几种：加权求和是最简单的，给两路结果各一个权重，按加权分数排序；倒数排名融合不看具体分数只看排名，把两路结果的排名做加权，对分数尺度不一致的情况更鲁棒；先过滤再向量检索是用关键词检索做粗筛，再在粗筛结果里做向量精排。

我在实际项目里用得最多的是倒数排名融合，因为它不需要调分数权重，对两路检索器的分数差异不敏感。实现上也不复杂，就是把两路结果的排名取倒数后加权相加，再重新排序。

4.3 提示词模板的设计

提示词是RAG系统里唯一直接约束模型行为的环节。设计得不好，模型可能忽略检索内容自己编，或者把检索内容原封不动抄一遍。

我常用的提示词结构是这样的：先给模型一个角色设定，比如“你是一个基于给定资料回答问题的助手”；然后明确约束“只使用提供的资料回答，资料中没有的信息不要编造”；接着是检索到的上下文片段，每个片段标注来源；最后是用户问题。

关键约束有几条。必须明确说“只使用提供的资料”，否则模型会混入自己的训练知识。必须说“资料中没有就说不知道”，否则模型会硬编。上下文片段要有清晰的分隔和编号，方便模型引用也方便排查问题。问题放在最后，因为模型对末尾内容的注意力通常更强。

还有一个细节是上下文长度控制。如果检索回来的片段总长度超过了模型的上下文窗口，就要截断。截断策略可以是按相似度排序后取前几个，也可以是对每个片段做摘要。我一般优先保证片段数量，因为多个片段比单个长片段更能覆盖不同角度的信息。

4.4 生成参数的影响

调用大模型时的几个参数也会影响RAG效果。**温度（temperature）**控制输出的随机性，RAG场景通常设低一些，0.1到0.3之间，因为需要的是准确引用而不是创意发挥。最大输出长度要设够，避免回答被截断，但也不要太大以免浪费。重复惩罚可以防止模型反复说同一句话。

有些模型支持引用返回功能，可以让模型在回答里标注哪句话来自哪个片段。这个功能对可追溯性很有帮助，但需要模型支持，而且会增加输出长度。如果模型不支持，也可以在提示词里要求模型用方括号标注来源编号。

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

5.1 检索不准的排查思路

检索不准是最常见的问题，表现是回答里缺少关键信息或者引用了不相关的片段。排查时我按这个顺序走：

先看切分。把检索到的片段原文打印出来，看它是不是完整的语义单元。如果片段被切断了，说明切分策略有问题，调整切分长度或重叠窗口。

再看嵌入模型。拿几个典型问题，手动算一下问题和正确片段的相似度，看是不是真的低。如果低，可能是嵌入模型不适合这个领域，考虑换模型或者对领域数据做微调。

然后看检索参数。K值是不是太小，相似度阈值是不是设得太高，有没有加元数据过滤把正确片段滤掉了。

最后看知识库覆盖。有些问题知识库里根本没有对应内容，检索自然找不到。这时候要补充文档，而不是调检索参数。

5.2 模型不按资料回答的处理

模型不按资料回答有两种表现：一种是忽略资料自己编，另一种是过度依赖资料把无关内容也抄进去。

忽略资料的情况，通常是提示词约束不够强。可以加强约束语句，比如把“只使用提供的资料”改成“必须且只能使用提供的资料，任何资料之外的信息都是不允许的”。也可以在资料前后加分隔标记，让模型更清楚哪部分是资料。

过度依赖资料的情况，通常是检索回来的片段里有噪音。解决方法是提高检索精度，比如加相似度阈值、减少K值、加元数据过滤。也可以在提示词里加一句“如果资料与问题无关，忽略该资料”。

5.3 性能瓶颈的定位

RAG系统的延迟主要来自三个环节：嵌入、检索、生成。嵌入和检索通常很快，几十到几百毫秒；生成是大头，取决于模型大小和输出长度，可能几秒到十几秒。

如果整体延迟高，先分别测三个环节的耗时。嵌入慢就换小模型或做批量处理；检索慢就加索引或减少数据量；生成慢就换小模型或限制输出长度。

还有一个容易被忽略的点是首次加载。嵌入模型和向量库首次加载可能很慢，如果服务是冷启动的，第一个请求会特别慢。解决办法是服务启动时预热，或者保持常驻进程。

5.4 常见问题速查表

5.5 几个踩过的坑

第一个坑是忽略文档预处理。PDF里的表格、图片、页眉页脚如果不清掉，会变成噪音进入知识库。我现在的做法是解析后先做一轮清洗，去掉短于一定长度的行、去掉纯符号行、合并被换行打断的句子。

第二个坑是嵌入模型和生成模型不匹配。有一次换了嵌入模型但没换生成模型，结果检索出来的片段语义相关性明显下降。后来发现两个模型的语义空间不一致，检索器认为相关的片段，生成器觉得不相关。换回配套模型后问题消失。

第三个坑是没有处理空检索。用户问了一个知识库里完全没有的问题，检索返回的片段相似度都很低，但系统还是把它们塞给模型，模型就硬编了一个答案。后来加了相似度阈值判断，低于阈值就直接返回“没有找到相关信息”，幻觉率大幅下降。

第四个坑是元数据格式不统一。不同来源的文档用了不同的字段名，有的叫“source”有的叫“来源”，导致过滤时匹配不上。后来定了一套统一的元数据规范，所有文档入库前都按规范转换。

6. 效果评估与持续迭代

6.1 怎么判断RAG系统好不好

评估RAG系统不能只看“回答看起来对不对”，要有可量化的指标。我通常从两个层面评估：检索层面和生成层面。

检索层面看召回率和精确率。召回率是正确片段被检索到的比例，精确率是检索到的片段中正确的比例。这两个指标需要人工标注一批问题和对应的正确片段，然后跑检索看结果。召回率低说明检索不到，精确率低说明检索回来太多噪音。

生成层面看忠实度和相关性。忠实度是回答是否完全基于检索内容，没有编造；相关性是回答是否切题。这两个指标可以用人工评分，也可以用另一个模型来打分。人工评分更准但成本高，模型打分快但需要校准。

6.2 迭代优化的优先级

拿到评估结果后，优化要有优先级。我的经验是：先修检索，再修生成。因为检索是生成的上游，检索不准，生成再优化也没用。

检索优化的顺序是：切分策略 > 嵌入模型 > 检索参数 > 混合检索。切分是基础，切分不对后面都白搭。嵌入模型是核心，模型不行检索质量上不去。检索参数调优成本最低，可以先试。混合检索是锦上添花，前面都做好了再考虑。

生成优化的顺序是：提示词 > 模型选择 > 生成参数。提示词调整成本最低，效果也最直接。模型选择取决于预算和延迟要求。生成参数微调空间有限，通常放在最后。

6.3 持续维护的要点

RAG系统上线不是终点，知识库需要持续维护。我一般会做几件事：

定期检查检索日志，看哪些问题检索效果差，针对性补充文档或调整策略。监控相似度分布，如果整体相似度下降，说明知识库和用户问题的匹配度在降低，可能需要更新文档。收集用户反馈，用户标记的错误回答是最直接的优化线索。定期重新嵌入，如果换了嵌入模型，所有文档都要重新处理。

还有一个实际问题是文档版本管理。同一份文档可能有多个版本，旧版本如果不清理，会和新版本一起被检索到，造成冲突。我的做法是给每个文档加版本号和生效时间，检索时只取最新版本。

7. 一些个人体会

RAG系统看起来架构简单，但真正做好需要关注的细节非常多。我最大的体会是：检索质量决定上限，生成质量决定下限。检索做得好，即使生成模型一般，回答也能用；检索做得差，生成模型再强也救不回来。

另一个体会是不要追求一步到位。先用最简单的方案跑通全流程，哪怕切分是固定长度、嵌入是小模型、检索是纯向量，只要能跑起来就能看到问题在哪。然后针对最痛的点逐个优化，比一开始就设计复杂架构要高效得多。

最后说一个容易被忽略的点：RAG不是万能的。有些问题适合RAG，比如事实查询、文档问答；有些问题不适合，比如需要推理、计算、多步规划的任务。判断一个需求适不适合RAG，就看它是不是“查资料能解决”。如果是，RAG大概率有效；如果不是，可能需要其他方案配合。