企业官网建设流程全解析

1. RAG到底是什么，为什么大家都开始用它

RAG（检索增强生成）最近出镜率实在太高了，几乎每个做大模型应用的人都会提到它。所谓RAG，通俗地说就是给大模型外挂一个“资料库”，在模型回答问题之前，先去这个资料库里检索相关的片段，然后把检索到的内容连同用户问题一起喂给大模型，让它基于这些资料来生成回答。

我在一开始接触RAG的时候，纯粹是因为一个很现实的问题：大模型虽然知识面广，但它不知道我公司内部的业务数据，也不知道最近三天发生的事情。我试过直接用公开模型回答，效果只能说“表面光鲜”，一落到具体业务上就露馅。它会一本正经地说出一个不存在的产品型号，或者把过时的政策当成现行规定来讲。与其反复微调模型（成本高、周期长、而且每次业务更新都要重来一遍），不如用RAG把外部知识“现取现用”。

RAG解决了三个核心痛点：一是知识时效性，检索的都是最新入库的内容；二是领域私有性，企业内部文档、产品手册、行业报告都能作为检索源；三是可追溯性，你可以知道模型回答的依据来自哪一段文档，而不是凭空生成。当然，它本身不是没有缺陷——检索质量直接决定答案质量，如果检索阶段拿回来的都是无关内容，后面再怎么调Prompt、换模型都白搭。所以我写这篇内容，专门聊聊怎么把“检索质量”这件事做扎实，从指标理解到实操策略，再到评估工具，一条线走通。适合刚接触RAG的人建立整体认知，也适合已经在做RAG但被检索效果困扰的人对照排查。

很多人把RAG当成一个“检索 + 生成”的流水线，觉得只要搭起来就能用。实际踩过坑之后你会发现，效果好坏的分水岭几乎都集中在“检索”这一侧——上下文里有没有相关证据，决定了模型是“有理有据地答”还是“礼貌地胡扯”。我见过有人辛辛苦苦把向量数据库搭好，召回率却低得可怜，最后排查发现是分块策略出了问题；也见过有人检索的片段明明包含正确答案，但被大量无关片段挤占，模型反而被带偏。这些问题都不是模型本身造成的，而是“检索链路设计”的问题。

所以在聊具体提升方法之前，先把两个关键指标说清楚，因为它们是我们接下来所有优化动作的“靶子”。

2. 检索准确率与召回率：先搞懂这两个指标，再看怎么优化

2.1 准确率（Precision）与召回率（Recall）的本质区别

检索阶段可以理解成一个“大海捞针”的过程：文档库里总共有100个可能相关的片段，你的检索系统只返回了10个，其中6个确实是相关的。这时候准确率就是 6/10 = 0.6，召回率是 6/100 = 0.06。

准确率关心的是“我捞上来的东西里有多少是对的”，召回率关心的是“所有对的东西里我捞上来多少”。一个追求“少而精”，一个追求“多而全”。在RAG场景里，这两个指标有一个微妙的博弈关系：召回率太低，模型可能拿不到关键证据，只能瞎编；准确率太低，大量噪声片段混进上下文，模型容易被无关信息干扰，还可能超出上下文窗口限制。

举个例子。我做过一个某产品的客服问答系统，用户问“某某型号支持快充吗”，文档库里真正的答案只在产品规格书的第15页第三段。如果检索系统只返回了产品介绍页的几段营销文案，看起来“相关”，但根本没提快充这事——准确率似乎还行（返回的都是产品相关内容），但召回率很差，关键证据没进来。模型最后只能根据营销文案里的“超长续航”“轻薄便携”这些信息发挥，回答得倒是流畅，但内容根本不触及核心问题。这种“答非所问”在早期RAG系统里非常常见。

评估RAG检索效果时，不能只盯着“返回结果是不是这个领域的”，要盯着“返回结果里有没有包含能回答问题的那句关键信息”。这决定了我们对RAG的优化是“方向性调整”而非“表面功夫”。

2.2 一个容易被忽略的事实：准确率和召回率有时不可兼得

