企业官网建设流程全解析

1. RAG为什么火：大模型的“记忆力”有多大局限

1.1 静态参数的天然短板

先聊一个很多接触大模型不久的人容易忽略的事实：传统大模型的“知识”，其实是在训练阶段一次性固化在参数里的。训练结束之后，模型本身不会再主动获取任何新信息，也不会因为某条新闻、某份内部文档、某个数据库的更新而改变自己对世界的认知。你可以把它想象成一位在毕业那天把所有知识都背下来的学生，之后无论世界怎么变化，他回答你的内容始终停留在毕业那一刻的记忆里。

这个特性带来两个直接问题。第一是知识时效性差。比如某个产品的最新版本已经在两个月前发布，模型如果训练数据只覆盖到更早的时间，它给出的版本号、功能列表、兼容性说明大概率都是错的。第二是知识覆盖度不足，尤其针对特定业务场景。通用模型见过海量公开语料，但对于某个企业内部的产品手册、售后工单、研发文档、合规条款这类私有资料，它根本“没读过”，自然也就答不出准确信息。很多人一开始误以为大模型是万能的，实际一用才发现，它对自己的训练数据边界之外的知识几乎是“一窍不通”。

更麻烦的是幻觉问题。当模型遇到知识盲区，它不会老老实实说“我不知道”，而是会基于概率生成一段听起来很像那么回事、实际却完全没依据的答案。这种现象原因并不复杂：模型的解码过程本质是在选择下一个最可能的token，这个选择依赖的是训练阶段学到的语言模式，而不是对事实的验证。于是，“一本正经地胡说八道”就成了大模型落地时最让人头疼的问题之一。

1.2 RAG要解决的不只是“知识新”

那怎么让模型既保持原有能力，又能掌握最新的、私有化的知识？业内跑通的主流方案就是RAG，全称Retrieval-Augmented Generation，检索增强生成。它的思路用一句话概括：不把知识塞进模型的参数里，而是在回答问题时，先从外部知识库检索相关内容，再把检索结果作为上下文一并交给模型生成答案。

这个思路和人类查资料很像。一个专家不可能记住所有细节，但他知道在回答问题时去查哪本手册、翻哪份档案，把查到的内容结合自己的判断组织成答案。RAG就是给大模型配了一个外挂资料库，让它在每次回答前先“翻书”，再“开口”。这也是它区别于微调（Fine-tuning）的关键所在。

微调的做法是把新知识通过额外的训练步骤写进参数里，模型被“重塑”了一遍。但微调有几个绕不开的短板：成本高，每次知识更新都要重新训练；周期长，训练、评估、上线一套流程走下来往往以天甚至周为单位；还有灾难性遗忘的风险，新知识学进去，旧能力可能反而退化。RAG则完全不同，知识放在外部向量数据库或者文档索引里，更新知识只需要更新外部数据源，模型参数一行都不用动。这一下子就解决了知识时效性和私有化接入的问题。

所以RAG本质上解决的是三个层面的事：让模型能回答训练数据之外的新知识，让模型能结合业务私域数据给出精准回答，同时大幅降低幻觉的发生概率。它不是要替代大模型本身，而是给大模型补上了一个动态知识接入层。理解了这一点，再去看RAG的各种技术细节，思路就会清晰很多。

2. 拆开RAG：三段式工作流的每个环节

2.1 索引阶段：先得让文档“可被检索”

RAG的完整流程可以拆成三段：索引、检索、生成。第一步是索引阶段，这个阶段做的事情，是把一堆原始文档变成能让计算机快速查找的结构化数据。

原始文档是没法直接被向量检索的。你手里的PDF、Word、Markdown、HTML，甚至是一堆数据库记录，首先要做解析和清洗。解析解决的是“格式兼容”问题，把不同格式的文本抽出来；清洗解决的是“噪音”问题，去掉页眉页脚、重复段落、无意义的符号、乱码等。这个过程看着简单，实际很考验细节。比如PDF里的表格，直接抽文本经常会丢掉行列关系，检索的时候自然就找不准；扫描件还需要先走OCR识别，识别的准确率又会直接影响后续检索效果。

