企业官网建设流程全解析

你手里有一堆文档、FAQ、操作手册，业务方又急着上一个能"基于咱们自己的资料回答问题"的智能助手。直接微调大模型？成本高、周期长，新资料一出就得重来。这时候就该轮到 RAG（Retrieval Augmented Generation，检索增强生成）登场了。

RAG 的思路说穿了就一句话：模型不知道答案，但它的"外挂资料库"知道。生成之前先检索，把检索到的相关资料作为上下文塞给大模型，让它看着资料回答。官方点的说法叫知识检索增强，白话讲就是"开卷考试"——不用死记硬背，把参考资料摆在模型面前，要求它照着答案作答。

这篇内容我会从 RAG 系统的整体设计讲起，拆解检索端和生成端的实操细节，把参数怎么定、分块怎么切、Embedding 怎么选、命中率怎么调都捋一遍，再把我实际调试中踩过的一些坑和排查思路整理出来。适合刚接触 RAG、准备在业务里落地一个知识问答系统的朋友参考。

1. RAG 系统整体思路与设计选型

1.1 为什么选了 RAG 而不是微调

我在团队内部推技术方案的时候，通常第一件事就是归档需求和约束。业务方当时的诉求很明确：需要模型回答公司内部的制度、产品文档、售后故障排除手册里的内容，而且资料每个月都会有更新。

如果走微调这条路，意味着要准备一份足够大的高质量问答对数据集。公司文档和问答对完全是两回事，需要人工标注、清洗、构造 prompt，投入的人力成本比开发系统本身还高。而且在每次文档更新后，模型都得重新训练才能学到新内容，周期动辄按周计算。对于知识库频繁变动的业务场景，这是不可接受的。

RAG 的优势正好打在痛点上：

• 文档更新了，只需要重跑一遍索引，或者增量导入，分钟级生效。
• 不需要针对业务构造训练语料，检索质量决定回答质量的上限。
• 可解释性强，回答可以带上引用的来源段落，用户能自己回去翻原始文档，业务方也更容易愿意信任这个系统。
• 冷启动成本低，算上接口调试和系统的代码编写，一个最小可用版本两三天就能跑通。

弊端同样存在：回答的质量强依赖检索效果，检索方案翻车，模型再强也白搭；多一跳检索流程，端到端延迟比直接调模型要高几百毫秒；系统组件变多，从单模型调用变成"检索+排序+生成"的链路，排查问题的难度也上去了。

对比一下这两种路线的适用边界，方便决策的时候对号入座：

1.2 整体架构和关键组件

一个标准的 RAG 系统，按数据流向可以拆成四个环节：查询处理、检索、排序和生成。

查询处理是用户输入问题的第一站。直接拿用户原始的提问去检索，效果通常一般，因为口语化问题、关键词表述和知识库的书面说法经常对不上。这一步可以做改写、扩展、拆分，让检索条件更贴近知识库的表达习惯。

检索是核心环节。系统把用户输入转换成向量，去向量数据库里查语义相近的文本块。现在做检索基本不会只用向量召回，我一般会加一层 BM25 关键词语义召回，把两路结果合并——纯向量方法对这种短文本、专有名词多的场景，命中率不够稳。

排序又叫 Rerank。初步召回的结果按向量相似度排序可能不准确，需要过一遍交叉编码器精排，让模型同时看"问题+文档块"，输出一个更精准的相关性分数，做一次截断，只留下最相关的几段。

生成就是把精排后的结果拼进 Prompt，交给大模型总结归纳。Prompt 里通常还要交代"只能基于给定材料回答，材料里没有的内容直接说明不知道"，这能明显减少编造情况。

1.3 什么时候不适合用 RAG

RAG 也不是银弹，先坦白说说它的适用边界，免得后面踩了坑再后悔。

如果知识库里的内容本身信息密度极低且公说公有理，比如论坛杂谈、未整理的会议纪要，检索到的片段可能无法支撑答案；如果知识库内容属于逻辑链条很长的推理任务，比如"根据这三个公式推导出第四种情况"，直接把多段文字扔给模型并不合适；如果业务要求的是能力增强而非知识注入，比如让模型学会某种固定的输出结构、生成特定风格的文章，RAG 还不如微调来得省心。

一句话总结：RAG 解决的是"知识在文档里，模型不知道"的问题，不是"模型能力不够强"的问题。

2. 检索端实操：决定上限的关键环节

2.1 知识库清洗与切块策略

检索端第一个容易翻车的地方，不是 Embedding 模型选得不够好，而是切块的粒度没找准。文档清洗只是格式层面的工作——去掉页眉页脚、抽取 PDF 表格、统一编码格式。真正的难点在于把长文档切成适合检索的"语义单元"。