很多初学者会陷入一个误区，认为“提升召回率就是让系统多返回一些结果”，于是把Top-K从5改成20。这个操作名义上能提升召回（更多候选进来），但通常会把准确率拉下去——大量弱相关的片段混入上下文。

在实际工程中，我不建议盲目调大Top-K候选数量，而是采用“两阶段检索”策略：召回阶段尽量放宽（比如取Top-100），保证高召回；精排阶段再做一次精细的过滤和重排（比如压缩到Top-5或者Top-3），保证高准确率。这样既避免了“漏掉关键信息”，又避免了“噪声吞没上下文”。

打个比方：召回阶段像海选，来者不拒，先把可能有戏的都叫来；重排阶段像终面，仔细看每个人的材料，只留下真正能答上题的人。这样做的好处是，两个指标在不同阶段各有侧重，而不是在同一个阶段相互妥协。

我在实际项目中用的链路是：向量检索召回Top-50 + 关键词检索召回Top-50 → 合并去重 → 重排模型精排 → 取Top-5作为上下文。这个设计我们在后面“提升召回率”和“提升准确率”部分会拆开讲。这里的核心记住了：别用单一检索策略同时扛准确率和召回率，分开处理，各干各的，效果好得多。

3. 提升检索准确率的核心手段：从分块、向量化到重排

3.1 分块策略：开头没做好，后面全白搭

很多人提升准确率的第一反应是换模型、调参数、换Embedding模型，但我觉得真正值得先查的是“分块”（Chunking）策略。分块粒度控制得不好，后续一切优化手段都像在松软地基上盖高楼。

分块太粗，比如直接把一整篇PDF文档作为一个片段，这样向量化后的语义向量表达力会严重弱化——一个几千字的向量被压缩成一条，语义信息被平均化，检索时根本找不精准。分块太细，比如按句子切，又会导致单个片段缺乏上下文，“快充”两个字单独成段，检索模型不知道它属于“充电技术”还是“售后政策”。

我通常采用“固定长度 + 重叠窗口”的分块方法：设块大小为300到500个token（按中英文不同灵活调整），重叠50到100个token。为什么要有重叠？因为如果关键信息恰好被分块边界断开，重叠可以保证信息出现在相邻的两个块中，至少有一侧不会丢失语义完整性。这是一个成本很低但对召回影响极大的细节。

还有一种更精细的做法是按文档结构分块。比如针对产品手册，先按章节节点切分，再在每个二级标题下做段落合并。这种方式比纯按字符数切更贴合语义边界，实际效果也好很多。我在某文本处理项目里用结构分块替换了纯长度分块之后，检索精度大约提升了15%。但结构分块的缺点是需要知道文档结构，而别人的文档不一定有清晰标题体系。所以我的建议是：先跑通固定长度分块，再看文档结构有没有利用空间。

3.2 向量化模型选型：不同模型对准确率的影响有多大

分块之后，每个片段就是一个“候选”，下一步是把候选片段编码成向量。Embedding模型的选择直接影响检索准确率，这一点我刚开始做的时候低估了。我最早用的通用Embedding模型效果不佳，后来换成一款在中文语料上做过专门优化的模型后，检索效果提升非常直观——就像同样是找资料，一个助手只读过新闻，另一个助手读了你所在的行业论坛和产品文档，理解的深度完全不一样。

关于Embedding模型有几个实践建议：

• 尽量选择上下文长度较大的模型，因为分块越大，向量化时能保留的上下文信息就越完整。
• 量化版本通常会在准确率上有轻微损失，但性能提升明显。如果线上QPS压力大，可以考虑在“准召”要求不那么高的场景使用量化版本，核心场景保留全精度。
• 如果资源允许，可以考虑领域微调Embedding模型，把测试集里的“问题-答案片段”对做成训练数据。这个方案调优空间最大，但也最费功夫。对一个中型团队来说，我建议先尝试换通用模型，再考虑微调，否则容易投入产出不成比例。

