企业官网建设流程全解析

把二十一篇拆开的零件拧成一台能跑的车，这件事我拖了很久。前面那些文章分别讲清了文档解析、切片策略、向量化、混合检索、重排、评测集、部署运维，每一个单独都能落地，但确实没有一篇告诉你它们该怎么按顺序装进同一个系统里。这篇文章就是那个"组装手册"，目标很直接：从0到1搭一个生产级RAG系统，中间每一步都给出选型理由和踩坑提醒，让看过前面21篇内容的你，能照着拼出一台可上线、可维护、效果可评测的机器，而不是停留在Demo阶段。

1. 定架构：生产级系统必须做对的三件事

1.1 先回答一个比技术更重要的问题

很多人上来就聊大模型选型、向量库对比、Embedding模型哪个分高，架构图上画得漂漂亮亮，一上线就翻车。原因很简单：生产级和学术Demo的边界不一样。

学术Demo的验收标准是"某个测试集上跑出了一个好看的数"，生产级的验收标准是"线上真实流量下能不能稳定输出、出错了能不能解释、数据变了能不能感知、成本能不能控住"。这两套逻辑几乎处处冲突。

我在某公司内部帮一个业务线搭知识库问答系统时，最开始就吃过这个亏。当时花了两周把检索链路调得很好，评测集上Recall@5到了0.9，结果一接入真实工单数据，立刻暴露出三个问题：第一，文档更新的实时性没人管，用户昨天刚提交的工单，今天系统根本查不到；第二，知识库里有大量带权限的合同文件，向量检索把所有片段一视同仁地暴露给了所有人；第三，线上日志里根本没有"这次回答引用了哪个片段"的记录，出了问题找人复盘全靠猜。

所以这篇文章的第一个结论就是：搭RAG之前，先定义清楚你的数据流、权限边界和可观测性，再谈模型和算法。模型选错了可以换，Embedding效果差可以调，但数据流设计错了，返工成本是指数级的。

1.2 整体数据流与组件分工

一个生产级RAG系统的完整链路可以拆成五层，我习惯用一张表把它们的分工和失败模式都列出来，设计时就照着表逐项确认：

每一层的失败模式都不太一样。比如接入层的解析错误是隐蔽的——文档解析出来少了一页，索引和检索不会报错，但用户问到那一页的内容，系统就一脸茫然。再比如生成层的引用错位，模型在答案里标了个来源编号，但那个编号对应的片段和答案内容根本对不上，这类问题如果不靠日志和评测去抓，用户反馈出来时已经积累了一堆投诉。

建设顺序也很重要。我的建议是先跑通"接入-切分-向量化-检索-生成"的最小闭环，让业务方看到端到端效果，再回头补权限、增量、监控这些工程化能力。否则一上来就把系统设计得特别重，团队容易把精力耗在基础设施上，等真正调效果的时候已经没劲了。

1.3 技术选型里的三条现实经验

选型这件事，我不太爱写"某某工具吊打某某"这类结论，因为不同公司的基础设施、运维能力、团队熟悉度完全不同。但有三条经验是通用的：

第一，向量存储选型看过滤能力和生态，不止看召回效果。生产环境里基本都要做权限过滤、时间过滤、业务线过滤，如果向量库的元数据过滤能力很弱，要么你把过滤变成检索后处理（性能差），要么你被迫拆多个集合（运维复杂）。实测下来，过滤的灵活度和写入吞吐这两个指标，比单测里那零点几个点的Recall差异重要得多。

第二，大模型推理服务要支持流式输出和并发控制。RAG系统的体验瓶颈往往不在首token时延，而在整体回答节奏。流式输出能让用户第一时间看到内容在生成，感知延迟大幅下降。并发控制则是防爆手段，不控制并发，一次推广活动带来的流量可以直接把你的推理成本打穿。

第三，优先用团队已经熟悉的开源组件，新玩具要单独做隔离验证。公司如果已经重度使用了某套检索中间件，就不必为了"向量检索更酷"而引入另一套重系统。先把手里的工具用好，遇到明确瓶颈再换，这是最不容易返工的路。

2. 文档与索引：决定RAG上限的预处理细节

2.1 文档加载比想象中更花时间

很多人以为文档解析就是把PDF和Word拖进代码里跑一段"解析器"，然后得到一个字符串列表，两小时搞定。真实情况是，解析花掉整个项目30%的时间很正常，而且解析质量直接决定后续所有环节的天花板。