文本抽出来之后，下一步是分块（Chunking）。这一步在很多人看来不起眼，却是整个RAG系统里最影响效果、也最容易翻车的环节。分块策略好不好，直接决定了一个问题是能在知识库里命中准确片段，还是检索回来一堆碎片化、语义残缺的文本。这部分我会在后面单独开一节详细讲，这里先了解它的大方向即可。

分块完成之后，每个块要做两件事：一是向量化（Embedding），把一段文本映射成一个高维向量；二是写入向量数据库，同时建立对应的索引结构。向量化的核心目标，是让语义相近的文本在向量空间里距离相近。比如“如何申请年假”和“年假申请流程”这两句话字面上差得远，但embedding出来的向量应该很近，因为语义是一样的。这是后续语义检索的基础。

到这个阶段，知识库的“内功”就算练好了：文档被切成了若干语义单元，每个单元都有自己的向量坐标，等着被检索调用。

2.2 检索阶段：从相似度到语义的距离

用户发起一个问题之后，检索阶段就把问题也做一次向量化，然后在向量数据库里搜索和问题向量最相似的文本块，返回Top-K个结果作为候选上下文。

这里有个关键点需要理解：向量检索返回的不是“内容相同”的文本，而是“语义相似”的文本。比如用户问“产品保修期多久”，知识库里可能没有“保修期”这三个字，但有一句“自购买之日起一年内，因非人为因素导致的故障可免费维修”，这两句话语义相关，向量距离近，就能被检索到。这是向量检索相比传统关键词检索最大的优势，也是RAG能理解自然语言提问的原因。

但语义检索也有自己的盲区，比如精确匹配的场景。用户查“订单号T20240115的状态”，如果用纯向量检索，模型并不擅长精确匹配这种标识符类的信息。所以现在很多成熟的RAG系统都会选择混合检索，也就是向量检索和关键词检索（BM25这类算法）并行，再把结果做融合排序。这个细节后面我在工程落地部分会展开。

检索质量直接决定了生成质量。这个道理很容易理解：如果检索回来的上下文就是错的，那不管模型多强，生成出来的答案都不可能对。RAG系统里流传着一句话：垃圾进，垃圾出。检索不到相关内容，或者检索结果不相关，是RAG效果差的最主要原因，远多于生成环节的问题。

2.3 生成阶段：上下文注入与提示词设计

检索完成后，把用户原始问题和检索到的文本块拼接成提示词，交给大模型生成答案。这是RAG的最后一步，也是很多人以为不需要优化、实际上大有文章的一步。

提示词里要说明清楚：哪些是参考材料，哪些是用户问题，模型的任务是什么。一个简单的提示词模板大致长这样：

请根据以下参考材料回答问题。如果参考材料中找不到答案，请直接说明“根据现有资料无法回答”，不要编造内容。 参考材料： {检索到的文本块拼接} 用户问题：{用户问题}

这个模板里有三个设计要点。第一是明确告诉模型“参考材料”和“问题”的分界，避免模型把参考材料和问题混在一起；第二是强制模型在缺乏信息时承认不知道，这是扼制幻觉的一个直接有效的手段；第三是不要给模型过多的自由发挥空间，要求它严格基于材料作答。

这里有一个很常见的误区：有人以为把检索到的所有文本块全部塞进提示词里，信息越多，模型答得越好。实际恰恰相反。一方面，大模型的注意力会被无关内容分散，真正的关键信息反而容易被淹没；另一方面，上下文越长，生成延迟越高，成本也越高。所以这里的目标不是“越多越好”，而是“精简且准确”。这也引出后面要讲的重排序（Rerank）环节，它存在的意义就是在检索出的候选结果里，把真正有用的排在前面，把没用的挤出去。

生成阶段还需要留意一个能力边界：模型并不具备“自动区分参考材料里哪句是可信的、哪句是噪音”的能力。换句话说，如果检索回来的上下文本身包含互相矛盾的信息，模型很可能把两个矛盾点都吸收进去，然后生成一个逻辑上并不自洽的答案。这个问题的解决办法，又得回到检索质量上做文章，而不是在生成提示词这一层强行修补。

3. 分块策略：最能看出功力的隐性环节

3.1 分块的本质，是在平衡两件事