有个细节值得提一下：向量检索的距离度量方式也会影响效果。余弦相似度最常用，但如果你的向量不是单位向量归一化过，内积和欧氏距离的结果会有差异。我习惯在Index构建前做向量归一化，这样三种距离度量的结果在排序上基本等价，后续调参时少一些坑。

3.3 重排：把最相关的信息压到最前面

召回阶段返回的候选结果往往数量较多，质量参差不齐。直接取Top-5作为大模型上下文，可能其中只有两条真正相关，其余三条是“看起来相关”的噪音。解决思路是加入重排（Rerank）环节。

重排模型通常是一个基于交叉编码器（Cross-Encoder）的模型——它可以把“用户问题”和“候选片段”拼接在一起，计算一个精细的相关性打分。相比之下，向量检索用的双塔（Bi-Encoder）模型无法做到这种交互级判断，所以精度上天然不如交叉编码器。代价是交叉编码器计算量更大，无法提前把文档库向量化好，必须在查询时实时计算。

我在项目中常用如下流程：向量检索取回Top-50候选，交给重排模型打分，最后只取Top-5。这么做的最大收益是：即便召回阶段因为“语义近似”捞回了很多相关但不够精确的片段，重排阶段也能把它们重新排序，把最契合问题和上下文的片段挤到前面。

重排模型的选择也有讲究。小模型速度快，但判断能力弱；大模型精度高，但延迟明显。线上场景经常需要在延迟和精度之间做取舍。我个人的经验是：如果文档片段长且内容密集，用一个精度更高的重排模型；如果文档片段短且信息明确，用小模型完全够用。

3.4 查询改写：用户的问题不清晰，检索再好也没用

用户在真实场景中的提问往往含有噪声：口语化、指代不明确、问题太宽泛。直接拿原始问题去做检索，效果有限。查询改写（Query Rewriting）是提升准确率的一条“隐藏路径”。

常见的做法有两种：一种是基于规则改写，比如去掉无意义语气词、给专有名词补全全称；另一种是基于大模型改写，让模型把用户问题“重写”成更适合检索的形式。例如用户问“那个轻薄本多少钱”，直接去检索“那个轻薄本多少钱”效果很差，改写为“某品牌轻便笔记本价格”后，检索结果的命中率高很多。

我建议在查询改写和大模型生成之间加一个“检索前意图判断”的环节。先判断用户是想要事实类回答、对比类回答还是操作指导类回答，再针对性地做查询改写。比如对比类问题改写时，要保留“对比”的语义，而不是把问题简化成单纯的事实查询，否则检索到的片段可能只包含某一个对象的介绍，缺少另一方的信息。

4. 提升召回率的实用技巧：混合检索与候选扩展

4.1 只靠向量检索，召回率一定会有瓶颈

向量检索（语义检索）擅长理解意图相似但字面不同的查询。比如用户搜“哪里能修屏幕”，向量检索能匹配到“手机碎屏更换维修点”这样字面上不完全一致但语义相近的内容。但它也有短板——对专有名词、缩写、精确编号、型号这些字面敏感的信息，向量检索往往不敏感。

举个例子，用户搜索“ABC-100型号的保修期是多少”，文档里正好有“ABC-100”，但如果用户写成了“ABC100”或者“ABC 100”而文档用的是带连字符的写法，向量检索可能匹配不上。原因在于Embedding模型通常对字符级别的精确匹配不够敏感，它更关注整体语义。

这时候只依赖向量检索，召回率就会卡住。我的解决方案是引入“混合检索”（Hybrid Search）：向量检索负责语义匹配，关键词检索负责精确匹配，两者结果合并后再去重。关键词检索可以用BM25算法，也可以直接用倒排索引配合布尔查询。BM25算法是经典的信息检索算法，它基于词频和文档长度来计算相关性，在短文本匹配上表现稳定。

在“精确信息检索”场景下，BM25往往比向量检索更可靠。有一组在多个数据集上的实测数据印证了这一点：纯BM25的召回率在某些类型的问题上甚至超过纯向量检索，而“BM25 + 向量检索”的混合策略则普遍优于单一策略。这也是行业里越来越多人接受混合检索的原因。