切块设计遵循的基本原则是：每一块内容保持语义完整。一段话内不要硬拆，一个表格不要拆开，一个知识点的概念、解释、示例尽量放同一块里。块太长，语义混杂，Embedding 出来的向量指向分散，检索精度下降；块太短，语义残缺，匹配精准但召回的片段内容不完整，生成阶段要去拼凑上下文，效果同样不好。

实际操作中我用的是"固定大小+重叠窗口"和"递归字符分割"的组合策略。先按章节标题切分出大段，再对超过长度上限的大段做二次切分。固定大小的标准参数可以设成每块 512 个 token 左右，重叠量设为 50 到 100 个 token。重叠区域相当于给相邻块之间加了缓冲带，能避免恰好把一个完整知识点拦腰切断。

一个实操中总结出的经验：不同文档类型要适配不同的切分参数。操作手册类文档适合中小块 256 到 384 个 token，因为操作步骤短小精悍，块太大反而引入噪声；规章制度、技术白皮书这种论述型文档适合大块 512 到 768 个 token，因为它们的信息往往分散在多个关联段落里；产品 FAQ 基本上不需要复杂切分，一问一答天然是一块，按条目切就行。

提示：切块策略对检索效果的影响远比想象中更大，我见过团队为了换一个更贵的 Embedding 模型反复调参，结果把相同预算花在优化切分上，效果提升反而更明显。切块不是一个"调一次就完事"的步骤，它应该跟着评估指标不断迭代。

2.2 Embedding 模型选型与向量维度权衡

Embedding 模型的作用是把文本块转成一组浮点数向量，让语义相近的文本在向量空间里距离更近。这个选择直接决定检索质量的上限。

团队里做选型的时候，第一考虑的是嵌入模型对领域文本是否友好。通用模型在公开语料上表现不错，但业务文档里全是专业术语和内部黑话时，表现可能明显下滑。第二考虑的是向量维度，常见的有 384、768、1024、1536 等。维度越高，精度上限越高，但存储成本、检索耗时也随之上涨，单条向量占用空间按维度乘以 4 字节估算。第三考虑的是上下文窗口长度，长文本切块用长上下文模型更舒服，但通常还是建议切块不超过 512 token。

中文场景下，还得多考虑分词对齐问题。很多开源模型的训练语料以英文为主，中文语义表达上天然吃亏。做中文 RAG 选型，要么选专门针对中文优化的模型，要么在开源模型的基础上用自己领域的数据做一遍微调。动手之前先跑一轮评测，把常见的"近义词替换、语序调整、术语变体"这些问题丢进去，看返回的 Top 5 是不是符合预期。

在实际生产里，向量化还有一个容易漏掉的环节：文本规范化。同样的内容，全角半角不统一、繁简混合、中英混排方式多样，都会导致向量偏移。洗数据时统一走一遍文本规范化，比事后调模型参数更划算。

2.3 向量数据库选型与混合检索的必要性

向量数据库的选型，本质上是对"能力边界"和"运维成本"的权衡。做 PoC 阶段用小的嵌入式向量库就够；上了生产，并发查询量和数据量上来了，就得考虑独立部署的向量库。

我按场景整理过一份选型参考：

检索方案上，我强烈建议不要做纯向量检索。原因是纯语义检索有两个明显短板：一是专有名词、编号、型号这类精确关键词，语义上没啥得力信号，向量匹配不出来；二是用户输入短问题，Embedding 化后的语义覆盖不完整。BM25 这类关键词检索恰好能和向量互补，一个管精确匹配和术语召回，一个管同义改写和语义召回，两路结果合并后效果才稳。

混合检索的合并策略上有几个思路：加权和取并集、先并后精排两步走。我在实践里常用的是先召回，后统一交给 Rerank 模块做精排，这样两条召回通道返回的分数不做直接对比，由精排模型统一裁决相关度。

2.4 Rerank：为什么它值得单独占一个模块

很多第一次搭 RAG 系统的朋友都会问一个问题：向量检索返回的结果，本来就是按相似度排序的，为什么还要再做一次精排？

原因在于：向量相似度和"问题是否真正包含了答案信息"之间，存在一个 gap。向量把文本压成一个高维向量，能表达全局语义，但无法精确刻画词与词之间的交互关系。交叉编码器结构让两个文本逐 Token 交互，计算更精细的相关性，精度自然更高。检索阶段为了保证召回率会放宽限制，返回 20 到 50 条候选，但这么多内容不可能全部塞进 Prompt，必须经过 Rerank 截留到 3 到 5 条，用最少的 Token 拿到最高密度的信息。