很多人容易忽略的是，其实分块是整个RAG系统里最不性感但最决定效果的一环。分块的本质，是在两个互相矛盾的目标之间找平衡：块太小，单个块包含的语义信息不足，检索时容易漏掉关键内容；块太大，每个块里有大量无关信息，语义向量被“稀释”，相似度计算的精度就会下降。

用一个生活里的例子来说。假设你要从一本几百页的操作手册里找到“如何重置管理员密码”这一小节。如果把整本手册作为一个单元，你确实能保证“信息都在里面”，但向量化之后，整本手册的语义跨度非常大，包含大量和“重置密码”无关的内容，查询向量和整本手册的向量之间的相似度会被拉低；如果把手册按每个句子切分，每句都是独立单元，那“打开控制台”“输入新密码”“确认修改”这三句被切散了，单独每一句都无法完整回答问题。所以分块要做的事，就是找到那个“包含了足够上下文，又不混入太多无关信息”的粒度。

这个粒度没有统一标准，和文档类型、内容密度、检索场景都有关系。但有一个很好的直觉可以参考：尽量让每个块是一个“语义完整”的单元。一个块应该能独立回答某类问题，而不是要求多个块拼凑在一起才能理解。基于这个直觉，才有了下面几种分块策略。

3.2 固定大小分块：最稳妥的基线方案

固定大小分块是最容易理解也最容易实现的策略：设定一个chunk_size（块的大小），通常按字符数或token数计算，然后从头到尾把文本切成等长的片段，为了避免语义断裂，再设置一个overlap（重叠长度），让相邻块之间保留一部分重复文本。

实际配置中，chunk_size比较常见的起点是300到800个token，overlap一般取chunk_size的10%到20%。比如一个常见的配置是chunk_size=500、overlap=50。这样做的好处是代码实现简单，处理速度快，效果也基本可控，适合作为系统的基线方案先跑起来。

不过固定分块的缺点也很明显：它完全不考虑文本的语义边界。一个段落可能被从中间拦腰切断，一句话可能被拆成两半，导致块内文本语义不完整。检索的时候，命中的块可能正好是“半句话”，模型拿着这半个句子自然没法给出完整的回答。所以固定分块只能作为基线，而不是终极方案。我自己的习惯是先用固定分块把整个流程跑通，确认向量检索、生成链路没有问题之后，再切换到更精细的分块策略上做效果优化。

3.3 结构感知分块与递归切分

更好的分块方式，是借助文档本身的结构信息。Markdown的标题层级、HTML的段落标签、PDF的章节标题、代码文件里的类和方法定义，这些都是天然的“语义边界”。结构感知分块就是先识别文档的结构层级，再在每个层级内部做切分，尽可能保证一个块包含完整的章节或段落。

以Markdown文档为例，可以按标题级别来切分：#一级标题下的内容归为一个块，##二级标题下再细分。这样切出来的块往往语义非常聚焦，因为每个块天然对应一个主题。而且文档的标题本身能作为块内容的“摘要关键词”，对后续检索也有帮助。

更通用一点的做法是递归切分，这也是很多成熟框架内置的策略。思路是：先用一组预定义的文本分隔符（比如\n\n、\n、句号、分号）按优先级依次尝试切分，如果某个分隔符切出来的块仍然超过目标长度，就用下一个更低优先级的分隔符继续递归切分。这样做的好处是能在“保持语义完整”和“控制块大小”之间取得更好的折中。

还有更高级的方式，比如基于embedding的语义分块，通过检测文本向量之间的突变点来确定切分位置。这种方式的成本更高，但能捕捉到“上一段在讲规格、下一段在讲价格”这类语义切换。在实际项目中，如果文档类型比较固定，结构又清晰，结构感知分块往往是性价比最高的选择；如果文档类型五花八门，没有稳定结构，递归切分加适当调参更实在。

3.4 小体积分块与大上下文窗口的取舍

现在的大模型上下文窗口越来越大，动辄128K、200K的也不少。这就引出一个问题：既然模型上下文窗口那么大，直接把整篇文档塞进去，让模型自己找答案，不是更省事吗？

这个思路乍看有道理，实际却行不通。第一是成本问题，上下文越长，每次调用的价格和延迟都在涨，生产环境里根本扛不住；第二是检索精度问题，长上下文会让模型“淹没”在大量无关信息中，注意力被分散，反而不如短小精悍的相关上下文效果好；第三是相关性评判问题，你的评估指标没法细粒度地观测模型到底用了哪一段信息，出了问题很难定位。