4.2 混合检索的权重如何调，才能达到最佳效果

混合检索有一个看起来简单但实际上很有讲究的点：向量检索结果和关键词检索结果如何合并排序？

最简单的做法是“先按各自得分排序，再按固定比例交替合并”，或者做加权求和。我习惯的做法是：先定义两种检索结果的相似度都在0到1之间（标准化），然后按权重α做线性加权：最终得分 = α × 向量得分 + （1 - α） × 关键词得分。α默认取0.7左右，然后再根据具体场景调。

调权重有个小技巧：拿一批典型的用户问题做测试集，对每个问题人工标注哪些文档片段是正确答案，然后遍历α从0.1到0.9，计算每组权重下的召回率，画出一条曲线，取峰值对应的α。这个做法不复杂，但能让你用数据说话，而不是靠感觉调参。

在有些阶段，你甚至可以根据查询类型动态调整权重。比如查询里出现了明确的型号编号（能匹配到正则表达式），就把关键词检索的权重调高；如果查询是口语化的描述，就把向量检索的权重调高。这种策略称为“路由式混合检索”，实现不复杂但收益明显。

4.3 多路召回：不要把自己限制在一种检索模式里

除了向量检索和关键词检索，还有一种提升召回率的思路叫“多路召回”——同时从多个角度、多个索引、多个来源获取候选片段。

比如在我做的一个技术文档问答系统里，我同时建立了三个索引：一个用于向量检索，一个用于关键词检索，一个用于标题检索。遇到用户问“如何配置网络”，标题检索可以直接命中某个文档的标题“网络配置指南”，向量检索可以命中正文中关于“网络参数设置”的段落，关键词检索可以命中“配置网络”这个短语所在的片段。三路结果合并起来，覆盖范围明显比单一一路广得多。

多路召回的核心思想是“宁可多召回，也别漏掉”。召回阶段多花点算力没关系，重排阶段会把把关，过滤掉不相关内容。如果由于成本和复杂度，暂时做不到多路，至少也应该把“向量检索 + 关键词检索 + 重排”的三段式链路建立起来。这是性价比最高的基础配置。

4.4 知识库的质量：召回率的天花板取决于数据本身

有一个经常被忽视的底层问题：如果文档库里本身就没有答案，任何检索策略都救不了召回率。提升召回率有一个前置工作——做好知识库的数据治理。

我在一个项目里遇到过“怎么调都调不好”的怪事。后来排查发现，知识库里的PDF是从扫描件OCR出来的，大量段落存在乱码和错别字，很多关键词在索引里根本不存在。BM25匹配不到，向量化效果也差。这个问题的根源不在检索策略，而在数据质量。

数据治理这里有几个关键步骤：

• 清洗：去掉页眉页脚、重复内容、签名档、水印文字。
• 规范化：统一术语、单位、缩写格式。比如“AI”和“人工智能”应该统一为一种写法，或者在预处理时做同义词扩展。
• 结构化：尽可能保留文档的标题层级，这对后续分块和按结构检索非常重要。
• 定期更新：增加的内容要周期性同步到索引里，删除的内容也要及时从索引中移除，否则旧数据会持续干扰检索。

我用一个生活化的比喻来形容这件事：检索系统像一个图书馆管理员，你给他一本印刷清晰的分类目录，他就能快速找到书；你给他一堆字迹潦草、页码错乱的复印纸，他再熟练也没办法快速定位。所以，优化知识库质量是提升召回率的前置条件，而且越早做效果越好。

5. 评估工具怎么选：从指标到平台，把优化效果量化出来

5.1 评测维度：不只是准确率和召回率

既然要提升检索准确率和召回率，那就必须有一套评估机制来量化“提升了多少”。RAG的评估体系通常分成两部分：检索评估和生成评估。检索评估主要看准确率、召回率、MRR（Mean Reciprocal Rank）、Hit Rate等；生成评估主要看忠实度（Faithfulness）、答案相关性（Answer Relevance）等。