做 Rerank 的常见的方案有：使用专门的 Rerank 模型服务，效果最好、对接最快，但多一个网络调用；本地部署开源精排模型，延迟低，对硬件有一定要求；用大模型做 Last-Level Ranking，把候选块丢给模型让它按相关性打分，适合候选集不大、对延迟不敏感的场合。

注意：Rerank 的分数和向量相似度分数不能直接对比，它们的分布、标定方式完全不同。不要在代码里用同一个阈值去卡这两个来源，否则某一路的候选会被误杀。

3. 生成端增强：让模型"戴着镣铐跳舞"

3.1 Prompt 模板设计与引用追溯

检索做得再好，Prompt 设计不合理，输出质量照样拉垮。生成端的核心诉求是：让模型严格基于检索到的资料生成回答，同时不丢失自己的语言组织能力。

我常用的 Prompt 模板长这样，直观展示下设计思路：

你是企业知识库的智能助手。请严格基于以下给定的资料片段回答问题。 资料片段： {context} 用户问题：{question} 回答要求： 1. 优先使用资料片段中的信息，做条理化归纳；不得编造资料中不存在的事实。 2. 如果资料片段无法回答用户问题，请直接回复"根据现有资料无法回答该问题"。 3. 回答末尾用[来源:N]标注所引用资料的编号。

这个模板里有三个关键点。第一，给模型一个明确边界，明说"资料里没有，就认怂"。这一点能有效减少幻觉。第二，在资料片段里为每个片段加编号，让模型在表达里顺手引用来源。业务方对这一点相当看重，因为他们需要向用户证明"这不是模型瞎编的，是从官方文档里查来的"。第三，把用户问题放在资料片段之后。实际测试中，问题出现在后文能让模型更聚焦当前的指令语境。

3.2 上下文长度控制与参数调优

生成端的另一个核心是上下文窗口管理：给的资料太多，超长截断，模型抓不住重点，响应也慢；给的资料太少，关键内容没覆盖到，答案自然不全。

参数调优上有四个可调的旋钮，我把经验值列出来：

这些参数的调优不是靠感觉，而是要靠评测跑出来的。挑 50 到 100 条覆盖不同场景的问答对，反复调参后对比输出效果，比听别人说"这个参数设成多少最优"靠谱得多。

还有一个经常被忽视的细节：上下文顺序。精排后的块不要按原始的相似度顺序简单拼接。按相关性降序排列是一个合理选择，把最相关的内容放在上下文靠前位置，模型对 Prompt 头部信息通常更敏感。

3.3 查询改写与多查询扩展

用户提问的方式五花八门，知识库里的说法却相对固定。比如用户问"离职的时候公积金怎么提"，文档里写的是"职工与单位终止劳动关系后，账户封存满半年可办理销户提取"。这种场景下，直接拿原始问句去检索，结果大概率不理想。

解决这个问题有两条路线。

查询改写。先用大模型把用户的原始问题改写成更规范、更贴合文档表达的问句，再拿改写后的问句去检索。比如把口语化的"公积金咋提"改写成"住房公积金提取条件和办理流程"。这是低成本高收益的方案，建议首选。

多查询扩展。针对一个问题，让模型生成多个不同角度的子问题，分别检索后把结果合并再去重。例如问"公司年假怎么休"，可以扩展出"年假天数规定""年假申请流程""未休年假补偿标准"三个子查询，大大增加命中面。

这两条路线的共性代价是增加了一次模型调用延迟，换来的是检索命中率提升。对于问答质量要求较高的场景，这笔延迟开销是值得的。

3.4 缓存与性能开销控制

当 RAG 系统上线后，延迟是必被质问的问题。一次完整链路的耗时分布大约是这样：查询改写的大模型调用占大头，300 到 800 毫秒；Embedding 查询在 30 到 80 毫秒；向量检索在 10 到 50 毫秒；Rerank 在 30 到 120 毫秒；生成答案的大模型调用最长，500 到 2000 毫秒。

整体算下来，一个典型请求的端到端延迟通常会在 1 到 3 秒区间。想优化，思路集中在几个方向：

缓存高频问题。完全相同的用户问题，直接缓存答案；语义相近的问题，做向量相似度检索后命中缓存答案。热点问题差不多能覆盖 30% 到 40% 的流量。异步化和流式输出。生成阶段使用 SSE 流式输出，用户收到第一个 Token 的时间大幅缩短，体感速度快了很多。还有批量 Embedding。离线导入知识库时，按批次批量向量化而不是逐条调用，索引构建时间能节约几倍。