我在做某企业制度库的时候，第一版解析规则非常简单：按段落切分，提取纯文本，去掉换行。上线后很快就发现一个魔幻现象：用户只要问"年假有多少天"，系统给出的答案里频繁出现"第5页仅供参考"这种引用。查了日志才发现，解析器把PDF的页眉页脚也提取进了正文，切分时这些页眉和正文混在一起，模型被干扰后就开始胡说。改法也不复杂：解析时把页眉、页脚、页码、水印这些噪声标记出来并过滤掉，日期和编号字段单独保留成元数据，不参与正文切分。

格式归属和表格处理是另一个大坑。Word里"标题2"这个东西，在解析结果里如果丢掉了层级信息，那你后面的"按标题切分切片"就无从谈起。至于表格，纯文本化会把一个三行五列的表拦腰截断，导致检索时只看得到表格的一部分。对这类内容，我目前比较认可的做法是保留块级结构：每个标题、每个段落、每个表格块都打上类型标签，切分时再把相邻的同结构文本聚合起来。这样虽然实现起来复杂一点，但远期收益很高，尤其当知识库里有大量表格类内容的时候。

2.2 切分策略如何影响召回

切分的目标是让每个片段保持语义独立、边界清晰。字符窗口切分是最省事的，按512或1024个token硬切，写起来几分钟，但后果是片段经常把两个无关话题的边界切断，或者把一句话切得支离破碎。

我在生产环境里实际验证过几种做法，比较推荐的是**"标题优先 + 段落聚合 + 重叠窗口"的组合**：先按文档的标题层级把内容组织成一棵目录树，叶子节点是每个标题下的段落；然后把过短的叶子节点向上合并到父节点，避免出现只有一行字的废话片段；最后再做一个固定窗口的重叠切分，给长段落留出上下文缓冲。这样做的效果是：大多数片段有明确的主题边界，长文档也能覆盖到。

这里要特别提一下"父子分块"这个思路，它在处理"检索到片段但上下文不足"的问题上非常有用。简单来说，检索子块（比如一个几十字的段落），但喂给模型的上下文是父块（比如整个章节），这样既能精确定位到相关内容，又能让大模型理解完整的上下文。代价是多一次查询、多一层存储映射，但我认为这对很多知识库场景都是值得的。

2.3 Embedding的质量验证

Embedding模型选型，最容易踩的坑就是"榜单崇拜"——看哪个模型在公开榜上分高就换哪个，结果换完之后业务指标毫无变化甚至倒退。原因很简单：公开榜单的测试集（语义相似度、句子聚类这些任务）跟你的业务数据分布不相干，真正有效的验证方式是拿你自己的知识库做召回测试。

我自己的做法是，在项目一开始就留出三组测试集：

• 一组是语义相似样本，比如"怎么申请加班费"和"加班补贴的申请流程是什么"；
• 一组是专名和编号样本，比如"PRD-2024-033号文档"这种精确词汇；
• 一组是否定和条件样本，比如"不包含外包人员的名单"和"包含外包人员的名单"这种极易搞混的查询。

之后每次换Embedding模型，都在这三组上跑Recall@K对比。Second组的结果尤其能说明问题：通用Embedding模型在语义匹配上做得很好，但在专名、编号、缩略语上常常失手，因为这类词在训练语料里出现的上下文太少，向量表征拉不开距离。这时就需要混合检索来兜底了，后面一节会细说。

另外，Embedding模型的服务化是一个经常被忽略的环节。前期实验可以按批处理来跑，生产环境则必须把它变成一个独立服务，负责把用户Query和文档片段统一编码。这里有一个典型坑：线上服务的模型和批量建立索引时用的模型版本不一致，导致向量空间错位，检索效果突然劣化。这个问题的排查难度很高，因为你肉眼看起来所有配置都对，但向量已经不在同一个语义空间里了。解决方式就是建立模型版本号机制，每次发布新Embedding模型都要同步重建索引，并且让检索服务校验索引版本。

3. 检索与生成：召回、重排、上下文编排的完整链路

3.1 多路召回：向量检索不是唯一通道

如果只保留一路向量检索，系统在大量真实查询下会表现出令人沮丧的脆弱性。比如用户输入一个员工编号"E10234"，问"这个人的考勤记录"，向量检索可能把它当成普通文本去算语义，返回一堆根本不含这个编号的片段。再比如用户查询"不是外包的员工"，向量检索对否定语义的区分能力很弱，容易把"外包员工"的文档也召回来。

我常用的做法是至少保留三条召回通道：