这里特别强调MRR和Hit Rate——如果你关注的不是“Top-5里有没有正确答案”，而是“正确答案排在第几位”，MRR就是一个更有区分度的指标。比如答案在第一位，MRR贡献1.0；在第三位，贡献0.33。这非常重要，因为即使正确答案进了Top-5，如果排在第5位，大模型把它当依据的概率也会显著降低——前面4条不相关内容可能把上下文带偏。

忠实度这个指标也值得关注：它衡量的是“模型生成的回答有多少内容能在提供的文档片段里找到依据”。如果一个回答流畅但内容大部分是模型自己发挥的，忠实度就会很低。这在事实问答场景中是致命的。

5.2 常用评估工具：从离线到在线，按需选择

在评估工具上，我踩过一些坑，也给过不少团队推荐过方案。按照从轻量到重量排列，目前比较实用的有几类：

基于规则的评估：如果你没有复杂的语义判断需求，可以先写规则脚本。比如，给问题准备一组黄金答案关键词，检查检索结果中是否包含这些关键词。这个方法实现简单、速度快，适合早期快速迭代。

使用评测框架：当规则无法满足时，可以引入评测框架。目前比较主流的是RAGAS与TeRRa两种。RAGAS通过生成式模型对“忠实度”和“答案相关性”打分，用法直观，适合快速给系统效果做体检。TeRRa更适合测试集完整的严谨评测场景，支持多维度指标计算。两者不冲突，可以根据团队阶段选用。

构建私有评测集：不管是使用框架还是规则，都需要一组高质量的测试集。我的做法是从真实用户问题中抽取典型样本，人工标注出对应的正确答案片段，构成一个约200条左右的“黄金数据集”。之后的每次改动，都用这组测试集跑一遍，对比指标变化。这一步极其重要，远比调参本身更能避免“改了这个指标却毁了那个指标”。

5.3 我推荐的评估工作流：三级评估体系

我的实际项目中建立了一个三级评估体系，分享出来供参考：

• 第一级：单查询评测。选10到20条典型问题，人工查看每条检索结果的前5个片段，判断是否包含关键答案。快速发现明显问题，适合开发阶段的快速验证。
• 第二级：批量离线评测。用黄金测试集跑完整指标，输出准确率、召回率、MRR、忠实度等。每次改动（不管是换Embedding、改分块还是调权重）都跑一遍，对比前后差异。
• 第三级：线上日志分析。收集真实用户查询的日志，定期抽样，检查“用户问了什么、系统检索了什么、模型答了什么”。这一步没有离线评测那么精准，但能发现离线评测覆盖不到的“长尾问题”。

三级评估体系的价值在于“快慢结合”：开发时用第一级快速验证方向，改动落地前用第二级做回归，上线后用第三级持续监控效果。

6. 一个完整的实战流程：从搭建到调优，每步怎么走

6.1 基础链路搭建：没有捷径，但可以少走弯路

第一步是准备知识库文档，做数据清洗和规范化。第二步是基于文档结构或固定长度做分块，生成索引。第三步是选Embedding模型，将分块向量化并写入向量数据库。第四步是搭建检索服务，包含向量检索、关键词检索、混合融合、重排。第五步是设计Prompt模板，把检索结果作为上下文拼接给大模型。

这个流程的核心链路虽然固定，但每一步都有可选参数和可替换组件。我的建议是先跑一个“快速原型”——所有模块用最简单的方式串联起来，确认整条链路能跑通，再逐步替换和优化单个模块。很多团队一上来就追求完美，结果卡在某个组件上无法推进，反而白白浪费时间。

6.2 第一次调优：先看最影响效果的三个点

链路跑通后，第一次调优我建议只关注三个点，不要贪多：

一是分块大小和重叠窗口。先用一组典型问题，测试“块大小300 + 重叠50”、“块大小500 + 重叠100”等几种组合，看召回率变化。块越大，每个片段包含的信息越丰富，但检索精度可能下降；块越小，精度高但容易丢失上下文。这个权衡需要针对你自己的文档类型测试。