提示：还有一个优化点是并行调用。查询改写、向量检索、BM25 检索这三个环节并不存在严格的先后依赖，可以在代码里并行执行，能压掉近一半的前置耗时。

4. RAG 评估体系与问题排查思路

4.1 离线评估指标怎么建

RAG 系统上线后，怎么证明它比上一个版本好？不能靠拍脑袋看几条问答，要建立一套可复现的评估流程。

评估体系分两个层次。第一个层次是检索质量，主要看召回率和命中率：给定一组标准问答对，正确答案对应的文档片段，有没有出现在召回列表里。第二个层次是生成质量，重点关注忠实度和答案相关性：忠实度是模型回答的内容是否都能在给定材料里找到依据，别自己发挥；答案相关性是回答有没有正面解决用户的问题，不跑偏。

实操中我给团队搭建的最小评估方案是这样的：准备 60 到 100 条评测问题，每条问题标注标准答案和支撑文档块；跑批式执行 RAG 流程，记录检索候选列表、精排列表、最终生成的答案；模型或人工给三个维度打分——检索命中是否在前 5、答案忠实度、答案相关性。

这个流程一周跑一次，每次改动切分参数、Embedding 模型、Prompt 模板之后，都重跑一遍对比分数。用数据说话，而不是用"我感觉效果好多了"来推进项目。

4.2 常见问题速查：检索不到、答案编造、上下文超长

把我在实际项目里遇到过的典型问题和排查结论整理成表，方便对号入座：

针对"答案编造"这个高频问题，多说一句：这往往不是模型的问题，而是检索的问题。而人最容易产生的错觉是"模型在胡说八道"。实际上多数情况是支撑答案的内容埋在文档深处，根本就没被检索出来，模型手里没有正确的原材料，只能根据残缺的上下文"脑补"。所以排查编造问题，第一个动作永远是打开调试面板，看哪些块被召回了，哪些块进入了 Prompt。

4.3 线上问题排查手段

线上系统出了状况，需要快速定位是哪一环出了问题，靠肉眼猜是猜不出来的。在系统设计阶段就应该给链路加上日志记录，关键节点要能追溯：

• 记录用户原始输入和查询改写后的结果，确认改写环节是否引入偏差。
• 记录向量检索和 BM25 检索的召回数量以及 Top 块的内容，确认是否召回为空或丢失关键信息。
• 记录 Rerank 后的截留结果，确认是否有遗漏。
• 记录最终 Prompt 的完整文本，这一步最关键——看到模型实际吃了什么，才能解释它为什么这么回答。

我调线上问题时的习惯是：先看 Prompt，确认支撑材料在不在里面；Prompt 里没有，就回溯到 Rerank 和检索环节看是什么时候丢的，是召回时就没召回，还是精排时被排到后面截断了；最后再怀疑模型本身，毕竟模型输出不受控的情况也是有的，但概率远低于检索问题。

4.4 持续迭代的节奏和方法

RAG 系统的迭代不应该是一锤子买卖，知识库在变，用户提问方式也在变。建议建一个反馈闭环：

每两周做一次线上问答质量抽检，挑 30 到 50 条真实用户问题，人工给检索和答案质量打分。把打分低的问题归因——是知识库没有这个知识、切分导致信息破碎、检索排序不合理，还是生成环节理解偏差。每个归因类别对应一个优化动作：补知识库内容、调切分参数、调召回策略、改 Prompt 模板。改动后重跑离线评测集，对比指标变化。

这套闭环跑起来之后，RAG 系统的质量就不是"上线即巅峰"了，而是能跟着业务一起持续变好。

5. 我再分享几点个人体会

RAG 系统真正落地之后，我最大的感受是：它的技术难点并不在于某个单独环节有多深，而在于权衡。检索精度和召回率要权衡，Prompt 详细度和上下文占用要权衡，回答完整度和延迟要权衡，甚至系统装饰程度和维护成本都是要找平衡点的。

切块大小、top_k、Rerank 模型、Embedding 选型，这些参数凑在一起后是一个互相关联、互相影响的系统。单独调某一个参数可能看不出变化，但组合起来天翻地覆。一套稳定可复现的评测集，是这个领域最值得先投入的东西——没有评测，一切调优都是盲人摸象。

如果现在让我给一个刚起步团队的最终建议，我会说：先用最快的路径把整条链路跑通，哪怕是直连云厂商的各类服务，哪怕只有几十条文档数据，也要先让数据从头到尾流起来。然后再盯着评测指标，一个一个环节往深里调。RAG 最怕的不是效果差，而是停在某个环节反复打磨，忽略了系统的整体目标。