所以现在的共识是：RAG还是要靠精准检索，不能指望靠上下文窗口硬扛。窗口大放大了RAG的上限，比如你可以把更多的候选上下文块传给模型，而不必过分纠结于只传3个还是5个块；但它不会替代检索的必要性。也就是，上下文窗口是“冗余空间”，不是“主存储”。设计RAG时，还是要以“检索到精准的、小块的内容”为核心目标，上下文窗口只是给你多一份容错空间。

4. 向量检索与重排序：召回质量的关键抓手

4.1 选Embedding模型时的几个判断点

所有文本都要过embedding模型，所以embedding模型的质量直接决定了检索的天花板。现实里没有最好的embedding模型，只有适合你的数据分布和技术栈的模型，但有几个通用的判断点可以参考。

第一个判断点是语义理解能力。这个能力不好直接量化，一个简单的方法是拿你自己的数据做测试：准备十几条真实用户问题，每个问题配一条“期望命中的文本”，然后跑一遍检索，看Top-K里能否命中目标文本。跑分高的模型，对于你的场景才是有意义的。这个动作不用搞得太复杂，却能筛掉很多“面试很强、实战不行”的模型。

第二个判断点是对领域术语和长短文本的支持。如果你的知识库是法律文书或医疗文献，术语密度很高，通用embedding模型可能并不了解这些词之间的语义关系，这时候微调或者选领域适配的模型效果会更好。另外，大部分embedding模型对中文的支持明显弱于英文，尤其是老一代模型，这一点需要实测，不要看榜单，直接拿自己的文档测。

第三个判断点是向量维度与检索性能。维度越高，理论上能承载的信息越多，但计算和存储成本也越高。常见的维度有768、1024、1536、3072等。如果你的知识库有几百万个块，高维度带来的存储和查询成本就不是小数目，需要提前评估。

顺带提一句：查询侧和文档侧最好用同一个embedding模型。如果你用模型A给文档建索引，却用模型B给用户问题做向量化，那文档向量和查询向量根本不在同一个语义空间里，检索效果一定会崩。这个错误我见过不止一次，排查半天才发现是两套向量模型混用了。

4.2 Rerank的必要性与实操

向量检索返回的Top-K结果，只是“语义上比较相似”的结果，实际不一定都相关。比如用户问“产品的退款政策”，一个关于“退换货物流时长”的文本块虽然也涉及“退”，但并不是用户真正想找的信息，却可能因为语义相似排在前列。这时候就需要Rerank环节，用更精细的模型对Top-K候选做一次重新打分和排序。

Rerank模型和embedding模型的工作方式不一样。Embedding模型是把文本压缩成一个向量，用向量距离衡量相似度；Rerank模型则是把用户问题和候选文本拼接成一个输入，直接让模型输出一个相关性分数。因为Rerank能看到完整的词汇交互，所以打分精度远高于纯向量相似度。代价是更慢、更贵，这也是为什么它要放在粗排（向量检索）之后、精排的位置上，而不是替代粗排。

实操时，典型的流程是：向量检索先召回50到100个候选，再用Rerank模型从里面选出5到10个最优的传入生成阶段。这个流程在可接受的速度成本下，能把检索精度提高一个明显的档次。

Rerank模型的选择也有讲究。要关注模型的输入长度限制，如果候选文本块很长，超过模型支持的最大长度，需要先做截断；还要关注模型对中文的支持程度和打分的分辨力，有些模型打出来的分数普遍很高，区分度不够，这种在实际场景里就不太好用。

4.3 混合检索：从RAG-Fusion看互补性

纯向量检索擅长语义匹配，但对精确匹配、专有名词、编号代码这类场景往往无能为力。比如用户查询“设备型号为RD-820的设备故障率”，向量检索可能觉得“RD-820”和“RD-830”很像，从而召回错误型号。而关键词检索（比如BM25）恰恰擅长这类精确匹配，因为它基于词典命中和词频统计。

于是就有了混合检索的思路：向量检索和关键词检索并行，各自返回一批候选结果，再通过RAG-Fusion这类算法做结果融合。简单来说，就是把多路检索结果看成一个整体，按排序位置给每篇文档计分，最后把不同来源的分数相加，按总分重新排序。这样做的好处是：既保留了语义搜索的泛化能力，又兼顾了关键词搜索的精确性，两类方法的盲区互相被填补。