二是Embedding模型的选择。分别用几款不同模型跑一遍黄金测试集，对比MRR指标。这部分不一定要立刻追求最优，但可以选择明显更贴合领域数据的模型。

三是重排和非重排的对比。在测试集上分别跑“直接取Top-5”和“取Top-50后重排再取Top-5”，看准确率和忠实度提升幅度。如果提升不明显，可能是数据本身的相关性区隔度已经很高，重排优化空间小；如果提升显著，说明检索阶段的噪声确实在伤害生成效果。

6.3 持续迭代：用评估驱动改动，而不是靠感觉

经过几轮调优，系统基本能达到一个可用的状态。但真正让效果提升到“好用”的，还是持续迭代。我的节奏是这样的：

• 每周跑一次离线评测，记录一组关键指标到表格里。
• 每月做一次线上日志抽样分析，检查用户反馈异常的例子。
• 每次改动只改一个变量，避免多个改动叠加导致“指标变了但不知道为什么”。
• 定期扩充黄金测试集：把线上发现的新案例加入测试集，防止优化方向偏离真实场景。

这种迭代方式看起来不够“刺激”，但胜在稳定、可追踪、结论可信。很多团队在某次调参后效果变差，往往是因为没有记录基线，改来改去不知道是哪个改动引起的。养成记录实验参数与指标的习惯，对长期优化至关重要。

7. 一个容易被忽略的细节：Prompt也会影响检索效果

既然前面反复提到检索结果会进入上下文给到模型，那么Prompt的设计自然也会间接影响“检索效果”。准确地说，Prompt并不会改变检索结果本身，但会影响模型如何利用检索结果——这直接决定最终答案好不好。

我常见的一个错误是：把检索结果一股脑拼进Prompt，不加任何格式标识，也不区分“文档片段”和“用户问题”。结果模型把用户问题也当作文档的一部分，或者把多个不相关文档片段的内容混在一起，生成出的答案既不像引用原文，也不像直接回答。

我现在的做法是，在Prompt中明确区分“检索到的资料”和“用户的问题”，并且明确指令模型只能基于检索资料回答，如果资料中找不到答案，就如实说“不知道”。这个简单的调整，在很多场景下能让忠实度和准确率有明显提升。尤其是当检索结果中存在多个不同观点时，清晰的Prompt会引导模型做更谨慎的取舍，而不是随意混合拼接。

另外一个细节是处理“检索结果为空”或“检索结果相关性极低”的情况。我建议在Prompt中设置一个类似“根据以下资料，如果资料无法回答问题，请直接说资料不足，不要猜测”的指令，避免模型在信息缺漏时自行脑补。这在系统设计的可靠性上很重要——答错远比答“不知道”危害大。

8. 关于RAG的几件长期有效的事

做RAG到现在，我的体会是：真正影响检索效果的因素，往往不是某个惊艳的算法，而是一堆细节能否扎扎实实做好。数据清洗是否彻底，分块是否符合语义边界，Embedding模型是否适配领域，混合检索权重是否经过实测调优，重排逻辑是否合理，评估机制是否真正覆盖了线上场景——这些点看起来平平无奇，但每一个都能让指标肉眼可见地变化。

如果非要给刚接触RAG的人一条最重要的建议，我会说：先搭评估体系，再谈优化。没有评估，你根本分不清自己是在进步还是在原地打转。一套20条样本的黄金测试集，加上跑一次离线评测的脚本，比任何高级算法都更能帮到你。

我还有一个体会是：不要试图用一个模型解决所有问题。检索链路里，Embedding模型、重排模型、生成模型，它们的角色完全不同，术业有专攻。想让系统效果整体提升，应该分别优化每一环，而不是把所有希望押在某个环节的“大而全”上。

RAG的发展远未定型，时不时有新模型、新方法冒出来。但底层的基本功——理解检索本质、掌握混合检索、会做系统评估——是稳定的。把基础打牢，不管工具怎么变，你都能快速迁移和适应。这篇内容如果对你有帮助，照着链路搭一套，踩完一轮坑再回来对照，很多问题会一目了然。