1. 向量检索：负责语义相近的内容召回；
2. 关键词/倒排检索：负责专名、编号、精确短语的命中；
3. 规则或者元数据过滤查询：比如按文档类型过滤、按日期范围过滤。

多路召回的数据合并是最容易出现技术债的地方。不同通道的分数尺度不一样，直接相加会导致某一通道完全主导结果。一个比较稳妥的做法是RRF（倒数排名融合）：根据每个片段在各通道的排名位置来打分，把不同通道拉齐到同一尺度上，然后再做综合排序。实现简单，效果稳定，几乎没有需要调的超参。

3.2 重排是低成本高回报的环节

重排模块我愿称之为"整个RAG系统里性价比最高的20毫秒"。召回阶段为了覆盖率会把候选范围放得很宽，但精排阶段必须压缩到几个最相关的片段，否则拼接给大模型之后，噪声片段会严重干扰生成质量。

重排模型一般用交叉编码器这类架构，把Query和片段拼在一起做深度交互，比向量检索的双塔结构更精准。这里可以做一个类比：向量检索像是在一个大仓库里通过索引标签找东西，速度快但只看个大概；重排则像是把你拿候选清单上的每件东西都拿起来仔细端详再决定留下哪几个。代价是慢，但因为我们只在Top 20~50的候选上做重排，实际耗时可控。

我在实战中还发现，重排模型同样需要本地化验证。公开榜单上分数很高的重排模型，在你的领域数据上未必好用。正确的做法是准备几十个典型Query，每个Query配好标准答案片段，直接在重排模型上做一次Recall@5对比测试，十几分钟就能出结果。这个验证成本很低，但收益很高，因为重排模型选对了，同样的召回结果下生成质量能提升一大截。

3.3 上下文编排与引用溯源

检索和重排搞定了之后，生成阶段的上下文编排是最后一道防线。这里有几个细节：

上下文窗口不是越多越好。把尽力召回的所有片段都拼进去，会让模型注意力被无关内容稀释，反而更容易产生幻觉。我的习惯是：重排后只取前3~5个片段作为上下文，并且按重排得分顺序放置，同时加入来源标识。

片段之间的语义冲突要敢于处理。知识库里经常存在旧版本文档和新版本文档内容矛盾的情况。做法是在索引阶段就代入生效日期元数据，生成阶段对冲突内容做时间兜底，优先采纳最新版本。

引用必须可追溯。我给系统的每条回答都加了引用标记，在流式输出时把每个片段对应的文档标题和片段ID一并返回。前端可以展示引用角标，后端可以记录日志。很多人在搭建时觉得引用是"锦上添花"，但它其实是生产级系统的刚需——没有引用，用户和运维方都没有办法快速判断回答是否可信。

幻觉抑制不能只靠提示词。我在提示词里加了"如果知识库中没有足够信息，请明确回答不知道，不要编造"之类的约束，这有一定作用，但不充分。真正有效的做法是在生成结果后加一道轻量校验：把生成内容的关键实体和片段内容做匹配，如果发现答案里出现片段里完全不存在的人名、编号、数字，就要标记为低置信结果，走人工确认流程。这道校验不用很复杂，但能拦掉相当一批明显的幻觉。

4. 质量与监控：评测集、线上日志与反馈闭环的落地

4.1 先造一个能跑回归的评测基座

没有评测集的RAG系统，所有优化都是在沙滩上盖楼。这个结论我强调过很多次，但依然有团队说自己"项目太急，先上线再说"。结果就是，改了一版切分策略之后，不知道效果变好还是变坏；换了一个Embedding模型，说不清线上故障是不是它导致的。

评测集的建设可以分三块来凑：

1. 线上日志沉淀：从用户真实Query里抽样，最好是近三个月内的，覆盖不同难度的查询；
2. 历史工单/FAQ：把业务方已有的标准问答对拿来做标准答案，这是最省力的标注来源；
3. 人工构造的边界样本：包括否定句、多跳问题、专名查询、需要明确拒绝回答的问题等。

评测指标的设置要分层。检索层看Recall@K、命中率（答案所在片段是否被召回到）；生成层看忠实度（回答是否忠实于上下文）、完整性（是否回答了用户的问题）、引用准确率（引用编号是否对应到正确片段）。生成层的指标现在多用大模型来评，节省人力，但要提防两个问题：一是评估模型和生成模型如果来自同一套体系，可能存在偏袒倾向；二是评估指标的口径要写死，否则每次评估结果不可比。

4.2 线上日志揭示真实质量