实际落地时，混合检索的权重怎么配不是固定的。有的场景语义相关性更重要，向量结果权重可以高些；有的场景代码、型号、人名这类精确匹配更多，关键词结果就要占更大的比重。这个只能靠标注样本和实验去调，没有一劳永逸的答案。关键是脑子里要有这根弦：检索通道不是只能选一条，多条通道互补才是生产级系统的常态。

5. 工程落地：参数配置与实验调优

5.1 一套可参考的初始配置

工程上落地一套RAG，不要上来就追求花哨的策略，先把一套保守的基线配置跑起来，再逐步调优。我这里给你一份我自己反复用过、作为起步基本不出大错的配置组合，参考价值比较直接。

这套配置的核心思路是：放大召回的容量，再用精排来提高精度。粗排阶段宁可多召回一些可能相关的块，避免漏掉真正有用的信息；精排阶段再做精细化筛选，保证进入生成阶段的材料质量。一开始就只召回前三名，万一中间有个召回偏差，后面补救的余地都没有。

5.2 评估指标：从“感觉好用”到可量化

很多团队做了RAG半天，评估全靠“我拿几个问题试了一下，感觉还行”。这种评估方式在demo阶段没问题，但到了生产环境就根本站不住脚。因为感觉是会骗人的，而且“感觉还行”没法指导后续的迭代优化。

要系统化评估一套RAG，建议拆成两部分来看：检索质量和生成质量。

检索质量最常用的指标是命中率（Recall@K）和准确率（Precision@K）。具体做法是准备一组评测问题集，给每个问题预先标注好“期望命中的文本块”，然后跑检索，看看Top-K结果里有没有出现期望命中的块。命中率越高，说明检索能力越强。这里的K怎么选，就看你后续给了生成模型多少上下文。

生成质量的评估更复杂一些，一般会从答案正确性、忠实性、完整性几个维度打分。忠实性尤其重要，它衡量的是“答案里的每个结论是否都有参考材料支撑”。这一步可以用手工评分，也可以借助大模型做自动评估。我建议两种结合：用大模型批量初筛，人工抽检最终结果。纯靠大模型自动评，偶尔会出现对荒谬答案给出高分的情况，这本身也是一个值得留意的坑。

5.3 成本与延迟优化

RAG系统的成本主要集中在两个地方：一是知识库建索引时的embedding计算和存储，这部分是一次性成本；二是每次查询时的embedding检索和Rerank调用，这部分是持续成本。

建索引的成本相对好控制，只在文档更新时产生。查询侧成本则要看你的线上QPS，每次查询如果走“向量检索+Rerank+大模型生成”全链路，延迟和费用都不低。优化手段主要在几个方向：向量检索的索引类型（HNSW这类近似最近邻算法能明显降低检索延迟）、Rerank的候选集大小（不用每次都Rerank全部候选）、以及上下文裁剪和缓存（高频相似问题可以直接命中缓存，省掉整条链路）。

还有一点容易被忽略：不要什么事都丢给大模型做。有些问题其实用规则或者关键词匹配就能解决得更快更便宜，比如“有没有货”“开放时间是什么”这类问题，完全可以在检索层面直接给出确定性答案，不必走到生成环节。把最贵的生成模型用在真正需要语义理解和组织语言的地方，系统整体性价比才会高。

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

6.1 检索不到或召回不相关

这是RAG落地时出现频率最高的问题。检索不出内容，生成环节再怎么努力也白搭。排查思路建议从下往上逐层看。

先看知识库建得对不对。原始文档有没有成功解析？段落有没有丢失？表格是不是被抽成了乱码？这些可以通过直接在向量数据库里捞几条文本看一眼来确认。再看分块是否合理，如果块太大导致语义稀释，检索结果会“模模糊糊”地相关，但不精准；如果块太小导致语义残缺，检索结果可能完全跑偏。

如果文档和分块都没问题，下一步就要测embedding模型本身。拿一条真实问题和一条期望命中的文档，分别向量化后计算相似度，如果相似度得分极低，说明模型并不认为这两个文本语义相关，这时候要么换模型，要么考虑是否需要用混合检索补充关键词通道。

这里有一个我在实践中很受益的定位方法：先把Rerank和生成环节都去掉，直接在向量数据库里做暴力检索，看返回结果。如果这一步返回的结果就是不准的，那后面加什么高级环节都救不回来；如果这一步结果是对的，只是Rerank把它排掉了，那就单独调Rerank。这个二分法能快速把问题定位到具体环节，而不是整条链路一起猜。

6.2 生成结果依然像“编造”

好不容易检索到了相关文本，结果大模型生成答案时还是像在编故事，这种情况也很常见。原因往往是提示词没有约束住模型的“发挥欲”。

先检查提示词里有没有明确要求“严格基于参考材料作答”。很多人只是把参考材料堆进去了，没有告诉模型怎么用，模型自然按照自己的惯性来。另一个常见原因是参考材料本身包含的信息不足以回答问题，但提示词里又没给模型“说不知道”的选项，于是模型只能自己脑补。这就需要在提示词里加一句：如果参考材料无法支撑答案，必须明确回复“根据现有资料无法回答”。

还有一种情况我没有罪证很多初学的人会踩：检索回了多个块，其中只有一个块是相关的，其他都是打酱油的。模型把所有块都视为同等可信的上下文，结果被无关信息带偏。这种时候就该去检查为什么无关内容能混进Top-K，是Rerank没筛干净，还是候选集太小导致有效信息被挤掉。生成质量的下滑，很多时候源头在检索质量，不要只盯着提示词改。

6.3 多个文档碎片互相矛盾

知识库里不同来源的文档，对同一个问题可能给出不同的说法。比如产品文档里说保修一年，售后服务条款里却提到某些部件保修两年。检索阶段可能同时召回这两个碎片，模型面对互相矛盾的上下文，生成的答案自然飘忽不定。

处理这类矛盾，有几个层面的手段。第一是靠分块和检索把范围尽量收窄，让模型只看到最相关的一份资料；第二是在提示词里增加指令，让模型优先采信某种来源的文档，或者要求它在不同文档有冲突时明确指出来，而不是自行融合；第三是在知识库层面做权威性标记，比如给不同来源的文档打上权重标签，检索排序时优先返回权威来源的内容。这几个手段不冲突，可以组合使用。

我个人的经验是：先别急着把矛盾交给模型自己判断。模型不具备对两个矛盾碎片的“仲裁能力”，它只会被最近的上下文带走。更好的做法是在知识库建设阶段就明确来源的优先级，让矛盾在检索阶段就被尽量规避掉。

6.4 延迟高，用户等不起

RAG链路比普通大模型调用多出了检索和Rerank两个环节，延迟自然更高。如果用户等不起，影响体验，就需要在工程上做一些取舍。

最直接的优化是做缓存。相同或高度相似的问题，直接复用上次的生成结果，不再走检索和生成链路，效果提升非常明显。其次是压缩候选集，Rerank阶段不需要对全部候选打分，可以先通过一个更简单的规则或者向量阈值粗筛一遍。再者是换更轻量的生成模型，如果问题场景对复杂推理要求不高，一个7B到14B的模型可能就够用，响应速度远快于70B级别的大模型。

还有一点值得提的是异步化和流式输出。流式输出能让用户先看到内容逐字出现，感知延迟明显降低；异步化则可以把耗时的知识库更新和检索任务放到后台执行，不阻塞主流程。这些都属于工程细节，但往往比调整模型参数更直接地改善用户体验。

做RAG这么久，我的体会是：它不是一个单一模型或者单一算法能撑起来的东西，而是一整套系统工程。每一个环节——文档解析、分块策略、embedding模型、向量检索、Rerank、提示词设计、评估迭代——都能让最终效果发生质变，也都能成为翻车的源头。如果你现在正打算在这条路上尝试，我建议你记住两件事：一是先跑通再调优，不要在第一版就追求极致；二是所有优化动作都要基于明确的评测结果，不要凭感觉瞎调。最后分享一个小观察：真正拉高RAG效果的，往往不是用了什么新模型，而是对知识库细节的处理足够到位——分块分得准、脏数据清得干净、检索参数调得合适。把这些基础活做到位，RAG的效果自然会给你惊喜。