线上日志在很多人眼里是"排查故障用的"，但在RAG系统里它更是质量分析的核心数据源。从第一天开始我就把日志设计成结构化，每条回答至少记录五个字段：

• 用户输入Query
• 检索召回Top N片段的ID和得分
• 重排后实际拼入上下文的片段ID
• 最终回答内容和引用标记
• 用户后续行为（点赞、点踩、复制、继续追问、离开）

有了这些数据，就能设置几项很实用的监控：无引用回答率（回答没有引用任何知识库片段，大概率是模型瞎答了）、检索为空率（找不到任何相关片段，说明知识库有缺口）、高延迟占比（超过20秒的回答比例，说明检索或生成链路有瓶颈）、低置信标记率（幻觉校验系统标记的疑似编造比例）。

线上出问题不可怕，可怕的是出问题后没法定位是哪个环节的锅。有了结构化日志之后，排查路径就很清晰了：先看检索为空还是召回低质，再看重排是否压掉了正确答案，最后检查是生成阶段引用错位还是模型幻觉。这个排查顺序，我建议每个维护RAG系统的团队都沉淀成一份SOP文档。

4.3 回归测试如何组织

评测集建好之后，要让它变成一个持续运转的回归机制。每改动一个环节——无论是升级Embedding模型、调整切分策略、还是修改提示词——都要跑一遍评测集，把结果和上一个基线的对比发出来。对比至少要看三个维度：检索指标有没有下降、生成指标有没有明显波动、典型案例有没有出现新问题。

这个机制最好能自动化。我在实践中采用的方法是脚本定时跑，每天早上先生成一份质量报告，把和上一版的指标差异高亮出来，再人工抽查几个典型案例。加了这套回归机制之后，团队的优化心态会变得稳健很多：不再凭感觉换参数，而是每次改动都能回答"它让哪些指标变好了，哪些指标变差了"。

5. 部署与运维：推理加速、缓存策略与版本演进的细节

5.1 三段式延迟的优化思路

生产级RAG系统的延迟，大致由三段时间叠加而成：Embedding计算、向量检索、重排、大模型生成。其中大模型生成通常占60%~80%的耗时，尤其是回答内容较长的时候。优化思路也对应着分三路走：

Embedding和重排这类相对小的模型，优先做常驻GPU推理并发优化，用批量推理提升吞吐，单请求时延控制在几十毫秒级；向量存储的瓶颈在查询吞吐和过滤复杂度，通常通过扩容副本、优化索引参数来缓解；大模型生成则主要通过流式输出来提升体验感知，首token时延比总时延更重要。

5.2 缓存与降级策略

生产系统必须有缓存意识，否则一次知识库批量更新导致的峰值检索流量就能把系统拖垮。缓存分两层：

第一层是Query级缓存，适用于高频重复提问的场景，命中后直接返回上一轮的结果，省掉整条链路；第二层是语义缓存，思路是把Query做向量化，和近期缓存的Query计算相似度，超过设定阈值就直接复用答案。语义缓存实现不复杂，但隐私和数据一致性要考虑清楚，带权限隔离的内容不建议在缓存层复用。

降级策略同样重要。我设计系统时给每个关键依赖都预设了降级预案：搜索服务不可用时，退化成纯关键词匹配而不是让用户报错；Embedding服务不可用时，直接用关键词召回兜底；生成模型不可用时，返回检索到的原始片段列表，至少让用户拿到资料。降级策略看似"难看"，但保证了系统永远有最低限度的可用性。

5.3 增量更新与版本灰度

知识库的更新频率直接影响系统的可信度。常见的问题是：管理员往系统里传了一堆新文档，但索引任务失败半路挂了，用户仍然查询不到新内容。处理增量更新的几个细节：

增量任务要幂等且可重跑。每个文档需要有唯一的索引标识，任务失败后重跑时不会重复写入或产生脏数据；版本号要贯穿全链路。Embedding模型版本、切分策略版本、知识库快照版本，三者对齐才能保证索引和检索的一致性；灰度发布。每次模型或策略升级，先让内部用户试用一个时段，对比线上日志的指标表现，确认无异常后再放开全量流量。

最后再补一条很个人化的经验：如果这是你第一次从0到1搭RAG系统，先不要贪多，用小范围的知识库（比如几百篇文档）把整条链路完整跑通，把评测集、日志、报警做起来，再逐步扩大知识规模。因为小系统上暴露问题的代价低，排查链路也短，等你把整个机制的坑都踩过一遍，扩大规模只是一个重复劳动问题，而不是一个智力挑战。